OK, here we go: GRX builds under Cygwin and MinGW, I have tried and tested both (sans printing), AFAIKT there is not more broken than there was before :-) Changes:
I have changed a couple of things in the sources of GRX 2.4.5: * src/vdriver/vd_win32.c: - Removed WinMain() and GRXLocalMain() - Moved the window registering code into detect() - Added code in setmode() that creates a message dispatcher thread that creates the graphics window and dispatches messages for it. - Added the WndThread - Changed WndProc(): No more need to Suspend the Worker task and having the Dialog box
* include/grx20.h - Nearly the patches Mariano proposed. If __CYGWIN32__ is defined, we also define __WIN32__. I am not sure this is a very good idea in the long run, one should rather check in the code if __MINGW32__ or __CYGWIN32__ is defined. - Removed the #undef GRXMain for the MinGW case, no longer needed.
here are the diffs:
<<grx20.diff>> <<vd_win32.diff>>
There seems to be an issue with the screen clearing after closing and re-opening the graphics window, so this is for sure not the final word. Also, the logic when to give the focus to the graphics window seems not to work as I want it to, so I need to recheck this.
Ciao Tom
-----Original Message----- From: Mariano Alvarez Fernandez [SMTP:malfer@telefonica.net] Sent: Mittwoch, 22. Januar 2003 19:29 To: Demmer, Thomas Cc: 'grx@gnu.de' Subject: Re: GRX2.4.5 and MinGW/Cygwin
[Demmer, Thomas] [...]
Please post your modified video driver here, if it doesn't hurt the Mingw port it will be ok, or (not desirable) we can have a special version for Mingw.
This was easy enough to do by creating grx.dll instead of libgrx.a and do the initialization in DllMain(). Thinking about this, I see no point
why
this cannot be moved to frame buffer creation stage... Hmm, I'll have a look into that.
You seem to know well the Windows platform and the GRX Win32 video & framedrivers have lot of problems/bugs. So you are welcome to improve it. As a suggestion (I have in my to do list for some day), the best thing will be to catch the window memory address and let the standard GRX framedrivers do the work.
A question about CygWin I'm not sure is license. I think CygWin programs must be GPL and GRX is LGPL. I don't know if this is a problem.
Greetings, M.Alvarez
Hi, Tom
In general, I like your changes to the windows videodriver, because we get rid of the special GRXMain entry point. It has some rough edges: pressing the close button is catastrophic (at least in W98) and the last app doesnt't get the focus when the GRX app end. But is a good start.
Some suggestions:
- Setmode. Create the window_thread only if mp->extinfo->mode != GR_frametext, and destroy the window_thread (if created) else.
- Detect. The detect function can be called more than one time, so it is necesary to have a static variable to signal it and return TRUE if the work was done. Move the InitialiceCriticalSection to "init" and add DeleteCriticalSection to "reset".
- Reset. Destoy the window_thread if was created.
- WM_CLOSE. We need to maintain the close dialog, people must be warned they are avorting the program. If user says yes, move the message to the queue, and let abort the program in the input driver (the main thread) mouse/w32inp.c.
Greetings, Mariano.
Mariano Alvarez Fernandez wrote:
In general, I like your changes to the windows videodriver, because we get rid of the special GRXMain entry point.
BTW, if you integrate this, please don't forget to remove the respective lines in the two Pascal units.
Frank
-
Demmer, Thomas -
Frank Heckenbach -
Mariano Alvarez Fernandez