Okay, so that must mean mingw comes with dozens or hundred of header files that contain the same win32 API function declarations, structure declarations, constant definitions, and so forth.
So, did they do "the obvious thing" (or obvious to me, anyway), which is to "allow all #include statements that refer to win32 API functions/structures/constants/etc" remain identical - AND - only require the header search path be different (to find the wingw32 versions)?
Or, did they require win32 programs be totally revamped to include different header files?
I will try what you suggest, but I think I already did that, and it failed. So I guess now I will remove all windoze/win32 specific search paths (and everything else), rediscover why that approach did not work, and report my problems here.
Just to be super-clear. When compiled with LINUX defined (in the IDE in the #define tab), the #ifdef LINUX blocks in my code creates windows via the lowest-level xlib XWindows function calls I could find. Ditto for every kind of create/query/configure/destroy function for OS-specific entities like "GPU", "display", "window" (some via the GLX subsystem of XWindows, which supports OpenGL). When compiled with WINDOZE defined (in the IDE in the #define tab), the #ifdef WINDOZE blocks in my code does all the above via totally conventional win32 API function calls.
So my engine actually *is* two engines - one for linux, one for windoze (though both based upon OpenGL) - with those #ifdef LINUX/WINDOZE statements deciding which contents of my functions are compiled on each OS. Of course, you really can't tell this from the "outside", because all OS-specific code is inside functions like "ig_window_create()"... which give no clue which OS (or graphics subsystem either, in fact) is creating/resizing/destroying windows, or creating/rotating/moving 3D objects, or doing collision-detection, or anything else.
The *interface* is totally "everthing independent", but it contains two sets of code for OS-specific functionality. However, what may not be obvious to folks who have not created such an engine, the OS-specific portion is only about 1% now, and will become 0.1% later, and in the long, long term eventually, probably less than 0.0001% or so. In fact, though the engine can "direct [static or shared] link" to any application that wants these capabilities at maximum speed, the engine can be driven by 100% identical client/application code through a "sockets/network layer"... so the client/application and server/engine literally can be totally different (different CPU, different OS, different endian, different programming language, different human language, different # of bit CPU, different <fill in the blank>).
Yes, everyone tells me I am totally crazy to write all this lowest-possible-level-OS-dependent-code myself - that I should save myself the time and effort by adopting some layer or framework. Sorry, been there, done that, got badly burned every time I depended upon every kind of "make it easier for me" promise. And every time I program at the absolute lowest level I can, it not only "works", but is vastly easier to understand, vastly more reliable, much faster, and nothing is *ever* hidden from me or beyond my control (until we enter the realm of the GPU innards, which my GPU shaders [and GPUPU code] deal with to the extent practical). So I can find, understand and fix problems and/or enhance anything in any way I wish, at any time - to the extent possible at all. So, just warning everyone, don't bother to suggest I "get conventional" in this way. Not gonna happen. But thanks for helping me figure out these problems, and thanks for all advice you care to give (except that one issue, where you are wasting your time on one intransigent doofus).
Oh, BTW, the only "external library" I adopt in my engine (so far) is OpenGL (though soon I may be forced to adopt some low-level sound library to avoid device-specific sound-programming). Do I get access to that simply via the glee.h and glee.c packages? Or what? Where should those be included from or where should I move a copy of the following files to? gl.h glx.h glext.h glxext.h