[Libevent-users] libevent 1.4.13 on Windows

[Michael Lenaghan <michaell@xxxxxxxxxx>]

Hello, all.

I compiled libevent 1.4.13 on Windows (using the free Microsoft Visual
C++ 2008 Express Edition) and ran into some issues that I thought I'd
pass on.

 * The libevent.sln file doesn't work out of the box; it fails to load
the test sub-projects because it's looking for .vcproj files that
aren't there. (If you open the libevent.dsw file it will create the
missing .vcproj files as it upgrades the project file.)

 * The project statically links the CRT using /MT and /MTd. In various
places MS recommends that you dynamically link the CRT unless you
"know what you're doing." Although dynamically linking the CRT using
/MD and /MDd entails its own issues (with manifest files and such) I
think that would still be a better default stance. (I've provided
excerpts from two MS pages below that disciss static CRTs.)

 * The event.h file does this:

#ifdef WIN32
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN
...

I'd suggest only undefining WIN32_LEAN_AND_MEAN if event.h did the
define in the first place; otherwise you might screw up other code.

 * The Windows code uses snapshots of config.h and event-config.h.
They contain the wrong version number:

In config.h:

/* Version number of package */
#define VERSION "1.3.99-trunk"

In event-config.h:

/* Version number of package */
#define _EVENT_VERSION "1.3.99-trunk"

 * The most interesting problem I ran into was the fact that Windows
also has an event.h file. Depending on the order in which include
directories are searched that can really screw you up. In my case I
included evhttp.h; evhttp.h included event.h; and then the file I was
compiling failed because ev_int64_t wasn't defined--despite the fact
that it should have been. It took a bit of time to sort that out!

===

I've noted a few small issues, but they were minor; I wanted to point
out that getting libevent up and running on Windows was really quite
easy. So: well done.

===

Using the statically linked CRT implies that any state information
saved by the C runtime library will be local to that instance of the
CRT. For example, if you use strtok, _strtok_l, wcstok, _wcstok_l,
_mbstok, _mbstok_l when using a statically linked CRT, the position of
the strtok parser is unrelated to the strtok state used in code in the
same process (but in a different DLL or EXE) that is linked to another
instance of the static CRT. In contrast, the dynamically linked CRT
shares state for all code within a process that is dynamically linked
to the CRT. This concern does not apply if you use the new more secure
versions of these functions; for example, strtok_s does not have this
problem.

Because a DLL built by linking to a static CRT will have its own CRT
state, it is not recommended to link statically to the CRT in a DLL
unless the consequences of this are specifically desired and
understood. For example, if you call _set_se_translator in an
executable that loads the DLL linked to its own static CRT, any
hardware exceptions generated by the code in the DLL will not be
caught by the translator, but hardware exceptions generated by code in
the main executable will be caught.

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

If you do choose to mix CRT libraries, remember that you have two
separate copies of the CRT, with separate and distinct states, so you
must be careful about what you try to do across a CRT-boundary. There
are many ways to get into trouble with two CRTs. Here are just a few:

 * There are two separate heaps. You cannot allocate (explicitly with
new, malloc, or so on -- or implicitly with strdup, strstreambuf::str,
or so on), and then pass the pointer across a CRT-boundary to be
freed.

 * You cannot pass a FILE* or file handle across a CRT-boundary and
expect the "stdio low-level IO" to work.

 * You cannot set the locale in one and expect the other's locale to be set.

http://support.microsoft.com/kb/140584
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.