Actually, the practice I refer to is using the latest build environment and not using the target version macro. You can get away with building a KM driver on Vista and running it way downlevel without using the target version macros, but I wouldn’t expect that to last forever.
I’m sure MmGetSystemRoutineAddress isn’t even close to being endangered. We’d be one of the first groups to howl, and it would actually be quite a chorus just from the few pieces I know about.
Bob,
That is news to me that this will work. Unfortunately, there are too
many things like the safe string libraries that will not work down to 2000!
I filed bugs on these during the beta, and unfortunately they were closed
with fixes.
I agree with Mark Roddy and others, the simplest and safest method to
support this is use the lowest common denominator code. If you need to use
extended functions create a library with targets for Vista, that uses the
MmGetSystemRoutine address and handles the requests.
I have spent way too much time cleaning up drivers so they work down
rev that customers followed the build for latest but just don’t use the new
calls approach that Microsoft recomends.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Actually, the practice I refer to is using the latest build environment and
not using the target version macro. You can get away with building a KM
driver on Vista and running it way downlevel without using the target
version macros, but I wouldn’t expect that to last forever.
I’m sure MmGetSystemRoutineAddress isn’t even close to being endangered.
We’d be one of the first groups to howl, and it would actually be quite a
chorus just from the few pieces I know about.
>>> Yes indeed - this only applies to kernel mode drivers - but of course
similar methods are available up above in user mode. I certainly don’t
recommend doing this. The OP pointed to a section of the docs and I just
intended to clarify what that section was actually talking about.
Actually, OP had a good point. This part of docs is misleading. Recently I had to solve the same problem, read it, thought something bad about MS and made it the standard way (the one you recommend).
<<
I thought better and edited this out before (meaning I may have been wiser if not older then), but I suspect given its location that the practice was written assuming that header files and accompanying library usage is the only difference in build environments, and it isn’t.
>
Having one binary to support multiple OSes with WDK isn’t quite easy. If you define the lowest platform versions, prototypes and definitions for newer platforms aren’t available because they’re preprocessed out from WDK headers. Finally I made a separate source file with Vista support and redefined NTDDI_VERSION and _WIN32_WINNT before including WDK headers. Which may not be quite safe but Vista-only part I’d have to copy from headers was too big.
<<
FWIW, what you did is good practice as far as I’m concerned. If it’s just a matter of function prototypes, you’ll have to go through a pointer, and have to define a typedef for each (or write some interesting casts), so changing the defines won’t help much. But you usually need structures. Flag definitions and the like, and using the headers this way is better than cutting and pasting a snapshot. We certainly have to do it enough ourselves.
But it’s not really any easier or safer in user mode.
Sorry the end of the first paragraph should have been “closed without
fixes”
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Don Burn” wrote in message news:xxxxx@ntdev…
> Bob,
>
> That is news to me that this will work. Unfortunately, there are too
> many things like the safe string libraries that will not work down to
> 2000! I filed bugs on these during the beta, and unfortunately they were
> closed with fixes.
>
> I agree with Mark Roddy and others, the simplest and safest method to
> support this is use the lowest common denominator code. If you need to
> use extended functions create a library with targets for Vista, that uses
> the MmGetSystemRoutine address and handles the requests.
>
> I have spent way too much time cleaning up drivers so they work down
> rev that customers followed the build for latest but just don’t use the
> new calls approach that Microsoft recomends.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> “Bob Kjelgaard” wrote in message
> news:xxxxx@ntdev…
> Actually, the practice I refer to is using the latest build environment
> and not using the target version macro. You can get away with building a
> KM driver on Vista and running it way downlevel without using the target
> version macros, but I wouldn’t expect that to last forever.
>
> I’m sure MmGetSystemRoutineAddress isn’t even close to being endangered.
> We’d be one of the first groups to howl, and it would actually be quite a
> chorus just from the few pieces I know about.
>
>
>
Safe strings do work to win2k, you have to use the lib instead of the
pure header though. Something you need to manage and know about
apriori, but not a show stopper
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, March 02, 2007 11:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Windows 2003/XP
Bob,
That is news to me that this will work. Unfortunately, there are
too
many things like the safe string libraries that will not work down to
2000!
I filed bugs on these during the beta, and unfortunately they were
closed
with fixes.
I agree with Mark Roddy and others, the simplest and safest method
to
support this is use the lowest common denominator code. If you need to
use
extended functions create a library with targets for Vista, that uses
the
MmGetSystemRoutine address and handles the requests.
I have spent way too much time cleaning up drivers so they work
down
rev that customers followed the build for latest but just don’t use the
new
calls approach that Microsoft recomends.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Actually, the practice I refer to is using the latest build environment
and
not using the target version macro. You can get away with building a KM
driver on Vista and running it way downlevel without using the target
version macros, but I wouldn’t expect that to last forever.
I’m sure MmGetSystemRoutineAddress isn’t even close to being endangered.
We’d be one of the first groups to howl, and it would actually be quite
a
chorus just from the few pieces I know about.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Don-
I use safe string for multi-platform drivers down to Win2K [not using it isn’t really an option here]. I also have some fairly trivial software-only test drivers that I can just build for Vista and they work.
For the safe string usage, place ntstrsafe.lib in TARGETLIBS and #define NTSTRSAFE_LIB before you include the header, but as long as you do that, you shouldn’t run afoul of the export differences in the kernels.
Thanks to all for the feedback. It always helps to have some concept of the real pain experienced in the event my doc bug comes back “Won’t Fix” and I’m feeling argumentative.
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Bob Kjelgaard[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, March 02, 2007 8:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Windows 2003/XPFWIW, what you did is good practice as far as I’m concerned. If it’s just a matter of function prototypes, you’ll have to go through a pointer, and have to define a typedef for each (or write some interesting casts), so changing the defines won’t help much. But you usually need structures. Flag definitions and the like, and using the headers this way is better than cutting and pasting a snapshot. We certainly have to do it enough ourselves.
It’d be nice if it is considered as standard need and WDK headers are written safer way. It means allow to access structures and definitions for newer version (by defining some symbol) but not function prototypes which’d have to be typedefed and resolved dynamically. What scares me and what collides with the approach I used is code like this (wdm.h):
#if (NTDDI_VERSION < NTDDI_LONGHORN)
BOOLEAN
RTLVERLIB_DDI(WdmlibRtlIsNtDdiVersionAvailable)(
ULONG Version
);
BOOLEAN
RTLVERLIB_DDI(WdmlibRtlIsServicePackVersionInstalled)(
ULONG Version
);
#define RtlIsNtDdiVersionAvailable WdmlibRtlIsNtDdiVersionAvailable
#define RtlIsServicePackVersionInstalled WdmlibRtlIsServicePackVersionInstalled
#endif
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Bob,
I know of the tricks on safe string, the problem was in some cases this
still does not work. In particular, you are back rev to Windows 2000 SP4,
since the improved WDK safe string stuff uses functions exported from the
kernel, that will not work with earlier revisions. Now consider the fun of
a driver that needs to be present at Windows 2000 install time, either I
teach every poor user the fun of slipstreaming the Windows 2000 release to
be SP4, or I throw out safe string! Or as I finally was forced to do, I
went back to older rev’s of the DDK, and cursed Redmond when they closed
the bugs without thinking! The experience has permanently soured me on
safe string, and I try to avoid it where ever possible.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Don-
I use safe string for multi-platform drivers down to Win2K [not using it
isn’t really an option here]. I also have some fairly trivial
software-only test drivers that I can just build for Vista and they work.
For the safe string usage, place ntstrsafe.lib in TARGETLIBS and #define
NTSTRSAFE_LIB before you include the header, but as long as you do that,
you shouldn’t run afoul of the export differences in the kernels.
Thanks to all for the feedback. It always helps to have some concept of
the real pain experienced in the event my doc bug comes back “Won’t Fix”
and I’m feeling argumentative.
Thanks, Don-
An education, as always. KMDF doesn’t support anything before SP4 (and safe string didn’t exist in the days when I did the bulk of my kernel work before returning here) so I wasn’t aware of this.
Michal- that was quite informative- thanks.
Hi Bob,
Our software package consists of TWAIN and WIA driver, and few other pieces.
The package plans to provide support for TWAIN from Win2K onwards, but WIA
support can only be provided from WinXP onwards. Hence we can not build our
software package on the lowest build envrionment of WDK, i.e., Win2K build
environment.
But as suggested by Anton A. Kolomyeytsev" xxxxx@rocketdivision.com in one
mail:
add *Subsystem Version = 5.00*(For Win2k)
when I tried by adding *Subsystem Version = 5.00*(For Win2k) in batch file
and build it on WDK 2003 server build environment i am able to use my
binaries on winXP and on Win2K also.
i want to know,
*Changing the subsystem version can affect* the driver behavior in any
way ???
I am thankful to all of you for your co-operation .
Regards
Abhishkek
On 3/3/07, Bob Kjelgaard wrote:
>
> Michal- that was quite informative- thanks.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>>
Our software package consists of TWAIN and WIA driver, and few other pieces. The package plans to provide support for TWAIN from Win2K onwards, but WIA support can only be provided from WinXP onwards. Hence we can not build our software package on the lowest build envrionment of WDK, i.e., Win2K build environment.
<<
Unless both functions are contained in a single built binary, you can also accomplish this by building the overall package for WinXP and setting NT_TARGET_VERSION to Win2K in the SOURCES file for the TWAIN binaries. OR you can kick the WINNT_WIN32-type versioning macros up (to indicate WinXP user mode function) in the header files used in your code to support the WIA function and build the whole package in the Win2K build environment as was suggested, and that should also work (but it won’t work in the old DDK, because it had separate sets of header files for each environment).
>
Changing the subsystem version can affect the driver behavior in any way ???
<<
That’s way too broad a question for me to give an accurate answer to. In this specific case, probably not. But I’m not intimately familiar with WIA and TWAIN support across four OS releases spanning some seven or eight years, so I’m not going to give an absolute “no problems will result”.
In the general case, my understanding is that different subsystems (eg windows, console, native) have differing interpretations of what that marking means, and I feel it is better not to touch it unless you have to. I have no idea if anything else (OS component outside the loader and subsystem, 3rd party app, other infrastructure likely to appear an end-user machines) has ideas of its own about what this marking means. The fact that they might and I have no way of being certain they don’t is enough to give me pause.
OVERALL:
Please understand that I answered this thread in the first place because our product and its associated tests have to work across these platforms, so I have some familiarity with the ins and outs of it. We have to build on the latest and use the target version macros- but in the WDK this is the same as building on the oldest, which is why I did and still do recommend it.
But I am not “official”. Whenever the bug I filed gets dealt with, I get my “official” response. I can post back if and when it happens, if there’s any interest [if it gets fixed, you’ll see it on MSDN in pretty much the same timeframe as any post I could do].