While looking at http://bugs.winehq.org/show_bug.cgi?id=1899 I noticed that dlls/msvcrt/tests/file.c didn't test O_APPEND, so I thought I'd try building that test standalone, running it under Windows, and adding the missing test logic.
(Rather than building under Windows, I used a shell script that invokes cl.exe -- see http://kegel.com/wine/cl-howto.html -- but that shouldn't matter here. Just to be clear about what version of cl I'm using, cl -? shows: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved I also have the Platform SDK installed, so I have MS's headers, e.g. /home/dank/.wine/drive_c/Program Files/MicrosoftSDK/include/WinNT.h and my INCLUDE environment variable is set to C:\Program Files\msvc2003\include;C:\Program Files\MicrosoftSDK\include This used to work fine.)
To compile a test standalone, one should be able to do e.g. cd dlls/msvcrt/tests cl -DSTANDALONE -D_X86_ -I../../../include file.c
The first problem I ran into is that some wine .h files use wine-specific processor defines, so compilation fails with e.g. ../../../include\basetsd.h(177) : fatal error C1189: #error : Unknown CPU architecture!
OK, I can live with one extra define, I guess, so I tried cl -DSTANDALONE -D_X86_ -D__i386__ -I../../../include file.c But that fails with the errors ../../../include\winnt.h(1680) : error C2054: expected '(' to follow 'inline' ../../../include\winnt.h(1681) : error C2085: 'NtCurrentTeb' : not in formal parameter list ... ../../../include\winbase.h(2271) : error C2054: expected '(' to follow 'inline'
Evidently cl doesn't like the inline functions in winnt.h and winbase.h.
Any suggestions? It seems a bit strange to be using wine's winnt.h when I have MS's headers, but I haven't tracked that down yet. Should Wine's headers build with cl?
Thanks, Dan
On 10/2/05, Dan Kegel daniel.r.kegel@gmail.com wrote:
To compile a test standalone, one should be able to do e.g. cd dlls/msvcrt/tests cl -DSTANDALONE -D_X86_ -I../../../include file.c
D'oh. No, it's not quite that simple to build standalone with cl; you have to avoid using wine's headers, like so: mkdir -p fauxinclude/wine ln -s ../../include/wine/test.h fauxinclude/wine cd dlls/msvcrt/tests cl -DSTANDALONE -D_X86_ -I../../../fauxinclude file.c And that works fine.
On Sun, 2005-10-02 at 10:08 -0700, Dan Kegel wrote:
D'oh. No, it's not quite that simple to build standalone with cl; you have to avoid using wine's headers
That doesn't seem right -- AFAIK, it should work with the Wine headers.
"Dan Kegel" daniel.r.kegel@gmail.com wrote:
../../../include\winbase.h(2271) : error C2054: expected '(' to follow 'inline'
Evidently cl doesn't like the inline functions in winnt.h and winbase.h.
Any suggestions? It seems a bit strange to be using wine's winnt.h when I have MS's headers, but I haven't tracked that down yet. Should Wine's headers build with cl?
You need one more define: -Dinline=__inline
And yes, I compile Wine tests (on which I'm working on time from time) with cl.exe under Windows using Wine headers.
On 10/2/05, Dmitry Timoshkov dmitry@baikal.ru wrote:
cl -DSTANDALONE -D_X86_ -D__i386__ -I../../../include file.c ../../../include\winbase.h(2271) : error C2054: expected '(' to follow 'inline'
You need one more define: -Dinline=__inline
Ah. Thanks. (I haven't tried it yet, but I believe you.)
And yes, I compile Wine tests (on which I'm working on time from time) with cl.exe under Windows using Wine headers.
On Mon, 2005-10-03 at 09:29 +0900, Dmitry Timoshkov wrote:
You need one more define: -Dinline=__inline
This is non-obvious. Can't we detect MSVC (say in windef.h) and define inline and the other defines that we need?
It seems rather silly to have to specify them on the command line.
On 10/2/05, Dimi Paun dimi@lattica.com wrote:
You need one more define: -Dinline=__inline
This is non-obvious. Can't we detect MSVC (say in windef.h) and define inline and the other defines that we need?
I'd love that. It should sense _X86_ and set __i386__ if found, too.
On Sun, 2005-10-02 at 22:19 -0700, Dan Kegel wrote:
I'd love that. It should sense _X86_ and set __i386__ if found, too.
Does this work?
Index: include/windef.h =================================================================== RCS file: /var/cvs/wine/include/windef.h,v retrieving revision 1.99 diff -u -p -r1.99 windef.h --- include/windef.h 22 Sep 2005 10:58:04 -0000 1.99 +++ include/windef.h 3 Oct 2005 05:26:26 -0000 @@ -41,6 +41,10 @@ extern "C" { # define _X86_ #endif
+#if defined(_X86_) && !defined(__i386__) +# define __i386__ +#endif + #ifdef __x86_64__ #define _WIN64 #endif @@ -126,6 +130,10 @@ extern "C" { # endif #endif
+#ifdef _MSC_VER +# define inline __inline +#endif + #define CALLBACK __stdcall #define WINAPI __stdcall #define APIPRIVATE __stdcall
Yes! It made my original, simple command work. I hope this makes it into CVS soon.
On 10/2/05, Dimi Paun dimi@lattica.com wrote:
On Sun, 2005-10-02 at 22:19 -0700, Dan Kegel wrote:
I'd love that. It should sense _X86_ and set __i386__ if found, too.
Does this work?
Index: include/windef.h
RCS file: /var/cvs/wine/include/windef.h,v retrieving revision 1.99 diff -u -p -r1.99 windef.h --- include/windef.h 22 Sep 2005 10:58:04 -0000 1.99 +++ include/windef.h 3 Oct 2005 05:26:26 -0000 @@ -41,6 +41,10 @@ extern "C" { # define _X86_ #endif
+#if defined(_X86_) && !defined(__i386__) +# define __i386__ +#endif
#ifdef __x86_64__ #define _WIN64 #endif @@ -126,6 +130,10 @@ extern "C" { # endif #endif
+#ifdef _MSC_VER +# define inline __inline +#endif
#define CALLBACK __stdcall #define WINAPI __stdcall #define APIPRIVATE __stdcall
-- Dimi Paun dimi@lattica.com Lattica, Inc.
-
Dan Kegel -
Dimi Paun -
Dmitry Timoshkov