My understanding is that the difficulties of implementing something with the same design as NTVDM on 64-bit is Virtual 8086 mode.
However, briefly reading Wikipedia it seems that later 64-bit processors make it slightly more possible to get into V86 than the original ones did because of VT-x: https://en.wikipedia.org/wiki/Virtual_8086_mo … and_VMX_support
I don't know much about the deep details though.

I aslo later tested Quake in the same 64-bit dosbox and it was not so slow, quite playable in lower video modes so I wonder that gcc compiling took so much time... Of course I know about DJGPP crosscompiler and virtualization (but I used what I already had on the machine, I didn't want spend extra time with downloading and setting up DOS on virtual disk for VM. Yes, currently I already have such Vdisk there for QEMU testing...

As noted in the winevdm documentation, 64 bit windows simply won't let you change the Local Descriptor Table.
There's no way around it, so you can just hope for somebody to develop a fast enough recompiler, or use a VM (HAXM in ntvdmx64?).

On the other hand.. Linux has no such limitation.
If your kernel has been compiled with CONFIG_X86_16BIT=y, you can mark code to run in 16-bit mode even though your OS is 64 (and if you are concerned with windows applications, older versions of wine should suit you)
This still wouldn't allow "native-like real mode" (for DOS).. But I think this is just the case because nobody tried to wire DOSEMU to Vt-x and unrestricted guests.

mirh wrote on 2020-06-09, 21:55:

64 bit windows simply won't let you change the Local Descriptor Table.

Newer Windows are more restrictive (on Win9x I think even GDT can be changed 😀 but you should be able to do it via kernel driver (ring 0), I can change any physical memory via KMD, I didn't tried it for LDT - would be some extra protection?

mirh wrote on 2020-06-09, 21:55:

If your kernel has been compiled with CONFIG_X86_16BIT=y, you can mark code to run in 16-bit mode even though your OS is 64

I still use 32-bit linux (with PAE) because of working DOSEMU. Good to know there's such kernel switch but what else you need in userpace to run DOS programs? Is it then fast as v86 on 32-bit system? Can it run also DOS PM programs (with extenders/DPMI)?

"Running 16 bit code" is just a subset of what you need for actual fully fledged DOS programs.
In 64-bit mode, the only possible way to run some kind of real mode "on bare metal" is virtualization.
Now, I would guess performance isn't really going to be 100% of "native vm86".. But close enough sounds reasonable (and in fact, some situations may even be faster).

DPMI should also be possible.. But I think that's still probably the sore point holding back the holy grail I mentioned above.

RayeR wrote on 2020-06-10, 00:28:

mirh wrote on 2020-06-09, 21:55:

64 bit windows simply won't let you change the Local Descriptor Table.

Newer Windows are more restrictive (on Win9x I think even GDT can be changed 😀 but you should be able to do it via kernel driver (ring 0), I can change any physical memory via KMD, I didn't tried it for LDT - would be some extra protection?

W10 1607 allegedly just straightaway crashes if LDT is touched.
Before that, in a very very very technical sense, I guess like editing raw memory could be done. But every task switch could be the last one.

I tired to install NTVDM64 on Win10-x64 from github (via install.bat) but according INF file it requires some more files (pop-up window required for ansi.sys):

[SourceDisksFiles.amd64]
ldntvdm.dll=1
ansi.sys=3
append.exe=3
autoexec.nt=3
backup.exe=3
bios1.rom=3
bios4.rom=3
...

where can I get this files? It's probably part of windows installation CD but of what windows version? No info in readme.md...

Maybe you should read the readme file? You have to compile it in order to get all the required files and the ntvdm.exe
https://github.com/leecher1337/ntvdmx64/blob/ … h/doc/minnt.txt
After compilation, you get all the files required and can prepare the installer directory.

Uh, I hoped that I can just install with precompiled binaries from release directory, I though recompile is only needed if someone wants to build ldntvdm.dll from source but not a must.
Does someone here tested it on w10-x64 and could provide precompiled package?

Google "ntvdmx64", first hit, for a CCPU build (not HAXM-acellerated) that isn't fully up-to-date.

IIRC, that project is based on the leaked NT4 source code. I'll need to double-check but recommend removing the links for now.

Do we need to be so uber-self-censored?
Well leecher, when I see the page it remembers me that I already visited it 2 years ago and I had downloaded the package but didn't had time to try it and completly forgot about it. I can see it was updated since then so I definitely have to give it a try!

BTW how it is about HAXM? I can see the CZ localized package contains ntvdmx64-haxm.inf that reference to HAXM but it is just leftover from some testing? In the source-readme there's mention about HAXM:
"Instead of using the emulated CCPU, it uses HAXM VT-x hardware accelleration (CPU needs to support it), so it is significally faster in textmode. But it doesn't support DPMI yet and will probably never support graphics, as it is technically impossible to emulate a real VGA
card with sufficient performance on VT-x"

So you mean it needs to be recompile to use HAXM - disabled by default?
Do you think it would be possible to workaround the DPMI problem? I would really appreciate to run DJGPP binaries and toolchain (even there's cross-compiler). I tried playing with QEMU version compiled with HAXM acceleration and it crashed too when try to run DPMI progs. like quake or simple commandline tools. So it seems it's problem of HAXM not the NTVDM? HAXM seems to be opensource
https://github.com/intel/haxm so it could be fixed?

Yes we do.

1. Keeps the undesirables away from the forum.
2.Informs the user on issues such as this.
3. Protects vogons from issues. Our stance has always been the same and we can point back to posts such as these to prove it.

Talking about the project is fine up to a point but sharing links to compiled binaries based off of leaked source code isn't allowed here.

Just use a Virtual Machine. With the resources available today there is no excuse not to . Back in the day when I used XP pro with 512megs of ram I could run RedHat 6.2, OS/2, and a Dos set all at the same time using MicroSofts free VM software. And still be able to use XP to surf the internet.

>DosFreak
OK, understand.

>Caluser2000
The beauty of NTVDM is that you can run any DOS program in a moment as native win32/64 programs without launching a VM, creating a vdisk and installing guest OS and drivers in, setting up a shared directory, etc. I have a bunch of dos commandline tools that I used to use also in WinXP but I can't do such simply and quick way in Win10-x64.

RayeR:
The haxm .inf file is in every package. However, it just gets used by the install.bat if there is a haxm-driver present in the package.
So HAXM-builds have the same directory structure, but also contain the custom haxm-driver from ntvdmx64 in the package that in turn gets loaded by a ntvdm.exe version that is compiled for haxm-support. So basically there are only 3 differences in the HAXM-packages:
- ntvdm.exe compiled with HAXM support
- Special IntelHaxm.sys driver (it WON'T work with the standard HAXM-driver, as this one is missing functions needed!)
- autoexec.bat that doesn't load DOSX.EXE (DPMI support)

So, yes, you need a recompiled version of NTVDM with HAXM-support, as it takes completely different codepaths than with the CCPU. Maybe some day there will be support for runtime CPU-switching, i.e. to use the CCPU for applications that do video I/O and the HAXM VT-x CPU for codepaths that don't have planar graphics I/O, but that may take a very long time to implement for a single developer.
Btw., regardign graphics, you can try to run QEMU with an installed DOS and an application that uses planar mode graphics like most DOS-games, and you will see that it also runs slow as hell due to the same problems (VGA emulation takes too many context switches). In my tests it performed even worse than NTVDMx64 with HAXM-support, so virtualization is not a solution imho.
If anybody here has an idea how to implement fast VGA emulation with VT-x support, I'd definitely be interested.

Recompiling it with HAXM-support isn't hard, there even is a video showing you how to compile it, so with a little effort, you can give it a try and check it our yourself.

Getting DPMI support working is a very hard task. It may be possible, but additional manpower would be needed, i.e. Interrupt hooking has to be implemented.
dosemu has an interesting approach for graphics and dpmi-problems. iirc, it just runs a virtual CPU in V86 mode and then basically lets doesmu operate like it would run on a x86 CPU in V86 mode. It also contains a CPU-emulator and switches between emulated and VT-x CPU for VGA emulation.
However all ntvdm V86 support is in Windows NT kernel, so all V86 stuff would need to be reeimplemented, so I'm not sure if this approach is usable for NTVDMx64.

Regading Quake: There are other reasons why it won't work that are given in the README.txt already. Given the slow VGA performance in VT-x mode, it's not even worth trying, you are better off with an emulated CPU here.

So currently the best setup may be:
- NTVDMx64 HAXM for commandline and textmode applications due to its good integration
- WineVDM for Win16 applications
- DosBox for Games

Hi,
OK, I just installed this non-HAXM version on Win10-x64 10.0.16299.611 without any error.
This means all DOS programs exec through slower CCPU but should it support DPMI? As I understand the DPMI support limitation, that you talked about, was related only to HAXM version or did you mean both?

I tested a few simple realmode cmdline programs and also Mikro Manazer (tiny color text mode filemanager) and it seems run fine. That's good step forward.
Then I run some DPMI cmdline programs but always got error window, see below.
I also tried to run CWSDPMI -r before and the DPMI program started to execute but it hanged at point where it should return back to DOS. I have to click X button at cmd windows once and it terminated (the DPMI app not the cmdline window itself). I kown it's quite complex theme and time consuming at 1 person, thank you for your effor.

Yes, QEMU is not fast with VGA/VESA graphics (no-HAXM), similar to Dosbox. BTW I benchmarked various VMs and emulators specially for graphics performance and sound support of DOS games but I don't have results handy just now and didn't publish it on my web yet. But there was a big differences. E.g. VMWare and MSVPC performed VESA graphics very fast (near the bare metal speed run under plain DOS) so there must be a way how to do some smart memory mapping with minimum overhead under VT-X.

when you are talking about dosemu, you mean new doesmu2 or how it's called that for x64 machines?
Normal 32bit dosemu use CPU in v86 mode similar way as NTVDM, everything's fine and fast.
In 64bit mode the only way to get v86 mode could be start virtual machine (VMM) and then switch the virtual CPU to v86 mode (I don't know in what mode the virtual CPU starts, probably real mode?).
So then for any legacy IO access the VMEXIT happens and VMM must handle/emulate it and it's slow. For VESA LFB mode it should not require any IO access just do some smart memory mapping of LFB...

WineVDM - Yes, I already have it installed and it works well. There's better situation with win apps because they are not allowed to touch HW directly but call API that can be translated faster way than emulating direct HW access...

1Microsoft Windows [Version 10.0.16299.611]
2(c) 2017 Microsoft Corporation. Všechna práva vyhrazena.
3
4C:\DOS>MCOPY.EXE
5
6C:\DOS>cwsdpmi -r
7CWSDPMI V0.90+ (r7) Copyright (C) 2010 CW Sandmann  ABSOLUTELY NO WARRANTY
8
9C:\DOS>mcopy
10
11Martin's Advanced Copy 1.25 (C) 2000-2014 by Martin Rehak; -----
12Compiled by GCC 4.8.3 at 23:02:27, Jun  3 2014
13
14Syntax: MCOPY source_file, destination_file, offset (Bytes), count (Bytes)
15Use count=0 for copying until EOF(source_file) - autocount.
16Hexa-numbers with "0x" prefix are allowed.
17If destination_file is not specified then file OUTPUT.TMP will be created.
18Source file name can be same as destination file name.
19MCOPY will ask you before rewriting potential existing files.
20(forced terminate by click X)
21C:\DOS>

Caluser2000 wrote on 2020-06-12, 00:47:

Just use a Virtual Machine. With the resources available today there is no excuse not to . Back in the day when I used XP pro with 512megs of ram I could run RedHat 6.2, OS/2, and a Dos set all at the same time using MicroSofts free VM software. And still be able to use XP to surf the internet.

I guess people want to be able to mix DOS and Win32 commands in a single bat file, for example, or pipe output between them. Kind of ridiculous that with WSL this is totally possible to do with Win32 and Linux binaries on Windows 10, but not DOS programs!

RayeR wrote on 2020-06-12, 16:09:

QEMU is not fast with VGA/VESA graphics (no-HAXM), similar to Dosbox. BTW I benchmarked various VMs and emulators specially for graphics performance and sound support of DOS games but I don't have results handy just now and didn't publish it on my web yet. But there was a big differences. E.g. VMWare and MSVPC performed VESA graphics very fast (near the bare metal speed run under plain DOS) so there must be a way how to do some smart memory mapping with minimum overhead under VT-X.

PCPBENCH VESA mode 4101h (640x480 8bpp) clocked in 82FPS on QEMU TCG. The same VESA mode with KVM/HAXM/WHPX clocked in over 300FPS. I don't think this can be considered slow and I got the numbers on a aging Core i3-4010U laptop on battery. QEMU standard VGA with BOCHS dispi is quite fast for VESA LFB application/games, probably faster than any DOS machines prior to year 1999. With KVM/HAXM/WHPX it can play Extreme Assault in software render as smooth as the 3Dfx render.

For DOS programs i just use Dosbox, for (some) Windows 3.11 applications I also use WINEVDM : https://github.com/otya128/winevdm
Some applications work well, others do not unfortunately. Another approach i like to use for problematic applications is just emulating Windows 98 in dosbox.

under linux on i5-450M 2.4GHz (Westmere, 2010)

------------qemu-kvm|qemu-tcg|dosemu2|dosbox
pcpbench 100| 749.8 | 115.0 | 741.4 | 80
pcpbench 101| 662.8 | 103.7 | 649.4 | 69

dosemu2 without kvm