Re: glib-tml-980819-0.patch

[Tim Janik <timj gtk org>]

On Thu, 20 Aug 1998, Tor Lillqvist wrote:

> Just uploaded:
> 
> glib-tml-980819-0.patch is the renewed version of my GLib patch for
> Win32. Now only the glib.h file contains those uglyish GLIBAPI
> declarations, they aren't needed in the .c files.
> 
> (Maybe that GLIBAPI stuff isn't too bad on Unix, either, with them you
> can see which functions are intended as the public API, and which are
> just for glib's internal use?)

actually those fuctions shouldn't appear in glib.h then...

ok, i'm currently reading over your diff...
and got some comments:

glib error handlers:
you have basically just commented out the code that is performed
by g_debug and g_stack_trace, and let them just call abort() if
NATIVE_WIN32 is defined.
since all three functions, g_attach_process, g_debug and g_stack_trace
are a somewhat "hackish" unixism, i'd really like to rename them to
something like

void g_unix_attach_process (const gchar *progname,
                            gboolean     query);
void g_unix_debug          (const gchar *progname);
void g_unix_stack_trace    (const gchar *progname,
                            gboolean     query);

and just provide default implementations like {abort();} for them
on systems like windows.
this way, the unix-related behaviour of these functions is clearly
stated in the API, and i guess this change wouldn't impose many
problems, 'cause there shouldn't be many programs out there that
make actuall use of fork()+exec(gdb).

GLIBAPI stuff:
i'm hesitating a bit to apply this, since it would be nice if we could
keep glib.h in its current manner. the automatic Window header file
generation i suggested in the "Re: Gtk port to Win32 "progress report""
thread might be a solution to this.

./gmessages.c:
- what do you define GMESSAGES_C for?
- you are making definitions for a newline string and its length,
  i'd say we should better make those global, so other programs
  can take advantage of this in their output as well (plus
  a directory seperator):
  #ifdef NATIVE_WIN32
  #define G_NL "\r\n"
  #define G_NL_LEN 2
  #define G_DIR_SEP "\\"
  #else /* !NATIVE_WIN32 */
  #define G_NL "\n"
  #define G_NL_LEN 1
  #define G_DIR_SEP "/"
  #endif /* !NATIVE_WIN32 */
  
- does the AllocConsole() and WriteConsole() stuff properly deal with
  out of memory conditions?

gmodule.h:
- there is a reason for extern const char *g_log_domain_gmodule; to be
  defined prior to the inclusion of glib.h (though a bad one). the
  g_wanring, g_message and g_error inline functions (#ifndef __GNUC__)
  use this variable within their function body, so it needs to be defined
  when glib.h is included.
- why do you prefix the function typedefs for GModuleCheckInit and
  GModuleDeInit with GMODULEAPI? so far my understanding was, that GMODULEAPI
  is only required for actuall symbols that need to be exported...

testgmodule.c:
- granted, i didn't care much about fiddeling out the actuall file names for
  dynamic plugins yet, so your change to just #ifdef WIN32 for changing
  the plugin names is probably justified ;) but we should really supply an
  extra function for this, something like
gchar*
g_module_make_file_name (const gchar *module_name)
{
  g_return_val_if_fail (module_name != NULL, NULL);
#ifdef WIN32
  return g_strconcat ("lib", module_name, ".dll", NULL);
#else /* !WIN32 */
  return g_strconcat ("lib", module_name, ".so", NULL);
#endif /* !WIN32 */
}
  btw, why are you checking for "WIN32" here, and not for "NATIVE_WIN32" as
  in the above?

miscellaneous:
- we probably need to make adaptions to a few else functions,
  e.g. g_dirname, g_basename come to mind.


ok, that's about it ;)
for one i'd really like to thank you very much for going through
this, making glib more portable is actually a *very* worthwhile
goal.
also, i'm pretty astonished how few changes actually were required
to get this going under windows, especially since a big bunch of
your chages is only about checking for the existing include files
and similar stuff. but maybe that's just me ;)


> BTW, I have now compiled and linked gdk and gtk. I ran the _simple_
> program this morning and it even opened a window called "hello world".
> But it speweed out lots of errors about unrecognized objects and color
> allocation failures... Still, progress.

cool, i'll definitely want to see that somewhen ;)

> 
> --tml
> 

---
ciaoTJ