January 2003 - Wine-Devel - list.winehq.org

Re: problem building tests with msvc6

by Dan Kegel

Francois Gouget wrote: > On Sun, 5 Jan 2003, Dan Kegel wrote: > [...] > >>To work around this, I removed ntdll from wineruntests_files >>(makes sense, since I'm building on windows Me, I suppose). > > > wineruntests does not compile. The reason is that the ntdll tests only > compile with the Wine headers while many other tests only compile with > the MSVC headers. (That's why a batch file is more practical for running > all the tests) > > So wineruntests should probably be removed. OK, but how do you compile all the tests then? wineruntests is the only project that invokes all the test subprojects. Once I removed ntdll, wineruntests compiled fine. Maybe you just meant "ntdll should be removed from wineruntests"? - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 6, 2003

Re: problem building tests with msvc6

by Francois Gouget

On Sun, 5 Jan 2003, Dan Kegel wrote: [...] > To work around this, I removed ntdll from wineruntests_files > (makes sense, since I'm building on windows Me, I suppose). wineruntests does not compile. The reason is that the ntdll tests only compile with the Wine headers while many other tests only compile with the MSVC headers. (That's why a batch file is more practical for running all the tests) So wineruntests should probably be removed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Jan. 6, 2003

Re: problem building tests with msvc6

by Dan Kegel

Found the missing step. I needed to do Build / Set Active Configuration / "wineruntests - Win32 MSVC Headers" before building. That lets me get to the next set of errors: c:\wtest\dlls\ntdll\tests\error.c(23) : fatal error C1083: Cannot open include file: 'ntstatus.h': No such file or directory c:\wtest\dlls\ntdll\tests\rtlbitmap.c(26) : fatal error C1083: Cannot open include file: 'winternl.h': No such file or directory This happens even after installing service pack 5 for msvc6. To work around this, I removed ntdll from wineruntests_files (makes sense, since I'm building on windows Me, I suppose). Haven't finished building yet, but thought I'd at least post these two workarounds. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 6, 2003

Re: #include directives

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > I don't really like headers that require you to #include other headers > first. So I like our winspool.h better than the Windows one. But should > we 'fix' it anyway? To avoid people writing tests that compile in Wine > but not on Windows for instance? ;-) Yes we should fix it, our headers should have the exact same dependency graph as the Windows ones. -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2003

Re: [RFC] __WINESRC__ & public headers

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > That's simply an optimization; maybe we could use an inline function > > instead. > > Ditto, right? Yes, it would just be cleaner without it but it won't break anything. > Right. But it seems to me the NONAMELESS* names are a bit overloaded: > on one hand, they are used to signal how some structures are defined, > on the other they describe the capabilities of the compiler. > > For example, what if one decides to use names on _all_ gcc versions? > This thing gets in the way, no? No, then you define NONAMELESS* yourself, that's what we do in Wine. > What about all the other things I've mentioned? Should we do anything > about them? And if yes, what? The extra flag values etc. should be removed, by fixing the code to not depend on extending the API that way. Of course that's easier said than done... -- Alexandre Julliard julliard(a)winehq.com

Jan. 6, 2003

Conformance tests status update

by Francois Gouget

Yesterday I compiled and uploaded new Windows binaries for the conformance tests. The new binaries contain a ton of fixes, in particular for the following tests but there are more: kernel/alloc kernel/format_msg kernel/path kernel/process msvcrt/scanf netapi32/access netapi32/apibuf netapi32/wksta You can find them at the following URL: http://fgouget.free.fr/wine/tests-en.shtml That page will also tell you when the Windows binaries were last updated. However now I need *help* to fix the following test failures. I.e these tests fail and I don't know how to fix them so a patch, or hints as to what needs to be done would be greatly appreciated: (well, the alternative is that I could also just remove them) * kernel32/alloc On Win9x fails with: alloc.c:208: Test failed: GlobalReAlloc failed to convert FIXED to MOVEABLE: error=87 alloc.c:213: Test failed: Converting from FIXED to MOVEABLE didn't REALLY work alloc.c:238: Test failed: Discarded memory we shouldn't have alloc.c:239: Test failed: GlobalUnlock Failed. * kernel32/file On Win9x fails with: file.c:609: Test failed: WriteFile error 183 file.c:610: Test failed: expected number of bytes written 0 file.c:611:Current offset = 0100 file.c:612: Test failed: expected file offset 21 file.c:617: Test failed: WriteFile error 87 file.c:618: Test failed: expected number of bytes written 0 file.c:620: Test failed: expected file offset 517 file.c:634: Test failed: ReadFile error 0 file.c:635: Test failed: expected number of bytes read 0 file.c:636:Current offset = 0000 file.c:637: Test failed: expected file offset 21 file.c:639: Test failed: pattern match failed * kernel32/locale Fails on Win98 with: locale.c:499: Test failed: GetDateFormat check DATE_YEARMONTH with null format expected ERROR_INVALID_FLAGS got return of '10' and error of '0' * netapi32/access Fails on NT4: access.c:77: Test failed: NetUserGetInfo: rc=2221 then crashes And on Win 2000/XP with: access.c:95: Test failed: Bad Network Path * user32/sysparams Messes up the user's environment on Win9x and has lots of failures. * user32/win Crashes on Win9x when calling SetParent(desktop, hwndMain) There are more tests that fail and I would certainly appreciate help with these too (would free me lots of time to do other things on Wine). Otherwise I will have a crack at them and see what I can do. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Jan. 5, 2003

Re: [RFC] __WINESRC__ & public headers

by Dimitrie O. Paun

On January 5, 2003 07:39 pm, Alexandre Julliard wrote: > > For example, what if one decides to use names on _all_ gcc versions? > > This thing gets in the way, no? > > No, then you define NONAMELESS* yourself, that's what we do in Wine. OK, but my problem is that we defined them on the #ifdef __WINESRC__. Which means our code will fail with other headers (even though, granted the fix is trivial). But I'm thinking, wouldn't it better to explicitely define these in the files that need it? > The extra flag values etc. should be removed, by fixing the code to > not depend on extending the API that way. Of course that's easier said > than done... Yay! Can you please suggest a solution / comment on my comments :)? Here they are again: -- It seems to me we want to move these to a wine/multimedia.h header. include/mmddk.h:#ifdef __WINESRC__ include/mmddk.h-#define DRV_QUERYDSOUNDIFACE (DRV_RESERVED + 10) include/mmddk.h-#endif include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-/* this call (GetDriverFlags) is not documented, nor the flags returned. include/mmsystem.h- * here are Wine only definitions include/mmsystem.h- */ include/mmsystem.h-#define WINE_GDF_EXIST 0x80000000 include/mmsystem.h-#define WINE_GDF_16BIT 0x10000000 include/mmsystem.h-#endif include/mmsystem.h:#ifdef __WINESRC__ include/mmsystem.h-#define WAVE_DIRECTSOUND 0x0080 include/mmsystem.h-#endif -- ? include/rpcproxy.h:#if defined(__WINESRC__) && defined(__WINE_WINE_OBJ_OLEAUT_H) include/rpcproxy.h-/* see http://msdn.microsoft.com/library/en-us/dnmsj99/html/com0199.asp?frame=true */ include/rpcproxy.h- include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateProxyFromTypeInfo( LPTYPEINFO pTypeInfo, LPUNKNOWN pUnkOuter, REFIID riid, include/rpcproxy.h- LPRPCPROXYBUFFER *ppProxy, LPVOID *ppv ); include/rpcproxy.h-RPCRTAPI HRESULT RPC_ENTRY include/rpcproxy.h- CreateStubFromTypeInfo( LPTYPEINFO pTypeInfo, REFIID riid, LPUNKNOWN pUnkServer, include/rpcproxy.h- LPRPCSTUBBUFFER *ppStub ); include/rpcproxy.h- include/rpcproxy.h-#endif -- Seems like it wants moving to a wine/base.h include/winbase.h:#ifdef __WINESRC__ include/winbase.h-#define CRITICAL_SECTION_INIT(name) { (void *)(__FILE__ ": " name), -1, 0, 0, 0, 0 } include/winbase.h-#endif -- These want moving to a wine-private header (wine/base.h?) include/winnt.h:#ifdef __WINESRC__ include/winnt.h-#define MEM_SYSTEM 0x80000000 include/winnt.h-#endif include/winnt.h:#ifdef __WINESRC__ include/winnt.h- include/winnt.h-/* Macros to retrieve the current context */ include/winnt.h- include/winnt.h-#ifdef __i386__ include/winnt.h- include/winnt.h-#define _DEFINE_REGS_ENTRYPOINT( name, fn, args ) \ include/winnt.h- __ASM_GLOBAL_FUNC( name, \ include/winnt.h- "call " __ASM_NAME("__wine_call_from_32_regs") "\n\t" \ include/winnt.h- ".long " __ASM_NAME(#fn) "\n\t" \ include/winnt.h- ".byte " #args ", " #args ) include/winsock.h:#ifdef __WINESRC__ include/winsock.h-#define FD_WINE_LISTENING 0x10000000 include/winsock.h-#define FD_WINE_NONBLOCKING 0x20000000 include/winsock.h-#define FD_WINE_CONNECTED 0x40000000 include/winsock.h-#define FD_WINE_RAW 0x80000000 include/winsock.h-#define FD_WINE_INTERNAL 0xFFFF0000 include/winsock.h-#endif -- What about these? include/wownt32.h:#ifdef __WINESRC__ include/wownt32.h-/* under Wine use the kernel functions directly so we don't have to import wow32 */ include/wownt32.h-HANDLE WINAPI K32WOWHandle32(WORD,WOW_HANDLE_TYPE); include/wownt32.h-WORD WINAPI K32WOWHandle16(HANDLE,WOW_HANDLE_TYPE); include/wownt32.h-#define WOWHandle32 K32WOWHandle32 include/wownt32.h-#define WOWHandle16 K32WOWHandle16 include/wownt32.h-#endif -- Dimi.

Jan. 5, 2003

ole db conformance tests

by Dan Kegel

Say, how close are these kinds of things to being able to run under wine? http://msdn.microsoft.com/library/en-us/oledb/htm/testtoolsov.asp - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 5, 2003

Re: [RFC] __WINESRC__ & public headers

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- Why do we need this undef? > include/objidl.h:#ifdef __WINESRC__ > include/objidl.h-#undef GetObject > include/objidl.h-#endif Because GetObject is a WINELIB_NAME_AW #define, and these cause a (deliberate) syntax error when building Wine. > -- Why are these Wine specific? > include/winbase.h:#ifdef __WINESRC__ > include/winbase.h-#define GetCurrentProcess() ((HANDLE)0xffffffff) > include/winbase.h-#define GetCurrentThread() ((HANDLE)0xfffffffe) > include/winbase.h-#endif That's simply an optimization; maybe we could use an inline function instead. > -- This one's a bugger. It make no sense to define these things conditionally on the > -- version of the compiler. One's code is written one way or another. > -- I suggest we remove these completely, and we defined the NONAMELESS* explicitly > -- in the files that need them. The idea is that you can then use the NONAMELESS defines to write more portable code, without having to duplicate the compiler checks. So the user's code can do something like: #include <winnt.h> #ifdef NONAMELESSUNION #define U(x) u.x #else #define U(x) x #endif -- Alexandre Julliard julliard(a)winehq.com

Jan. 5, 2003

Re: #include directives

by Dimitrie O. Paun

On January 5, 2003 05:27 pm, Francois Gouget wrote: > This means you can write a C file that just contains '#include > <winspool.h>' and it will work. But that would fail on Windows because > in the Windows sdk 'winspool.h' contains none of these #include > directives. I think we should not include more than the Windows headers. This way our sources will be compatible with other headers as well, such as w32api, or the MS ones (if and when we'll try to compile some of our stuff on Windows). -- Dimi.

Jan. 5, 2003