Running 16-bit app installed on x64 through Telnet? (Error)

[Houdhey]

Dear leecher,

I've installed your program on my Windows Server 2012 64bits. Worked well.

I'm trying to run this app through a telnet client. So I connected my telnet server (Windows 2012) and my telnet client (Windows 10), both of them are 64bits. When I tried to run the app, it shows me same message as running a 16 bit app in 64 bits system.

"This version of Foxpro is not compatible with the version of Windows"

Do you know if there is a way to avoid this?

[leecher1337]

Ok, that's because the loader currently isn't injecting into Services (like the Telnet server), for saftey reasons, to not crash them, and for practical reasons as it is propagating via GUI applications and the injection into non-GUI applications (like services) isn't very easy and may be a bit unstable. I need to find a way to inject it into a given service, i.e. by making a service wrapper that loads the service with the loader injected into it. I'll have to setup a test-VM where I can try this, this might take some time, as I don't expect a very easy solution for this.

Btw., I had good results for running DOS applications on terminals by using dosemu on linux, it works very stable and also offers you SSH capabilities for using the remotely over the Internet. Just saying...

[Houdhey]

Thanks for your answer, I hope you'll find a solution, that would be great, especially for a production environment.

I already tried to run DOS applications on terminal using dosemu on Linux, or Dosbox, the problem is not about running the DOS application, but for example I made a test of performance for Foxpro. The aim is to make researches in database quickly :

• Through a telnet running Foxpro on Windows server 2008 : the operations took 30 seconds.
• Through an SSH running DOSEMU/DOSBOX on Linux, or Windows : it took me more than 600 seconds.

I'm testing every possibilities

[leecher1337]

Just out of interest: Did you also test ntvdmx64 performance-wise (without telnet, just as a plain user)? Remember that ntvdmx64 just uses a slow emulated CPU and not v86 mode like the original Windows x32 NTVDM, which is the key to its great performance. In my performance tests of emulated DOS systems, I found VDOS to have the best performance on x64 systems, though it's not usable in your usecase due to its inability to make use of streaming I/O. NTVDMX64 can speed up a little bit (ca. 25%) for plain Realmode and textmode applications when using HAXM, so this also is an option. Still, VDOS was outperforming it, at least with pervasive SQL (BTRIEVE) operations.

I wonder that DOSEMU is slow, because there was this kernel hack that even allows Linux to run v86 mode on x64 systems: http://v86-64.sourceforge.net/ If you are just using the linux machine for DOS Telnet sessions, I wonder why you don't use a 32bit Linux machine which can do V86 mode natively with dosemu, should also perform well.

[Houdhey]

I've tested ntvdmx64 performance in Windows Server 2012 (x64), I did the same operations as for x32, and it took me 1034 seconds ! (I set up a counter of execution)

I've tested on Windows 10 x64, 3568 seconds. So for both, same conclusion : you were right.

I don't know why i did not have the idea to test this locally on NTVDMx64, but the fact that it takes too much time, is the answer to my problem : it's not efficient for production environment.

I'm going to try vDos, i didn't know about this.

[leecher1337]

I haven't tried it, but http://www.bttr-software.de/products/jhoffmann/#rmenu may be a good starting point to get telnet support into VDos, in case that it performs OK. Still, I think that DOSEMU is worth a futher look (i.e. setting up a 32bit linux machine with dosemu on it acting as a DOS terminal server).

[Houdhey]

That's exactly what I did with DOSEMU. I installed it on Fedora 30, FreeBSD, Debian, and it took too much time. (More than 600 seconds). I did not test with telnet, only opening Dosemu locally and testing my operations... So, if I wanted to telnet this, it would be problematic. I'm not talking about a little program, it's not a problem. But for example my foxpro file has a size of 1 giga, with billions of lines. I'm doing my benchmarks on these big operations that take long time. The best performance I've had is from Windows Server 2008 x32.

I'll give you the results when I'll test on vDOS.

[leecher1337]

Aha, it just sounded very suspicious to me that DOSEMU has the same bad performance as DOSBOX. It's clear that DOSBOX-Performance is very bad, as it also only uses a CPU emulator (also on x32), but DOSEMU should be capable of V86 mode, thus it shouldn't be as slow as DOSBOX. So maybe there was an issue with DOSEMU setup or the kernel V86 support or something like this. It just sounds unlogical (i.e. compiled without vm86plus support http://www.dosemu.org/docs/README-tech/0.99/README-tech-5.html). There must be an explanation for this...

One explanation might be, that you didnt set sysctl -w vm.mmap_min_addr=0 Then V86 support gets disabled of this is not 0 iirc.

Did you check the ~/.dosemu/boot.log ? If you see something like

 WARN: vm86plus service not available in your kernel 
 WARN: using CPU emulation for vm86() 

then there is somthing wrong with the setup and it only uses useless CPU emulation. Some Linux Distributions also disabled VM86 syscall in their kernel versions, so you need to build your own kernel that enables this important functionality. i.e. on Debian, there was this problematic change: https://salsa.debian.org/kernel-team/linux/commit/b6d0d17b8a48068459b1db3ad0f4a6b479a41847

[cracyc]

Maybe try dosemu2 (https://github.com/stsp/dosemu2) which supports kvm.

[Houdhey]

Thanks for your answer Leecher, indeed, it is not available in my kernel. I did as you said : sysctl -w vm.mmap_min_addr=0

Still, the boot.log displays this warning.

_DOSEMU-1.4.0.8-180-g35054ba7 is coming up on Linux version 5.1.19-300.fc30.x86_64 #1 SMP Mon Jul 22 16:32:45 UTC 2019 x86_64 Compiled with GCC version 9.0.1 -m64 WARN: vm86plus service not available in your kernel WARN: using CPU emulation for vm86() CONF: reserving 640Kb at 0x00000 for 'd' (Base DOS memory (first 640K)) CONF: reserving 48Kb at 0xF4000 for 'r' (Dosemu reserved area) CONF: reserving 128Kb at 0xA0000 for 'v' (Video memory) WARN: using non-zero memory base address 0x10f000. WARN: You can use the better-tested zero based setup using WARN: sysctl -w vm.mmap_min_addr=0 WARN: as root, or by changing the vm.mmap_minaddr setting in WARN: /etc/sysctl.conf or a file in /etc/sysctl.d/ to 0. CONF: reserving 8256Kb at 0x100000 for 'x' (Extended memory (HMA+XMS)) Registering HWRAM, type=e base=0x41381000 size=0x400000 CONF: reserving 4096Kb at 0x41381000 for 'e' (VGAEMU LFB) CONF: reserving 12Kb at 0xC0000 for 'V' (VGAEMU Video BIOS) SERIAL $Id$ CONF: detected layout is "fr-latin1" CONF: detected alternate layout: fr-latin1 CONF: reserving 16Kb at 0xE4000 for 'E' (EMS page frame) CONF: reserving 16Kb at 0xE8000 for 'E' (EMS page frame) CONF: reserving 16Kb at 0xEC000 for 'E' (EMS page frame) CONF: reserving 16Kb at 0xF0000 for 'E' (EMS page frame) CONF: reserving 132Kb at 0xC3000 for 'U' (Upper Memory Block (UMB, XMS 3.0)) TIME: using 9154 usec for updating ALRM timer

So as you said, I have to build my own kernel (I've never done that before, that will be a rewarding experience). Thank you very much for guiding me, I would never know that by my own !

@cracyc It is specific to debian, as I see, not Fedora Thanks for the suggestion

[leecher1337]

If you just want to test, you may also use an older Debian Version, i.e. Debian 7 32bit still has VM86 support enabled:

root@debian:/# cat /boot/config-3.2.0-4-686-pae | grep VM86 CONFIG_VM86=y root@debian:/# cat /etc/debian_version 7.11

[Houdhey]

Well, I'm struggling with that Debian 7 since Friday, because it's obsolete so I had difficulties to install it (All ftp servers weren't working, but I found solution)

So I do have CONFIG_VM86=y and Debian version 7.11, but I meet a lot of problems installing Dosemu, do you have any idea of where to download the right dosemu package? Because I can't find it on the net

I'm going to try on Debian Jessie (8)

[leecher1337]

Why not use the precompiled binaries from http://www.dosemu.org/stable/ ? I tested on Debian 7 and they worked fine for me.

[Houdhey]

Ok, I've tested my program and this time it took 45 seconds (rather than 600 seconds)... 👍 I was wrong about under-estimating DOSEMU efficiency.

Still, Windows Server 2008 is faster 🥇 .

I'm gonna try the recompilation of kernel in Fedora for my own experience. Thank you very much for the help, I think I can close this issue now !

[leecher1337]

Yeah, just keep Windows Server 2008, original NTVDM still is the best! ;-)