nanogui: Microwindows for Hercules
Subject:
RE: Microwindows for Hercules
From:
Greg Haerr ####@####.####
Date:
15 Jul 1999 22:36:10 -0000
Message-Id: <01BECEDF.7F940AF0.greg@censoft.com>
: Obviously it would be smart to fill it in. However you must set it to NULL
: in the driver because of symbol resolution.
:
: As long as the device driver header file version matches with the one that
: the microwin server uses, the offsets are known.
:
: Locating the symbols inside the driver is the hard part.
:
: Perhaps a separate file, created via an external program, which contains
: this structure, is the better way to go. This way when the structure changes,
: you don't have to go around recompiling all the drivers that have been
: distributed, you just need a program to fixup your jumptable files.
Currently this is all overkill, since the drivers are compiled into the
microwin binary. Also, due to inkd of a neat design, we don't have the problems
that require the driver symbol to be NULL.
:
: Does anyone know if code exists to hunt for symbols inside a binary? Does
: bcc generate any symbol information?
Sure, you can run nm86 on .o and a.out files.
:
: If bcc doesn't generate any symbol info, then I would suggest that each driver
: be an archive of object files, with a manifest. You would need the code from
: the linker to search the archive and something to read the manifest.
:
: >
: > struct driver herc_card[]={
: > herc_hline,
: > herc_vline,
: > generic_line,
: > };
: >
: > or it can be done in a function that examines the structure at load
: > time and patches up any NULLs with real function pointers. This is a
: > good way to reduce the special cases.
All this would be solved with Al's DLL stuff, which he's working on.
Then we'd having dynamically linked libraries, of which each driver would be one.
Greg
: >
