RE: build environment for 64 bit driver - general questio ns

I guess we stupidly and stubbornly want to focus on the problems we are
trying to solve by writing kernel mode code rather than the tools we are
using to write the code.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of KMillar
Sent: Thursday, June 16, 2005 9:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] build environment for 64 bit driver - general questions

Alberto,
I totally agree with you.
For some reason some people in this industry are soooo reluctant to let go
of their command line tools and complex build environments. I do not
understand why such people use Microsoft tools to develop code for Windows.
They are obviously longing to return to their *nix roots.

“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> This idiot uses a project file for both 32-bit and 64-bit, and it works
> fine. As he pointed out in a recent thread, it’s way more important to
> achieve commonality between driver and application than to follow the
> party line 100% percent. About the specific points in this post,
>
> 1. Driver building is a nearly unmaintainable mess today, and the
> judicious use of an IDE goes a long way towards alleviating it.
>
> 2. If you do your job right you will not get any more wrong than anyone
> elsewhere. No offense intended, but I for myself trust my hand more than
> anyone else’s, including people who work for Microsoft.
>
> 3. Nothing replaces a thorough, comprehensive and deep understanding of
> the machine architecture, its hardware, its instruction set, the
> peripheral(s) you’re trying to support, the C or C++ language you use to
> develop your code, and the code you write. If you achieve that, tools such

> as Driver Verifier or PreFast can be quite irrelevant: do you job
> thoroughly and carefully and you don’t need props.
>
> 4. It’s not my job to debug Microsoft’s code. Sorry, dudes, if you choose
> to do that, that’s your prerogative, but don’t demand it. Furthermore, as
> I see it, the only bit of the DDK that should really be necessary are
> the include files and possibly a library or two - everything else is
> superfluous and Occam’s Razor alone tells us to be very stingy in using
> it. These things are like taxes: you pay them if you must, but you pay the

> least possible and you grumble a lot when you need to. Because, again, no
> offense intended, I trust my hand better than anyone else’s, including the

> people who put the DDK together.
>
> And what do you know ? My software works, and it has been working for a
> long, long while.
>
> Now, one point. One reason why driver writing today is, and I capitalize
> for emphasis,
>
> THERE IS NO COMMON RUNTIME SYSTEM THAT PERFORMS WELL BOTH IN RING 3 AND
> RING 0,
>
> and, also,
>
> THERE IS NO COMMON COMPILER THAT CAN GENERATE CONSISTENT CODE FOR BOTH
> RING 0 AND RING 3,
>
> and,
>
> MANY OF THE VERY NICE INDUSTRY-STRENGTH DEVELOPMENT TOOLS ROUTINELY USED
> BY APPLICATION WRITERS DO NOT SUPPORT KERNEL DEVELOPMENT,
>
> and finally,
>
> THE CONCEPT OF WIZARD-DRIVEN PROGRAM GENERATION AND DEVELOPMENT,
> COMMONPLACE IN MFC AND IN .NET, IS NOT SUPPORTED IN DRIVERLAND.
>
> The issue isn’t that kernel development is “special” or “harder” in any
> way; it’s just that the powers of that be (Microsoft, are you listening?)
> do not support kernel development to the same extent they support
> applications development. Hence the addons, and what do you know ? They’re

> very, very welcome, at least to some of us idiots. And again, our software

> tends to work just as well as anyone else’s.
>
> So, dudes, there’s more than one way to skin a cat, and there’s more than
> one way in this profession of ours to act like an idiot.
>
>
> Alberto.
>
>
>
> ----- Original Message -----
> From: “Don Burn”
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, June 16, 2005 6:43 AM
> Subject: Re: [ntdev] build environment for 64 bit driver - general
> questions
>
>
>> Use Ddkbuild, the approach of a project file does not work for 32 bit or
>> 64 bit. The idiots who do this should be flogged to the edge of their
>> lives. I have gone in to multiple customers who have gotten sold this
>> concept, and fixed their problems by just converting them to a real build

>> environment. Using the visual studio stupidity you:
>>
>> 1. Create a unmaintable mess, since Micosoft has been known to
>> change the options
>> 2. Introduce corner cases, since it likely you will get something
>> wrong
>> 3. Disable the use of tools such as the driver version of PreFast
>> and Static Driver Verifier
>> 4. Make it impossible to submit a bug to Microsoft on the DDK, since

>> you are playing by the rules
>>
>> If you want to do crap like this, stay out of the Windows kernel.
>>
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> ----- Original Message -----
>> From: “Olav”
>> To: “Windows System Software Devs Interest List”
>> Sent: Thursday, June 16, 2005 3:01 AM
>> Subject: [ntdev] build environment for 64 bit driver - general questions
>>
>>
>> Hello all,
>> does anybody have some working project file for Visual Studio 2003 / 2005
>> used to compile x86-64bit WDM driver? Is there any sample project
>> available somewhere?
>>
>> Issues I am interested in are:
>> - how to define the driver entry point (for 32bit was used
>> driver_entry_function@8, but it doesnt seem to work with same settings
>> under 64bit driver, neither @16 do)
>> - what optimisations, discovered parameters for compiler are good to use
>> for driver
>> - what calling conventions are you using to declare these and other (eg
>> PNP) functions?
>> - what method are you using to use assembler code (eg which external
>> compiler)?
>>
>> Thanx!
>> Olav
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Gotta agree with Mark, and I used to use Walter Oney’s driver wizard in VS 6
to create driver projects. However, with the advent of .NET and soon version
8 of VS, things tend to change in the VS IDE environment to rapidly. Case in
point: they have changed the solutions and projects once AGAIN so that
loading a solution/project from .NET into Whidbey alters it such that you
can’t run it in .NET. You have to restore the sln and vcproj files from
backups. Wonderful … I have one solution and MANY project files that
someone else created under .NET, which means chasing down all those vcproj
files.

Like Mark said, I can spend my time debugg’n my tools or debugg’n my driver.
I and my boss prefer I debug the driver, not the tools I use to develop the
driver. Besides, Mark’s DDKBUILD allows you to painlessly use both worlds.
Did I say painlessly?


The personal opinion of
Gary G. Little

“Roddy, Mark” wrote in message news:xxxxx@ntdev…
>I guess we stupidly and stubbornly want to focus on the problems we are
> trying to solve by writing kernel mode code rather than the tools we are
> using to write the code.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of KMillar
> Sent: Thursday, June 16, 2005 9:03 AM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] build environment for 64 bit driver - general
> questions
>
> Alberto,
> I totally agree with you.
> For some reason some people in this industry are soooo reluctant to let go
> of their command line tools and complex build environments. I do not
> understand why such people use Microsoft tools to develop code for
> Windows.
> They are obviously longing to return to their *nix roots.
>
>
> “Alberto Moreira” wrote in message news:xxxxx@ntdev…
>> This idiot uses a project file for both 32-bit and 64-bit, and it works
>> fine. As he pointed out in a recent thread, it’s way more important to
>> achieve commonality between driver and application than to follow the
>> party line 100% percent. About the specific points in this post,
>>
>> 1. Driver building is a nearly unmaintainable mess today, and the
>> judicious use of an IDE goes a long way towards alleviating it.
>>
>> 2. If you do your job right you will not get any more wrong than anyone
>> elsewhere. No offense intended, but I for myself trust my hand more than
>> anyone else’s, including people who work for Microsoft.
>>
>> 3. Nothing replaces a thorough, comprehensive and deep understanding of
>> the machine architecture, its hardware, its instruction set, the
>> peripheral(s) you’re trying to support, the C or C++ language you use to
>> develop your code, and the code you write. If you achieve that, tools
>> such
>
>> as Driver Verifier or PreFast can be quite irrelevant: do you job
>> thoroughly and carefully and you don’t need props.
>>
>> 4. It’s not my job to debug Microsoft’s code. Sorry, dudes, if you choose
>> to do that, that’s your prerogative, but don’t demand it. Furthermore, as
>> I see it, the only bit of the DDK that should really be necessary are
>> the include files and possibly a library or two - everything else is
>> superfluous and Occam’s Razor alone tells us to be very stingy in using
>> it. These things are like taxes: you pay them if you must, but you pay
>> the
>
>> least possible and you grumble a lot when you need to. Because, again, no
>> offense intended, I trust my hand better than anyone else’s, including
>> the
>
>> people who put the DDK together.
>>
>> And what do you know ? My software works, and it has been working for a
>> long, long while.
>>
>> Now, one point. One reason why driver writing today is, and I capitalize
>> for emphasis,
>>
>> THERE IS NO COMMON RUNTIME SYSTEM THAT PERFORMS WELL BOTH IN RING 3 AND
>> RING 0,
>>
>> and, also,
>>
>> THERE IS NO COMMON COMPILER THAT CAN GENERATE CONSISTENT CODE FOR BOTH
>> RING 0 AND RING 3,
>>
>> and,
>>
>> MANY OF THE VERY NICE INDUSTRY-STRENGTH DEVELOPMENT TOOLS ROUTINELY USED
>> BY APPLICATION WRITERS DO NOT SUPPORT KERNEL DEVELOPMENT,
>>
>> and finally,
>>
>> THE CONCEPT OF WIZARD-DRIVEN PROGRAM GENERATION AND DEVELOPMENT,
>> COMMONPLACE IN MFC AND IN .NET, IS NOT SUPPORTED IN DRIVERLAND.
>>
>> The issue isn’t that kernel development is “special” or “harder” in any
>> way; it’s just that the powers of that be (Microsoft, are you listening?)
>> do not support kernel development to the same extent they support
>> applications development. Hence the addons, and what do you know ?
>> They’re
>
>> very, very welcome, at least to some of us idiots. And again, our
>> software
>
>> tends to work just as well as anyone else’s.
>>
>> So, dudes, there’s more than one way to skin a cat, and there’s more than
>> one way in this profession of ours to act like an idiot.
>>
>>
>> Alberto.
>>
>>
>>
>> ----- Original Message -----
>> From: “Don Burn”
>> To: “Windows System Software Devs Interest List”
>> Sent: Thursday, June 16, 2005 6:43 AM
>> Subject: Re: [ntdev] build environment for 64 bit driver - general
>> questions
>>
>>
>>> Use Ddkbuild, the approach of a project file does not work for 32 bit or
>>> 64 bit. The idiots who do this should be flogged to the edge of their
>>> lives. I have gone in to multiple customers who have gotten sold this
>>> concept, and fixed their problems by just converting them to a real
>>> build
>
>>> environment. Using the visual studio stupidity you:
>>>
>>> 1. Create a unmaintable mess, since Micosoft has been known to
>>> change the options
>>> 2. Introduce corner cases, since it likely you will get something
>>> wrong
>>> 3. Disable the use of tools such as the driver version of PreFast
>>> and Static Driver Verifier
>>> 4. Make it impossible to submit a bug to Microsoft on the DDK,
>>> since
>
>>> you are playing by the rules
>>>
>>> If you want to do crap like this, stay out of the Windows kernel.
>>>
>>> Don Burn (MVP, Windows DDK)
>>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>>> Remove StopSpam from the email to reply
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: “Olav”
>>> To: “Windows System Software Devs Interest List”
>>> Sent: Thursday, June 16, 2005 3:01 AM
>>> Subject: [ntdev] build environment for 64 bit driver - general questions
>>>
>>>
>>> Hello all,
>>> does anybody have some working project file for Visual Studio 2003 /
>>> 2005
>>> used to compile x86-64bit WDM driver? Is there any sample project
>>> available somewhere?
>>>
>>> Issues I am interested in are:
>>> - how to define the driver entry point (for 32bit was used
>>> driver_entry_function@8, but it doesnt seem to work with same settings
>>> under 64bit driver, neither @16 do)
>>> - what optimisations, discovered parameters for compiler are good to use
>>> for driver
>>> - what calling conventions are you using to declare these and other (eg
>>> PNP) functions?
>>> - what method are you using to use assembler code (eg which external
>>> compiler)?
>>>
>>> Thanx!
>>> Olav
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
>>> ‘’
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>>
>>>
>>> —
>>> Questions? First check the Kernel Driver FAQ at
>>> http://www.osronline.com/article.cfm?id=256
>>>
>>> You are currently subscribed to ntdev as: xxxxx@ieee.org
>>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>