4 ms·
The whole slow IO library, was a problem in a lot of places and spawned the nansi.sys/etc utilities on dos too. That is because the DOS console output services
by StillBored 4y ago
The whole slow IO library, was a problem in a lot of places and spawned the nansi.sys/etc utilities on dos too. That is because the DOS console output services were generally a lot slower than could be accomplished with a bit of hand spun assembly running out of RAM. So instead of going through ansi.sys + BIOS int 10 it was possible to hook the output int (21,2 IIRC) and dump right to the text framebuffer tracking little more than the current color and cursor position.
It was so easy I wrote my own at one point (before I discovered/got nansi.sys? I can't remember the sequence). It was IIRC faster than the later nansi sys replacements but didn't work 100% of the time either. Probably because I only implemented the common subset needed to run a couple programs I wanted faster text output from. I remember for a while switching back and forth between mine and a replacement driver depending on application before I got a 486+VLB which was so fast that I could no longer tell the difference between the two.
- rep_lodsb 4y agoMost full-screen programs wrote directly to video memory anyway. It's mainly the ones ported from UNIX that needed an ANSI driver. Now in the glorious future of 2022, every console app runs on an emulated DEC VTxxx, and if you press "Esc" it can't be sure if that's a real key or part of some control sequence unless it waits a second to find out if more bytes arrive.