DOS ain't dead

I have a fullscreen editor (microemacs 3.6) working
satisfactorily on PDOS/386. Running under Windows
requires a hack to get around a bug that I haven't
been able to find, and I don't use that anyway, so
it hasn't been a priority.

I now realize that DOS+HX+doslfn running under ArcaOS
(OS/2) is probably the environment I really want.

But traditionally DOS has only provided ANSI.SYS for
screen output, but not keyboard input.

I want the ESC [ A etc for cursor keys to come through
to my apps (like microemacs).

It is only with Windows 10 that Microsoft started allowing
that.

I would like to know if there is a reason keyboard input
for MSDOS is not ANSI standard (no driver), and whether
this should be changed with a DOS driver or in HX.

Also, the ANSI standard allows 2 ESC to be sent when the
user presses ESC, and this is what I want (and what PDOS
does), but it is not what Windows does. So I'd like this
to be configurable.

I was just about to raise an HX issue on github when I
realized that this may be a DOS question.

Thanks. Paul.

I'm confused by this question.

Terminals needed a way to send codes for special keys over the wire. DOS computers were supposed to use the DOS keyboard interrupt to read keystrokes, or the lower-level BIOS interrupt routines. For special keys you have to use the BIOS routines, as DOS will just return ASCII codes.

When acting like a terminal, sure, those keystrokes have to be translated to whatever ASCII codes the host is expecting. But for local processing it doesn't make sense.

What are you trying to accomplish?

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> I'm confused by this question.
>
> Terminals needed a way to send codes for special keys over the wire. DOS
> computers were supposed to use the DOS keyboard interrupt to read
> keystrokes, or the lower-level BIOS interrupt routines. For special keys
> you have to use the BIOS routines, as DOS will just return ASCII codes.
>
> When acting like a terminal, sure, those keystrokes have to be translated
> to whatever ASCII codes the host is expecting. But for local processing it
> doesn't make sense.
>
> What are you trying to accomplish?

Actually I was confused by your question!

But I think I have figured it out - but not really.

First - I already have what I want with both PDOS/86 and PDOS/386 - applications expect to receive escape sequences for input, and PDOS delivers them.

And Windows 10+ supports this too. And I have written such Windows applications. And those ANSI-input-applications work under PDOS/386. And now I would like them to work under Freedos+HX.

But - and this is what confuses me - even if I was using just MSDOS alone, surely a PDOS/86 (semi-clone of MSDOS) application (expecting escape sequences), would work under MSDOS too, so long as the ANSIKEYBOARD.SYS or whatever existed? Because that driver would convert BIOS keys into escape sequences, and so long as genuine MSDOS doesn't interfere with the input flow, it my PDOS/86 applications will suddenly become "odd MSDOS applications", right?

> I'm confused by this question.
>
> Terminals needed a way to send codes for special keys over the wire. DOS
> computers were supposed to use the DOS keyboard interrupt to read
> keystrokes, or the lower-level BIOS interrupt routines. For special keys
> you have to use the BIOS routines, as DOS will just return ASCII codes.

This is incorrect, on DOS stdin connected to the CON device that reads from the ROM-BIOS int 16h, you will receive non-ASCII keypresses as two DOS keypresses: A zero, and then a scancode.

For example, here's the FreeDOS kernel's CON device code to do that: https://github.com/FDOS/kernel/blob/29ccb6e45414a8a18346a97fdb0f35ebd6fb4025/kernel/console.asm#L132

---
l

DOS systems are not terminals. A DOS system generally has direct access to read the keyboard (through a DOS function or a BIOS interrupt for more control) and DOS and BIOS also provide mechanisms for writing text to a screen.

ANSI.SYS seems almost like an accidental add-on. It makes it easier to "print" colored text to the screen and format the screen, similar to the way a terminal would do it. But classical DOS never provided enhanced keyboard handling through ANSI.SYS - you still had to use the DOS read console or the BIOS interrupt.

The fact that later systems supported this is irrelevant.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> ANSI.SYS seems almost like an accidental add-on. It makes it easier to
> "print" colored text to the screen and format the screen, similar to the
> way a terminal would do it. But classical DOS never provided enhanced
> keyboard handling through ANSI.SYS - you still had to use the DOS read
> console or the BIOS interrupt.

It's more than an accidental add-on - it's a start
towards complying to ANSI X3.64

> The fact that later systems supported this is irrelevant.

I don't consider it to be irrelevant.

Irrelevant for your use case/interests - yes.

But not for mine. I want to write ANSI X3.159-1989
plus ANSI X3.64-compliant applications, and I am
already doing that, or other people are already
doing that (e.g. Microemacs 3.6). I now wish to
build that source code - unchanged - for a DOS
or DOS-like or maybe DOS-inspired target, ie
PDOS/86 or Freedos+HX, and only the former works.

I don't want to change "my" source code, because
it is standards-conforming. I want to change the
component that isn't standards-conforming, which
is DOS 6.22 - but I don't have that source code.

I do have the Freedos source code, so I could
change that.

Or I could have an additional driver, or an
enhancement to a freeware ANSI.SYS, that provides
the additional functionality I want.

And that unchanged source code should also work on
other systems like the Amiga. And other than EBCDIC
differences, I already know that it works on IBM
mainframes (although they normally have 3270 terminals,
not ANSI terminals - but that's a chicken and egg
problem, not a technical problem).

ANSIplus is most likely what you need.

---
DOS isn't about why. It's about why not.

Hey, it's OK to make old software and machines do unreasonable things. I'm not arguing with you about the merits of that; it's your project and not my business. I'm just pointing out that it's not in ANSI.SYS or any other device driver I know of for DOS because that's not how DOS software at the time used the keyboard.

Usually if you want to write something that runs on multiple platforms you include some sort of compatibility layer that hides the machine specifics, like the curses library on Unix. Trying to bend the various OSes to your will is a very different approach. For DOS specifically you'll need a device driver that intercepts the BIOS routine and generates the ESC sequences that you are looking for. Which will be fine while you are in your program, but that device driver will interfere with other DOS programs. Which is probably why a device driver that remaps the cursor keys like that doesn't exist.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> ANSIplus is most likely what you need.

Thanks for the link. I tried it and couldn't get it
to do what I want. I contacted the author but didn't
get a reply.

> Hey, it's OK to make old software and machines do unreasonable things. I'm
> not arguing with you about the merits of that; it's your project and not my
> business. I'm just pointing out that it's not in ANSI.SYS or any other
> device driver I know of for DOS because that's not how DOS software at the
> time used the keyboard.

Ok, thanks. That sounds like a chicken and egg
problem though.

> Usually if you want to write something that runs on multiple platforms you
> include some sort of compatibility layer that hides the machine specifics,
> like the curses library on Unix.

I see.

> Trying to bend the various OSes to your
> will is a very different approach. For DOS specifically you'll need a
> device driver that intercepts the BIOS routine and generates the ESC
> sequences that you are looking for.

I was thinking a TSR that hooks the DOS read, for
read from handle 0.

> Which will be fine while you are in
> your program, but that device driver will interfere with other DOS
> programs.

I didn't even think of that. The thing is - I'm not
running other DOS programs. Only Win32 programs,
using HX.

And even then - I'm only running Win32 programs that
I provide myself. Well - ones that read from the
keyboard and do something with cursor keys, anyway.
And really only one of them even - microemacs 3.6.

> Which is probably why a device driver that remaps the cursor
> keys like that doesn't exist.

Ok, makes sense. Thanks. I have an abnormal use case.
So I'll need to organize that myself.

Actually, the BIOS might be a better place to intercept.
Because if I redirect stdin to a file, for some unusual
situation like automatic commands for microemacs, it would
have the ANSI escapes in there already. And I wouldn't be
able to translate a single ESC pressed by the user into
two ESC for the stream.

And if that command STTY or whatever it is that redirects
stdin to a serial port, was run, and I attached a VT100
or whatever to the serial port, it shouldn't be interfered
with either.

BFN. Paul.

> > ANSIplus is most likely what you need.
>
> Thanks for the link. I tried it and couldn't get it
> to do what I want. I contacted the author but didn't
> get a reply.

I got a reply!

It looks like it does do what I want, but unfortunately
it looks like HX bypasses both DOS and the BIOS and
directly manipulates the keyboard hardware!

So I will need to ask for an enhancement to HX instead.

However, the workaround is to make a DOS version of
Microemacs 3.6, which should at least allow me to edit
small files.

I have done that, but ran into an apparently unrelated
issue trying to test it, so I'll report back when I'm
finished with that.

> > > ANSIplus is most likely what you need.
> >
> However, the workaround is to make a DOS version of
> Microemacs 3.6, which should at least allow me to edit
> small files.
>
> I have done that, but ran into an apparently unrelated
> issue trying to test it, so I'll report back when I'm
> finished with that.

Everything worked!

I have released a new uc8086 at http://pdos.org with
an me.exe

You can edit small files on PDOS/86, and presumably
bigger files with Freedos.

Freedos requires ansiplus installed.

One side-effect was that I can't use cursor up for
command recall on freedos.

Regardless - common source code - all C90-compliant
with ANSI X3.64 extensions. On a mainframe there is
some change to deal with ASCII vs EBCDIC issues, but
that's all.


http://www.sweger.com/ansiplus/AnsiPlus.html

E:\>grep -i ansi config.sys
config.sys: device=C:\ANSIPLUS\ANSIPLUS.exe

E:\>grep -i ansi autoexec.bat
autoexec.bat: path c:\freedos\bin;c:\hx\bin;c:\winpath;d:\dos;
d:\;c:\dospath;c:\watcom\binnt;c:\watcom\binw;c:\ansiplus

E:\>grep -i setaplus autoexec.bat
autoexec.bat: setaplus loadkeys pdoskeys.cfg

E:\>type pdoskeys.cfg
27,27,27
0,72,27,"[A"
0,80,27,"[B"
0,77,27,"[C"
0,75,27,"[D"

E:\>

> > > ANSIplus is most likely what you need.
> >
> It looks like it does do what I want, but unfortunately
> it looks like HX bypasses both DOS and the BIOS and
> directly manipulates the keyboard hardware!

Some completely unrelated work (getting gcc 3.2.3 to
use 64-bit long) triggered a reinvestigation into this.

Starting with Windows PE32. I realized there was a
way to detect whether I had received a single ESC
from Windows, rather than PDOS/386, that needed to
be doubled. That made Windows 10+ work properly for
my ANSI applications.

But I couldn't find any good way to work on Windows
2000, as there is no ANSI support in cmd.exe.

But there is in command.com if I add ansi.sys to
config.nt.

And that allowed me to get MSDOS working without
ansiplus (I instead changed pdpclib). And then I
realized I could change Linux the same way too,
so I did that.

So pre-Win 10 was the only holdout.

Then I realized I might be able to use HX to load
the PE32 in a command.com window in Windows 2000.
But HX refused to load because it said my environment
already support PE32, and I couldn't see an obvious
way to say "do it anyway".

I was thinking of requesting an enhancement to HX,
but then I added "dosonly" to my config.nt and HX
was willing to load and I was able to put in a
different Windows change (customized for pre-Win10),
and hey presto - I could run ANSI-supporting (both
keyboard and screen) Win32 executables under HX on
Windows 2000.

There are probably add-on ANSI drivers to support
ANSI for Win32 before Windows 10 that I could use
instead of HX (and they would be required for
64-bit Windows 7 and 8 for example, where command.com
and thus ansi.sys is no longer available), but HX is
good enough for me, for now.

Windows 2000 is good because it allows me to run
OS/2 1.x programs as well.

It took me quite a while to realize that pdpclib was
the place to make this change instead of changing
every terminal emulator I used or whatever. I was
basically asking the wrong question.

BFN. Paul.

> There are probably add-on ANSI drivers to support
> ANSI for Win32 before Windows 10 that I could use
> instead of HX (and they would be required for
> 64-bit Windows 7 and 8 for example, where command.com
> and thus ansi.sys is no longer available), but HX is
> good enough for me, for now.
>

What's wrong with the included ANSI.SYS that comes with W2k? I think that works well under NTVDM.

If you need an alternative ANSI.SYS for Windows, I think Jason Hood has one:
http://www.adoxa.altervista.org/ansicon/index.html

> Windows 2000 is good because it allows me to run
> OS/2 1.x programs as well.

Why would you want that? Isn't the most software also available on Windows 2000 itself?

Going over several layers of emulation usually is prone to bugs that are hard to debug.

> > I'm confused by this question.
> Actually I was confused by your question!

I am confused by your both. (joke)

DOS it is about MICRO computers (like Commodore, Atari etc).
ANSI-terminal it is from mainframe world.
Why you try to run alien's software?

Or in other words, try to do something, what is require different architecture for hardware and software. This is the same as making tea in a hat. I can say what you meet at end of this road. "dos does not support multitasking and multiusers". IMHO, does not have a sense repeat unix software (till solved this problems). Will be better keep and save exists micro-technology. It can be applicable for micro-controllers, drones etc (Real-time programs are a peak which is unattainable for modern software).

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > There are probably add-on ANSI drivers to support
> > ANSI for Win32 before Windows 10 that I could use
> > instead of HX (and they would be required for
> > 64-bit Windows 7 and 8 for example, where command.com
> > and thus ansi.sys is no longer available), but HX is
> > good enough for me, for now.
>
> What's wrong with the included ANSI.SYS that comes with W2k? I think that
> works well under NTVDM.

I am already using that - for OUTPUT. And as you noted, I need to go to NTVDM. But I still want to run 32-bit software. Win32 executables. And hence - HX.

And for INPUT, I needed to modify my C library (PDPCLIB) to generate the appropriate ANSI escapes for cursor movement (that other application software expects).

> > Windows 2000 is good because it allows me to run
> > OS/2 1.x programs as well.
>
> Why would you want that? Isn't the most software also available on Windows
> 2000 itself?

I am interested in 16-bit software too (as you apparently are too if you are still running MSDOS). So OS/2 1.x is an important part of that.

> Going over several layers of emulation usually is prone to bugs that are
> hard to debug.

The choice is either this or not working at all.

And also I'm the one who is doing any debugging. I might be the only one using it too.

BFN. Paul.

> > > I'm confused by this question.
> > Actually I was confused by your question!
>
> I am confused by your both. (joke)
>
> DOS it is about MICRO computers (like Commodore, Atari etc).
> ANSI-terminal it is from mainframe world.

ANSI terminals are not from the mainframe (which
doesn't really support them - although you can
quibble about that). But generally mainframes
only use block mode devices.

But regardless, ANSI/VT100 is what was standardized.

I have spent decades making the mainframe conform
to that standard (except I made it EBCDIC instead
of ASCII).

MSDOS 1.0 was probably written using a VT100
terminal connected to a PC, and I assume ANSI
has always been an option.

I don't see anything wrong with sticking with
what was standardized.

The Commodore Amiga and 68000-based Atari both
support ANSI X3.64 too. In actual fact - that
is what I have been interested in for nearly
40 years - what is preventing people from
switching from the IBM PC to the Amiga?

> Or in other words, try to do something, what is require different
> architecture for hardware and software. This is the same as making tea in a
> hat.

The standard is not so onerous that it can't
be implemented on a PC.

What do you suggest as an alternative anyway if
you want to write portable fullscreen character
applications?

Or are you saying it is impossible to make them
portable?

> I can say what you meet at end of this road. "dos does not support
> multitasking and multiusers". IMHO, does not have a sense repeat unix
> software (till solved this problems). Will be better keep and save exists
> micro-technology. It can be applicable for micro-controllers, drones etc
> (Real-time programs are a peak which is unattainable for modern software).

If you don't have a fullscreen application, you are
not affected regardless.

This is for people who want a fullscreen editor, like
microemacs, instead of a line mode editor like edlin.

BFN. Paul.

> I am already using that - for OUTPUT. And as you noted, I need to go to
> NTVDM. But I still want to run 32-bit software. Win32 executables. And
> hence - HX.
>

Well, to me it sounds like all this could be done much simpler. Like, running it in pure DOS or even DOSEmu on Linux should do the work in much simpler way (and it's likely to have a builtin debugger).

But, I don't mind. It's your project, so you do you. :)

> And for INPUT, I needed to modify my C library (PDPCLIB) to generate the
> appropriate ANSI escapes for cursor movement (that other application
> software expects).
>

Cool. I can stand behind that. :)

> I am interested in 16-bit software too (as you apparently are too if you
> are still running MSDOS). So OS/2 1.x is an important part of that.
>

You want to implement 16-bit OS/2 runtime on PDOS/386?

Well, if that's what your goal is, take a look at the following projects:
https://github.com/icculus/2ine
https://github.com/osfree-project

Or you just want to have ability to run 16-bit OS/2 apps on your development machine?

> And also I'm the one who is doing any debugging. I might be the only one
> using it too.

Well, have fun. :P

> > I am already using that - for OUTPUT. And as you noted, I need to go to
> > NTVDM. But I still want to run 32-bit software. Win32 executables. And
> > hence - HX.
>
> Well, to me it sounds like all this could be done much simpler. Like,
> running it in pure DOS

If I just wanted to run this one Win32 executable,
I could indeed use pure DOS.

But what if I want to run Visual Studio 2005 Professional
to produce Win32 and Win64 Hercules/380 executables?

The development machine I have chosen is Windows 2000.
The last version that didn't require activation.

I run that under Virtualbox under Windows 10 currently.

On a Chinese-made computer with a Zhaoxin processor.

> or even DOSEmu on Linux should do the work in much
> simpler way (and it's likely to have a builtin debugger).

I have tested that I can run my Virtualbox + Windows
2000 under Linux if necessary, but for now I am happy
to run under Windows 10.

> > I am interested in 16-bit software too (as you apparently are too if you
> > are still running MSDOS). So OS/2 1.x is an important part of that.
>
> You want to implement 16-bit OS/2 runtime on PDOS/386?

No. Currently PDOS/86 uses the MSDOS API. I am
tentatively planning to switch to the OS/2 1.x
API for both RM16 and PM16.

Note that MSDOS 4.0 (which I have never used) was
able to load NE executables. But I assume that
executed DOS interrupts. I would instead (pretend
to) be loading an OS/2 1.x DLL (I need to find out
what Microsoft C 6.0 produces for its DLL - similar
to MSVCRT.DLL but with no standardized name) -
including on RM16.

> Well, if that's what your goal is, take a look at the following projects:
> https://github.com/icculus/2ine
> https://github.com/osfree-project

Both of those are copyright, so not what I'm after.

> Or you just want to have ability to run 16-bit OS/2 apps on your
> development machine?

I want that TOO. And that's ALL I want currently. I
haven't started the switch from MSDOS to OS/2 1.x.
I have other priorities at the moment (gccx64).

BFN. Paul.