Timeline for Invert LCD screen in DOS 5.0
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 13, 2020 at 21:07 | history | edited | user3840170 | CC BY-SA 4.0 |
spelling
|
| Dec 13, 2017 at 2:00 | comment | added | Jules | E.g., a "quick virus scanner" (i.e. program that listed all executable files on the disk and checked their details against a hashtable from the last run) I wrote back in the early 90s originally used DOS output to display the details of each file it checked as it was doing so, and took about 3 minutes to process a 40MB hard disk. Switching to direct display output shaved that down to less than 1 minute: printing the names of each file through DOS took longer than getting the directory listings that contained them and looking up their details in an on-disk hashtable. | |
| Dec 13, 2017 at 1:58 | comment | added | Jules | @Tommy - right. Almost every full-screen program bypassed the DOS/BIOS screen output routines (and therefore ANSI.SYS which hooked into those) in order to work directly with display hardware. It wasn't just games; DOS's display handling routines were slow enough that just about any program that did non-trivial tasks with the screen could benefit from direct output. | |
| Dec 12, 2017 at 15:03 | comment | added | Tomas By | @RichF: haven't got anyhing to work in the sense of actually changing the colours. Am looking at Ultravision now. | |
| Dec 12, 2017 at 14:38 | comment | added | Tommy | It's not just games though, surely? Wasn't Lotus 1-2-3 one of the standard "how compatible is this IBM compatible?" test pieces because it goes straight to hardware? I can't think of any application more straight-laced than a spreadsheet. | |
| Dec 12, 2017 at 14:00 | comment | added | RichF | Have you verified your ECHO commands outside the .BAT? Or better yet, comment out the program's launch within the .BAT than ran it to see if the ECHOs worked? Even if they work as expected, your program may be bypassing normal console control (as Stephen implied), in which case they bypass ANSI.SYS. // Hmm, I don't know why ANSI.SYS would prevent your machine from booting. It was part of msDOS since v2.0. | |
| Dec 12, 2017 at 13:43 | comment | added | Tomas By |
No, it doesn't seem to have any effect. The program is started from a .bat file, and I am adding echo ANSI commands at the beginning (after loading ansi.sys from condig.sys).
|
|
| Dec 12, 2017 at 13:35 | comment | added | Stephen Kitt | ... or programs which read the current settings and apply them manually (console I/O under DOS has a lot of moving parts depending on the variant). | |
| Dec 12, 2017 at 13:34 | comment | added | RichF | @TomasBy It will only affect programs which use normal text screen drivers. Games, for example, would not even know ANSI.SYS was there, and it would have no effect upon them. Plus, you can change colors on the fly in between programs. | |
| Dec 12, 2017 at 13:33 | comment | added | Tommy | I think ANSI.SYS provides a virtual terminal, so can affect only those programs that do not go straight to the hardware. In non-virtualised DOS I don't think anybody gets to tell the latter what to do. | |
| Dec 12, 2017 at 13:24 | comment | added | RichF | @TomasBy sorry, I've gotten out of habit of thinking in DOS. I was editing my answer as you added your comment. ANSI.SYS works fine (and originally intended for) a full-screen environment. | |
| Dec 12, 2017 at 13:20 | history | answered | RichF | CC BY-SA 3.0 |