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

GIMP certainly is better, but for instance much of GNOME was pretty
infested with non-ANSI gccisms or gnumakeisms still quite recently.


Reply via email to