Mail Archives: cygwin/1998/09/13/05:18:56
>
> Since the use of _WIN32 to conditionalize code for portibility started
> prior to the cygwin project, I ask that you pick a new macro, say
> _WIN32_API_, to use for your definition. I shouldn't be forced to
> have to be concerned with breaking headers if I undefine _WIN32 as the
> original poster of this message had to do.
>
Hello People,
My biggest issue with the consequences of -U_WIN32 was the fact that the code
compiled cleanly whether or not _WIN32 was defined. It was at execution time
that the trouble started. Code compiled with _WIN32 defined worked just fine.
The same code compiled with -U_WIN32 did not, access violated and provided no
clues as to what went on that I with my limited experience could use to
diagnose and correct the problem. I would have, most likely, been looking at
what I did wrong in my code, which would have been a wrong place to look :-)
Fortunately for me I had the code working on all 4 platforms I built for, I was
fiddling with the GNUmakefile at the time, I remembered what I did AND I
remembered that the code worked before I did -U_WIN32. Just luck all the way
....
In less favourable circumstances I would have likely wasted a great deal of
time trying to fix my code, which was not broken, and eventually given up on
building for Cygwin32 environment :-(. That would not have been bad, merely
inconvenient for me. Others, which is why I posted the issue and the
'workaround', may not be so lucky.
------------------
Cheers ...
Michael Czapski
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -