bright@dataioDataio.UUCP (Walter Bright) (10/24/85)
I have been watching the evolution of MS-DOS for some time, and never see some fundamental problems being corrected. These corrections I believe are simple to implement, and would ease a lot of difficulty for us implementors. I am posting this in the hope that Microsoft/IBM will see it, and maybe feel some pressure to correct them. 1) Provide an MS-DOS 'configuration' call that would return the following information: a. What is the CPU? (8088, 80286, etc.) b. What is the clock rate? c. What display is connected? is it color? d. Is there an 8087 or 80287 connected? e. What is the manufacturer and model # of the machine? f. Is ANSI.SYS installed? What other device drivers are installed? g. Is 'Windows' or 'Topview' active? h. How many serial ports are connected? Many of these are discernable by examining the BIOS. But in order to do that, the program becomes 'misbehaved' and non- portable. Having such calls would make it possible for programs to write directly to the screen for machines it knows are safe, and to automatically revert to more 'well-behaved' but slower methods when these are necessary. Programs could also become largely self-configuring. 2) Rewrite the serial I/O BDOS calls so they are interrupt driven internally to MS-DOS, and have a choice of XON/XOFF protocol or handshaking to handle flow control. Every communications program I know of has to directly manipulate the hardware to do this, and therefore becomes hopelessly non-portable. Until MS-DOS provides these services, Microsoft and IBM will have to continually struggle with misbehaved programs.