But Peter, assume Src2Dsp does a good job of (1) setting up environment
variables as they should, (2) setting up compiler and linker sequences in
the proper way, (3) taking care of all the other things in such a way that
what’s generated is just a good old Microsoft style build. After all,
build.exe isn’t but a shell around nmake, and nmake itself doesn’t create
anything but batch streams. These batch streams are, in the end, what the
IDE generates as well. The only difference is, in one case I have a command
line environment, in the other I have a GUI-based interactive one.
Would you still object ? That’s what we’re aiming at with Src2Dsp, just to
have a tool where one can take an existing build.exe environment, and create
a .dsp project that does exactly the same thing.
Alberto.
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Friday, October 18, 2002 3:18 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Why not use BUILD [was Re: Errors while building
samples of DriverStudio in Windows XP]
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> One more thing: for the diehards, we put a “build” button on the IDE, that
> builds through build.exe in the good old fashioned way. So, what do you
> know, we give you a choice !
>
Gosh! That’s good news. Thank whoever did that for me, will ya?
(note that I never said DriverWorks did not build drivers properly… just
that using the wrong TOOLS (and settings) results in drivers being built
improperly.)
Now EVERYbody’s happy. Almost.
Now, please, just make SRC2DSP a tools that can ONLY be used to import a
project to DriverWorks. And not make it available to devs in the general
developer community who (a) might not own DriverWorks, and (b) might not
understand the consequences of the implicit they’re making by not using the
correct tools to build their drivers.
Please?
Anybody who’s smart enough to elect to use the IDE over BUILD (on their own,
outside of DriverWorks) should be smart enough to be able to convert their
sources file and the appropriate compiler and linker flags to a VS project.
This is still NOT a good idea, in any way, but at least they’re making a
conscious decision. So, when the next rev of the DDK is released, and it
contains a new compiler or a new set of flags, and they lose out or their
driver is incompatible in some weird way… they have nobody to blame but
themselves.
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.