Marc Lehmann writes: > So much for ANSI-C: > ../include/lcms.h:38: windows.h: No such file or directory > typedef HANDLE cmsHPROFILE; > WORD GammaTable[1]; > cmsHPROFILE LCMSEXPORT cmsOpenProfileFromMem(LPVOID MemPtr, DWORD dwSize); Well, he does say it is intended for the Windows platform, so this is to be expected. Including <windows.h> is for a programmer on Windows as natural as including <stdio.h> for C programmers in general. Of course it is sad that people write an inherently portable library using Windows-specific types etc, but that's life. (Note: I do *not* consider myself a Windows programmer, but I play one on this list ;-) Most of these types have obvious counterparts in GLib. (WORD = guint, HANDLE = gpointer, LPVOID = gpointer) The real challenge when/if porting this is if some Win32 feature that does not have a portable equivalent is used. > the c standard (double definitions, indented preprocessor constructs, nice > calls to the ansi function "MessageBox" etc..) And a corresponding Unix library would call the ansi function "syslog"? GIMP certainly is better, but for instance much of GNOME was pretty infested with non-ANSI gccisms or gnumakeisms still quite recently. --tml
