> And this is the first application I've heard of > that insists on ESC sequences instead of using > the BIOS routines,
I think it's not that straightforward. I would expect (ie could be wrong) that most fullscreen text applications - written by people who don't even use DOS - e.g. Amiga, VAX, Unix, would be using ANSI escapes by default (I don't see any other choice - at least as default - this is the only standard we have for text mode terminals). Yes, if you're prepared to add a curses layer, then you can support both the standard, plus non-standard things like a PC BIOS. But neither fullscreen application that I actually used and care about (microemacs and msged) added that layer (both added their own layer though). > so it's a limited market. Sure. It's starting off like that. Everything I produce is. At least to date. > Shooting for platform independence is admirable. Sure. At some level I am trying to answer "what went wrong?". And perhaps demonstrating what we could have had instead if people had simply followed the standards. Although C90 came a bit late for people to be in a position to follow. BTW, I forgot to mention something. One thing that underpins the totally portable (other than ASCII/EBCDIC differences for keyboard characters) is a specific flavor of the C90 spec. If you do setvbuf NBF to switch off buffering of stdin, it is assumed that by default that the C library will switch into raw mode and switch off line buffering, so that all the platform-specific code that would otherwise need to be done to achieve that (all the tset stuff on Unix e.g.) is hidden away in the C library. But in reality there is no requirement for the C library to actually do that that I am aware of, and I'm not aware of anything other than PDPCLIB that does that. So if using an arbitrary C library your application would be forced to add platform-specific code after all. > Trying to force decades > old operating systems to match is probably a dead end. Do you mean started decades ago or ended decades ago? Both Freedos and PDOS/86 are in active development. Windows is in active development too, and at a particular point in Windows 10 finally embraced ANSI X3.64, allowing the platform independence. In fact, I remember reading something on Microsoft's website with regard to the old methods that used a virtual screen buffer as being obsolete and not the direction Microsoft was taking. I'm not stating that Microsoft is embracing the exact same concept that I am (not saying they're not either), but I don't think it is so black and white that the microemacs that I just released as source and DOS binary is inherently useless. You should have seen the horrifying procedure you used to have to do to create or edit files on UC8086. Of course you can say that UC8086 itself is inherently useless too. But I'm expecting to burn the latest UC8086 onto a CF and boot it on my Book 8088 later today. I don't think I can even do that with the Freedos distribution I use as I think it has a dependence on an 80386 processor. So for an alternative to UC8086 I will be using MSDOS 6.22 and ANSIPLUS. What can the Book 8088 ship with that isn't a copyright violation? Limited market - for now, probably. But the small keyboard may be suitable for my nearly 2 year old daughter. I need to see how fast the CGA graphics program loads a still picture too (or whether it works at all). I think newborns can only see high-contrast black and white images (which is all I currently provide). The ability to distract a newborn is measured in seconds and those seconds are extremely valuable in my experience. The main application I wrote (on UC8086 now) is "bincount", but it was only about a month ago that I first managed to get my daughter to just hit enter instead of pressing random keys. I don't think she was observing the feedback though. That was on PDOS/386. I'll probably be having a fresh attempt on the Book 8088. Limited market? Probably. Forever? Probably. Probably. Linus said that his Unix would never be as sophisticated as what was it? SCO? I've forgotten. Almost no-one else has even heard of it to even forget. BFN. Paul.
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
