Re: basic file handling in glib.

[Guy Harris <gharris flashcom net>]

On Thu, Sep 07, 2000 at 08:04:03PM -0400, Havoc Pennington wrote:
> GLib doesn't have a file abstraction layer; for portability you have
> to use fopen() and so on from the standard C library,

That being why it's called the "standard" C library. :-)

Ethereal, for example, uses the C I/O routines for a lot of its file
I/O, and works fine both on Windows and UNIX.

> and avoid using UNIX features such as file permissions.

...and also being careful to use "b" in the mode argument to "fopen()"
if one is opening a file to which one will read or write binary data
rather than text; on Windows, for example, '\n' gets turned into '\r\n'
when writing to a "FILE *" not opened in binary mode, and '\r\n' gets
turned into '\n' when reading from a "FILE *" not opened in binary mode.

That's not a complete list of the things one must do if one is writing a
GTK+ application to run both on Windows and UNIX; for example, if the
application is to run in the GUI subsystem rather than the console
subsystem on Windows (i.e., a console window shouldn't be popped up for
the application if the application isn't run from a console window), the
main routine has to be "WinMain()" rather than "main()", although the
following hack, stolen from the Win32 port of the GIMP:

	#ifdef WIN32

	#ifdef __GNUC__
	#define _stdcall  __attribute__((stdcall))
	#endif

	int _stdcall
	WinMain (struct HINSTANCE__ *hInstance,
	         struct HINSTANCE__ *hPrevInstance,
	         char               *lpszCmdLine,
	         int                 nCmdShow)
	{
	  return main (__argc, __argv);
	}

	#endif

obviates the need to do too much to handle that.

You'd also have to include the appropriate Windows header files when
doing that.

I don't know if anybody has a compendium of tips of that sort.