Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Breaks Command Prompt in Creators Update #4

Closed
hifihedgehog opened this issue Apr 2, 2017 · 8 comments
Closed

Breaks Command Prompt in Creators Update #4

hifihedgehog opened this issue Apr 2, 2017 · 8 comments
Labels

Comments

@hifihedgehog
Copy link

After installing this in Creators Update, unlike in Anniversary Update where this would work, Command Prompt no longer works. The most basic of commands like dir and cd are rendered inoperable. So much for this marvelous tool :(

@leecher1337
Copy link
Owner

Hi, I don't have creator's build installed yet, but maybe you are just referring to the replacement of cmd.exe by PowerShell in certain menus in the Creators Update version?
This isn't so hard to restore:
http://winaero.com/blog/add-command-prompt-back-to-winx-menu-in-windows-10-build-14971/

If they left the console intact, ntvdmx64 shouldn't be affected by this change, I hope.

@hifihedgehog
Copy link
Author

Unfortunately, both PowerShell and Command Prompt no longer worked. Whatever is modified in the system registry affects both. After attempting install, the font size was changed in both of these and dir and cd and other commands no longer worked. Fortunately, I always back up and I also had my Anniversary Update still around in Windows.old. Quick fix. However, this is clearly not safe or compatible with Creators Update as-is.

@leecher1337
Copy link
Owner

Could theoretically be realted to the change
[HKEY_CURRENT_USER\Console]
"ForceV2"=dword:00000000

This disables the stupid enforcement of the V2 console, as NTVDM is and will always be compatible only with Console V1 (due to the requirements for windowed graphics).
You could try to reset this value to 1 and check if console then starts to work again.
If this is the case, I'd somehow have to modify the loader to change console enforcement based on the type of process being launched, but generally I prefer Console V1 anyway, so until now, it made perfect sense to change this globally and permanently.

No idea about the dir and cd commands, that sounds odd.

@leecher1337
Copy link
Owner

I installed the preview build of creators update, then reinstalled NTVDMx64 (as like with all major updates, all system level applications get ruined on update) and it works like a charm without any of the problems you described.
Therefore please provide proof for your claims, otherwise I will close this bug report as invalid.

@hifihedgehog
Copy link
Author

I have since gone back to Anniversary Update and upgraded again to clean build of Creators Update. So I do not have this and I am not going to experiment since I have since migrated to Creators Update's RTM build permanently. However, everything I said happened did happen. I am giving my word and I am sorry there are no screencaps. What I saw did indeed happen following all your steps. Here is my data point: I was running Windows 10 x64 on a Surface Pro 4 m3.

@leecher1337
Copy link
Owner

Maybe your Console V1 DLL was damaged during the update and this caused the problems. As Creator's update isn't officially released yet, it may also be that you received a build that had some bugs in it which caused this that were fixed by M$ in the meantime.
Another explanatin would be, that some appliation inserted an improper appinit-Hook to your registry that then got activated by installing NTVDMx64, which depends on Appinit.

You can try to setup a virtual machine and try it out in there, maybe you can reproduce the problem with it? I obviously can't fix a problem that cannot be reproduced for me.
There are no grave changes made to the system by NTVDMx64, just some files are copied, a few registry keys get added and above mentioned console settings are activated and appinit-DLLs are enabled. Everything can be reverted at least manually with regedit (uninstaller leaves Appinit and console v1 enabled, as it doesn't know their previous status).

@hifihedgehog
Copy link
Author

hifihedgehog commented Apr 4, 2017

I can confirm that I have the RTM build of Creators Update so I am fine in that department. You can leave this issue closed since I honestly don't have the time currently to try and debug this on a more in-depth basis than I already did. I will try taking a look at it again a month from now when I have some extra free time on my hands and see if I can get this working in my particular configuration. I know already several individuals at the TabletPCReview forums I frequent who are highly interested in this patch for playing retro DOS games and running other old 16-bit software more transparently. DOSBox and VMs aren't exactly appealing to them and I would love to get a simple zipped-up distribution working for them. Sorry that I don't have the time available right now to invest in this excellent project but I will hold off until the end of April.

@leecher1337
Copy link
Owner

Take your time, I'll continue to try to find and fix bugs in the meantime ;)
I never tried it on a Tablet PC, but why should it work differently there than on a PC, it's the same Windows...
For games, I'd still recommend using DOSBox though. NTVDMx64 currently also relies on an emulated SoftCPU, which is slow and may be worse than DOSBox's emulation! NTVDM never had a great history when it comes to support of DOS-games, especially when they are using Protected mode DPMI extenders.
Maybe someone is willing to implement the V86 mode monitor via VT-x technology as a kernel driver and then using NTVDM's Monitor-features for it, then we would theoretically be able to gain the same performance than the original NTVDM and not rely on a SoftCPU anymore. But that would involve lots and lots of work and a lot of expertise in the field of CPU architecture and VT-x.

For DOS application software, however, NTVDMx64 may be an advantage over vDOS, DOSBox, etc., due to its tight interaction with the Windows console and 32bit applications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants