Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@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 ReactOS) (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.
- Conclusion: 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.
Free life Boaz