unresolved external symbol _atexit

NTDEV
21

See below.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Wednesday, December 03, 2008 4:53 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] unresolved external symbol _atexit

The driver object has been taken over by NDIS. It no longer belongs to us.
Device object creation is done in the port driver and not in the miniports.
Yes, it could be workable in a ‘normal’ driver. In the NDIS world, we don’t
own the driver object and it is passed to the NDIS registration call. That
is the only time we touch it. None of the normal setting up of function
pointers occurs. I realize you know this, but someone reading might be
misled.
****
Actually, I’ve never worked in the NDIS world, so no, I didn’t know it. And
under those conditions, the use of a global to hold the information would be
required.
****
I think much of this occurs with KMDF also which is why there is a special
way to register with KMDF that keeps it from trying to own the driver
object. A sample NDIS driver is supposed to show how this is done so you
have an upper NDIS edge, but a lower KMDF edge. I have not looked at that
sample since we only have our hardware below us and no other driver is
called, but it is useful for a USB network adapter.

I do agree with what you say about some that think passing parameters down
the stack is expensive. The solution is to keep the parameters in the
device extension where everyone can have access to them. Those that are
unique to a specific request then can be packaged into one structure to
reduce the amount of data being pushed on the stack. I think the prefast
default stack limit test of 1KB is a little excessive for many drivers. I
like to keep a single function’s stack usage to below 256 bytes and even
that is a little high for legacy file system filters where reentrancy is a
possibility due to other filters. That is a big advantage to the minifilter
model.
****
Stack space is the limitation; time is not (when a function call/return
takes 350ps, that is 175ps call and 175ps return, on a 350ps (2.8GHz)
pipelined superscalar architecture, with each parameter push costing a
whopping 175ps, it is hard to sustain the argument that function calls are
expensive. The alternative is to allocate a block of storage which is the
parameter block holding all relevant information, and pass only a pointer to
that struct. Since this involves storage allocation, which *is* expensive,
the alternatives are a block of preallocated objects (sort of dangerous) or
a lookaside list.
****

However, if this world of device drivers were easy, it wouldn’t be as much
fun or pay as much. Even with miniports, minifilters, and KMDF it is still
far more difficult than writing C# for small user programs. The
interactions between other drivers both OS and third party, can keep you
learning and thinking.
****
If we didn’t get challenged, life would get real dull real fast
joe
****

“Joseph M. Newcomer” wrote in message
news:xxxxx@ntdev…
See below.



From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Wednesday, December 03, 2008 2:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] unresolved external symbol atexit

There are justifications for using globals, but generally you are correct in
that they are misused. If you have a crash dump callback for secondary data
and your driver supports multiple instances of your hardware, using a global
is the only way to find all your device structures.

Wouldn’t this be doable simply by finding the DRIVER_OBJECT and walking its
list.?

Since you are running at HIGH_LEVEL in the callback, you only need to see if
the global linked list was in the process of being updated and if not you
can grab the information you need to add to the dump. Some of the WMI
performance information might be driver oriented vice device specific, so
that can be another justification.


Yes, the driver-level stuff is one of the justifications. Unfortunately,
the drivers I’ve seen aren’t at all that sophisticated, they just declare
global variables “So I don’t have to keep passing parameters down the stack,
because that’s expensive!” ARGH!

Most of the crashes are from concurrent access to these variables. The
usual: “We plugged a second device in, and every time we do this it
bluescreens”. I’m sure you’ve all seen these. Reading these drivers is
about as much fun as chewing on lemons for several hours.

I had once case where they said “The system would just hang, and someone
told us we were getting deadlock, so we started removing spin locks until it
stopped deadlocking”.


Please be specific as to the problems you think local static values can
cause. I see some use for them, but don’t think I have done it in a driver
recently. I do see a place where a table is needed and it should not be
exposed via a global. That table is initialized at compile time and not
modified during execution, so I think it is acceptable. It is an easy way
to do a type of data & code binding as is done in C++, but in standard C.
It could be done with a global, but it shows its usage and restricts its
access easily.
****
The usual one is “retaining state for the next call”. In a preemptive,
multiprocessor, preemptive threading environment, with the possibility of
multiple instances of the device, this is extremely dangerous; these are all
old C application programmers to whom the concepts of “threads” and
“concurrency” are a foreign language. When I explain race conditions to
them, they assure me that these are not possible because.and go off on some
single-threaded explanation that cannot possibly work. What I tell my
students is “If you have a global variable or local static variable that is
not preceded by the word ‘const’, consider that you have probably made a
coding error. When you get sophisticated enough that you know what you are
doing, you will realize that there are two exceptions: write-once constants
and true global state” In our book on device drivers, we actually chose a
DDK example driver for discussion that uses genuine global state, among
other reasons so we could talk about the need for and proper management of
global state, but in general, drives with global state and static local
variables represent the first or second driver the coder has written, and
they are still thinking single-threaded application-level code.

So when I see a global variable, the first thing I do is see how it is being
(mis)used, and I’m almost always right about the (mis) part.

Of course, they way they solve this is to correct it by stuffing it into the
device extension, without actually solving the fundamental race conditions
that can occur. About half the time, they win by accident, because once it
is no longer shared across all device instances, there is not a problem.
But sometimes it is passive/dpc/isr level concurrency that nails them.
Either the algorithm is fundamentally wrong, or there is no synchronization.

The problem is that they don’t have a good “ownership” model of the data
(e.g., the buffer pointer in the extension is either “owned” by the dequeue
handler, or the ISR, or the DPC, sequentially and never concurrently, and it
will work. Or there is an overlap, and I still get “but a++ is an atomic
operation, so cannot fail!” (How they determined this is unknown, since I
rarely see the compiler generating an INC instruction.but it was once true
on a couple machines in the past [PDP-11 and Vax] so someone probably passed
this on as “urban legend”).

There’s nothing wrong with const and pseudo-const (write once at
initialization and never change) data, but that’s not where I see the
problems.

joe

“Joseph M. Newcomer” wrote in message
news:xxxxx@ntdev…
Which raises the issue: why are there global objects in a driver? This is
extremely risky (in general, most people who declare global objects are C
application programmers who are not aware of the numerous problems this
creates in a driver-and for that matter, they shouldn’t have been global
objects anyway, even in C, but most people are prone to using them). Every
driver that I have ever reviewed that had a global declaration (other than
the write-once pseudo-const of saving the DriverEntry path value) got it
wrong. (The next step down is declaring local static values in functions.a
really dangerous practice much beloved by C programmers)
joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Wednesday, December 03, 2008 12:35 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

It is also used for implicitly generated code for global constructors and
destructors as previously mentioned.

Check for global instances of class objects.

- S

_

From: Joseph M. Newcomer
Sent: Tuesday, December 02, 2008 22:29
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol atexit
atexit is a user-mode library call. Look it up in the MSDN (atexit). This
is used to create user-library exit calls in the C runtime library. So you
are probably misusing C++ in some fashion to cause it to call a CRT
user-level library call.
joe

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Tuesday, December 02, 2008 10:06 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] unresolved external symbol _atexit

hello folks,

i am geting this weird linker error when i try building the driver. any
clues?

the driver has c++ classes in it, but no dynamic allocation/dealloc.

thanks

AP

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.

22

>Wouldn’t this be doable simply by finding the DRIVER_OBJECT and walking its list.?

The list is undocumented, internal only and you cannot acquire _IopDatabaseLock which guards it.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

23

>I do agree with what you say about some that think passing parameters down the stack is expensive.

I would group parameters to structures and pass the structure pointer. Since the structure itself is on the caller’s stack, the values are not copied to the callee’s stack.

You can also allocate it from the lookaside.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

24

I could actually give some important uses of essentially global objects in a
driver, although I actually dynamically allocate these in DriverEntry (and
deallocate in unload) like Bob Kjelgaard’s example.

  1. a global driver object, that has things like debugging level and registry
    parameters read during DriverEntry
  2. memory pool objects (similar to look aside lists) used for other object
    allocations/freeing

You could just get away with the single global driver object, and make any
other globals be a member variable. I know in my C++ drivers, I use a macro
at the beginning of every class definition that allocates some metadata
(like class name and virtual debug dump of the object), and also defines a
static class variable that holds the allocation pool for that class of
object. Keeping these static class variable definitions with the class
definition seems clearer than having to update the members of a global
driver class.

My class definitions looks something like:

class BusPdo : public OSDevice {
public:
CLASS_META_DATA(“BusPdo”);
CLASS_POOL_ALLOCATOR(‘DPGX’);
BusPdo(void);
virtual ~BusPdo(void);
…
};

The macro CLASS_META_DATA defines the metadata methods (since C++ has lame
run-time metadata, I have virtual methods to return the correct metatdata)
and the macro CLASS_POOL_ALLOCATOR looks like:

#define CLASS_POOL_ALLOCATOR(poolTagValue) \
static ObjectMemoryPool * memoryPool; \
static const ULONG poolTag = poolTagValue; \
__forceinline void *operator new(size_t size) { return
memoryPool->Allocate(size, poolTagValue);}; \
__forceinline void operator delete( void * ptr, size_t size ) {
memoryPool->Free(ptr, size, poolTagValue);};

This does require me to allocate the class static and my driver
initialization code to have a whole set of lines that look something like
(one per class):

BusPdo::memoryPool = new
(sizeof(BusPdo),0,1,BusPdo::poolTag)ObjectMemoryPool;
if (BusPdo::memoryPool)
…

Note that these class statics are pointers or scalers, NOT class instances,
so there is no need for global class constructors (which take run-time
support).
In the next C++ driver framework I write (I’m on my fourth, they are the IP
of my employers), I’ll probably try to do a little better about simplfying
this class boilerplate code.

Globals objects would have a lifetime longer than a device instance lifetime
or are shared between device instances. Unlike an application, where you
enter some sort of “main” routine and don’t exit that routine for the entire
lifetime of the program, drivers have no “permanent” stack frame, not to
mention much more lmited stack size. I allocate nearly all objects in pool,
except for some really tiny ones like local spinlocks or smart pointers. Due
to limited kernel stack size, non-tiny objects allocated in local frames is
bad, just like non-tiny C struct’s allocated in frames is bad.

It seems like there has been some misunderstanding on how easy it is to
start using C++ in a driver. It’s been a few years since I was starting a
frameowrk, but as I remember all you need to do is put the following in a
.cpp file:

class demoClass {
public:
long aMemberVar;
demoClass(void) { aMemberVar = 0;};
virtual ~demoClass(void);

// class private allocators
__forceinline void *operator new(size_t size) { return
ExAllocatePoolWithTag(NonPagedPool, size, ‘tag1’);};
__forceinline void operator delete( void * ptr, size_t size ) { if (ptr)
ExFreePoolWithTag(ptr, ‘tag1’); };
};

Once you declare the class you can go:

demoClass *anInstance;
anInstance = new demoClass;

Of course really effectively using C++ in a driver is a little more complex.

Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, December 03, 2008 11:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

Which raises the issue: why are there global objects in a driver? This is
extremely risky (in general, most people who declare global objects are C
application programmers who are not aware of the numerous problems this
creates in a driver-and for that matter, they shouldn’t have been global
objects anyway, even in C, but most people are prone to using them). Every
driver that I have ever reviewed that had a global declaration (other than
the write-once pseudo-const of saving the DriverEntry path value) got it
wrong. (The next step down is declaring local static values in functions.a
really dangerous practice much beloved by C programmers)
joe

25

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 12:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

It seems like there has been some misunderstanding on how easy
it is to start using C++ in a driver.
You can be right but it seems OP has enough problems even without C++ so
better would be to avoid it. I’d say C++ in kernel is only for
experienced developers who know what they’re doing and who are able to
solve problems themselves. Such a developer woudln’t ask the original
question.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com http:</http:>]

26

I decided to go back to the first post in this thread to add this reference:

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

“A P” wrote in message news:xxxxx@ntdev…
hello folks,

i am geting this weird linker error when i try building the driver. any clues?

the driver has c++ classes in it, but no dynamic allocation/dealloc.

thanks

AP

27

Hi Michal,

I’d agree with you there, kernel C++ is not for beginers. My view is all
kernel software is not for beginners. I’d hope all the non-beginners would
at least play with C++, and get a sense of it. For MANY years I thought C++
was pure junk, but somewhere along the way I figured out that I liked it a
lot more than straight C.

Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, December 03, 2008 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 12:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

It seems like there has been some misunderstanding on how easy it is to
start using C++ in a driver.
You can be right but it seems OP has enough problems even without C++ so
better would be to avoid it. I’d say C++ in kernel is only for experienced
developers who know what they’re doing and who are able to solve problems
themselves. Such a developer woudln’t ask the original question.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http:</http:> http://www.upek.com]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

28

Jan,

I’d distinguish beginners and kernel mode beginners. It someone falls to
both categories, it is sad story :slight_smile: Also, I’d distunguish average kernel
programmers and really experienced ones. C++ in kernel needs real
experience IMO.

BTW, have yous seen UMDF WDK samples? They’re written in C++. I’m not
C++ expert, I wrote much more code in C but these samples look as really
strange C++ for me. As if a C programmer is forced to use C++ because of
COM interfaces used but still thinks and writes in C. I’d like to see
opinion from C++ driver programmers. (I asked our user mode C++ expert
and what he said can’t be published ;-))
Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com http:</http:>]

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

Hi Michal,

I’d agree with you there, kernel C++ is not for beginers. My
view is all kernel software is not for beginners. I’d hope all the
non-beginners would at least play with C++, and get a sense of it. For
MANY years I thought C++ was pure junk, but somewhere along the way I
figured out that I liked it a lot more than straight C.

Jan

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, December 03, 2008 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 12:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol
_atexit

It seems like there has been some
misunderstanding on how easy it is to start using C++ in a driver.
You can be right but it seems OP has enough problems
even without C++ so better would be to avoid it. I’d say C++ in kernel
is only for experienced developers who know what they’re doing and who
are able to solve problems themselves. Such a developer woudln’t ask the
original question.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com
http:</http:> ]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other
seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR
Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars
visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

29

Michal Vodicka wrote:

I’d distinguish beginners and kernel mode beginners. It someone falls
to both categories, it is sad story :slight_smile: Also, I’d distunguish average
kernel programmers and really experienced ones. C++ in kernel needs
real experience IMO.

BTW, have yous seen UMDF WDK samples? They’re written in C++. I’m not
C++ expert, I wrote much more code in C but these samples look as
really strange C++ for me. As if a C programmer is forced to use C++
because of COM interfaces used but still thinks and writes in C. I’d
like to see opinion from C++ driver programmers. (I asked our user
mode C++ expert and what he said can’t be published ;-))

I think that blanket, non-specific criticism like this of a large and
easy target is not useful in any way. These samples were not offered as
shining golden examples of state-of-the-art C++ programming. These are
drivers – small, special-purpose. They are interfacing with APIs that
are, for the most part, C APIs. Many of them were probably ported from
WDM drivers written in C.

Do you actually have any real criticisms, or are you just casting a net
of derision for effect? Honestly, what did you expect?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

30

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 04, 2008 6:37 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] unresolved external symbol _atexit

I think that blanket, non-specific criticism like this of a large and
easy target is not useful in any way.

It was more astonishment than criticism.

These samples were not
offered as
shining golden examples of state-of-the-art C++ programming.
These are
drivers – small, special-purpose. They are interfacing with
APIs that
are, for the most part, C APIs.

Sorry, that’s not rigth. We’re speaking about UMDF and they’re mostly
using WDF COM interfaces. C APIs are seldom used, usually only few Win32
functions.

Many of them were probably
ported from WDM drivers written in C.

Porting in this case would mean total rewrite. I guess they were portted
from KMDF samples, instead.

Do you actually have any real criticisms, or are you just
casting a net
of derision for effect? Honestly, what did you expect?

I expected discussion and opinions from C++ experts.

As for real criticism, the worst for me seems usage of COM interfaces.
Instead of using ATL or some other kind of smart pointers, normal
pointer are used and references are handled manually. It is not only
tedious and strange, it is also dangerous. It is not necessary to use
all C++ features but why not use a small subset which makes code
cleaner, safer and more readable?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

31

Michal Vodicka wrote:

As for real criticism, the worst for me seems usage of COM interfaces.
Instead of using ATL or some other kind of smart pointers, normal
pointer are used and references are handled manually. It is not only
tedious and strange, it is also dangerous. It is not necessary to use
all C++ features but why not use a small subset which makes code
cleaner, safer and more readable?

Yes, here I will agree with you. It seems that MANY Windows C++
programmers are deathly afraid of ATL, and it is much to their
detriment. ATL has a GREAT collection of template classes that can make
C++ code shorter and much easier to read. For example, quick, write a
little utility that opens a mapped view of a file and scan it. Now, how
many parameters do CreateFile and MapViewOfFile have? But with ATL, I
can practically write it without checking the references:

#include <atlfile.h>
CAtlFile f;
f.Create( argv[1], GENERIC_READ, FILE_SHARE_READ, OPEN_ALWAYS );

CAtlFileMapping fm;
fm.MapFile( f );

Now I can do (PUCHAR)fm and start reading bytes. Same thing for
registry access:

CRegKey key;
key.Open(
HKEY_CLASSES_ROOT,
“CLSID\{926ddb16-3c8e-476c-9068-eb4555a99231}\InprocServer32”,
KEY_READ
);

DWORD dwVal;
key.QueryDWORDValue( “DelayCount”, dwVal );

My admiration of ATL extends to WTL, from the same team, which
considerably simplifies the writing of small GUI apps.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</atlfile.h>

32

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 04, 2008 7:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] unresolved external symbol _atexit

Yes, here I will agree with you. It seems that MANY Windows C++
programmers are deathly afraid of ATL, and it is much to their
detriment. ATL has a GREAT collection of template classes
that can make
C++ code shorter and much easier to read.

This is what I mean. Samples should be easy to read so a beginner isn’t
lost in ugly implementation details. I’m just working on an UMDF driver
and using CComPtr alone makes significant difference in both
readability and reliability. No more

SAFE_RELEASE(ptr1);
SAFE_RELEASE(ptr2);
…
SAFE_RELEASE(ptrN);

> My admiration of ATL extends to WTL, from the same team, which
> considerably simplifies the writing of small GUI apps.

Our application team agrees with you. They were quite happy after switch
from MFC monster to WTL. Now, they’re switching to C#.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

33

Well, firstly C++ and ATL are two different things.

As far as ATL is concerned, the initial UMDF samples did not use ATL to not throw one more variable at the driver developers. The theory was that if a developer knows ATL he/she can easily translate the sample to ATL usage but if he/she doesn’t know ATL then that is one more thing to learn and it is not transparent what’s going on. It is true that not using ATL leads to more code.

With 1.7 release there is a SocketEcho sample which uses ATL, so now we have both.

Aside from lack of ATL usage if you have feedback about C++ usage in the sample we would love to hear it. Likewise if you have feedback on the ATL sample, that is welcome too.

Thanks,
Praveen

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, December 04, 2008 11:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, December 04, 2008 7:42 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] unresolved external symbol _atexit

Yes, here I will agree with you. It seems that MANY Windows C++
programmers are deathly afraid of ATL, and it is much to their
detriment. ATL has a GREAT collection of template classes
that can make
C++ code shorter and much easier to read.

This is what I mean. Samples should be easy to read so a beginner isn’t
lost in ugly implementation details. I’m just working on an UMDF driver
and using CComPtr alone makes significant difference in both
readability and reliability. No more

SAFE_RELEASE(ptr1);
SAFE_RELEASE(ptr2);
…
SAFE_RELEASE(ptrN);

> My admiration of ATL extends to WTL, from the same team, which
> considerably simplifies the writing of small GUI apps.

Our application team agrees with you. They were quite happy after switch
from MFC monster to WTL. Now, they’re switching to C#.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

34

I wrote many of the core UMDF samples and reformatted some of the others into the current style. The WPD team wrote their own samples, as did the sideshow folks and I can?t attest for what they look like.

I wrote these to minimize the amount of C++ magic being used because I wanted them to be approachable by folks who (to be honest) fear C++. I chose not to use ATL ? even though it does make the COM stuff easier ? for similar reasons. ATL depends on a lot of magic. Once you?ve really come to trust the magic it?s pretty helpful. If you?re new to it then the magic makes you want to tear your hair out. I?ve spent hours spelunking through the ATL headers trying to figure out which special macro I was missing which would allow my driver to compile.

Feel free to publish what your C++ expert said ? I?d be happy to hear it. Chances are I won?t agree with it but that?s a different matter :slight_smile:

-p

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, December 04, 2008 9:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

Jan,

I’d distinguish beginners and kernel mode beginners. It someone falls to both categories, it is sad story :slight_smile: Also, I’d distunguish average kernel programmers and really experienced ones. C++ in kernel needs real experience IMO.

BTW, have yous seen UMDF WDK samples? They’re written in C++. I’m not C++ expert, I wrote much more code in C but these samples look as really strange C++ for me. As if a C programmer is forced to use C++ because of COM interfaces used but still thinks and writes in C. I’d like to see opinion from C++ driver programmers. (I asked our user mode C++ expert and what he said can’t be published ;-))

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.comhttp:</http:>]

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 3:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit
Hi Michal,

I’d agree with you there, kernel C++ is not for beginers. My view is all kernel software is not for beginners. I’d hope all the non-beginners would at least play with C++, and get a sense of it. For MANY years I thought C++ was pure junk, but somewhere along the way I figured out that I liked it a lot more than straight C.

Jan

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, December 03, 2008 4:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, December 04, 2008 12:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] unresolved external symbol _atexit
It seems like there has been some misunderstanding on how easy it is to start using C++ in a driver.
You can be right but it seems OP has enough problems even without C++ so better would be to avoid it. I’d say C++ in kernel is only for experienced developers who know what they’re doing and who are able to solve problems themselves. Such a developer woudln’t ask the original question.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.comhttp:</http:>]

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

35

Peter Wieland wrote:

I wrote many of the core UMDF samples and reformatted some of the
others into the current style. The WPD team wrote their own samples,
as did the sideshow folks and I can’t attest for what they look like.

I wrote these to minimize the amount of C++ magic being used because I
wanted them to be approachable by folks who (to be honest) fear C++.
I chose not to use ATL … even though it does make the COM stuff easier
… for similar reasons. ATL depends on a lot of magic.

I would have to disagree with that. It IS true for CString; building
the seemingly simple CString classes requires three separate include
files with a level of complexity that one rarely sees outside of STL,
but the COM wrappers, the file wrappers, the registry wrapper, and most
of the collection classes are rather straightforward.

However, it is great to get an insight into the thinking behind some of
these decisions. Thanks for that.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

36

>Instead of using ATL or some other kind of smart pointers

Smart pointers are even not ATL, they are existing as _com_ptr_t in some base header of Visual Studio since at least 1998.

Yes, in C++, they are good.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com