Multi-Plattform Support, was: Re: Windows 2003/XP

NTDEV
1

Just 2 cents:

(a) With applications I discovered the same problem as Abhishek (e.g. a
test app built in the XP build environment does not run on Windows
2000). My solution was to ditch WDK “build” and to use the VS6 “nmake”.
For very small test applications with one or two source files this is
probably easiest.

(b) Doron Holan showed a nice way to set the target OS version in the
“sources” file used by build.exe to compile your stuff.
Addind this one definition should be fairly easy.
The key is “the SOURCES file” (= one file used by build.exe),
not “your source files” (=possibly 100+ files). :slight_smile:

(c) The BulkUsb (WDM) WDK sample demonstrates nicely the MSDN quote that
Abhishek referred to (please bear with me, even if this now applies to
driver level and not to an application):

You build the USB driver in the XP build environment – and it runs
without modification anywhere on Windows 2000, Windows XP, Windows 2003
Server and Windows Vista. The 64-bit compiles run on all 64-bit
platforms, too.

(It will actually not build in the Windows 2000 build environment.
Without giving you any reason, why, and also no other hint. You just
have to figure this one out.)

(d) You can get even more “legacy” OS support:
My driver needs to work on Windows ME and Windows 98, too (some
customers use our software in combination with a computer as a “black
box” system).

So I had to cater for Windows 98 and Windows ME, too:

  • Windows ME is very easy: here is just the ExFreePoolWithTag call
    missing, so the redefinition of ExFreePool (bulkusb.h) has to be
    “shielded” by something like “#ifdef BREAK_WIN98_WINME”

  • Windows 98 is a bit trickier: two USBD functions were exported in a
    wrong way by USBD.SYS(W98) and some NTOSKRNL functions do not exist.
    The most reasonable way to cope with this is to write a lower driver
    that implements the missing functions. Luckily you don’t need to do this
    yourself:
    Buy Walter Oney’s book (Programming the Windows Driver Model, 2nd Ed.),
    get the ServicePacks from his web site, and use WDMSTUB.SYS and
    USBD98.LIB. (And don’t forget to copy two #define lines from stddcls.h
    to use renamed USBD functions that link with USBD98.LIB).

BTW, the missing calls on Win98 and WinME were discovered using
WDMCHECK.EXE (also by Walter Oney, free download).
You have to actually run this on a Windows 98 and Windows ME installation.

Cheers
-Hagen

2

Hi,

Joining this thread a little bit late…
I have a fundamental question:
I need to deliver a driver that support Win2K through Vista.
I’m as a developer think that the best thing to do is to compile one target, with target Win2K and dynamically load any enhanced functions in later OS.
Is there any performance ‘price’ doing so?
I mean:
If I compile same code, one compile for Win2K as target and second for Vista as target and than I run it on VISTA - will the performance be the same?

Thanks

3

> I’m as a developer think that the best thing to do is to compile one target,
with

target Win2K and dynamically load any enhanced functions in later OS.

You can even forget about this dynamic load, and everything will work fine
anyway.

Coding to w2k’s APIs is enough big time, unless you do something like a GigE
miniport.

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