MmGetSystemRoutineAddress BugCheck?

NTDEV
101

Because people misinterpret the version data they get back when they do
version checks. For instance, instead of >= a lot of folks mistakenly
use == and then fail to run on a new major or minor version of the OS.
This is why RtlVerifyVersionInfo and RtlGetVersion were introduced.
RtlVerifyVersionInfo will perform the right check for you.
Additionally, like I said previously, RtlGetVersion returns more
information to you then PsGetVersion does, especially with the EX
version of the structure.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 7:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Well, that is part of the problem. Why does it matter if I don’t want
the new functionality and just want to use PsGetVersion? It works and
has worked for a good long time. Is there something wrong with using
that function on Vista? I want to use that function because I know it
works everywhere and I don’t have to worry about what my driver is
targeting or what it might target tomorrow. I just don’t understand,
unless there is a technical problem, why a function like that would ever
be obsoleted.

Bill M.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

We pushed back on the warning for PsGetVersion, we get warned
too ;). The idea is to encourage those driver writers who do not target
win2k to use the newer API, PFD has no way of knowing what the minimum
targeted OS is to turn off warnings selectively…

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 8:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Yes…what he said…ditto.

Bill M.

“Mark Roddy” wrote in message
news:xxxxx@ntdev…

I’m okay with having a new improved PsGetVersionEx, but
not with obsolescing the existing PsGetVersion while the platforms that
only provide that version are still out there, especially in light of
this discussion.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think
of the implications. It seems a bad idea to change, from platform to
platform, the routines used to determine the platform. It seems to me
anyway??

Bill M.

“Doron Holan” wrote
in message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on
Win2k and then uses MmGetSystemRoutineAddress to get RtlGetVersion for
later platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress
BugCheck?

Ok, nobody has asked this yet so I’ll take the
dangerous leap.

Vista WHQL now requires submission of the
PreFast output. PreFast puts out a warning for the use of PsGetVersion.
So in our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress
(“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress
(“PsGetVersion”))


(We’d only be using this on 32-bit operating
systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k
through Vista.)

1. Since both of these XxxGetVersion routines
are not alphabetically before any exports in either ntoskrnl or hal,
this should not bug check, so this should be OK. But it might be an
overkill. So …

2. Will Microsoft accept a WHQL submission for
a driver that uses the obsolete PsGetVersion? I know, you can #pragma
the warning, but Microsoft might inspect my import table. I’d sure like
to know the answer to this before we go through a couple of weeks
running the tests and submitting them to find that we gotta recode,
rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a
solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On
Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress
BugCheck?

Alternatively, you could always check the OS
version before calling
MmGetSystemRoutineAddress and circumvent the
problem entirely. Call
PsGetVersion, if that reports XP or later, then
you can link to
RtlGetVersion and use that for even
service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems
rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote
in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of
it this morning (had to,
I
use this function a lot past and present). But
I’d rather not be deemed

“official”, since I don’t own this part of the
code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP
SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP
SP2 because there wasn’t
sufficient justification (OCA /customer
complaints, etc). Don’t shoot
the
messenger- everything I can see says it was
proactively fixed when
internally identified, and the owner did his
best to get it ported as
far
back as acceptable. Because of this, and the
time I spent on those
efforts,
my guess would be that Server SP1 (and thus
“64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is
unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI
name starting near the
front
of the ANSI sort order (basically alphabetical
order) to hit this-
DbgPrintEx was the furthest in I saw any report
of. Might be any name
before the first name in the HAL (but that’s a
wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an
exception handler to work
around
it.

—
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

—
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

— 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

—
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

—
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

—
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

102

>Additionally, like I said previously, RtlGetVersion returns more information to you then >PsGetVersion does, especially with the EX version of the structure.

Right, that is why I said “if I don’t want the new functionality”. I don’t care…I just want to get the version and go.

Because people misinterpret the version data they get back when they do version checks. For >instance, instead of >= a lot of folks mistakenly use == and then fail to run on a new major or minor >version of the OS.

I have no problem with this up to the point that Winqual process makes this mandatory. I don’t know if they do…I guess I will find out shortly. I hope someone puts a note somewhere to say they can’t ever do that. I kind of look at this as you guys made the ambiguous DDI, you have to live with it.

Not trying to beat a dead horse, but issues like this one make creating cross-platform generic code bases very difficult and it keeps on happening. Forcing the use of a new DDI, that in my case buys me effectively nothing costs me and/or the companies that employ me $$. Someone needs to look backwards while everyone is looking forwards…follow?

Just a thought.

Bill M.

“Doron Holan” wrote in message news:xxxxx@ntdev…
Because people misinterpret the version data they get back when they do version checks. For instance, instead of >= a lot of folks mistakenly use == and then fail to run on a new major or minor version of the OS. This is why RtlVerifyVersionInfo and RtlGetVersion were introduced. RtlVerifyVersionInfo will perform the right check for you. Additionally, like I said previously, RtlGetVersion returns more information to you then PsGetVersion does, especially with the EX version of the structure.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 7:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Well, that is part of the problem. Why does it matter if I don’t want the new functionality and just want to use PsGetVersion? It works and has worked for a good long time. Is there something wrong with using that function on Vista? I want to use that function because I know it works everywhere and I don’t have to worry about what my driver is targeting or what it might target tomorrow. I just don’t understand, unless there is a technical problem, why a function like that would ever be obsoleted.

Bill M.

“Doron Holan” wrote in message news:xxxxx@ntdev…

We pushed back on the warning for PsGetVersion, we get warned too ;). The idea is to encourage those driver writers who do not target win2k to use the newer API, PFD has no way of knowing what the minimum targeted OS is to turn off warnings selectively.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 8:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Yes…what he said…ditto.

Bill M.

“Mark Roddy” wrote in message news:xxxxx@ntdev…

I’m okay with having a new improved PsGetVersionEx, but not with obsolescing the existing PsGetVersion while the platforms that only provide that version are still out there, especially in light of this discussion.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Why was this changed btw? Did whoever changed it think of the implications. It seems a bad idea to change, from platform to platform, the routines used to determine the platform. It seems to me anyway??

Bill M.

“Doron Holan” wrote in message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to work on Win2k and then uses MmGetSystemRoutineAddress to get RtlGetVersion for later platforms, I am pretty sure you can do the same w/out issue.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll take the dangerous leap.

Vista WHQL now requires submission of the PreFast output. PreFast puts out a warning for the use of PsGetVersion. So in our drivers I was thinking of (excuse the pseudo code):

if (pRtlGetVersion = MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah, I know, I gotta use UNICODE_STRINGS

else
if (pPsGetVersion = MmGetSystemRoutineAddress (“PsGetVersion”))


(We’d only be using this on 32-bit operating systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support Win 2k through Vista.)

1. Since both of these XxxGetVersion routines are not alphabetically before any exports in either ntoskrnl or hal, this should not bug check, so this should be OK. But it might be an overkill. So …

2. Will Microsoft accept a WHQL submission for a driver that uses the obsolete PsGetVersion? I know, you can #pragma the warning, but Microsoft might inspect my import table. I’d sure like to know the answer to this before we go through a couple of weeks running the tests and submitting them to find that we gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”

cc

Subject
RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check the OS version before calling
MmGetSystemRoutineAddress and circumvent the problem entirely. Call
PsGetVersion, if that reports XP or later, then you can link to
RtlGetVersion and use that for even service-pack-level granularity
before
making further MmGetSystemRoutineAddress calls.

I’d prefer that to relying on an SEH; seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first heard of it this morning (had to,
I
use this function a lot past and present). But I’d rather not be deemed

“official”, since I don’t own this part of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted for XP SP2 because there wasn’t
sufficient justification (OCA /customer complaints, etc). Don’t shoot
the
messenger- everything I can see says it was proactively fixed when
internally identified, and the owner did his best to get it ported as
far
back as acceptable. Because of this, and the time I spent on those
efforts,
my guess would be that Server SP1 (and thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as that OS is unsupported.

FURTHERMORE:

* You need to be looking for a non-existent DDI name starting near the
front
of the ANSI sort order (basically alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any report of. Might be any name
before the first name in the HAL (but that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an exception handler to work
around
it.

—
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

—
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

— 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

—
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

—
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

—
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

103

I completely agree that this is frustrating. Fortunately for you guys,
KMDF internally, for the most part, sees these errors before they make
it out into final WDK and we get them fixed. These types of changes
typically come from other teams and we are just as surprised as you are
when they initially arrive.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 9:18 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Additionally, like I said previously, RtlGetVersion returns more
information to you then >PsGetVersion does, especially with the EX
version of the structure.

Right, that is why I said “if I don’t want the new functionality”. I
don’t care…I just want to get the version and go.

Because people misinterpret the version data they get back when they do
version checks. For >instance, instead of >= a lot of folks mistakenly
use == and then fail to run on a new major or minor >version of the OS.

I have no problem with this up to the point that Winqual process makes
this mandatory. I don’t know if they do…I guess I will find out
shortly. I hope someone puts a note somewhere to say they can’t ever do
that. I kind of look at this as you guys made the ambiguous DDI, you
have to live with it.

Not trying to beat a dead horse, but issues like this one make creating
cross-platform generic code bases very difficult and it keeps on
happening. Forcing the use of a new DDI, that in my case buys me
effectively nothing costs me and/or the companies that employ me $$.
Someone needs to look backwards while everyone is looking
forwards…follow?

Just a thought.

Bill M.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

Because people misinterpret the version data they get back when
they do version checks. For instance, instead of >= a lot of folks
mistakenly use == and then fail to run on a new major or minor version
of the OS. This is why RtlVerifyVersionInfo and RtlGetVersion were
introduced. RtlVerifyVersionInfo will perform the right check for
you. Additionally, like I said previously, RtlGetVersion returns more
information to you then PsGetVersion does, especially with the EX
version of the structure.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Thursday, June 07, 2007 7:03 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Well, that is part of the problem. Why does it matter if I
don’t want the new functionality and just want to use PsGetVersion? It
works and has worked for a good long time. Is there something wrong
with using that function on Vista? I want to use that function because
I know it works everywhere and I don’t have to worry about what my
driver is targeting or what it might target tomorrow. I just don’t
understand, unless there is a technical problem, why a function like
that would ever be obsoleted.

Bill M.

“Doron Holan” wrote in
message news:xxxxx@ntdev…

We pushed back on the warning for PsGetVersion, we get
warned too ;). The idea is to encourage those driver writers who do not
target win2k to use the newer API, PFD has no way of knowing what the
minimum targeted OS is to turn off warnings selectively…

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 8:36 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress BugCheck?

Yes…what he said…ditto.

Bill M.

“Mark Roddy” wrote in
message news:xxxxx@ntdev…

I’m okay with having a new improved
PsGetVersionEx, but not with obsolescing the existing PsGetVersion while
the platforms that only provide that version are still out there,
especially in light of this discussion.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Wednesday, June 06, 2007 6:32 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] MmGetSystemRoutineAddress
BugCheck?

Why was this changed btw? Did whoever changed
it think of the implications. It seems a bad idea to change, from
platform to platform, the routines used to determine the platform. It
seems to me anyway??

Bill M.

“Doron Holan”
wrote in message news:xxxxx@ntdev…

KMDF directly imports PsGetVersion to
work on Win2k and then uses MmGetSystemRoutineAddress to get
RtlGetVersion for later platforms, I am pretty sure you can do the same
w/out issue.

d

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@attotech.com
Sent: Wednesday, June 06, 2007 1:26 PM
To: Windows System Software Devs
Interest List
Subject: RE: [ntdev]
MmGetSystemRoutineAddress BugCheck?

Ok, nobody has asked this yet so I’ll
take the dangerous leap.

Vista WHQL now requires submission of
the PreFast output. PreFast puts out a warning for the use of
PsGetVersion. So in our drivers I was thinking of (excuse the pseudo
code):

if (pRtlGetVersion =
MmGetSystemRoutineAddress (“RtlGetVersion”)) // Yeah, I know, I gotta
use UNICODE_STRINGS

else
if (pPsGetVersion =
MmGetSystemRoutineAddress (“PsGetVersion”))


(We’d only be using this on 32-bit
operating systems. All the 64-bit systems support RtlGetVersion.)
(And we want a single binary to support
Win 2k through Vista.)

1. Since both of these XxxGetVersion
routines are not alphabetically before any exports in either ntoskrnl or
hal, this should not bug check, so this should be OK. But it might be
an overkill. So …

2. Will Microsoft accept a WHQL
submission for a driver that uses the obsolete PsGetVersion? I know,
you can #pragma the warning, but Microsoft might inspect my import
table. I’d sure like to know the answer to this before we go through a
couple of weeks running the tests and submitting them to find that we
gotta recode, rebuild and run 'em over again.

Thanks,

Jerry.

Doron Holan
Sent by: xxxxx@lists.osr.com

06/04/2007 02:25 PM

Please respond to
“Windows System Software Devs Interest List”

To

“Windows System Software Devs Interest List”

cc

Subject

RE: [ntdev] RE:MmGetSystemRoutineAddress BugCheck?

That is exactly what I was trying to
state as a solution, perhaps not as
clearly. Thanks for reiterating ;).

d

-----Original Message-----
From: xxxxx@lists.osr.com

[mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
Sent: Monday, June 04, 2007 10:34 AM
To: Windows System Software Devs
Interest List
Subject: Re:[ntdev]
RE:MmGetSystemRoutineAddress BugCheck?

Alternatively, you could always check
the OS version before calling
MmGetSystemRoutineAddress and circumvent
the problem entirely. Call
PsGetVersion, if that reports XP or
later, then you can link to
RtlGetVersion and use that for even
service-pack-level granularity
before
making further MmGetSystemRoutineAddress
calls.

I’d prefer that to relying on an SEH;
seems rather more bulletproof than

swallowing foreign access violations…

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Bob Kjelgaard”
wrote in message
news:xxxxx@ntdev…
I looked into this as soon as I first
heard of it this morning (had to,
I
use this function a lot past and
present). But I’d rather not be deemed

“official”, since I don’t own this part
of the code. So I’ve been
waiting,
but I’ll offer this info as is.

It is fixed in Vista. It will be fixed
in XP SP3. Couldn’t find
anything
about Server SP1. It was not accepted
for XP SP2 because there wasn’t
sufficient justification (OCA /customer
complaints, etc). Don’t shoot
the
messenger- everything I can see says it
was proactively fixed when
internally identified, and the owner did
his best to get it ported as
far
back as acceptable. Because of this,
and the time I spent on those
efforts,
my guess would be that Server SP1 (and
thus “64-bit XP”) has probably
got
the fix.

IMO, it won’t get fixed for Win2K, as
that OS is unsupported.

FURTHERMORE:

* You need to be looking for a
non-existent DDI name starting near the
front
of the ANSI sort order (basically
alphabetical order) to hit this-
DbgPrintEx was the furthest in I saw any
report of. Might be any name
before the first name in the HAL (but
that’s a wild guess, and there’ve
been
too many of them already).

* It appears that you can readily use an
exception handler to work
around
it.

—
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

—
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

— 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

—
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

—
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

—
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

—
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

104

So, your point is… Getting logo’ed is annoying and arbitrary? Well, yeaaahhhh. It’s not like it’s EVER been about technical quality or correctness.

Bottom line: YOU want THEIR logo to help sell YOUR products… so YOU have to do what THEY want.

Sorry, but that’s all it really comes down to,

Peter
OSR

105

Did I say I minded the logoing process?

What I mind, and I guess I am not explaining myself well, is that a
perfectly valid function that is the only function that works on all
platforms and is STILL valid on all platforms gets obsoleted just because
some bright bulb decided to come up with a new better function that does the
same thing and washes your car. I don’t need my car washed (only on some
arbitrary platform and later).

It changes from this:

SomeDDIThatWorksPerfectlyWellOnAllPlatforms(…);

to this:

if (not on arbitrary version of Windows or later)
{
// Do what always works
SomeDDIThatWorksPerfectlyWellOnAllPlatforms(…);
}
else
{
SomeSpiffyNewDDIThatHopefullyWorksOnSomeArbitraryVersionOfWindowsAndHopefullyDoesn’tGetReplacedAgain(…);
}

And of course the two are never similar so, you have to jack around with
types and such. It’s just a mess…what this sort of thing never bothered
you?

And again, I don’t mind the new DDI, but c’mon the old DDI in this case is
perfectly fine…why force a change just because someone might not know how
to program…it’s silly.

Bill M.

wrote in message news:xxxxx@ntdev…
>


>
> So, your point is… Getting logo’ed is annoying and arbitrary? Well,
> yeaaahhhh. It’s not like it’s EVER been about technical quality or
> correctness.
>
> Bottom line: YOU want THEIR logo to help sell YOUR products… so YOU have
> to do what THEY want.
>
> Sorry, but that’s all it really comes down to,
>
> Peter
> OSR
>
>

106

Somebody had to say it.

>> xxxxx@osr.com 2007-06-07 14:44 >>>

So, your point is… Getting logo’ed is annoying and arbitrary? Well,
yeaaahhhh. It’s not like it’s EVER been about technical quality or
correctness.

Bottom line: YOU want THEIR logo to help sell YOUR products… so YOU
have to do what THEY want.

Sorry, but that’s all it really comes down to,

Peter
OSR

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

107

OF COURSE it’s silly. And OF COURSE the well-intentioned folks who implement this stuff don’t really understand how we use these functions and why these changes drive us up the wall.

Want my favorite example: Why was PoStartNextPowerIrp declared deprecated, so that it causes warnings when you build in the checked build environment… yet you can’t build a down-level compatible driver without calling it? So, is it or is it not deprecated?

Peter
OSR

108

Yeah well good to see you are keeping your tempo of helpful comments in this
thread.

Bill M.

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Somebody had to say it.
>
>>>> xxxxx@osr.com 2007-06-07 14:44 >>>
>


>
> So, your point is… Getting logo’ed is annoying and arbitrary? Well,
> yeaaahhhh. It’s not like it’s EVER been about technical quality or
> correctness.
>
> Bottom line: YOU want THEIR logo to help sell YOUR products… so YOU
> have to do what THEY want.
>
> Sorry, but that’s all it really comes down to,
>
> Peter
> OSR
>
>
> —
> 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
>

109

xxxxx@osr.com wrote:

So, your point is… Getting logo’ed is annoying and arbitrary? Well, yeaaahhhh. It’s not like it’s EVER been about technical quality or correctness.

Bottom line: YOU want THEIR logo to help sell YOUR products… so YOU have to do what THEY want.

Sorry, but that’s all it really comes down to,

No, there really is one more important aspect to this, and that is the
dreaded “CAUTION! This driver is unsigned; it was probably written by
crazed paranoid crack addicts, and its installation will probably result
in the end of Western Civilization” warning. The logo signature is the
only way to eliminate that. It’s more having Microsoft help sell my
products, it’s Microsoft actively disparaging my products unless I jump
through the “annoying and arbitrary” hoops.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

110

What I said had nothing to do with you. I was just talking about the
whole lab process in general. Also, I stated publicly I was wrong. It
does happen. I really don’t see the big deal man.

mm

>> xxxxx@sbcglobal.net 2007-06-07 15:38 >>>
Yeah well good to see you are keeping your tempo of helpful comments in
this
thread.

Bill M.

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Somebody had to say it.
>
>>>> xxxxx@osr.com 2007-06-07 14:44 >>>
>


>
> So, your point is… Getting logo’ed is annoying and arbitrary?
Well,
> yeaaahhhh. It’s not like it’s EVER been about technical quality or
> correctness.
>
> Bottom line: YOU want THEIR logo to help sell YOUR products… so
YOU
> have to do what THEY want.
>
> Sorry, but that’s all it really comes down to,
>
> Peter
> OSR
>
>
> —
> 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
>

—
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

111

> It seems there are multiple versions of the library. One version doesn’t

MmGetSystemRoutineAddress at all, guess it just calls
ZwQuerySystemInformation. Probably this version is intended for “older” OSes
where ZwQuerySystemInformation is known to work. What I don’t know is how
you could make a single binary that would work in every OS. Guess it isn’t
possible.

All versions (in fact, there is only 1) call ZwQuerySystemInformation.

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

112

Maxim S. Shatskih wrote:

> It seems there are multiple versions of the library. One version doesn’t
> MmGetSystemRoutineAddress at all, guess it just calls
> ZwQuerySystemInformation.

All versions (in fact, there is only 1) call ZwQuerySystemInformation.

No. There is a single version in the WDK, but there are 3 libraries in the *download* (check the link on the AuxKlibQueryModuleInformation doc page). As I was saying, one library is for user mode and two for kernel mode. One kernel mode is for NT4, the other is for W2k and later.

The NT4 version calls ZwQuerySystemInformation *unconditionally* (it doesn’t have much choice, but it’s safe in NT4). The w2k version first calls MmGetSystemRoutineAddress to check if a new DDI is exported by the kernel. If it does (which I guess will happen in future OS versions), then it uses the new DDI. It calls ZwQuerySystemInformation only when the new DDI is not present.

I didn’t reverse engineer the library, but this is almost obvious just by looking at the symbols and the name of the new (future) DDI.

113

> No. There is a single version in the WDK, but there are 3 libraries in the *download*

Forgot to note that I am talking about 3 libraries in the download for X86. There are *in addition*, two separate downloads for X64 and I64.