[meynaf]

Originally Posted by kerravon

I would think use the W, A, S, D keys for cursor movement would be something that the application is not actually aware of. My interest is clean applications. It is a secondary concern for the OS to be clean.

It is not for "cursor" movement, but for player movement in some game. Or for whatever, it does not matter.
A program should have the ability to detect key presses. Or key releases. Or several keys simultaneously.

Originally Posted by kerravon

The segmentation models, which (as far as I can tell) are a facet of computer science, or even maths, rather than the 8086, are:

Nope. They're just x86 stuff - and largely obsolete stuff in addition.

Originally Posted by kerravon

tiny - code and data segments are the same and unchanged. this is actually what normal systems like the Amiga use as the only available option.

Amiga has nothing such as "code and data segments", so, no.
Compilers can be setup for "small data" model, where a register (typically a4 or a5) is used to access bss section. That's about all.

Originally Posted by kerravon

small - code and data segments are fixed, but different, giving you up to 64k for each address space

medium - code segment register can change (so needs to be reloaded all the time), allowing you to have more than 64k of code. data restricted to 64k.

compact - code segment register doesn't change, so code restricted to 64k, but data register is constantly reloaded allowing more than 64k of data to be addressed.

large - both code and data segment register are constantly reloaded, allowing access to more than 64k of both code and data

huge - same as large, but when data (not code) pointers are manipulated, care is taken to ensure that if a 64k boundary is crossed, the segment register is adjusted, and in either case, the offset is normalized to be as small as possible. This has a large performance overhead and is rarely used, and a popular C compiler, Turbo C, doesn't even support it properly, merely allowing static data to exceed 64k in this model.

This is why it is not necessary (as far as I can tell, from my experience in writing an OS), to plaster your code with near/far pointers. All you need to do is select a memory model appropriate to your requirements. Unfortunately when I was writing PDOS/86, and mostly sharing a code base with PDOS/386 (it was only later with PDOS-generic that I realized the code base could be shared beyond just x86), I only understood up to "large", but actually the job for the OS (but not applications) required "huge".

Well i don't know where you fetched all this, but anyway it is clear that segmentation has an impact, whatever efforts done to try to hide it away.
Compare this to 68k where you can access any place, any time, and still use things similar to short pointers (relative accesses).
If you want your system to work on top of true MSDOS, you should perhaps consider going to flat mode.

Originally Posted by kerravon

chars are guaranteed to have at least 8 bits, and so long as you don't attempt to put more than 8 bits of data into each char, there shouldn't be a problem. I can't think of one, anyway. Yes, it's inefficient, and in the unlikely event that you run a profiler over your code and discover that the bottleneck of your application is in this code, you could go to the effort of having some macros which default to the inefficient manipulation, but can use direct access if you are on the most important platform.

That's not the point. It makes char type unsuitable for reading bytes from a data stream. There is no "read byte" primitive in C.

Originally Posted by kerravon

Understood. I am hoping that commercial vendors will see a market opportunity for something that satisfies an apparent need as above, and rather than write it from scratch, they can start with the PDOS code base, lowering their development costs, and passing those savings on to the consumer (I believe in capitalism).

If you want your system to serve as a basis for something more advanced, you have to design it in a way that will allow this. But apparently you are currently closing the door to even simple graphics...

Originally Posted by kerravon

Why do you think it is overkill? It's the proper way to provide a snappy display of a screen, isn't it? If the reason people refuse to use ANSI codes is the failure to be snappy, then fine, lock/unlock a frame buffer to give others an opportunity to convert to ANSI codes.

Text-only display is fast enough, especially on a text screen, so yes, it's overkill.
Besides, flipping frames requires either recomputing whole scene or data copying from previous scene. So you will lose performance for little benefit - if any at all.

Originally Posted by kerravon

Not sure what constitutes "proper". It's just one more valid paradigm, isn't it? I'm looking for a solution to get MSDOS programs written in a way that satisfies the main PC market, yet opens up the ability to use the Amiga as an alternative.

A proper abstraction is something that hides the implementation details and therefore allows different implementations to be used.
MSDOS is PC hardware oriented.

Originally Posted by kerravon

Understood. I'm not ready to discuss the world's best screen abstraction paradigm. All I'm looking for is a paradigm acceptable to the PC, where people felt the need to directly manipulate the hardware, for unspecified performance reasons (I believe), yet has necessary "metadata" to allow interpretation on alternate systems.

Yes, you are looking for something specific to PC, that can with some efforts and some workaround also work on other systems but guess what, Amiga already has PC-Task for this. We don't need an MSDOS port.

Frankly, fflush(stdout) for screen handling, really ? What if someone redirects output to some file ? Yes, with simple ">file" command. Oh yeah, now the user will see nothing and wonder what happens !
Graphical operations and file operations are two very different things and it is IMO horrible design mistake to have them use same API. Or maybe it's just me, because i can do screen setup with just 4 lines of asm using my system framework.