Hello, I am calling this patch pre5 rather than #5 because it doesnt fully address the rest of the PSDK porting issues and one of my new years resolutions for 2004 is for every patch I send to winehq to be good enough to go right in to CVS. ;)
With this patch we can build 90% of comdlg32 on MS_VC with the PSDK except for one major bug and one minor question.
1. Can we please fix winnt.h line 175? This #define NONAMELESSSTRUCT thing is wrong. It breaks building on the PSDK and w32api. I have not be able to find any thing about it in Microsofts documentation or headers. If we removed support for it its going to break GCC 2.8.xx but if someone is on 2.8 its time to upgrade.
/me is quoting here from the Microsoft headers under Fair use and all of that......
"// // For compilers that don't support nameless unions // #ifndef DUMMYUNIONNAME #ifdef NONAMELESSUNION #define DUMMYUNIONNAME u #define DUMMYUNIONNAME2 u2 #define DUMMYUNIONNAME3 u3 #define DUMMYUNIONNAME4 u4 #define DUMMYUNIONNAME5 u5 #else #define DUMMYUNIONNAME #define DUMMYUNIONNAME2 #define DUMMYUNIONNAME3 #define DUMMYUNIONNAME4 #define DUMMYUNIONNAME5 #endif #endif // DUMMYUNIONNAME "
Thats it. All I can find is the DUMMYUNION stuff in some of the headers. If we just remove support for DUMMYSTRUCT in WINE its going to break a lot of stuff so we will prob'l need to perl script the cleanup.
2. Do you want me to dump printdlg.h now and compleate the cleanup or can it wait untill after the DUMMYSTRUCT thing is fixed? I can move the rest of the structures and internal function declairations to cdlg.h and cdlg16.h now but I want to wait till I can get printdlg.c to compile with out bitching about missing member s1 and u1 blah...
Thanks Steven
__________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003
On January 4, 2004 01:39 pm, Steven Edwards wrote:
- Can we please fix winnt.h line 175? This #define NONAMELESSSTRUCT
thing is wrong. It breaks building on the PSDK and w32api. I have not be able to find any thing about it in Microsofts documentation or headers. If we removed support for it its going to break GCC 2.8.xx but if someone is on 2.8 its time to upgrade.
Alexandre, let's just get rid of the NONAMELESSSTRUCT support, it just causes problems, and the benefit is a bit dubious. Any interesting compiler will probably be compatible with either msvc or gcc or both. Should I look at creating a patch?
"Dimitrie O. Paun" dpaun@rogers.com writes:
Alexandre, let's just get rid of the NONAMELESSSTRUCT support, it just causes problems, and the benefit is a bit dubious. Any interesting compiler will probably be compatible with either msvc or gcc or both. Should I look at creating a patch?
I don't think it's a good idea, it will break a lot of things, including gcc 2.95 support.
--- Alexandre Julliard julliard@winehq.com wrote:
Alexandre, let's just get rid of the NONAMELESSSTRUCT support, it just causes problems, and the benefit is a bit dubious. Any interesting compiler will probably be compatible with either msvc or gcc or both. Should I look at creating a patch?
I don't think it's a good idea, it will break a lot of things, including gcc 2.95 support.
So is there any fix for us? Can we move the NONAMELESS stuff to a internal header like like port.h? MSVC does even define NONAMLESSONION in the same place we do with WINE and w32api.
Thanks Steven
__________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus
Steven Edwards steven_ed4153@yahoo.com writes:
So is there any fix for us? Can we move the NONAMELESS stuff to a internal header like like port.h? MSVC does even define NONAMLESSONION in the same place we do with WINE and w32api.
That won't really help, it needs to be available in the exported headers since it's used in structure definitions. Building with MSVC headers will require changing the code to use macros everywhere we reference the nameless structs.
On January 6, 2004 03:17 pm, Alexandre Julliard wrote:
Building with MSVC headers will require changing the code to use macros everywhere we reference the nameless structs.
Man, oh man, this will greatly uglify things. Clearly, there is no perfect solution to this problem, we'll have to make a tradeoff. Now, I have tested nameless structs with gcc 2.96 (which comes with RedHat 7.x), and they work just fine. I haven't tested with any of the 2.95.x, but even if they don't work, it's been more than 2.5 years since 3.0 hit the streets.
In other words, by now most people have upgraded from 2.95.x. Apparently Dave Miller claims 2.95.x is still desirable on Sparc, but that's not that interesting for us. On the other hand, being able to compile Wine with the PSDK brings real value. We can not look back forever, 2.5 years is long enough. For people who are hell bent to use 2.95, they can install a newer gcc version in a different directory, and use that to build wine. It's unpleasant, but not a big deal.
"Dimitrie O. Paun" dpaun@rogers.com writes:
In other words, by now most people have upgraded from 2.95.x. Apparently Dave Miller claims 2.95.x is still desirable on Sparc, but that's not that interesting for us. On the other hand, being able to compile Wine with the PSDK brings real value.
I frankly think that being portable to various Unix compilers is of more value than building with the PSDK headers. I have nothing against adding hacks to enable both, but killing our Unix portability to support MSVC headers is not a good idea.
-
Alexandre Julliard -
Dimitrie O. Paun -
Steven Edwards