Is Windows LP64?

[Don_Burn_1]

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Don Burn wrote:
>
> Again, as an existence proof, I would point to the wildly heterogeneous
> world of Unix, where 32-bit ints and 64-bit longs have lived a happy and
> peaceful coexistence for a long time.
>
I can remember that Unix did not live harmoniously for a lot of that time.
I fact at the C++ standards committee meetings people had to be physically
restrained about this subject.

–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

Information from ESET NOD32 Antivirus, version of virus signature database 4872 (20100216)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

[OSR_Community_User]

On Tue, 2010-02-16 at 10:18 -0800, Tim Roberts wrote:

Do they introduce a “long long long” type for 128-bit ints?

Tim,

That would be a ‘long long long long’, not a ‘long long long’. Suitable
for the Cray-8, if Seymour was still alive.

Hummm I left Sun prior to seeing the ZFS code, I’m wondering what they
did…

Thx,
-PWM

[Peter_Viscarola_OSR]

I was particularly sensitive
to chauvinistic programming assumptions about things like “bytes” and
“characters”…

I say if you ever programmed on a DECSystem-10 (where a byte is any contiguous set of 2 or more bits) you’ll never think of a “byte” the say way again.

Tim says that Windows is ILP64 and Peter says LLP64.

It’s LLP64.

If you don’t believe me, believe Raymon Chen: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

or MSDN:

http://msdn.microsoft.com/en-us/library/ms973190.aspx

or if you want something “open source” you can believe Wikipedia:

http://en.wikipedia.org/wiki/64-bit

And why is that? It is a relic of the circa 1993 conversion from 16-bit
to 32-bit, because it was the only type guaranteed to be 32-bit in both
environments.

Only partially. The use of the abstract architectural data types actually derives in large part from the desire to hide underlying details of the various processor architectures on which Windows can (could) run. Each processor architecture could/might have different data type preferences… having a standard, operating system defined, set of definitions that everyone used prevented any possible confusion. It’s just another way for creating that buffering abstraction.

Using OS defined abstract types is architecturally clean and consistent. It leads to predictable code that easily understood.

Having the length of your “short” or “long” data type change, based on the OS version is at the very least inconvenient. Heck, it’s not even that way in .NET (where “int” is always 32-bits and “long” is always 64 bits").

Or, alternatively, and better, you define your own compiler-independent
types, or use some pseudo-standard include file that eliminates the issue.

Well, if “you” is Microsoft, that’s exactly what they’ve done. Those types are ULONG, USHORT, UCHAR.

If you mean “you” is driver developer, that’s what you often get in Linux code. Every dev has his own silly set of definitions that changes or doesn’t change depending on the target platform or some include constraint. It makes me nuts. Just what I want to do when I pick up somebody’s code… figure out what the TimInt and uTim32 data types are.

Actually… I think the whole thing really comes down to personal preference and what you’re used to more than anything. But I really *do* dislike the idea of your data types changing their length depending on where your code is running.

Peter
OSR

[Tim_Roberts]

xxxxx@osr.com wrote:

Tim says that Windows is ILP64 and Peter says LLP64.

No, Tim never said Windows was ILP64. Those acronyms are attributes of
a COMPILER, not of an operating system. Tim said Visual C++ was ILP64.

It’s LLP64.

Yes. It used to be ILP64, because Visual C++ was late in getting “long
long” support. Now, it’s LLP64.

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

[Maxim_S_Shatskih]

> There is lots of Unix code that compiles just fine on 16-bit, 32-bit,

and 64-bit platforms. I don’t understand why Microsoft couldn’t trust
us to do the same.

Because, unlike UNIX, Windows was never widely portable (to little-endian 32bit machines only), and Windows programmers knew this very well. So, lots of unportable Windows code exists.

That’s why MS went the direction they went, and I support this.

Also about \system32 and \syswow64. This allows to have 32bit and 64bit versions of the same stuff - system DLLs, notepad and so on. Why is this bad?

Retaining the name of \system32 for the OS’s main dir is also a good idea.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-401513-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, February 16, 2010 12:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is Windows LP64?

> There is lots of Unix code that compiles just fine on 16-bit, 32-bit,
> and 64-bit platforms. I don’t understand why Microsoft couldn’t trust
> us to do the same.

Because, unlike UNIX, Windows was never widely portable (to little-endian
32bit machines only), and Windows programmers knew this very well. So,
lots
of unportable Windows code exists.

That’s why MS went the direction they went, and I support this.

Also about \system32 and \syswow64. This allows to have 32bit and 64bit
versions of the same stuff - system DLLs, notepad and so on. Why is this
bad?

Retaining the name of \system32 for the OS’s main dir is also a good idea.

Max, you’re kidding, right? Of all the ways MSFT could have dealt with the
move to 64 bits, using System32 as the location for 64-bit binaries, and
SysWow64 as the location for 32-bit binaries seems most likely to surprise
and confuse. Or maybe it’s just me?

Phil

[Maxim_S_Shatskih]

> SysWow64 as the location for 32-bit binaries seems most likely to surprise

and confuse.

Was never confusing to me. The main Windows dir retained the old name. The legacy sandbox dir has new name.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Tim_Roberts]

Maxim S. Shatskih wrote:

> There is lots of Unix code that compiles just fine on 16-bit, 32-bit,
> and 64-bit platforms. I don’t understand why Microsoft couldn’t trust
> us to do the same.
>

Because, unlike UNIX, Windows was never widely portable (to little-endian 32bit machines only), and Windows programmers knew this very well. So, lots of unportable Windows code exists.

And Microsoft should be ENCOURAGING this? The 16-to-32 transition
pushed good habits, for a short while. Given the opportunity to do the
same thing again, the opportunity was squandered.

Purity has value. That notion has somehow been lost.

That’s why MS went the direction they went, and I support this.

It’s fascinating to me that so many knowledgeable and experienced
developers can have such diametrically opposed opinions on such a
seemingly fundamental topic.

Also about \system32 and \syswow64. This allows to have 32bit and 64bit versions of the same stuff - system DLLs, notepad and so on. Why is this bad?

It’s bad because it’s silly. 64-bit stuff should go in System64, 32-bit
stuff should go in System32. How do you explain to someone that “no,
no, your 32-bit DLLs need to go in SysWow64”?

Again, I go back to the example of the 16-to-32 transition. 16-bit
stuff stayed in System, 32-bit stuff went in System32. This actually
allowed you to have Windows 3.1 and Windows 95 co-exist on the same
machine, using the same base directory.

Extending that successful model, why wouldn’t a reasonably intelligent
designer have simply added a new directory for 64-bit code, called
System64? By doing that, they COULD have allowed 32-bit and 64-bit
systems to boot from the same base directory, although that would have
been mostly an accident.

That choice would have completely eliminated the need for the stupid
file system redirection.

Retaining the name of \system32 for the OS’s main dir is also a good idea.

Why? The system directory was renamed from System to System32 when we
went from Windows 3.1 to Windows 95, and the world survived. Every
programmer with a brain already uses GetSystemDirectory instead of
hardcoding the path. 32-bit code that assumed System32 would continue
to work. Some installers would need to change, but they needed to
change anyway, to deal with the SysWow64 nonsense.

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

[Peter_Viscarola_OSR]

It’s bad because it’s silly. 64-bit stuff should go in System64, 32-bit stuff should go in System32.

Now THAT’s something we (you, Phil, and I) can definitely agree on.

While I understand why they did it (the 32- to 64-bit transition was supposed to be “seamless” and “transparent” to most software), it creates some astonishingly confusing cases. Most of the time, to be perfectly honest, I don’t remember or understand what’s where and have to look it up or just give up and search for the file…

Peter
OSR

[Maxim_S_Shatskih]

> to work. Some installers would need to change, but they needed to

change anyway, to deal with the SysWow64 nonsense.

If installer is 32bit - then not so it will automatically see SysWow64 as System32

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Peter_Wieland]

The main point was to avoid surprising & confusing 32-bit applications which were recompiled to 64-bit applications. Chasing down every use of system32 within the code and changing it over to system64 would have been a nightmare for everyone.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Tuesday, February 16, 2010 11:53 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is Windows LP64?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-401513-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, February 16, 2010 12:47 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Is Windows LP64?

> There is lots of Unix code that compiles just fine on 16-bit,
> 32-bit, and 64-bit platforms. I don’t understand why Microsoft
> couldn’t trust us to do the same.

Because, unlike UNIX, Windows was never widely portable (to
little-endian 32bit machines only), and Windows programmers knew this
very well. So,
lots
of unportable Windows code exists.

That’s why MS went the direction they went, and I support this.

Also about \system32 and \syswow64. This allows to have 32bit and
64bit versions of the same stuff - system DLLs, notepad and so on. Why
is this
bad?

Retaining the name of \system32 for the OS’s main dir is also a good idea.

Max, you’re kidding, right? Of all the ways MSFT could have dealt with the move to 64 bits, using System32 as the location for 64-bit binaries, and
SysWow64 as the location for 32-bit binaries seems most likely to surprise and confuse. Or maybe it’s just me?

Phil

---

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

[Tim_Roberts]

Peter Wieland wrote:

The main point was to avoid surprising & confusing 32-bit applications which were recompiled to 64-bit applications. Chasing down every use of system32 within the code and changing it over to system64 would have been a nightmare for everyone.

I dispute that. Anyone who hard-coded “System32” in their application
deserves whatever trouble they got. That lesson should have been
learned quite clearly in 1994 with the System -> System32 transition.

I guess that’s really the fundamental basis of my gripe. MANY of the
decisions that were made in the 32/64 transition seemed to have been
made in order to appease or enable bad programmers. You ended up making
the system more complicated for the GOOD programmers by enabling and
encouraging bad habits.

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

[Prokash_Sinha-1]

>

I’d argue the REAL mistake was long ago when the C language designers didn’t
specify the size of int and long, they just left it an implementers choice,
and implementers make different choices. Lots of language definitions DO
specify the size of basic types.

This is not what I thought all along… I[H]*MO, this is one of the best thing done ( but not specifying size_t ).

For the network, it is a different story ( big vs little ), so XDR is not bad at that.

[Prokash_Sinha-1]

Sounds like symlink might be good sometime!!!

There are plenty of FSF software that can easily break symlink, specially those who don’t play nice are SCMs…

On Feb 16, 2010, at 2:13 PM, Tim Roberts wrote:

Peter Wieland wrote:
> The main point was to avoid surprising & confusing 32-bit applications which were recompiled to 64-bit applications. Chasing down every use of system32 within the code and changing it over to system64 would have been a nightmare for everyone.
>

I dispute that. Anyone who hard-coded “System32” in their application
deserves whatever trouble they got. That lesson should have been
learned quite clearly in 1994 with the System -> System32 transition.

I guess that’s really the fundamental basis of my gripe. MANY of the
decisions that were made in the 32/64 transition seemed to have been
made in order to appease or enable bad programmers. You ended up making
the system more complicated for the GOOD programmers by enabling and
encouraging bad habits.

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

---

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

[Bob_Kroeter]

> Anyone who hard-coded “System32” in their application deserves whatever trouble they got

Agreed.

If installer is 32bit - then not so it will automatically see SysWow64 as System32

Not true, I have been there. A 32-bit installer installing a 64-bit driver must have access to the real system32. How many threads have been opened up on this subject?

FS redirection was a quick and dirty trick to fix a few old apps. But how many writing new code from that point forward are wasting time tripping over it, learning what it is, and working around it? How many people are forced to call GetProcAddress in new code now? This thing should have been done in a way that could fix the old apps and not messed up the whole system going forward.

Large Pages…why introduce another page size value?

You could ask the Itanium designers who upped the page size many years ago. And the large page size add on you alluded to is further proof 4K is too small, but we are stuck with them.

[Maxim_S_Shatskih]

> Not true, I have been there. A 32-bit installer installing a 64-bit driver

Rebuild the installer.

After all, 32bit SetupAPI does not work in WOW64.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[Doron_Holan]

Two words rule all decisons here: app compat. That is windows’ bread and butter. Purity of design/architecture is usually 2ndary to ap compat. I can’t tell you how many times a broken LOB app in a fortune 500 company causes an app compat fire…

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Tim Roberts
Sent: Tuesday, February 16, 2010 2:14 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Is Windows LP64?

Peter Wieland wrote:
> The main point was to avoid surprising & confusing 32-bit applications which were recompiled to 64-bit applications. Chasing down every use of system32 within the code and changing it over to system64 would have been a nightmare for everyone.
>

I dispute that. Anyone who hard-coded “System32” in their application
deserves whatever trouble they got. That lesson should have been
learned quite clearly in 1994 with the System -> System32 transition.

I guess that’s really the fundamental basis of my gripe. MANY of the
decisions that were made in the 32/64 transition seemed to have been
made in order to appease or enable bad programmers. You ended up making
the system more complicated for the GOOD programmers by enabling and
encouraging bad habits.

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

—
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

[OSR_Community_User]

Sure that works ok short term.

But long term everyone has to deal with new and surprising
inconsistencies.

Ideally app compatibility (for those who are unable to update said apps)
would be solved by tools like XP Mode.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-401580-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, February 17, 2010 2:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is Windows LP64?

Two words rule all decisons here: app compat. That is windows’ bread
and butter. Purity of design/architecture is usually 2ndary to ap
compat. I can’t tell you how many times a broken LOB app in a fortune
500 company causes an app compat fire…

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Tim Roberts
> Sent: Tuesday, February 16, 2010 2:14 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Is Windows LP64?
>
> Peter Wieland wrote:
> > The main point was to avoid surprising & confusing 32-bit
> applications which were recompiled to 64-bit applications. Chasing
> down every use of system32 within the code and changing it over to
> system64 would have been a nightmare for everyone.
> >
>
> I dispute that. Anyone who hard-coded “System32” in their application
> deserves whatever trouble they got. That lesson should have been
> learned quite clearly in 1994 with the System -> System32 transition.
>
> I guess that’s really the fundamental basis of my gripe. MANY of the
> decisions that were made in the 32/64 transition seemed to have been
> made in order to appease or enable bad programmers. You ended up
> making
> the system more complicated for the GOOD programmers by enabling and
> encouraging bad habits.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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

[Doron_Holan]

App compat shimming works to a certian degree, but it is not an absolute fix. Short term or long term does not matter in the face of profit. We are a for profit company after all and sometimes the bottom line wins out, sometimes it does not. Stuff like system32 on a 64 bit system seems like an easy thing to trash and beat up on, but really friggin smart people made that decision and understood what they were doing, both the pros and cons …if you think you can do a better job, please apply

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Dan Newton
Sent: Tuesday, February 16, 2010 5:24 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is Windows LP64?

Sure that works ok short term.

But long term everyone has to deal with new and surprising
inconsistencies.

Ideally app compatibility (for those who are unable to update said apps)
would be solved by tools like XP Mode.

> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-401580-
> xxxxx@lists.osr.com] On Behalf Of Doron Holan
> Sent: Wednesday, February 17, 2010 2:12 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Is Windows LP64?
>
> Two words rule all decisons here: app compat. That is windows’ bread
> and butter. Purity of design/architecture is usually 2ndary to ap
> compat. I can’t tell you how many times a broken LOB app in a fortune
> 500 company causes an app compat fire…
>
> d
>
> tiny phone keyboard + fat thumbs = you do the muth
>
>
>
> -----Original Message-----
> From: Tim Roberts
> Sent: Tuesday, February 16, 2010 2:14 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Is Windows LP64?
>
> Peter Wieland wrote:
> > The main point was to avoid surprising & confusing 32-bit
> applications which were recompiled to 64-bit applications. Chasing
> down every use of system32 within the code and changing it over to
> system64 would have been a nightmare for everyone.
> >
>
> I dispute that. Anyone who hard-coded “System32” in their application
> deserves whatever trouble they got. That lesson should have been
> learned quite clearly in 1994 with the System -> System32 transition.
>
> I guess that’s really the fundamental basis of my gripe. MANY of the
> decisions that were made in the 32/64 transition seemed to have been
> made in order to appease or enable bad programmers. You ended up
> making
> the system more complicated for the GOOD programmers by enabling and
> encouraging bad habits.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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

[OSR_Community_User]

Heh, fair point,

It’s a funny discussion actually because:

a) it is water under the bridge, whats done is done

and

b) for all the interesting things said about WOW64 it actually ‘just
works’ most of the time and is pretty transparent to the user

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-401585-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, February 17, 2010 2:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Is Windows LP64?

App compat shimming works to a certian degree, but it is not an
absolute fix. Short term or long term does not matter in the face of
profit. We are a for profit company after all and sometimes the bottom
line wins out, sometimes it does not. Stuff like system32 on a 64 bit
system seems like an easy thing to trash and beat up on, but really
friggin smart people made that decision and understood what they were
doing, both the pros and cons …if you think you can do a better job,
please apply

d

tiny phone keyboard + fat thumbs = you do the muth

-----Original Message-----
From: Dan Newton
> Sent: Tuesday, February 16, 2010 5:24 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Is Windows LP64?
>
>
> Sure that works ok short term.
>
> But long term everyone has to deal with new and surprising
> inconsistencies.
>
> Ideally app compatibility (for those who are unable to update said
> apps)
> would be solved by tools like XP Mode.
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-401580-
> > xxxxx@lists.osr.com] On Behalf Of Doron Holan
> > Sent: Wednesday, February 17, 2010 2:12 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Is Windows LP64?
> >
> > Two words rule all decisons here: app compat. That is windows’ bread
> > and butter. Purity of design/architecture is usually 2ndary to ap
> > compat. I can’t tell you how many times a broken LOB app in a
fortune
> > 500 company causes an app compat fire…
> >
> > d
> >
> > tiny phone keyboard + fat thumbs = you do the muth
> >
> >
> >
> > -----Original Message-----
> > From: Tim Roberts
> > Sent: Tuesday, February 16, 2010 2:14 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Is Windows LP64?
> >
> > Peter Wieland wrote:
> > > The main point was to avoid surprising & confusing 32-bit
> > applications which were recompiled to 64-bit applications. Chasing
> > down every use of system32 within the code and changing it over to
> > system64 would have been a nightmare for everyone.
> > >
> >
> > I dispute that. Anyone who hard-coded “System32” in their
> application
> > deserves whatever trouble they got. That lesson should have been
> > learned quite clearly in 1994 with the System -> System32
transition.
> >
> > I guess that’s really the fundamental basis of my gripe. MANY of
the
> > decisions that were made in the 32/64 transition seemed to have been
> > made in order to appease or enable bad programmers. You ended up
> > making
> > the system more complicated for the GOOD programmers by enabling and
> > encouraging bad habits.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > 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