PDOS-generic change

[[e-mail]]

I had previously proposed having an osfunc() call
in PDPCLIB which would turn into an execution of
the C library in PDOS-generic. This would then
create new executables, not compatible with
anything except PDOS-generic.

However, I've thought of a compromise. What I
can do is have a flavor of PDOS-generic that
basically exports msvcrt.dll.

So PDPCLIB-based applications that have been
built with msvcrt will work on both normal
Windows and modified PDOS-generic. As well
as PDOS/386.

I note that the way I currently build executables on
Windows, msvcrt.dll is the only dependency, there
is no kernel32.dll listed. My current msvcrt.dll does
use kernel32.dll, but my new one tied to
PDOS-generic presumably won't, as I'm not actually
trying to support the Windows API in PDOS-generic,
just C90.

On the mainframe I think I will support the original
osfunc() plan, as I don't see any way around needing
new executables for that environment. I'm not sure
if the msvcrt.dll paradigm could be exported as-is
to the mainframe and whether that would serve
some purpose. Presumably this would mean
PE/COFF executables on the mainframe, so that the
DLL dependencies could be listed.

Maybe that would be a reasonable replacement for
PDOS-generic - PE/COFF executables dependent on
msvcrt.dll, available on every platform, starting with
the mainframe.

BFN. Paul.

[Melzzzzz]

Post by ***@gmail.com
some purpose. Presumably this would mean
PE/COFF executables on the mainframe, so that the
DLL dependencies could be listed.

Ahahahhahahhaha.

[[e-mail]]

Post by Melzzzzz

Post by ***@gmail.com
some purpose. Presumably this would mean
PE/COFF executables on the mainframe, so that the
DLL dependencies could be listed.

Ahahahhahahhaha.

Do you see some technical problem with that?

Note that there wouldn't be a real msvcrt.dll on
either modified PDOS-generic on the PC or on
the mainframe. It would just be modified
PDOS-generic exporting its own linked-in C
library. Assuming that is technically possible.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
Note that there wouldn't be a real msvcrt.dll on
either modified PDOS-generic on the PC or on
the mainframe. It would just be modified
PDOS-generic exporting its own linked-in C
library. Assuming that is technically possible.

And maybe PE/COFF modules which are only
dependent on msvcrt.dll could be loaded by
PDOS/86 too, just in real mode, just with 8086
instructions?

And they would work on the theoretical 8086+
with 16-bit segment shifts too?

Note that I am only supporting relocatable
PE/COFF modules.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
And maybe PE/COFF modules which are only
dependent on msvcrt.dll could be loaded by
PDOS/86 too, just in real mode, just with 8086
instructions?

And the exact standard 32-bit PE/COFF executable
format would be used, with flat 32-bit addresses.

I'm not sure what markup should be done so that
PDOS/86 can identify this as an 8086 executable
(and all the relocatable addresses should be
updated with a segmented address) rather than an
80386 executable (where all the relocatable addresses
would remain flat).

For the 8086+, addresses would effectively remain flat.
The main difference with the 8086+ is that the executable
needs to be loaded onto a 64k boundary, at least
potentially, and the linker needs to ensure that functions
don't straddle a 64k boundary, and PE/COFF seems to be
designed for this situation:

/* Virtual size of a section is larger than in file,
* so the difference is filled with 0. */
if (section->VirtualSize > section->SizeOfRawData)
{
memset(exeStart
+ section->VirtualAddress
+ section->SizeOfRawData,
0,
section->VirtualSize - section->SizeOfRawData);
size_in_file = section->SizeOfRawData;
}

As far as I can tell, a large memory model program
doesn't need to have any embedded segment shift
information, and should be relinkable to work on an
8086+, and if you just produce an 8086+ module, it
doesn't need to be relinked to work on an 8086, it
just may use extra memory for the executable.

A very huge Smaller C module would need to be
recompiled though, because the segment shift is
embedded throughout the code.

Ideally there would be an msvcrt.dll equivalent for
both very huge and large memory models. The
PE/COFF module presumably needs appropriate
markup in the header for that.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
As far as I can tell, a large memory model program
doesn't need to have any embedded segment shift
information, and should be relinkable to work on an
8086+, and if you just produce an 8086+ module, it
doesn't need to be relinked to work on an 8086, it
just may use extra memory for the executable.

And it would be good if the linker printed out how
much extra padding needed to be added, so that
you know whether to bother creating a separate
8086 executable.

Also, I don't see any reason why PE/COFF is needed
at all. The existing MZ executable format should
work fine, unless you wish to make use of msvcrt.dll.

However, I now know where a problem lies.

When it comes time to do an MSDOS interrupt,
you need to convert a far pointer into a segment
and offset in order to put them into proper registers,
and it is more convenient to do this in C, using
something like FP_SEG() and FP_OFF().

So this is the point where (at least I) convert a
far pointer to an unsigned long and shift 16
bits.

But I would rather have far pointer conversions
produce an absolute address, so that I can do
the reverse, ie char *vidbuf = (char *)0xb8000;

And actually, the above statement requires
knowledge of the number of bit shifts too.

I think for the vidbuf example we need the compiler
to generate a function call, and that function call
can see whether this is the first call, and if so, it
does an MSDOS-extended interrupt which returns
two values in say cx and dx. cx is the number of
bits to shift, and dx is the value that needs to be
added to a segment whenever you exceed 64k in
the offset, for use by huge pointers.

FP_SEG and FP_OFF can similarly be function
calls. but you don't need to know the number of
bits to shift, you just need to get the first or last
16 bits of the pointer.

With the vidbuf example, it's probably best to put
that in a macro too, ABS2ADDR() which does the
function call, so that you're not dependent on the
compiler to be so smart.

I believe FP_SEG and FP_OFF are existing practice
for writing MSDOS programs, but is there an
existing practice for ABS2ADDR and ADDR2ABS?

Actually, whatever existing or new practice is, I
think this should be part of C90+ - people should
stop coding absolute addresses with a (char *)
cast, and use a macro instead, to allow alternate
compilers to be used.

And obviously ideally there would be an MSDOS
call to get the video buffer, or people would be
writing ANSI terminal codes instead. But there
may be other applications where an absolute
address needs to be used, outside of MSDOS's
knowledge (or a non-MSDOS, non-PC environment
too).

Any suggestions?

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com
And maybe PE/COFF modules which are only
dependent on msvcrt.dll could be loaded by
PDOS/86 too, just in real mode, just with 8086
instructions?

Actually, I think I should support a subset of
kernel32.dll too. Specifically whatever the functions
are that deal with reading directories, so that my
"command.com" can do a "dir". And "rm -f *.o" can
be written too.

Basically Win32 can inspire a rewrite of MSDOS.

And the mainframe would support this limited Win32
API too.

That seems to be the point of harmonization.

Windows 10 finally supported a way of supporting an
ANSI terminal too.

I think the following layers should exist:

MBR
boot sector
loader
32-bit BIOS
generic BIOS
OS
application

And it is at the “generic BIOS” layer (see bios/bios.c)
that the ANSI control codes need to be interpreted,
with that layer responsible for knowing how to talk
to different hardware, including VGA monitors and
VT100 terminals and IBM PC BIOSes.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
Basically Win32 can inspire a rewrite of MSDOS.
And the mainframe would support this limited Win32
API too.
That seems to be the point of harmonization.

Although I think the osfunc() model is probably better.
I don't like DLLs.

Maybe I can implement both.

BFN. Paul.

[Rod Pemberton]

On Sun, 18 Apr 2021 13:54:37 -0700 (PDT)

Post by ***@gmail.com

Post by ***@gmail.com
Basically Win32 can inspire a rewrite of MSDOS.
And the mainframe would support this limited Win32
API too.
That seems to be the point of harmonization.

Although I think the osfunc() model is probably better.
I don't like DLLs.
Maybe I can implement both.

One of the things I found with my OS and some of my personal apps is
that the more uniform they are, the more maintainable they are.

I was using both OpenWatcom and DJGPP (GCC with custom DOS library) for
DOS for them. At first, I would just add custom code via #ifdef as
needed, where needed, but these apps became very messy and less
readable. Now, some of them are ported to Linux too using GCC with
GLIBC.

All three compilers have different methods of doing colored text. So,
I pushed that code down into the lowest level functions, e.g., to
"hide" them, which made my apps more consistent, more readable, less
complex, and easier to port.

So, if you're going to take this approach, you might look how they
implement wrapper style libraries designed for games and OS
development, which have low-level hardware support, like libSDL:

https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer
https://www.libsdl.org/

Many significant games have been coded using libSDL, although it could
be used for coding an OS or a GUI too.

If you're not familiar with libSDL, you might've heard of less
developed libraries like Allegro or SVGAlib.

--