Can't start 16-bit apps with OTVDM after uninstalling NTVDMx64 (As well as a few other issues)

[AngryDavid808]

Hello! I have a Windows 10 machine and I have recently installed NTVDMx64
It kept crashing with a different error code every time, so I uninstalled it through Control Panel.
I have set my machine to start 16-bit apps with otvdm, but now that I've uninstalled NTVDMx64, this error message appears instead:
"APP PATH HERE is a 16-bit application. You don't have permission to execute 16-bit applications. Contact your system Adminstrator."
Now, I am the adminstrator, but I still couldn't find my way out of this.
Also, for some reason, ldntvdm.dll is still in System32, and injected into winlogon.exe, and I honestly want to remove the injection and delete the file to get everything back to what it was before. How can I do this?
Thanks in advance.
Regards,
David

[leecher1337]

There was a bug in the uninstaller leaving the loader intact after uninstallation which was fixed in 7f12eff
To completely remove the loader, remove it from
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs key. after a reboot, you should be able to delete the ldntvdm.dll in System32 directory.

The loader should be compatible with OTVDM and give it precedence on 16bit Windows applications,if it is installed.

Out of interest, which errors did you get? It runs flawlessly here, so I wonder what problems occured on your machine. Did they occur in ntvdm.exe directly?

[AngryDavid808]

There was a bug in the uninstaller leaving the loader intact after uninstallation which was fixed in 7f12eff
To completely remove the loader, remove it from
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs key. after a reboot, you should be able to delete the ldntvdm.dll in System32 directory.

The loader should be compatible with OTVDM and give it precedence on 16bit Windows applications,if it is installed.

Out of interest, which errors did you get? It runs flawlessly here, so I wonder what problems occured on your machine. Did they occur in ntvdm.exe directly?

Well, to be honest, I can't remember what these errors exactly say, but I do remember that they give a different error code every single time, and my 16-bit apps as well as my DOS apps never start. And yes, same goes for ntvdm.exe directly, I tried to directly execute it before reinstalling Windows because of a BsoD with stop code 0x0000c1, I believe that was the stop code. Since I now know how to get rid of the injection, I may actually reinstall NTVDMx64 and try to capture some of these error for you.
Thank you for responding btw.

[leecher1337]

Sounds like ERROR_BAD_EXE_FORMAT. May be a problem with the loader. Which Windows version and which file date of the loader? Weird, I never managed to produce a BSOD with the loader yet...

Btw., 16bit support was only added recently (3 days ago), but also the old loader left 16bit apps alone so that they can be handled by otvdm (the new loader checks for the presence of OTVDM and if OTVDM is installed, it takes OTVDM, otherwise it handles it with NTVDM to not interfere with it).

The loader generally logs to DebugView console, so its log output may shed some light on the issue. Generally, the injection is somewhat time critical when injecting into console processes and therefore can be a bit unrealiable sometimes (the conhost methos still turned out to be the most reliable compared to other methods), however the AppInit-injection into windowed processes should be OK.

[AngryDavid808]

Sounds like ERROR_BAD_EXE_FORMAT. May be a problem with the loader. Which Windows version and which file date of the loader? Weird, I never managed to produce a BSOD with the loader yet...

Btw., 16bit support was only added recently (3 days ago), but also the old loader left 16bit apps alone so that they can be handled by otvdm (the new loader checks for the presence of OTVDM and if OTVDM is installed, it takes OTVDM, otherwise it handles it with NTVDM to not interfere with it).

The loader generally logs to DebugView console, so its log output may shed some light on the issue. Generally, the injection is somewhat time critical when injecting into console processes and therefore can be a bit unrealiable sometimes (the conhost methos still turned out to be the most reliable compared to other methods), however the AppInit-injection into windowed processes should be OK.

Thank you for your response.

I was and still am on Windows 10 Build 1909. Before I reinstalled Windows, I actually had a user-made registry problem that caused Windows to reboot with no errors right whenever it finishes the boot process. I tried to do a System Restore, and this BsoD started appearing. Note that I had the same problem I have now when I did that System Restore. Because of this, I'm actually kind of scared to update Windows 10 to Build 2004. As for which version of the loader, I don't quite know, I fetched a pre-built copy from columbia.edu.

Also, where can I find the latest pre-built version of NTVDMx64? I actually want to give it another shot before I remove the injection.

I honestly can't read debug logs, but if you want some, please tell me how I can send them over for you to take a look at it.

[leecher1337]

My current test machine is Windows 10 Build 1903 (I didn't get any offers for update yet, not even to 1909... Don't know why, it says,I'm on most current release).

Also, where can I find the latest pre-built version of NTVDMx64? I actually want to give it another shot before I remove the injection.
Most recent loaders can be found in this repo: https://github.com/leecher1337/ntvdmx64/tree/master/ntvdmpatch/release/ldntvdm

As for ntvdm executable and libraries, as I cannot provide them due to legal reasons, you either have to build them yourself using the minnt build instructions or wait, until columbia.edu updates their build. E. Mendelson usually updates the files within a few weeks after a new release here.

To get the debug logs, just download DebugView and let it run, the loader ldntvdm should spit out some log lines that you can copy as soon as you start an application. You can copy and paste them here together with an error description (possibly screenshot). I cannot promise that I can see something from it, but we can try at least.

[AngryDavid808]

My current test machine is Windows 10 Build 1903 (I didn't get any offers for update yet, not even to 1909... Don't know why, it says,I'm on most current release).

Maybe you can try downloading the Windows 10 Disc Images from microsoft.com and install the latest version using them. I used their Disc Images to reinstall Windows, so yeah, maybe you can try giving it a go in a VM and try testing NTVDMx64 on it.

[AngryDavid808]

Update on the situation:

So, I downloaded a pre-built version of NTVDMx64 from columbia.edu (Late April build), installed it with making sure that Avast is turned off and that the Windows folder is added as an exception in Avast. I directly start ntvdm.exe a few times, it gives me some error about preparing the environment every time. Now for some ducking reason, NTVDMx64 works just fine with no errors, and OTVDM started functioning like normal again. I absolutely have no idea how I did it, but it just happened. I suspect it was all Avast's fault since it kept detecting and deleting ldntvdm.dll from pretty much everywhere it existed on my computer. So yeah, all is working.... Except for Duke Nukem 3D, setup.exe throws an error. I'll send it tommorow when I get enough sleep.

[leecher1337]

Just to let you know: Starting ntvdm.exe directly must fail, that's not how it works. The whole loader is just there to prepare everything so that ntvdm can launch. Technically, the loader registers the next command to execute with the console host and when ntvdm.exe starts, it fetches the next command to execute from console host.

Antivirus programs are a real pest, I even tried to encrypt the loader, but it didn't help against these annoying AV-programs. And when I apply for a whitelisting with an AV-vendor, the drama starts again as soon as a new loader version is compiled.

Running games with NTVDMx64 won't make you very happy anyway, as the CCPU is just way too slow for an acceptable gaming experience, so I'd say you should resort to DosBox for gaming, which is highly optimized for this.

[AngryDavid808]

Indeed, I faced problems with the games that actually worked. And apps as well.

Sometimes any app I use (I tried EDIT and QBASIC) doesn't respond well to input, so it disregards some of the keys I press. Hope you know what I mean. As for Duke Nukem and Duke Nukem 2, they worked, but with slowdowns and no PC Speaker output, except for a long beep on Duke Nukem 2 (I use a laptop that has a PC Speaker in it). I also couldn't check Soundblaster in Duke Nukem 2's settings to get some music and sound output. Both games give me no audio output.

[AngryDavid808]

Alright! So, I finally had time to log what exactly is going on when starting Duke Nukem 3D's setup program, as well as the error itself. Both of them are inside this ZIP file here.

[leecher1337]

For music, you need to set the sound to Adlib (as stated in the readme).
I suspect you didn't read the readme file, otherwise you would have noticed the comment about PC Speaker output solution in there.

I never experienced any missed keystrokes, I cannot reproduce this no matter how fast I type.

[AngryDavid808]

I'm deeply sorry, nevermind about the keystroke problem. I felt it while using EDIT.exe, but now that I'm adapted to how it works, I don't feel it anymore. Btw, can I somehow maximize the window of whatever DOS app I'm using and stretch its display (sorry if that's not the correct expression), or put it in fullscreen mode?

[leecher1337]

There used to be the -EyeStrain[xx] parameter on non-x86 builds where [xx] is a hex-code from the list of VK_ keycodes for a key to be assigned to switch between 3 stretching modes (normal - medium - big) via a hotkey. This worked in NT/2k - times when the loader fetched the commandline to execute from cmdline regkey in WOW registry node, but as the newer loaders have harcoded ntvdm.exe in the kernelbase.dll the parameter cannot be specified this way anymore. I'll issue a little patch that will allow to read the parameter from the VDM environment regkey to enable this useful feature again, let's see, if it works.

The other sad history part is fullscreen: This used to work on Windows versions up to Windows 8, until Microsoft enforded their new WDDM Display driver model which doesn't allow direct hardware pass-through anymore and therefore fullscreen was effectively dead.
As Windows 7 supported both XPDDM and WDDM (no idea why they pulled XPDDM support in later Windows versions even though it worked on Windows 7), it was possible to use with some tricks on Win 7 x32. BUT: This functionality relies on IO permission bitmap and this isn't supported on 64bit Windows, so it still isn't possible on Windows 7 x64.
Fullscreen support would be ideal for gaming etc., as it would allow direct harware access to the card without having to do the slow VGA emulation, but sadly, it's not possible with the current Windows driver architecture.

[AngryDavid808]

Hey, I had a tiny question, thanks for all the help btw. ^^

How can I benefit from your last commitment? Thank you again in advance.

[leecher1337]

Compile it and try it out, it's not so complicated, there even is a video tutorial:
https://github.com/leecher1337/ntvdmx64/blob/master/ntvdmpatch/doc/minnt.txt

You can just update the ntvdm.exe in SysWOW64 directory, if you fear that your current setup will break again by uninstalling and reinstalling.

[peter8777555]

2020/06/02 PM 06:49 2,134,653 ntvdmx64-master.zip
MD5 : 11f76834a8c0f95a952a00e19bdafd39

Building OK.

[leecher1337]

@peter8777555 Did you test the new WOW32 part (16bit Windows support)? Would be interesting to hear if it works for you.

[peter8777555]

I have installed WineVDM on Windows 7 X64.

How to disable the WineVDM ? I do NOT want to uninstall WineVDM.

I have checked below

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NtVdm64\0OTVDM
"CommandLine"=" --ntvdm64: "%m" --ntvdm64-args: %c"
"InternalName"=""
"ProductName"=""
"ProductVersion"="*"
"MappedExeName"="K:\DOS\WineVDM\otvdmw.exe"

and

set WOWTRACE=C:\log.txt
set WOWLOGLVL=16

[leecher1337]

@peter8777555 If you do not want to use the .reg scripts from otvdm for install and uninstall, which will set and remove mentioned 0OTVDM key, just rename 0OTVDM to something different. In case you have the newest ldntvdm.dll loader installed (only the newest loader supports Win16, the old one just doesn't handle Win16 applications at all), it will then start NTVDM for wow16 after a reboot (or another event that causes the loader to inject where it checks presence of OTVDM)..
If you want to have OTVDM back, name the key back to 0OTVDM and reboot.

[peter8777555]

Step 1:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NtVdm64\0OTVDM
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\NtVdm64\0OTVDM

rename to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NtVdm64\1230OTVDM
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\NtVdm64\1230OTVDM

Step 2 :
UnInstall NTVDMX64 by Administrator.

Step 3 :
Install NTVDMX64 by Administrator.

---

Advanced INF Install

INF Install Failed。Reason: Access Deny。

---

OK

What is wrong ??
Which file access deny ??

Step 4 :

C:\Windows\SysWOW64

2020/06/03 PM 02:59 1,418,752 ntvdm.exe
2017/03/09 AM 12:52 14,336 ntvdm64.dll
2020/06/03 PM 02:59 15,872 ntvdmd.dll

OK : It can run ALL DOS program.
NG : It can NOT run ALL Windows 16 bit.

By the way,

set WOWTRACE=C:\log.txt
set WOWLOGLVL=16

No log.txt in C:\

[leecher1337]

Hm, access denied? Normally it should tell you which file or regkey it cannot install.
Unfortunately, there was a bug in all older NTVDMx64 versions which failed to remove the ldntvdm.dll loader. Therefore, please validate that the ldntvdm.dll loaders in system32 and syswow64 are both the most recent ones from this repository, if an old loader is still present, it will still start, but 16bit support won't work with it.
The set WOWTRACE obvisouly only works, if you issued the command in the same console you are later starting the 16bit app from, it's not a global setting, but I guess you know that. As you have troubles starting 16bit applications, it's clear that there is no log then, as they cannot be executed.
Also make sure that wow32.dll and user.exe from Windows installation got replaced by the ones from NTVDMx64 (compare file sizes and timestamp). These 2 files are still present in modern Windows versions and are basically stubs that need to be replaced by our versions.

If you still have an old loader present, please report, I might need to add a check to the install.bat then to give an option to remove the old loader code, if still present in system, as the problem may occur to all users who want to update. Not sure if Advanced Inf installer takes care of it, theoretically, it should.
As always, Debugview logs may be helpful for debugging loader output, in case it fails to start win16 applications.

[peter8777555]

I use Screen2Exe to demo(record) my problem.
Run Demo.exe

By the way,
2017/03/09 AM 12:52 16,384 ntvdm64.dll
Can i delete this file ?

Why install.bat no OVERWRITE with NEW version ?

Do i need copy C:\work\ntvdmpatch\releases\usa\wow32 C:\Windows\SysWOW64 ??

[leecher1337]

2017/03/09 AM 12:52 16,384 ntvdm64.dll
Can i delete this file ?

If you want to permanently ruin your chances to get otvdm working again, you may delete it. :-D
So as I guess you are as happy with winevdm as I am, no, please don't delete ntvdm64.dll

Install.bat should move the wow32.dll and user.exe to a backup location after doing a takeown /f on them so that they can be replaced by the Advanced Inf installer. That's why you got "Access denied", I suppose, as takeown and move didn't work for whatever reason.
Unfortunately, as I had to test my wow32, I already had these files removed and therefore there wasn't an error hit in my install tests in the test VM. That's why it's always good if more people test to find such problems.
See here:
wow32.inf

[InstallCmdsPre]
%10%\Symbols\instntvdmx64.bat instwow "%16425%" "%10%\Symbols\Backup"

install.bat

:instwow
md %3
takeown /f %2\wow32.dll
move %2\wow32.dll %3\
takeown /f %2\user.exe
move %2\user.exe %3\

Maybe install.bat can be modified to log the result of the commands to find out why moving these file doesn't work. I guess I need to install a fresh VM to reproduce the problem myself, or do you have an idea?

What I also saw in your demo is that there are a lot of questions whether to overwrite the files in syswow64. Did you just reinstall without uninstalling (which is OK in this case), or does my uninstallation routine fail to remove these files (not a real problem, but for the sake of cleanness...)?

[peter8777555]

I overwrite wow32.dll and user.exe to C:\Windows\SysWOW64

Run ALL Win16 programs always error

---

File Error

Cannot find NETWORK.DRV

Close(C)

[leecher1337]

Cannot find NETWORK.DRV

Close(C)

Thank you for the hint, I completely forgot to add the contents of wow2.reg to the .inf file. Of course that also didn't occur on my test VM as entries were already there. I will fix this shortly

[peter8777555]

So as I guess you are as happy with winevdm as I am

What I also saw in your demo is that there are a lot of questions whether to overwrite the files in syswow64.

Did you just reinstall without uninstalling (which is OK in this case), or
does my uninstallation routine fail to remove these files (not a real problem, but for the sake of cleanness...)?

Yes,i am happy with WineVDM.

I always
copy C:\work\ntvdmpatch\releases\usa\dos C:\Windows\System32
copy C:\work\ntvdmpatch\releases\usa\dos C:\Windows\SysWOW64

I UnInstall NTVDMX64 then Install NTVDMX64.

STRONG SUGGESTION:
Install.bat always OVERWRITE with new version.

[peter8777555]

NTVDMX64 for DOS program.
WineVDM for Win16 program.
So my OLD PC(over 10 years) on Windows 7 X64 can run DOS16/Win16/Win32/Win64 program.
Great :-D

[peter8777555]

By the way,

It can NOT work.

ren c:\windows\system32\ldntvdm.dll c:\windows\system32\ldntvdm.bak

C:>ren/?
RENAME [drive:][path]filename1 "filename2".
REN [drive:][path]filename1 "filename2".

It MUST below
ren c:\windows\system32\ldntvdm.dll ldntvdm.bak

It can work.

[AngryDavid808]

Well, I discovered something new. (I'm still using the version form columbia.edu btw.)
I had a setup for a demo of a DOS game called F-22 Lightning II lying around in my computer. So, I thought of giving that setup program a shot. And this picture shows what I got. Everything functions fine (supposedly), however, the graphics are beyond messed up. I attached the files as well so you can test things yourself.

F22Demo.zip

[AngryDavid808]

Heya! Long time no see!
There is one last issue I wanted to address.
The NTVDM loader seems to be causing trouble with Windows Updates on Windows 7. Since I have BypassESU installed on my computer, I recieve monthly security updates for Windows 7. The thing is, for as long as NTVDMx64 is installed, the update will always fail until I uninstall it, remove the injection if it's still there, and then restart the computer, only then the update will succeed. I suspect it has something to do with the fact that the loader uses critical system files, thus, the update cannot be completed because these files cannot be modified as they're being used by the loader.
Is there a way to solve this problem without going through the trouble of uninstalling NTVDM and reinstalling it after the update? Many thanks in general.

[leecher1337]

Hi,

The loader just does in-memory patches, so it shouldn't "lock" a system file. To find out the reason, have you checked the windows\Windowsupdate.log protocol file to find out the exact error you are getting?
Did you also check windows\Logs\CBS\CBS.log protocol?

Please provide a download link to a Windows update package that fails to install so that I can try to reproduce the problem.

Regards

[AngryDavid808]

Righty-O! Here's a link to the package I'm trying to install, just make sure you have BypassESU v7 installed properly on Windows 7 before executing the package: https://www.catalog.update.microsoft.com/Search.aspx?q=4571729
I checked the Windows Update log and pasted the important part of it here: https://pastebin.pl/view/1dc59f6a
CBS.zip I also attached the entire CBS log for you to take a look at it, just remember to run Notepad as adminstrator so you can read the file.

[AngryDavid808]

WU-Log.zip Here's the full WU log in case you need more information.

[AngryDavid808]

Hello, @leecher1337. It seems that it's been 20 days since I last contacted you, but I didn't hear back from you about the problem yet. Could you please update me about the situation? Thanks in advance!

[leecher1337]

I'll let you know if I find a solution to your problem.

[AngryDavid808]

Thank you! I'll be waiting, good luck! But please, when you fix it, release the new update as a major one, so the version that's on columbia.edu gets updated as well.

[AngryDavid808]

YES! I've been waiting for this! Thank you so much, man! You are awesome.

[AngryDavid808]

Ok, I finally found a way to build it. Though, the CMD window errored out twice about a cmdline that's not recognizable or in other words does not exist. Otherwise, everything went ok. 16-bit support works, DOS programs also work just fine, however, when I close any DOS program, NTVDM.exe just stops working every time, which is not fatal, but it's pretty annoying since an error pops up every single time. Also the F22 Demo setup graphics issue is still not fixed.

[leecher1337]

F22 installer definitely works:

Maybe you have an old source or library sticking around? The bug was fixed in ca95541

The crash of the ntvdm.exe process is weird, maybe a compilation issue, as you said you had issues with compiling? Which errors did you specifically get?

[AngryDavid808]

Once I reinstall the version I compiled, I'll get back to you with that specific error. Just gimme 15 minutes.

[AngryDavid808]

So, these are the errors I've been getting when installing.

I downloaded every specific file required this time, did everything correctly, building went ok, and it doesn't seem like it's working for me at all.
By the way, this is the tutorial I used by Enderman: https://www.youtube.com/watch?v=unU7uyFJWmo
I used a freshly installed Windows XP 32-bit VM, and did every exact step properly. And yes, I downloaded the latest version of NTVDMx64. Hope you can help me with this issue it's now pissing me off instead of just puzzling my mind.

[leecher1337]

Ah, ok, the error during install can be ignored, it's just a try to add an exclution for Windows Defender for the loaders. If you are using another Antivirus solution or not having Windows defender, the commands will fail, but that's no problem.

Quoting readme.txt regarding old-src build:

   This has been the default repository until Feb/2020 where 
   development has been switched to MINNT tree.
   This build method therefore is DEPRECATED in favour of the 
   MINNT build systemand will not receive any future updates!
   This build is left unmaintained and unchecked, so don't complain
   if it doesn't build anymore.

I'm not maintaining old-src build anymore, it doesn't get tested and lacks newer patches, therefore please use MINNT build instead. MINNT is also building faster and you don't have a requirement for a Windows XP build machine.
MINNT build instructions also link to a youtube video by me showing the build process like Enderman's tutorial.

So please try MINNT build instead.

[AngryDavid808]

Ah, so should I copy the minnt files in and go with bld-minnt instead of just bld while building? At least I now know that I'm kinda on the right path.

[AngryDavid808]

So I got stuck, again. This time at the sizzle_minnt.cmd part. The build shell wouldn't just open and these errors just pop up. Can't believe I have to start everything over.
Please help me out. Thanks in advance.

[leecher1337]

Please read the readme:

Please ensure that your build root is in a directory with a very short path 
length, otherwise the build process will fail.
So i.e. C:\WORK
Alternatively, map the build root to a seperate drive letter, i.e. W: with
subst W: .

I should add that blanks in the directory path are also a very bad idea, so I suggest you go with the suggestions of c:\WORK as build directory.

[AngryDavid808]

Oh, okie, thanks. I did read the steps btw. Guess I'll just start over.

[AngryDavid808]

Alright. I finally managed to build it correctly 100% this time with no errors whatsoever, the F22 demo installer issue was fixed, which indicates that everything has been done correctly. However, the Windows 7 Update issue is still present, it still fails while NTVDMx64 is installed. So yeah, good job! Many thanks for the update! 👌👌👌
I still hope you can find another workaround for the Windows Update problem. I'm trying to install the 2020-10 security rollup update.

[kristibektashi]

There used to be the -EyeStrain[xx] parameter on non-x86 builds where [xx] is a hex-code from the list of VK_ keycodes for a key to be assigned to switch between 3 stretching modes (normal - medium - big) via a hotkey. This worked in NT/2k - times when the loader fetched the commandline to execute from cmdline regkey in WOW registry node, but as the newer loaders have harcoded ntvdm.exe in the kernelbase.dll the parameter cannot be specified this way anymore. I'll issue a little patch that will allow to read the parameter from the VDM environment regkey to enable this useful feature again, let's see, if it works.

The other sad history part is fullscreen: This used to work on Windows versions up to Windows 8, until Microsoft enforded their new WDDM Display driver model which doesn't allow direct hardware pass-through anymore and therefore fullscreen was effectively dead. As Windows 7 supported both XPDDM and WDDM (no idea why they pulled XPDDM support in later Windows versions even though it worked on Windows 7), it was possible to use with some tricks on Win 7 x32. BUT: This functionality relies on IO permission bitmap and this isn't supported on 64bit Windows, so it still isn't possible on Windows 7 x64. Fullscreen support would be ideal for gaming etc., as it would allow direct harware access to the card without having to do the slow VGA emulation, but sadly, it's not possible with the current Windows driver architecture.

This makes me wonder. is full screen mode possible on Windows 10 32-bit if DWM.exe is disabled? This is doable by renaming the file alongside sihost.exe, replacing with stubs (rundll32.exe works great for this purpose), enabling console login (by deleting a dll file in system32) and rebooting. Note: this breaks UWP apps

[leecher1337]

No, it's not about some usermode goo, but it's in the kernel. There simply is no support for XPDM anymore in the kernel, only WDDM, and WDDM doesn't expose all necessary functions / IOCTLS for it, as this would be incompatible with using the GPU accelleration that Windows uses nowadays, as far as I understand.
Windows 7 kernel still had support for XPDM, but even there, it depended on the quality of the underlying WDDM driver.
For example, some Intel Video drivers were sometimes unable to restart, if you stopped them (and thus switched back to XPDM display driver, which normally is just the standard VGA driver shipped with Windows). Other display drivers worked quite well with just restarting them at runtime.
But XPDM is just gone from newer kernel and there sadly goes the NTVDM fullscreen support.

Here are some links about it:
http://support.microsoft.com/kb/926657
https://colinxu.wordpress.com/2011/02/18/cmd-prompt-can-be-full-screen-again-in-windows-7-%E2%80%93-an-explanation-of-why-windows-7-doesnt-support-cmd-prompt-full-screen-mode-and-an-issue-analysis/

It seems that the rason for hte XPDM support in Win 7 mainly was that they could still use the classic VGA driver an starting with Windows 8, they wrote a WDDM VGA driver and therefore cut off XPDM support from kernel completely, as it was not necessary anymore in their view (leaving behind p*ssed DOS users, but as usual, they don't care).

And as mentioned, you would still have the problem with the IO permission bitmap on x64 versions of Windows, which was no issue an i386 and there also is no solution for it in the kernel (even not on Windows XP x64), as x64 Windows was never meant to run NTVDM and therefore nobody had to think about a solution to this problem anyway.