diff mbox

[9/9] w32: Replace Windows specific data types in common header files

Message ID 1393174935-11750-10-git-send-email-sw@weilnetz.de
State Superseded
Headers show

Commit Message

Stefan Weil Feb. 23, 2014, 5:02 p.m. UTC
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>
---
 block/raw-aio.h               |    4 ++--
 cpus.c                        |    4 +++-
 include/qemu/event_notifier.h |    8 ++------
 include/qemu/main-loop.h      |    4 ++--
 include/qemu/thread-win32.h   |   29 ++++++++++++++++++++---------
 include/qom/cpu.h             |    2 +-
 ui/vnc-enc-tight.c            |    5 -----
 util/event_notifier-win32.c   |    1 +
 util/qemu-thread-win32.c      |   17 +++++++++--------
 9 files changed, 40 insertions(+), 34 deletions(-)

Comments

Kevin Wolf Feb. 24, 2014, 10:17 a.m. UTC | #1
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
Andreas Färber Feb. 24, 2014, 1:07 p.m. UTC | #2
Am 23.02.2014 18:02, schrieb Stefan Weil:
> 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>
[...]
> diff --git a/include/qom/cpu.h b/include/qom/cpu.h
> index 367eda1..6ea48c4 100644
> --- a/include/qom/cpu.h
> +++ b/include/qom/cpu.h

First of all, why was I not CC'ed on this change?
File is listed under "CPU" subsystem in MAINTAINERS.

Patches not getting sufficient review is one risk, causing merge
conflicts another. People should be aware of changes you make in their
files, even if "just" Windows-related.

> @@ -170,7 +170,7 @@ struct CPUState {
>  
>      struct QemuThread *thread;
>  #ifdef _WIN32
> -    HANDLE hThread;
> +    void *hThread;
>  #endif
>      int thread_id;
>      uint32_t host_tid;

I had moved the field unchanged from another header, I believe. I don't
think this is a good change (assuming the Windows API is still using
this type and not void*), especially since it's #ifdef'ed anyway.

And I don't understand why reducing the number of files dependent on
windows.h is a good thing either. Your cover letter does not explain.
We've not been trying to reduce dependencies on glib either, nor is
there precedence for replacing other pointer types elsewhere (e.g.
qemu_irq). Wherever possible, we've been using the most precise pointer
type to let the compiler or static analysis tools help us catch mismatches.

Is all this just to speed up rebuilds after MinGW updates?

Regards,
Andreas
Peter Maydell Feb. 24, 2014, 1:24 p.m. UTC | #3
On 24 February 2014 10:17, Kevin Wolf <kwolf@redhat.com> wrote:
> Not sure if I understand the problem. Why is it bad to depend on
> windows.h?

It drags in an enormous pile of stuff that grabs a lot of
namespace that it would be nice to not have to avoid by
fiddling with QEMU code. (For instance the Spitz board
clashes with a MOD_SHIFT #define.)

thanks
-- PMM
Kevin Wolf Feb. 24, 2014, 1:44 p.m. UTC | #4
Am 24.02.2014 um 14:24 hat Peter Maydell geschrieben:
> On 24 February 2014 10:17, Kevin Wolf <kwolf@redhat.com> wrote:
> > Not sure if I understand the problem. Why is it bad to depend on
> > windows.h?
> 
> It drags in an enormous pile of stuff that grabs a lot of
> namespace that it would be nice to not have to avoid by
> fiddling with QEMU code. (For instance the Spitz board
> clashes with a MOD_SHIFT #define.)

Right, I can understand that you want to avoid device models or other
random source files to have a polluted namespace.

The file that I'm CCed for, however, is block/raw-aio.h, which is only
included in the raw-posix block driver (there it's #ifdef'ed away) and
in the raw-win32 one (which has an obvious dependency on Windows
headers).

Can't see how dropping the type safety improves anything there. I might
see the improvement of not polluting the namespace in other places, but
am still not convinced that using void* instead of specific types is a
good idea.

Kevin
Peter Maydell Feb. 24, 2014, 1:51 p.m. UTC | #5
On 24 February 2014 13:44, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 24.02.2014 um 14:24 hat Peter Maydell geschrieben:
>> On 24 February 2014 10:17, Kevin Wolf <kwolf@redhat.com> wrote:
>> > Not sure if I understand the problem. Why is it bad to depend on
>> > windows.h?
>>
>> It drags in an enormous pile of stuff that grabs a lot of
>> namespace that it would be nice to not have to avoid by
>> fiddling with QEMU code. (For instance the Spitz board
>> clashes with a MOD_SHIFT #define.)
>
> Right, I can understand that you want to avoid device models or other
> random source files to have a polluted namespace.
>
> The file that I'm CCed for, however, is block/raw-aio.h, which is only
> included in the raw-posix block driver (there it's #ifdef'ed away) and
> in the raw-win32 one (which has an obvious dependency on Windows
> headers).

Yes, there doesn't seem too much point in that particular case.

> Can't see how dropping the type safety improves anything there. I might
> see the improvement of not polluting the namespace in other places, but
> am still not convinced that using void* instead of specific types is a
> good idea.

We might be able to abstract away the differences into a
QEMU-defined type in some cases rather than using void*.
(I haven't looked to see if this is feasible.)

thanks
-- PMM
Stefan Weil Feb. 24, 2014, 11:07 p.m. UTC | #6
Am 24.02.2014 14:07, schrieb Andreas Färber:
> Am 23.02.2014 18:02, schrieb Stefan Weil:
>> These header files are used by most QEMU source files. If they
>> depend on windows.h, all those source files do so, too.
>>
[...]
> 
> First of all, why was I not CC'ed on this change?
> File is listed under "CPU" subsystem in MAINTAINERS.
> 
> Patches not getting sufficient review is one risk, causing merge
> conflicts another. People should be aware of changes you make in their
> files, even if "just" Windows-related.

Sorry, I simply missed your name in the lengthy output from
get_maintainer.pl.

> I had moved the field unchanged from another header, I believe. I don't
> think this is a good change (assuming the Windows API is still using
> this type and not void*), especially since it's #ifdef'ed anyway.

Please see my mail to Kevin (which will be sent in a moment).

> 
> And I don't understand why reducing the number of files dependent on
> windows.h is a good thing either. Your cover letter does not explain.
> We've not been trying to reduce dependencies on glib either, nor is
> there precedence for replacing other pointer types elsewhere (e.g.
> qemu_irq). Wherever possible, we've been using the most precise pointer
> type to let the compiler or static analysis tools help us catch mismatches.

See also my other mail.

> 
> Is all this just to speed up rebuilds after MinGW updates?

The .d files don't track dependencies to system include files. A MinGW
update won't trigger new compilations, so this is not a reason at all.

Regards
Stefan
Stefan Weil Feb. 24, 2014, 11:12 p.m. UTC | #7
Am 24.02.2014 14:51, schrieb Peter Maydell:
> On 24 February 2014 13:44, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 24.02.2014 um 14:24 hat Peter Maydell geschrieben:
>>> On 24 February 2014 10:17, Kevin Wolf <kwolf@redhat.com> wrote:
>>>> Not sure if I understand the problem. Why is it bad to depend on
>>>> windows.h?
>>>
>>> It drags in an enormous pile of stuff that grabs a lot of
>>> namespace that it would be nice to not have to avoid by
>>> fiddling with QEMU code. (For instance the Spitz board
>>> clashes with a MOD_SHIFT #define.)
>>
>> Right, I can understand that you want to avoid device models or other
>> random source files to have a polluted namespace.
>>
>> The file that I'm CCed for, however, is block/raw-aio.h, which is only
>> included in the raw-posix block driver (there it's #ifdef'ed away) and
>> in the raw-win32 one (which has an obvious dependency on Windows
>> headers).
> 
> Yes, there doesn't seem too much point in that particular case.
> 
>> Can't see how dropping the type safety improves anything there. I might
>> see the improvement of not polluting the namespace in other places, but
>> am still not convinced that using void* instead of specific types is a
>> good idea.
> 
> We might be able to abstract away the differences into a
> QEMU-defined type in some cases rather than using void*.
> (I haven't looked to see if this is feasible.)
> 
> thanks
> -- PMM
> 

Kevin, I'll have a look on that special case in v2 of my patch series.
I'll say more on type safety and Peter's suggestion in another mail.

Stefan
Stefan Weil Feb. 24, 2014, 11:17 p.m. UTC | #8
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
Andreas Färber Feb. 25, 2014, 8:37 a.m. UTC | #9
Am 25.02.2014 00:07, schrieb Stefan Weil:
> Am 24.02.2014 14:07, schrieb Andreas Färber:
>> Am 23.02.2014 18:02, schrieb Stefan Weil:
>>> These header files are used by most QEMU source files. If they
>>> depend on windows.h, all those source files do so, too.
>>>
> [...]
>>
>> First of all, why was I not CC'ed on this change?
>> File is listed under "CPU" subsystem in MAINTAINERS.
>>
>> Patches not getting sufficient review is one risk, causing merge
>> conflicts another. People should be aware of changes you make in their
>> files, even if "just" Windows-related.
> 
> Sorry, I simply missed your name in the lengthy output from
> get_maintainer.pl.
> 
>> I had moved the field unchanged from another header, I believe. I don't
>> think this is a good change (assuming the Windows API is still using
>> this type and not void*), especially since it's #ifdef'ed anyway.
> 
> Please see my mail to Kevin (which will be sent in a moment).

My opinion still stands. You can easily add "typedef void * HANDLE;" to
qemu-typedefs.h or osdep.h to retain telling type names, in this case
explaining why the variable is called "hThread" - h for "HANDLE".

Regards,
Andreas
Stefan Weil Feb. 26, 2014, 6:14 a.m. UTC | #10
Am 25.02.2014 09:37, schrieb Andreas Färber:
> Am 25.02.2014 00:07, schrieb Stefan Weil:
[...]
>>> I had moved the field unchanged from another header, I believe. I don't
>>> think this is a good change (assuming the Windows API is still using
>>> this type and not void*), especially since it's #ifdef'ed anyway.
>> Please see my mail to Kevin (which will be sent in a moment).
> My opinion still stands. You can easily add "typedef void * HANDLE;" to
> qemu-typedefs.h or osdep.h to retain telling type names, in this case
> explaining why the variable is called "hThread" - h for "HANDLE".
>
> Regards,
> Andreas

I'm not sure whether I fully understand what you say.

Yes, adding a typedef for HANDLE or LONG is easy. I decided against that
solution because it is nearly impossible to avoid conflicts with the
typedefs pulled by windows.h. The QEMU typedef for HANDLE would have to
be protected by conditional compilation, and windows.h would have to be
included before that code. I am afraid that there will be lots of build
breakages in the future simply because people usually don't test with
MinGW and we have no simple rules how include statements should be ordered.

Stefan
Stefan Hajnoczi Feb. 27, 2014, 3:45 p.m. UTC | #11
On Sun, Feb 23, 2014 at 06:02:15PM +0100, Stefan Weil wrote:
> 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.

Can you use a typedef?  When I read code that uses HANDLE, I immediately
know this is Windows and which sorts of APIs can accept this HANDLE
value.

Now when I see void * it's just an opaque C type.  We've lost
information :(.

/* Since windows.h drags in a lot of headers, we define equivalent
 * typedefs for some core Win32 types.
 */
typedef void *QEMU_WIN32_HANDLE; /* is there a more concise name? */
...

Stefan
diff mbox

Patch

diff --git a/block/raw-aio.h b/block/raw-aio.h
index 7ad0a8a..fd3f3bf 100644
--- a/block/raw-aio.h
+++ b/block/raw-aio.h
@@ -42,9 +42,9 @@  BlockDriverAIOCB *laio_submit(BlockDriverState *bs, void *aio_ctx, int fd,
 #ifdef _WIN32
 typedef struct QEMUWin32AIOState QEMUWin32AIOState;
 QEMUWin32AIOState *win32_aio_init(void);
-int win32_aio_attach(QEMUWin32AIOState *aio, HANDLE hfile);
+int win32_aio_attach(QEMUWin32AIOState *aio, void *hfile);
 BlockDriverAIOCB *win32_aio_submit(BlockDriverState *bs,
-        QEMUWin32AIOState *aio, HANDLE hfile,
+        QEMUWin32AIOState *aio, void *hfile,
         int64_t sector_num, QEMUIOVector *qiov, int nb_sectors,
         BlockDriverCompletionFunc *cb, void *opaque, int type);
 #endif
diff --git a/cpus.c b/cpus.c
index 945d85b..4e91e08 100644
--- a/cpus.c
+++ b/cpus.c
@@ -39,7 +39,9 @@ 
 #include "qemu/bitmap.h"
 #include "qemu/seqlock.h"
 
-#ifndef _WIN32
+#ifdef _WIN32
+#include "sysemu/os-winapi.h" /* SuspendThread, ... */
+#else
 #include "qemu/compatfd.h"
 #endif
 
diff --git a/include/qemu/event_notifier.h b/include/qemu/event_notifier.h
index 1b75f29..222ef8c 100644
--- a/include/qemu/event_notifier.h
+++ b/include/qemu/event_notifier.h
@@ -15,13 +15,9 @@ 
 
 #include "qemu-common.h"
 
-#ifdef _WIN32
-#include "sysemu/os-winapi.h"
-#endif
-
 struct EventNotifier {
 #ifdef _WIN32
-    HANDLE event;
+    void *event;
 #else
     int rfd;
     int wfd;
@@ -40,7 +36,7 @@  int event_notifier_set_handler(EventNotifier *, EventNotifierHandler *);
 void event_notifier_init_fd(EventNotifier *, int fd);
 int event_notifier_get_fd(EventNotifier *);
 #else
-HANDLE event_notifier_get_handle(EventNotifier *);
+void *event_notifier_get_handle(EventNotifier *);
 #endif
 
 #endif
diff --git a/include/qemu/main-loop.h b/include/qemu/main-loop.h
index 6f0200a..68d2798 100644
--- a/include/qemu/main-loop.h
+++ b/include/qemu/main-loop.h
@@ -152,7 +152,7 @@  typedef void WaitObjectFunc(void *opaque);
  * @func: A function to be called when @handle is in a signaled state.
  * @opaque: A pointer-size value that is passed to @func.
  */
-int qemu_add_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque);
+int qemu_add_wait_object(void *handle, WaitObjectFunc *func, void *opaque);
 
 /**
  * qemu_del_wait_object: Unregister a callback for a Windows handle
@@ -163,7 +163,7 @@  int qemu_add_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque);
  * @func: The function that was passed to qemu_add_wait_object.
  * @opaque: A pointer-size value that was passed to qemu_add_wait_object.
  */
-void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque);
+void qemu_del_wait_object(void *handle, WaitObjectFunc *func, void *opaque);
 #endif
 
 /* async I/O support */
diff --git a/include/qemu/thread-win32.h b/include/qemu/thread-win32.h
index 127a7ba..d2ff862 100644
--- a/include/qemu/thread-win32.h
+++ b/include/qemu/thread-win32.h
@@ -1,24 +1,35 @@ 
 #ifndef __QEMU_THREAD_WIN32_H
 #define __QEMU_THREAD_WIN32_H 1
-#include "sysemu/os-winapi.h"
+
+/* QemuCriticalSection is a substitute for CRITICAL_SECTION and
+ * introduced here to avoid dependencies on windows.h. */
+
+typedef struct {
+    void *DebugInfo;
+    long LockCount;
+    long RecursionCount;
+    void *OwningThread;
+    void *LockSemaphore;
+    unsigned long *SpinCount;
+} QemuCriticalSection;
 
 struct QemuMutex {
-    CRITICAL_SECTION lock;
-    LONG owner;
+    QemuCriticalSection lock;
+    long owner;
 };
 
 struct QemuCond {
-    LONG waiters, target;
-    HANDLE sema;
-    HANDLE continue_event;
+    long waiters, target;
+    void *sema;
+    void *continue_event;
 };
 
 struct QemuSemaphore {
-    HANDLE sema;
+    void *sema;
 };
 
 struct QemuEvent {
-    HANDLE event;
+    void *event;
 };
 
 typedef struct QemuThreadData QemuThreadData;
@@ -28,6 +39,6 @@  struct QemuThread {
 };
 
 /* Only valid for joinable threads.  */
-HANDLE qemu_thread_get_handle(QemuThread *thread);
+void *qemu_thread_get_handle(QemuThread *thread);
 
 #endif
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 367eda1..6ea48c4 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -170,7 +170,7 @@  struct CPUState {
 
     struct QemuThread *thread;
 #ifdef _WIN32
-    HANDLE hThread;
+    void *hThread;
 #endif
     int thread_id;
     uint32_t host_tid;
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 92220e3..2e6fb88 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -27,11 +27,6 @@ 
  */
 
 #include "config-host.h"
-
-/* This needs to be before jpeglib.h line because of conflict with
-   INT32 definitions between jmorecfg.h (included by jpeglib.h) and
-   Win32 basetsd.h (included by windows.h). */
-#include "sysemu/os-winapi.h" /* TODO: workaround, remove */
 #include "qemu-common.h"
 
 #ifdef CONFIG_VNC_PNG
diff --git a/util/event_notifier-win32.c b/util/event_notifier-win32.c
index 6dbb530..bf39268 100644
--- a/util/event_notifier-win32.c
+++ b/util/event_notifier-win32.c
@@ -13,6 +13,7 @@ 
 #include "qemu-common.h"
 #include "qemu/event_notifier.h"
 #include "qemu/main-loop.h"
+#include "sysemu/os-winapi.h" /* CreateEvent, ... */
 
 int event_notifier_init(EventNotifier *e, int active)
 {
diff --git a/util/qemu-thread-win32.c b/util/qemu-thread-win32.c
index 27a5217..6d1f777 100644
--- a/util/qemu-thread-win32.c
+++ b/util/qemu-thread-win32.c
@@ -10,11 +10,10 @@ 
  * See the COPYING file in the top-level directory.
  *
  */
+
+#include "sysemu/os-winapi.h" /* LocalFree, ... */
 #include "qemu-common.h"
 #include "qemu/thread.h"
-#include <process.h>
-#include <assert.h>
-#include <limits.h>
 
 static void error_exit(int err, const char *msg)
 {
@@ -30,18 +29,20 @@  static void error_exit(int err, const char *msg)
 void qemu_mutex_init(QemuMutex *mutex)
 {
     mutex->owner = 0;
-    InitializeCriticalSection(&mutex->lock);
+    /* mutex->lock uses a data type which must fit CRITICAL_SECTION. */
+    g_assert(sizeof(mutex->lock) == sizeof(CRITICAL_SECTION));
+    InitializeCriticalSection((CRITICAL_SECTION *)&mutex->lock);
 }
 
 void qemu_mutex_destroy(QemuMutex *mutex)
 {
     assert(mutex->owner == 0);
-    DeleteCriticalSection(&mutex->lock);
+    DeleteCriticalSection((CRITICAL_SECTION *)&mutex->lock);
 }
 
 void qemu_mutex_lock(QemuMutex *mutex)
 {
-    EnterCriticalSection(&mutex->lock);
+    EnterCriticalSection((CRITICAL_SECTION *)&mutex->lock);
 
     /* Win32 CRITICAL_SECTIONs are recursive.  Assert that we're not
      * using them as such.
@@ -54,7 +55,7 @@  int qemu_mutex_trylock(QemuMutex *mutex)
 {
     int owned;
 
-    owned = TryEnterCriticalSection(&mutex->lock);
+    owned = TryEnterCriticalSection((CRITICAL_SECTION *)&mutex->lock);
     if (owned) {
         assert(mutex->owner == 0);
         mutex->owner = GetCurrentThreadId();
@@ -66,7 +67,7 @@  void qemu_mutex_unlock(QemuMutex *mutex)
 {
     assert(mutex->owner == GetCurrentThreadId());
     mutex->owner = 0;
-    LeaveCriticalSection(&mutex->lock);
+    LeaveCriticalSection((CRITICAL_SECTION *)&mutex->lock);
 }
 
 void qemu_cond_init(QemuCond *cond)