Ethereal-dev: Re: [Ethereal-dev] patch to fix runtime problems with Visual Studio > 6
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