Architecture

[Jean-Claude Gervais <jc dot gervais at videotron dot ca>]

Hi again,


	I've been doing some thinking, and here's what I've arrived at, feel free
to give me feedback.


	Essentially, the XOpenWin application should act as a loader, meaning it
loads the requested Windows program we would like to redirect and injects a
DLL into it that will perform the function hooking. It can then exit. Its
job will be accomplished.


	The DLL, on startup, (meaning during the DLLMain's PROCESS ATTACH
notification) must hook the app's GDI and USER calls, and establish a link
to a third entity that we can call the XOpenWin server. The DLL needs to
manage the state of its application's display, so that if the app ever
closes, the DLL and whatever it had accumulated, as task information will go
away.

	On the other hand, the DLL might be able to "talk" to Cygwin-XFree by
itself, or it might not.

	Cygwin XFree is a unique resource on the system, like a serial port would
be, if you like. So I don't think it can be "shared". We'd probably need an
"XOpenWin Server", that would be the access point for all XOpenWin client
app's ingress to X. Alternatively, the code to service the X requests could
also cohabitate within the DLL, whatever is decided should be selected on a
basis of flexibility and robustness.

	Should this module be a part of Cygwin-XFree? Probably not; adding huge
chunks into existing modules just makes them more complicated, it would
probably be best to have an XOpenWin Server, that would serve as interface
to Cygwin-XFree.

	That's all I've got for now. Please let me know what you think and lets
refine our ideas further.

Jean-Claude