Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] USE_THREADS on Win32

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: Sun, 04 Jul 2004 21:17:58 +0200
Gisle Vanem wrote:

"Ulf Lamping" <ulf.lamping@xxxxxx> wrote:

main.c:
The definition USE_THREADS won't be set anywhere, so your changes won't take any effect ?!?
Has this to be added to the config.h.win32 file?

Yes, or to config.nmake.
How is it done for UNIX builds? I would imagine, that it's done using the config.h created by configure? In that case, we might want to do it the same way (defining USE_THREADS in config.h.win32). As the detection of the GTK
version is done in the code (main.c) this should do in all cases.


You shouldn't remove hints about problems detected in earlier versions:
/* multithread support currently doesn't seem to work in win32 gtk2.0.6 */
otherwise this has to be tested all again and again and again and ...

Well, I use GTK+ 2.4.3 and haven't seen any problems with threads
yet...
Yes, but there are others that might need special GTK version as they are installed on their specific platform, and they might be thankful for any advice they can get. I'm testing on GTK1.3, GTK 2.2 and GTK2.4, so I might be interested ...


webbrowser.c:
Why is webbrowser.c compiled faster when another header file is included?!?

No, it compiles faster if WIN32_LEAN_AND_MEAN is defined. Thus <windows.h>
doesn't include all kind of crap we don't need. Except for the case of webbrowser.c
and print_mswin.c where <shellapi.h> and <winspool.h> is needed. But I quess you who use MSVC also use precompiled headers, so the speed isn't noticeable. But it matters for MingW/gcc which doesn't have PCH yet (and hearing the problem with PCH in gcc 3.4+, it be a long time untill we have it).

Now I understand, I will add this to webbrowser.c

Regards, ULFL