Quote:
|
Originally Posted by DaWei
It's unlikely that you'll be able to use the old Borland stuff. If you're talking about the vintage I'm thinking of, it won't run under a memory-managed, I/O protected system.
|
Actually, you might be surprised. Under Windows, at least, it should work as long as he stays away from SuperVGA modes. I've done programming with 'tweaked' VGA modes ('mode-x' and such) under Win2K, and it seems to work fine. My theory is that since the OS knows about the standard VGA registers, it can properly virtualize access. With the SVGA modes, the OS can't really regulate things, since each card behaves differently, so it just blocks access to the I/O ports involved (though there are hacks to get around this).
Quote:
|
Originally Posted by DaWei
I might add that neither the old EDIT that ran under MS-DOS nor the EDIT that runs under cmd.exe is a GUI. They're purely text mode. You can achieve that functionality by merely making a console-based application.
|
Yup. I believe this is exactly what the OP had in mind.
@OP: if you want to do this sort of thing, you need to be clear whether you're writing a true DOS program, or simply working in a command window in WinNT/2K or later. Under Win9x/ME, it was a 'DOS box', but under later versions, it's not.
If you're writing a DOS program, you can use several methods.
One is to call the BIOS (generally done through assembly, inline or otherwise, or the interrupt wrapper functions available in many DOS compilers). This is one of the slower methods in most cases, not that you'll notice on modern machines.
Another is direct memory access; text mode video memory is at a fixed (for the video mode) address. This memory is alternating character and attribute bytes; the character is obviously the extended ASCII code of the character at that position in the frame buffer, and the attribute byte is a bit field representing foreground and background (3 bits each), intensity (one bit; essentially it adds to the foreground field), and the blink/background intensity bit (it either makes the foreground text blink, or expands the range of background colors much as the intensity bit does for foreground colors). I don't recall offhand whether it's the attribute or character byte that comes first, though. Note that this method only affects the content of the frame buffer. It does not reposition the cursor, and you need to address this issue, which can be done by calling BIOS to set the cursor position, or directly accessing the video card registers (typically through assembly, though some DOS compilers support wrapper functions to read and write I/O ports).
Another is to use features supplied by your compiler. Some DOS compilers have library functions to position the text-mode cursor; subsequent text writes (via printf(), for example) will take place at this new position. Likewise, you might find functions to set the text color, etc.
Lastly, you can use the functionality of a console driver that provides positioning and attribute control. An example would be DOS's ANSI.SYS, but you can get better ANSI drivers, such as NNANSI. In this case, you just embed escape sequences into your text output, and you're set. This solution isn't exactly the best, though; ANSI drivers aren't commonly set up on Windows machines these days. Also, the text can get cluttered up with escape sequences, which can make for ugly string literals (though this isn't so much a drawback as something you need to keep in mind). You can write wrapper functions to bypass this last issue.
If you're writing a Windows console program, you can use the Win32 API to handle this, or you can- oh wait, the Win32 API is the only way. If this is what you're doing, I can give you some pointers, but if it's not, I'm not going to bother.