Using the Visual Studio 6.0 Driver Build Environment

Ive already borrowed so much information from CodeGuru that Ive started getting frustrated that I haven't contributed anything myself to the site. Therefore, I respectfully offer this articles to my fellow programmers.

Some time ago, I had to write an NT 4.0 device driver. Since I was already used to the comfort of Visual Studio 6, it was hard to me to fall back to the free build and checked build environments, provided by the DDK. Especially I missed the browser possibilities that Visual Studio provides.

So, I started around digging into the DDK build environment to find out how it works, and if I could extend the environment to be usable within the Visual Studio. My primary goal was to keep the existing environment intact, and furthermore, I want to use this environment within VS 6.

The solution was simpler than I expected. I only need to set up some additional files.

_build.bat

. This *.bat is directly called by VS 6 and has the same command parameters as the DDK setenv.bat. This *.bat will clean up some existing files ( i.e. build.dat which I do wish to rebuild every time ), saves the actual directory ( see PrCHDIR ) and calls the original setenv.bat from the DDK. The _build.bat calls bscmake.exe at the end. This enables me to browse to the source code afterwards. The _build.bat is not project-depended.

PrCDIR.exe

On starting setenv.bat, one is move into the DDK root directory. And this not so good if you want to automate the environment. The small PrCHDIR program prints the actual directory and drive letter. The _build.bat catches it output and stores it into a @temp.bat. Once the setenv.bat has been called, the @temp.bat puts you back into your proper build directory.

I386mk.inc

The DDK build environment use this file which resides in the %DDKROOT%\Inc directory. If you copy this file into your proper build directory, the Build will use this file instead. I extended this file with following lines
!IF "$(ASM_LST)"=="YES" 
DBGFLAGS=$(DBGFLAGS) /FAcs 
/Fa$(TARGETPATH)\$(TARGET_DIRECTORY)\$(TARGETNAME).asm
!ENDIF

!IF "$(GEN_SBR)"=="YES" 
DBGFLAGS=$(DBGFLAGS) /FR$(TARGETPATH)\$(TARGET_DIRECTORY)\$(TARGETNAME).sbr
!END

When I define now ASM_LST=YES and GEN_SBR=YES into the sources file, I get my *.asm and *.sbr. The *.sbr is needed by bscmake.exe.

BASEDIR

The BASEDIR is a define internally generated during the build. This define is not available upon start of _build.bat. To make the _build.bat somewhat universal, I defined the BASEDIR within the NT 4.0 environment and set it equal to the DDKROOT.

Some restrictions: the _build.bat expects that the generated files are stored into sub directories of the actual build directory: the sources should contain TARGETPATH=. instead of TARGETPATH=$(BASEDIR)\lib

See the downloadable file more details. It contains an example of this build environment for the KBDCLASS driver provided within the DDK and the PrCHDIR.exe tool plus source code.

Downloads

Download demo project - 224 Kb


Comments

  • using ddk

    Posted by athree on 11/22/2006 12:33pm

    how ddk can be used to develop kernel device driver

    Reply
  • It's not interesting

    Posted by DmitryShm on 08/15/2005 09:57am

    That's not interesting to me because I can read compiler logs. Lots of information is there. Full command lines and others. So I can easily read this info and modify my Studio Compiler and Linker options.

    Reply
  • auto complete

    Posted by Legacy on 07/08/2003 12:00am

    Originally posted by: eli

    its working fine but autocomplete isnt working for ddk functions and data structures
    is there something i can do
    thanks ahead

    Reply
  • Build support for DDK's and Samples using Visual Studio 6.0 /.NET

    Posted by Legacy on 06/19/2003 12:00am

    Originally posted by: Ghijselinck Christiaan


    People who like to be supported to (re)build other DDK samples ( all versions ) or their own drivers using Visual Studio 6.0/.NET , may send me their requests.

    • setup file

      Posted by keshu82_sh on 07/27/2005 07:10am

      hi, can u tell me how i make a setup file for INF file(i mean setup.exe). keshu

      Reply
    Reply
  • The link to the Keyboard sample [ KbdClass_demo.zip ] has moved

    Posted by Legacy on 10/01/2002 12:00am

    Originally posted by: Christiaan Ghijselinck

    The link from the Update to the keyboard sample "KbdClass_demo.zip" will no longer been valid. People who want to download this sample, will find it at to http://members.fortunecity.com/qualitysoftware/News.htm .
    You may also take a look at www.qualitysoftware.tk for more samples that use the _build.bat environment, even for XP and using Visual Studio.NET

    Reply
  • Thank you! Is this applied a same rule for WDM driver?

    Posted by Legacy on 09/06/2002 12:00am

    Originally posted by: minja

    This environment make me easy to approach driver development.!! Thank you.

    And I have a Question about an environment of WDM driver develping.
    If there is any difference , Please leave the way to build WDM driver like this.

    Forgive my poor english, and Thank you.

    Reply
  • Adding "Build Date"

    Posted by Legacy on 10/31/2001 12:00am

    Originally posted by: Christiaan Ghijselinck

    Although, it seems to be that "version planning" becomes regularized, I still struggle with the rules to apply. Is it sheme :

    "xx.xx.xx.xx" or "xx,xx,xx,xx" or "x.xx.xxx" or "x.xx.xxxx.xxxx" or .... ?

    Who will explain how to manage the numbers anyway.

    Thus, instead of inventing another new scheme, I will wait for this "rules". However, what if I want to manage my own distributions and builds, and at least as uncomplicated as possible? And what is more reliable and simplier than beeing able to display the exact build date in the "Version Information" of your executable or driver ?

    Putting this information into your generated file is also a matter of a few quick and simple steps :

    1.
    The "Build Date" string must be provided within your resource file. When building device drivers, the resources are taken from the "common.ver" which resides in the %DDKROOT%\Inc directory. If you copy however this file into your own project directory, you may change it according your own needs without damaging the original.

    I added

    VALUE "Build Date", VER_BUILDDATE_STR

    in the "StringFileInfo" block.

    2.
    The VER_BUILDDATE_STR must now been resolved somewhere before the resource file gets compiled. In case of driver builds, this can easely be done by means of extending the "C_DEFINES" i.e. adding -DVER_BUILDDATE_STR="""%DATETIME%"""

    3.
    The last step is to resolve the %DATETIME%. So, I used the same simple way as I used with the "PrCHDIR.exe". A small "DATETIME.exe" prints out the text : set DATETIME="Wday Mon dd hh:mm:ss yyyy". This text is catched once again in @temp.bat. The @temp.bat is immediately executed afterwards and deleted.


    Those who are interested may download a new version of the sample Keyboard Driver build with the adapted _build.bat :

    http://users.skynet.be/sky75490/KbdClass_demo.zip

    The "common.ver" and DATETIME.exe project is included.

    Reply
  • Build Environment for W2000

    Posted by Legacy on 09/24/2001 12:00am

    Originally posted by: Christiaan Ghijselinck


    You can download a Windows 2000 dedicated build environment using Visual Studio 6.0 at :

    http://users.skynet.be/sky75490/Serial2000_demo.ZIP


    There are fundamentally no changes with the latest version I provided for WinNT 4.0. Since I wanted to be able to install and run the environment for NT4.0 and Win2000 on the same computer, I had to declare a new system wide define :

    "set W2DDK=x:\ddkroot"

    The "x:\ddkroot" is the name of the directory where you installed the Win2000 DDK. To be sure not to disturb my existing NT4.0 environment, I installed the Win2000 DDK on another machine and copied the complete directory afterwards to my own development system, not overwriting the existing NT4.0 DDK :

    NT4.0 build directory = F:\DDK
    W2000 build directory = F:\W2DDK

    If you do so, you may however NOT call the "setenv.bat" out of the win2000 \bin directory, since both NT40 and Win2000 DDK's use the same "BASEDIR" system define !

    I solved this by adding "set BASEDIR=%W2DDK%" in _build.bat before the "setenv.bat" is called.

    When both DDK environments will not be installed on the same machine, you don't have to add the W2DDK system wide define. Of course, you have then to delete the
    "set BASEDIR=%W2DDK% out of the _build.bat too...

    Take a look also at the changes made in "i386mk.inc" and "sources" by comparing them to the original Win2000 versions.

    Note that I adapted the "setenv.bat" on two different places :

    1.
    The calls to "vcvars32.bat" and "ddkvars.bat" are shortend.
    This may not be necessary, calling these batch files just caused myself some trouble while older versions of include files within my personal build environment.

    2.
    The "set Path=%BASEDIR%\bin;%path%" is changed into "set path=%path%;%BASEDIR%\bin".
    It seems to be that "link.exe" provided with the DDK is an older version than the version provided VS6.0 Service Pack 5. The older version crashed every time with "access violation" on my system.

    Other changes in _build.bat are minor. Just make a file-compare with the latest NT4.0 version to see the differences.


    Reply
  • BUILD.EXE & #pragma message (.....)

    Posted by Legacy on 09/03/2001 12:00am

    Originally posted by: Christiaan Ghijselinck


    It seems to be that "build.exe" parsers beautyfully all error messages and warnings coming from Cl.EXE with except of ...

    -- #pragma message --

    This means that if you want to display a reminder text during compilation from within your source that should appear at the STDOUT during the BUILD, and you took too much well known drugs, your ' #pragma message ' will remain in your source forever...

    But, BUILD knows how to handle "warnings" , thus ...

    ... define your own ' #pragma TODO '

    /* --- define this where you need it --- */
    #ifndef _TODO
    #define _TODO
    #define __LINE ( __LINE__ )
    #define __GETLINE(x) "(" #x ")"
    #define GETLINE __GETLINE __LINE
    #define TODO(y) message ( __FILE__ GETLINE " : warning ! " #y " " )
    #endif
    /* --- end of definitions --- ( ... struggling around with __LINE__ wasn't that easy ) */

    ... and if you want to insert a reminder, write something like :


    #pragma TODO ( ... do BSOD's still appear in XP ? )

    Reply
  • Update

    Posted by Legacy on 08/27/2001 12:00am

    Originally posted by: Christiaan Ghijselinck


    The posted version has some constraints that can however be solved easely. I had overseen that the "I386mk.inc" does already contain statements to generate a *.bsc file. Furthermore, my version works only fine if you have solely one C-file within your project. The same remark applies to the generation of the *asm file. Both issues are solved. I added furthermore some support for rebuilding message files. The _build.bat is also made "project independend".

    For those who are still interested, an upgrade of the zip package can be downloaded from my personal webspace
    ( case sensitive ! ) :

    http://users.skynet.be/sky75490/KbdClass_demo.zip

    and please make a file compare with the old version to look for the changes.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • The operational costs of managing an x86 base are taxing IT budgets, making it difficult to fund and staff new initiatives. Today's IT organization must seek efficiencies in its operations and shift to a more agile infrastructure that's flexible enough to adapt to future changes in the business. Read this Q & A session with Jed Scaramella, research manager for IDC's Enterprise Platforms and Data Center Trends, to learn how the integrated nature of the blade platform delivers critically needed efficiencies …

  • The rapid evolution of enterprise storage technologies, combined with external forces, like the explosion of big data, can cause Linux® and server administrators to play catch-up when it comes to storage. Running a bunch of monolithic storage devices and proprietary, disconnected technologies forces administrators to spend valuable time creating and managing complex solutions. To reduce complexity and enable rapid deployment of new technologies and applications, server administrators need a single open …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds