Re: [Qemu-devel] [PATCH 9/9] w32: Replace Windows specific data types in common header files

[Stefan Weil <sw@weilnetz.de>]

Am 24.02.2014 11:17, schrieb Kevin Wolf:
> Am 23.02.2014 um 18:02 hat Stefan Weil geschrieben:
>> These header files are used by most QEMU source files. If they
>> depend on windows.h, all those source files do so, too.
>>
>> All Windows specific data types which are replaced use identical
>> definitions for the 32 and 64 bit Windows APIs. HANDLE and LONG
>> can be directly replaced by void * and long. CRITICAL_SECTION
>> is replaced by a new struct of the same size.
>>
>> Add an explicit dependency on sysemu/os-winapi.h for some files which need it.
>> These sources use the Windows API (see comment after include statement)
>> and no longer get windows.h indirectly from other header files.
>>
>> A workaround which was added in the previous patch is no longer needed.
>>
>> Now 175 *.o files remain which still depend on windows.h.
>>
>> Cc: Anthony Liguori <aliguori@amazon.com>
>> Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> Cc: Kevin Wolf <kwolf@redhat.com>
>> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> Not sure if I understand the problem. Why is it bad to depend on
> windows.h?
>
> Kevin

It's not generally bad, but there are some disadvantages if too many
files depend on it.

Let me explain first what windows.h is (I assume you know that, but
maybe others don't): it is the central Windows API header which includes
lots of other files, so we don't talk about a single header file but a
rather large collection of such files. Another header file which QEMU
uses very often is glib.h for the glib-2.0 API. I counted the number of
files which get included by a simple #include of one of these two header
files and also measured their size:

glib.h (Debian wheezy)
  564910 bytes in 86 files, this includes 22 standard header files like
stddef.h, ...

windows.h (Debian wheezy MinGW-w64)
  3659593 bytes in 116 files (macro WIN32_LEAN_AND_MEAN is not defined),
10 of them are standard header files
  1147623 bytes in 46 files (macro WIN32_LEAN_AND_MEAN is defined)

QEMU uses WIN32_LEAN_AND_MEAN, but even then windows.h gets about 1 MB
of header file code whereas glib.h gets more files but only 0.5 MB of
header file code.

This header file code is analysed by the compiler more than 1800 times
for a full build, so the compiler reads and parses about 2 GB of code.
Native builds on Windows are slow. Reading and parsing 2 GB does not
make them faster. I don't know whether caching compilers are available
for Windows and if so whether they work good.

There exist several implementations of the header files for the Windows
API: the original header files from Microsoft (which exist in different
versions, but QEMU does not use them), the MinGW implementation (was
standard for QEMU), the MinGW-w64 implementation (now recommended for
QEMU, supports 32 and 64 bit) and the Cygwin implementation (currently
unsupported and not working with QEMU). All of them differ and need
special handling. By including windows.h we get potential problems and
namespace pollutions . The current QEMU code already contains some hacks
for such problems (which are removed by my patches) and would need one
more hack (which is not needed with my patches). See also a discussion
which I and Peter had nearly a year ago:
http://patchwork.ozlabs.org/patch/244758/. It was the trigger for this
patch series.

All those different implementations of the Windows API header files use
the same definitions for basic types as HANDLE or LONG, so we don't
loose anything by replacing the Windows specific types by standard C
types. Nor would we gain anything if we introduced new types like
QEMU_HANDLE or QEMU_LONG. Everybody is used to files and sockets being
int on UNIX, so why not use void pointers for Windows handles in this
special case if it avoids pulling gigabytes of code?

Regards
Stefan