Congradulations - windef.h
boaz at hishome.net
Thu Jan 1 06:42:27 CST 2004
Alexandre Julliard wrote:
>"Dimitrie O. Paun" <dpaun at rogers.com> writes:
>>On December 31, 2003 04:38 am, Boaz Harrosh wrote:
>>>they were/are protected, but I think it should be removed from winegcc
>>>because they don't do the Job.
>>Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h
>>idea. In general, he does not like non-standard headers...
>No, I don't. Boaz, could you please explain a bit more why the
>definitions in winegcc don't work for you?
In short __declspec( selectany ) && __declspec( thread )
It has been discussed before. Lots of reasons
- Why header ? why not command line?
1. It is best if defines are in a header file and not on an hard-coded
command-line. One would like to have the freedom to override default
defines. For example: a windows dll project will have ten tons of
dllimport/dllexport directives. The GCC will warn about it (I have
3.3.1). If in a header, one can nullify this directive and have clean
compilation instead of tunning off warnings and miss on Fatal warnings
(there are some warning in GCC that should be errors and make your
program fly :( ).
2. If you inspect my patch you see that it is not that small. putting it
all on a command line is not practical.
3. In an header you can do things that a command line can't. For example
current code will do an __ONLY_IN_WINELIB(). Now winegcc will override
that. Which means winegcc can not be used for wine compilation. And that
makes it harder for a, one day, have MinGW/Wine set of Makefiles. (See
(If you think about it, many wine dll's could be compiled as PE with
MinGW and make no difference)
Conclusion: winegcc should stick to command-line switches and
translations of options. like include directories, extra libs and so on.
All code related and defines should go to an header file. If you don't
like the ms-extensions.h name than it can be winegcc.h.
- What's new in the patch?
1. The main 2 things that are currently missing for me are: a) selectany
vs weak and b) __declspec( thread ) vs __thread. These completely break
under current implementation. The only way to go is with Ove's solution
of mapping all options to defines and than overriding as necessary.
(hard to do on a command line)
2. Please have a quick look on my current patch. I have done quite a
comprehensive mappings of all __declspec's to GCC options. it should not
be missed by winegcc users.
I do not like current proposed solution (windef.diff). These things
do not belong in windef.h - proof of that they are absent from M$
windef.h. They belong in a special header that mediates between
different compilers. (like msvc vs gcc in our case). One could use
ComuC++ or borlandC++ or even Intel, to compile wine and also to compile
his WineLib application. These compilers have their own partial support
for Microsoft extensions. And could actually make a WineLib user's life
a bit easier because of other gcc peculiarities that forces them to
change perfectly good code.
What I propose is to go and collect all these msvc'ism into one
header and clean that mess away from pure wine headers. I promise to not
save any efforts in doing so. (One does at most what one can do :) )
And before we decide about all that, please accept my current patch it
will not touch winegcc users only make them miss some of the fun.
More information about the wine-devel