I’m writing an app that provides a simple DOS environment for 32bit DOS programs. It works to some degree on 32bit XP and Vista, but not on 64bit Vista.
The problem is I need to mess with the Local Descriptor Table. I’m using NtSetInformationProcess with class ProcessLdtInformation. On 64bit Vista that returns STATUS_NOT_IMPLEMENTED.
I’m guessing this can be done with a Device Driver, but the big problem is I’ve never written one before.
Does anyone here know of any already exisiting driver that does something like this? Or could someone give me a few pointer as to how to go about it. I’ve used the NTDDK briefly before to write a VDD so I have the tools, I think. The sort of thing that’s worrying me is how to mantain the LDT on process swaps (Will the OS do that anyway, or is there a sort of “process local storage” I can put it in? - perhaps that makes no sense at all).
Anyway, I’d really appreciate any clues.
It is illegal to modify the LDT (or IDT or GDT, etc) on 64 bit Vista.
–
Jonathan Morrison
wrote in message news:xxxxx@ntdev…
> I’m writing an app that provides a simple DOS environment for 32bit DOS
> programs. It works to some degree on 32bit XP and Vista, but not on 64bit
> Vista.
>
> The problem is I need to mess with the Local Descriptor Table. I’m using
> NtSetInformationProcess with class ProcessLdtInformation. On 64bit Vista
> that returns STATUS_NOT_IMPLEMENTED.
>
> I’m guessing this can be done with a Device Driver, but the big problem is
> I’ve never written one before.
>
> Does anyone here know of any already exisiting driver that does something
> like this? Or could someone give me a few pointer as to how to go about
> it. I’ve used the NTDDK briefly before to write a VDD so I have the tools,
> I think. The sort of thing that’s worrying me is how to mantain the LDT
> on process swaps (Will the OS do that anyway, or is there a sort of
> “process local storage” I can put it in? - perhaps that makes no sense at
> all).
>
> Anyway, I’d really appreciate any clues.
>
Jonathan Morrison wrote:
It is illegal to modify the LDT (or IDT or GDT, etc) on 64 bit Vista.
In what sense illegal? I can see that changing the IDT or GDT would be
very dangerous, but in other versions of Windows, the LDT is unused
and hence free for use by the app. What is it about 64bit Windows
that makes playing with the LDT a taboo?
Cheers,
Paul.
Paul Gardiner wrote:
Jonathan Morrison wrote:
> It is illegal to modify the LDT (or IDT or GDT, etc) on 64 bit Vista.
In what sense illegal? I can see that changing the IDT or GDT would be
very dangerous, but in other versions of Windows, the LDT is unused
and hence free for use by the app. What is it about 64bit Windows
that makes playing with the LDT a taboo?
I just found this:
http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx, which
discusses one of the kernel protection mechanisms. The Answer to the 5th
question from the bottom specifically mentions IDT and GDT, but doesn’t
mention LDT. Could it be that the LDT is free to be altered?
I can’t easily just give up on this. I have no other way to make my
virtual DOS enviroment work. Its essential to have control of the LDT.
Cheers,
Paul.
Paul Gardiner wrote:
I just found this:
http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx, which
discusses one of the kernel protection mechanisms. The Answer to the 5th
question from the bottom specifically mentions IDT and GDT, but doesn’t
mention LDT. Could it be that the LDT is free to be altered?
I can’t easily just give up on this. I have no other way to make my
virtual DOS enviroment work. Its essential to have control of the LDT.
You understand that Win64 systems are not able to run 16-bit code at
all? I know you said your environment was designed to run 32-bit DOS
programs, but most 32-bit DOS programs use a 16-bit stub loader to load
the DOS extender. Those loaders will not work in Win64.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
Paul Gardiner wrote:
> I just found this:
> http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx, which
> discusses one of the kernel protection mechanisms. The Answer to the 5th
> question from the bottom specifically mentions IDT and GDT, but doesn’t
> mention LDT. Could it be that the LDT is free to be altered?
>
> I can’t easily just give up on this. I have no other way to make my
> virtual DOS enviroment work. Its essential to have control of the LDT.
You understand that Win64 systems are not able to run 16-bit code at
all? I know you said your environment was designed to run 32-bit DOS
programs, but most 32-bit DOS programs use a 16-bit stub loader to load
the DOS extender. Those loaders will not work in Win64.
My program is the loader. Its kind of a replacement for DOS/4GW, but
its a win32 program not a DOS one. Hence the stub is never executed.
The initial client program I’m targetting has one small piece of
realmode code which my enviroment gets asked to hang on the realmode
keyboard interrupt vector, but I don’t ever have to call that because it
also hooks the protected mode vector. That just gives my environment the
choice of two entry point to choose when informing the client program of
keyboard events, and of course I make it choose the protected mode one.
Besides that, everything in the client programs I’m considering is
32bit.
VDos32 is mostly working. I’ve had people test it on Vista with no
problems, where there is no DOS support. My only problem is on
64bit systems where I can’t find a way to access the LDT.
In fact it should be possible even to run 16bit code on win64, if
only the LDT can be accessed. The only hard limitation in the CPUs
is that V86 mode is missing, so realmode addressing cannot be handled.
That is why a general purpose virtual DOS enviroment cannot be created.
But what I’m trying to do should be fine.
Cheers,
Paul.
Paul Gardiner wrote:
My program is the loader. Its kind of a replacement for DOS/4GW, but
its a win32 program not a DOS one. Hence the stub is never executed.
The initial client program I’m targetting has one small piece of
realmode code which my enviroment gets asked to hang on the realmode
keyboard interrupt vector, but I don’t ever have to call that because
it also hooks the protected mode vector. That just gives my
environment the choice of two entry point to choose when informing the
client program of keyboard events, and of course I make it choose the
protected mode one. Besides that, everything in the client programs
I’m considering is 32bit.
VDos32 is mostly working. I’ve had people test it on Vista with no
problems, where there is no DOS support. My only problem is on
64bit systems where I can’t find a way to access the LDT.
Well, the official word, presented earlier today, is that there is no
“legitimate” way to do this. They have removed those interfaces from
the kernel.
Now, they can’t prevent a kernel driver from executing the lldt
instruction directly, but there is no guarantee that it will survive a
task switch. That is really the key problem.
In fact it should be possible even to run 16bit code on win64, if
only the LDT can be accessed. The only hard limitation in the CPUs
is that V86 mode is missing, so realmode addressing cannot be handled.
The x64 chips certainly DO have v86 mode. Without it, you couldn’t run
Win32 on an x64 chip. What you’re lacking is operating system support
for v86 mode in the Win64 systems.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
Well, the official word, presented earlier today, is that there is no
“legitimate” way to do this. They have removed those interfaces from
the kernel.
Now, they can’t prevent a kernel driver from executing the lldt
instruction directly, but there is no guarantee that it will survive a
task switch. That is really the key problem.
Yeah, that’s what I’m wondering. Could I not detect task switching in
the driver, and keep setting the lldt for the process(es) concerned?
> In fact it should be possible even to run 16bit code on win64, if
> only the LDT can be accessed. The only hard limitation in the CPUs
> is that V86 mode is missing, so realmode addressing cannot be handled.
The x64 chips certainly DO have v86 mode. Without it, you couldn’t run
Win32 on an x64 chip. What you’re lacking is operating system support
for v86 mode in the Win64 systems.
Yes, sorry, clearly it does, but you really cannot use it. V86 isn’t
really a mode its a possible attribute of protected mode tasks. On
64bit OSes, you don’t get to use protected mode for 32bit apps. Instead
you use the 64bit mode’s compatibility sub-mode, and that doesn’t
support V86.
Cheers,
Paul.
Paul Gardiner wrote:
Tim Roberts wrote:
>
> Now, they can’t prevent a kernel driver from executing the lldt
> instruction directly, but there is no guarantee that it will survive a
> task switch. That is really the key problem.
Yeah, that’s what I’m wondering. Could I not detect task switching in
the driver, and keep setting the lldt for the process(es) concerned?
I’m not sure you can hook task switching, or that you would want to.
However, it may not be necessary. I don’t have a Win64 system alive
right now to check, but there may already be an empty LDT set up. You
should do an sldt and see what you find. You may be able to just write
the entries yourself.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
I’m not sure you can hook task switching, or that you would want to.
However, it may not be necessary. I don’t have a Win64 system alive
right now to check, but there may already be an empty LDT set up. You
should do an sldt and see what you find. You may be able to just write
the entries yourself.
I hope there is!! I guess I need a Win64 system here. I have an AMD64
based machine running 32bit XP. Do you know if VMWare running on win32
can host win64? I could maybe buy a copy of XP x64 edition, in the
hope that whatever works with that will work with 64bit Vista.
Also, do you think I can get away with writing an NT4-style legacy
driver as describer in http://www.catch22.net/tuts/kernel1.asp ?
I’m guessing what I want to do is actually fairly simple - as far
as device drivers go - so I’d hope I wouldn’t need to worry about
PNP and power management.
Anyway, thanks: that’s a great help.
Cheers,
Paul.
> based machine running 32bit XP. Do you know if VMWare running on win32
can host win64?
Last time I checked - no.
Some time ago I posted some related info here, the important thing
being that older AMD64s are not supported.
In other words, need 64 bit vm? Get a newer processor (3500+?
AMD Athlon 64, revision D or later? something like that) and an x64
host.
Oh, here it is:
http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=1901&sliceId=SAL_Public
While we are here: I do not remember what goes on with
MS Virtual Server in this case.
----- Original Message -----
From: “Paul Gardiner”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 24, 2006 5:13 AM
Subject: Re: [ntdev] LDT access in 64bit Vista
> Tim Roberts wrote:
>> I’m not sure you can hook task switching, or that you would want to.
>>
>> However, it may not be necessary. I don’t have a Win64 system alive
>> right now to check, but there may already be an empty LDT set up. You
>> should do an sldt and see what you find. You may be able to just write
>> the entries yourself.
>
> I hope there is!! I guess I need a Win64 system here. I have an AMD64
> based machine running 32bit XP. Do you know if VMWare running on win32
> can host win64? I could maybe buy a copy of XP x64 edition, in the
> hope that whatever works with that will work with 64bit Vista.
>
> Also, do you think I can get away with writing an NT4-style legacy driver
> as describer in http://www.catch22.net/tuts/kernel1.asp ?
> I’m guessing what I want to do is actually fairly simple - as far
> as device drivers go - so I’d hope I wouldn’t need to worry about
> PNP and power management.
>
> Anyway, thanks: that’s a great help.
>
> Cheers,
> Paul.
>
>
>
> —
> 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
Paul Gardiner wrote:
Tim Roberts wrote:
>
> However, it may not be necessary. I don’t have a Win64 system alive
> right now to check, but there may already be an empty LDT set up. You
> should do an sldt and see what you find. You may be able to just write
> the entries yourself.
I hope there is!! I guess I need a Win64 system here.
I assumed you already had one. How did you even know this would be a
problem?
I have an AMD64
based machine running 32bit XP. Do you know if VMWare running on win32
can host win64?
No. A Win64 host can run a Win32 guest, but not vice versa. VMware
does not do instruction-level simulation.
Also, do you think I can get away with writing an NT4-style legacy
driver as describer in http://www.catch22.net/tuts/kernel1.asp ?
I’m guessing what I want to do is actually fairly simple - as far
as device drivers go - so I’d hope I wouldn’t need to worry about
PNP and power management.
This is all just for research for your doctoral thesis, right? You
aren’t actually planning to release this into the wild? If so, then a
legacy-style driver is just fine.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
No, 32bit XP cannot host 64bit in a VMWare machine.
-Jeff
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Paul Gardiner
Sent: Tuesday, October 24, 2006 5:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] LDT access in 64bit Vista
Tim Roberts wrote:
I’m not sure you can hook task switching, or that you would want to.
However, it may not be necessary. I don’t have a Win64 system alive
right now to check, but there may already be an empty LDT set up. You
should do an sldt and see what you find. You may be able to just
write
the entries yourself.
I hope there is!! I guess I need a Win64 system here. I have an AMD64
based machine running 32bit XP. Do you know if VMWare running on win32
can host win64? I could maybe buy a copy of XP x64 edition, in the
hope that whatever works with that will work with 64bit Vista.
Also, do you think I can get away with writing an NT4-style legacy
driver as describer in http://www.catch22.net/tuts/kernel1.asp ?
I’m guessing what I want to do is actually fairly simple - as far
as device drivers go - so I’d hope I wouldn’t need to worry about
PNP and power management.
Anyway, thanks: that’s a great help.
Cheers,
Paul.
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
“sh_alex” wrote in message news:xxxxx@ntdev…
>> based machine running 32bit XP. Do you know if VMWare running on win32
>> can host win64?
> Last time I checked - no.
Yes it can - if the host is x64 and has hardware virtualization support.
A little utility is available on VMware site to test whether the host it capable
to run x64 guests. The host OS can be 32 bit.
Regards,
–PA
> The host OS can be 32 bit.
You are right, I was wrong: it is possible to run a 64-bit guest on a
32-bit host.
Do you happen to know whether it’s true for Virtual Server?
I mean, 64 bit guest on a 32 bit host (possibly, on a right hw)?
It looks like the answer is “no”, I even found that
“Virtual Server 2005 R2 … does not currently … support 64-bit guest
operating systems. Microsoft seems to be holding off 64-bit virtual
machine support until its Windows Server Virtualization product is
ready - sometime within the next two years or so.”
at
http://weblog.infoworld.com/virtualization/archives/2006/08/server_virtuali.html
Any idea whether this is still true?
----- Original Message -----
From: “Pavel A.”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 24, 2006 10:20 PM
Subject: Re:[ntdev] LDT access in 64bit Vista
> “sh_alex” wrote in message news:xxxxx@ntdev…
>>> based machine running 32bit XP. Do you know if VMWare running on win32
>>> can host win64?
>> Last time I checked - no.
>
> Yes it can - if the host is x64 and has hardware virtualization support.
> A little utility is available on VMware site to test whether the host it
> capable
> to run x64 guests. The host OS can be 32 bit.
>
> Regards,
> --PA
>
>
>
>
> —
> 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
sh_alex wrote:
> based machine running 32bit XP. Do you know if VMWare running on win32
> can host win64?
Last time I checked - no.
Some time ago I posted some related info here, the important thing
being that older AMD64s are not supported.
In other words, need 64 bit vm? Get a newer processor (3500+?
AMD Athlon 64, revision D or later? something like that) and an x64
host.
Oh, here it is:
http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=1901&sliceId=SAL_Public
That seems to suggest that some 64bit CPUs don’t support selectors at
all. Can that be right? Would certainly prevent what I’m wanting to do.
Cheers,
Paul.
Tim Roberts wrote:
Paul Gardiner wrote:
> I hope there is!! I guess I need a Win64 system here.
I assumed you already had one. How did you even know this would be a
problem?
I had some people offer to test VDos32 under Vista. The first few
reports back said it worked fine, but they were trying it on 32bit
Vista. Then someone tried 64bit Vista and reported the error
coming back from NtSetInformationProcess.
This is all just for research for your doctoral thesis, right? You
aren’t actually planning to release this into the wild? If so, then a
legacy-style driver is just fine.
Hmmm, no I intend to distribute this. What type of driver should I
write? This could easily be the only one I ever write, so I’m hoping to
avoid the need to understand every little detail. I quite like the idea
of a framework that automatically gives reasonable defaults for most
of the entry points.
Cheers,
Paul.
Paul Gardiner wrote:
Tim Roberts wrote:
> This is all just for research for your doctoral thesis, right? You
> aren’t actually planning to release this into the wild? If so, then a
> legacy-style driver is just fine.
Hmmm, no I intend to distribute this.
64-bit drivers have to be digitally signed. That’s yet another
pain-in-the-rear for you to handle.
What type of driver should I write? This could easily be the only one
I ever write, so I’m hoping to avoid the need to understand every
little detail. I quite like the idea of a framework that automatically
gives reasonable defaults for most of the entry points.
In the DDK, check out the src\general\ioctl sample. If you have
downloaded KMDF, check out the “nonpnp” sample. Both are simple legacy
drivers that demonstrate how to handle ioctls from user mode.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Paul Gardiner wrote:
sh_alex wrote:
>
> Oh, here it is:
> http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=1901&sliceId=SAL_Public
That seems to suggest that some 64bit CPUs don’t support selectors at
all. Can that be right? Would certainly prevent what I’m wanting to do.
What it says is that selectors are not supported “in long mode”. None
of the 64-bit CPUs use selectors at all in 64-bit mode. CS, DS, ES, FS,
GS, and SS are ignored.
However, all of them (even Itanium) support segmentation in 32-bit mode,
exactly like a Pentium. If your virtual DOS product is a 32-bit app,
then it will have a GDT available.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Was one of the first AMD64 CPUs, so