VOGONS


NTVDM on windows 10 x64

Topic actions

First post, by leecher

User metadata
Rank Newbie
Rank
Newbie

I just wanted to announce that I managed to compile and patch Microsoft Windows NTVDM on 64bit Windows and it seems to work at least for realmode applications and even supports console graphics.
This might become handy for users that want to benefit from the good console and shell integration of NTVDM compared to DosBox (i.e. run 32bit console programs from DOS-applications).
In case you are interested, take a look at https://github.com/leecher1337/ntvdmx64
Maybe some of you are interested to further improve the port (i.e. the DPMI stuff still needs some work).

Regards

Reply 1 of 60, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I guess that's kind of neat, but its reliance on stolen code might make it of dubious utility and I doubt Microsoft will be persuaded to included it in future versions (especially since "the DPMI stuff still needs some work"). Why exactly doesn't this work on Windows 7 or 8? And does it run 16-bit Windows programs?

Reply 2 of 60, by leecher

User metadata
Rank Newbie
Rank
Newbie

Yeah, it's just a proof-of-concept, that's why I just published patches and nothing more to ensure that there are no legal problems with the release itself.
I guess that the DPMI stuff is fixable, it was just too frustrating to debug without yoda.

It works on Windows 10 because I tested it there and some API calls and internal structs used in the loader code may be a bit different there, but it wouldn't be too hard to port, I guess, I just didn't know if it is necessary to port it to older Windows versions.
No WOW-Support for 16bit Windows, that would be too much work for a simple PoC.

Reply 3 of 60, by collector

User metadata
Rank l33t
Rank
l33t

Very interesting. Too bad about WOW, but understand about too much work. Certainly would be nice for those 16-bit installers.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 4 of 60, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

More specifically, it's a set of patches to the sourcecode of original Microsoft NTVDM from NT4 in order to work on 64bit Windows.

This is a serious problem. Eventually, all of Microsoft's code would have to be rewritten from scratch.

Reply 5 of 60, by Stiletto

User metadata
Rank l33t
Rank
l33t
Azarien wrote:

More specifically, it's a set of patches to the sourcecode of original Microsoft NTVDM from NT4 in order to work on 64bit Windows.

This is a serious problem. Eventually, all of Microsoft's code would have to be rewritten from scratch.

eh? I'm not sure you understand this thread. How is the inability for compiled illegal leaked Windows NT4 sourcecode to work in 64bit Windows a serious problem?

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 6 of 60, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
Stiletto wrote:

eh? I'm not sure you understand this thread. How is the inability for compiled illegal leaked Windows NT4 sourcecode to work in 64bit Windows a serious problem?

As I understand, he is trying to reuse leaked and modified NT4 code on Windows 10. This is asking for legal problems, and if this project is going anywhere it should focus solely on writing new code.

Reply 7 of 60, by Stiletto

User metadata
Rank l33t
Rank
l33t
Azarien wrote:
Stiletto wrote:

eh? I'm not sure you understand this thread. How is the inability for compiled illegal leaked Windows NT4 sourcecode to work in 64bit Windows a serious problem?

As I understand, he is trying to reuse leaked and modified NT4 code on Windows 10. This is asking for legal problems, and if this project is going anywhere it should focus solely on writing new code.

oh, hah, I misunderstood you. Quite amazingly, too. My bad.

Well... he's not distributing compiled binaries and the sourcecode he's released is just a patch upon the illegal source, so it's about as legal as it can get in this situation. Still, I largely agree with you. It's a neat hack, but also troubling.

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 8 of 60, by leecher

User metadata
Rank Newbie
Rank
Newbie

I now managed to get it working on Windows 7.
Additionally I wanted to work on WOW16, I got it so far that i can convert 16bit to 32bit calls, but unfortunately the 16bit appliations crash randomly mustly during startup. As there is no reproducable pattern behind it, this is pretty hard to debug. Maybe a bug with memory management, der LDT or even the CCPU?
Is there any experienced programmer willing to help me with this?

Reply 9 of 60, by filipetolhuizen

User metadata
Rank Oldbie
Rank
Oldbie
leecher wrote:

I now managed to get it working on Windows 7.
Additionally I wanted to work on WOW16, I got it so far that i can convert 16bit to 32bit calls, but unfortunately the 16bit appliations crash randomly mustly during startup. As there is no reproducable pattern behind it, this is pretty hard to debug. Maybe a bug with memory management, der LDT or even the CCPU?
Is there any experienced programmer willing to help me with this?

Well, I don't know if it helps, but I'd be happy to test it. And congrats for your breakthrough.

Reply 10 of 60, by leecher

User metadata
Rank Newbie
Rank
Newbie

Hi,
If you are interested in the DOS-part, you can download it from the project page. emendelson also made a build publically availabe in the issue tracker issue #7.
For WOW16, this implements a cooperative multitasking scheduler, but the scheduling doesn't take place in NTVDM, but is issued to the kernel scheduler, i.e. by invoking NtYieldExecution() syscall. Now I think the problem is that NTVDM on x64 in turn already runs in WOW32 and therefore it may be incapable of doing the scheduling of a WOW16 process (WOW32 i.e. also usees the WOW-Structure offset in the TEB for its stuff already so that I have to use another TLS-Pointer for Wow16 stuff).
So I guess there is no scheduling taking part leading the CCPU to concurrently execute 2 threads at the same time causing random crashes. The interaction with the scheduler is not so easy to understand, I'm not sure if cooperative scheduling on the CCPU would be possible without relying on the mechanisms of the kernel task scheduler...
Did someone take a look at this how it works?

Reply 11 of 60, by truemaster

User metadata
Rank Newbie
Rank
Newbie

good job i installed it on win10 x64 and it works. not good as 32bit but works. the only problem is the antivirus the zip archives are ok but after install even if i open the powershell on standar cmd the commant line closes imediatly and the antivirus says blocked malicious attemp. looks like someone didnt wont that patch to go on.

Reply 12 of 60, by leecher

User metadata
Rank Newbie
Rank
Newbie

I recently switched from CreateProcess() hooking propagation to injection via conhost.exe
This is because CreateProcess hooks were a bit unstable with certain applications. However the loader sourcecode still supports both injection mechanisms.
Seems that some stupid antivirus products mistakenly see the DLL injection as malicious. If it helps, I could make both injection methods configurable, i.e. via registry key.
It may help to switch to an Antivirus software that is only signature-based and does not do behavioural detection, as it cannot know if injected DLL is malicious or not and therefore assumes the worst.

Reply 14 of 60, by leecher

User metadata
Rank Newbie
Rank
Newbie

It just means that, if everything works so far, the "release\" subdirectory should contain all the files needed for the installation package, so chdir to the releae directory and put its contente i.e. in a .zip file and you should have a complete package containing installer and files.