> The use of (n)curses for example is a typical Unix thing, that has > nothing to do with DOS and should not be shoehorned into a DOS > application...
add DEVICE=ANSI.SYS to your config.sys and you can easily 'port' (=compile and fix C compiler discrepacies) your curses programs to DOS. >> >>> Some *ix utilities MIGHT be useful for the use on DOS, >> MKS Toolkit? GNUish? EMX? DJGPP? Heck, even Simtel and Garbo had a few. > I said "some" utilities. Not everything plus the kitchen sink. >> >> >> "The Lessons of Unix Can Be Applied Elsewhere" >> > Nice statement, but I think that this is wrong. And just for the record, > I used my first Unix system before I used my first DOS system... > Unix was from the start to be an abstraction of the hardware underneath, > running on different hardware, usable with minimal knowledge of the > hardware (specially, CPU wise). > DOS (as in MS-DOS/PC-DOS) is directly tied to the Intel 8086 CPU, it's > segmented memory models, it's access to an underlying BIOS (and various > extensions) on the hardware level and out of necessity, much more > reliant on direct access to the hardware underneath. >> >>> And yes, an article, possibly a series of articles, about programming on >>> DOS, for DOS, will be forthcoming... programming *on* DOS in the year 2023 is like self flagellation. you are absolutely allowed to do it; it's just not recommended. >> I built and tested P5 Pascal (ISO 7185) with GPC (and GNU Make) for >> DOS, Windows, and Linux. > ISO 7185 is the worst thing that could happen to Pascal. Utterly useless > and outdated by the time it was released. > Same as the standards for "minimal" and "extended" BASIC. There is not > one mainstream BASIC implementation that is really sticking to either one.. +1 Tom _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
