Re: Batch file for Visual Studio build, was Why not u se BUILD [was Re: Errors while building sa

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] 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%;%
INCLUDE%
SET LIB=%SDK_LIB_DEST%%CPU%;
goto launch

:setenvxp
SET
INCLUDE=%CRT_INC_PATH%;%SDK_INC_PATH%;%DDK_INC_PATH%;%WDM_INC_PATH%;%IFS
KIT_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]
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…
>
> 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%%