Hi.

I ported GRX to lcc-win32, overcoming all it's (lcc-win32's, no offence) bugs somehow, but wasn't happy with the results: -O (optimize) generated invalid code. Anyway, I gained some experience and was able to write DLL support for the MinGW version of the library. How it works:

1. The MinGW section of makedefs.grx contains a new setting, "USE_DYNAMIC". When set to 'y', all sources are compiled with -D__DLL32__ and src/makefile.w32 creates/installs/etc. a DLL and an import library instead of a static library.

2. <grx20.h> and <libbcc.h> define "extern", if not already defined, to "extern __declspec(dllimport)" if __DLL32__ is defined and to "extern" if not just before the first public symbol, and undefine it after the last public symbol.

3. The private headers (<libgrx.h>/<bccgrx00.h>/...) define "extern" to "extern" before including <grx20.h>/<libbcc.h>.

4. All GRX suorces include <grx20.h>/<libbcc.h> not directly but via a private header [14 changes] and include <libgrx.h> before <grdriver.h>/<grfontdv.h>/<grxkeys.h> [1 change].

It sounds more compilated than it is. In a few words, the exported public symbols are seen as "extern" by the library and as "extern __declspec(dllimport)" by the applications.

5. If the DLL is being detached and the window thread is still [indicated as] running, the GRX window is closed.

All symbols from <grx20.h> and <bccgrx.h> are exported; the symbols private to GRX are exported because of their macro usage (mostly when GRX_SKIP_INLINES is not defined). _GrCloseVideoDriver is exported solely because of demogrx.

To use the DLL version of the library, simply recompile your application with "-D__DLL32__". The DLL is 341KB, the test programs are (average) 16KB; demogrx is 24KB; bccbgi is 37KB (all executables stripped). The overhead of using a DLL is significant when doing many calls to small GRX functions, such as get/put pixel, and negligible for complex functions.

The DLL is stable. If anything is improperly declared inside libgrx, either the assembler fails because of duplicate "_D" symbols, or the DLL doesn't link because of missing "__imp_" symbols. That is, you can't have an invalid DLL. All tests run as supposed and the changes aren't big, so IMHO the DLL support is worth including in the 2.4.6 release. Mariano?

P.S. <bgiext.h> is emptied, it does the same as <libbcc.h>. P.P.S. Non-incremential, as far as my patches are concerned.