Hello, First thanks Dimi and Alexandre for the header fixes. I have been outa town till lastnight so I have not had a chance to do much testing of the MS_VC build yet. I will start working on this soon as I want to get these dlls imported in to ReactOS. First thing is first. Whats up with the *_must_be_suffixed_with_W_or_A_in_this_context error? To build comctl32 with the Mingw/PSDK headers we need to do something about this. Almost every file is expecting IDC_ARROWA and the PSDK/w32api dont define a A/W suffix. I think once we fix this comctl32 should build out of the box with the PSDK or w32api. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Steven Edwards wrote:
First thing is first. Whats up with the *_must_be_suffixed_with_W_or_A_in_this_context error?
If you are compiling a core Wine DLL, you are not allowed to use the base name (IDC_ARROW). You must pick either the Ansi (IDC_ARROWA) or Wide (IDC_ARROWW) versions. To achieve this, wine uses a macro called "WINELIB_NAME_AW". It is defined in windef.h. You can see that if UNICODE is defined, this macro adds the "W" at the end, if not defined, it adds an "A" at the end, but if it is part of the wine compilation, it defines a name that is bound to cause an error, by appending "func_must_be_suffixed_with_W_or_A_in_this_context". In other words, if you need the Ansi version, use IDC_ARROWA. If you need the Unicode version, use IDC_ARROWW, but you cannot use IDC_ARROW from inside a Wine DLL.
To build comctl32 with the Mingw/PSDK headers we need to do something about this. Almost every file is expecting IDC_ARROWA and the PSDK/w32api dont define a A/W suffix. I think once we fix this comctl32 should build out of the box with the PSDK or w32api.
Just use IDC_ARROWA directly. If you get this error, it implies that you are using the Wine headers already. As IDC_ARROW is defined in include/winuser.h on line 2560, and IDC_ARROWA is defined two lines above it, I find it hard to accept that IDC_ARROW is defined as it is, while IDC_ARROWA is undefined.
Thanks Steven
Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Shachar Shemesh wrote:
Steven Edwards wrote:
First thing is first. Whats up with the *_must_be_suffixed_with_W_or_A_in_this_context error?
If you are compiling a core Wine DLL, you are not allowed to use the base name (IDC_ARROW). You must pick either the Ansi (IDC_ARROWA) or Wide (IDC_ARROWW) versions. To achieve this, wine uses a macro called "WINELIB_NAME_AW". It is defined in windef.h. You can see that if UNICODE is defined, this macro adds the "W" at the end, if not defined, it adds an "A" at the end, but if it is part of the wine compilation, it defines a name that is bound to cause an error, by appending "func_must_be_suffixed_with_W_or_A_in_this_context".
Steven's point is that MS headers don't define the A and W version of the resource identifiers (both resource types - RT_???? - and default resources - ID?_???? -). Which means we cannot compile some Wine DLLs (like commctrl, but also winmm, shell32...) without the wine headers. Since Wine code relies on information which isn't defined by the MS headers (nor the Mingw's), we do have an issue here. As a comparison: - wine defines any resource (say XX) as either XXA if _UNICODE isn't defined, or XXW if _UNICODE is defined. - MS headers don't define the XXA and XXW types but directly the XX constant. First of all, we need to change wine's header (winuser.h here) to stick to windows'. so the possible solutions are: - As we compile Wine without the _UNICODE flag, we could change the code as follows: XXA => XX XXW => (LPWSTR)XX drawback: we'll have warnings if we need to compile with the _UNICODE flag... - create a wine internal header for those specific definitions (the XXA and XXW) which would be defined as currently in winuser.h. We should also undefine the XX to avoid using the XX form of the constant. A+ -- Eric Pouech
Eric Pouech wrote:
Shachar Shemesh wrote:
Steven Edwards wrote:
First thing is first. Whats up with the *_must_be_suffixed_with_W_or_A_in_this_context error?
If you are compiling a core Wine DLL, you are not allowed to use the base name (IDC_ARROW). You must pick either the Ansi (IDC_ARROWA) or Wide (IDC_ARROWW) versions. To achieve this, wine uses a macro called "WINELIB_NAME_AW". It is defined in windef.h. You can see that if UNICODE is defined, this macro adds the "W" at the end, if not defined, it adds an "A" at the end, but if it is part of the wine compilation, it defines a name that is bound to cause an error, by appending "func_must_be_suffixed_with_W_or_A_in_this_context".
Steven's point is that MS headers don't define the A and W version of the resource identifiers (both resource types - RT_???? - and default resources - ID?_???? -). Which means we cannot compile some Wine DLLs (like commctrl, but also winmm, shell32...) without the wine headers. Since Wine code relies on information which isn't defined by the MS headers (nor the Mingw's), we do have an issue here.
That's not entirely true. It's true that only IDC_ARROW is defined, but it is defined as "MAKEINTRESOURCE(32512)". MAKEINTRESOURCE, in turn, is defined as a AW macro. Still, I agree that we are in a somewhat of a fix here. How about if we do it this way: Define IDC_ARROWn as 32512 Define IDC_ARROW as MAKEINTRESOURCE(IDC_ARROWn) This way, you will still get the error, you are still prohibited from using an unqualified version. From within the Wine sources, you can just do MAKEINTRESOURCEA(IDC_ARROWn). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Still, I agree that we are in a somewhat of a fix here. How about if we do it this way: Define IDC_ARROWn as 32512 Define IDC_ARROW as MAKEINTRESOURCE(IDC_ARROWn) This way, you will still get the error, you are still prohibited from using an unqualified version. From within the Wine sources, you can just do MAKEINTRESOURCEA(IDC_ARROWn). but IDC_ARROWn won't be defined in MS headers... so wine source won't compile with MS headers
thus, this either boils down to defining the IDC_ARROW[AW] in a wine specific header A+ -- Eric Pouech
Eric Pouech wrote:
Still, I agree that we are in a somewhat of a fix here. How about if we do it this way: Define IDC_ARROWn as 32512 Define IDC_ARROW as MAKEINTRESOURCE(IDC_ARROWn) This way, you will still get the error, you are still prohibited from using an unqualified version. From within the Wine sources, you can just do MAKEINTRESOURCEA(IDC_ARROWn).
but IDC_ARROWn won't be defined in MS headers... so wine source won't compile with MS headers
Makes you wonder about one thing, though - do you think that the Windows sources compile with the Windows headers? I think defining headers to be used only when compiling Wine itself ought to be acceptable.
thus, this either boils down to defining the IDC_ARROW[AW] in a wine specific header
Guess so. The only alternative is to use a cast when using a W function with IDC_ARROW.
A+
Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
--- Eric Pouech <pouech-eric(a)wanadoo.fr> wrote:
If you are compiling a core Wine DLL, you are not allowed to use the base name (IDC_ARROW). You must pick either the Ansi (IDC_ARROWA) or Wide (IDC_ARROWW) versions. To achieve this, wine uses a macro called "WINELIB_NAME_AW". It is defined in windef.h. You can see that if UNICODE is defined, this macro adds the "W" at the end, if not defined, it adds an "A" at the end, but if it is part of the wine compilation, it defines a name that is bound to cause an error, by appending "func_must_be_suffixed_with_W_or_A_in_this_context".
<snip>
- create a wine internal header for those specific definitions (the XXA and XXW) which would be defined as currently in winuser.h. We should also undefine the XX to avoid using the XX form of the constant.
I like this idea. WINE will never be able to built out of the box using just the PSDK. Even M$ seems to have there own internal SDK so I guess we should create include/wine/internal.h and move everything there? If we do this then we dont have to change any of the sources except to add that header and it should build. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
so the possible solutions are: - As we compile Wine without the _UNICODE flag, we could change the code as follows: XXA => XX XXW => (LPWSTR)XX drawback: we'll have warnings if we need to compile with the _UNICODE flag...
I think what we want is to add casts in all cases, both A and W. That's unfortunately the only way to make the code really portable. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Eric Pouech <pouech-eric(a)wanadoo.fr> writes:
so the possible solutions are: - As we compile Wine without the _UNICODE flag, we could change the code as follows: XXA => XX XXW => (LPWSTR)XX drawback: we'll have warnings if we need to compile with the _UNICODE flag...
I think what we want is to add casts in all cases, both A and W. That's unfortunately the only way to make the code really portable.
In that case, wer'e going to do ugly things in the code, why not just call "MAKEINTRESOURCEA/W" in the source? It is still not exactly "nice", but at least it doesn't assume that (WCHAR*)MAKEINTRESOURCEA(5) is a legal thing. Shachar P.S. On retrospect, this may be what you (Alexandre) meant to begin with. Sorry for the repeat if so. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
participants (4)
-
Alexandre Julliard -
Eric Pouech -
Shachar Shemesh -
Steven Edwards