XP DDK Compiling

> ----------

From: xxxxx@nryan.com[SMTP:xxxxx@nryan.com]
Reply To: xxxxx@lists.osr.com
Sent: Friday, May 23, 2003 11:33 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: XP DDK Compiling

  1. Nobody says you can’t use external editors to edit C files included
    in a VisualC project. I know people who do it all the time.

Sure, I also did it when worked on projects other created this way by
others. The problem is you need VC installed and have to call it for build
which is slower than simple makefile or SOURCES. And create projects there,
start it for every project change. No, thanks.

  1. Automated nightly builds are incredibly simple with VS NET .2003’s
    new solution configurations. I build half-a-million lines of source code
    (some as user-mode, some as kernel-mode, some as both) with these three
    commands:

devenv.com /rebuild “Release” client.sln
devenv.com /rebuild “Release 2kDrv” client.sln
devenv.com /rebuild “Release Nt4Drv” client.sln

You can even force VisualC to use your batch file’s environment instead
of its own directory search paths (in the GUI options) with the /useenv
switch.

It was possible also with older versions; we did it during conversion phase
for old projects. My point was different: how to enforce common
configuration for all projects at one place. Editing every project isn’t an
option, at least not professional option.

  1. It is true you CAN build user-mode code with the DDK, but that’s not
    what it was designed for, was it?

We can only guess. There is support for it inside DDK, even MFC apps can be
build this way. Build utility uses nmake which was surely designed for user
mode code, the rest is just makefile.def i.e common configuration.

As Max pointed out, NT is (or at least was) build this way.

All of the samples in the Platform SDK
use the build tools installed with VisualC.

Just because it is for users who use VS. DDK also contains SDK headers
including STL, I use it for all user mode development.

Yes, I agree that building
kernel-mode code with VisualC was not what that was designed for either,
but my point remains that we need ONE development environment for what
is to me an arbitrary distinction between ‘user-mode’ and ‘kernel-mode’
code.

DDK is quite suitable development environment for both. All you need is
headers, libs, compiler, make and build utilities. Everything else is user’s
choice.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

> 2. Automated nightly builds are incredibly simple with VS NET
.2003’s

new solution configurations. I

They were not so complex even with MSVC4, but SOURCES is better in
this particular case. Lesser number of problems.

  1. It is true you CAN build user-mode code with the DDK, but that’s
    not
    what it was designed for, was it? All of the samples in the Platform
    SDK
    use the build tools installed with VisualC.

IIRC SOURCES is used for user-mode code too.
Sometimes it is simpler to type a couple of words in SOURCES, then to
browse the project settings dialog in MSVC with lots of its tabs and
options.

Max

> Max, how do you manage to call APIs exported only by post-NT OS’s
using

a common binary? NT doesn’t support MmGetSystemRoutineAddress.

Getting the kernel image base by ZwQuerySystemInformation, then the
handicrafted GetProcAddress which works with PE header. A screenful of
code.

Max

Another problem with single binary approach is Driver Verifier. For
example
MmGetSystemAddressForMdl / MmMapLockedPages bugchecks on XP with
DriverVerifier. It mandates to use MmGetSystemAddressForMdlSafe /
MmMapLockedPagesSpecifyCache.

-Srin.

-----Original Message-----
From: Nick Ryan [mailto:xxxxx@nryan.com]
Sent: Friday, May 23, 2003 2:42 PM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling

Max, how do you manage to call APIs exported only by post-NT OS’s
using
a common binary? NT doesn’t support MmGetSystemRoutineAddress. I
considered wrapping MmGetSystemRoutineAddress as a call into a
kernel-mode .dll that I would build and install separately, but
decided
it was just easier to split the binary as a whole.

  • Nick Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
> S. Shatskih
> Sent: Friday, May 23, 2003 1:45 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: XP DDK Compiling
>
>
> > 1. Fold the separate (and prehistoric even by UNIX standards) DDK
> > development environment into Visual C .NET. Drivers are no longer
10
> C
> > files and a header. They include multiple external libraries and
> shared
> > code between user-mode and kernel-mode projects. This sort of
thing
> is
> > impossible to do within the limitations of the DDK.
>
> IIRC MS builds the whole core OS tree by BUILD.
> MSVC’s project management has only 1 advantage. It is simpler
> for beginners. Nothing more.
>
> > building a driver binary that works perfectly on everything from
W2K
> SP0
> > to 3790.
>
> I have the binary working from NT4-no-SPs to some Win2003 builds.
>
> Max
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>


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

That’s MmGetSystemRoutineAddress is for; it lets you choose which
version of the API to call at run-time (it’s the KM equivalent to
GetProcAddress).

  • Nick Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@NAI.com
Sent: Saturday, May 24, 2003 8:57 AM
To: NT Developers Interest List
Subject: [ntdev] RE: XP DDK Compiling

Another problem with single binary approach is Driver
Verifier. For example MmGetSystemAddressForMdl /
MmMapLockedPages bugchecks on XP with DriverVerifier. It
mandates to use MmGetSystemAddressForMdlSafe /
MmMapLockedPagesSpecifyCache.

-Srin.

> -----Original Message-----
> From: Nick Ryan [mailto:xxxxx@nryan.com]
> Sent: Friday, May 23, 2003 2:42 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: XP DDK Compiling
>
> Max, how do you manage to call APIs exported only by post-NT OS’s
using
> a common binary? NT doesn’t support MmGetSystemRoutineAddress. I
> considered wrapping MmGetSystemRoutineAddress as a call into a
> kernel-mode .dll that I would build and install separately, but
decided
> it was just easier to split the binary as a whole.
>
> - Nick Ryan
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
> > Shatskih
> > Sent: Friday, May 23, 2003 1:45 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: XP DDK Compiling
> >
> >
> > > 1. Fold the separate (and prehistoric even by UNIX
standards) DDK
> > > development environment into Visual C .NET. Drivers are
no longer
10
> > C
> > > files and a header. They include multiple external libraries and
> > shared
> > > code between user-mode and kernel-mode projects. This sort of
thing
> > is
> > > impossible to do within the limitations of the DDK.
> >
> > IIRC MS builds the whole core OS tree by BUILD.
> > MSVC’s project management has only 1 advantage. It is simpler for
> > beginners. Nothing more.
> >
> > > building a driver binary that works perfectly on everything from
W2K
> > SP0
> > > to 3790.
> >
> > I have the binary working from NT4-no-SPs to some Win2003 builds.
> >
> > Max
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@nryan.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nai.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com


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

xxxxx@NAI.com wrote:>

Another problem with single binary approach is Driver Verifier. For
example
MmGetSystemAddressForMdl / MmMapLockedPages bugchecks on XP with
DriverVerifier. It mandates to use MmGetSystemAddressForMdlSafe /
MmMapLockedPagesSpecifyCache.

In this particular case, there is a documented and WHQL-approved
workaround: set the MDL_MAPPING_CAN_FAIL flag and use the unsafe version
of the macro. Cf. my WDM book at p. 424.

But an example that *is* a problem is IoAllocateWorkItem. Last time I
asked about this, HCT fails a driver that imports ExQueueWorkItem,
whether or not you actually call it in 2K/XP. To deal with that, I wrote
WDMSTUB.SYS – a lower filter that supplies a large number of missing
imports for 98/Me.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com