Development Status Update 3

[Harold Hunt <Harold at compasstechnologies dot com>]

Sometimes a problem can be daunting because you don't know the size of it;
fortunately, the header issue turned out to be fairly simple.

Identifier collisions between X and Win32 headers come down, so far, to
three typedefs or #define'd data types, one function, and one macro and
function collision.

Data types:
ATOM (Win32: WORD, X: unsigned long)
BOOL (Win32: int, X: unsigned char)
BYTE (same datatype, one #define'd, the other typedef'd, I think)

Functions:
FreeResource()  (Win32: deprecated, so it can be #ifdef'd out)

Macro/function:
CreateWindow (Win32: macro, can be #undef'd, X: part of screen structure,
function prototype)

For now I munged a couple header files to allow compilation, albeit with
warnings; I'll have to go back later and thoughtfully address each of the
five cases identified so far to determine a more appropriate resolution.

I have removed all calls to functions residing in xf_dx.dll and replaced
them with code in XWin.exe; I have not yet torn out all stray references to
xf_dx.dll.

My to-do list, slightly amended from yesterday, is as follows:
1)  Finalize header file fixes and produce diffs
2)  Finalize Imakefile changes and produce diffs
3)  Remove references to xf_dx.dll from XWin.exe code
4)  Standardize any identifier names that have slipped through
	the cracks
5)  Try to eliminate as many build warnings as possible
6)  Remove deprecated files
7)  Add some comments/tips
8)  Tarball the source and diffs
9)  Release the framework for other developers to examine

Keep in mind that we will still have to do some design work before we start
implementing functions in the framework... though we may be able to throw
together a machine independent implementation fairly quickly just to have
something that works.

I'll keep everyone posted,

Harold