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
