DOS ain't dead

> Also I noticed that this has things like DosWrite().
> This is basically an early incarnation of OS/2 - and
> one that looks better to me - ie it doesn't use the
> ULONG etc.

Just to expand - Microsoft *did* create a C-callable
interface to MSDOS - ie DosWrite() etc. This is apart
from anything they included in their C compiler
(write() or whatever - not sure what they provided).

And if you accept the legitimacy of the DosWrite()
call interface (used - albeit barely - by Microsoft's
own utilities), like:

v4.0/src/CMD/RESTORE/RTFILE.C

/*************************************************************/
/* write to dest file */
/*************************************************************/
retcode =
DOSWRITE
(dest_file_handle,
(char far *)&buf_pointer[0],
(unsigned) numread,
(unsigned far *) &numwrite
);

Then the definition of "32-bit MSDOS" would be:

v4.0/src/H/DOSCALLS.H

extern unsigned far pascal DOSWRITE (
unsigned,
char far *,
unsigned,
unsigned far * );

but those 16-bit unsigned parameters now naturally
morph into 32-bit (exactly what should happen for
a transition to 32-bit), and the pointers remain
as 32-bit, but obviously the "far" keyword is no
longer applicable, and they are flat pointers.

Since a recompilation is being done regardless, the
"pascal" calling convention could be dropped in
favor of cdecl.

And given the naming convention, you end up with
something similar to OS/2.

OS/2 in actuality went with:

USHORT APIENTRY DosWrite(USHORT hfile, void *ptr,
USHORT towrite, USHORT *tempWritten);

for 16-bit

and:

ULONG APIENTRY DosWrite(ULONG hfile, void *ptr,
ULONG towrite, ULONG *tempWritten);


ie the source code is not compatible.

In actuality you can simply ignore the official OS/2
documentation and use the MSDOS 4.0 definitions and
source, and it will happen to work with both 16-bit
and 32-bit OS/2.

So I would suggest that this (MSDOS 4.0) should be
adopted as the official standard to use instead of
POSIX or Windows or OS/2 (I don't like any of them
except the OS/2 function names), and provide existing
use (MSDOS 4.0, OS/2 1.x, Windows up to 2000, OS/2 2.0+).

The existing header file - doscalls.h - could be used too.

And the nature of the beast means that a thin wrapper
could be written to translate that into Win32 equivalents
so that everything from Win 95 to Win 11 is also covered.

Any thoughts?

BFN. Paul.

> Using just this disk - ie just the raw DOS 4.0 files -
> I could theoretically write a program to convert
> LF to CRLF etc rather than just copying an unzip
> program across. I already have a crlffix - I could
> copy that across instead and likely compile it.
>
> Not sure what a sensible goal here would be.

It may not qualify as "sensible", but I am formulating
a goal now.

There was this Kon-Tiki Expedition on a balsa wood raft:

https://en.wikipedia.org/wiki/Kon-Tiki_expedition

https://www.google.com.ph/books/edition/Kon_Tiki/x...ric+raft%22&pg=PT35&printsec=frontcover

“Radio!” I said, horrified. “What the hell do we want with that? It’s
out of place on a prehistoric raft.”

“Not at all—it’s a safety precaution which won’t have any effect on
your theory so long as we don’t send out any SOS for help. And we shall
need the radio to send out weather observations and other reports. But
it’ll be no use for us to receive gale warnings because there are no reports
for that part of the ocean, and, even if there were, what good would they
be to us on a raft?”


So now, using just the DOS 4.0 distribution, and any public domain
source code I can obtain, how far can I get on an XT with 640k in
preparation for jumping to an AT or 386? And perhaps only using
things that I have documented on the disk.

So long as I don't exceed the memory available on the machine
in those days, it doesn't matter if I am instead running under
qemu.

In fact, PdAndro is coming into view (we should find out soon
if it is accepted on the Google Play Store), so I might be able
to write my own 8086 emulator and do it on a Smartphone.

I already have the beginnings of an 8086 emulator.

I've done a lot of cleanup and I am doing a new build at
the moment.

BFN. Paul.

> The CRLF hit harder for some reason, so the files like
> chdir.asm will choke with either a hang or spurious errors.
>
> Using just this disk - ie just the raw DOS 4.0 files -
> I could theoretically write a program to convert
> LF to CRLF etc rather than just copying an unzip
> program across. I already have a crlffix - I could
> copy that across instead and likely compile it.

Both of these [2021] goofy kludges are very simple hacks to workaround a flaw
in [then] current versions of A72 assembler (e.g. 1.03a) where it won't read
properly from *nix-only text files (LF-only ending).

N.B. public domain, free for any use.

crlffile.asm

org 100h ; public domain, nenies proprajho

DOS equ 21h
ARGC equ 80h
ARGV equ 82h
CR equ 13
LF equ 10
OPENFILEREAD equ 3D00h
CREATEFILE equ 3Ch
CLOSEFILE equ 3Eh

Komenco:
  mov si,ARGC
  cmp byte[si+1],CR
  jz Fino
  xor bh,bh
  mov bl,byte[si]
  mov byte[si+bx+1],bh
OpenFiles:
  mov ax,OPENFILEREAD
  mov dx,ARGV
  int DOS
  jc Fino
  mov [inhandle],ax
  mov ah,CREATEFILE
  xor cx,cx
  mov dx,outfile
  int DOS
  jc Fino
  mov [outhandle],ax
  call main
CloseFiles:
  mov ah,CLOSEFILE
  mov bx,[inhandle]
  int DOS
  mov ah,CLOSEFILE
  mov bx,[outhandle]
  int DOS
  dec byte[err]
Fino:
  mov ax,[err]
  int DOS

main:
  call readbyte
  test ax,ax
  jz main_ret
  cmp byte[buf],LF
  jnz main_write
  mov dl,byte[buf]
  push dx
  mov byte[buf],CR
  call writebyte
  pop dx
  mov byte[buf],dl
main_write:
  call writebyte
  jmp short main
main_ret:
  ret

readbyte:
  mov ah,3Fh
  mov bx,[inhandle]
  mov cx,1
  mov dx,buf
  int DOS
readbyte_ret:
  ret

writebyte:
  mov ah,40h
  mov bx,[outhandle]
  mov cx,1
  mov dx,buf
  int DOS
  ret

outfile db 'CRLF.OUT',0
err db 1,4Ch
inhandle dw 0
outhandle dw 0
buf db 0

; EOF


crlf.asm

org 100h ; public domain, nenies proprajho

DOS equ 21h
CR equ 13
LF equ 10
EXIT equ 4C00h
ISKEYPRESS equ 0Bh
READ equ 8
WRITE equ 2

Komenco:
  mov ah,ISKEYPRESS
  int DOS
  test al,al
  jz Fino
  mov ah,READ
  int DOS
  cmp al,LF
  jnz WriteIt
AddCR:
  push ax
  mov dl,CR
  mov ah,WRITE
  int DOS
  pop ax
WriteIt:
  mov dl,al
  mov ah,WRITE
  int DOS
  jmp short Komenco
Fino:
  mov ax,EXIT
  int DOS

; EOF