I thought industry have evoluted beyond the point of this argument. C++ is a
BETTER C to me. Outside kernel such as GUI and object container type of
programming, C++ is far far better than C. Ever programmed Motif? How does
it compare to MFC?
In kernel one just needs to know not over use C++ in kerenl (as well as in
many other places), not kind abuse of C++ like ACE.
I stop using DriverWorks but instead have my own C++ library so I can keep
it mean and lean and not overly wrapping an C API.
Note that NT kernel API is mostly objected based API. Therefore there are
actully not much code/speed saving in using C.This is because most kernel
APIs require a context and state such as certain object and your own
DeviceExtension.
For example, in most your C functions, you say
YourImplemetationOfSomeDDKDefinedFunctionPrototype(DeviceObject, …)
{
MYEXTENSION* MyExtension = (MYEXTENSION*) DeviceObject->DeviceExtension;
…use… MyExension->this_and_that …all the time…
}
in C++
YourImplemetationOfSomeDDKDefinedFunctionPrototype(DeviceObject, …)
{
CMyDevice* pMyDevice = (CMyDevice*) DeviceObject->DeviceExtension;
pMyDevice->MyImplemetationOfXXX(…);
}
There is one more delegation of function call because kernel API is C API.
But this is not so bad, you could even use __fastcall in your C++ define of
the member function. the “this” and usually the IRP will be passed by
registers. And you can use __forceinline on your member function so there is
no penalty in using C++ compare to C if the function is used only in one
place or two. It makes your code cleaner since you simply access your data
members in your class “this-and-that” (implicitly this->this_and_that).
Another example is C++ template library wrapping of list/map/queue/tree is
easier and cleaner than using C API and CONTAINING_RECORD macro while it
incurs no overhead and code size penalty compared to C because its inline
nature.
Using a C++ library saves you a lot of typing, copy-paste-modify-rename. It
is more robust code reuse.
Look at Microsoft class, port, miniclass, miniport driver model, etc. I
wished it could be in a class library form. So instead of filling a function
table, miniclass/miniport driver simply implement pure virtual functions
(they arein the function tables), instead of calling XXXClassYYYFunc, which
more times than not is yet-another-wrapper of kernel API, one just make a
call to the base class suport functions.
Look at DMA adapator object API, does that not look like a C++ object?
Things like MDL etc.
In my C++ library, I don’t have many layers of inheritance, most no more
than two, but a lot of #ifdef #endif in the base class. So it is (almost) as
lean as any well written C code.
For example
class MyBaseDevice
{
#ifdef WDM_DRIVER
// wdm style driver
#ifdef PCI_DEVICE
// PCI related things
#endif // PCI_DEVICE
#ifdef USB_DEVICE
// USB related things
#endif // USB_DEVICE
#else // WDM_DRIVER
// NT 4.0 style driver
#endif // WDM_DRIVER
};
#define WDM_DRIVER
#define PCI_DEVICE
class MyPciDevice : public MyBaseDevice
{
};
This has a template effect that keeps class as flat as possible while
accomdate commons of many different devices without code bloating
I heard BeOS kernel is mostly written in C++. BeOS was known smaller and
faster than NT. If the kernel API is in C++, there is no inherit advantage
of using C. C++ is not only OOP (even though not a pure one), but also a
type safe language.
Bi
-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Friday, October 18, 2002 3:22 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Batch file for Visual Studio build, was Why not u se
BUILD [was Re: Errors while building samples of DriverStudio in Windo ws XP]
This is the first mistake C++ programmers make; C++ is NOT a better C. I
surly understand C++. I towed the C++ band wagon for many years. This is
exactly the problem; using C++ features in a C way to make a better C. How
many programmers have I met that called C++ a better C. Might as well go
back to Pascal.
If your driver requires C++, I recommend reviewing your design. The last
thing I want in a driver is multiple layers of abstraction and as for
constructor and destructor; give me a break; literally.
Has anyone ever wondered why all MS drivers are in C; at least the ones in
the DDK?
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Justin Frodsham
Sent: Friday, October 18, 2002 2:37 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Batch file for Visual Studio build, was Why not u se
BUILD [was Re: Errors while building samples of DriverStudio in Windo ws XP]
That doesn’t sound like an informed comment. Where do you draw the line on
C++ features that should be used? What if a guy is just using C++ as a
better C than C? If I had a nickle for every time some grouchy old school
programmer that has no interest in understanding what c++ really is, I
wouldn’t have to work. Passing objects on the stack by value etc is not a
good idea, but calling simple member functions to objects has no more
overhead than calling a C function.
-Justin
At 09:22 AM 10/18/2002, you wrote:
Well, if you are using C++ in your drivers, the build environment is the
least of your worries.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com [ mailto:xxxxx@lists.osr.com
mailto:xxxxx ] On Behalf Of Bi Chen
Sent: Friday, October 18, 2002 12:08 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Batch file for Visual Studio build, was Why not u se
BUILD [was Re: Errors while building samples of DriverStudio in Windo ws XP]
Peter.
I beg to differ. I have been using Visual Studio .dsp for years on more than
dozen of drivers, long before driverworks was out.
Here is a sample of batch file that is improved from Walter’s batch file
that you can modify to build your driver for any NT Family OS. It uses DDK’s
own setenv.bat to set environmental variables and compiler/link to be used
first. Then it allows you to add additional environmental variables to fit
your project. I keep sources file around for automatic release build by QA
people
BTW, using “start msdev.exe /useenv” does not leave the command prompt (dos
box) window around. Dsp file setting should be sync to new OS DDK by
comparing the compiler/link options in build log file with that in dsp
project setting.
Here is the batch file
echo Setting BASEDIR
REM You must set DDK for target OS
SET BASEDIR=C:\Win2kDDK
REM You must set TARGET OS because Microsoft does not make it any easier
SET TARGETOS=WIN2K
SET DEFAULTLIB=%LIB%;
call %BASEDIR%\bin\setenv.bat %BASEDIR% checked
if “%TARGETOS%” == “WINXP” goto setenvxp
SET IFSKIT_INC_PATH=%BASEDIR%\src\filesys\inc
SET
INCLUDE=%SDK_INC_PATH%;%DDK_INC_PATH%;%WDM_INC_PATH%;%IFSKIT_INC_PATH%;%INCL
UDE%
SET LIB=%SDK_LIB_DEST%%CPU%;
goto launch
:setenvxp
SET
INCLUDE=%CRT_INC_PATH%;%SDK_INC_PATH%;%DDK_INC_PATH%;%WDM_INC_PATH%;%IFSKIT_
INC_PATH%;
SET LIB=%SDK_LIB_DEST%%CPU%;
:launch
REM Additional include and lib
SET LIB=%LIB%;%DEFAULTLIB%;
REM SET ADDIOTNAL ENVIROMENTAL VARIABLES
REM SET PATH=%PATH%;ADDITIONAL_PATH
REM SET INCLUDE=%INCLUDE%;ADDITONAL_INC
start “Launching…” MSDEV.EXE /useenv
Bi
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com mailto:xxxxx]
Sent: Friday, October 18, 2002 10:01 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Why not use BUILD [was Re: Errors while building
samples of DriverStudio in Windows XP]
That’s all nonsense, Alberto, you should know better.
(“Remove my DOS box for security?” Knock knock… BUILD doesn’t run under
DOS or in any sort of DOS box. In runs at the Windows command prompt. It’s
NOT DOS. And it’s NOT removable in any supported way.?
It is absolutely, positively, professionally irresponsible to RECOMMEND that
anybody build a driver for Windows XP or .NET 2003 using anything other than
the compiler and linker shipped in the DDK.
Like Visual Studio (I can’t imagine why, but lets say you do): Great. Just
use an external build procedure and thereby get the correct tools.
I’ve said this before: The DDK ships the correct compiler and linker for
building drivers. It was not easy for the DDK team to get these included in
the DDK at no extra cost. There’s a REASON that they are there. I see
build problems all the time due to using the wrong tools.
If YOU want to use different tools to build Windows drivers, by all means,
have a good time. You are experienced enough, and clever enough, and
probably have enough time and resources to make it work. This is a personal
decision.
Heck, I’ve seen people write drivers for Windows NT using Borland C++…
But PLEASE… Don’t encourage others to use THE WRONG compiler and linker.
It doesn’t make sense. “Hey, I recommend you use a compiler and linker
different from the one that Microsoft recommend, even though I have no way
of knowing the difference”.
That’s just not providing good advice to people, and it is most certainly
NOT doing the driver community a service.
Peter
OSR
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev news:xxxxx …
>
> It’s command line oriented, it won’t run if I rename or remove my dos box
> for security reasons. It requires maintaining a separate sources file and
> possibly dir files. It does not adapt itself to dynamic changes to the
> project or the solution. It makes it hard to do things piecewise, for
> example, compile files in onesies and twosies without building. Its output
> is not integrated with the rest of the IDE. It requires me to jump from
> window to window, or to add custom steps to my project.
>
> Sorry, that’s the way it used to be when I was a kid back in the sixties,
eh
> ? But this is the twentieth first century now, time to move on.
>
>
> Alberto.
>
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: zeppelin@io.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%</news:xxxxx></mailto:xxxxx></mailto:xxxxx>