Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

kerravon

Ligao, Free World North,
30.10.2021, 10:02

PDOS-generic (Announce)

I have done a "proof of concept" for PDOS-generic.
This allows you to use an existing operating system,
e.g. Amiga OS (which has no BIOS) as a glorified
BIOS, so that an MSDOS-like OS (PDOS-generic) can
be run under it.

At native CPU speed. With no emulator.

Disks are still emulated using a host disk file.

The code is pure C90 so can be taken anywhere.
Executables are tiny because they use the C library
that is exported by the OS.

So far I haven't found any show-stoppers, although
I didn't know that when doing the development.

I'm interested in any technical analysis.

Executables for Windows can be obtained from the
bottom of http://pdos.org

To have a look at how it was implemented, the main
file is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/generic/pdos.c

BFN. Paul.

kerravon

Ligao, Free World North,
31.10.2021, 06:40

@ kerravon

PDOS-generic

> I have done a "proof of concept" for PDOS-generic.

I've just realized something.

This constitutes an alternate vision for what a
32-bit version of MSDOS should look like.

It still has an MSDOS-like API, but because they
are wrapped in C functions instead of directly
coding an INT 21H, I was able to bypass the
application coding an INT 21H. That could be
added, but it would happen outside of the
application.

And a C library is provided too. Why not?

And the BIOS layer could in fact be standalone,
or even UEFI-based, rather than being dependent
on some other OS such as Amiga OS.

BFN. Paul.

kerravon

Ligao, Free World North,
31.10.2021, 09:43

@ kerravon

PDOS-generic

Something else occurred to me.

1. Would it have been feasible for MSDOS to have
been written in C instead of assembler, and (with
the benefit of hindsight) waited for compilers to
become better and RAM to become cheaper, and
possibly distributed multiple versions of the
product with different memory requirements.

2. Assuming people are happy with the PDOS-generic
design of passing an array of OS functions as a
simple stack parameter, could this have been done
for the 16-bit MSDOS too?

The timeline I have is that MSDOS 1.0 was released
in 1981 and MSDOS 2.0 in 1983. I think we can ignore
1.0 because that is effectively CP/M, and has a
different design consideration.

With the benefit of hindsight, the 80386 was coming
out in 1986. 32-bit OS/2 2.0 was released in 1992.

Assume people have the application source code in C
available, and that a 32-bit C compiler was also
made available in a timely manner, and that people
are happy to produce 2 versions of their software
for people who have memory constraints.

Actually, there's an alternative. Using 80386
selectors, and setting the D bit to 16-bit default,
it is actually possible to address up to 512 MiB
of memory using pure 16-bit instructions. That
could have alleviated memory pressure too. The
important thing is to not hardcode a segment shift
value of 4. MSDOS could have provided a call to
retrieve that value if you needed it for some
reason. Maybe a 16-bit processor with these
characteristics could have been produced faster
than waiting for the 80386 (that included them,
along with proper 32-bit mode).

By 1985, 512K memory was US$210, which is probably
a point where you shouldn't be making design
decisions based on saving m*oney on RAM.

Another consideration is that the C standard wasn't
actually ratified until 1989-1990, so there is some
difficulty exporting a C library to applications.
With the benefit of hindsight we know what the C
standard is, and it is something that could have
been written in 1980. Let's assume that we had the
C standard and appropriate compilers and libraries
in 1980, and we were just waiting for someone to
authorize the writing of MSDOS 2.0 with a fresh
API, to be delivered in 1983.

Hold the use of the 8086 and the 80386 constant.
Hold the C90 standard constant, but backdated to
1980. Hold memory prices constant. What could have,
or should have been done, with the benefit of
hindsight, and flexibility in software choices?
ie what options did humanity have available, but
missed?

BFN. Paul.

ecm

Düsseldorf, Germany,
31.10.2021, 22:11

@ kerravon

PDOS-generic

> Hold the use of the 8086 and the 80386 constant.
> Hold the C90 standard constant, but backdated to
> 1980. Hold memory prices constant. What could have,
> or should have been done, with the benefit of
> hindsight, and flexibility in software choices?
> ie what options did humanity have available, but
> missed?

I just dream of a world in which IBM honoured that interrupts 00h to 1Fh were declared reserved for the CPU by Intel. Would make debugging and hardware interrupt requests a lot easier. (lDebug doesn't hook the Real 86 Mode interrupt 0Dh, which would be useful as GPF handler but overlaps with an IRQ handler.)

---
l

kerravon

Ligao, Free World North,
31.10.2021, 22:29

@ ecm

PDOS-generic

> > Hold the use of the 8086 and the 80386 constant.
> > Hold the C90 standard constant, but backdated to
> > 1980. Hold memory prices constant. What could have,
> > or should have been done, with the benefit of
> > hindsight, and flexibility in software choices?
> > ie what options did humanity have available, but
> > missed?
>
> I just dream of a world in which IBM honoured that interrupts 00h to 1Fh
> were declared reserved for the CPU by Intel. Would make debugging and
> hardware interrupt requests a lot easier. (lDebug doesn't hook the Real 86
> Mode interrupt 0Dh, which would be useful as GPF handler but overlaps with
> an IRQ handler.)

I looked that up:

http://www.ctyme.com/intr/int-0d.htm

What is it that links IRQ5 to INT 0Dh? Can that
be changed, on your PC at least?

ecm

Düsseldorf, Germany,
31.10.2021, 22:32

@ kerravon

PDOS-generic

> I looked that up:
>
> http://www.ctyme.com/intr/int-0d.htm
>
> What is it that links IRQ5 to INT 0Dh? Can that
> be changed, on your PC at least?

You can generally reconfigure the PIC to provide the IRQs on some other group of interrupt numbers. Most 32-bit systems (including JEMM386 I believe) do that. However, a 86-DOS-compatible system will still serve the IRQ on the traditional interrupt 0Dh when it is passed to 86 Mode.

---
l

kerravon

Ligao, Free World North,
31.10.2021, 22:46

@ ecm

PDOS-generic

> > I looked that up:
> >
> > http://www.ctyme.com/intr/int-0d.htm
> >
> > What is it that links IRQ5 to INT 0Dh? Can that
> > be changed, on your PC at least?
>
> You can generally reconfigure the PIC to provide the IRQs on some other
> group of interrupt numbers. Most 32-bit systems (including JEMM386 I
> believe) do that. However, a 86-DOS-compatible system will still serve the
> IRQ on the traditional interrupt 0Dh when it is passed to 86 Mode.

But if you used say Freedos you could change that
behavior by changing the Freedos source code?

BFN. Paul.

tom

Germany (West),
02.11.2021, 18:25

@ kerravon

PDOS-generic

> But if you used say Freedos you could change that
> behavior by changing the Freedos source code?

nope. you won't even find a single line dealing with hardware stuff.

not interrupt vectors, not I/O addresses.

neither in the kernel nor anywhere else.

ANYDOS relies on the BIOS to do these things. entirely.

otoh applications are allowed (or in the case of serial communications required) to make these changes. and have to check if this is compatible with all the other - more or less - interesting stuff running on the machine at the same time, like network adapters, industrial interface cards, etc.

good luck with defining your own rules to be followed by everybody else.

kerravon

Ligao, Free World North,
02.11.2021, 21:29

@ tom

PDOS-generic

> > But if you used say Freedos you could change that
> > behavior by changing the Freedos source code?
>
> nope. you won't even find a single line dealing with hardware stuff.
>
> not interrupt vectors, not I/O addresses.
>
> neither in the kernel nor anywhere else.
>
> ANYDOS relies on the BIOS to do these things. entirely.

I see. Note that PDOS/386 does that too.

But is there any reason why Freedos can't change
the PIC to put the interrupts elsewhere and then
copy the existing interrupt vectors to that new
location? Or is the problem that the BIOS hardcodes
the INT 0Dh?

> otoh applications are allowed (or in the case of serial communications
> required) to make these changes. and have to check if this is compatible
> with all the other - more or less - interesting stuff running on the
> machine at the same time, like network adapters, industrial interface
> cards, etc.

If applications can do it, why not the OS? Also,
why did you say serial communications are required
to make changes? They can call INT 14h, can't they?

> good luck with defining your own rules to be followed by everybody else.

Depending on the use case, it only has to be good
enough to work on ecm's machine. I don't know what
he is running.

BFN. Paul.

ecm

Düsseldorf, Germany,
03.11.2021, 08:54

@ kerravon

PDOS-generic

> > good luck with defining your own rules to be followed by everybody else.
>
> Depending on the use case, it only has to be good
> enough to work on ecm's machine. I don't know what
> he is running.

I'm not a "he".

---
l

kerravon Ligao, Free World North, 03.11.2021, 19:48 @ ecm	PDOS-generic Post reply
	> > > good luck with defining your own rules to be followed by everybody > else. > > > > Depending on the use case, it only has to be good > > enough to work on ecm's machine. I don't know what > > he is running. > > I'm not a "he". Apologies. In particular for the 300+ PMs you must have received after posting that.

marcov

02.11.2021, 19:42

@ kerravon

PDOS-generic

> Something else occurred to me.
>
> 1. Would it have been feasible for MSDOS to have
> been written in C instead of assembler, and (with
> the benefit of hindsight) waited for compilers to
> become better and RAM to become cheaper, and
> possibly distributed multiple versions of the
> product with different memory requirements.

The first Dos systems had 64kb. Even when there was more memory the space occupied by nested shells also needed to be minimized.

Low memory directly affected the apps that you wanted to run, it was a different time.

Only with the more 386 oriented 5 and 6 versions that could have changed, (e.g. 4dos had very low shell overhead by using XMS).

> With the benefit of hindsight, the 80386 was coming
> out in 1986. 32-bit OS/2 2.0 was released in 1992.

Note that in 1992/93 286s were still sold new, and 386sx (and DX even more so) were still high end.

> Assume people have the application source code in C
> available, and that a 32-bit C compiler was also
> made available in a timely manner, and that people
> are happy to produce 2 versions of their software
> for people who have memory constraints.

A good, industry wide solution for 386 apps in e.g. the early nineties would have been welcomed, tools inclusive.

> By 1985, 512K memory was US$210, which is probably
> a point where you shouldn't be making design
> decisions based on saving m*oney on RAM.

I would take msdos 5 as more logical point at which a change should have been forced. By then, new machines routinely were 1MB or more, and 386s started to penetrate.

> Another consideration is that the C standard wasn't
> actually ratified until 1989-1990, so there is some
> difficulty exporting a C library to applications.

The C standard has nothing to do with any of this.

> With the benefit of hindsight we know what the C
> standard is, and it is something that could have
> been written in 1980.

Before the standard, there was K&R, ..... if you were an Unix workstation programmer. But in Dos, C was only emerging. Apple and Microsoft (both Unix licensees and vendors!) switched to C, but the application programmers despised it, because it too often was combined with abstraction layers that were considered useless overhead.

> Let's assume that we had the
> C standard and appropriate compilers and libraries
> in 1980, and we were just waiting for someone to
> authorize the writing of MSDOS 2.0 with a fresh
> API, to be delivered in 1983.

> Hold the use of the 8086 and the 80386 constant.
> Hold the C90 standard constant, but backdated to
> 1980. Hold memory prices constant. What could have,
> or should have been done, with the benefit of
> hindsight, and flexibility in software choices?
> ie what options did humanity have available, but
> missed?

Maybe it would have had an impact on Unix fragmentation, but I doubt it would have affected dos that much.

I do think maybe 32-bit could have emerged as the norm for applications earlier (than 1995+ with win95), but that is only weakly correlated with C.

kerravon

Ligao, Free World North,
02.11.2021, 22:00

@ marcov

PDOS-generic

> > With the benefit of hindsight, the 80386 was coming
> > out in 1986. 32-bit OS/2 2.0 was released in 1992.
>
> Note that in 1992/93 286s were still sold new, and 386sx (and DX even more
> so) were still high end.

Thanks for the info.

> > Assume people have the application source code in C
> > available, and that a 32-bit C compiler was also
> > made available in a timely manner, and that people
> > are happy to produce 2 versions of their software
> > for people who have memory constraints.
>
> A good, industry wide solution for 386 apps in e.g. the early nineties
> would have been welcomed, tools inclusive.

GCC couldn't fit the bill? Can you give an example
of what would have been good and technologically
possible? And whether the starting point would
have needed to be before the 80386 came out in
1986. Note that most of a 32-bit C compiler can
be written without a specific 32-bit processor.

> > By 1985, 512K memory was US$210, which is probably
> > a point where you shouldn't be making design
> > decisions based on saving m*oney on RAM.
>
> I would take msdos 5 as more logical point at which a change should have
> been forced. By then, new machines routinely were 1MB or more, and 386s
> started to penetrate.

Ok, so that's 1991. What specific change would
you have forced?

> > Another consideration is that the C standard wasn't
> > actually ratified until 1989-1990, so there is some
> > difficulty exporting a C library to applications.
>
> The C standard has nothing to do with any of this.

I think it is good for programmers to have a set
of rules which are known to work cross-platform,
and are accepted internationally, which only
happened in 1990.

> > With the benefit of hindsight we know what the C
> > standard is, and it is something that could have
> > been written in 1980.
>
> Before the standard, there was K&R, ..... if you were an Unix workstation
> programmer. But in Dos, C was only emerging. Apple and Microsoft (both Unix
> licensees and vendors!) switched to C, but the application programmers
> despised it, because it too often was combined with abstraction layers that
> were considered useless overhead.

What abstraction layer are you talking about?
fopen/fread? Was the complaint valid? Was there
a solution to the complaint that wouldn't have
involved abandoning C entirely? (in favor of
assembler I assume).

> > Let's assume that we had the
> > C standard and appropriate compilers and libraries
> > in 1980, and we were just waiting for someone to
> > authorize the writing of MSDOS 2.0 with a fresh
> > API, to be delivered in 1983.
>
> > Hold the use of the 8086 and the 80386 constant.
> > Hold the C90 standard constant, but backdated to
> > 1980. Hold memory prices constant. What could have,
> > or should have been done, with the benefit of
> > hindsight, and flexibility in software choices?
> > ie what options did humanity have available, but
> > missed?
>
> Maybe it would have had an impact on Unix fragmentation, but I doubt it
> would have affected dos that much.

It took me a while to realize you meant "different
versions of Unix" rather than "memory fragmentation
within a particular Unix running instance". :-)

> I do think maybe 32-bit could have emerged as the norm for applications
> earlier (than 1995+ with win95), but that is only weakly correlated with C.

Do you think that C wrappers for the MSDOS API,
combined with a 32-bit version of MSDOS, would
have achieved that and been a good thing?

I have been writing wrappers for decades, but
even without them, MSDOS C compilers did come
with wrappers with similar functionality. Here
is one of my wrappers:

int PosFindFirst(char *pat, int attrib)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;

regsin.h.ah = 0x4e;
regsin.x.cx = attrib;
#ifdef __32BIT__
regsin.d.edx = (int)pat;
#else
regsin.x.dx = FP_OFF(pat);
sregs.ds = FP_SEG(pat);
#endif
int86x(0x21, &regsin, &regsout, &sregs);
if (regsout.x.cflag)
{
return (regsout.x.ax);
}
else
{
return (0);
}
}

BFN. Paul.

marcov

03.11.2021, 16:43

@ kerravon

PDOS-generic

> > A good, industry wide solution for 386 apps in e.g. the early nineties
> > would have been welcomed, tools inclusive.
>
> GCC couldn't fit the bill?

DJGPP on extender V2 had its first release in 1996, by then the beginning of the end for Dos had already started.

Djgpp v1 was cumbersome and not selfhosted (needed licensed Borland compiler to compile)

Moreover gcc was only the toolchain side of the problem (if you liked C to begin with).

The core problem was not having a stable 32-bit application interface built into dos. DJGPP still thunks through the extender to access the old 16-bit interrupt calls. _NOW_ in 2021.

> Can you give an example
> of what would have been good and technologically
> possible?

Extender and long term stable 32-bit API built into dos.

> And whether the starting point would
> have needed to be before the 80386 came out in
> 1986.

Maybe having it early (before '90-92) would have created more of a driving force for 386 sales.

> Note that most of a 32-bit C compiler can
> be written without a specific 32-bit processor.

It is not just about the compiler.

> > I would take msdos 5 as more logical point at which a change should have
> > been forced. By then, new machines routinely were 1MB or more, and 386s
> > started to penetrate.
>
> Ok, so that's 1991. What specific change would
> you have forced?

Extender built in, 32-bits API (dos interface).

Note that to a certain degree this was the case (himem/emm386) for memory usage, but not for the rest.

> I think it is good for programmers to have a set
> of rules which are known to work cross-platform,
> and are accepted internationally, which only
> happened in 1990.

If you mean POSIX, the attempt at Unix reunification that was later rebranded as universal, that was first published in 1988, and was already in the works since 1995.

But the universality of that was always more a wish from the unix crowd than an absolute fact, and worse only about reuse of application in source form.

> > Before the standard, there was K&R, ..... if you were an Unix
> workstation
> > programmer. But in Dos, C was only emerging. Apple and Microsoft (both
> Unix
> > licensees and vendors!) switched to C, but the application programmers
> > despised it, because it too often was combined with abstraction layers
> that
> > were considered useless overhead.
>
> What abstraction layer are you talking about?
> fopen/fread?

32-bits alternatives for many used dos/bios calls.Though that would probably hit the roof of shared services and drivers and thus compatibility.

And that is probably all the reasons why this all didn't happen. The major vendors recognized this and had already embarked on quests for WinNT and OS/2.

> Was the complaint valid?

Yes. 16-bit code being tight was very important. 640kb simply wasn't enough.

> Was there
> a solution to the complaint that wouldn't have
> involved abandoning C entirely? (in favor of
> assembler I assume).

There was, but the resulting C would be a mix of HLL and assembler. IOW the C would be for productivity reasons only, and the result would not be portable.

That latter aspect only emerged in the mid nineties, and even then slowly.

> > Maybe it would have had an impact on Unix fragmentation, but I doubt it
> > would have affected dos that much.
>
> It took me a while to realize you meant "different
> versions of Unix" rather than "memory fragmentation
> within a particular Unix running instance". :-)

Hehe.

> > I do think maybe 32-bit could have emerged as the norm for applications
> > earlier (than 1995+ with win95), but that is only weakly correlated with
> C.
>
> Do you think that C wrappers for the MSDOS API,
> combined with a 32-bit version of MSDOS, would
> have achieved that and been a good thing?

A 32-bits API, memorymodel, and some associated toolchain.

> I have been writing wrappers for decades, but
> even without them, MSDOS C compilers did come
> with wrappers with similar functionality. Here
> is one of my wrappers:

I have been modifying and writing Pascal and Modula2 RTLs for decades, and they are the same. That is simply language runtime, not OS.

Except on Unix (or if you are charitable, POSIX) where the runtime is elevated to some magically status. But there are severe problems with that as I already described in earlier threads.

kerravon

Ligao, Free World North,
03.11.2021, 20:06

@ marcov

PDOS-generic

> > > A good, industry wide solution for 386 apps in e.g. the early nineties
> > > would have been welcomed, tools inclusive.
> >
> > GCC couldn't fit the bill?
>
> DJGPP on extender V2 had its first release in 1996, by then the
> beginning of the end for Dos had already started.

I believe EMX was earlier than that. That's what
I used.

> The core problem was not having a stable 32-bit application interface built
> into dos. DJGPP still thunks through the extender to access the old 16-bit
> interrupt calls. _NOW_ in 2021.

I have 3 different 32-bit interfaces that could
be suitable for integrating into DOS (Freedos I
guess). Do you have something specific in mind?

Would you be happy if the DOS interrupts thunked
to 32-bit counterparts? I assume you're not happy
to switch to 32-bit-only apps?

> > I think it is good for programmers to have a set
> > of rules which are known to work cross-platform,
> > and are accepted internationally, which only
> > happened in 1990.
>
> If you mean POSIX, the attempt at Unix reunification that was later
> rebranded as universal, that was first published in 1988, and was already
> in the works since 1995.

Did you mean 1985?

Regardless, no, I was talking about ISO/IEC 9899:1990
aka C90.

> > I have been writing wrappers for decades, but
> > even without them, MSDOS C compilers did come
> > with wrappers with similar functionality. Here
> > is one of my wrappers:
>
> I have been modifying and writing Pascal and Modula2 RTLs for decades, and
> they are the same. That is simply language runtime, not OS.

The wrapper I showed you did an INT 21H. I don't
know what alternative you could possibly be
suggesting.

In my OS at least (both PDOS/86 and PDOS/386),
that wrapper has an identically-named function
in the main OS source file, waiting to service
that call. I don't see how it can get any
OS-ier than that.

BFN. Paul.

marcov

13.11.2021, 15:49

@ kerravon

PDOS-generic

> > DJGPP on extender V2 had its first release in 1996, by then the
> > beginning of the end for Dos had already started.
>
> I believe EMX was earlier than that. That's what
> I used.

There was also V1, but that was cumbersome. I never used OS/2 for production much.

> > The core problem was not having a stable 32-bit application interface
> built
> > into dos. DJGPP still thunks through the extender to access the old
> 16-bit
> > interrupt calls. _NOW_ in 2021.
>
> I have 3 different 32-bit interfaces that could
> be suitable for integrating into DOS (Freedos I
> guess). Do you have something specific in mind?

My interests in Dos are nowadays limited in some FPC work and general interest. I considered this more a thread where things went wrong with Dos.

> Would you be happy if the DOS interrupts thunked
> to 32-bit counterparts? I assume you're not happy
> to switch to 32-bit-only apps?

Back then, if it was good for anything I'd have been happy, yes.

> > If you mean POSIX, the attempt at Unix reunification that was later
> > rebranded as universal, that was first published in 1988, and was
> already
> > in the works since 1995.
>
> Did you mean 1985?

Yes.

> Regardless, no, I was talking about ISO/IEC 9899:1990
> aka C90.

Never saw anything special about it. Probably nice for *nixers who had to specify their applications in C source at that time, but for the rest fairly irrelevant.

Like most languages standards, too deliberately terse on the library front IMHO.

> The wrapper I showed you did an INT 21H. I don't
> know what alternative you could possibly be
> suggesting.

The point that is if the wrapper had been 32-bit callable and in the OS, then as time progressed successors and emulators could have hooked it.

kerravon

Ligao, Free World North,
14.11.2021, 09:01

@ marcov

PDOS-generic

> > Regardless, no, I was talking about ISO/IEC 9899:1990
> > aka C90.
>
> Never saw anything special about it. Probably nice for *nixers who had to
> specify their applications in C source at that time, but for the rest
> fairly irrelevant.

It provided a universal language for computers.

> Like most languages standards, too deliberately terse on the library front
> IMHO.

I've been using it for the 30+ years it has existed,
and I can't see anything wrong with it.

> > The wrapper I showed you did an INT 21H. I don't
> > know what alternative you could possibly be
> > suggesting.
>
> The point that is if the wrapper had been 32-bit callable and in the OS,
> then as time progressed successors and emulators could have hooked it.

I don't know what "hooking" you are talking about,
and what relevance emulators are, but the wrapper
I provided is 32-bit callable, and in both PDOS/386
and PDOS-generic.

Microsoft has abandoned MSDOS, so some other stream
needs to take its place, e.g. Freedos.

Do you have a specific proposal that could be added
to Freedos so that a suitable wrapper is both 32-bit
callable and in the OS as you requested?

Or alternatively, that is still thunked, in Freedos,
in 2021, but on PDOS/386 or PDOS-generic, is run
entirely as 32-bit, which is useful once you have
migrated (by 2021) all of your 16-bit apps to 32-bit.

BFN. Paul.

tom

Germany (West),
04.11.2021, 15:28

@ marcov

PDOS-generic

> The core problem was not having a stable 32-bit application interface built
> into dos.

I fail to see the problem.

> DJGPP still thunks through the extender to access the old 16-bit
> interrupt calls. _NOW_ in 2021.

you are running on top of an OS from 1993. what do you expect?

> Extender and long-term stable 32-bit API built into dos.

Extenders are stable, have been around since ~1990 and give you all the 32-bit API's you might ever want. they are just OS extensions - exactly what you asked for.

Someone has to convert 32-bit operations into 16-bit DOS/BIOS. The advantage of doing this in the extender is that the required memory is not needed when running 16-bit applications and memory is scarce.

in addition, you may select an extender that pages memory, possibly even provides memory protection, and more interesting protected mode stuff.

marcov

08.11.2021, 10:21

@ tom

PDOS-generic

> > The core problem was not having a stable 32-bit application interface
> built
> > into dos.
>
> I fail to see the problem.

Now or then? The question was what IMHO should have gone different with the course of dos.

>
> > DJGPP still thunks through the extender to access the old 16-bit
> > interrupt calls. _NOW_ in 2021.
>
> you are running on top of an OS from 1993. what do you expect?

That's now. I was talking about then.

> > Extender and long-term stable 32-bit API built into dos.
>
> Extenders are stable, have been around since ~1990 and give you all the
> 32-bit API's you might ever want. they are just OS extensions - exactly
> what you asked for.

Needing to use the plural of "Extenders" already says enough. If it had been centralized there would only be one, and with that also some more standardization of the 32-bit level interface.

> Someone has to convert 32-bit operations into 16-bit DOS/BIOS.

This is exactly the point;

> The
> advantage of doing this in the extender is that the required memory is not
> needed when running 16-bit applications and memory is scarce.

The point that I discuss is more that 3rd party code is doing that. At an earlier point msdos should have expanded. (one can say it did and it became win9x though)

> in addition, you may select an extender that pages memory, possibly even
> provides memory protection, and more interesting protected mode stuff.

But now call a program using extender X from a dosbox spawned by a program using extender y...... By having a default 32-bit part (extender) built into dos at some point, that could have been avoided, and it would also have allowed Dos to expand possible 32-bit API offering

Of course this is all in 30 year hindsight

tkchia

08.11.2021, 16:24
(edited by tkchia, 08.11.2021, 19:18)

@ marcov

PDOS-generic

Hello marcov,

> Needing to use the plural of "Extenders" already says enough. If it had
> been centralized there would only be one, and with that also some more
> standardization of the 32-bit level interface.

There is a standardized 32-bit interface. It is called DPMI.

If you ever wondered why a DJGPP program runs just fine whether it is running on top of CWSDPMI, DPMIONE, QDPMI, or dosemu — it is because it is running on top of a clearly standardized ABI — the "DOS Protected Mode Interface Specification 0.9". If you throw away CWSDPMI and load another DPMI client, the DJGPP program will continue to work just fine. Because there is a standardized ABI.

Also, just to clear up a few misconceptions:

DPMI hosts and DOS extenders are actually separate things. DPMI provides a sort of thin layer of abstraction to allow protected mode programs to call back to (or simulate) real-mode BIOS or DOS functionality. (Seriously, read the specification...)

A DOS extender (e.g. DOS/4G, PMODE/W) would normally build on top of this thin DPMI layer to provide a thicker, more full-fledged "int 0x21 ABI" (and more). This allows programs to pretend, at the assembly language level, that they are dealing with a sort of fully "32-bit DOS", with a 32-bit "int 0x21, ah = 0x40" etc.

However, this thick DOS extender layer is not a requirement. In fact DJGPP's C runtime library does not use a DOS extender at all. (!) It only requires a DPMI host, and directly calls out to the thin DPMI layer. You do not need DOS/4G, etc. to run a DJGPP program.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

DosWorld

08.11.2021, 17:17
(edited by DosWorld, 08.11.2021, 17:38)

@ tkchia

PDOS-generic

[del]

---
Make DOS great again!
Make Russia small again!

marcov

13.11.2021, 16:03

@ tkchia

PDOS-generic

>
> > Needing to use the plural of "Extenders" already says enough. If it had
> > been centralized there would only be one, and with that also some more
> > standardization of the 32-bit level interface.
>
> There is a standardized 32-bit interface. It is called DPMI.

It is a bit minimal (most non memory related calls are multiplexed over one single intr() routine, IIRC there was also some trouble with INTs with arguments to memory being handled differently by varying extenders, some marshalled for you, some not)

Anyway, I see DPMI more as an attempt to regulate and workaround the problems rather than a solution. Sure, it works somewhat, but it is limited and more importantly, it does solve the problem that your EXE is hard linked to a certain 3rd party extender.

tkchia

13.11.2021, 17:42

@ marcov

PDOS-generic

Hello marcov,

> > There is a standardized 32-bit interface. It is called DPMI.
> It is a bit minimal (most non memory related calls are multiplexed over one
> single intr() routine, IIRC there was also some trouble with INTs with

I think you are again conflating several things. Again:

(1) DPMI hosts and DOS extenders are separate things.
(2) No, DJGPP programs do not rely on any DOS extender (this is unlike Watcom programs).
(3) It might be a good idea to read the DPMI specification.

> arguments to memory being handled differently by varying extenders, some
> marshalled for you, some not)

Well... this is how standards work, no?

The DPMI specification says what services a DPMI host must provide at minimum. Obviously, DPMI hosts (and environments) can provide service beyond this minimum. Different DPMI hosts and DOS extenders will provide different kinds of such "extra" services. I fail to see why this is a problem with DPMI.

If your program — or your C runtime library — ignores what the DPMI standard says, and insists on using features present only in, say, DOS/4G, then — surprise! — the program will only work on top of DOS/4G. (Well, no surprise there.) Again, I fail to see the problem here.

The way to make your program work on other DPMI environments is to rewrite it, so that it relies only on features offered by the DPMI standard.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

kerravon

Ligao, Free World North,
12.11.2021, 01:50

@ marcov

PDOS-generic

> > > The core problem was not having a stable 32-bit application interface
> > built
> > > into dos.
> >
> > I fail to see the problem.
>
> Now or then? The question was what IMHO should have gone different with
> the course of dos.

That is correct. That is my question.

> The point that I discuss is more that 3rd party code is doing that. At an
> earlier point msdos should have expanded. (one can say it did and it became
> win9x though)

I would argue that win9x is a radically different
API unrelated to MSDOS. So if we're talking about
"yet another 32-bit OS", win9x fits the bill.

I mentioned that I had 3 offerings of "32-bit MSDOS"
already, but I have in mind a 4th.

Include functions like PosFindFirst() that directly
map on to the INT 21H call, but implement them with
calls to kernel32.dll functions.

This places a burden on the compiler, linker and OS
to support DLLs so is not as good as PDOS-generic,
in my opinion.

What's your opinion?

And one more option would be the "Family API" to be
used for 32-bit programming, and let the 16-bit one
cover all platforms (do 16-bit executables still work
on 64-bit Windows, given that "long mode" supports
PM16?).

BFN. Paul.

kerravon Ligao, Free World North, 12.11.2021, 11:10 @ kerravon	PDOS-generic Post reply
	> And one more option would be the "Family API" to be > used for 32-bit programming 1. I think that will actually give me a subset of OS/2 2.0. 2. This doesn't look anything remotely like MSDOS: http://www.edm2.com/index.php/DosOpen_(FAPI) Meaning it is yet another API.

Ringding 12.11.2021, 13:39 @ kerravon	PDOS-generic Post reply
	> And one more option would be the "Family API" to be > used for 32-bit programming, and let the 16-bit one > cover all platforms (do 16-bit executables still work > on 64-bit Windows, given that "long mode" supports > PM16?). AFAIK Windows has never been able to run 16bit OS/2 applications.

kerravon

Ligao, Free World North,
13.11.2021, 02:26

@ Ringding

PDOS-generic

> > And one more option would be the "Family API" to be
> > used for 32-bit programming, and let the 16-bit one
> > cover all platforms (do 16-bit executables still work
> > on 64-bit Windows, given that "long mode" supports
> > PM16?).
>
> AFAIK Windows has never been able to run 16bit OS/2 applications.

It seems it stopped support with Windows 2000:

https://en.wikipedia.org/wiki/New_Executable

Ringding 13.11.2021, 09:55 @ kerravon	PDOS-generic Post reply
	Apparently I was mistaken. I always thought it supported only 32-bit OS/2, but in fact it seems to have been the other way around and only ever supported 16-bit executables. According to multiple sources, Windows 2000 still had this ability. I really need to try this out!

Ringding 13.11.2021, 10:51 @ Ringding	PDOS-generic Post reply
	> I really need to try this out! Yes, I can confirm that I can run an OS/2 16-bit executable that uses the family API (built with Microsoft C 6) on a plain installation of Windows 2000 Professional SP4.

Back to index page

22632 Postings in 2109 Threads, 402 registered users, 431 users online (0 registered, 431 guests)
DOS ain't dead | Admin contact

powered by my little forum