DOS ain't dead

Hi,

it's possible running NTDVM.exe from win Xp on win 7 32 bit for emulate 16 bit programs?

win 7 ntdvm.exe if execute graphic programs say can't execute on full screen mode and ask to terminate..

Thanks

Roberto

No, running NTVDM from WinXP under Win7 is not possible.

---
DOS-u-akbar!

> Hi,
>
> it's possible running NTDVM.exe from win Xp on win 7 32 bit for emulate 16
> bit programs?
>
> win 7 ntdvm.exe if execute graphic programs say can't execute on full
> screen mode and ask to terminate..
>
> Thanks
>
> Roberto


This _might_ work for you.

https://answers.microsoft.com/en-us/windows/forum/...ms-in-full/243962f3-64ff-4004-8b5a-d570dfd4e292

An even better method is that when you need to run DOS programs, boot to real DOS

Fergawdsakes...

My machines (intel-i5 quadcore & intel core2),
are all dual boot to OpenDos v7.01 & Slackware64-current

And I completely rid myself of WinCrap way back in the days of Win98 :)

---
--
http://glennmcc.org/

If I remember well it's due to new windows driver model for VGA adapters that doesn't allow fullscreen VGA/VESA (introduced in Win Vista). It should be possible to use some older VGA drivers from XP era for some VGAs in some compatability mode that then could run fullscreen but you may not fully utilize new features/speed of your VGA in Windows so it's not reccomended.
Use some kind of virtualization if the DOS app is not speed critical and need to run still under Windows. E.g. VMWare offers quite good performance in VESA modes.

---
DOS gives me freedom to unlimited HW access.

>
> This _might_ work for you.
>
> https://answers.microsoft.com/en-us/windows/forum/...ms-in-full/243962f3-64ff-4004-8b5a-d570dfd4e292
>
This is intersted, but work only with EXE progra, not with .COM ..

> This is intersted, but work only with EXE progra, not with .COM ..

Perhaps it can be made to work if you rename the .COM file to have an .EXE filename extension. DOS doesn't care either way, but the file properties dialogue that you want may be displayed just by changing the name.

If it really requires an MZ .EXE format file (unlikely), you can convert a flat .COM format file to wrap it in an MZ shim. It needs to set up SS = CS = -10h, SP = FFFEh, IP = 100h, and allocate enough memory to the process (64 KiB is plenty).

---
l

> If I remember well it's due to new windows driver model for VGA adapters
> that doesn't allow fullscreen VGA/VESA (introduced in Win Vista). It should
> be possible to use some older VGA drivers from XP era for some VGAs in some
> compatability mode that then could run fullscreen but you may not fully
> utilize new features/speed of your VGA in Windows so it's not reccomended.
>
> Use some kind of virtualization if the DOS app is not speed critical and
> need to run still under Windows. E.g. VMWare offers quite good performance
> in VESA modes.

It is still possible, even on Windows 10 32-bit to run NTVDM programs in full screen, BUT one has to disable the current video card drivers, and switch to the default VGA-only adapter, losing all acceleration modes.

It may be possible to run NTVDM via XP drivers with fullscreen VESA support without losing acceleration options, but I've never been able to find XP-compatible drivers for Broadwell Intel chipsets or newer (i7 5000 series or newer). In fact finding ANY i3, i5, or i7 chipset video drivers for XP is a nigh impossible task. I gave up long ago. I'd welcome anyone who can post where to find (releatively) recent XP drivers for gen 5 and up Intel i3s- i7s.

Another option for NTVDM support in *64-bit* Win 10 might be:

https://www.vogons.org/viewtopic.php?t=65472&p=744861

The VOGONS topic seems promising, yet I have not tried that solution, either.

DOSBOX is no solution, it is FAR too slow and kludgy. I can't stand it, and how it is touted as a panacea for "running DOS programs" in Windows. It is absurdly slow.

Yes, interesting discussion, did someone tried NTVDM64?
https://github.com/leecher1337/ntvdmx64

Here some info about run 16-bit code in long mode
https://stackoverflow.com/questions/57133019/how-t...-the-local-descriptor-table-on-64-bits-windows/

---
DOS gives me freedom to unlimited HW access.

> Yes, interesting discussion, did someone tried NTVDM64?
> https://github.com/leecher1337/ntvdmx64
>
> Here some info about run 16-bit code in long mode
> https://stackoverflow.com/questions/57133019/how-t...-the-local-descriptor-table-on-64-bits-windows/

Since the query was about a system running Win7 32bit...

How does ntvdmx64 come-into-play ?

---
--
http://glennmcc.org/

It's a bit off topic but I think 64b users are much more interested as they don't have NTVDM at all and would like to have even that crippled one from Win7. When Zyzzle reminded it to me I have to definitely try it...

---
DOS gives me freedom to unlimited HW access.

I just installed non-HAXM version of NTVDMx64 on Win10-x64 10.0.16299.611 without any error. DOS programs exec through slower CCPU emulation.
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.
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). So it's far better than nothing and it work seamless compared to VMs/EMs, I hope it would help others who sticked with 64b Win for some reasons.

---
DOS gives me freedom to unlimited HW access.

> It's a bit off topic but I think 64b users are much more interested as they
> don't have NTVDM at all and would like to have even that crippled one from
> Win7. When Zyzzle reminded it to me I have to definitely try it...

Just an FYI... all 3 of my 64bit machines (2 intel dualcore & 1 intel i5),
are all setup as dual boot to Slackware64-current & OpenDos v7.01
(no WinCrap of any version here)

Soooo.... why the heck does anyone ever bother trying to run DOS programs
via some kludge method while booted to WinCrap ?

Boot the machine to DOS and be done with all of the hassle.

---
--
http://glennmcc.org/

How about CONHOSTF? See https://www.waldbauer.com/vb/showpost.php?p=8108&postcount=8 for a description.

Regards

> How about CONHOSTF? See
> https://www.waldbauer.com/vb/showpost.php?p=8108&postcount=8 for a
> description.

To me it reads like CONHOSTF will only support text mode, but iw2evk wrote "if execute graphic programs".

---
Forum admin

> Soooo.... why the heck does anyone ever bother trying to run DOS programs
> via some kludge method while booted to WinCrap ?

Because someone e.g. want to use various commandline tools for dos under windows too? And he can do it seamless as in NTVDM instead launching VM or rebooting? I think that different users have different use cases so it's good when there are more choices.

---
DOS gives me freedom to unlimited HW access.

The package conhostf.zip? requires forum login, please can you host it somewhere else? Or just send it to me via email?

---
DOS gives me freedom to unlimited HW access.

> > Soooo.... why the heck does anyone ever bother trying to run DOS
> programs
> > via some kludge method while booted to WinCrap ?
>
> Because someone e.g. want to use various commandline tools for dos under
> windows too? And he can do it seamless as in NTVDM instead launching VM or
> rebooting? I think that different users have different use cases so it's
> good when there are more choices.

My point is that more time is spent (unsuccessfully), trying to get this that
and the other thing to work than the total amount of time it would take to
reboot back-n-forth between DOS & WinCrap 100 different times.

Sooo... boot to DOS and be done with all of the kludging-around.

---
--
http://glennmcc.org/

> > > Soooo.... why the heck does anyone ever bother trying to run DOS
> > programs
> > > via some kludge method while booted to WinCrap ?
> >
> > Because someone e.g. want to use various commandline tools for dos under
> > windows too? And he can do it seamless as in NTVDM instead launching VM
> or
> > rebooting? I think that different users have different use cases so it's
> > good when there are more choices.
>
> My point is that more time is spent (unsuccessfully), trying to get this
> that
> and the other thing to work than the total amount of time it would take to
> reboot back-n-forth between DOS & WinCrap 100 different times.
>
> Sooo... boot to DOS and be done with all of the kludging-around.
>
>

I agree with you in theory (and practice, for I boot to plain DOS usually to get down to REAL work), but the reason these myriad kludges and hacks are appealing is simply because of M$oft's artificial limitations / abandonment of NTVDM for no good reason. And by extension, the disabling of "full screen mode" in 64-bit Windows is maddening. Lack of driver support for this simple task is a ridiculous excuse. Fullscreen mode was *intentionally* buried, for obscure and unfair reasons. We tinker, and try to get it to work, simply for the intellectual exercise -- because the problem is "there" and we DOS users are tinkerers back from the earliest days of bare metal and 8-bit days.

But it would save a lot of time to be able to run, in two seconds some simple, beloved DOS programs via NTVDM rather than having to reboot, and reconfigure BIOS into Legacy mode, enable legacy boot of USB devices, disable wifi, EFI, etc all to recover as much DOS memory from within BIOS options as possible. For enabling these BIOS options on "modern" systems, for some reason deducts from the low 640k pool of system memory available!

Renaming .Com in .exe cause the message error "this program can not work in fullscreen mode etc"
I've installed now Dosbox, fulscreen running but seem slow ..

> > This is intersted, but work only with EXE progra, not with .COM ..
>
> Perhaps it can be made to work if you rename the .COM file to have an .EXE
> filename extension. DOS doesn't care either way, but the file properties
> dialogue that you want may be displayed just by changing the name.
>
> If it really requires an MZ .EXE format file (unlikely), you can convert a
> flat .COM format file to wrap it in an MZ shim. It needs to set up SS = CS
> = -10h, SP = FFFEh, IP = 100h, and allocate enough memory to the process
> (64 KiB is plenty).

Yes.
BW did you tried NTVDMx64 too? I think it's worth to try, installation is quick and it seems to work well for realmode dos app so why not. I got instructed by leecher I should recompile latest version that include DPMI patch do there chanche also DJGPP programs will work then :)

---
DOS gives me freedom to unlimited HW access.

Work also on win 7 professional 32 BIT?

> Yes.
> BW did you tried NTVDMx64 too? I think it's worth to try, installation is
> quick and it seems to work well for realmode dos app so why not. I got
> instructed by leecher I should recompile latest version that include DPMI
> patch do there chanche also DJGPP programs will work then :)

> > How about CONHOSTF? See
> > https://www.waldbauer.com/vb/showpost.php?p=8108&postcount=8 for a
> > description.
>
> To me it reads like CONHOSTF will only support text mode, but iw2evk wrote
> "if execute graphic programs".

The source code is available with the program at https://www.waldbauer.com/tmp/dl.php?download=conhostf (and IMHO the main culprit is enabling "video card switching" when in full screen mode): see also http://www.columbia.edu/~em36/wpdos/windowsseven.html

> Work also on win 7 professional 32 BIT?

Not sure but binary was tested only on x64. But it doesn't support fullscreen anyway. I asked Zyzzle.
BTW I was able to recompile NTVDMx64 from current source and now some simple DMPI programs works :) But e.g. DJGPP cannot compile even simple helloworld.c and silently exit without creating object file or crashes with GPF. So it's not perfect but better than old build. BTW did you know about OpenNT? I missed that project but it's dead now...

---
DOS gives me freedom to unlimited HW access.

> > Work also on win 7 professional 32 BIT?
>
> Not sure but binary was tested only on x64. But it doesn't support
> fullscreen anyway. I asked Zyzzle.
> BTW I was able to recompile NTVDMx64 from current source and now some
> simple DMPI programs works :) But e.g. DJGPP cannot compile even simple
> helloworld.c and silently exit without creating object file or crashes with
> GPF. So it's not perfect but better than old build. BTW did you know about
> OpenNT? I missed that project but it's dead now...

Yes, I did try NTVDMx64, and it does work for me, in Win 10 x64, but only for real mode flat 16-bit executables. No DPMI servers work, etc. This seems the same as your testing results.

I attempted unsuccessfully to recompile from source code to get DPMI working, but was not successful in compiling. Could you make your DPMI build of NTVDMx64 available? I will test it with simple DPMI server, for example CWSDPMI.EXE. I'll let you know if I am successful executing any DJGPP programs.

How did perform do the installation?
When I tried it on my Win10-x64 it complained about missing many files which my windows do not have.
I ran INSTALL.BAT, it started to do something but early it asked about files like AUTOEXEX.NT, CONFIG.NT, CMOS.RAM and many others. Some I created in the notepad some downloaded from internet but when I looked into some .INF file and saw that it wants about 30 these files I gave up.

---
DOS-u-akbar!

> How did perform do the installation?
> When I tried it on my Win10-x64 it complained about missing many files
> which my windows do not have.

You must compile this files from another source packages (not included in github) or you need to download full precompiled version that is old and doesn't run DPMI apps. My build have some issues (interference with some win32 app) that I'm trying to solve with help of Leecher. Then I will upload it somewhere. BTW NTVDM has it's own DMPI server DOSX.EXE. In this version it is probably limited to 16MB only, need to be increased....

---
DOS gives me freedom to unlimited HW access.

I tried conhostf on W10-x64 and it doesn't work (missing parts in 64b OS) but it should work on 32b systems so try it.

---
DOS gives me freedom to unlimited HW access.

> I tried conhostf on W10-x64 and it doesn't work (missing parts in 64b OS)
> but it should work on 32b systems so try it.

Hi,

intalled constohoff on win7 32 bit and run circad PCB cad .

"fatal error : video graphic not supported"

Maybe work virtual pc 2004 ?

VPC/VMware should work but you have to install OS in it.
Did the conhostf worked for you at least for textmode or simple VGA mode (the fullscreen)?

---
DOS gives me freedom to unlimited HW access.

> VPC/VMware should work but you have to install OS in it.
> Did the conhostf worked for you at least for textmode or simple VGA mode
> (the fullscreen)?

No, open a black fullscreen

Ok, after somes working out now i can switch from windows and fullmode screen and viceversa.
I don't understand why if i leave fullscreen mode on ntvdm (eg closing a dos program) and retourn to win 7 the resolution of screen fall into 800x600.
The right mode for save win 7 resolution it's retourn to windows mode BEFORE to close dos program?

reply from leecher:
You must take into account that you are in fact daling with 2 different video drivers here.
As soon as you switch to fullscreen and from that time on, as long as you have console windows open, you are on BASIC display adapter driver.
If you close all console windows, you will be back to your WDM driver.
Different video drivers have different resolution settings. So what you normally do:

1) Switch to fullscreen an back -> You are on BASIC display driver now
2) Go to desktop and change resolution of BASIC display driver to some resolution that it suitable for your monitor, if it supports it. Idally, the same as you use for your default WDDM display driver.
Windows should take note of it and from now on, you should also get the preferred resolution on BASIC display driver.

---
DOS gives me freedom to unlimited HW access.

I compiled new version of NTVDM x64 with increased DPMI memory (currently hardcoded) to 128MB. I can now compile a simple helloworld.c with DJGPP so DPMI works some way but it's not much stable, when compiling larger files it crashes. It can also run Memories 256B intro in a window :)

---
DOS gives me freedom to unlimited HW access.

> I compiled new version of
> NTVDM x64 with
> increased DPMI memory (currently hardcoded) to 128MB. I can now compile a
> simple helloworld.c with DJGPP so DPMI works some way but it's not much
> stable, when compiling larger files it crashes. It can also run
> Memories 256B intro
> in a window :)

Your compilation works for me (Win 10, 64-bit, i7 5500u CPU), and it shows the full 128mb DMPI memory available, but it is at least an order of magnitude slower than real DOS. For example, computing 64k digits of pi takes 0,22 second to compute in real DOS, but 130 seconds in NTVDM. Extracting a 2mb .ZIP file takes 0,05 second in real DOS, but 20 seconds in NTVDM, etc. I must be doing something wrong! I did not install WOW16 engine, as I don't need to run 16-bit Windows programs. Is order of magnitude slowdown (ie, 1000x slower than real DOS) the expected performance?

Yes, this is expected. As you know in 64-bit mode you don't have accessible v86 mode. The NTVDMx64 uses softcore CPU emulation same as NT4 for DEC Aplha used to run x86 programs. But still by my test the DJGPP compiling is ~10x faster than under Dosbox. There is also NTVDMx64 version that can use intel HAXM virtualization acceleration but unfortunatelly intel HAXM is limited and don't support DPMI programs. Also even with VT-X the graphics emulation is still very slow at too many VMEXIT occurs during emulation. So it helps for some real-mode text based programs. I didn't try to compile it yet, it needs more depencies and I'm not insterested without DPMI support...

---
DOS gives me freedom to unlimited HW access.

> Yes, this is expected. As you know in 64-bit mode you don't have accessible
> v86 mode. The NTVDMx64 uses softcore CPU emulation same as NT4 for DEC
> Aplha used to run x86 programs. But still by my test the DJGPP compiling is
> ~10x faster than under Dosbox. There is also NTVDMx64 version that can use
> intel HAXM virtualization acceleration but unfortunatelly intel HAXM is
> limited and don't support DPMI programs. Also even with VT-X the graphics
> emulation is still very slow at too many VMEXIT occurs during emulation. So
> it helps for some real-mode text based programs. I didn't try to compile it
> yet, it needs more depencies and I'm not insterested without DPMI
> support...

Thanks for clarification. Yes, I knew that without access to v86 mode -- and using software CPU emulation, things would be glacially slow. But, I also am using this for DPMI support, and it is really much better than the kludgy DOSBOX for my purposes also. Your patch making 128 MB of DMPI memory available is wonderful! It is great to be able to just run "command prompt" now and execute often-used DOS programs without fussing with DOSBox, virtual machines, or other DOS emulators. It is very convenient. Of course, when I want to get down to *real* work, I simply reboot my machine with my bootable memory stick, and bask in the glory of real DOS.

>
> 1) Switch to fullscreen an back -> You are on BASIC display driver now
> 2) Go to desktop and change resolution of BASIC display driver to some
> resolution that it suitable for your monitor, if it supports it. Idally,
> the same as you use for your default WDDM display driver.
> Windows should take note of it and from now on, you should also get the
> preferred resolution on BASIC display driver.[/i]

WOW !! now work fine..

thanks

Roberto iw2evk

You're welcome. Please pay attention to unusual 32bit programs behavior. I still have a problem under my Win10 that after installing my new NTVDMx64 some 32bit windows programs are crashing but it doesn't happen with old NTVDMx64 build by Edward. Leecher cannot reproduce it. Maybe it affects only some specific version of Win10 and not Win7. This maybe caused by DLL injection to every process by NTVDMx64. For me it's hard to debug I don't know Windows internals I just recompiled it by guide. So if you find that some 32bit program crash now that ran before then try uninstall NTVDMx64 from control panel.

---
DOS gives me freedom to unlimited HW access.

> You're welcome. Please pay attention to unusual 32bit programs behavior. I
> still have a problem under my Win10 that after installing my new NTVDMx64
> some 32bit windows programs are crashing but it doesn't happen with old
> NTVDMx64 build by Edward. Leecher cannot reproduce it. Maybe it affects
> only some specific version of Win10 and not Win7. This maybe caused by DLL
> injection to every process by NTVDMx64. For me it's hard to debug I don't
> know Windows internals I just recompiled it by guide. So if you find that
> some 32bit program crash now that ran before then try uninstall NTVDMx64
> from control panel.

I've no crashes yet using your compile of NTVDMx64 (I'm using Win 10.0.15063 x64), but I am using an older stripped-down version of Win10 LTSB. Which 32-bit programs crashed for you? I can test...

I have found 2 till now.
1) Mozilla Seamonkey 2.49 or 2.53 32-bit crashes when start to download any file from link, the file save window opens to navigate where save the file and it freeze for a moment and then pop up message that Mozilla stopped working and gets closed.
2) StrongRecovery 4.0.7.0 portable crashed at start when scanning drives.

I have quite old W10 where I disabled updates for 2 years, maybe something wrong there or interference with some specific driver or program, who knows...

---
DOS gives me freedom to unlimited HW access.

Hi, I compiled new NTVDMx64 with latest l33cher patches. We was able to debug and fix the crashing on my Win10 version. Also now the DPMI memory is not hardcoded but it reflect value in registry and you can set it individually in associated PIF file.

---
DOS gives me freedom to unlimited HW access.