Marti Maria wrote:
I'm considering as a solution to add a conditional #define named "LCMS_WIN_TYPES_ALREADY_DEFINED"
That would only take effect on non-windows compilation.
That could work for Wine, yes. And then use LCMS_VERSION to find out if the header supports this.
If this special flag is declared, then the types:
BYTE, LPBYTE, WORD, LPWORD
DWORD, LPDWORD, BOOL, FALSE, TRUE;
LPSTR, LPVOID, FAR, LOWORD() HIWORD() MAX_PATH
cdecl, ZeroMemory, CopyMemory should be added to this list.
The only drawback I can see is integral types should agree, but that seems not to be a big problem at all.
Actually, there may be a problem in this regard. DWORD is defined as 'unsigned long' on Windows, Wine and MinGW whereas lcms.h defines it as 'unsigned int'. These definitions are compatible on 32 bit systems AFAICS, but I'm not sure about 64 bit systems. Can someone enlighten us here? Anyway, the difference causes compiler warnings and that's why I did this:
#define DWORD LCMS_DWORD #include <lcms.h> #undef DWORD #define DWORD DWORD
So to get back Wine's original (typedef) definition of DWORD I redefine the (preprocessor) definition of DWORD after including lcms.h. This is a dirty hack because basically I'm circumventing C's type checking here.
Let me ask this question, is there a reason for DWORD's definition in lcms.h being different from the one on Windows?
-Hans
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
