>>the bottom line is that requiring anything really doesn’t mean bugs will
>just disappear
Below is I think a good example I received from a fellow developer the other
day.
Most of you have probably seen deprecation warnings on sprintf among other
things. It recommends you change to sprintf_s, which has an extra parameter
saying how long the buffer is.
What it doesn’t say is that it nulls out the entire contents of the buffer
beyond what you print.
EG: sprintf_s( buf, 500, “hello” );
This will write “hello” to the buffer, and then write 495 nulls. If you have
any code where you get the buffer size wrong, or sprintf to buf + 10 instead
of just buf (like me, when porting some existing code), then you may wipe
whatever memory happens to be past that buffer. It probably also applies to
most of the other ‘secure’ CRT _s versions of functions too.
Of course, I’m sure that the rest of you are far smarter than I and would
never make such a mistake as this, but consider this a heads up if you
weren’t aware 
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> All I’m saying, albeit not very clearly, is that you yourself are saying
> that WDM had problems, and I am wondering how you would feel if, instead
> of KMDF, WDM was the requirement for the types of devices the KMDF is
> now to support. My understanding is the one of the purposes of KMDF was
> to, once again, simplify the code required to support Plug and Play and
> Power Management, in, once again, and object oriented fashion. It seems
> that the first attempt did not turn out to well, so, given this, I don’t
> see why it is hard to understand why people are upset about a new
> framework being required.
>
> As for your point about Kernel32.DLL, I agree that, indeed, you must
> trust Microsoft for some things. Fine. That argument, however, applies
> equally well to the versioning issues I presented in other modules,
> which, pretty clearly, really suck. Your picking a module that has
> worked very well, and, perhaps, that will apply to KMDF. Perhaps not.
> Kernel32 is an unavoidable requirement. KMDF is, as evidenced by the
> fifteen years or so (or something like that) of NT history, quite
> clearly, not. And to me, the bottom line is that requiring anything
> really doesn’t mean bugs will just disappear, and, considering that one
> can circumvent (by design) KMDF, and there is no source code for it, it
> doesn’t mean that they will even improve. This same argument (that
> using X will produce better results in and of itself) has been applied
> to things like Visual Basic, every other 4GL in existence, Garbage
> Collection, C++, eXtreme Programming, et. c., and none of them produce
> that result, because it is impossible, and very, very few of them
> actually were better overall.
>
>
>
>
>
>
>>>> xxxxx@synaptics.spamblock.com 2006-10-05 19:52:14 >>>
> I can’t really parse this paragraph, but I think Martin’s asking if I
> think it would be all right for Microsoft to require you write your
> drivers in WDM.
>
> Depending on exactly what is meant by “WDM”, and exactly what kinds of
>
> drivers you’re talking about, Microsoft has been requiring exactly that
>
> for a long time, at least for drivers that you want them to certify.
> Ummm, can’t say I’m all that unhappy… considering the
> alternatives…
>
> What’s the point, exactly?
>
> WHQL requires that you install your drivers using PnP methods rather
> than patching the registry too (which you could do using lower-level,
> but otherwise perfectly valid APIs)… is that equally offensive?
>
> Martin O’Brien wrote:
>> My basic question to xxxxx@synaptics.com is, based on what he actually
>> quoted, how happy he or she would have been if Microsoft had made
> the
>> same stipulation requiring WDM? Its existence, and, in this sense,
> the
>> existence of KMDF itself, would seem to nullify arguments to the
> extent
>> that some of us are overreacting to the situation, as if it couldn’t
>> possibly occur, or even that is unlikely. It already has. I don’t
> mean
>> that critically, as that’s just part of the software development
> cycle,
>> until there exists stipulations that one must use it. As I see it, it
> is
>> a hard requirement, because “It’s not like Microsoft is saying you
>> can’t write a WDM mouse/keyboard driver, or even ship it to your
>> customers, they’re just saying that Microsoft doesn’t want to have
>> anything to do with it if you do” doesn’t, and shouldn’t mean
> anything
>> to them.
>>
>>
>>
>>
>>
>>
>>>>> xxxxx@cristalink.com 2006-10-04 19:48:14 >>>
>>> You don’t statically link to kernel32.dll either, but that doesn’t
>> seem to
>>> bother anyone
>>
>> The trouble is, kernel32 is present in 99.99% Windows installations,
>> while
>> KMDF must be redistributed, with all the hassles of installing it.
>>
>>> They fix bugs in that thing all the time and that doesn’t seem to
>> bother
>>> anyone.
>>
>> Yeah, right. For me, bugs in Windows are the major source of
>> problems. I
>> can fix my own bugs, but I can’t fix Microsoft ones. And Microsoft
>> won’t fix
>> them either, at least within a reasonable time frame, say a year or
>> two. I
>> claim this based on my own experience in multiple cases.
>>
>>> They don’t give you the source either, and that doesn’t seem to
> bother
>>
>>> anyone.
>>
>> Yes, it does.
>>
>>
>>
>>
>> “Ray Trent” wrote in message
>> news:xxxxx@ntdev…
>>> You know, when this requirement was first articulated, I pitched a
>> big fit
>>> for quite some time for a lot of the same reasons people have
>> discussed
>>> here.
>>>
>>> Then I calmed down and really thought about it.
>>>
>>> First of all, KMDF is nothing like MFC. They serve entirely
>> different
>>> purposes and accomplish their goals in entirely different ways.
> KMDF
>> is
>>> much more like “the way WDM should have been done in the first
> place,
>>
>>> because damn that thing is crufty and awful and way too
> complicated”.
>>
>>> Another way of looking at it is that KMDF is a lot more like NDIS.
>>>
>>> As for the “but we can’t statically link” argument: It’s part of
> the
>> dang
>>> OS. You don’t statically link to kernel32.dll either, but that
>> doesn’t
>>> seem to bother anyone (and think of what a nightmare that would
>> be).
>>> They fix bugs in that thing all the time and that doesn’t seem to
>> bother
>>> anyone. They don’t give you the source either, and that doesn’t
> seem
>> to
>>> bother anyone.
>>>
>>> Where was the huge outrage when Microsoft “hid” all the
> installation
>>
>>> details in UpdateDriverForPlugAndPlayDevices rather than “letting”
>> driver
>>> writers call the SetupAPI functions directly themselves?
>>>
>>> Sure, it’s new… but I suspect that a whole lot of kernel32.dll
> in
>>
>>> Vista is brand-spanking new too. At some level we have to trust MS
> to
>> do
>>> their job. Frankly, I know Doron reasonably well, and that gives me
>> quite
>>> a bit of confidence that KMDF is implemented as well if not better
>> than
>>> kernel32.dll was.
>>>
>>> I don’t know anything about SDIO or cellphone drivers, but as for
>>> mice/keyboards, I very much doubt that anyone writing one of those
> is
>>
>>> doing anything really all that complicated WRT the stuff that KMDF
> is
>>
>>> “hiding”. And if they are, that’s probably a pretty big red flag
>> (insert
>>> sheepish admission that I had to figure out a few tricky ways
> around
>> how
>>> KMDF does things during our port because our driver was being
>> “bad”).
>>> It’s not like Microsoft is saying you can’t write a WDM
>> mouse/keyboard
>>> driver, or even ship it to your customers, they’re just saying that
>
>>> Microsoft doesn’t want to have anything to do with it if you do. I
>> don’t
>>> really want to have anything to do with it either…
>>>
>>> Maxim S. Shatskih wrote:
>>>> About KMDF. I’m very much worried about the amount of KMDF
>> questions
>>>> here
>>>> on forums, most of which are due to a) people do not know WDM b)
>> KMDF is
>>>> source-less. Without the kind help of Doron, these people would be
>> stuck.
>>>> Note: MFC is provided with source, and KMDF to WDM is what is
>> MFC to
>>>> Win32.
>>>> Also note: MFC does not free the person from knowing Win32
>> itself,
>>>> though
>>>> yes, the need in Win32 knowledge with MFC is very small - only to
>> solve
>>>> the
>>>> hard issues.
>>>> Any framework provides an illusion that “now all complexities
>> are
>>>> solved”.
>>>> Not so. The simple and streamlined things are done much easier,
> but,
>> if
>>>> the
>>>> hard issue arises - then the framework complicates the things a
> lot,
>> the
>>>> person
>>>> will need to know both the framework and the underlying platform.
>>>>
>>>>> without worrying about hidden locks, et. c. It seems to me that,
>> if one
>>>>> looks at the history of software failures, they have several
> things
>> in
>>>>> common, one of which is invariably the use of new and relatively
>>>>> untested tool to attempt solve what generally boil down to
>> personnel,
>>>>> management and budgetary problems, the last of which is for the
>> most
>>>>> part intractable in many cases; i. e. - lack of dedicated
> resources
>> for
>>>>> testing. I think one of the major problems with any new tool,
> and,
>> in
>>>>> particular, mandating its use, is that its capabilities are
>> evaluated by
>>>>> its architects and original developers, and, in the process, some
>> very
>>>>> unattractive realities about the mistakes that the general public
>> might
>>>>> make, as well as poor decisions get ignored.
>>>> Correct. If the bla-bla architect - or just business people -
>> mandate
>>>> some
>>>> tool - then the chances of tool-based failure are very high. For
>>>> instance - the
>>>> user wants some feature, and the tool just crashes trying to
>> implement
>>>> it, as
>>>> it was with ill memored PowerBuilder in mid 90ies.
>>>>
>>>>> case with C++ - that Bjarne was able to translate real C programs
>> to C++
>>>>> with only a 2% performance drop is nice, but not all that
>> meaningful, as
>>>>> most of us are neither geniuses nor original architects. That
>> being
>>>>> said, we are not incompetent, as neither probably were the people
>> at
>>>>> Mentor Graphics, or any of the others who led the early large
> scale
>> C++
>>>>> projects outside of Murray Hill Labs, almost all of which failed
>>>> IIRC Borland did the first production C++ compiler in 1990, before
>> this,
>>>> only
>>>> “cfront” existed. The first MS’s C++ compiler was IIRC 1992 or
> 1993,
>>
>>>> always a
>>>> 32bit EXE itself - running under PharLap (PharLap embedded to the
>> binary)
>>>> on
>>>> DOS, in virtual DOS machine under PharLap on Windows 3.x and as
>> native PE
>>>> in
>>>> Windows 95/NT. This is how MSVC 1.5x worked.
>>>>
>>>> The UNIX and open-source people turned to C++ MUCH later then
> people
>>
>>>> working
>>>> for DOS/Windows with Borland’s or MS’s tools.
>>>>
>>>> Maxim Shatskih, Windows DDK MVP
>>>> StorageCraft Corporation
>>>> xxxxx@storagecraft.com
>>>> http://www.storagecraft.com
>>>>
>>>>
>>> –
>>> Ray
>>> (If you want to reply to me off list, please remove “spamblock.”
> from
>> my
>>> email address)
>>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from
> my
> email address)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
This is what I did with power tests. HCT S1/S3/S4 test was ridiculously slow and weak so I wrote my own and our QA use 100 - 1000x more power cycles for testing. They quickly started like some drivers, especially graphic ones, which can’t survive it