PDOS for Amiga

[kerravon]

Originally Posted by meynaf

For a single individual maybe, but all together certainly not.

If the Amiga is "just another MSDOS-capable system", it shouldn't really matter.

But perhaps MSDOS software isn't appropriate.
Compiling it for 68000 isn't enough. MSDOS has nothing for graphics, sound, etc. It depends fully on PC/x86 architecture. So yes you can do something similar but that's all.

I'm only trying to do MSDOS-compatibility (for the Amiga and elsewhere). Graphics and sound are beyond scope - they're not part of MSDOS. You can do a lot within the constraints of MSDOS. I actually bought a Commodore PC 5 circa 1987 and it had no graphics or sound.

Why ? We have much better already. MSDOS has no technical quality to justify it becoming a standard. It got dropped 20 years ago and for good reasons (for once).

I'm talking about the time the Amiga came out. I expect it to provide a 68000 version of MSDOS. How long would that have taken and what impact would it have had?

[meynaf]

Originally Posted by kerravon

If the Amiga is "just another MSDOS-capable system", it shouldn't really matter.

It's clearly not just that (hopefully !).

Originally Posted by kerravon

I'm only trying to do MSDOS-compatibility (for the Amiga and elsewhere). Graphics and sound are beyond scope - they're not part of MSDOS. You can do a lot within the constraints of MSDOS. I actually bought a Commodore PC 5 circa 1987 and it had no graphics or sound.

No, what you're trying to do isn't MSDOS compatibility. It's cloning of MSDOS ; similar but not compatible system.
And no, you cannot do a lot. Typical MSDOS programs used other primitives (BIOS) and/or accessed hardware directly. MSDOS is really just for disk access (hence the 'D' in its name).

Originally Posted by kerravon

I'm talking about the time the Amiga came out. I expect it to provide a 68000 version of MSDOS. How long would that have taken and what impact would it have had?

If MSDOS is just INT 21, then Atari ST has TRAP #1 with same function numbers - so it's already there.
How long would that have taken - not much. What impact would it have had - not much either. All 68000 machines by that time already had much better OSes than MSDOS.

[kerravon]

Originally Posted by meynaf

It's clearly not just that (hopefully !).

Sure. It's a superset of that.

No, what you're trying to do isn't MSDOS compatibility. It's cloning of MSDOS ; similar but not compatible system.
And no, you cannot do a lot. Typical MSDOS programs used other primitives (BIOS) and/or accessed hardware directly. MSDOS is really just for disk access (hence the 'D' in its name).

But maybe they wouldn't have done that if they knew they wanted their programs to run on the Amiga too. There is probably 4 levels of compatibility at the source code level:

1. C90
2. MSDOS + above
3. Bios + above
4. Hardware + above

Number 1 has been covered since SAS/C came out I think. Now I'm doing number 2. It gives programmers something to code to. What is the reason people felt the need to directly call the BIOS and/or hardware for a character-mode application, and could that have been changed if we had cooperative programmers?

If MSDOS is just INT 21, then Atari ST has TRAP #1 with same function numbers - so it's already there.

Wow - that's fantastic. I will make contact with the Atari people to see if my MSDOS programs are likely to work on that platform with the appropriate manifestation of the API. ie I need to write this wrapper for the Atari:

https://sourceforge.net/p/pdos/gitco...tree/src/pos.c

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);
}
}

How long would that have taken - not much. What impact would it have had - not much either.

Maybe having wrappers for all the INT/trap functions as above would have made a bigger impact, and made the Atari another supported platform?

All 68000 machines by that time already had much better OSes than MSDOS.

Sure, it's better, but doesn't even cover the MSDOS API. That's (potentially) the problem. Doesn't matter how good you are if you can't even be bothered supporting industry-standard FAT disks and the supporting API. It would seem to me that you first support that before adding all your goodies.

[meynaf]

Originally Posted by kerravon

But maybe they wouldn't have done that if they knew they wanted their programs to run on the Amiga too. There is probably 4 levels of compatibility at the source code level:

1. C90
2. MSDOS + above
3. Bios + above
4. Hardware + above

These 4 levels aren't enough to run real MSDOS programs properly - you also need x86. Yes, even for just source level.

Originally Posted by kerravon

Number 1 has been covered since SAS/C came out I think. Now I'm doing number 2. It gives programmers something to code to.

And then you'll discover 2 has nothing to offer 1 doesn't already have.

Originally Posted by kerravon

What is the reason people felt the need to directly call the BIOS and/or hardware for a character-mode application, and could that have been changed if we had cooperative programmers?

You don't need cooperative programmers. You need a proper API, which MSDOS is not -- hence the need for BIOS/hardware accesses.

Originally Posted by kerravon

Wow - that's fantastic. I will make contact with the Atari people to see if my MSDOS programs are likely to work on that platform with the appropriate manifestation of the API.

Not all int 21 functions are present on the Atari TOS because some are tied to PC specifics and useless anywhere else. But with proper wrappers, no reason it can't work.

Originally Posted by kerravon

ie I need to write this wrapper for the Atari:

https://sourceforge.net/p/pdos/gitco...tree/src/pos.c

Time for one liners then :

 return GEMDOS (78, pat, attrib);

Originally Posted by kerravon

Maybe having wrappers for all the INT/trap functions as above would have made a bigger impact, and made the Atari another supported platform?

No.

Originally Posted by kerravon

Sure, it's better, but doesn't even cover the MSDOS API. That's (potentially) the problem. Doesn't matter how good you are if you can't even be bothered supporting industry-standard FAT disks and the supporting API. It would seem to me that you first support that before adding all your goodies.

MSDOS isn't "minimum standard to have". It's just MSDOS and has zero right of becoming a standard.
It's not a real API either ; as an abstraction layer it's incredibly poor.
That said, Atari ST reads FAT directly and Amiga has separate filesystem handlers for that - it's one of its "goodies".
Note that FAT disks aren't exactly industry standard anymore.

[kerravon]

Originally Posted by meynaf

These 4 levels aren't enough to run real MSDOS programs properly - you also need x86. Yes, even for just source level.

I'm trying to define what "real" could have been. Just because people used x86 assembler doesn't mean it was necessary.

And then you'll discover 2 has nothing to offer 1 doesn't already have.

The MSDOS API gives you the ability to read directories, read timestamps on files. May as well be MSDOS setting the standard as Unix.

You don't need cooperative programmers. You need a proper API, which MSDOS is not -- hence the need for BIOS/hardware accesses.

Why do you need that for character mode applications? Why can't ANSI control characters be used if you need fullscreen? Or curses.

Note that FAT disks aren't exactly industry standard anymore.

They were important at the time the Amiga came out, which is what I am interested in.

[meynaf]

Originally Posted by kerravon

I'm trying to define what "real" could have been. Just because people used x86 assembler doesn't mean it was necessary.

I was not speaking about x86 assembler, but about what the mere x86 architecture inflicted to DOS programs. Things such as near/far pointers, for example.

Originally Posted by kerravon

The MSDOS API gives you the ability to read directories, read timestamps on files. May as well be MSDOS setting the standard as Unix.

There are many more programs doing graphics and sounds than programs reading directories or timestamps on files, so the "missing features" argument is invalid.

Originally Posted by kerravon

Why do you need that for character mode applications? Why can't ANSI control characters be used if you need fullscreen? Or curses.

Character mode applications need to display characters anywhere on screen and probably access screen memory directly. MSDOS doesn't provide APIs for that.

Originally Posted by kerravon

They were important at the time the Amiga came out, which is what I am interested in.

Why ?

[kerravon]

Originally Posted by meynaf

I was not speaking about x86 assembler, but about what the mere x86 architecture inflicted to DOS programs. Things such as near/far pointers, for example.

I don't think near/far pointers are required. You just need to select an appropriate memory model.

There are many more programs doing graphics and sounds than programs reading directories or timestamps on files, so the "missing features" argument is invalid.

My interest is in text mode applications, so "graphics" is invalid. And it took a long time before PCs did anything more than beeping, so "sound" is invalid too. Business applications at the time didn't do sound anyway.

Character mode applications need to display characters anywhere on screen and probably access screen memory directly. MSDOS doesn't provide APIs for that.

You can display characters anywhere on the screen with ANSI control characters. What's wrong with using that? If we had standardized on that (assuming ANSI wasn't standard already), we could have had cross-platform full-screen applications.

Why ?

I want to understand the state of computers at that time, because fundamentally I expect that when a superior computer is designed, people should use the superior computer. If we ever have a do-over, I want to be armed with the knowledge to say something like "do the C standard earlier and defer screen updates until flush(stdout) is done".

[meynaf]

Originally Posted by kerravon

I don't think near/far pointers are required. You just need to select an appropriate memory model.

There is no memory model to select. There is one. If you want something else, go to protected mode but it's not true MSDOS anymore.

Originally Posted by kerravon

My interest is in text mode applications, so "graphics" is invalid. And it took a long time before PCs did anything more than beeping, so "sound" is invalid too. Business applications at the time didn't do sound anyway.

This is very PC biased. Too PC biased.

Originally Posted by kerravon

You can display characters anywhere on the screen with ANSI control characters. What's wrong with using that? If we had standardized on that (assuming ANSI wasn't standard already), we could have had cross-platform full-screen applications.

Except that MSDOS doesn't have ANSI by default. Or is ansi.sys always present and always loaded ?
And what's wrong with that, a lot of things. It's just dirty way to access the screen. Why not print/locate primitives like old Basics do ? Simple, efficient.

Originally Posted by kerravon

I want to understand the state of computers at that time, because fundamentally I expect that when a superior computer is designed, people should use the superior computer.

There is nothing such as "superior computer". When new computer comes, things are superior but there are always regressions.
Look at what we have today : they can do a lot, but we have next to zero control on what happens in them. Hence the recent trend on vintage computers. Limited, but more friendly because simpler.

Originally Posted by kerravon

If we ever have a do-over, I want to be armed with the knowledge to say something like "do the C standard earlier and defer screen updates until flush(stdout) is done".

Apparently you don't have such knowledge yet, as you'd then know better than this quoted sentence
Deferring screen updates isn't clever. It requires some buffering (i.e. memory allocations otherwise not needed) and will nearly always be slower than just poking the screen immediately (even if we don't have character based screen modes).

If we could have a do-over, i'd just say : "keep things simple !".

If you want the knowledge, why not just asking those who have it ?

[kerravon]

Originally Posted by meynaf

There is no memory model to select. There is one. If you want something else, go to protected mode but it's not true MSDOS anymore.

That depends what you call "true MSDOS". I consider a 68000 version of MSDOS to be "true MSDOS" too.

Except that MSDOS doesn't have ANSI by default. Or is ansi.sys always present and always loaded ?

If the solution to our problems is to just have ansi.sys always loaded, or automatically loaded when an application signals it needs it, then this is the proper solution. Not ignore the Amiga because people have done direct screen writes instead.

And what's wrong with that, a lot of things. It's just dirty way to access the screen. Why not print/locate primitives like old Basics do ? Simple, efficient.

I think the advantage of ANSI is that remote terminals can be driven using the sequences.

There is nothing such as "superior computer". When new computer comes, things are superior but there are always regressions.

I expect at its heart for the Amiga to be a faster way of running C90 programs. That's not a regression. It's something that should be industry standard.

Look at what we have today : they can do a lot, but we have next to zero control on what happens in them. Hence the recent trend on vintage computers. Limited, but more friendly because simpler.

I wasn't aware there was a trend. Can you provide details? What are people looking for and which computers are they selecting?

Apparently you don't have such knowledge yet, as you'd then know better than this quoted sentence
Deferring screen updates isn't clever. It requires some buffering (i.e. memory allocations otherwise not needed) and will nearly always be slower than just poking the screen immediately (even if we don't have character based screen modes).

My understanding is that the IBM PC has "pages", and so what you could organize is for the fullscreen changes to be written to one of those pages which is not actually active, and the fflush() suddenly activates it, and then you can copy the data to the other page. So no extra buffering required.

If you want the knowledge, why not just asking those who have it ?

I don't know enough to know what question to ask.

[meynaf]

Originally Posted by kerravon

That depends what you call "true MSDOS". I consider a 68000 version of MSDOS to be "true MSDOS" too.

True MSDOS is for me something that will run existing MSDOS programs unchanged.

Originally Posted by kerravon

I think the advantage of ANSI is that remote terminals can be driven using the sequences.

This is how computing was done in the 70's

Originally Posted by kerravon

I expect at its heart for the Amiga to be a faster way of running C90 programs. That's not a regression. It's something that should be industry standard.

Maybe there is already something wrong in setting C90 as a standard. Ever thought about this ?

Originally Posted by kerravon

I wasn't aware there was a trend. Can you provide details? What are people looking for and which computers are they selecting?

Just search the web.

Originally Posted by kerravon

My understanding is that the IBM PC has "pages", and so what you could organize is for the fullscreen changes to be written to one of those pages which is not actually active, and the fflush() suddenly activates it, and then you can copy the data to the other page. So no extra buffering required.

That other page is your extra buffering.
Things are becoming even worse now : whole frame copied for every change that's committed to the screen.

Originally Posted by kerravon

I don't know enough to know what question to ask.

So what makes you believe you will acquire this knowledge by doing what you are currently doing ?

[kerravon]

Originally Posted by meynaf

True MSDOS is for me something that will run existing MSDOS programs unchanged.

All existing MSDOS programs, or some? With or without a recompile so that you can change processor?

This is how computing was done in the 70's

And shouldn't necessarily bee abandoned.

Maybe there is already something wrong in setting C90 as a standard. Ever thought about this ?

I've written an entire operating system (PDOS/386) in it and cannot fault the language. Maybe because I don't have the skills to do so.

That other page is your extra buffering.

Well it's being done anyway.

Things are becoming even worse now : whole frame copied for every change that's committed to the screen.

If it's being done on the PC anyway, then what's wrong with ANSI control characters with a copy being done after a fflush()?

So what makes you believe you will acquire this knowledge by doing what you are currently doing ?

Because it is working. Even if you just look at this thread you can see that I have made massive advances in my knowledge. PDOS-generic only exists because of this thread.

[meynaf]

Originally Posted by kerravon

All existing MSDOS programs, or some? With or without a recompile so that you can change processor?

It doesn't matter. In all cases, you can't turn non-trivial 16-bit MSDOS programs using x86_16's bogus memory model into 32-bit programs by just recompiling.

Originally Posted by kerravon

And shouldn't necessarily bee abandoned.

It's not among the things i'd keep from the past. I prefer to have control on my computer instead of using a remote one i don't own.

Originally Posted by kerravon

I've written an entire operating system (PDOS/386) in it and cannot fault the language. Maybe because I don't have the skills to do so.

People who invented C99 afterwards probably thought otherwise...

It's not really an entire operating system you've written. What you have is simple, partial system built on top of another.
File and text output are by far the easiest part ; for this the language doesn't matter.
I know because i've written my own sort of OS that works in a similar way, on top of AmigaOS. It's in all my programs that can use it ; users of these don't notice it's there because unused functions aren't in the executable. With it i could do picture viewer, sound player, many small tools handling files, and all my game ports.
Frankly MSDOS level of functionnality is just peanuts.

Originally Posted by kerravon

Well it's being done anyway.

Nope. Text-mode DOS programs don't use back-buffering or frame flipping. They just write on screen buffer.

Originally Posted by kerravon

If it's being done on the PC anyway, then what's wrong with ANSI control characters with a copy being done after a fflush()?

It's not being done on the PC anyway, what makes you think that ???

Originally Posted by kerravon

Because it is working. Even if you just look at this thread you can see that I have made massive advances in my knowledge. PDOS-generic only exists because of this thread.

So what is the next step ?

[kerravon]

Originally Posted by meynaf

It doesn't matter. In all cases, you can't turn non-trivial 16-bit MSDOS programs using x86_16's bogus memory model into 32-bit programs by just recompiling.

Why not? If the non-trivial program used large memory model, there was never a reason to code "far", so you can just recompile.

It's not among the things i'd keep from the past. I prefer to have control on my computer instead of using a remote one i don't own.

You can have it both ways if you channel everything through ansi.sys. I don't think you should be throwing the baby out with the bathwater.

People who invented C99 afterwards probably thought otherwise...

And I disagree with them. People have started tying things down to a requirement to have exact bitness like int32_t instead of int_least32_t. Instead of taking care to make your program work on an arbitrary computer like used to be the case.

It's not really an entire operating system you've written. What you have is simple, partial system built on top of another.

You seem to be talking about PDOS-generic. I mentioned PDOS/386. It isn't built on top of anything, although it does use the BIOS.

File and text output are by far the easiest part ; for this the language doesn't matter.
...
Frankly MSDOS level of functionnality is just peanuts.

I've been working on it since 1994. It isn't trivial.

Nope. Text-mode DOS programs don't use back-buffering or frame flipping. They just write on screen buffer.

But maybe they *should* because the hardware has the capability to do this and perhaps this would have resolved any complaints.

So what is the next step ?

Consolidate the GCC + binutils apparent win. Get time() working properly in PDPCLIB by finding out the names of the Amiga calls required and seeing if I have them in fd2pragma. And continue to try to find a way for text mode programs to work cross-platform in a way that I am comfortable with, so that I know how I should ideally have been coding circa 1990. Getting the mainframe and Amiga to connect to my BBS using my zmodem software would be good too. I want to prove that comms technology, mainly on the mainframe. Oh, and update the PDOS-generic convention to something acceptable to both UDOS (mainframe) and LK-DOS (8086) and see what these platforms can be made to do.

[meynaf]

Originally Posted by kerravon

Why not? If the non-trivial program used large memory model, there was never a reason to code "far", so you can just recompile.

Didn't you read what i wrote ? There is nothing such as large memory model provided by DOS !

Originally Posted by kerravon

You can have it both ways if you channel everything through ansi.sys. I don't think you should be throwing the baby out with the bathwater.

You just can't "channel everything" -- ansi is for output, not for input.
And either direction it's made, you're not in full control of the machine.

Originally Posted by kerravon

And I disagree with them. People have started tying things down to a requirement to have exact bitness like int32_t instead of int_least32_t. Instead of taking care to make your program work on an arbitrary computer like used to be the case.

So you prefer the mess of having every program define its own types and hope they work, i see.

Originally Posted by kerravon

You seem to be talking about PDOS-generic. I mentioned PDOS/386. It isn't built on top of anything, although it does use the BIOS.

As if it did change something.

Originally Posted by kerravon

I've been working on it since 1994. It isn't trivial.

Perhaps you need to rethink your strategy.

Originally Posted by kerravon

But maybe they *should* because the hardware has the capability to do this and perhaps this would have resolved any complaints.

But maybe they *shouldn't* because it has no sense ? There is absolutely nothing you can resolve this way. You're only adding complexity and extra opportunity to add bugs.
I'm not even sure PC text mode could even do this, btw.

Originally Posted by kerravon

Consolidate the GCC + binutils apparent win. Get time() working properly in PDPCLIB by finding out the names of the Amiga calls required and seeing if I have them in fd2pragma. And continue to try to find a way for text mode programs to work cross-platform in a way that I am comfortable with, so that I know how I should ideally have been coding circa 1990. Getting the mainframe and Amiga to connect to my BBS using my zmodem software would be good too. I want to prove that comms technology, mainly on the mainframe. Oh, and update the PDOS-generic convention to something acceptable to both UDOS (mainframe) and LK-DOS (8086) and see what these platforms can be made to do.

I.e. lots of complexity for little results.

[kerravon]

Originally Posted by meynaf

Didn't you read what i wrote ? There is nothing such as large memory model provided by DOS !

Not sure what you're talking about there. There are tiny, small, medium, compact, large and huge memory models available for the 8086.

You just can't "channel everything" -- ansi is for output, not for input.

Is there a reason ansi couldn't have been for input too?

And either direction it's made, you're not in full control of the machine.

You are so long as you don't redirect your terminal.

So you prefer the mess of having every program define its own types and hope they work, i see.

"int" and "long" exist for a good reason and should be the preferred types to use.

But maybe they *shouldn't* because it has no sense ? There is absolutely nothing you can resolve this way. You're only adding complexity and extra opportunity to add bugs.

By using buffering you can have a new screen displayed instantly, in case that is the barrier to adoption.

I'm not even sure PC text mode could even do this, btw.

Although I've never used it, I remember someone telling me that is how he wrote his code.

I.e. lots of complexity for little results.

I'm happy with the results of those things.

[meynaf]

Originally Posted by kerravon

Not sure what you're talking about there. There are tiny, small, medium, compact, large and huge memory models available for the 8086.

No. Only segmented memory model exists for 8086.

Originally Posted by kerravon

Is there a reason ansi couldn't have been for input too?

What ? You want the user to type ansi codes now ?

Originally Posted by kerravon

You are so long as you don't redirect your terminal.

Redirect to what ?

Originally Posted by kerravon

"int" and "long" exist for a good reason and should be the preferred types to use.

No. They are useless when reading data from files.

Originally Posted by kerravon

By using buffering you can have a new screen displayed instantly, in case that is the barrier to adoption.

No. This is called frame flipping, it's slower than direct screen access, and i strongly doubt PC text modes ever supported this anyway.

Originally Posted by kerravon

Although I've never used it, I remember someone telling me that is how he wrote his code.

Perhaps you need to find some docs online about this, to check what's possible and what's not.

Originally Posted by kerravon

I'm happy with the results of those things.

Isn't this lacking a little bit of ambition ?

[Thomas Richter]

Originally Posted by meynaf

What ? You want the user to type ansi codes now ?

Actually, it would be the keyboard or some other input channel that would create the ANSI codes.

Originally Posted by meynaf

No. They are useless when reading data from files.

It depends. For external representation of data, int and long are useless as they are not portable. For internal algorithms, "int" is the fastest integer type the machine offers, so it does make sense to use it, tough not for external data representation.

Originally Posted by meynaf

No. This is called frame flipping, it's slower than direct screen access, and i strongly doubt PC text modes ever supported this anyway.

Actually, they do.

Originally Posted by meynaf

Isn't this lacking a little bit of ambition ?

Well, I personally don't quite see the point of this project in first place.

[kerravon]

Originally Posted by meynaf

No. Only segmented memory model exists for 8086.

I have no idea what you are talking about. Segmentation introduces the different memory models I listed.

No. They are useless when reading data from files.

They are perfectly fine for a file for internal use. For external use you can use chars the same way I got PDOS-generic to read FAT hard disk images on the Amiga.

Isn't this lacking a little bit of ambition ?

Ambition like what?

[kerravon]

Originally Posted by meynaf

No. This is called frame flipping, it's slower than direct screen access, and i strongly doubt PC text modes ever supported this anyway.

I had another thought. Maybe MSDOS could have been extended to have another interrupt that returns a buffer that just so happens to be 0xb8000, with those characteristics, and when you've finished updating that buffer you are required to do another interrupt that displays that buffer. On an IBM PC this may or may not involve frame flipping, but on the Amiga this would instead involve a different set of manipulations (and the address wouldn't be 0xb8000) and maybe if there was a terminal involved, it would result in some ANSI escape sequences.

[meynaf]

Originally Posted by Thomas Richter

Actually, it would be the keyboard or some other input channel that would create the ANSI codes.

But what codes ? A key press is just a character (usually).
And ANSI codes don't handle keys by position, do they ? How the heck can we then do "WASD" kind of key detection for movement ?

Originally Posted by Thomas Richter

It depends. For external representation of data, int and long are useless as they are not portable. For internal algorithms, "int" is the fastest integer type the machine offers, so it does make sense to use it, tough not for external data representation.

This is what i said, they are useless when reading data from files - aka external representation of data.

Originally Posted by Thomas Richter

Actually, they do.

Strange, i always thought the screen's memory buffer was at a fixed address, something like $b8000. The reason why peecees were limited to 640kb.

Originally Posted by Thomas Richter

Well, I personally don't quite see the point of this project in first place.

Neither do I. But perhaps i can still help.

Originally Posted by kerravon

I have no idea what you are talking about. Segmentation introduces the different memory models I listed.

Oh yeah ? Then you have to tell what each one of them is, in detail - so that we're sure we're speaking about the same thing.

Originally Posted by kerravon

They are perfectly fine for a file for internal use. For external use you can use chars the same way I got PDOS-generic to read FAT hard disk images on the Amiga.

But even chars aren't guaranteed to have fixed size. And inefficient for handling larger datatypes anyway.

Originally Posted by kerravon

Ambition like what?

Like something more complete feature wise. Say, bitmap graphics, sounds, multitasking, keyboard/mouse/joystick handling, GUI, timers/interrupts, and whatever i forgot about. My own system framework even contains functions for handling dynamic strings/arrays...

Originally Posted by kerravon

I had another thought. Maybe MSDOS could have been extended to have another interrupt that returns a buffer that just so happens to be 0xb8000, with those characteristics, and when you've finished updating that buffer you are required to do another interrupt that displays that buffer. On an IBM PC this may or may not involve frame flipping, but on the Amiga this would instead involve a different set of manipulations (and the address wouldn't be 0xb8000) and maybe if there was a terminal involved, it would result in some ANSI escape sequences.

This is not new, it's called lock/unlock of frame buffer...
But for text-only it seems overkill. Besides, it is not a proper abstraction for text output (the host would have to do screen format translation if it's not an old PC with text modes).
I rather see things this way : a function which takes x,y position and string as input, shows the text at the given place, and then returns updated x,y position. Or that function would take special value as position to resume from previous one.