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
