nancygold's Journal

DOS Gamedev
Decided to proceed with decompiling that game, because it does some really funny and unusual things already in the init code.
Fore example, it has a special routine for opening its data file for reading.

int file_open_rdonly(char *filename) {
  int handle, hwerr;
  
  do {
    HWErrorHndlrInstall();
    handle = _open(filename,O_RDONLY|O_DENYNONE); /* O_DENYNONE = Allow concurrent access  */
    hwerr = HWErrorHndlrUninstall();
    if (handle != -1) return handle;
  } while (hwerr == ERR_SHARING_VIOLATION);
  return -1;
}

The HWErrorHndlrInstall install an error handler, overriding existing handler at `int 24h`, but just for the duration of the call to _open.

That _open is your usual Unix open syscall, which in case of Borland C++ 3.0 translates to calling the DOS through int 21.
In case of some concurrent DOS systems and network filesystems it can try accessing a locked file, so they install the handler to catch the 0x20 = ERR_SHARING_VIOLATION. The open itself also has an unusual O_DENYNONE flag too, which tells DOS to not lock the file.

I know nothing about DOS, but apparently it does lock files which were opened for reading, so even the program itself can't open them for reading?

Also, I'm still struggling to imaging why would a simple game, running under a frigging DOS, care about its config file being locked.

Additionally, these these HWErrorHndlrInstall/HWErrorHndlrUninstal, the 48-bit random number generator, are one of the few routines written in assembly and residing in the base code section after the standard C library

Current Mood: amused