Bregalad wrote:Does they allow indirect access through BIOS calls ? How to do those with C language ?
With
DJGPP (GCC for DOS), BIOS calls in C looked something like:
Code: Select all
#include <dos.h>
void mode_13h()
{
union REGS regs;
regs.h.ah = 0x00; // AH = task parameter for BIOS call (00h sets video mode)
regs.h.al = 0x13; // AL = mode to use (13h is VGA 320x200 8-bit bitmapped)
// call BIOS interrupt 10h
int86(0x10,®s,®s);
}
It's not that different from how you'd do it in assembly, you just have a wrapper function that copies a C structure into the real registers, runs the interrupt instruction, then copies the registers back into your C structure (in case it had a return value).
Bregalad wrote:I tought the whole point of "PC compatibles" is that older stuff is still supported...
I think it's a bit of a
Ship of Theseus, or a
ring species situation. Each generation has been backwards compatible with a few generations prior, but eventually the old ones get dropped off.
Though in the case of PCs, the graphics hardware is still VGA compatible. The critical difference is just that direct access to hardware is now restricted by the operating system (with help from the modern CPU) to only be available to device drivers.
You
could switch operating systems though.
There's one called
FreeDOS which is meant for this purpose. (Modern, open source variation of DOS, intended to run new and old DOS software.) You can dual-boot with it, of course. (Running it in a VM or just using DOSBox might be a lot more convenient?)
Bregalad wrote:But it'd be extremely impractical to write a program which is designed to be booted into. Users would have to reserve a partition on a USB key or CF card or whathever storage device just for this program, and they'd have to reboot every time they want to use it
Ha ha ha, but making a "boot disk" just to run one game that's already installed on your hard drive was definitely part of the authentic DOS experience.
There were many games that I needed special boot settings for (e.g. not loading device drivers you don't need for that game to conserve memory). Of course, it used to boot in under 10 seconds too, and extra floppy disks to use for this were cheap.
Bregalad wrote:Developing new applications which requires DOSBox do not sound like a great idea to me. It'd feel like programming a NES game intended to be run in Nesticle.
Just becomes it would run in DOSBox in Windows doesn't mean it can't run natively in an appropriate environment, though? I mean... most people here are used to this from NES already. I don't really see what's so different about this case...