PDOS for Amiga

[Thomas Richter]

Originally Posted by kerravon

First, the year is 1983 and MSDOS 2.0 has just been released.

As a reminder, it's 2021 now. Not 1983.

Originally Posted by kerravon

I need advice to give to MSDOS programmers.

Advice: Don't use this. It is outdated. We're now almost 40 years after the release of MS-DOS. The only advice you should give to authors is not to depend on this design anymore.

Originally Posted by kerravon

If you can agree with all of the above, then the only remaining thing is to discuss the PDOS-generic design. ie can you see anything wrong with having a pure C90 system?

Then, by all means, please make it one. Poking into a screen memory is not a "C90 design". It is a 1983 design.

[kerravon]

Originally Posted by Thomas Richter

Then, by all means, please make it one. Poking into a screen memory is not a "C90 design". It is a 1983 design.

PDOS-generic doesn't poke screen memory. PDOS-generic will receive calls to PosWriteFile() (basically matching the MSDOS 2.0 INT 21H AH=40H function). The data stream will contain ANSI control characters generated by the "well-behaved MSDOS application". PDOS-generic will not interpret these. It will rely on the higher-level BIOS to do that.

The higher-level BIOS looks very similar to C, exporting a C library, which includes a stdout stream. It so happens that on the Amiga the BIOS is in fact a C library, and writing to stdout will pass that data on to the Amiga Write() function. The Amiga understands ANSI codes, so nothing further needs to be done.

Does that sound more reasonable?

[kerravon]

Originally Posted by kerravon

If they say "but ANSI is slow!" then the correct technical response is to change/replace ansi.sys or even change MSDOS 2.0 to PDOS/86, so that it stops using the BIOS and directly manipulates the hardware, so should be fast enough even on an IBM PC XT.

Actually, another place it could have gone is in the C library. Perhaps if a setvbuf to fully-buffered is done, the ANSI interpretation starts. Because if you unconditionally drive 0xb8000 it will prevent redirection from working.

[Thomas Richter]

Does the speed argument even matter in 2021? Today's machines are by at least two powers of magnitude faster than machines back then.

[kerravon]

Originally Posted by Thomas Richter

Does the speed argument even matter in 2021? Today's machines are by at least two powers of magnitude faster than machines back then.

My goal is to have people writing "standard code" as early as possible. I don't like POSIX (has fork(), doesn't have some sort of alloc()), plus not based on FAT capability. I much prefer the simpler MSDOS system. It was capable of running within 64k, and this is a different "class" of problem.

C90 does 90% of the job of getting people to write "standard code". ANSI control sequences come close to doing the rest. Plus if you are manipulating files in a directory, as you often are, you need an API for that, which is where MSDOS comes in.

The question then is what is the barrier to using these things.

It is amazing that Windows only started supporting ANSI control sequences a few years ago.

[Thomas Richter]

Originally Posted by kerravon

My goal is to have people writing "standard code" as early as possible.

How does that relate to the "speed" argument?

[kerravon]

Originally Posted by Thomas Richter

How does that relate to the "speed" argument?

The "standard code" needs to be fast enough for an IBM PC XT. Otherwise people will write IBM PC-specific code.

[Thomas Richter]

And why is that an important target, in year 2021? Furthermore, why is this even the right forum, given that eab is on Amiga?

[kerravon]

Originally Posted by Thomas Richter

And why is that an important target, in year 2021?

To answer the question of what went wrong in the 1980s that saw people writing non-portable software.

Furthermore, why is this even the right forum, given that eab is on Amiga?

Because it feeds into the design of PDOS-generic, which was conceived in this forum, and has an Amiga target already.

I've just modified micro-emacs so that the ANSI flavor works with PDPCLIB as the C runtime library for Win32. I think the same micro-emacs source code should work on PDOS-generic under the Amiga (since the Amiga already supports ANSI escape codes), but I need to write more code to handle setvbuf of stdin to no-buffering for both PDOS-generic and the Amiga version of PDPCLIB to make it accept a ctrl-x, ctrl-c sequence. I assume the Amiga is line-buffered when doing a Read() from standard input?

[meynaf]

Originally Posted by kerravon

To answer the question of what went wrong in the 1980s that saw people writing non-portable software.

Why not just asking the question ?

IMO it didn't go wrong in the 80's. Rather, in the 90's.
In the 80's machines didn't have enough horsepower to do otherwise : if you didn't tie your program to some specific architecture it would have been feature limited, lacked performance, or even didn't work at all. This has changed since.
In addition, every vendor had own view and this led to fragmentation. This hasn't changed since.

Software today suffers from unneeded complexity because it's marketing needs which controls the world, not technical needs.

There is nothing wrong in wanting to examine the past so to avoid repeating past mistakes.
There is nothing wrong in willing to adopt an ABI that's simple, portable and easy to use. And testing it on limited machines to see how good it performs.
However, taking MSDOS for this task is betting on the bad horse. Same for C90.
(Note that i won't blame you for that ; currently there is no good horse at all to bet on.)

What we could do is to design new set of APIs that satisfies the "keep it stupid simple" paradigm.
But it must be feature complete.

[kerravon]

Originally Posted by meynaf

Why not just asking the question ?

It is in my nature to convert answers into code before I forget, so I need to prepare the code. :-)

IMO it didn't go wrong in the 80's. Rather, in the 90's.
In the 80's machines didn't have enough horsepower to do otherwise : if you didn't tie your program to some specific architecture it would have been feature limited, lacked performance, or even didn't work at all. This has changed since.

That's a very interesting observation. You think there was a need to rethink things in the 90s but that didn't happen.

But first - do you agree that even in the 80s it was possible to make text mode programs portable? Or do you think memory was a constraint then? I think the correct solution for memory constraints was to upgrade to an AT.

In addition, every vendor had own view and this led to fragmentation. This hasn't changed since.

There don't seem to be a lot of vendors anymore. I know I am focussing on MSDOS, but maybe PDOS-generic should be using the Win32 API instead. Or as well as. Or maybe just a small library is sufficient.

Software today suffers from unneeded complexity because it's marketing needs which controls the world, not technical needs.

One horrendous thing is that Microsoft's business model is that they only get money from Windows when a new PC is manufactured. So they keep trying to obsolete physical computers. Instead of providing something for an XT onwards.

There is nothing wrong in wanting to examine the past so to avoid repeating past mistakes.
There is nothing wrong in willing to adopt an ABI that's simple, portable and easy to use. And testing it on limited machines to see how good it performs.
However, taking MSDOS for this task is betting on the bad horse. Same for C90.
(Note that i won't blame you for that ; currently there is no good horse at all to bet on.)

So far I haven't been able to fault C90 other than it doesn't provide some definitions like:

#define ESC_CHAR '\x1b'

so that I can control an ANSI terminal from both ASCII and EBCDIC. I was thinking of creating a c90ext.h

What we could do is to design new set of APIs that satisfies the "keep it stupid simple" paradigm.
But it must be feature complete.

It's "keep it simple, stupid". If by "complete" you mean "graphics", I believe there are already large graphics libraries available. OpenGL? Or what did you have in mind?

[Thomas Richter]

Originally Posted by kerravon

It is in my nature to convert answers into code before I forget, so I need to prepare the code. :-)

Sorry, but that seems to be the wrong approach - at least as long as you're still able to ask people from that age.

Originally Posted by kerravon

But first - do you agree that even in the 80s it was possible to make text mode programs portable?

As long as you restrict yourself to a subset of the possibilities of the machine that is guaranteed to exist on larger set of machines, yes.

Originally Posted by kerravon

Or do you think memory was a constraint then?

Yes, of course it was a constraint.

Originally Posted by kerravon

There don't seem to be a lot of vendors anymore.

There are plenty vendors, more than ever. Just nobody cares about outdated technology, because there are no customers for such software, quite simple.

Originally Posted by kerravon

I know I am focussing on MSDOS, but maybe PDOS-generic should be using the Win32 API instead. Or as well as. Or maybe just a small library is sufficient.

It does not matter, as there is no market for operating systems anymore. If there is anything close to an operating system today, then that's browser, html, ECMAscript and CCS.

Originally Posted by kerravon

One horrendous thing is that Microsoft's business model is that they only get money from Windows when a new PC is manufactured. So they keep trying to obsolete physical computers. Instead of providing something for an XT onwards.

Actually, Microsoft is more than Windows, and their current business model is to "software as a service", that is, to force customers into renting their software.


And no, nobody cares about XT or AT or (to bring it back on topic) Amiga anymore. XT even less. Today's hardware requires the power for more than "running windows". How do you want to stream a video in real time with an XT? Most internet traffic is video today.

Originally Posted by kerravon

So far I haven't been able to fault C90 other than it doesn't provide some definitions like:

#define ESC_CHAR '\x1b'

so that I can control an ANSI terminal from both ASCII and EBCDIC. I was thinking of creating a c90ext.h

Of course C does not define that. ESC is a particular control sequence of a particular encoding, and defined in another standard (ISO 646 aka ASCII is one of them), and C is encoding-agnostic, so why should it define it?

Originally Posted by kerravon

It's "keep it simple, stupid". If by "complete" you mean "graphics", I believe there are already large graphics libraries available. OpenGL? Or what did you have in mind?

Today? Graphics and cross-platform is pretty much "SDL" to me today.

[kerravon]

Originally Posted by Thomas Richter

Of course C does not define that. ESC is a particular control sequence of a particular encoding, and defined in another standard (ISO 646 aka ASCII is one of them), and C is encoding-agnostic, so why should it define it?

If it defines a '\a' for "alert", why not have something for the very important ESC char needed to write ANSI escape sequences? Rather than burdening the compiler with a '\e', it seems simple to have an ESC_CHAR and ESC_STR defined. The other character I need is XON.

[meynaf]

Originally Posted by kerravon

That's a very interesting observation. You think there was a need to rethink things in the 90s but that didn't happen.

But first - do you agree that even in the 80s it was possible to make text mode programs portable? Or do you think memory was a constraint then? I think the correct solution for memory constraints was to upgrade to an AT.

That depends. In late 80s yes, probably, but not before.
Yes memory was a constraint, but display capabilities were more important IMO. Say, if you want 80x25 -- impossible for my old Oric. Limited to 4 colors on Atari ST. How to be portable under these conditions ?

Originally Posted by kerravon

There don't seem to be a lot of vendors anymore. I know I am focussing on MSDOS, but maybe PDOS-generic should be using the Win32 API instead. Or as well as. Or maybe just a small library is sufficient.

Not a lot of vendors yes, but we still have different OSes that don't share the same API system...

Originally Posted by kerravon

One horrendous thing is that Microsoft's business model is that they only get money from Windows when a new PC is manufactured. So they keep trying to obsolete physical computers. Instead of providing something for an XT onwards.

And now we have planned obsolescence on handheld devices too.

Originally Posted by kerravon

So far I haven't been able to fault C90 other than it doesn't provide some definitions like:

#define ESC_CHAR '\x1b'

so that I can control an ANSI terminal from both ASCII and EBCDIC. I was thinking of creating a c90ext.h

You want to fault C90 ?
Consider how it handles arithmetic overflow, for example.

Originally Posted by kerravon

It's "keep it simple, stupid". If by "complete" you mean "graphics", I believe there are already large graphics libraries available. OpenGL? Or what did you have in mind?

I mean graphics, sounds, multitasking, everything.
It must be so that just about every program in existence could be rewritten with it. I don't think a web browser could be written with just your current PDOS functions, for example.

[kerravon]

Originally Posted by meynaf

You want to fault C90 ?
Consider how it handles arithmetic overflow, for example.

I haven't noticed any issue with arithmetic overflow when writing PDOS/386. Maybe it depends on the task you're using it for?

I mean graphics, sounds, multitasking, everything.
It must be so that just about every program in existence could be rewritten with it. I don't think a web browser could be written with just your current PDOS functions, for example.

I have written a comms program (front-end mailer for BBS) in just C90. It does rely on a reliable connection though. I could thus have a comms program that retrieves a web page. And so long as it is text, I should be able to display it. I could even use micro-emacs to display it. Note that I'm more interested in deafblind people being able to "read" a web page than sound/graphics.

[meynaf]

Originally Posted by kerravon

I haven't noticed any issue with arithmetic overflow when writing PDOS/386. Maybe it depends on the task you're using it for?

Of course it depends on the task. Your PDOS/386 is just a wrapper around functions, it's somehow trivial task. Try to write cpu emulation code and you'll see a completely different world.

Originally Posted by kerravon

I have written a comms program (front-end mailer for BBS) in just C90. It does rely on a reliable connection though. I could thus have a comms program that retrieves a web page. And so long as it is text, I should be able to display it. I could even use micro-emacs to display it. Note that I'm more interested in deafblind people being able to "read" a web page than sound/graphics.

Most web pages aren't just text.

[Thomas Richter]

Originally Posted by kerravon

I haven't noticed any issue with arithmetic overflow when writing PDOS/386. Maybe it depends on the task you're using it for?

Actually, it depends on the environment and the machine the code is executed on. For example, if adding two signed integers overflows, there is nothing the C standard guarantees. It is undefined behaviour, so anything can happen. C does not guarantee that numbers are represented in binary, and in two's complement representation.

[kerravon]

Originally Posted by meynaf

Of course it depends on the task. Your PDOS/386 is just a wrapper around functions, it's somehow trivial task.

PDOS/386 is a complete standalone OS - a 32-bit version of MSDOS, and also a mini Windows clone. It is 30,000 lines of code, plus there is another 20,000 lines of code for the C library.

[meynaf]

Originally Posted by kerravon

PDOS/386 is a complete standalone OS - a 32-bit version of MSDOS, and also a mini Windows clone. It is 30,000 lines of code, plus there is another 20,000 lines of code for the C library.

No it is not complete. It is just "disk" operating system. And not a Windows clone either as it does not provide a GUI system (it would be great if it did !).
And perhaps not 100% standalone - I imagine you call BIOS for base i/o (disk block access) and only implement FAT file system yourself ?

But granted - it's more complex than just a wrapper. Probably still not a good stress test for the programming language, though.

That said, 30000 (+20000) lines seem excessive for this. What justifies such a big size ?
In comparison, my system framework contains code for graphics, sounds, disk i/o, memory handling (including dynamic sized arrays/strings), resource tracking, command line parsing, keyboard, mouse, timer + vblank interrupts, amiga asl file/dir selector, and contains atari screen conversion + c2p + ham8 rendering.
And it is (a little less than) 8500 lines. Yes, of asm.
So ok, it works on top of AmigaOS, but nevertheless.

[kerravon]

Originally Posted by meynaf

That said, 30000 (+20000) lines seem excessive for this. What justifies such a big size ?

I don't know. That's just what it took. I looked at the 4 biggest files in size of bytes. pdos.c is 5050 lines, fat.c is 3674 lines, pcomm.c is 3388 lines, exeload.c is 1620 lines.

Probably still not a good stress test for the programming language, though.

The C compiler is also written in pure C90, so that's 400,000 lines. All the other software I want is written in pure C90 too, with the sole exception of the editor (micro-emacs, 50,000 lines) and the BBS message reader (msged, 25,000 lines) using ANSI escape sequences (not something covered by C90, but a different standard). I just got msged working yesterday.

So I've proven the entire software suite I wish to run. All in C90. I don't know how other languages stack up against that - if you write the entire development suite in that language, what do you get?

BTW, one thing I discovered while getting msged to build - I had to press ESC twice to exit because I don't use a timer (not part of C90), and the keyboard routine is looking for an ANSI escape sequence when it encounters an ESC, and it is exited if a second ESC is detected.

Since I wish to write in standard C90 instead of making my code timing-sensitive and non-standard, I was thinking that what I should actually do is make the OS (PDOS) keyboard routine generate two ESC characters in response to the user pressing ESC. What do you think of that?