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

More On Solaris ADDRESS_SPACE_LIMIT

by Robert Lunnon

In dlls/ntdlls/virtual.c around line 1033 in NtAllocateVirtualMemory: NTSTATUS res=anon_mmap_aligned( &base, size,VIRTUAL_GetUnixProt( vprot ), 0 ); if (res) return res; Why is mmap used here rather than just a malloc/calloc to the OS ? If I can convert this call to a calloc then the ADDRESS_SPACE_LIMIT test will pass on Solaris. Can someone give me some insight here ? Bob

Jan. 5, 2003

Re: console handling

by Eric Pouech

Dimitrie O. Paun wrote: > On January 4, 2003 04:32 pm, Eric Pouech wrote: > >>this patch fixes a couple of issues in the console handling (but >>shouldn't help Lionel & Sylvain with the issues they reported on wd) > > > Hi Eric, > > Do you have any plans to reorganize wineconsole a bit so that you don't > need allocate a bitmap as big as the entire buffer, but rather one as > big as the displayed screen only? This way we can have 3000-5000 line > scroll buffers (as I have in my konsole, rxvt, xterm, etc.) > that's somewhere way deep in my todo list... as of today you can use the (n)curses backend that does what you need (this means, for the debugger, to start it before a crash occurs) A+ -- Eric Pouech

Jan. 5, 2003

Re: Windows XP conformance test update 1/5

by Marcus Meissner

> oleaut32/safearray reports 8 failures but the page only shows 4 failures. Simple, I did update these tests after your last run. > C:\winetests>oleaut32_test.exe safearray > safearray.c:137: Test failed: SAC(20,1,[1,0]), result 8, expected 0 > safearray.c:143: Test failed: SAGE for vt 20 returned elemsize 8 instead of > expected 0 > safearray.c:159: Test failed: copy of SAC(20,1,[1,0]), result 8, expected 0 > safearray.c:162: Test failed: SAGE for vt 20 returned elemsize 8 instead of > expected 0 > safearray.c:137: Test failed: SAC(21,1,[1,0]), result 8, expected 0 > safearray.c:143: Test failed: SAGE for vt 21 returned elemsize 8 instead of > expected 0 > safearray.c:159: Test failed: copy of SAC(21,1,[1,0]), result 8, expected 0 > safearray.c:162: Test failed: SAGE for vt 21 returned elemsize 8 instead of > expected 0 > safearray: 958 tests executed, 0 marked as todo, 8 failures. But these are still the same failures, just twice now. Ciao, Marcus

Jan. 5, 2003

Re: RESENT: running confirmance tests, question

by Sylvain Petreolle

Francois, Thanks. All tests runned sucessfully and match the test page but netapi32 access. I know its marked as invalid test for XP, but it currently crashes. > I have just uploaded a new version of the test binaries to the above > location. Before that version the binaries contained lots of patches > that were not yet in CVS because I compiled them from my standard > Wine > tree. Now I am using a separate Wine tree so the binaries are > compiled > from a clean CVS tree. Also, now the page will tell you when the > winetests.zip file has last been updated. Currrently it reads: > > winetests.zip -- Sunday, 05-Jan-2003 04:32:51 MET -- 1.1M ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 5, 2003

Re: Removing (HANDLE)NULL casts (2)

by Francois Gouget

On Sun, 5 Jan 2003, Dimitrie O. Paun wrote: > On January 4, 2003 10:28 pm, Francois Gouget wrote: > > A few handle types escaped the script the first time around. So here is > > an updated version that will catch them. The updated version will also > > catch casts of NULL to LP{C,W,wC}STR and LPVOID. > > Why not just use 0 instead of NULL? Does it make any difference? For the C/C++ compilers it does not make a difference, but to me it does (maybe because I've used languages with stronger typing than C a lot). For me 0 is an integer and thus it is wrong to assign it to a pointer. The compiler agrees with me for all non-zero integers but makes an exception for 0; 'for convenience's sake', or perhaps for historical reasons. NULL is a pointer so that's the right thing to use to initialize a pointer. Similarly I prefer '\0' to 0 even if the compiler does not care. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Jan. 5, 2003

Re: Windows XP conformance test update 1/5

by Francois Gouget

On Sun, 5 Jan 2003, David Miller wrote: > Not much to report this time but there is something... strange. > > kernel32/drive reported the following. [...] > Previously this test passed, so I rebooted to see if the problem went > away. After reboot the kernel32 test clamed not to be a valid win32 > application. Turns out the size was 0 bytes. I re-extracted the zip file > and ran kernel32/drive again. This time is passed. I have not seen the > failure before but I did run into the "not a valid win32 application" > message before, and the file size was 0 bytes. Yes, that's pretty strange. I don't see what could cause this problem. > oleaut32/safearray reports 8 failures but the page only shows 4 failures. [...] > Also I don't see urlmon/generated on the status page at all. It passed. > > C:\winetests>urlmon_test.exe generated > generated: 4 tests executed, 0 marked as todo, 0 failures. Thanks, I updated the page. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Jan. 5, 2003

[RFC] __WINESRC__ & public headers

by Dimitrie O. Paun

Folks, With the current efforts to cleanup our headers on __WINESRC__s, I realized we are actually quite close to 'clean' header, something that should allow us to compile Wine with other headers, such as those from the w32api package that's part of mingw. This is a worthy goal as the compiler will flag problems in our headers (by complaining about different prototypes), as well as in the w32api headers. A win-win situation for the free software world. What do we need to do before we can try this stunt? Well, we need to cleanup our headers of __WINESRC__ tests that modifies them in a incompatible way. Let me be more explicit: 1. Tests that do not allow a file to be included in Wine are OK. If we use other headers, those file will simply be ignored, as they would not be used by Wine. 2. Tests to keep certain things undefined/undeclared in Wine are OK. Such tests simply make the header files a subset of the standard one, and the stuff that's not defined is not used, so all is good. 3. Tests that _add_ stuff to headers are BAD. It's clear that such things will not be present in other headers, and things will not work out as nicely. 4. Tests that modify the behavior of the headers are BAD. Same explanation as above. I will list below things that fall under 3, and 4. Ideas on how to deal with them are highly appreciated. -- 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 -- Why do we need this undef? include/objidl.h:#ifdef __WINESRC__ include/objidl.h-#undef GetObject include/objidl.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 -- 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 -- 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. include/winnt.h:#ifdef __WINESRC__ include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# define NONAMELESSUNION include/winnt.h-#else include/winnt.h-/* Anonymous struct support starts with gcc 2.96 or gcc/g++ 3.x */ include/winnt.h-# if !defined(NONAMELESSSTRUCT) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && (defined(__cplusplu s) || (__GNUC_MINOR__ < 96))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSSTRUCT include/winnt.h-# endif include/winnt.h-/* Anonymous unions support starts with gcc 2.96/g++ 2.95 */ include/winnt.h-# if !defined(NONAMELESSUNION) && (defined(__GNUC__) && ((__GNUC__ < 2) || ((__GNUC__ == 2) && ((__GNUC_MINOR__ < 9 5) || ((__GNUC_MINOR__ == 95) && !defined(__cplusplus)))))) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) include/winnt.h-# define NONAMELESSUNION -- 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 -- There are also some in include/winternl.h, but those can wait for now :) -- Dimi.

Jan. 5, 2003

Re: interesting crash in msvc6.0 setup

by Dan Kegel

Uwe Bonnes wrote: >>>>>>"Dan" == Dan Kegel <dank(a)kegel.com> writes: > Dan> Whenever it crashes in winnt/xp, it leaves one or more windowless > Dan> wcmd's running the following script: > > Dan> :Repeat del "E:\vs60wiz.exe" if exist "E:\vs60wiz.exe" goto Repeat > Dan> del "C:\WINDOWS\DEL4056.BAT" > > Dan> in a loop, chewing up huge amounts of CPU time. > > Try my patch > Cc: wine-patches(a)winehq.com > Subject: Re: [RESENT] Batch support for CreateProcess (2 of 3) Hey, that seems to get rid of the leftover wcmd's! - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 5, 2003

Re: Removing (HANDLE)NULL casts (2)

by Dimitrie O. Paun

On January 5, 2003 03:35 am, Francois Gouget wrote: > For me 0 is an integer and thus it is wrong to assign it to a pointer. > The compiler agrees with me for all non-zero integers but makes an > exception for 0; 'for convenience's sake', or perhaps for historical > reasons. NULL is a pointer so that's the right thing to use to > initialize a pointer. I used to think this way years ago, but I have relaxed my position. Zero is fundamentally built into the language so deep, that playing with tricks like NULL and '\0' seem like a waste of time. Moreover, I seem to remember some arguments sometime ago about 0 being actually preferred to NULL, at least in C++. Bottom like, it seems to me there is little point in having a different names for the same thing: zero. In fact, I'd say it's bad from a theoretical standpoint (and no, I don't much care for the stronger typing argument, it buys you nothing in this case). But if it makes you happy... :) -- Dimi.

Jan. 5, 2003

Handle table? win2k internals doc?

by Dan Kegel

On the off chance that MSVC6's installer is cheating and reading the handle table entries directly by dereferencing file handles, I started wondering whether wine needed to make all its handles look a bit more like windows handles. What's the best source of info about how Windows formats its handles and arranges its handle table? "Inside Microsoft Windows 2000" by David A. Solomon and Mark Russinovich http://www.sysinternals.com/insidew2k.shtml seems like a good source of info. Is it worth the $35 for a budding wine hacker? The Windows 2000 DDK is probably a good source, http://www.microsoft.com/ddk/W2kDDK.asp but for some reason, http://download.microsoft.com/download/win2000ddk/install/combined-8-00/nt5… is a broken link. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 5, 2003