Ethereal-dev: Re: [Ethereal-dev] patch to fix runtime problems with Visual Studio > 6

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Tue, 07 Mar 2006 20:57:09 +0100
RABRET Laurent RD-MAPS-ISS wrote:
Hi,
Please find enclosed a patch fixing problems with Ethereal compiled with
Visual Studio > 6. In the code I fixed, when "glib" >= 2.6 was used,
some macros forced file operations to be process through glib. The
problem was that glib is compiled with VS6. Hence, there was a run time
lib mismatch problem causing Ethereal to crash at runtime. I've added
some "#pragma comment" in the code because when glib will (if ever...)
be compiled with VS > 6, symmetrical problem will occur (...but for
Ethereal compiled with VS6).  My feeling is that to avoid such problems,
it is probably better to never use glib for file operations (on Windows
at least). However, it's certainly a bad idea if glib provides many
advantages (I don't know). If you also think it's better to suppress
glib file operations on Windows, you would just have to slightly modify
this patch...
There's a problem with Unicode chars in the filenames, therefore the GLib conversion functions are used since GTK2.6.

See http://wiki.ethereal.com/Development/FilenameEncoding for some details.

As Gerald has recently implemented the WIN32 native file dialogs (which are currently not working with Unicode chars), I'm quite unsure about the way to go now.

Currently we are using UTF8 internally and converting it at the "outside corners", just as the Unix version does.

It might be better to use locale based filenames instead of UTF8 on Win32, which would make the least trouble AFAIK. There's only one disadvantage: characters other than the current locale won't work. But that might be acceptable.
PS: don't you think it's time to officially support/distribute Ethereal
compiled with an "up to date" VS compiler on Windows?
In general: yes. MSVC 6 is really outdated and AFAIK no longer supported by MS in any way.

However, switching would mean we had to compile all the libs we use on our own (which I personally wouldn't like to do) or wait until all the libs we use provide a MSVC 7+ version (which is unlikely in the near future).

Regards, ULFL