running 32-bit code in LM64

[rdos]

My OS once supported MSDOS, as well as many DOS-extenders, but I'm sure most of that is broken know as I've dropped support for it. Still, one day when I have a lot of time, I might get into it again.

Still, my goal back then was to turn DOS into a multitasking environment, and I had thread support in DOS extender apps, as well as in native MS-DOS apps. I did not run DOS in real mode, rather used V86 mode and also virtualized the first 4k page to be able to emulate DOS & BIOS variables.

I once also had Win32 emulation DLLs, actually advanced enough to run Borlands debugger on my OS. However, I've moved away from that and now have a native API, and no support for Win32 or MS-DOS (although it can be added again, if ever desired). I could also execute 16-bit NE executables.

[kerravon]

In fact, PDOS-generic is what I eventually came up with as "right", but then I suddenly noticed I could twist it for expedience to support win64 executables that were dependent on msvcrt.dll. And today I am hoping that I can support win32 executables dependent on msvcrt.dll the same way under OS/2 2.0+.

This worked btw - the result can be found by searching for win32os2 at http://pdos.org

Same deal with win32lin which I uploaded a short time ago (for Linux obviously).

This one has an issue I don't know how to get around.

My applications (ie micro-emacs) rely on two ESC coming through when the user presses ESC (as allowed by ANSI X3.64), rather than relying on a non-standard random delay (I don't like random delays ever since someone from Alpha Centauri told me 4 years ago that it was causing an issue).

But the "MATE" terminal I use on Kylin Linux only sends one ESC with no ability to configure that.

I don't know which component is responsible for fixing this.

So that means currently I have to press ESC twice.

I have the same issue on Windows 10.

I don't have the issue on OS/2 or PDOS/386 because I am required to interpret the keyboard myself. I don't have that option at all on Linux. On Windows I could likely go through some hoops.

[eekee]

This one has an issue I don't know how to get around.

My applications (ie micro-emacs) rely on two ESC coming through when the user presses ESC (as allowed by ANSI X3.64), rather than relying on a non-standard random delay (I don't like random delays ever since someone from Alpha Centauri told me 4 years ago that it was causing an issue).

But the "MATE" terminal I use on Kylin Linux only sends one ESC with no ability to configure that.

I don't know which component is responsible for fixing this.

So that means currently I have to press ESC twice.

I have the same issue on Windows 10.

I don't have the issue on OS/2 or PDOS/386 because I am required to interpret the keyboard myself. I don't have that option at all on Linux. On Windows I could likely go through some hoops.

I'm having the same issue in different Forth interpreters. Gforth on Windows handles it right, presumably with a Windows call to get the actual key, but Pforth is reliant on terminals and I had gave up and made the user press ESC twice. After considerable thought, I concluded a delay is the only way to do it better, given the constraint of sticking with the terminals I have. I had no idea there was a double-ESC option, especially as VIM and other VI editors don't expect it.

This was just the tail end of a 25-year saga of dissatisfaction with terminals, and I want to be free of them in the future. (I'm disappointed in myself that I still need them now.) Plan 9 and VNC have, between them, shown me that remote windowing can be practical and relatively lightweight. Plan 9 showed me that even if you're just drawing text, a remote window system can be a better design than ANSI standard terminals. Though having said that, I'm sure there are much better-designed terminals than the ANSI standard or anything else of the VT-xxx range. In-band signalling is stupid.

I just looked up the VT100 keyboard expecting, from the protocol design, that it would have a CAN (cancel) key and no ESC key. I couldn't believe it when I saw it had an ESC key in a prominent position. To borrow your phrasing, @kerravon, I consider this a _deficient_ design! What we have is not what was good, but what was available.