Porting usb device driver to Vista 64

NTDEV
1

Hi,

Currently i am trying to port an existing USB device driver to vista 64 bit . problem is i have not developed the source code and i am new to device drivers. So any suggestions you can give me is most welcome.

The device driver’s source is in cpp and build tool used earlier is VC 6 and NTDDK (all i had to do was to open the project in VC and build the sys file). The existing driver works for WIN 98/2k/xp and vista 32.

Here is what i have done so far.

  1. i have installed WDK 6001 and created the “source” file to build the source code. (I copied the preprocessor definitions from the VC6 project settings )

  2. For testing i used the WDK XP free build environment to successfully build the sys files ( there are two).

  3. Here is the problem the built drivers are almost half the size of the original drivers and on installing i get a “code 39” error.

  4. I then tried to use WDk with VC 6(instead of NTDDK) and changed the environment variables but on building VC throws an error “fatal error C1189: #error : Compiler version not supported by Windows DDK”

Can anyone please suggest me how to proceed further, cause I am running out of ideas.

Thanks in Advance
Raghu

2

Let me go through your existing USB device driver source code. Give me
a link to your source.

On Nov 16, 2007 3:50 PM, wrote:
> Hi,
>
> Currently i am trying to port an existing USB device driver to vista 64 bit . problem is i have not developed the source code and i am new to device drivers. So any suggestions you can give me is most welcome.
>
> The device driver’s source is in cpp and build tool used earlier is VC 6 and NTDDK (all i had to do was to open the project in VC and build the sys file). The existing driver works for WIN 98/2k/xp and vista 32.
>
> Here is what i have done so far.
>
> 1) i have installed WDK 6001 and created the “source” file to build the source code. (I copied the preprocessor definitions from the VC6 project settings )
>
> 2) For testing i used the WDK XP free build environment to successfully build the sys files ( there are two).
>
> 3) Here is the problem the built drivers are almost half the size of the original drivers and on installing i get a “code 39” error.
>
> 4) I then tried to use WDk with VC 6(instead of NTDDK) and changed the environment variables but on building VC throws an error “fatal error C1189: #error : Compiler version not supported by Windows DDK”
>
> Can anyone please suggest me how to proceed further, cause I am running out of ideas.
>
> Thanks in Advance
> Raghu
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Barun Kumar Parichha,
Research Scholar,
Dept of Computer Science & Engg.
I.I.T. Madras
Chennai - 36

3

On Nov 16, 2007 2:50 PM, wrote:

> Hi,
>
> Currently i am trying to port an existing USB device driver to vista 64
> bit . problem is i have not developed the source code and i am new to device
> drivers. So any suggestions you can give me is most welcome.

I had done the same task few months back. I was not also knowing anything
into the source code. What I did was I used 'PREFast utility available in
this location: WinDDK\6000\tools\pfd\bin\bin\amd64\PREFast.exe

Then I run PREFast over the source code and it generated some XML files,
stating changes to be done into the source code to port the source under 64
Bit environment. Then I updated source as per directions given by XML file
and then I was able to build the drivers on 64 bit environment.

>
>
> The device driver’s source is in cpp and build tool used earlier is VC 6
> and NTDDK (all i had to do was to open the project in VC and build the sys
> file). The existing driver works for WIN 98/2k/xp and vista 32.

>
> Here is what i have done so far.
>
> 1) i have installed WDK 6001 and created the “source” file to build the
> source code. (I copied the preprocessor definitions from the VC6 project
> settings )
>
> 2) For testing i used the WDK XP free build environment to successfully
> build the sys files ( there are two).
>
> 3) Here is the problem the built drivers are almost half the size of the
> original drivers and on installing i get a “code 39” error.
>
> 4) I then tried to use WDk with VC 6(instead of NTDDK) and changed the
> environment variables but on building VC throws an error “fatal error C1189:
> #error : Compiler version not supported by Windows DDK”

With above steps, what exactly you want to achieve? Do you want to make sure
that source what is given is building properly? <br>
Yogi

>
>
> Can anyone please suggest me how to proceed further, cause I am running
> out of ideas.
>
> Thanks in Advance
> Raghu
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

I would suggest that you first get your driver to compile and work for x32 using sources and build.exe. After that is done, port to 64 bit. WHDC contains a lot of information on helping you port to 64 bits, see http://www.microsoft.com/whdc/driver/64bitguide.mspx

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@zilog.com
Sent: Thursday, November 15, 2007 9:51 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Porting usb device driver to Vista 64

Hi,

Currently i am trying to port an existing USB device driver to vista 64 bit . problem is i have not developed the source code and i am new to device drivers. So any suggestions you can give me is most welcome.

The device driver’s source is in cpp and build tool used earlier is VC 6 and NTDDK (all i had to do was to open the project in VC and build the sys file). The existing driver works for WIN 98/2k/xp and vista 32.

Here is what i have done so far.

  1. i have installed WDK 6001 and created the “source” file to build the source code. (I copied the preprocessor definitions from the VC6 project settings )

  2. For testing i used the WDK XP free build environment to successfully build the sys files ( there are two).

  3. Here is the problem the built drivers are almost half the size of the original drivers and on installing i get a “code 39” error.

  4. I then tried to use WDk with VC 6(instead of NTDDK) and changed the environment variables but on building VC throws an error “fatal error C1189: #error : Compiler version not supported by Windows DDK”

Can anyone please suggest me how to proceed further, cause I am running out of ideas.

Thanks in Advance
Raghu

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Before you do anything else, download the Vista RTM WDK
(connect.microsoft.com or msdn.microsoft.com) and use that instead of
the 6001 WDK. The later is still beta, and it currently produces kmdf
drivers that will not install on downlevel systems (Vista and anything
that came before it).

Are you using DDKBuild inside of VC? If not, then it sounds like you
have a non-standard build system for the original driver. This makes it
very difficult to say anything about it. It sounds like you’re driver
is corrupt, but we’ll need to see the source code and sources file to
see what’s going on.

To get started, please post your ‘sources’ file, the names of all your
source files, and the contents of the file that contains ‘DriverEntry.’

Good luck,

mm

xxxxx@zilog.com wrote:

Hi,

Currently i am trying to port an existing USB device driver to vista 64 bit . problem is i have not developed the source code and i am new to device drivers.

So any suggestions you can give me is most welcome.

The device driver’s source is in cpp and build tool used earlier is VC 6 and NTDDK (all i had to do was to open the project in VC and build the sys file).

The existing driver works for WIN 98/2k/xp and vista 32.

Here is what i have done so far.

  1. i have installed WDK 6001 and created the “source” file to build the source code. (I copied the preprocessor definitions from the VC6 project settings )

  2. For testing i used the WDK XP free build environment to successfully build the sys files ( there are two).

  3. Here is the problem the built drivers are almost half the size of the original drivers and on installing i get a “code 39” error.

  4. I then tried to use WDk with VC 6(instead of NTDDK) and changed the environment variables but on building VC throws an error "fatal error C1189:

#error : Compiler version not supported by Windows DDK"

Can anyone please suggest me how to proceed further, cause I am running out of ideas.

Thanks in Advance
Raghu

6

Thanks for the reply guys.i have posted the source files at http://rapidshare.com/files/70050902/Netchip.zip.html

i have used this folder to build in the XP free build env.
Please excuse me this once cause i forgot to delete the temp files in it.

yogesh,
yes, i was trying to make sure the source files were building for X86.
And I will definetly try with prefast next.

Thanks
Raghu

7

For Vista 64, all kernel mode modules must be digitally signed by the
company certificate. This is checked on load.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi,
>
> Currently i am trying to port an existing USB device driver to vista 64 bit .
problem is i have not developed the source code and i am new to device drivers.
So any suggestions you can give me is most welcome.
>
> The device driver’s source is in cpp and build tool used earlier is VC 6 and
NTDDK (all i had to do was to open the project in VC and build the sys file).
The existing driver works for WIN 98/2k/xp and vista 32.
>
> Here is what i have done so far.
>
> 1) i have installed WDK 6001 and created the “source” file to build the
source code. (I copied the preprocessor definitions from the VC6 project
settings )
>
> 2) For testing i used the WDK XP free build environment to successfully build
the sys files ( there are two).
>
> 3) Here is the problem the built drivers are almost half the size of the
original drivers and on installing i get a “code 39” error.
>
> 4) I then tried to use WDk with VC 6(instead of NTDDK) and changed the
environment variables but on building VC throws an error “fatal error C1189:
#error : Compiler version not supported by Windows DDK”
>
> Can anyone please suggest me how to proceed further, cause I am running out
of ideas.
>
> Thanks in Advance
> Raghu
>

8

I would get rid of VC6 and use either the DDK compiler or the compiler that
comes with VS2003, VS2005 or VS2008. My driver, for example, builds and
works fine with either of those. In fact, I prefer to use standard MSVC
compilers, because it’s a royal pain to switch environments when I have to
build a test app - the DDK compiler doesn’t like full-fledged C++ apps very
much! Also, this allows me to have an MSVC solution that has multiple
projects, some for kernel-side code and some for user-side code: I have the
option of batch building them all by capitalizing on the “dependencies”
ability of the IDE, or I can build them separate when I need it. To add to
the heresy, we have a few Python scripts that checkout and build the whole
nine yards, drivers and apps, 32 and 64 bits, debug and release, every
night, and they invoke devenv.exe to build the driver and its associated
applications.

You can call setenv.bat to setup your environment and then call build.exe,
for example, from a buildmydriver.bat file tied up to the build toolbar, or
if you’re more adventurous, you can invoke setenv.bat as a pre-build step
and use the standard IDE build toolbar.

And if you’re really adventurous, you can package the whole thing inside an
MSVC addin. I didn’t do that yet, but I’m seriously considering it.

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, November 16, 2007 12:50 AM
Subject: [ntdev] Porting usb device driver to Vista 64

> Hi,
>
> Currently i am trying to port an existing USB device driver to vista 64
> bit . problem is i have not developed the source code and i am new to
> device drivers. So any suggestions you can give me is most welcome.
>
> The device driver’s source is in cpp and build tool used earlier is VC 6
> and NTDDK (all i had to do was to open the project in VC and build the sys
> file). The existing driver works for WIN 98/2k/xp and vista 32.
>
> Here is what i have done so far.
>
> 1) i have installed WDK 6001 and created the “source” file to build the
> source code. (I copied the preprocessor definitions from the VC6 project
> settings )
>
> 2) For testing i used the WDK XP free build environment to successfully
> build the sys files ( there are two).
>
> 3) Here is the problem the built drivers are almost half the size of the
> original drivers and on installing i get a “code 39” error.
>
> 4) I then tried to use WDk with VC 6(instead of NTDDK) and changed the
> environment variables but on building VC throws an error “fatal error
> C1189: #error : Compiler version not supported by Windows DDK”
>
> Can anyone please suggest me how to proceed further, cause I am running
> out of ideas.
>
> Thanks in Advance
> Raghu
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

9

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, November 17, 2007 4:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Porting usb device driver to Vista 64

I would get rid of VC6 and use either the DDK compiler or the compiler that
comes with VS2003, VS2005 or VS2008.

Great. We didn’t have compilers flamewar here for some time :slight_smile:

My driver, for example, builds and
works fine with either of those. In fact, I prefer to use standard MSVC
compilers, because it’s a royal pain to switch environments when I have to
build a test app - the DDK compiler doesn’t like full-fledged C++ apps very
much!

It has nothing to do with compiler but with the DDK environment. Yes, it’d be nice if it is improved.

Also, this allows me to have an MSVC solution that has multiple
projects, some for kernel-side code and some for user-side code: I have the
option of batch building them all by capitalizing on the “dependencies”
ability of the IDE, or I can build them separate when I need it.

Congratulations! You reinvented build.exe inside this crazy environment :wink: Next time you can do the same using Java if you want something even more crappy :wink:

To add to
the heresy, we have a few Python scripts that checkout and build the whole
nine yards, drivers and apps, 32 and 64 bits, debug and release, every
night,

This isn’t heresy, this is very reasonable approach. In the long term and from some company size the only maintainable one. We don’t use Python but bash + make for the same thing and I can’t imagine to work without it.

and they invoke devenv.exe to build the driver and its associated
applications.

We started with the same years before because it was the easiest way how to convert existing VS projects under the buildengine. Then we converted almost all project to use our scripts natively (scripts use command line compilers for many platforms). Today I said last two people using VS to convert their projects or they’re on their own.

Reason? One for many: it is necessary to have an easy way how to set standard project settings and variants at one place. With VS projects it is impossible and they’re unmaintainable. It can be good for one-man-company who controls everything but not for more teams which have to cooperate.

You can call setenv.bat to setup your environment and then call build.exe,
for example, from a buildmydriver.bat file tied up to the build toolbar, or
if you’re more adventurous, you can invoke setenv.bat as a pre-build step
and use the standard IDE build toolbar.

And if you’re really adventurous, you can package the whole thing inside an
MSVC addin. I didn’t do that yet, but I’m seriously considering it.

Alberto, OP needs to create standard driver build at first. Standard way using WDK and build.exe. Once his driver is buildable from command line, he can start play with integration to a preferred IDE. Not start with it. It seems he is far from it just now and the reason is somebody before was really adventurous and created VS project :wink:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

10

Hi, Michal,

It actually has to do with the compiler,not with the build environment. Try
this: put a line pointing to your DDK binary directory right on top of your
MSVC 2005 C++ Executable directory list. Now try to compile something
complex, such as a C++ application that uses templates. The compiler’s going
to issue error messages on perfectly acceptable code.

As for creating a “standard driver” first, I disagree. I find the build.exe
method byzantine, and in this day and age it is way easier for a beginner to
take a standard MSVC environment and learn to use it than to master the ins
and outs of a cmd box. I also believe that if someone doesn’t know how to
use an IDE such as VS2005 to build and run code, he or she should not try to
write drivers; a driver writer should be able to move up and down the
kernel-user line with ease. I believe that the best approach to start
someone in driver development is to wipe out the cmd box from the system
altogether, and force the newbie to become GUI-oriented. Cmd boxes are,
well, so twentieth century. :slight_smile:

Alberto.

----- Original Message -----
From: “Michal Vodicka”
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 17, 2007 12:05 AM
Subject: RE: [ntdev] Porting usb device driver to Vista 64

> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
> Reply To: Windows System Software Devs Interest List
> Sent: Saturday, November 17, 2007 4:21 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>
> I would get rid of VC6 and use either the DDK compiler or the compiler
> that
> comes with VS2003, VS2005 or VS2008.
>
Great. We didn’t have compilers flamewar here for some time :slight_smile:

> My driver, for example, builds and
> works fine with either of those. In fact, I prefer to use standard MSVC
> compilers, because it’s a royal pain to switch environments when I have to
> build a test app - the DDK compiler doesn’t like full-fledged C++ apps
> very
> much!
>
It has nothing to do with compiler but with the DDK environment. Yes, it’d
be nice if it is improved.

> Also, this allows me to have an MSVC solution that has multiple
> projects, some for kernel-side code and some for user-side code: I have
> the
> option of batch building them all by capitalizing on the “dependencies”
> ability of the IDE, or I can build them separate when I need it.
>
Congratulations! You reinvented build.exe inside this crazy environment :wink:
Next time you can do the same using Java if you want something even more
crappy :wink:

> To add to
> the heresy, we have a few Python scripts that checkout and build the whole
> nine yards, drivers and apps, 32 and 64 bits, debug and release, every
> night,
>
This isn’t heresy, this is very reasonable approach. In the long term and
from some company size the only maintainable one. We don’t use Python but
bash + make for the same thing and I can’t imagine to work without it.

> and they invoke devenv.exe to build the driver and its associated
> applications.
>
We started with the same years before because it was the easiest way how to
convert existing VS projects under the buildengine. Then we converted almost
all project to use our scripts natively (scripts use command line compilers
for many platforms). Today I said last two people using VS to convert their
projects or they’re on their own.

Reason? One for many: it is necessary to have an easy way how to set
standard project settings and variants at one place. With VS projects it is
impossible and they’re unmaintainable. It can be good for one-man-company
who controls everything but not for more teams which have to cooperate.

> You can call setenv.bat to setup your environment and then call build.exe,
> for example, from a buildmydriver.bat file tied up to the build toolbar,
> or
> if you’re more adventurous, you can invoke setenv.bat as a pre-build step
> and use the standard IDE build toolbar.
>
> And if you’re really adventurous, you can package the whole thing inside
> an
> MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>
Alberto, OP needs to create standard driver build at first. Standard way
using WDK and build.exe. Once his driver is buildable from command line, he
can start play with integration to a preferred IDE. Not start with it. It
seems he is far from it just now and the reason is somebody before was
really adventurous and created VS project :wink:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

11

Yep, this is a good way to start the upcoming holidays :-). We really did
not have a deep discussion about anything this year !!!. It is mostly
robotics type Q/A :slight_smile:

I always take the easiest ( or apparently so ) path to build under ddk. But
I’ve worked with quite a few places where MSVC ide is used for all the
builds as you mentioned. But whenever I see something like this, first I try
to build under ddk for sanity check. “My idea is that, how can I fall back
to base line in case there is some problem”. Yes there are schools of
thought that would say RTFM of the IDE env. or ddk build env., then fix it.
But it could very well be long process. At any rate, the build env. was not
much of a problem. And it has its use… Also an in-between step is to use
the ddkbuild.bat.

Having bunch of scripts to drive build is really for build engineers!. But
when one has to wear many hats, scriptography becomes cryptograpy and when
handed over to someone new the chances are that there is a sudden loss of
gravitaional power!!!

For IDE I use source insight, to see who calls who, click to jump back and
forth. MSVC 2005 might have this feature, but I’ve been using source insight
for quite sometime.

-pro

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Friday, November 16, 2007 7:21 PM
Subject: Re: [ntdev] Porting usb device driver to Vista 64

>I would get rid of VC6 and use either the DDK compiler or the compiler that
>comes with VS2003, VS2005 or VS2008. My driver, for example, builds and
>works fine with either of those. In fact, I prefer to use standard MSVC
>compilers, because it’s a royal pain to switch environments when I have to
>build a test app - the DDK compiler doesn’t like full-fledged C++ apps very
>much! Also, this allows me to have an MSVC solution that has multiple
>projects, some for kernel-side code and some for user-side code: I have the
>option of batch building them all by capitalizing on the “dependencies”
>ability of the IDE, or I can build them separate when I need it. To add to
>the heresy, we have a few Python scripts that checkout and build the whole
>nine yards, drivers and apps, 32 and 64 bits, debug and release, every
>night, and they invoke devenv.exe to build the driver and its associated
>applications.
>
> You can call setenv.bat to setup your environment and then call build.exe,
> for example, from a buildmydriver.bat file tied up to the build toolbar,
> or if you’re more adventurous, you can invoke setenv.bat as a pre-build
> step and use the standard IDE build toolbar.
>
> And if you’re really adventurous, you can package the whole thing inside
> an MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>
>
> Alberto.
>
>
>
> ----- Original Message -----
> From:
> To: “Windows System Software Devs Interest List”
> Sent: Friday, November 16, 2007 12:50 AM
> Subject: [ntdev] Porting usb device driver to Vista 64
>
>
>> Hi,
>>
>> Currently i am trying to port an existing USB device driver to vista 64
>> bit . problem is i have not developed the source code and i am new to
>> device drivers. So any suggestions you can give me is most welcome.
>>
>> The device driver’s source is in cpp and build tool used earlier is VC 6
>> and NTDDK (all i had to do was to open the project in VC and build the
>> sys file). The existing driver works for WIN 98/2k/xp and vista 32.
>>
>> Here is what i have done so far.
>>
>> 1) i have installed WDK 6001 and created the “source” file to build the
>> source code. (I copied the preprocessor definitions from the VC6 project
>> settings )
>>
>> 2) For testing i used the WDK XP free build environment to successfully
>> build the sys files ( there are two).
>>
>> 3) Here is the problem the built drivers are almost half the size of the
>> original drivers and on installing i get a “code 39” error.
>>
>> 4) I then tried to use WDk with VC 6(instead of NTDDK) and changed the
>> environment variables but on building VC throws an error “fatal error
>> C1189: #error : Compiler version not supported by Windows DDK”
>>
>> Can anyone please suggest me how to proceed further, cause I am running
>> out of ideas.
>>
>> Thanks in Advance
>> Raghu
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

12

Cmd boxes are … this is what I realized about 4 years ago, and
mentioned it here in another discussion.

It is really a matter of taste, comfortness, already an expert in some area
etc. etc. For newbie, it makes sense to use the IDE first.

One thing I found though is when a newbie starts on kernel mode they hardly
have any clue, and more often than not they are more careful in crafting
code than those who are heavily experienced in user mode, and come play with
kernel mode. Some of the nice thing I’ve seen ( and I hate most are )

  • No comments at all
  • Variable names does not make sense
  • c files and under #include
  • massive use of macros ( instead of inline )
  • functions are more than 100 lines long
  • global variables are their’s parental property
  • same function statically defined in more than one files
  • less use of header files, instead put all these definition/declarations
    inside c files
  • and many more …

Since some newbie would also read this, I’ve a question to ask here —

What is a good program?

My answer is "If most of the components are easily replaceable " (Pls give
it a thought)

Happy thanksgiving!

-pro

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 17, 2007 5:11 AM
Subject: Re: [ntdev] Porting usb device driver to Vista 64

> Hi, Michal,
>
> It actually has to do with the compiler,not with the build environment.
> Try this: put a line pointing to your DDK binary directory right on top of
> your MSVC 2005 C++ Executable directory list. Now try to compile something
> complex, such as a C++ application that uses templates. The compiler’s
> going to issue error messages on perfectly acceptable code.
>
> As for creating a “standard driver” first, I disagree. I find the
> build.exe method byzantine, and in this day and age it is way easier for a
> beginner to take a standard MSVC environment and learn to use it than to
> master the ins and outs of a cmd box. I also believe that if someone
> doesn’t know how to use an IDE such as VS2005 to build and run code, he or
> she should not try to write drivers; a driver writer should be able to
> move up and down the kernel-user line with ease. I believe that the best
> approach to start someone in driver development is to wipe out the cmd box
> from the system altogether, and force the newbie to become GUI-oriented.
> Cmd boxes are, well, so twentieth century. :slight_smile:
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Michal Vodicka”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, November 17, 2007 12:05 AM
> Subject: RE: [ntdev] Porting usb device driver to Vista 64
>
>
>> ----------
>> From:
>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Saturday, November 17, 2007 4:21 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>>
>> I would get rid of VC6 and use either the DDK compiler or the compiler
>> that
>> comes with VS2003, VS2005 or VS2008.
>>
> Great. We didn’t have compilers flamewar here for some time :slight_smile:
>
>> My driver, for example, builds and
>> works fine with either of those. In fact, I prefer to use standard MSVC
>> compilers, because it’s a royal pain to switch environments when I have
>> to
>> build a test app - the DDK compiler doesn’t like full-fledged C++ apps
>> very
>> much!
>>
> It has nothing to do with compiler but with the DDK environment. Yes, it’d
> be nice if it is improved.
>
>> Also, this allows me to have an MSVC solution that has multiple
>> projects, some for kernel-side code and some for user-side code: I have
>> the
>> option of batch building them all by capitalizing on the “dependencies”
>> ability of the IDE, or I can build them separate when I need it.
>>
> Congratulations! You reinvented build.exe inside this crazy environment
> :wink: Next time you can do the same using Java if you want something even
> more crappy :wink:
>
>> To add to
>> the heresy, we have a few Python scripts that checkout and build the
>> whole
>> nine yards, drivers and apps, 32 and 64 bits, debug and release, every
>> night,
>>
> This isn’t heresy, this is very reasonable approach. In the long term and
> from some company size the only maintainable one. We don’t use Python but
> bash + make for the same thing and I can’t imagine to work without it.
>
>> and they invoke devenv.exe to build the driver and its associated
>> applications.
>>
> We started with the same years before because it was the easiest way how
> to convert existing VS projects under the buildengine. Then we converted
> almost all project to use our scripts natively (scripts use command line
> compilers for many platforms). Today I said last two people using VS to
> convert their projects or they’re on their own.
>
> Reason? One for many: it is necessary to have an easy way how to set
> standard project settings and variants at one place. With VS projects it
> is impossible and they’re unmaintainable. It can be good for
> one-man-company who controls everything but not for more teams which have
> to cooperate.
>
>> You can call setenv.bat to setup your environment and then call
>> build.exe,
>> for example, from a buildmydriver.bat file tied up to the build toolbar,
>> or
>> if you’re more adventurous, you can invoke setenv.bat as a pre-build step
>> and use the standard IDE build toolbar.
>>
>> And if you’re really adventurous, you can package the whole thing inside
>> an
>> MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>>
> Alberto, OP needs to create standard driver build at first. Standard way
> using WDK and build.exe. Once his driver is buildable from command line,
> he can start play with integration to a preferred IDE. Not start with it.
> It seems he is far from it just now and the reason is somebody before was
> really adventurous and created VS project :wink:
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

13

> altogether, and force the newbie to become GUI-oriented. Cmd boxes are,

well, so twentieth century. :slight_smile:

So are the most OS kernels in popular use.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

14

Alberto:

With regards to the compiler, what version of the WDK/DDK are you using
that causes this problem. This definitely used to be true, is it still,
because I thought the the WDK compilers at least are identical to VS2003.

I, like you, do not like BUILD and do not use it, but I think you’re
giving this guy not particularly good advice. Personally, I think
copying an existing sample/sources is easier than figuring out the build
settings for VC, but that’s not the most important reason. The major
reason is because by not using BUILD, you are almost guaranteeing
yourself that no one on lists like these is going to be able to help
you, and in most cases won’t even be willing to try. Look at this
thread; I haven’t seen word one yet about ‘Porting Usb Device Driver to
Vista x64’ yet. Also, if it applies, this guys drivers will never pass
WHQL. I, like you, am willing to live with all of this, as I deeply
hate build, WHQL isn’t an issue for me, and I would agree with you that
not using BUILD is indeed made out to be the end of world by some, and
is really quite safe and easy, but but I certainly wouldn’t recommend it
to anyone as the way to start.

mm

Alberto Moreira wrote:

Hi, Michal,

It actually has to do with the compiler,not with the build environment.
Try this: put a line pointing to your DDK binary directory right on top
of your MSVC 2005 C++ Executable directory list. Now try to compile
something complex, such as a C++ application that uses templates. The
compiler’s going to issue error messages on perfectly acceptable code.

As for creating a “standard driver” first, I disagree. I find the
build.exe method byzantine, and in this day and age it is way easier for
a beginner to take a standard MSVC environment and learn to use it than
to master the ins and outs of a cmd box. I also believe that if someone
doesn’t know how to use an IDE such as VS2005 to build and run code, he
or she should not try to write drivers; a driver writer should be able
to move up and down the kernel-user line with ease. I believe that the
best approach to start someone in driver development is to wipe out the
cmd box from the system altogether, and force the newbie to become
GUI-oriented. Cmd boxes are, well, so twentieth century. :slight_smile:

Alberto.

----- Original Message ----- From: “Michal Vodicka”

> To: “Windows System Software Devs Interest List”
> Sent: Saturday, November 17, 2007 12:05 AM
> Subject: RE: [ntdev] Porting usb device driver to Vista 64
>
>
>> ----------
>> From:
>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>> on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
>> Reply To: Windows System Software Devs Interest List
>> Sent: Saturday, November 17, 2007 4:21 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>>
>> I would get rid of VC6 and use either the DDK compiler or the compiler
>> that
>> comes with VS2003, VS2005 or VS2008.
>>
> Great. We didn’t have compilers flamewar here for some time :slight_smile:
>
>> My driver, for example, builds and
>> works fine with either of those. In fact, I prefer to use standard MSVC
>> compilers, because it’s a royal pain to switch environments when I
>> have to
>> build a test app - the DDK compiler doesn’t like full-fledged C++ apps
>> very
>> much!
>>
> It has nothing to do with compiler but with the DDK environment. Yes,
> it’d be nice if it is improved.
>
>> Also, this allows me to have an MSVC solution that has multiple
>> projects, some for kernel-side code and some for user-side code: I
>> have the
>> option of batch building them all by capitalizing on the “dependencies”
>> ability of the IDE, or I can build them separate when I need it.
>>
> Congratulations! You reinvented build.exe inside this crazy environment
> :wink: Next time you can do the same using Java if you want something even
> more crappy :wink:
>
>> To add to
>> the heresy, we have a few Python scripts that checkout and build the
>> whole
>> nine yards, drivers and apps, 32 and 64 bits, debug and release, every
>> night,
>>
> This isn’t heresy, this is very reasonable approach. In the long term
> and from some company size the only maintainable one. We don’t use
> Python but bash + make for the same thing and I can’t imagine to work
> without it.
>
>> and they invoke devenv.exe to build the driver and its associated
>> applications.
>>
> We started with the same years before because it was the easiest way how
> to convert existing VS projects under the buildengine. Then we converted
> almost all project to use our scripts natively (scripts use command line
> compilers for many platforms). Today I said last two people using VS to
> convert their projects or they’re on their own.
>
> Reason? One for many: it is necessary to have an easy way how to set
> standard project settings and variants at one place. With VS projects it
> is impossible and they’re unmaintainable. It can be good for
> one-man-company who controls everything but not for more teams which
> have to cooperate.
>
>> You can call setenv.bat to setup your environment and then call
>> build.exe,
>> for example, from a buildmydriver.bat file tied up to the build
>> toolbar, or
>> if you’re more adventurous, you can invoke setenv.bat as a pre-build step
>> and use the standard IDE build toolbar.
>>
>> And if you’re really adventurous, you can package the whole thing
>> inside an
>> MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>>
> Alberto, OP needs to create standard driver build at first. Standard way
> using WDK and build.exe. Once his driver is buildable from command line,
> he can start play with integration to a preferred IDE. Not start with
> it. It seems he is far from it just now and the reason is somebody
> before was really adventurous and created VS project :wink:
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

15

> Reason? One for many: it is necessary to have an easy way how to set

standard project settings and variants at one place. With VS projects it
is impossible and they’re unmaintainable. It can be good for
one-man-company who controls everything but not for more teams which
have to cooperate.

Michal, I couldn’t disagree more at this point. Even with property sheets (.vsprops files) which were introduced with VS 2005 you won’t get a heavenly build environment, but it will allow to have the settings in a central place when working in a team.

// Oliver

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info

16

So, for that matter, are all ‘guis’.

On Nov 17, 2007 10:14 AM, Maxim S. Shatskih wrote:

> > altogether, and force the newbie to become GUI-oriented. Cmd boxes are,
> > well, so twentieth century. :slight_smile:
>
> So are the most OS kernels in popular use.
>
> –
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

17

Martin,

I used the DDK compiler from 3790.1830 for quite a while (a good two years),
and I couldn’t compile serious apps with it. I have now moved up to WDK
6000, and I must admit I didn’t try much app compiling as yet with the
compiler that comes with the WDK. But there’s a fair amount of difference
between the 2003 and the 2005 compilers, we have a slew of app code which
builds ok under 2003 but not under 2005, and we’re slowly converting the
code to iron out the differences.

I have coded my driver for the VS2005 compiler as a target, and after a few
tweaks here and there, I can use either compiler. I even downloaded the
VS2008 beta and made sure my code compiles and runs under it.

Actually, WHQL isn’t an issue to me either. But I do use build.exe, from
inside the IDE. A few batch files wrap my usage of build.exe so that I don’t
have to remember it exists. The IDE is flexible enough that one can use
bog-standard build procedures and yet wrap them within a VS2005 solution!

One last thing, there’s no need to figure out the build settings for VC, all
one has to do is to call setenv.bat with the right parameters prior to
calling build.exe. My VS2005 project properties sheet points to batch files
mydriver_build.bat and mydriver_rebuild.bat, inside which I call setenv with
the right parameters, invoke build.exe at the top level directory, and copy
the resulting driver executable, pdb and map files out to my runtime
directory. It’s actually very simple, even a plain vanilla VS2005 Utility
Project will do!

Alberto.

----- Original Message -----
From: “Martin O’Brien”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 17, 2007 12:49 PM
Subject: Re:[ntdev] Porting usb device driver to Vista 64

> Alberto:
>
> With regards to the compiler, what version of the WDK/DDK are you using
> that causes this problem. This definitely used to be true, is it still,
> because I thought the the WDK compilers at least are identical to VS2003.
>
> I, like you, do not like BUILD and do not use it, but I think you’re
> giving this guy not particularly good advice. Personally, I think copying
> an existing sample/sources is easier than figuring out the build settings
> for VC, but that’s not the most important reason. The major reason is
> because by not using BUILD, you are almost guaranteeing yourself that no
> one on lists like these is going to be able to help you, and in most cases
> won’t even be willing to try. Look at this thread; I haven’t seen word
> one yet about ‘Porting Usb Device Driver to Vista x64’ yet. Also, if it
> applies, this guys drivers will never pass WHQL. I, like you, am willing
> to live with all of this, as I deeply hate build, WHQL isn’t an issue for
> me, and I would agree with you that not using BUILD is indeed made out to
> be the end of world by some, and is really quite safe and easy, but but I
> certainly wouldn’t recommend it to anyone as the way to start.
>
> mm

18

Hi, Pro,

Oh, I hate macros. Actually, you forgot one of my favorites: big data
structures on the stack.

Happy Thanskgiving to you too!

Alberto.

----- Original Message -----
From: “Prokash Sinha”
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 17, 2007 10:01 AM
Subject: Re: [ntdev] Porting usb device driver to Vista 64

> Cmd boxes are … this is what I realized about 4 years ago, and
> mentioned it here in another discussion.
>
> It is really a matter of taste, comfortness, already an expert in some
> area etc. etc. For newbie, it makes sense to use the IDE first.
>
> One thing I found though is when a newbie starts on kernel mode they
> hardly have any clue, and more often than not they are more careful in
> crafting code than those who are heavily experienced in user mode, and
> come play with kernel mode. Some of the nice thing I’ve seen ( and I hate
> most are )
>
> - No comments at all
> - Variable names does not make sense
> - c files and under #include
> - massive use of macros ( instead of inline )
> - functions are more than 100 lines long
> - global variables are their’s parental property
> - same function statically defined in more than one files
> - less use of header files, instead put all these definition/declarations
> inside c files
> - and many more …
>
> Since some newbie would also read this, I’ve a question to ask here —
>
> What is a good program?
>
> My answer is "If most of the components are easily replaceable " (Pls
> give it a thought)
>
> Happy thanksgiving!
>
> -pro
>
> ----- Original Message -----
> From: “Alberto Moreira”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, November 17, 2007 5:11 AM
> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>
>
>> Hi, Michal,
>>
>> It actually has to do with the compiler,not with the build environment.
>> Try this: put a line pointing to your DDK binary directory right on top
>> of your MSVC 2005 C++ Executable directory list. Now try to compile
>> something complex, such as a C++ application that uses templates. The
>> compiler’s going to issue error messages on perfectly acceptable code.
>>
>> As for creating a “standard driver” first, I disagree. I find the
>> build.exe method byzantine, and in this day and age it is way easier for
>> a beginner to take a standard MSVC environment and learn to use it than
>> to master the ins and outs of a cmd box. I also believe that if someone
>> doesn’t know how to use an IDE such as VS2005 to build and run code, he
>> or she should not try to write drivers; a driver writer should be able to
>> move up and down the kernel-user line with ease. I believe that the best
>> approach to start someone in driver development is to wipe out the cmd
>> box from the system altogether, and force the newbie to become
>> GUI-oriented. Cmd boxes are, well, so twentieth century. :slight_smile:
>>
>> Alberto.
>>
>>
>> ----- Original Message -----
>> From: “Michal Vodicka”
>> To: “Windows System Software Devs Interest List”
>> Sent: Saturday, November 17, 2007 12:05 AM
>> Subject: RE: [ntdev] Porting usb device driver to Vista 64
>>
>>
>>> ----------
>>> From:
>>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>>> on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
>>> Reply To: Windows System Software Devs Interest List
>>> Sent: Saturday, November 17, 2007 4:21 AM
>>> To: Windows System Software Devs Interest List
>>> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>>>
>>> I would get rid of VC6 and use either the DDK compiler or the compiler
>>> that
>>> comes with VS2003, VS2005 or VS2008.
>>>
>> Great. We didn’t have compilers flamewar here for some time :slight_smile:
>>
>>> My driver, for example, builds and
>>> works fine with either of those. In fact, I prefer to use standard MSVC
>>> compilers, because it’s a royal pain to switch environments when I have
>>> to
>>> build a test app - the DDK compiler doesn’t like full-fledged C++ apps
>>> very
>>> much!
>>>
>> It has nothing to do with compiler but with the DDK environment. Yes,
>> it’d be nice if it is improved.
>>
>>> Also, this allows me to have an MSVC solution that has multiple
>>> projects, some for kernel-side code and some for user-side code: I have
>>> the
>>> option of batch building them all by capitalizing on the “dependencies”
>>> ability of the IDE, or I can build them separate when I need it.
>>>
>> Congratulations! You reinvented build.exe inside this crazy environment
>> :wink: Next time you can do the same using Java if you want something even
>> more crappy :wink:
>>
>>> To add to
>>> the heresy, we have a few Python scripts that checkout and build the
>>> whole
>>> nine yards, drivers and apps, 32 and 64 bits, debug and release, every
>>> night,
>>>
>> This isn’t heresy, this is very reasonable approach. In the long term and
>> from some company size the only maintainable one. We don’t use Python but
>> bash + make for the same thing and I can’t imagine to work without it.
>>
>>> and they invoke devenv.exe to build the driver and its associated
>>> applications.
>>>
>> We started with the same years before because it was the easiest way how
>> to convert existing VS projects under the buildengine. Then we converted
>> almost all project to use our scripts natively (scripts use command line
>> compilers for many platforms). Today I said last two people using VS to
>> convert their projects or they’re on their own.
>>
>> Reason? One for many: it is necessary to have an easy way how to set
>> standard project settings and variants at one place. With VS projects it
>> is impossible and they’re unmaintainable. It can be good for
>> one-man-company who controls everything but not for more teams which have
>> to cooperate.
>>
>>> You can call setenv.bat to setup your environment and then call
>>> build.exe,
>>> for example, from a buildmydriver.bat file tied up to the build toolbar,
>>> or
>>> if you’re more adventurous, you can invoke setenv.bat as a pre-build
>>> step
>>> and use the standard IDE build toolbar.
>>>
>>> And if you’re really adventurous, you can package the whole thing inside
>>> an
>>> MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>>>
>> Alberto, OP needs to create standard driver build at first. Standard way
>> using WDK and build.exe. Once his driver is buildable from command line,
>> he can start play with integration to a preferred IDE. Not start with it.
>> It seems he is far from it just now and the reason is somebody before was
>> really adventurous and created VS project :wink:
>>
>> Best regards,
>>
>> Michal Vodicka
>> UPEK, Inc.
>> [xxxxx@upek.com, http://www.upek.com]
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

19

Oh, I’ve seen recursion in a file system driver and that too with a bunch of
native and struct variables…

How hard it is to blow up the stack space?

Give me couple grands, i will device test case that would blow the stack at
will or even at random. I could make it even so random that would look like
living in ghost town …

Anyway, I’m letting my branch get pruned now ( not a feasible search branch
for subject matter of this thd :-).

-pro

----- Original Message -----
From: “Alberto Moreira”
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 17, 2007 3:24 AM
Subject: Re: [ntdev] Porting usb device driver to Vista 64

> Hi, Pro,
>
> Oh, I hate macros. Actually, you forgot one of my favorites: big data
> structures on the stack.
>
> Happy Thanskgiving to you too!
>
> Alberto.
>
>
> ----- Original Message -----
> From: “Prokash Sinha”
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, November 17, 2007 10:01 AM
> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>
>
>> Cmd boxes are … this is what I realized about 4 years ago, and
>> mentioned it here in another discussion.
>>
>> It is really a matter of taste, comfortness, already an expert in some
>> area etc. etc. For newbie, it makes sense to use the IDE first.
>>
>> One thing I found though is when a newbie starts on kernel mode they
>> hardly have any clue, and more often than not they are more careful in
>> crafting code than those who are heavily experienced in user mode, and
>> come play with kernel mode. Some of the nice thing I’ve seen ( and I hate
>> most are )
>>
>> - No comments at all
>> - Variable names does not make sense
>> - c files and under #include
>> - massive use of macros ( instead of inline )
>> - functions are more than 100 lines long
>> - global variables are their’s parental property
>> - same function statically defined in more than one files
>> - less use of header files, instead put all these definition/declarations
>> inside c files
>> - and many more …
>>
>> Since some newbie would also read this, I’ve a question to ask here —
>>
>> What is a good program?
>>
>> My answer is "If most of the components are easily replaceable " (Pls
>> give it a thought)
>>
>> Happy thanksgiving!
>>
>> -pro
>>
>> ----- Original Message -----
>> From: “Alberto Moreira”
>> To: “Windows System Software Devs Interest List”
>> Sent: Saturday, November 17, 2007 5:11 AM
>> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>>
>>
>>> Hi, Michal,
>>>
>>> It actually has to do with the compiler,not with the build environment.
>>> Try this: put a line pointing to your DDK binary directory right on top
>>> of your MSVC 2005 C++ Executable directory list. Now try to compile
>>> something complex, such as a C++ application that uses templates. The
>>> compiler’s going to issue error messages on perfectly acceptable code.
>>>
>>> As for creating a “standard driver” first, I disagree. I find the
>>> build.exe method byzantine, and in this day and age it is way easier for
>>> a beginner to take a standard MSVC environment and learn to use it than
>>> to master the ins and outs of a cmd box. I also believe that if someone
>>> doesn’t know how to use an IDE such as VS2005 to build and run code, he
>>> or she should not try to write drivers; a driver writer should be able
>>> to move up and down the kernel-user line with ease. I believe that the
>>> best approach to start someone in driver development is to wipe out the
>>> cmd box from the system altogether, and force the newbie to become
>>> GUI-oriented. Cmd boxes are, well, so twentieth century. :slight_smile:
>>>
>>> Alberto.
>>>
>>>
>>> ----- Original Message -----
>>> From: “Michal Vodicka”
>>> To: “Windows System Software Devs Interest List”
>>> Sent: Saturday, November 17, 2007 12:05 AM
>>> Subject: RE: [ntdev] Porting usb device driver to Vista 64
>>>
>>>
>>>> ----------
>>>> From:
>>>> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>>>> on behalf of Alberto Moreira[SMTP:xxxxx@ieee.org]
>>>> Reply To: Windows System Software Devs Interest List
>>>> Sent: Saturday, November 17, 2007 4:21 AM
>>>> To: Windows System Software Devs Interest List
>>>> Subject: Re: [ntdev] Porting usb device driver to Vista 64
>>>>
>>>> I would get rid of VC6 and use either the DDK compiler or the compiler
>>>> that
>>>> comes with VS2003, VS2005 or VS2008.
>>>>
>>> Great. We didn’t have compilers flamewar here for some time :slight_smile:
>>>
>>>> My driver, for example, builds and
>>>> works fine with either of those. In fact, I prefer to use standard MSVC
>>>> compilers, because it’s a royal pain to switch environments when I have
>>>> to
>>>> build a test app - the DDK compiler doesn’t like full-fledged C++ apps
>>>> very
>>>> much!
>>>>
>>> It has nothing to do with compiler but with the DDK environment. Yes,
>>> it’d be nice if it is improved.
>>>
>>>> Also, this allows me to have an MSVC solution that has multiple
>>>> projects, some for kernel-side code and some for user-side code: I have
>>>> the
>>>> option of batch building them all by capitalizing on the “dependencies”
>>>> ability of the IDE, or I can build them separate when I need it.
>>>>
>>> Congratulations! You reinvented build.exe inside this crazy environment
>>> :wink: Next time you can do the same using Java if you want something even
>>> more crappy :wink:
>>>
>>>> To add to
>>>> the heresy, we have a few Python scripts that checkout and build the
>>>> whole
>>>> nine yards, drivers and apps, 32 and 64 bits, debug and release, every
>>>> night,
>>>>
>>> This isn’t heresy, this is very reasonable approach. In the long term
>>> and from some company size the only maintainable one. We don’t use
>>> Python but bash + make for the same thing and I can’t imagine to work
>>> without it.
>>>
>>>> and they invoke devenv.exe to build the driver and its associated
>>>> applications.
>>>>
>>> We started with the same years before because it was the easiest way how
>>> to convert existing VS projects under the buildengine. Then we converted
>>> almost all project to use our scripts natively (scripts use command line
>>> compilers for many platforms). Today I said last two people using VS to
>>> convert their projects or they’re on their own.
>>>
>>> Reason? One for many: it is necessary to have an easy way how to set
>>> standard project settings and variants at one place. With VS projects it
>>> is impossible and they’re unmaintainable. It can be good for
>>> one-man-company who controls everything but not for more teams which
>>> have to cooperate.
>>>
>>>> You can call setenv.bat to setup your environment and then call
>>>> build.exe,
>>>> for example, from a buildmydriver.bat file tied up to the build
>>>> toolbar, or
>>>> if you’re more adventurous, you can invoke setenv.bat as a pre-build
>>>> step
>>>> and use the standard IDE build toolbar.
>>>>
>>>> And if you’re really adventurous, you can package the whole thing
>>>> inside an
>>>> MSVC addin. I didn’t do that yet, but I’m seriously considering it.
>>>>
>>> Alberto, OP needs to create standard driver build at first. Standard way
>>> using WDK and build.exe. Once his driver is buildable from command line,
>>> he can start play with integration to a preferred IDE. Not start with
>>> it. It seems he is far from it just now and the reason is somebody
>>> before was really adventurous and created VS project :wink:
>>>
>>> Best regards,
>>>
>>> Michal Vodicka
>>> UPEK, Inc.
>>> [xxxxx@upek.com, http://www.upek.com]
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

20

> Oh, I hate macros. Actually, you forgot one of my favorites: big data

structures on the stack.

Hehe, that’s a good one. Actually after a few “incidents” we had to train some other developers whose code is linked to (from a static library) what restrictions apply in kernel mode and which are of concern to them and which to us.

Since then, the quality of the linked-to code has improved a lot and PREfast does its share as well to find “stack-hogs” :wink:

// Oliver

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info