- wine-devel - winehq.org

Conformance tests --MSVC Headers 2 of 2
by Tom 10 Dec '02

10 Dec '02

Build Log --------------------Configuration: ntdll_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_NTDLL_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\ntdll\tests\error.c" "C:\include\wine\dlls\ntdll\tests\rtlbitmap.c" "C:\include\wine\dlls\ntdll\tests\rtlstr.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" with contents [ /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/ntdll_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/ntdll_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\error.obj .\Output\Win32_MSVC_Headers\generated.obj .\Output\Win32_MSVC_Headers\rtlbitmap.obj .\Output\Win32_MSVC_Headers\rtlstr.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" Output Window Build Log --------------------Configuration: oleaut32_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2E.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_OLEAUT32_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\oleaut32\tests\vartest.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2E.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2F.tmp" with contents [ oleaut32.lib /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/oleaut32_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/oleaut32_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\vartest.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2F.tmp" Output Window Build Log --------------------Configuration: ntdll_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_NTDLL_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\ntdll\tests\error.c" "C:\include\wine\dlls\ntdll\tests\rtlbitmap.c" "C:\include\wine\dlls\ntdll\tests\rtlstr.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" with contents [ /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/ntdll_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/ntdll_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\error.obj .\Output\Win32_MSVC_Headers\generated.obj .\Output\Win32_MSVC_Headers\rtlbitmap.obj .\Output\Win32_MSVC_Headers\rtlstr.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" Output Window

1 0

what to do with include/wine/obj_base.h?
by Ove Kaaven 10 Dec '02

10 Dec '02

I've submitted a patch to move the API prototypes out of obj_base.h, and I'd now be ready to submit unknwn.idl and unknwn.h, which would also supersede the interfaces defined in there, but I'm unsure about what to do with the remainder of it, namely the ICOM_* macros in there. Note that there's a shortcoming of those macros, they don't handle array arguments. Such arguments are binary-compatible with pointer arguments though, so it's not a serious shortcoming for Wine and widl (which could easily convert array args in IDL to pointer args in C), but it's a little ugly and may have source-compatibility issues if widl is used by Winelib code that implements interfaces with such method args. There are standard COM interfaces with this problem too, e.g. IPropertyStorage, but since such interfaces are implemented by Wine and not by app code, there's unlikely to be source-compatibility issues there. So the options include 1) keep using obj_base.h as it is, let widl use those macros as is (and convert array args to pointer args), include it into unknwn.h 2) move ICOM macros to include/objbase.h, and dispose of obj_base.h 3) make widl use the MS-style macros in objbase.h (but I'm not sure what to do about ICOM_MSVTABLE_COMPAT and ICOM_USE_COM_INTERFACE_ATTRIBUTE in this case) 4) make widl not use macros at all, but emit full C and C++ definitions directly (this is what midl.exe does, it seems) 5) make widl support any of the above with a command-line option, so that Wine headers uses 1 or 2, while Winelib apps get to use 3 or 4. 6) redesign the ICOM macros (but I doubt anyone's going to volunteer for that unless tied to a chair supervised by an ancient master of torture with a cat-o'-nine-tails in his toolbox, there's too much code to change)

4 5

Re: wine/dlls/winsock/socket.c: Force SO_REUSEADDR ...
by Martin Wilck 10 Dec '02

10 Dec '02

Hi, judging from the Traces these programs are rare examples of lame network programming. You find series of things that shouldn't be done, such as bind()ing in a client application, not closing down a socket cleanly but expecting the next bind() to the same address to succeed, polling the socket with ioctl (FIONREAD), etc. I am really asking myself if it's right to hack wine to violate the specs just for the sake of so poorly programmed applications. I'd be grateful for advice by experienced Wine hackers here. Perhaps we need to introduce Windows version-dependent behavior. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller 10 Dec '02

10 Dec '02

I could probably run some tests under WinXP. I just need to compile the tests on windows, execute them, and post output to wine-devel? Is this correct?

7 12

Re: strcat+strcat+strcat == baaad"
by Jeff Smith 10 Dec '02

10 Dec '02

You caught me... I thought something like this existed. I would say that by default, Auto should be 0. I think this would be best for the average user. They are probably even less likely than me to read the debugging documentation (and want to change a registry setting like this). -- Jeff S >From: Eric Pouech <eric.pouech(a)wanadoo.fr> > >>Can we do something like throw up a message box before loading the >>debugger, >>asking if we want to debug? Or perhaps there should be a command-line >>option to >>the debugger that presents said dialog, then use that option when starting >>the >>debugger in the event of an crash. >RTFM >hints: AeDebug, Auto >A+ _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: strcat+strcat+strcat == baaad"
by Jeff Smith 10 Dec '02

10 Dec '02

>From: vkxzjq6lg(a)cswebmail.com > >Francois Gouget wrote: > > > Of course, that implies that we should promptly fix any such crash. > > Otherwise it just makes Wine unusable without any benefit. > >That's the catch. I'm not approaching Wine as a Wine developer. Wine is >almost ready for >prime time now and as a non-Wine developer (who's roped in so far only as >far as necessary >to get the app I want to run running) I'm approaching it as a near >production system. > >When only hard core Wine developers were seeing it, opening the debugger >made sense. > >Wine is leaving the core development stage and now it's time to be >arranging for bug >reporting mechanisms which don't require that you be a programmer willing >to start >debugging Wine to get your applications running. > >That means avoiding a raw debugger window and providing something more end >user friendly. >To me that means something like logging every non-dangerous failure >possible rather than >killing the application. Then, when the application finishes, winseerver >can pop up a >polite window telling the user that there was a problem and asking them to >report it to >the developers, making it easy to do that. > >It definitely doesn't involve opening debugger windows. Those will scare >away the end >users who need to be submitting those logs so the developers can see which >app or internal >routine was breaking the rules and what needs to be fixed. > >So: Wine's almost there (and congratulations on getting to the point where >I can seriously >write that!). Time to be thinking about what end users can handle and >changing how garbage >data reporting is handled to make it more friendly to them. Can we do something like throw up a message box before loading the debugger, asking if we want to debug? Or perhaps there should be a command-line option to the debugger that presents said dialog, then use that option when starting the debugger in the event of an crash. Perhaps this can be combined with some of the other ideas to create a reasonable user experience during a failure. -- Jeff S _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

WinXP Professional conformance test results
by David Miller 10 Dec '02

10 Dec '02

These tests were completed individually on WinXP Pro using the binaries from here: http://fgouget.free.fr/wine/winetests.zip C:\winetests>advapi32_test.exe registry h:\wine\wine\dlls\advapi32\tests\registry.c:80: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:81: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:94: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:95: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:96: Test failed: value set to 'xxxxxxxxxx' instead of 'Te' h:\wine\wine\dlls\advapi32\tests\registry.c:97: Test failed: data set to 'xxxxxxxxxx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:108: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:109: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:111: Test failed: data set to 'xxxxxxxxxx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:122: Test failed: data_count set to24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:123: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:134: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:135: Test failed: val_count set to 20 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:136: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:137: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:138: Test failed: value is 'xxxxxxxxxx' instead of Test h:\wine\wine\dlls\advapi32\tests\registry.c:139: Test failed: data is 'xxxxxxxxxx' instead of foobar h:\wine\wine\dlls\advapi32\tests\registry.c:155: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:156: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:169: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:170: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:182: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:183: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:184: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:185: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:195: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:196: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:197: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:198: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:199: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:200: Test failed: data is not 'foobar' registry: 56 tests executed, 0 marked as todo, 31 failures. C:\winetests>kernel32_test.exe alloc alloc: 58 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe atom atom: 229398 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe codepage codepage: 2 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe directory directory: 48 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe drive drive: 158 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe environ environ: 39 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe file h:\wine\wine\dlls\kernel\tests\file.c:578: Test failed: DeleteFile should fail with an empty path, and last error value should be ERROR_FILE_NOT_FOUND h:\wine\wine\dlls\kernel\tests\file.c:610:Current offset = 0015 h:\wine\wine\dlls\kernel\tests\file.c:635:Current offset = 0015 file: 487238 tests executed, 0 marked as todo, 1 failure. C:\winetests>kernel32_test.exe format_msg format_msg: 58 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe locale locale: 54 tests executed, 0 marked as todo, 0 failures. C:\winetests>kernel32_test.exe path h:\wine\wine\dlls\kernel\tests\path.c:517: Test failed: GetLongPathNameA: wrong return code, 104 instead of 44 h:\wine\wine\dlls\kernel\tests\path.c:927:TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp h:\wine\wine\dlls\kernel\tests\path.c:935:TMP=C:\WINDOWS h:\wine\wine\dlls\kernel\tests\path.c:944:TMP=C:\ h:\wine\wine\dlls\kernel\tests\path.c:954:TMP=C: h:\wine\wine\dlls\kernel\tests\path.c:879: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:892: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:898: Test failed: win2000 BUG: should return path without terminating back slash path: 2083 tests executed, 0 marked as todo, 4 failures. C:\winetests>kernel32_test.exe process tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:374: Test failed: StartupInfoA:lpDesktp expected (null), got WinSta0\Default h:\wine\wine\dlls\kernel\tests\process.c:375: Test failed: StartupInfoA:lpTitle expected (null), got C:\winetests\kernel32_test.exe tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:450: Test failed: StartupInfoA:lpDesktp expected (null), got WinSta0\Default tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:527: Test failed: StartupInfoA:lpTitle expected (null), got C:\winetests\kernel32_test.exe tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. process: 116 tests executed, 0 marked as todo, 4 failures. C:\winetests>kernel32_test.exe thread thread: 112 tests executed, 0 marked as todo, 0 failures. msvcrt_test.exe msvcrt <-- crashes C:\winetests> C:\winetests>netapi32_test.exe access h:\wine\wine\dlls\netapi32\tests\access.c:95: Test failed: Bad Network Path access: 23 tests executed, 0 marked as todo, 1 failure. C:\winetests>netapi32_test.exe apibuf apibuf: 15 tests executed, 0 marked as todo, 0 failures. C:\winetests>netapi32_test.exe wksta wksta: 14 tests executed, 0 marked as todo, 0 failures. C:\winetests>rpcrt4_test.exe rpc h:\wine\wine\dlls\rpcrt4\tests\rpc.c:124: ** Uuid Conversion and Comparison Tests ** rpc: 901 tests executed, 0 marked as todo, 0 failures. C:\winetests>shell32_test.exe shlfileop h:\wine\wine\dlls\shell32\tests\shlfileop.c:286: Test failed: Files are copied to other directory h:\wine\wine\dlls\shell32\tests\shlfileop.c:287: Test failed: The file is copied shlfileop: 121 tests executed, 0 marked as todo, 2 failures. C:\winetests>shell32_test.exe shlfileop h:\wine\wine\dlls\shell32\tests\shlfileop.c:286: Test failed: Files are copied t o other directory h:\wine\wine\dlls\shell32\tests\shlfileop.c:287: Test failed: The file is copied shlfileop: 121 tests executed, 0 marked as todo, 2 failures. C:\winetests>shlwapi_test.exe clist h:\wine\wine\dlls\shlwapi\tests\clist.c:367: Test failed: allowed bad element size h:\wine\wine\dlls\shlwapi\tests\clist.c:372: Test failed: allowed adding a container clist: 236 tests executed, 0 marked as todo, 2 failures. C:\winetests>shlwapi_test.exe shreg h:\wine\wine\dlls\shlwapi\tests\shreg.c:172: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:196: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:206: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:207: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:208: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:263: Test failed: didn't open copy (test didn't complete in 10 min, I ctrl-C out at this point) C:\winetests>user32_test.exe class class: 80 tests executed, 0 marked as todo, 0 failures. C:\winetests>user32_test.exe win h:\wine\wine\dlls\user\tests\win.c:91:main window 001F0080 main2 00220110 desktop 00010014 child 000B00F4 h:\wine\wine\dlls\user\tests\win.c:107:created child 001E00F6 h:\wine\wine\dlls\user\tests\win.c:120:created child of desktop 001F00F6 h:\wine\wine\dlls\user\tests\win.c:130:created child of child 002000F6 h:\wine\wine\dlls\user\tests\win.c:140:created top-level 002100F6 h:\wine\wine\dlls\user\tests\win.c:150:created owned top-level 002200F6 h:\wine\wine\dlls\user\tests\win.c:160:created popup 002300F6 h:\wine\wine\dlls\user\tests\win.c:170:created owned popup 002400F6 h:\wine\wine\dlls\user\tests\win.c:180:created top-level owned by child 002500F6 h:\wine\wine\dlls\user\tests\win.c:186:created popup owned by desktop 002600F6 h:\wine\wine\dlls\user\tests\win.c:192:created popup owned by child 002700F6 h:\wine\wine\dlls\user\tests\win.c:198:created WS_CHILD popup 002800F6 h:\wine\wine\dlls\user\tests\win.c:204:created owned WS_CHILD popup 002900F6 h:\wine\wine\dlls\user\tests\win.c:209:testing parent changes h:\wine\wine\dlls\user\tests\win.c:221:created child 002A00F6 h:\wine\wine\dlls\user\tests\win.c:247:created top-level 002B00F6 h:\wine\wine\dlls\user\tests\win.c:264:created popup 002C00F6 h:\wine\wine\dlls\user\tests\win.c:281:created child 002D00F6 h:\wine\wine\dlls\user\tests\win.c:298:created top-level 002E00F6 h:\wine\wine\dlls\user\tests\win.c:307:created owned popup 002F00F6 h:\wine\wine\dlls\user\tests\win.c:323:created owner 003000F6 and popup 001600CE h:\wine\wine\dlls\user\tests\win.c:337:created owner 001700CE and popup 003100F6 h:\wine\wine\dlls\user\tests\win.c:345:created owner 001800CE and popup 003200F6 win: 373 tests executed, 0 marked as todo, 0 failures. C:\winetests>wininet_test.exe http h:\wine\wine\dlls\wininet\tests\http.c:90:Starting with flags 0x10000000 h:\wine\wine\dlls\wininet\tests\http.c:92:InternetOpenA <-- h:\wine\wine\dlls\wininet\tests\http.c:95:InternetOpenA --> h:\wine\wine\dlls\wininet\tests\http.c:101:InternetConnectA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0012E990 4 h:\wine\wine\dlls\wininet\tests\http.c:104:InternetConnectA --> h:\wine\wine\dlls\wininet\tests\http.c:108:HttpOpenRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0012EC04 4 h:\wine\wine\dlls\wininet\tests\http.c:122:HttpOpenRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:126:HttpSendRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:133:HttpSendRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESOLVING_NAME(10) 0102FB04 15 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_NAME_RESOLVED(11) 0102FAF4 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0102FB9C 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0102FD40 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0102FCE0 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 0102FD64 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 0102FDA8 8 h:\wine\wine\dlls\wininet\tests\http.c:140:Option 0x17 -> 1 0 h:\wine\wine\dlls\wininet\tests\http.c:144:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:149:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Tue, 10 Dec 2002 05:27:22 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html h:\wine\wine\dlls\wininet\tests\http.c:154:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:158:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) h:\wine\wine\dlls\wininet\tests\http.c:163:Option 0x1 -> 1 text/html h:\wine\wine\dlls\wininet\tests\http.c:166:Entery Query loop h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 743 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 3348 h:\wine\wine\dlls\wininet\tests\http.c:172: Test failed: InternetQueryDataAvailable failed h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 0102FDA8 8 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:90:Starting with flags 0x0 h:\wine\wine\dlls\wininet\tests\http.c:92:InternetOpenA <-- h:\wine\wine\dlls\wininet\tests\http.c:95:InternetOpenA --> h:\wine\wine\dlls\wininet\tests\http.c:101:InternetConnectA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0012E990 4 h:\wine\wine\dlls\wininet\tests\http.c:104:InternetConnectA --> h:\wine\wine\dlls\wininet\tests\http.c:108:HttpOpenRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0012EC04 4 h:\wine\wine\dlls\wininet\tests\http.c:122:HttpOpenRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:126:HttpSendRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0012EA3C 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0012EA18 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0012EB28 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 0012EB14 4 h:\wine\wine\dlls\wininet\tests\http.c:133:HttpSendRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:140:Option 0x17 -> 1 0 h:\wine\wine\dlls\wininet\tests\http.c:144:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:149:Option 0x16 -> 1 HTTP/1.1 200 OK Date: Tue, 10 Dec 2002 05:27:23 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html h:\wine\wine\dlls\wininet\tests\http.c:154:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:158:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) h:\wine\wine\dlls\wininet\tests\http.c:163:Option 0x1 -> 1 text/html h:\wine\wine\dlls\wininet\tests\http.c:166:Entery Query loop h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 743 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 3348 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 3760 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 620 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1974 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_ STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbeef INTERNET_ STATUS_HANDLE_CLOSING(70) 0012EC30 4 http: 24 tests executed, 0 marked as todo, 1 failure. C:\winetests>winmm_test.exe wave h:\wine\wine\dlls\winmm\tests\wave.c:56:found 1 WaveOut devices h:\wine\wine\dlls\winmm\tests\wave.c:82: 0: "Sound Blaster AWE64" 5.10 (1:100): channels=65535 formats=bffff support=002c h:\wine\wine\dlls\winmm\tests\wave.c:133:Testing invalid 2MHz format wave: 53 tests executed, 0 marked as todo, 0 failures C:\winetests>ws2_32_test.exe sock h:\wine\wine\dlls\winsock\tests\sock.c:694: **** STARTING TEST 0 **** h:\wine\wine\dlls\winsock\tests\sock.c:332:simple_server (6e0) starting h:\wine\wine\dlls\winsock\tests\sock.c:341:simple_server (6e0) ready h:\wine\wine\dlls\winsock\tests\sock.c:346:simple_server (6e0): waiting for client h:\wine\wine\dlls\winsock\tests\sock.c:391:simple_client (728): starting h:\wine\wine\dlls\winsock\tests\sock.c:394:simple_client (728): server ready h:\wine\wine\dlls\winsock\tests\sock.c:391:simple_client (724): starting h:\wine\wine\dlls\winsock\tests\sock.c:394:simple_client (724): server ready h:\wine\wine\dlls\winsock\tests\sock.c:406:simple_client (728) connected h:\wine\wine\dlls\winsock\tests\sock.c:346:simple_server (6e0): waiting for client h:\wine\wine\dlls\winsock\tests\sock.c:406:simple_client (724) connected h:\wine\wine\dlls\winsock\tests\sock.c:374:simple_server (6e0) exiting h:\wine\wine\dlls\winsock\tests\sock.c:427:simple_client (728) exiting h:\wine\wine\dlls\winsock\tests\sock.c:427:simple_client (724) exiting h:\wine\wine\dlls\winsock\tests\sock.c:696: **** TEST 0 COMPLETE **** h:\wine\wine\dlls\winsock\tests\sock.c:694: **** STARTING TEST 1 **** h:\wine\wine\dlls\winsock\tests\sock.c:332:simple_server (748) starting h:\wine\wine\dlls\winsock\tests\sock.c:341:simple_server (748) ready h:\wine\wine\dlls\winsock\tests\sock.c:346:simple_server (748): waiting for client h:\wine\wine\dlls\winsock\tests\sock.c:445:event_client (604): starting h:\wine\wine\dlls\winsock\tests\sock.c:445:event_client (750): starting h:\wine\wine\dlls\winsock\tests\sock.c:447:event_client (604): server ready h:\wine\wine\dlls\winsock\tests\sock.c:467:event_client (604) connected h:\wine\wine\dlls\winsock\tests\sock.c:505:event_client (604): all data sent - shutdown h:\wine\wine\dlls\winsock\tests\sock.c:346:simple_server (748): waiting for client h:\wine\wine\dlls\winsock\tests\sock.c:526:event_client (604): all data received h:\wine\wine\dlls\winsock\tests\sock.c:538:event_client (604): close event h:\wine\wine\dlls\winsock\tests\sock.c:556:event_client (604) exiting h:\wine\wine\dlls\winsock\tests\sock.c:447:event_client (750): server ready h:\wine\wine\dlls\winsock\tests\sock.c:467:event_client (750) connected h:\wine\wine\dlls\winsock\tests\sock.c:505:event_client (750): all data sent - shutdown h:\wine\wine\dlls\winsock\tests\sock.c:374:simple_server (748) exiting h:\wine\wine\dlls\winsock\tests\sock.c:526:event_client (750): all data received h:\wine\wine\dlls\winsock\tests\sock.c:538:event_client (750): close event h:\wine\wine\dlls\winsock\tests\sock.c:556:event_client (750) exiting h:\wine\wine\dlls\winsock\tests\sock.c:696: **** TEST 1 COMPLETE **** sock: 128 tests executed, 0 marked as todo, 0 failures. C:\winetests>user32_test.exe sysparams h:\wine\wine\dlls\user\tests\sysparams.c:184:testing SPI_{GET,SET}BEEP h:\wine\wine\dlls\user\tests\sysparams.c:306:testing SPI_{GET,SET}MOUSE h:\wine\wine\dlls\user\tests\sysparams.c:374:testing SPI_{GET,SET}BORDER h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=1, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=0, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=7, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=20, value= h:\wine\wine\dlls\user\tests\sysparams.c:406:testing SPI_{GET,SET}KEYBOARDSPEED h:\wine\wine\dlls\user\tests\sysparams.c:440:testing SPI_ICONHORIZONTALSPACING h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=101, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=32, value= h:\wine\wine\dlls\user\tests\sysparams.c:480:testing SPI_{GET,SET}SCREENSAVETIMEOUT h:\wine\wine\dlls\user\tests\sysparams.c:515:testing SPI_{GET,SET}SCREENSAVEACTIVE h:\wine\wine\dlls\user\tests\sysparams.c:555:testing SPI_{GET,SET}KEYBOARDDELAY h:\wine\wine\dlls\user\tests\sysparams.c:590:testing SPI_ICONVERTICALSPACING h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=101, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=32, value= h:\wine\wine\dlls\user\tests\sysparams.c:635:testing SPI_{GET,SET}ICONTITLEWRAP h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=1, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=0, value= h:\wine\wine\dlls\user\tests\sysparams.c:670:testing SPI_{GET,SET}MENUDROPALIGNMENT h:\wine\wine\dlls\user\tests\sysparams.c:707:testing SPI_SETDOUBLECLKWIDTH h:\wine\wine\dlls\user\tests\sysparams.c:738:testing SPI_SETDOUBLECLKHEIGHT h:\wine\wine\dlls\user\tests\sysparams.c:770:testing SPI_SETDOUBLECLICKTIME h:\wine\wine\dlls\user\tests\sysparams.c:817:testing SPI_SETMOUSEBUTTONSWAP h:\wine\wine\dlls\user\tests\sysparams.c:880:testing SPI_{GET,SET}DRAGFULLWINDOWS h:\wine\wine\dlls\user\tests\sysparams.c:915:testing SPI_{GET,SET}WORKAREA h:\wine\wine\dlls\user\tests\sysparams.c:953:testing SPI_{GET,SET}SHOWSOUNDS h:\wine\wine\dlls\user\tests\sysparams.c:997:testing SPI_{GET,SET}DESKWALLPAPER sysparams: 318 tests executed, 0 marked as todo, 10 failures.

1 0

Re: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com 10 Dec '02

10 Dec '02

"Dimitrie O. Paun" wrote: > > On December 5, 2002 11:16 am, Alexandre Julliard wrote: > > It's the kind of thinking that leads to having an exception > > handler inside strlen() like Windows does. It's just plain wrong. > > <nod/>. This is generally true for other things as well: > > 1. Many places in our code where we have invariant like > pointer p is never NULL, yet we always have: > > if (!p) return NULL; /* or whatever error condition */ > > Such a check is harmful (hides bugs), slow (useless > runtime check), bloat (more generated code), > ugly (clutters the code), at the very least. Just > Don't Do It (TM) -- let the code crash. Agreed that it's harmful because it hides what may be a real error. Lousy idea unless p really is allowed to have that value. If it's a call exposed to external callers it needs to warn somehow, even to the console if necessary (assuming that Wine wants to give end users some feedback they can give back to the Wine developers and to the developer of the faulty application). Those warnings can vanish should there ever be a production build with debugging removed. If it's internal only it should be an assert or fixme. Being too free with "let the code crash" is a bad idea. Microsoft got a lot of really bad heckling in the Windows 3.1 era for GPFs. Wine doesn't want to crash if it's reasonably harmless to continue (like for a failed screen update). Does want to report the problem, of course, rather than silently ignore it, otherwise it'll never get fixed. > > 2. ZeroMemory when we don't need to, when we pass struct > internally, yet same functions can be called externally > with no guarantee that the struct has unused field > zeroed out. > Agreed if it is a call to an internal only function. If it's to a function with an external API then it may need zeroing to get to the state required for that. > 3. In general, we have all sort of 'defensive programming' > checks for invariants. Problem is, we never going to > catch bugs in this area this way. Just use assert() > if you feel a check is needed. If it's a documented external interface it can't assert and die because the application making the call presumably works on real Windows. So it needs to be warned/fixme'd or whatever so end users can report the issue to Wine developers for fixing. If it's internal, assert is sort of OK, though as someone trying to get an application working I want a fixme rather than sudden death (except in file output interfaces!). I don't need perfect functionality. I do need to get the app to the point where it is safely functioning and an assert may kill it when it doesn't need to die. > In short, this defensive programming crap is just that: crap. Do you agree with the way I've explained how I see the difference between redundant defensive programming and detecting and reporting problems which need to be fixed? If not, where do you differ and why? James ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

3 2

[Fwd: A registry editor taking shape ...]
by Dan Kegel 10 Dec '02

10 Dec '02

Hey, looks like the Samba guys are doing a registry editor... - Dan -------- Original Message -------- Subject: A registry editor taking shape ... Date: Mon, 9 Dec 2002 01:56:50 -0800 (PST) From: Richard Sharpe <rsharpe(a)richardsharpe.com> To: <samba-technical(a)samba.org> Hi, A registry editor, editreg, is slowly taking shape in Samba-head. The goal is to be able to do things like: - delete keys and values - add keys and values - change keys and values - Change the SIDS/SecDescs applied to keys. - write out the changes tree - create a tree from scratch What would be useful is some thoughts on how the interface should be constructed, as in command-line, or a .reg file of commands, etc. Regards ----- Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com

2 1

Import Lib patche
by Steven Edwards 10 Dec '02

10 Dec '02

Hola, Just wondering if you were still doing the import lib stuff. I saw in a past message that you had some patches outstanding and assumed import lib patch is one of them. I think this is the only thing holding up being able to compile all of the regression tests under windows via Mingw. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

1 0

wpp
by Dimitrie O. Paun 10 Dec '02

10 Dec '02

Folks, Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E? -- Dimi.

5 11

Windows XP Conformance Test results...
by Kye Lewis 10 Dec '02

10 Dec '02

Hi, My Results using the batch file and Windows XP. If you need any more information about msvcrt_test crash, just ask. My desktop also becomes smaller after running user32_test sysparams, the approximate time of this is marked below in the appropriate section. These results are obtained with Windows XP Home ==== advapi32_test ==== h:\wine\wine\dlls\advapi32\tests\registry.c:80: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:81: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:94: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:95: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:96: Test failed: value set to 'xxxxxxxxxx' instead of 'Te' h:\wine\wine\dlls\advapi32\tests\registry.c:97: Test failed: data set to 'xxxxxxxxxx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:108: Test failed: data_count set to24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:109: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:111: Test failed: data set to 'xxxxxxxxxx' instead of 'foobar' h:\wine\wine\dlls\advapi32\tests\registry.c:122: Test failed: data_count set to24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:123: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:134: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:135: Test failed: val_count set to 20 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:136: Test failed: data_count set to 24 instead of 7 h:\wine\wine\dlls\advapi32\tests\registry.c:137: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:138: Test failed: value is 'xxxxxxxxxx' instead of Test h:\wine\wine\dlls\advapi32\tests\registry.c:139: Test failed: data is 'xxxxxxxxxx' instead of foobar h:\wine\wine\dlls\advapi32\tests\registry.c:155: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:156: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:169: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:170: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:182: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:183: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:184: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:185: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:195: Test failed: expected ERROR_SUCCESS, got 234 h:\wine\wine\dlls\advapi32\tests\registry.c:196: Test failed: val_count set to 5 instead of 4 h:\wine\wine\dlls\advapi32\tests\registry.c:197: Test failed: data_count set to 48 instead of 7*sizeof(WCHAR) h:\wine\wine\dlls\advapi32\tests\registry.c:198: Test failed: type 2 is not REG_SZ h:\wine\wine\dlls\advapi32\tests\registry.c:199: Test failed: value is not 'Test' h:\wine\wine\dlls\advapi32\tests\registry.c:200: Test failed: data is not 'foobar' registry: 56 tests executed, 0 marked as todo, 31 failures. ==== kernel32_test ==== alloc: 58 tests executed, 0 marked as todo, 0 failures. atom: 229398 tests executed, 0 marked as todo, 0 failures. codepage: 2 tests executed, 0 marked as todo, 0 failures. directory: 48 tests executed, 0 marked as todo, 0 failures. drive: 156 tests executed, 0 marked as todo, 0 failures. environ: 39 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\file.c:578: Test failed: DeleteFile should fail with an empty path, and last error value should be ERROR_FILE_NOT_FOUND h:\wine\wine\dlls\kernel\tests\file.c:610:Current offset = 0015 h:\wine\wine\dlls\kernel\tests\file.c:635:Current offset = 0015 file: 487238 tests executed, 0 marked as todo, 1 failure. format_msg: 58 tests executed, 0 marked as todo, 0 failures. generated: 609 tests executed, 0 marked as todo, 0 failures. locale: 54 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\path.c:927:TMP=C:\WINDOWS\TEMP h:\wine\wine\dlls\kernel\tests\path.c:935:TMP=C:\WINDOWS h:\wine\wine\dlls\kernel\tests\path.c:944:TMP=C:\ h:\wine\wine\dlls\kernel\tests\path.c:954:TMP=C: h:\wine\wine\dlls\kernel\tests\path.c:879: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:892: Test failed: win2000 BUG: expected 12, got 13 h:\wine\wine\dlls\kernel\tests\path.c:898: Test failed: win2000 BUG: should return path without terminating back slash path: 2083 tests executed, 0 marked as todo, 3 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:374: Test failed: StartupInfoA:lpDesktop expected (null), got WinSta0\Default h:\wine\wine\dlls\kernel\tests\process.c:375: Test failed: StartupInfoA:lpTitle expected (null), got C:\DOCUME~1\Owner\DESKTOP\WINETE~1\KERNEL32_TEST.exe tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:450: Test failed: StartupInfoA:lpDesktop expected (null), got WinSta0\Default tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\kernel\tests\process.c:527: Test failed: StartupInfoA:lpTitle expected (null), got C:\DOCUME~1\Owner\DESKTOP\WINETE~1\KERNEL32_TEST.exe tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. process: 116 tests executed, 0 marked as todo, 4 failures. thread: 112 tests executed, 0 marked as todo, 0 failures. ==== msvcrt_test ==== Fails to run (msvcrt_test.exe has encountered a problem and needs to close. We are sorry for the inconvenience) Debug Shows Unhandled exception in msvcrt_test.exe (NTDLL.DLL): 0xC0000005: Access Violation More information available if required ==== netapi32_test ==== h:\wine\wine\dlls\netapi32\tests\access.c:95: Test failed: Bad Network Path access: 23 tests executed, 0 marked as todo, 1 failure. apibuf: 15 tests executed, 0 marked as todo, 0 failures. wksta: 14 tests executed, 0 marked as todo, 0 failures. ==== rpcrt4_test ==== h:\wine\wine\dlls\rpcrt4\tests\rpc.c:124: ** Uuid Conversion and Comparison Tests ** rpc: 901 tests executed, 0 marked as todo, 0 failures. ==== shell32_test ==== generated: 272 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\shell32\tests\shlfileop.c:286: Test failed: Files are copied to other directory h:\wine\wine\dlls\shell32\tests\shlfileop.c:287: Test failed: The file is copied shlfileop: 121 tests executed, 0 marked as todo, 2 failures. ==== shlwapi_test ==== h:\wine\wine\dlls\shlwapi\tests\clist.c:367: Test failed: allowed bad element size h:\wine\wine\dlls\shlwapi\tests\clist.c:372: Test failed: allowed adding a container clist: 236 tests executed, 0 marked as todo, 2 failures. generated: 19 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\shlwapi\tests\shreg.c:172: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:196: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:206: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:207: Test failed: () h:\wine\wine\dlls\shlwapi\tests\shreg.c:208: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (44,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:241: Test failed: didn't open dest shreg: 39 tests executed, 0 marked as todo, 7 failures. ==== user32_test ==== class: 80 tests executed, 0 marked as todo, 0 failures. generated: 1524 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\user\tests\sysparams.c:184:testing SPI_{GET,SET}BEEP h:\wine\wine\dlls\user\tests\sysparams.c:306:testing SPI_{GET,SET}MOUSE h:\wine\wine\dlls\user\tests\sysparams.c:374:testing SPI_{GET,SET}BORDER h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=1, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=0, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=7, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=BorderWidth, testValue=20, value= h:\wine\wine\dlls\user\tests\sysparams.c:406:testing SPI_{GET,SET}KEYBOARDSPEED h:\wine\wine\dlls\user\tests\sysparams.c:440:testing SPI_ICONHORIZONTALSPACING h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=101, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconSpacing, testValue=32, value= h:\wine\wine\dlls\user\tests\sysparams.c:480:testing SPI_{GET,SET}SCREENSAVETIMEOUT h:\wine\wine\dlls\user\tests\sysparams.c:515:testing SPI_{GET,SET}SCREENSAVEACTIVE h:\wine\wine\dlls\user\tests\sysparams.c:555:testing SPI_{GET,SET}KEYBOARDDELAY h:\wine\wine\dlls\user\tests\sysparams.c:590:testing SPI_ICONVERTICALSPACING h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=101, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconVerticalSpacing, testValue=32, value= h:\wine\wine\dlls\user\tests\sysparams.c:635:testing SPI_{GET,SET}ICONTITLEWRAP h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=1, value= h:\wine\wine\dlls\user\tests\sysparams.c:170: Test failed: Wrong value in registry: subKey=Control Panel\Desktop, valName=IconTitleWrap, testValue=0, value= h:\wine\wine\dlls\user\tests\sysparams.c:670:testing SPI_{GET,SET}MENUDROPALIGNMENT h:\wine\wine\dlls\user\tests\sysparams.c:707:testing SPI_SETDOUBLECLKWIDTH h:\wine\wine\dlls\user\tests\sysparams.c:738:testing SPI_SETDOUBLECLKHEIGHT h:\wine\wine\dlls\user\tests\sysparams.c:770:testing SPI_SETDOUBLECLICKTIME h:\wine\wine\dlls\user\tests\sysparams.c:817:testing SPI_SETMOUSEBUTTONSWAP // Desktop Resizes somewhere between here: h:\wine\wine\dlls\user\tests\sysparams.c:880:testing SPI_{GET,SET}DRAGFULLWINDOWS h:\wine\wine\dlls\user\tests\sysparams.c:915:testing SPI_{GET,SET}WORKAREA And Here // h:\wine\wine\dlls\user\tests\sysparams.c:953:testing SPI_{GET,SET}SHOWSOUNDS h:\wine\wine\dlls\user\tests\sysparams.c:997:testing SPI_{GET,SET}DESKWALLPAPER sysparams: 318 tests executed, 0 marked as todo, 10 failures. win: 373 tests executed, 0 marked as todo, 0 failures. wsprintf: 4 tests executed, 0 marked as todo, 0 failures. ==== wininet_test ==== generated: 252 tests executed, 0 marked as todo, 0 failures. h:\wine\wine\dlls\wininet\tests\http.c:90:Starting with flags 0x10000000 h:\wine\wine\dlls\wininet\tests\http.c:92:InternetOpenA <-- h:\wine\wine\dlls\wininet\tests\http.c:95:InternetOpenA --> h:\wine\wine\dlls\wininet\tests\http.c:101:InternetConnectA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0012E990 4 h:\wine\wine\dlls\wininet\tests\http.c:104:InternetConnectA --> h:\wine\wine\dlls\wininet\tests\http.c:108:HttpOpenRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0012EC04 4 h:\wine\wine\dlls\wininet\tests\http.c:122:HttpOpenRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:126:HttpSendRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:133:HttpSendRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESOLVING_NAME(10) 00D6FB04 15 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_NAME_RESOLVED(11) 00D6FAF4 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 00D6FB9C 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 00D6FD40 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 00D6FCE0 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 00D6FD60 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 00D6FDA8 8 h:\wine\wine\dlls\wininet\tests\http.c:140:Option 0x17 -> 1 8 h:\wine\wine\dlls\wininet\tests\http.c:144:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:149:Option 0x16 -> 1 HTTP/1.0 200 OK Date: Mon, 09 Dec 2002 22:47:48 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Content-Type: text/html X-Cache: MISS from cache.net2000.com.au Connection: close h:\wine\wine\dlls\wininet\tests\http.c:154:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:158:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) h:\wine\wine\dlls\wininet\tests\http.c:163:Option 0x1 -> 1 text/html h:\wine\wine\dlls\wininet\tests\http.c:166:Entery Query loop h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 773 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 465 h:\wine\wine\dlls\wininet\tests\http.c:172: Test failed: InternetQueryDataAvailable failed h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_COMPLETE(100) 00D6FDA8 8 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:90:Starting with flags 0x0 h:\wine\wine\dlls\wininet\tests\http.c:92:InternetOpenA <-- h:\wine\wine\dlls\wininet\tests\http.c:95:InternetOpenA --> h:\wine\wine\dlls\wininet\tests\http.c:101:InternetConnectA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0004 0xdeadbeef INTERNET_STATUS_HANDLE_CREATED(60) 0012E990 4 h:\wine\wine\dlls\wininet\tests\http.c:104:InternetConnectA --> h:\wine\wine\dlls\wininet\tests\http.c:108:HttpOpenRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbead INTERNET_STATUS_HANDLE_CREATED(60) 0012EC04 4 h:\wine\wine\dlls\wininet\tests\http.c:122:HttpOpenRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:126:HttpSendRequestA --> h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTING_TO_SERVER(20) 0012EA3C 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTED_TO_SERVER(21) 0012EA18 12 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_SENDING_REQUEST(30) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_REQUEST_SENT(31) 0012EB28 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RECEIVING_RESPONSE(40) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_RESPONSE_RECEIVED(41) 0012EB10 4 h:\wine\wine\dlls\wininet\tests\http.c:133:HttpSendRequestA <-- h:\wine\wine\dlls\wininet\tests\http.c:140:Option 0x17 -> 1 8 h:\wine\wine\dlls\wininet\tests\http.c:144:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:149:Option 0x16 -> 1 HTTP/1.0 200 OK Date: Mon, 09 Dec 2002 22:47:49 GMT Server: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6 PHP/4. 1.2 X-Powered-By: PHP/4.1.2 Content-Type: text/html X-Cache: MISS from cache.net2000.com.au Connection: close h:\wine\wine\dlls\wininet\tests\http.c:154:Option 0x22 -> 1 http://www.winehq.com/about/ h:\wine\wine\dlls\wininet\tests\http.c:158:Option 0x5 -> 0 http://www.winehq.com/about/ (12150) h:\wine\wine\dlls\wininet\tests\http.c:163:Option 0x1 -> 1 text/html h:\wine\wine\dlls\wininet\tests\http.c:166:Entery Query loop h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 773 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 465 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 1460 h:\wine\wine\dlls\wininet\tests\http.c:183:ReadFile -> 1 447 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CLOSING_CONNECTION(50) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_CONNECTION_CLOSED(51) 00000000 0 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC000C 0xdeadbead INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 h:\wine\wine\dlls\wininet\tests\http.c:78:Callback 00CC0008 0xdeadbeef INTERNET_STATUS_HANDLE_CLOSING(70) 0012EC30 4 http: 28 tests executed, 0 marked as todo, 1 failure. ==== winmm_test ==== h:\wine\wine\dlls\winmm\tests\wave.c:56:found 1 WaveOut devices h:\wine\wine\dlls\winmm\tests\wave.c:82: 0: "SB Live! Wave Device" 5.10 (1:100): channels=65535 formats=bffff support=002c h:\wine\wine\dlls\winmm\tests\wave.c:133:Testing invalid 2MHz format wave: 53 tests executed, 0 marked as todo, 0 failures. ==== ws2_32_test ==== sock: 128 tests executed, 0 marked as todo, 0 failures.

1 0

Re: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com 10 Dec '02

10 Dec '02

Francois Gouget wrote: > Of course, that implies that we should promptly fix any such crash. > Otherwise it just makes Wine unusable without any benefit. That's the catch. I'm not approaching Wine as a Wine developer. Wine is almost ready for prime time now and as a non-Wine developer (who's roped in so far only as far as necessary to get the app I want to run running) I'm approaching it as a near production system. When only hard core Wine developers were seeing it, opening the debugger made sense. Wine is leaving the core development stage and now it's time to be arranging for bug reporting mechanisms which don't require that you be a programmer willing to start debugging Wine to get your applications running. That means avoiding a raw debugger window and providing something more end user friendly. To me that means something like logging every non-dangerous failure possible rather than killing the application. Then, when the application finishes, winseerver can pop up a polite window telling the user that there was a problem and asking them to report it to the developers, making it easy to do that. It definitely doesn't involve opening debugger windows. Those will scare away the end users who need to be submitting those logs so the developers can see which app or internal routine was breaking the rules and what needs to be fixed. So: Wine's almost there (and congratulations on getting to the point where I can seriously write that!). Time to be thinking about what end users can handle and changing how garbage data reporting is handled to make it more friendly to them. ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

2 1

DOSMEM_Init VirtualProtect fails
by vkxzjq6lg＠cswebmail.com 10 Dec '02

10 Dec '02

To further my porting work, I've patched my copy of DOSMEM.C like this: else if (dos_init && !already_mapped) { if (DOSMEM_dosmem) { ERR( "Needs access to the first megabyte for DOS mode\n" ); ExitProcess(1); } MESSAGE( "Warning: unprotecting the first 64KB of memory to allow real-mode calls.\n" " NULL pointer accesses will no longer be caught.\n" ); /* James Day added the if/FIXME/return false around this VirtualProtect because OzWin on my AMD K6-3 gave this result: wine --debugmsg +dosmem ozwin2 fixme:toolhelp:InterruptRegister16 (0000, 0x26f00ba), stub. Warning: unprotecting the first 64KB of memory to allow real-mode calls. NULL pointer accesses will no longer be caught. fixme:dosmem:DOSMEM_Init Failed to unprotect first 64KB of memory. init=1, done=1, mapped=0 fixme:toolhelp:InterruptUnRegister16 (0000), stub. */ if ( ! VirtualProtect( NULL, 0x10000, PAGE_EXECUTE_READWRITE, NULL ) ) { FIXME("Failed to unprotect first 64KB of memory. init=%d, done=%d, mapped=%d\n", (int)dos_init, already_done, already_mapped); return FALSE; } /* copy the BIOS and ISR area down */ memcpy( DOSMEM_dosmem, DOSMEM_sysmem, 0x400 + 0x100 ); NtProtectVirtualMemory is returning STATUS_INVALID_PARAMETER to VirtualProtectEx and DOSMEM_Init wasn't handling this failure gracefully - the memcpy was tripping the debugger and falling flat, taking the application with it. Anyone got any better ideas? Want more information on what's happening, like which of the STATUS_INVALID_PARAMETER cases is happening? Lindows 3.0 OS (Debian plus bits), Wine 20021125 compiled here with only this change. Not running as root. 128MB of RAM. ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

1 0

How to find out if file is loaded?
by Klaus Niederkrueger 09 Dec '02

09 Dec '02

Hello, I would like to know the following: I start some program with "wine -debugmsg +file" and I get quite a lot of times trace:file:CreateFileW L"tiles\\TS01.bmp" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x80 trace:file:CreateFileW returning 0x58 trace:file:_lopen ('tiles\TS01.BMP',0000) trace:file:CreateFileW L"tiles\\TS01.BMP" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE OPEN_EXISTING attributes 0x0 trace:file:CreateFileW returning 0x58 trace:file:ReadFile 0x58 0x406d2690 14 0x406d264c (nil) trace:file:ReadFile 0x58 0x406d2668 40 0x406d264c (nil) trace:file:ReadFile 0x58 0x406d26a4 1024 0x406d264c (nil) trace:file:_lclose handle 88 So it seems to me that the file tiles\TS01.BMP is loaded, but when I use "ltrace wine ..." I don't find any output regarding this file. Why is that? Thanks for any answer Klaus

2 2

Re: strcat+strcat+strcat == baaad
by Morten Welinder 09 Dec '02

09 Dec '02

Unless we're talking an inner and very intensive loop, all this is a bit silly. However, assuming that it does make sense, sprintf variants are not part of the answer. They're interpreted and var-arg type, both of which are little good for efficiency. More like something along these lines: char *tmpdst = dst; strcpy (tmpdst, src1); tmpdst += strlen (src1); strcpy (tmpdst, src2); tmpdst += strlen (src2); strcpy (tmpdst, src3); tmpdst += strlen (src3); ... strcpy (tmpdst, srcN); tmpdst += strlen (srcN); ... This works even better when the strlen calls have known results. Of course, nothing keeps the compiler from noticing a certain pattern of sprintf calls can producing an equaivalent of the above, but right now gcc will not do that if I recall correctly. Morten

2 1

Non latin fonts and non local fonts
by Shachar Shemesh 09 Dec '02

09 Dec '02

Hi list, http://bugs.winehq.com/show_bug.cgi?id=1157 It appears that when I'm copying the Windows fonts to C:\windows\Fonts, setting LANG to he_IL is all it takes for Hebrew to be displayed in edit controls and dialog boxes. When I try to copy the exact same fonts to /usr/lib/X11/fonts/windows, and adding them to the XF86Config fonts dir, and running ttmkfdir, no go. The fonts are available to Wine (and each is enumerated multiple times in the fonts dialog), but Hebrew is not displayed by default. Sometimes, when I force the CHARSET to HEBREW_CHARSET, I get Hebrew after all, but I'm not at all sure the same font is used then. In addition to this problem, I was wondering why we no longer enumerate the X fonts the moment there is ONE font file in c:\windows\Fonts? Is there a reason for them to magically disappear? Shachar

2 1

Re: strcat+strcat+strcat == baaad
by Alexandre Julliard 09 Dec '02

09 Dec '02

Francois Gouget <fgouget(a)free.fr> writes: > I don't like pieces of code that go: > > strcpy(foo, bar1); > strcat(foo, bar2); > strcat(foo, bar3); > strcat(foo, bar4); > strcat(foo, bar5); > strcat(foo, bar6); > > It's really inefficient: the cost increases quadratically with the size > of the resulting string. Well, no, the cost is linear. It would only be quadratic if the number of strcat calls depended on the length of the string. > It's more efficient to do: > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); I seriously doubt that sprintf would be faster that a couple of strcats. And I don't think we need to worry about this kind of micro-optimizations right now... -- Alexandre Julliard julliard(a)winehq.com

10 26

Wine startup problem
by Leonardo Giordani 09 Dec '02

09 Dec '02

I'm using CVS Wine 20021125, but I cannot start any application: what I gete is always -bash-2.05b$ wine War3.exe Loading required GL library /usr/X11R6/lib/libGL.so.1.2 err:ntdll:RtlpWaitForCriticalSection section 0x4010ad10 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=09545090 It hangs and does nothing. What's the matter? Thank you ------------ Leonardo Giordani leo.giordani(a)libero.it

3 3

Disassembly of the adobe svg plugin
by Mike Hearn 09 Dec '02

09 Dec '02

Well, I have about 2 hours now when I can work on trying to get the adobe svg plugin to work in Wine. I have a deadline to meet for Friday that requires the plugin, so if I can't get it working back to Windows it is (it's like a damn magnet). I've already located a mouse bug (problem with my last patch, oops) and fixed it (patch sent), but the lack of render on paint problem still eludes me. Having not got a response to the last email, I'll assume it's OK to try poking about inside the plugin itself to figure out what's going wrong. If anybody has some tips, now would be the time to tell me about them :) I hope this doesn't invalidate any patches I might produce..... -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 6

Turkish keyboard Support
by Armish 09 Dec '02

09 Dec '02

Hi all, I tried the latest wine (Wine-20021125.tar.gz) and saw that though it supports the Turkish Keyboard Layout, I cannot write the specail chars of Turkish (Like ı ş ğ � � � ...) Then I found a (Turkish) keyboard.c but still don't know where or how to it? (The keyboard.c is working well with my kernel) What can I do? (The keyboard.c is in the attach. for someone who want to check) Thanks __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

Re: Turkish keyboard Support
by Jeff Smith 09 Dec '02

09 Dec '02

Was this working under Wine-20021031? I have been trying to figure out a similar problem with the Spanish keyboard layout. If this caused a regression for you as well, it means I have been looking at the wrong problem. If you could test with the 20021031 version and compare results, that could be very helpful. -- Jeff S >From: Armish <acemimsi(a)yahoo.com> > >Hi all, >I tried the latest wine (Wine-20021125.tar.gz) and saw >that though it supports the Turkish Keyboard Layout, I >cannot write the specail chars of Turkish (Like ý >þ ð ü ç ö ...) >Then I found a (Turkish) keyboard.c but still don't >know where or how to it? (The keyboard.c is working >well with my kernel) What can I do? >(The keyboard.c is in the attach. for someone who want >to check) >Thanks _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

POSE (Palm OS Emulator) on WINE?
by Bodo Wenzel 09 Dec '02

09 Dec '02

Hi list. Because Sony doesn't provide a Unix source code branch, I tried to run their Windows based POSE on WINE. At first glance it runs, but only until a command of the context menu is chosen. WINE reports an "unhandled exception" and launches the debugger. My question: does anyone heard about how to make POSE run on WINE? Is anyone interested in making them work together? Both are Open Source... Unfortunately I can't because of my lack of time :-( TIA, Bodo

2 2

Re: Fix the winmm/wave tests
by Alexandre Julliard 09 Dec '02

09 Dec '02

Francois Gouget <fgouget(a)free.fr> writes: > * dlls/winmm/tests/wave.c > > Error handling in waveOutOpen works now (patch has been in CVs for a > couple of weeks) -> removing the todo_wine This doesn't work for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c && touch wave.ok err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) wave.c:145: Test failed: opening the device at 2MHz should fail 0: rc=4 -- Alexandre Julliard julliard(a)winehq.com

2 1

Question about STRICT
by Vincent Béron 09 Dec '02

09 Dec '02

I was compiling the tests on MSVC (hence my patch), and the gdi32test wouldn't compile with the Wine headers (but would with MSVC's). The problem can be traced back to the absence of STRICT in windef.h. With the closure of bug #90 (compilation with -DSTRICT), I think it would make sense to define it in a header (windef.h seems logical), with an ifdef NO_STRICT provision (see the attached proposed patch). This would allow to remove all -DSTRICT on compilation command lines. I await your comments on it. Vincent --- wine-20021206-1700/include/windef.h 2002-10-23 20:47:38.000000000 -0400 +++ wine-20021206-1700/include/windef.h 2002-12-07 16:34:02.000000000 -0500 @@ -28,6 +28,12 @@ #ifndef WINVER #define WINVER 0x0500 #endif + +#ifndef NO_STRICT +#ifndef STRICT +#define STRICT +#endif /* STRICT */ +#endif /* NO_STRICT */ #include "winnt.h"

2 1

Fw: Loading Autorun.inf on CD's
by Dustin Navea 09 Dec '02

09 Dec '02

----- Original Message ----- From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> To: "Tony Lambregts" <tony_lambregts(a)telusplanet.net>; "Dustin Navea" <speeddymon(a)sbcglobal.net> Cc: "Sylvain Petreolle" <spetreolle(a)yahoo.fr>; "Wine Developers" <wine-devel(a)winehq.com> Sent: Sunday, December 08, 2002 5:11 AM Subject: Re: Loading Autorun.inf on CD's > If you want act in this way, I have something for you. > This could help Paul Jones, who is searching how to "launch" *.msi > installers. interesting > The better way we can handle this is a program who tries to open every > document we give to it. A freeware utility exists in cygwin world and > is called cygstart, using the existing registry. If we give it a .doc, > it looks in HKCR and starts Worpad/Winword. > That is a definite must.. > If we tweak the registry of a .inf (winedefault.reg), we can ask it to > launch a tiny program that will open the .inf and run the program > specified. Sounds like it could work, but what about inf installer files (ie TweakUI's inf, or driver inf files) how would they be handled? > > I have not seen this work either and definitely not with an .inf. Yes > > it > > would be cool and if you want to start a bug concerning it feel free. > > I > > am not that worried about it though. The way I see it is that most of > > > > this is not realy a wine problem but rather with setting up autorun > > so > > that it is able to understand what to do with an .inf file. I suppose > > > > another way to look at it might be that wcmd could/should be able to > > handle something like "wcmd autorun.inf". > > -Dustin

2 2

regression: msvc4.0 install dies sooner now
by Dan Kegel 09 Dec '02

09 Dec '02

I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5, couldn't resist. Today I finally tried to install it under Wine. wine-20020605-2 (rh8): installer started; when I clicked on 'Install Visual C++', it put up a 'Installing... please wait' dialog, then failed with a 'Can't read version info from C:\windows\kernel386.drv' message (more or less), then hung. wine-20021125 (from source): installer started; when I clicked on 'Install Visual C++', it hung. Looks like a regression to me. Logs of --debugmsg +relay are up at http://www.kegel.com/msvc4setup-wine20020605.log.bz2 http://www.kegel.com/msvc4setup-wine20021125.log.bz2 The latter file is 28MB uncompressed, 512KB compressed. I'm now building the intermediate releases of wine to see if I can narrow down when the regression occurred. - Dan

4 6

Re: Fix my broken WM_MOUSEHOVER patch
by Dimitrie O. Paun 09 Dec '02

09 Dec '02

On December 9, 2002 11:26 am, Mike Hearn wrote: > Patch is relative to wine root, made with cvs diff, is this right? Yes, and no (it's not in the right format). Please read: http://www.winehq.org/development/#patches http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html -- Dimi.

3 2

Problem with DOSFS_OpenDevice
by Gustavo Junior Alves 09 Dec '02

09 Dec '02

Hi All, I having problems with raw printing. I receive this message from trace: device open lpt1 not supported (yet) Looking the code, I do not found any support for parallel ports neither on server or dos_fs. I missed something or DOSFS_OpenDevice does not support parallel printers? Thanks for the help. Gustavo Junior Alves alves(a)coslinux.com.br

2 1

Re: wine/dlls/winsock socket.c
by Martin Wilck 09 Dec '02

09 Dec '02

Am Sam, 2002-12-07 um 00.19 schrieb Alexandre Julliard: > Christoph Frick <frick(a)SC-Networks.de> > Force (WS_)SO_REUSEADDR before binding to a socket; Sorry, this is definitely wrong. Windows, just as Unix, returns WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There must be some special circumstances involved in those games the patch is supposed to fix. Perhaps they assume a certain Winsock implementation or Windows version. I'd like to know what remote addresses exactly the apps call bind() for, and in what order. Perhaps there are subtle differences in the way EADDRINUSE and SO_REUSEADDR are handled. > ignore (WS_)SO_DONTROUTE; Network games in Grand Prix Legends and Nascar 2002 > are possible now. Footnote (i) in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… says that this is - in principle - legal: "A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way." However the patch implements the first behavior (ignore) whereas the Windows TCP/IP transport behaves as the second (later calls to getsockopt() refelect the SO_DONTROUTE settings, which seems to have no further effect). > Patch: http://cvs.winehq.com/patch.py?id=6523 Alexandre, please back this patch out for now, at least the SO_REUSEADDR part which is plain wrong. Please don't get me wrong: These issues need to be fixed, but please, not by applying hackish patches for special applications such as this one. Christoph: sorry I missed out on your previous mails to wine-devel. Next time, say something about sockets in the subject line and chances are I won't miss them again. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> On December 8, 2002 06:01 pm, Patrik Stridvall wrote: > > It would be very nice it something made a GNU C compiler > > library to support among other things only running > > the preprocessor. > > Um, you mean like "cpp"? The debian packagers have even split > it out from > the gcc package for convenience, the package description explains; > > --------- > [snip] > The GNU C preprocessor is a macro processor that is used > automatically by > the GNU C compiler to transform programs before actual compilation. > > This package has been separated from gcc for the benefit of those who > require the preprocessor but not the compiler. > [snip] > --------- > > so clearly it can be done, and this is presumably for the > reasons Dimitrie > mentioned - preprocessing can be a useful (and much faster) subset to > separate out from the compilation process. Note that I said LIBRARY. Still running cpp is presumably more lightweight that running "gcc -E". > But as for the GPL argument against using the GNU C > (pre)compiler from a > run-time (ie. "forking/exec of 'gcc -E' is like linking to a > GPL lib"), I > find that rather hard to believe - especially as invoking > "gcc -E" can be > framed in very user-supplied terms. Eg. if the user is able to (in > theory) configure the program to exec() any precompilation > programs (and > command-line options) they want, then who is going to sue > *who* when the > default value for that setting just happens to be "gcc -E" when the > program installs? Exactly, as I said, it would never fly in court. However that doesn't mean that the FSF doesn't claim it never the less: http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem > Richard Stallman will sue Redhat? Or will > the FSF begin > a crackdown against adolescent nerds who illegally point > GPL-incompatible > configuration files to GPL-licensed precompilers ...? I really don't > think this should be a cause for concern. No, I don't think it would be a cause for concern either. Still, as I said, that is what they claim. Obviously they are not stupid so it would be very unlikely that they would press the issue. They seem to prefer to use FUD to accieve their goals instead.

2 1

Winedbg and gcc 3.2
by Alberto Massari 09 Dec '02

09 Dec '02

Hi everybody, a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine libraries (I got messages like "No debug information in ELF '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. So today I digged a little bit and I found that winedbg supports the "stabs" debug format, and looks for the ".stabs" segment in the binary. The copy of gcc 3.2 I have (gcc-3.2-1mdk) doesn't produce this segment unless I replace the -g option with -gstabs. My questions at this point are: - is this behavior typical of every gcc 3.2? or it's only Mandrake that does it? - is somebody going to change the "configure" script to detect such a situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, but I am not expert in this field... I just hacked my copy to make it work in my tree) - or should winedbg be improved to understand more debug formats, so that it can handle whatever informations the "-g" option spits out? Thanks, Alberto P.S. Please don't flame me if I said something naive....

2 2

GDI RestoreDC()
by Mike Hearn 09 Dec '02

09 Dec '02

Hi all, I think I've traced the problem with the Adobe SVG plugin not reliably rendering: This is from a good run (when I use an svg file I know will render OK): 080746b8:Call kernel32.LOCAL_Free(0000019f,00001aca) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1aca): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5300a17c 080746b8:Call gdi32.BitBlt(000008a8,00000000,00000000,0000008c,0000008c,00000ba0,00000000,00000000,00cc0020) ret=5300a1ae As you can see, it appears to perform the BitBlt call correctly, those parameters look correct. Here is the same section from a bad run: 080746b8:Call kernel32.LOCAL_Free(0000019f,00001ac2) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1ac2): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5301b3df 080746b8:Call gdi32.RestoreDC(000008a8,ffffffff) ret=53018c68 It doesn't call BitBlt at all, not now, not later, not at all. Instead, it calls RestoreDC for no apparently good reason. That last argument looks highly suspicious, in that MSDN says it's an int which when positive identifies a state and when negative identifies a "step", ie -1 would restore the last state from the stack. I can't figure out what ffffffff would be as an int though :( Would it be negative or positive? Either way, is this an intelligent sort of value for the parameter to have? The MSDN docs are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcon… I can't figure out why it would suddenly call RestoreDC and then seemingly go off on a tangent (the traces match up until that point), rather than do a BitBlt like it's supposed to. The SVG files vary only in that the "good" one has some interactivity (but it's not triggered at startup). Does anybody have any ideas? I'm fresh out for today. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> In other words, preprocessing is like 10% of compilation, so > it can't be unbearably slow. Something else is wrong. Perhaps. It was quite a few years ago I did it. I just remember abandoning the idea of using "gcc -E" for preprocessing in winapi_check because of horrible a speed slowdown. > > The FSF claims that you forking and calling a GPL:ed executable > > is the same as linking with a GPL:ed library and calling > > functions in that library. > > Do you have a reference to this? Never heard of something like > this before. It was dicussed extensively during the great licensing war. http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem The main part is this I think: < The difference between this and "incorporating" the GPL-covered software < is partly a matter of substance and partly form. The substantive part is < this: if the two programs are combined so that they become effectively < two parts of one program, then you can't treat them as two separate programs. < So the GPL has to cover the whole thing. In the case of wrc it is pretty clear that "gcc -E" will one of the parts of the whole program and thus wrc must be under the GPL (or compatible with it). While, as I said earlier, this is a not a direct problem for a LGPL application, we have as I said I policy not to "link" with GPL:ed applications.

1 0

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller 09 Dec '02

09 Dec '02

As someone only attempting to learn C I am looking for some other way to contribute something to wine. I have WinXP home on my laptop, so I could do WinXP tests if you can give me more information on what needs to be done. Dave

1 0

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> On December 8, 2002 03:27 pm, Patrik Stridvall wrote: > > It is faster. Mucher faster. Using cpp/gcc -E needs to > > fork a new process for example. > > What?!? You got to be kiddin', right? If you can measure > any difference in build time between the forking gcc -E > and using wpp I'll give you a dollar in small change. I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time. So I'm pretty sure that I can measure it, yes. However, the big question is not if it is measuarable but rather if it is worth the cost or not. So, yes, I agree that we need to discuss the question. > On Linux process creating is extremely fast, and we do > fork 1000s of processes while building wine, this sort > of argument is just silly. Well, it is not really the "fork" in it self that is the problem it is the overhead of loading and initializing gcc and that sort of things. > By the same rationale I suggest having a complete copy > of gcc, ld, nm, and whatever tools we use while building > wine. It is not primarily a question of having a complete copy of whatever. It is a question of having whatever accessable as functions in a library to avoid a lot of unnessary overhead. It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor. > So no, if speed is the only argument, I say we get rid > of it: it's not worth maintaining a fraction of all that > additional code. 1. Depending on "gcc -E" will make it harder to port wrc to Windows. 2. It might be less flexible (not sure though). > > And then of course using "gcc -E" would possibly cause > > a GPL violatation. Not that it would matter very much > > if wrc and friend were GPL:ed. > > WTF are you talking about?!? How did you figure this one > out? Really, this is simply false, you can fork GPL > programs all you want, and cause no GPL violation. The FSF claims that you forking and calling a GPL:ed executable is the same as linking with a GPL:ed library and calling functions in that library. This is of course absurd and would IMHO opinion nether fly in a court of law but still.... Sure wrc and friend are under a GPL compatible license (LGPL), so it wouldn't be a direct violation. However Wine has a policy that we do not link with GPL:ed libraries regardless in order to avoid possible problems for companies working with Wine so no we really can't make wrc depend of "gcc -E".

3 2

Re: Wine/FF7 midi help request
by Jeff Smith 08 Dec '02

08 Dec '02

>From: Robotech_Master <robotech(a)eyrie.org> > >On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a >discussion about midi in WINE in which FF7 was mentioned): > > > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > > modification to wine at all, and the OSS emulation of ALSA makes the > > thing transparent to WINE. > >Can you, or someone, please let me know how to set up wine to use >this? I'm running Debian Linux; these are the versions of timidity >and wine that I have: > >ii timidity 2.11.2-1.3 Software-only MIDI sequencer. >ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) This is something I would not mind knowing myself. It's not too high a priority for me though as I have SoundFonts working on my SBLive now. >For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a >Soundblaster live card. > >On the FF7 config program, it gives me the choices > > Wine OSS midi out (#0) - disabled > EMU10K1 midi This looks like what I would get from the OSS driver - emu10k1. The module name for the ALSA driver is snd-emu10k1. The choices I would expect from ALSA's OSS emulation would be something like: Emu10k1 MIDI 0-0 Emu10k1 Port 0 Emu10k1 Port 1 Emu10k1 Port 2 Emu10k1 Port 3 >Under "midi data" it gives me the choises > > General midi > Soundfont midi (Creative AWE32/AWE64) > Yamaha XG midi I would imagine this should stay on General midi unless you are *sure* it needs to be on another selection. >No matter what I try, in whatever combination, I get "Error opening >device" and the wine console says > >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel >(0x403ab930,0001003c,3):stub > >Can someone help me out--or point me at somewhere else I can find >help? Try running it like this ... wine -debugmsg +winmm,+midi,+msacm program_name.exe ... and send the output. -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

3 3

RE: wpp
by Patrik Stridvall 08 Dec '02

08 Dec '02

> Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? It is faster. Mucher faster. Using cpp/gcc -E needs to fork a new process for example. And then of course using "gcc -E" would possibly cause a GPL violatation. Not that it would matter very much if wrc and friend were GPL:ed. Obviously any GPL claim would be absurd as we discussed to death in the great licensing flamewar but still.

2 1

Re: Intel 8x0 and ALSA sound driver
by Nikolay Stefanov 08 Dec '02

08 Dec '02

On Sunday 08 December 2002 5:39 pm, Eric Pouech wrote: > which I'm say is a bad idea. the Alsa driver should report all available > drivers, and you should not be forced to define the one you want. > To be more correct, the notion of "default device" exists under windows, > but has to be handled at the wave mapper level, not at the driver level. Aha, got it. I doubt that I will be able to implement this, so I might just file it as a bug report. > that's why I say we have to remove those assertions and do proper error > handling instead > btw, if ALSA fails with an assert it's either: > - a bug in the ALSA driver > - a bug in the ALSA library > => those should be fixed (as ALSA isn't 1.0 yet, there's no need to work > around it in wine code) I had a look at mplayer code and it is structured in a completely different way than winealsa for the mmap case. I'm looking at wodPlayer_WriteMaxFrags, btw. This leads me to believe that the way wine does it is off, and it's not a driver issue... I'll try to tinker a bit with it and see whether I have any success. Nikolay

1 0

Loading Autorun.inf on CD's
by Dustin Navea 08 Dec '02

08 Dec '02

Hey guys, I was browsing through the forums on franksworld.net and noticed this post: http://www.frankscorner.org/wineforum/viewthread.php?tid=158 Now that got me thinking, wine doesnt have any method to check .inf files right now and load an installer if it finds one on a CD. I was wondering, what do you guys think it would take to get that supported? I know that we would probably have to associate .inf files with wine and/or have some sort of a wine cd detector that actively monitors cd's for autorun files, but what would need to be added to wine itself to parse an autorun file, so that we could create the loader later? -Dustin

3 5

Re: what to do with include/wine/obj_base.h?
by Jeff Smith 08 Dec '02

08 Dec '02

>From: Ove Kaaven <ovehk(a)ping.uio.no> >On 6 Dec 2002, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > 4) make widl not use macros at all, but emit full C and C++ >definitions > > > directly (this is what midl.exe does, it seems) > > > > I'd say this is the way to go if it's not too painful, it seems to be > > the most flexible. In any case obj_base.h has to go, so if we keep the > > macros they have to be put inside one of the standard headers, which > > wouldn't be very clean. > >We may have to keep the macros anyway, there are headers that use them >that can't be generated from IDL, like the DirectX headers. I suppose they >could be converted to using the MS-style objbase.h macros by perl scripts >or by rewriting them from api headers or something, but someone else would >have to take on that task, I think. > >But I'll try to add a widl header generation mode that don't use macros, >then. I don't really care whether the ICOM_ macros go or stay in the current form, but if they stay, they should at least be corrected in the following sense. Presently, a typical macro in obj_base.h is #define ICOM_METHOD4(ret,xfn,ta,na,tb,nb,tc,nc,td,nd) \ public: virtual ret CALLBACK (xfn)(ta a,tb b,tc c,td d) = 0; Note that we have na, nb, ... on the 'left' matching with a, b, ... on the 'right'. Not that this causes problems, it's just that it isn't right. And if the stuff gets stripped, it is a moot point anyway. If anyone thinks it is worth any effort, I can easily create a patch. -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

2 1

Re: wine/dlls Maketest.rules.in Makedll.rules.in
by Eric Pouech 07 Dec '02

07 Dec '02

Alexandre Julliard a écrit : > > ChangeSet ID: 6522 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/06 13:51:20 > > Modified files: > dlls : Maketest.rules.in Makedll.rules.in > > Log message: > Build test programs as part of the normal build. > > Patch: http://cvs.winehq.com/patch.py?id=6522 Alexandre, this patch is broken when building from a clean tree: - when building the tests for ntdll we need to link to kernel32 (for a cui program) which isn't built at this time - IMO, building the tests programs at the same time as the modules is a bad idea. we don't impose that tests for DLL x only depends on DLL x and DLLs built (in the wine dependency order) before x. - so, either we back up to the previous mode, or we add dependencies on test building as well A+

2 1

tools/wrc/wrc.c portability breakage
by Gerald Pfeifer 07 Dec '02

07 Dec '02

The following patch broke portability of tools/wrc/wrc.c: revision 1.18 date: 2002/12/06 19:49:36; author: julliard; state: Exp; lines: +78 -10 Dimitrie O. Paun <dpaun(a)rogers.com> Make wrc command line compatible with windres. 1) getopt() is supposed to to come from <unistd.h>, and <getopt.h> is a non-standard header. 2) getopt_long() is non-portable (and does not exist on FreeBSD, for example). The man page for getopt() clearly shows that, BTW: #define _GNU_SOURCE #include <getopt.h> Would you mind fixing this problem? Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 4

Failure running 1998-era online manual
by Dan Kegel 07 Dec '02

07 Dec '02

I grabbed Wine-20021125 and built it on my Red Hat 7.3 box. Its behavior installing http://enduser:enduser@bbs.toshiba.co.uk/file/area128/S22D95UM.ZIP (the Windows 95 version of the user manual for my 1998-era Toshiba laptop) seems much improved over May/June 2002 wine, cool! However, running the app does no better. To run the app, you do cd 'c/Program Files/DOC' wine edoc32.exe TOSHIBA.M14 On Windows, it works fine. On Wine, it displays a splash screen, then exits. Here's a partial log: 08074e50:Ret kernel32.lstrcpyA() retval=406d2dc0 ret=01643c25 08074e50:Call winmm.mmioInstallIOProcA(2034314d,01643b30,10010000) ret=01643c54 trace:mmio:MMIO_InstallIOProc (540291405, 0x1643b30, 10010000, 1) fixme:mmio:MMIO_InstallIOProc Global procedures not implemented ... 08074e50:Ret winmm.mmioInstallIOProcA() retval=01643b30 ret=01643c54 08074e50:Ret PE DLL (proc=0x1641030,module=0x1640000,type=1,res=0x1) retval=1 ... 08074e50:Starting process C:\Program Files\DOC\edoc32.exe (entryproc=0x41c9b0) ... 08074e50:Call winmm.mmioOpenA(406d2cfc "+init",00000000,00000000) ret=00405fd6 trace:mmio:MMIO_Open ('+init', (nil), 00000000, 1); 08074e50:Call ntdll.RtlAllocateHeap(40380000,00000008,0000005c) ret=40c3e59b 08074e50:Ret ntdll.RtlAllocateHeap() retval=403c42b8 ret=40c3e59b trace:mmio:MMIO_ParseExtA ("+init") err:mmio:MMIO_ParseExtA + but no . in szFileName: "+init" It sounds like mmioOpen's documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… is incomplete; it doesn't describe what the function does when there's no filename, just a +init, in the string passed to mmioOpen. I tried patching the source for MMIO_ParseExtA to assume an extension of "" in this case, but it didn't help, the program still exits. Any suggestions? - Dan

2 2

Language search order
by Shachar Shemesh 07 Dec '02

07 Dec '02

From dlls/kernel/locale.c if (GetEnvironmentVariableA( "LC_ALL", buf, sizeof(buf) ) || GetEnvironmentVariableA( "*LC_CTYPE*", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANGUAGE", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LC_MESSAGES", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANG", buf, sizeof(buf) )) Hi list, I'm trying to understand the above line of code. It would appear to me that default_lcid is used for "find resource". The manual for locale says: LC_CTYPE This changes the behaviour of the character handling and classi- fication functions, such as isupper() and toupper(), and the multi-byte character functions such as mblen() or wctomb(). Specifically, I'm looking into setting LC_CTYPE to "he_IL" so I can type Hebrew characters, while setting "LC_MESSAGE" to "C" so the messages programs issue are in English (or whatever their local setting says). It seems to me we may want to support independant settings of the two. I realize that there are places where we may want to use the information from LC_CTYPE (WideCharToMultiByte comes to mine), but I believe that we should use a different setting for that so we can allow Unix users independant control over both settings. Thoughts? Shachar

1 0

Unicode question
by Rolf Kalbermatter 07 Dec '02

07 Dec '02

Hello, In trying to get shell32 a little bit more Unicodified I came across this function ParseFieldA which is taken from shellord.c. I'm quite unfamiliar with Unicode so I still have to learn a lot. I have finally found most of the string manipulation functions which work for Unicode but when it comes down to simple character comparison I'm a little bit in the dark here. Some code snippets elsewhere in wine make me believe that for the english charset WCHAR == char is actually mostly true. However I wonder if this can be relied on in code. For instance the Unicode version of ParseField would in that case look like this but I really want the opinion of someone else on, if the code if (*src++ == ',') nField--; is actually working as expected on all systems independent of the actually used charsets for the local languages. And has anyone a good idea what the semi-stub would mean for this function? Maybe that it should ignore commas in quoted strings? /************************************************************************* * ParseFieldW [internal] * * copies a field from a ',' delimited string * * first field is nField = 1 */ DWORD WINAPI ParseFieldW(LPCWSTR src, DWORD nField, LPWSTR dst, DWORD len) { WARN("(%s,0x%08lx,%p,%ld) semi-stub.\n", debugstr_w(src), nField, dst, len); if (!src || !src[0] || !dst || !len) return 0; /* skip n fields delimited by ',' */ while (nField > 1) { if (*src == 0x0) return FALSE; if (*src++ == ',') nField--; } /* copy part till the next ',' to dst */ while ( *src != 0x0 && *src != ',' && (len--)>0 ) *(dst++) = *(src++); /* finalize the string */ *dst = 0x0; return TRUE; } Rolf Kalbermatter

4 3

RE: Let --disable-debug actually do something
by Medland, Bill 07 Dec '02

07 Dec '02

> -----Original Message----- > From: Alexandre Julliard [mailto:julliard@winehq.com] > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. Oh. So how is setting --disable-debug supposed to result in the FIXMES being compiled out? I just don't understand what is supposed to be happening here; all I know is that it isn't working. (Or is that not what it is supposed to do?) a) --disable-debug results in the settings in config.h changing. b) wine/debug.h tests that setting that becomes defined in config.h, in order to reduce FIXME to a basically null statement. c) dlls/user/hook.c, for example, includes a FIXME statement. neither hook.c nor debug.h include config.h so if I insert #ifndef NO_DEBUG_MSGS #error I was right #endif just before the fixme of NotifyWinEvent then it tells me I am right. I can only think of two ways that setting --disable-debug could be expected to result in the FIXMES being compiled out (which I presume is what is supposed to happen). Either it is supposed to result in a change to the makefiles so the -D NO_DEBUG_MSGS gets specified (and I see no indication of that) or else it results in a #define NO_DEBUG_MSGS at a suitable point that comes before it is actually needed (which appears to be the intention). So I presume that the problem is that config.h is not being included before its contents are needed. So the question is where should it be included. One solution would be to include it explicitly in every file that includes a WARN, FIXME or TRACE. Do you really want that? The other is to include it in the file that uses it (viz. debug.h). So tell me why I am an idiot and what solution you want me implement. I guess the simplest would be to drop --disable-debug from the configure. > > -- > Alexandre Julliard > julliard(a)winehq.com > Bill Medland

4 3

Where to use dosdev
by György 'Nog' Jeney 07 Dec '02

07 Dec '02

In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.

2 3

small updates to debugger.sgml
by Tony Lambregts 07 Dec '02

07 Dec '02

Before I could feel right about adding "Advanced Debugging Techniques" to the documnetation I needed to update the documentation on the debugger. There is still one section that is out of date (that I am aware of). The section that I am refering to is as follows > Program hangs, nothing happens > > Switch to UNIX shell, get the process-ID using ps -a | grep wine, and > do a kill -HUP <pid> (without the < and >). Wine will then enter its > internal debugger and you can proceed as explained above. Also, you > can use --debug switch and then you can get into internal debugger by > pressing Ctrl-C in the terminal where you run Wine. > This is _wrong_ since neither work. I have added a fix me message in front of this since I am unable to come up with anything usefull to replace it. If anyone has a usefull suggestion I would appreciate it. Change log: Update the debugger documentation for current usage. Files: /documnetation/debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.13 diff -u -r1.13 debugger.sgml --- debugger.sgml 1 Oct 2002 18:13:09 -0000 1.13 +++ debugger.sgml 29 Nov 2002 06:08:53 -0000 @@ -271,8 +271,9 @@ <para> This file describes where to start debugging Wine. If at any point you get stuck and want to ask for help, please read the - file <filename>documentation/bugreports</filename> for - information on how to write useful bug reports. + <emphasis>How to Report A Bug</emphasis> section of the + <emphasis>Wine Users Guide</emphasis> for information on how to write + useful bug reports. </para> <sect2> @@ -311,8 +312,7 @@ <para> Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information - gathered to the newsgroup or the relevant developer as - feasible. + gathered to the bug report as feasible. </para> <orderedlist> @@ -362,17 +362,26 @@ If you have found a misbehaving function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is - a <function>TRACE(<channel>,"(...)\n");</function> at - the beginning of the function. Rerun wine with + a <function>WINE_DEFAULT_DEBUG_CHANNEL(<channel>);</function> + at the beginning of the file. Rerun wine with <parameter>-debugmsg +xyz,+relay</parameter> added to the commandline. </para> + <para> + Occasionally there are additional debug channels defined at the + begining of the file in the form. + <function>WINE_DECLARE_DEBUG_CHANNEL(<channel>);</function> + If so the offending fuction may also uses one of these alternate + channels. Look through the the function for + <function>TRACE_(<channel>)(" ... /n");</function> and add any + additional channels to the commandline. + </para> </listitem> <listitem> <para> Additional information on how to debug using the internal debugger can be found in - <filename>debugger/README</filename>. + <filename>programs/winedbg/README</filename>. </para> </listitem> <listitem> @@ -386,29 +395,25 @@ </listitem> <listitem> <para> - If even that isn't enough, add more debug output for - yourself into the functions you find relevant. See - <filename>documentation/debug-msgs</filename>. You might + If even that isn't enough, add more debug output for yourself + into the functions you find relevant. See The section on Debug + Logging in this guide for more information. You might also try to run the program in <command>gdb</command> instead of using the WINE-debugger. If you do that, use <parameter>handle SIGSEGV nostop noprint</parameter> to disable the handling of seg faults inside - <command>gdb</command> (needed for Win16). If you don't use - the <parameter>--desktop</parameter> or - <parameter>--managed</parameter> option, start the WINE - process with <parameter>--sync</parameter>, or chances are - good to get X into an unusable state. + <command>gdb</command> (needed for Win16). </para> </listitem> <listitem> <para> - You can also set a breakpoint for that function. Start wine - with the <parameter>--debug</parameter> option added to the - commandline. After loading the executable wine will enter - the internal debugger. Use <parameter>break - KERNEL_LSTRLEN</parameter> (replace by function you want - to debug, CASE IS RELEVANT) to set a breakpoint. Then use - <command>continue</command> to start normal + You can also set a breakpoint for that function. Start wine + useing <command>winedbg</command> instead of + <command>wine</command>. Once the debugger is is running enter + <command>break</command> <parameter>KERNEL_LSTRLEN</parameter> + (replace by function you want to debug, CASE IS RELEVANT) + to set a breakpoint. Then + use <command>continue</command> to start normal program-execution. Wine will stop if it reaches the breakpoint. If the program isn't yet at the crashing call of that function, use <command>continue</command> again @@ -425,6 +430,7 @@ <title>Program hangs, nothing happens</title> <para> + <emphasis>Fix me - this is out of date </emphasis> Switch to UNIX shell, get the process-ID using <command>ps -a | grep wine</command>, and do a <command>kill -HUP <pid></command> (without the < and >). Wine will @@ -449,8 +455,7 @@ </para> <para> Since the failure happens usually directly before setting up - the Messagebox you can start wine with - <parameter>--debug</parameter> added to the commandline, set a + the Messagebox you can start winedbg and set a breakpoint at <function>MessageBoxA</function> (called by win16 and win32 programs) and proceed with <command>continue</command>. With <parameter>--debugmsg

2 3

Re: Some fixes in capabilities
by Andreas Mohr 07 Dec '02

07 Dec '02

On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote: > Hi all, > > As long as we do not support multi-texturing in our D3D driver, fill the > caps properly. Now SS2 does not try to do multitexturing anymore (not that > it actually works now, it's just that it would break less :-) ). > > Note: is there a way from DLL X to activate relay debugging ? What happens > is that SS2 somehow freezes at one point and doing a relay trace from > the start is about a 3 GB file... So what I would like to do is at a > specific function in the D3D code that I know to be just before the > freeze, call 'activate relay' and voila, I have relaying on :-) (to be > able to do that for all DLLs would be even better). > > But well, considering DLL separation and all that, I doubt that this > would be possible :-/ Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-) Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :) Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

7 8

Regression in wineconsole
by Tony Lambregts 07 Dec '02

07 Dec '02

Lately I have been having a problem with wineconsole spitting out the following errors and failing to load. err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting I had the stock RedHat 7.2 fonts loaded as well as the stock ms-windows when I first got this error. Now I have installed the XFree86 font from Ximian and it still cannot find a "decent" font. At this point with several hundred fonts to choose from I am suprised that it could not find one that it liked. In the past (upto the middle of November) wineconsole was quite happy with "clean 10". Does anyone have a suggestion on what should I do. -- Tony Lambregts

2 3

[RFC] winewrap
by Dimitrie O. Paun 07 Dec '02

07 Dec '02

Hi folks, Here is the first cut at winewrap, as described here: http://www.dssd.ca/wine/Winelib-Apps.html What it does at the moment: -- invokes winebuild to create the .spec.c file -- compiles the .spec.s file -- links in everything, and generates the .exe.so file What remains to be done: -- generate the actual executable. One possible option is to modify wineapploader so we simply symlink to it. I have a version of this around. Is this acceptable? Comments welcomes. /* * Wine wrapper: takes care of internal details for linking. * * Copyright 2002 Dimitrie O. Paun * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include "wine/port.h" #include <stdio.h> #include <string.h> #include <stdarg.h> #include <stdlib.h> #include <sys/param.h> #include <sys/wait.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #ifndef WINEDLLS #define WINEDLLS "/usr/local/lib/wine" #endif static char *output_name; static char **lib_files, **res_files, **obj_files; static int nb_lib_files, nb_res_files, nb_obj_files; void error(const char *s, ...) { va_list ap; va_start(ap, s); fprintf(stderr, "Error: "); vfprintf(stderr, s, ap); fprintf(stderr, "\n"); va_end(ap); exit(2); } char *strmake(const char *fmt, ...) { int n, size = 100; char *p; va_list ap; if ((p = malloc (size)) == NULL) return NULL; while (1) { va_start(ap, fmt); n = vsnprintf (p, size, fmt, ap); va_end(ap); if (n > -1 && n < size) return p; if (n > -1) size *= 2; if ((p = realloc (p, size)) == NULL) return NULL; } } void spawn(char *const argv[]) { int pid, status, i; for(i = 0; argv[i]; i++) printf("%s ", argv[i]); printf("\n"); if ((pid = fork()) == 0) execvp(argv[0], argv); else if (wait(&status) > 0) { if (WEXITSTATUS(status) == 0) return; else error("%s failed.", argv[0]); } perror(0); exit(1); } int main(int argc, char **argv) { char *library = 0; int i, j, len, is_object, no_opt = 0; char cmd[PATH_MAX]; char **spec_args, **comp_args, **link_args; for (i = 1; i < argc; i++) { if (!no_opt && argv[i][0] == '-') { switch (argv[i][1]) { case 'o': if (argv[i][2]) output_name = strdup(argv[i]+ 2); else if (i + 1 < argc) output_name = strdup(argv[++i]); else error("The -o switch takes an argument\n."); len = strlen(output_name); if (len > 4 && strcmp(output_name + len - 4, ".exe") == 0) output_name[len - 4] = 0; break; case 'l': if (argv[i][2]) library = argv[i]+ 2; else if (i + 1 < argc) library = argv[++i]; else error("The -l switch takes an argument\n."); if (strcmp(library, "winspool") == 0) library = "winspool.drv"; lib_files = realloc( lib_files, (nb_lib_files+1) * sizeof(*lib_files) ); lib_files[nb_lib_files++] = strdup(library); break; case '-': if (argv[i][2]) error("No long option supported\n"); no_opt = 1; break; default: error("Unknown option -%c\n", argv[i][1]); } continue; } /* it's a filename, not an option: test if it is a resource */ snprintf(cmd, sizeof(cmd), "readelf -V %s >/dev/null 2>/dev/null", argv[i]); is_object = (system(cmd) == 0); /* add it to its respective list */ if (is_object) { obj_files = realloc( obj_files, (nb_obj_files+1) * sizeof(*obj_files) ); obj_files[nb_obj_files++] = strdup(argv[i]); } else { res_files = realloc( res_files, (nb_res_files+1) * sizeof(*res_files) ); res_files[nb_res_files++] = strdup(argv[i]); } } /* build winebuild's argument list */ spec_args = malloc( (nb_lib_files + nb_obj_files + nb_res_files * 2 + 20) * sizeof (char *) ); j = 0; spec_args[j++] = "winebuild"; spec_args[j++] = "-fPIC"; spec_args[j++] = "-o"; spec_args[j++] = strmake("%s.spec.c", output_name); spec_args[j++] = "--exe"; spec_args[j++] = strmake("%s.exe", output_name); spec_args[j++] = "-m"; spec_args[j++] = "gui"; for (i = 0; i < nb_res_files; i++) { spec_args[j++] = "-r"; spec_args[j++] = res_files[i]; } for (i = 0; i < nb_obj_files; i++) spec_args[j++] = obj_files[i]; spec_args[j++] = "-L" WINEDLLS; for (i = 0; i < nb_lib_files; i++) spec_args[j++] = strmake("-l%s", lib_files[i]); spec_args[j++] = "-lmsvcrt"; spec_args[j] = 0; /* build gcc's argument list */ comp_args = malloc (20 * sizeof (char *) ); j = 0; comp_args[j++] = "gcc"; comp_args[j++] = "-fPIC"; comp_args[j++] = "-c"; comp_args[j++] = strmake("%s.spec.c", output_name); /* build ld's argument list */ link_args = malloc( (nb_obj_files + 20) * sizeof (char *) ); j = 0; link_args[j++] = "gcc"; link_args[j++] = "-shared"; link_args[j++] = "-Wl,-Bsymbolic"; link_args[j++] = "-lwine"; link_args[j++] = "-lm"; link_args[j++] = "-o"; link_args[j++] = strmake("%s.exe.so", output_name); link_args[j++] = strmake("%s.spec.o", output_name); for (i = 0; i < nb_obj_files; i++) link_args[j++] = obj_files[i]; link_args[j] = 0; /* run winebuild to get the .spec.c file */ spawn(spec_args); /* compile the .spec.c file */ spawn(comp_args); /* run gcc to link */ spawn(link_args); return 0; } -- Dimi.

2 11

Janitorial Projects -- conformance tests --recruiting volunteers
by Tom Wickline 07 Dec '02

07 Dec '02

We still need Win-95, Win-98SE, WinME, WinXP testers if anyone would like to Volinteer :)) If your new here and would like to help out this is a great way to get started.. You dont have to be a *programmer* And in the end your contribution will help out. I also think *someone* should make a list of all NON-PROGRAMING task that could be done by non programmers!!! And ask for Volunteers / Helpers There are many points of entry in any project.. We need to recruit Graphics Pro's to help this project as well !! Why ?? This would save the programmers alot of time... If others were doing these task. And they could do more important tasks. Just you $.02 Tom

1 0

Re: Registering DLL's
by Jaco Greeff 07 Dec '02

07 Dec '02

On Sat, 7 Dec 2002 01:13:53 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > Cool. Any other details other than "a bit further"? :))) > Like a ETA for a preview version, or something to be > integrated into the tree? *grin* I don't mind ETA's, it helps me focus. Second week in Jan 2003 for a preview and some serious feedback. I've only got about 4 days left before taking a bit of a break hence the longinsh delay. I've wanted to be quite a bit further along and have something out there by now, but this is problably better - it allows me to give serious attention to the feedback in Jan. Greetings, Jaco

1 0

Re: Registering DLL's
by Jaco Greeff 07 Dec '02

07 Dec '02

On Fri, 6 Dec 2002 10:32:45 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > On December 6, 2002 10:18 am, you wrote: > > You guys have got the ReactOS regedit based on Wine Regedit although it is > > read only atm. If someone is still planning on adopting it, then that will > > solve this part of the problem. > > Jaco was working on a cool too, I don't know what the status of that is: It is a bit further that the last staus update, we will need to see how it evolves as the configuration moves into the registry. Greetings, Jaco

2 1

RE: Cabinet FDICreate()
by Patrik Stridvall 06 Dec '02

06 Dec '02

> The MSXML4 .msi package dies with : > > fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, > 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub > > Is this scheduled to be implemented as part of the cabinet merge in > work? IIRC Greg Turner volunteer to do it however, also said I might take a while before getting around to do it. I, who did the stub, personally, haven't got much time to do it either. So don't hold you breath, unless you volunteer. Implementing it is not that hard I think especially since we got cabextract licensed under the LGPL for us. If not, install and use the native cabinet.dll instead.

2 1

RE: Let --disable-debug actually do something
by Medland, Bill 06 Dec '02

06 Dec '02

-----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. And why is the header that defines FIXME an installed include anyway? > > -- > Alexandre Julliard > julliard(a)winehq.com > >

1 0

re: Dll separation question
by Dan Kegel 06 Dec '02

06 Dec '02

Martin.Wilck(a)fujitsu-siemens.com wrote: > when writing code for DLL X, which functions from other DLLs may I call? As a Wine outsider, let me make a wild guess: To a first approximation, a nice way of thinking about it might be Write new DLLs using only published Microsoft APIs already implemented in other Wine DLLs. Ideally, new DLLs would work as replacements if compiled and run on a real Windows box. (although of course a whole lot of DLLs probably can't meet that strict definition.) - Dan

2 1

Re: FW: shell32.SHDefExtractIcon implementation take
by Uwe Bonnes 06 Dec '02

06 Dec '02

>>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: +/**************************************************************************** + * SHDefExtractIconW [SHELL32.@] + */ +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) +{ + UINT ret; + HICON hIcons[2]; ^^^^^^^^ + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); + + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, nIconSize, h\ Icons, NULL, 2, LR_DEFAULTCOLOR); + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ + if (ret == 0xFFFFFFFF) + return E_FAIL; + if (ret > 0) { + *phiconLarge = hIcons[0]; ^^^^^^^^^^^^ Rolf, this doesn't look right to me: You allocate space on the function local stack, then hand out a pointer to that memory and return from the function. No the function local stack is undefined and the pointers are dangling. I think the heap should be used for allocating the needed storage. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Let --disable-debug actually do something
by Alexandre Julliard 06 Dec '02

06 Dec '02

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 -0000 1.5 > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > @@ -23,6 +23,7 @@ > > #include <stdarg.h> > #include "windef.h" > +#include "config.h" You can't do that, installed includes shouldn't depend on config.h. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [RESENT] Batch support for CreateProcess (2 of 3)
by Alexandre Julliard 06 Dec '02

06 Dec '02

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > --- wine/programs/wcmd/builtins.c 24 Jul 2002 19:00:25 -0000 1.15 > +++ wine/programs/wcmd/builtins.c 6 Dec 2002 14:04:02 -0000 > @@ -406,7 +406,7 @@ > return; > } > if (test != negate) { > - WCMD_parameter (p, 2+negate, &s); > + WCMD_parameter (p, 2+negate+test, &s); This doesn't look right. The number of parameters doesn't depend on the result of the test. -- Alexandre Julliard julliard(a)winehq.com

1 0

Janitorial Projects
by Dimitrie O. Paun 06 Dec '02

06 Dec '02

Folks, I have updated the Janitorial section: http://www.dssd.ca/wine/Wine-Fun.html#janitorial with the list of cross calls from 32->16, and W->A. There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII. Any takers? :) -- Dimi. P.S. If you do work on some of those, let me know so I can put your name there, and mark what's being worked on, do we can avoid duplicated effort.

6 17

how to switch between threads
by Rajesh Akkineni 06 Dec '02

06 Dec '02

Hi, I am debugging wine with MS Media Player. Some places the program is blocking with som 7 to 8 threads opened. They are all waiting for a some event(ConnectNamedPipe) But i think there should be another thread with will Create the file or NamedPipe. So How can i see where the other threads are when i set a break point in a perticular method. How dose debuggers handle MultiThreaded Applications? Can i Shit to different Thread to exmine where is it when the program Halted? Thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

RE: strcat+strcat+strcat == baaad"
by vkxzjq6lg＠cswebmail.com 06 Dec '02

06 Dec '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. You're right in theory but you're partly wrong in practice. Some time back I changed a shared library which had been used by ten or so developers for about eight years. I changed all possible unspecified length string copies and concatenates to versions with length limits. The programs using the library crashed less and displayed bad output less. Nobody noticed any speed change there might have been. We all had access to all of the source code involved and none of it was deliberately hostile to the library. The changes caught things the application programmers had missed in their testing and odd or corrupt data which ended up in the databases and made them less harmful. It was then also easier to follow up and fix "the program displayed xyz trash here" than it was to fix "my PC crashed" or "your program died". As programmers we all try to follow the limits and take care with buffer sizes and lengths and validation. We all fail and we all fail to catch every time we fail. That's just the nature of bugs and what we do. Buffer length issues are particularly hard to find and no realistic testing for a project the size of wine will catch them all. Wine also needs to remember that hostile Windows program developers may deliberately try to break programs under wine by passing invalid parameters. Even if wine doesn't check all of those, it shouldn't die when it happens. At least one company has an interest in breaking wine when running its programs and coding defensively is a prudent thing. Performance is unknown and won't be known until any possible shared function is implemented. Just announce it with the length parameter and do it with a define. Let the person who implements it decide whether to use strcat, strlcat or whatever in the first implementation, a function or inline or whatever. Six months or a year from now someone can try different implementations to see whether there is a speed difference. Then they can do something about selecting the most efficient. It's an issue, so deal with it, but there's no way to know today which will be the best implementation because it depends on the data and it is obvious that nobody knows the data well enough to be certain which will work best. If you don't like the strlcat implementeation, then you can try it with strcat and tell everyone how much faster it is when the l is ignored. Or not. Even if the l is eventually ignored in production, having it around offers the opportunity to turn it on with a compile option and/or to use it for assert sanity checking in a debug build. Finally, hi.:) Just started monitoring this list because I'm helping to get a Windows application (OzWin) working under wine. James Day ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

3 2

Registering DLL's
by Jeff Smith 06 Dec '02

06 Dec '02

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]" Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg. About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions. Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way. -- Jeff S _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

4 4

Cabinet FDICreate()
by Mike Hearn 06 Dec '02

06 Dec '02

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: wine/tools Makefile.in .cvsignore mingwrap.c
by Dimitrie O. Paun 06 Dec '02

06 Dec '02

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

1 0

Re: Loading Autorun.inf on CD's
by Dustin Navea 06 Dec '02

06 Dec '02

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

1 0

[Alsa] A simple test for IDirectSound.GetCaps.
by Sylvain Petreolle 06 Dec '02

06 Dec '02

Running the dsound test using winealsa.drv, the program hangs and try to call the debugger. [syl@snoop dsound]$ make test make[1]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400bb478 make[1]: Quitte le répertoire `/home/wine/dlls/dsound/tests' According to http://www.delphifaq.com/fq/q1061.shtml, exception c0000194 is STATUS_POSSIBLE_DEADLOCK. How could I debug the tests ? ===== 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. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

WineBuild/WineLib <-> MFC
by jaymz＠free.fr 05 Dec '02

05 Dec '02

Going further into the MFC dll handling, I raised the following issue: I have two dynamic libs (mfc.dll.so and myapp.dll.so), both loaded by the wrapper (myapp.exe.so). The problem is that global or static class variables are badly exported from mfc.dll.so to myapp.dll.so. Here's an example: In mfc.dll.so, let assume that I export a global integer variable named myVar. I add @ extern myVar myVar in mfc.dll.spec. When I do a GetProcAddress of myVar from the wrapper, the returned address is good, but when I link my application, myVar is undefined (WineBuild did not include it in myapp.dll.spec.c). If I add instead in the spec file something like @ stdcall myVar() myVar, it's still good when using GetProcAdress, I can now link my application, but at runtime, the address of the variable is not the good one, so I'm using corrupted data ! Therefore, when the app runs, all static data are in fact not or badly initialized and it crashes. What's the exact syntact to correctly export class static variable from a dll ? Thanks a lot for your attention.

2 1

[RFC] wrc & windres
by Dimitrie O. Paun 05 Dec '02

05 Dec '02

Hi folks, As we discussed here a few weeks ago, there is good reason to have a windres compatible mode for wrc. Needless to say, this will greatly ease porting apps that use windres to Winelib. More information about the issues at hand can be found in this thread: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html That being said, what would it take to (1) keep the current wrc behavior, and (2) make it compatible with windres? First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc -> .res. It would be interesting (from the Winelib point of view) to also support .rc and .res -> .o. The other transformations supported by windres (.o -> .res -> .rc) are not as interesting, as they are not used in the build process. With that in mind, what do we need to do to have said compatibility? Well there are two things: 1. Support windres command line options 2. Add conversion of .rc and .res to .o I will treat each of these below. Command line compatibility -------------------------- Luckily, there is only one (seldom used) option that conflicts: -I. Moreover, it has a long format name in windres as well, which can be used instead. In other words, it should be very simple to add support for the windres options to wrc (most of them will just get ignored). In other words we can support windres's options while keeping full backwords compatibility. Having this compatibility makes sense as long as we support the conversion to .o files as well. Assuming we can do that, I would say this is something we should have. Conversion to .o files ---------------------- As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html generating .o files in proper format is non-trivial. And since I'm willing to do the work, there's no chance I'm going to propose something difficult to implement! :) What I have in mind is quite simple: store the .res file, as a byte array, in a .wine.resources ELF section, and have winebuild pick it up from there (as an alternative to getting it directly from the .res file, so current behavior is conserved). With these two changes, we eliminate the biggest nastiness of getting apps compiled with Winelib. The modification will typically be: -WINDRES=windres +WINDRES=wrc Moreover, the solution is: o Simple to implement o Fully backwards compatible with current Wine practice o Fully compatible with Win32 apps using the MinGW toolchain o Supports multiple resource files, etc. So now the big question: Alexandre, are patches that implement these ideas acceptable? Sorry for the long message, and thanks for reading this far. -- Dimi.

3 6

Re: [RFC] wrc & windres
by Jeff Smith 05 Dec '02

05 Dec '02

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> >Hi folks, > >As we discussed here a few weeks ago, there is good reason >to have a windres compatible mode for wrc. <snip> >That being said, what would it take to (1) keep the current wrc >behavior, and (2) make it compatible with windres? Here is an alternative idea for dealing with command-line incompatibility: create a link 'windres' pointing to 'wrc'. In the program, we could determine how the program was invoked and handle the command-line options accordingly. This should technically work, unless we find some reason to 'mix' command line options, in which case we we would have to start 'blending' the two syntaxes. Please note that I am not familiar with the command line options of either program. <snip> >The modification will typically be: >-WINDRES=windres >+WINDRES=wrc WINDRES would not have to be changed using this method. -- Jeff S. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

3 2

Re: possible memory corruption
by steve.lustbader＠philips.com 05 Dec '02

05 Dec '02

>>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: > > steve> When I try to load a window in my app that has a treeview in it, > steve> it crashes immediately, before the window even gets displayed. > steve> This is the end of the backtrace: > > Try running with native commctrl to see if the corruption comes from our > commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will > check on every heap manipulation to see if the heap is still okay. Then >look what corrupted the heap. It works fine with a native (WinXP) comctl32.dll. I'll post the +relay,+heap output shortly. -Steve

1 0

possible memory corruption
by steve.lustbader＠philips.com 05 Dec '02

05 Dec '02

When I try to load a window in my app that has a treeview in it, it crashes immediately, before the window even gets displayed. This is the end of the backtrace: 0x400d6377 (HEAP_FindFreeBlock+0x3b [heap.c:608] in libntdll.dll.so): movl 0x0(%edx),%eax 608 DWORD arena_size = (pArena->size & ARENA_SIZE_MASK) + Wine-dbg>bt Backtrace: =>0 0x400d6377 (HEAP_FindFreeBlock+0x3b(heap=0x41230000, size=0x108, ppSubHeap=0x406e1af4) [heap.c:608] in libntdll.dll.so) (ebp=406e1adc) 1 0x400d6df5 (RtlAllocateHeap+0x71(heap=0x41230000, flags=0xa, size=0x104) [heap.c:1028] in libntdll.dll.so) (ebp=406e1b04) 2 0x40b283e2 (COMCTL32_Alloc+0x4a(dwSize=0x104) [comctl32undoc.c:352] in comctl32.dll.so) (ebp=406e1b24) 3 0x40b732bb (TREEVIEW_UpdateDispInfo+0x227(infoPtr=0x41230838, wineItem=0x41232060, mask=0x1) [treeview.c:762] in comctl32.dll.so) (ebp=406e1ba4) 4 0x40b73d94 (TREEVIEW_InsertItemA+0x324(infoPtr=0x41230838, lParam=0x406e1be8) [treeview.c:1318] in comctl32.dll.so) (ebp=406e1bd8) 5 0x40b73eb6 (TREEVIEW_InsertItemW+0xb2(infoPtr=0x41230838, lParam=0x406e1f08) [treeview.c:1389] in comctl32.dll.so) (ebp=406e1c34) 6 0x40b79881 (TREEVIEW_WindowProc+0x6a5(hwnd=0x2006a, uMsg=0x1132, wParam=0x0, lParam=0x406e1f08) [treeview.c:5237] in comctl32.dll.so) (ebp=406e1c50) 7 0x408ec923 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406e1c74) 8 0x408ec9ae (WINPROC_CallWndProc+0x82(proc=0x40b791dc, hwnd=0x2006a, msg=0x1132, wParam=0x0, lParam=0x406e1f08) [winproc.c:183] in user32.dll.so) (ebp=406e1ca4) I had thought originally that it might be a treeview problem, since the crash happens based on calls from treeview, but Dimi says that it's probably memory getting corrupted somewhere. What trace would be helpful to debug this? Thanks, Steve, PS - I had previously posted a +treeview trace a couple of weeks ago. Here it is again, just in case it's helpful: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger...

2 1

valgrind and wine
by Dan Kegel 05 Dec '02

05 Dec '02

valgrind wine reports: ==6476== Valgrind detected that your program requires ==6476== the following unimplemented functionality: ==6476== modify_ldt(): I (JRS) haven't investigated this yet; sorry. ==6476== This may be because the functionality is hard to implement, ==6476== or because no reasonable program would behave this way, ==6476== or because nobody has yet needed it. In any case, let me know ==6476== (jseward(a)acm.org) and/or try to work around the problem, if you can. Dang. - Dan

3 4

RE: Remnants of -DSTRICT Conversion
by Patrik Stridvall 05 Dec '02

05 Dec '02

> Just a small request. Could someone write a script that would > remove one of > the last remnants of the -DSTRICT conversion. It is a little > issue with lots > of 0x%p's everywhere (mainly in NTDLL registry functions) > which need to be > replaced by just %p's. Sure here is the script: find . -name \*.c | xargs perl -i -pe 's/0x%p/%p/g' and as a bonus to Alexandre here is the patch. --8<--- *** strict * dlls/commdlg/filedlg95.c, dlls/ntdll/file.c, dlls/ntdll/heap.c, dlls/ntdll/misc.c, dlls/ntdll/nt.c, dlls/ntdll/om.c, dlls/ntdll/reg.c, dlls/ntdll/sec.c, dlls/ntdll/sync.c, loader/module.c, scheduler/process.c, scheduler/thread.c, win32/device.c: Replace 0x%p with %p.

1 0

Remnants of -DSTRICT Conversion
by Robert Shearman 05 Dec '02

05 Dec '02

Hi all, Just a small request. Could someone write a script that would remove one of the last remnants of the -DSTRICT conversion. It is a little issue with lots of 0x%p's everywhere (mainly in NTDLL registry functions) which need to be replaced by just %p's. Thanks, Rob

1 0

Use COMSPEC command interpreter to run .bat files.
by Sylvain Petreolle 05 Dec '02

05 Dec '02

Is your patch allowing the run of .bat files by wine itself, or only a W-process ? When I try it on command line I have this : [syl@snoop cygwin]$ wine cygwin.bat --debugmsg +process trace:process:PROCESS_InitWine starting process name="" file=(nil) argv[0]="cygwin.bat" trace:process:find_exe_file looking for "cygwin.bat" trace:process:find_exe_file Trying built-in exe "C:\\cygwin\\cygwin.bat" trace:process:find_exe_file Trying native exe "C:\\cygwin\\cygwin.bat" wine: cannot determine executable type for 'C:\cygwin\cygwin.bat' [syl@snoop cygwin]$ cat cygwin.bat @echo off C: chdir \cygwin\bin bash --login -i ===== 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. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

5 14

Wine Janitorial Projects
by Dimitrie O. Paun 04 Dec '02

04 Dec '02

Hi folks, The Wine Janitorial Project section has grown to the point where a separate page is warranted. It's been *greatly* enhanced, hopefully making the tasks a lot more explicit, easier to understand, and track. The first release of this page is available at: http://www.dssd.ca/wine/Wine-Janitorial-0.1.html As you are probably used to by now, the working version can be found here: http://www.dssd.ca/wine/Wine-Janitorial.html Please feel free to suggest new projects for the list. There are many things to cleanup in the tree, and having them available on an easy to read page increase the changes of (1) someone picking them up, and (2) us not forgeting them. So let me know if you come across anything that you feel should be on the list. Also, if you're working on something big, I can mark your name there so we can avoid duplicated work. Last but not least, there are a lot of small, self contained, and easy to get into tasks listed there. If you feel like getting your feet a bit wet in Wine development, this is an ideal opportunity to start, and get to know the project a little better. Just ask for help if you are new, and would like some help to get you started. -- Dimi.

2 2

Re: rpc_J_PL4
by Greg Turner 04 Dec '02

04 Dec '02

On Wednesday 04 December 2002 02:31 am, Francois Gouget wrote: > On Wed, 4 Dec 2002, Greg Turner wrote: > [...] > > > Anyhoo, yes, I like something like what you are doing better, it > > seems that if anything might just break out of the blue, it would > > be the unicode version, right? So I should have done more like > > that and that way wine doesn't lose the test. knowing there's no > > crash involved makes the difference, I guess. > > Submitting for inclusion then :-) well, if it doesn't crash, I say we'd might as well run the tests but show traces instead of "ok"'s on failure.... I really wish there was a "whatever" macro that took the same syntax as "ok" but didn't constitute failure (or is there? perhaps I should make one?) Anyhow, until I make my mind up or whatever, Francois' patch is fine by me, considered rpc_J_PL4-r0 if it's OK to call it X11. -gmt

2 1

Re: Registering DLL's
by Jeff Smith 04 Dec '02

04 Dec '02

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On December 4, 2002 01:36 pm, Jeff Smith wrote: > > Does anyone have any better ideas on what the "Right Way" to tackle > > this item is? I am sure that adding external functions that do not > > exist in native versions is *not* the way. > >This was Alexandre's idea. Alexandre, a more detailed brain dump on >the configuration stuff would be useful. For example: > >C.1 Merge configuration into the registry > >Any gochas? What would it take? > >C.5 Make Wine's DLLs register themselves to avoid manual merging of the >winedefault.reg > >How should this be implemented? See Jeff's questions. > >C.6 Write wine.inf script to setup a new Wine installation > >Do we have the code that executes .inf scripts? Is this one >just a matter of writing the scripts? > >-- >Dimi. For those interested, here are a couple of links relating to the INF file format (1), and the SetupAPI (2). I don't know how complete our implementation is, but it can be found under wine/dlls/setupapi. 1.) http://msdn.microsoft.com/library/en-us/install/hh/install/create-inf_4l47.… 2.) http://msdn.microsoft.com/library/en-us/install/hh/install/setupapi_2faf.asp -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

what happened wineboot?
by Matthew Davison 04 Dec '02

04 Dec '02

I have been trying to get programs installed which place entries in RunOnce. I read a while ago about a wineboot program which automates these jobs, thus simulating a reboot, similar to what crossover does. Does anyone have such a program, as I have been looking for it and cant find it. -- Matthew Davison <m.davison(a)virgin.net>

2 1

Re: Dll separation question
by Rolf Kalbermatter 04 Dec '02

04 Dec '02

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> wrote: >I am sorry to say that I still don't quite understand this issue, but - >can anybody point me to a resource saying what exactly I may or may not >do when writing code for a wine DLL? In particular, when writing code >for DLL X, which functions from other DLLs may I call? This interests me as well! >Example: When writing netapi32 code, can I call advai32 Registry >functions to obtain config options, or do I need to use the (IMO rather >awkward) ntdll interface ? I was under the impression that the main issue was that no DLL calls not officially exported functions in any other DLL, with officially exported meaning any function which is not wine specific eg. is also exported by the according MS Windows DLL. I have gotten the impression that all Wine specific exports start with the uppercase name of the DLL which implements them followed by an underscore and then the actual name and the main and final target is to get rid of any and all exports of such functions. So in general I would think that usage of the Reg.. functions from ADVAPI32 should be ok, but I'm not familiar with NETAPI32 at all and how it relates to the rest of Win. Maybe it is more considered part of the actual Win kernel and therefore should maybe call the Nt... functions in NTDLL. But the Reg... functions are really just a convinience wrapper around the according Nt... functions and ADVAPI32 is certainly a well known standard DLL. >Btw: Dll separation is a really complex issues and I think I'm not the >only one who feels he doesn't quite understand what it means. IMO winehq >needs a very clear description of that somewhere where it's easy to find. Some documentation or a link to them would certainly help. Rolf Kalbermatter

1 0

Dll separation question
by Martin Wilck 04 Dec '02

04 Dec '02

I am sorry to say that I still don't quite understand this issue, but - can anybody point me to a resource saying what exactly I may or may not do when writing code for a wine DLL? In particular, when writing code for DLL X, which functions from other DLLs may I call? Example: When writing netapi32 code, can I call advai32 Registry functions to obtain config options, or do I need to use the (IMO rather awkward) ntdll interface ? Btw: Dll separation is a really complex issues and I think I'm not the only one who feels he doesn't quite understand what it means. IMO winehq needs a very clear description of that somewhere where it's easy to find. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Painting message order?
by Mike Hearn 04 Dec '02

04 Dec '02

Hi all, My beloved SVG plugin broke again :( For some reason it's not repainting properly, in fact, the only way I can force it to repaint when running in wine desktop, internet explorer kiosk mode (ie it fills a window) is by toggling high quality/low quality which controls antialiasing. trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT sent from self wp=00000001 lp=00000000 trace:message:SPY_EnterMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] wp=00000001 lp=00000000 trace:message:SPY_ExitMessage (0x10041) DefWindowProc32: WM_NCPAINT [0085] returned 00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0085] WM_NCPAINT returned 00000000 trace:message:SPY_EnterMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND sent from self wp=000008a8 lp=00000000 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [0014] WM_ERASEBKGND returned 00000001 trace:message:SPY_ExitMessage (0x10041) L"{ATL:5303EA68}" message [000f] WM_PAINT returned 00000000 That's a message trace of the paint cycle (when I make it paint by minimizing the wine window for instance. It sends WM_PAINT, the does the NCPAINT thing which seems to be do do with window borders, and then some ERASEBKGND messages come from somewhere. I have a sneaking suspicion that the background gets erased after it's painted and not before, but that's a total shot in the dark and the absence of flicker kind of makes my theory look not so strong. I did some traces with +gdi as well, but it wasn't very helpful. There were lots of GetObjPtr and locking methods called, but I didn't see any actual obviously drawing related calls. There was 1 warning: GetObjPtr was called at one point with nil. What does this mean? I can't find any documentation about GetObjPtr on google. I'll look at the sources later to see if I can figure out what's wrong. Anyway, my final question is : is there a way to alter the colour with which the background is erased? Even if it screws up rendering elsewhere just for debugging i'd like to see if I can make it display as anything *except* offwhite. If so then it confirms my theory. Or are those messages processed by the plugin itself? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 3

Re: Fix winsock conformance test on Windows NT
by Francois Gouget 04 Dec '02

04 Dec '02

On 4 Dec 2002, Martin Wilck wrote: > Am Mit, 2002-12-04 um 10.21 schrieb Francois Gouget: > > > sock.c:456: Test failed: event_client (ea): connect error: 10022 > > I could reproduce that on NT4. [...] > But setting the socket to overlapped mode helps. So with the > following one-liner we should be fine. Yep, that works. Thanks :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner

1 0

Vstserver v0.2.0
by Kjetil S. Matheussen 04 Dec '02

04 Dec '02

http://www.notam02.no/arkiv/src/ VSTServer V0.2.0. ----------------- GRM tools 1 runs with the 25.11.2002 release of wine. ABOUT Vstserver is a program that must be running when using programs using vstlib. Vstlib is a library that can be used by programs to run windows vst audio plugins under linux/freebsd/i386solaris/etc. RUNNING First you should set the "VST_PATH" environment variable pointing to the directory where your VST dll files are placed. Then to run the vstserver program, you have to cd into the directory where the "vstservant.so" file is placed (and thats most probably the directory where this README file is placed), and then run the "vstserver" program. DEVELOPMENT Vstserver is released under the GPL, and vstlib under LGPL. If there comes many source-contributions, I will probably make it a sourceforge project. To use vstlib in a program, look at the tests/exampleclient program, and various vst plug-in documentation. The interface to the vstlib consists only of two functions (new/delete), the rest is like you would do when programming for windows, macos(X), beos, irix, etc. You do currently not have access to the audioMaster callback function from a client. If you need access to it, please contact me, and I'll extend the library and the vstservant program. CURRENT STATUS Vstserver seems to be very stable. Very few vst plug-ins and instruments wont run, and I am not able to hear any latency. And plug-ins does not seem to cause more cpu-power than under windows. BUGS 1. When loading a lot of plugins simultaniously, the X server crashes (!). I manage to do that when running the ladspa "listplugins" program _many_ times in a row like this: "listplugins &". I dont know the cause of it. (running redhat 7.2, with latest XFree rpm updates installed) 2. Shared memory handlig might be faulty. I suspect that it doesnt free resources because clients sometime complains about not getting shared memory. (see server/shmhandler.c) 3. The graphics code to support gui is just hacked together by looking at the winemine source-code included with the wine distribution. I have no windows programming experience or documentation about the windows API, so if someone that have windows programming experience would have a look at the code and check that its fine/not fine, that would be, eh, fine. (The code I'm unsure about is server/win/winwin.c and server/win/main.c, about 200 lines of code.) NOT WORKING DLLS - "SimSynth VSTi demo.dll" - The standalone version wont even run under wine, so theres currently not much hope for this one. Please send me dlls that wont work. FUTURE -Make a DX-plugin server. (would be fun running pi-warp under linux). -Add gui to the plugins not providing gui themselves. (help wanted, windows programming) HISTORY 0.1.1 -> 0.2.0: -When upgrading my wine installation from the 31.10.2002 version to the 25.11.2002 version, the "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" problem got much worse. So I changed the vstserver program to be a normal unix program that starts a winelib program called "vstservant.so" for each new request it gets. This seems to have solved the GDI heap problem totally. -Extended the audioMaster function yet more by copying a lot of opcode handlings from the vst~ pd external by Mark Williamson. I didn't ask before doing this, but according to the pdf file, he used some code from the plugin~ external, which then should automaticly make vst~ GPL. The positive result is that more plugins works. The negative result is that you now need to patch the steinberg "vst/aeffectx.h" file before compiling, as there are some strange things in it. -Some smaller fixes here and there. 0.1.0 -> 0.1.1: -Replaced the old audioMaster function in the server with the one coming from the plugin~ source by Jarno Seppänen. Result is that GRM tools 2 now works. (I thought there were a different reason it didnt work before, without going into further detail...) Seems like vst instruments works better now too. The mousedrag problem seems to have dissapeared. -Removed some debug printings. 0.0.2 -> 0.1.0: -Added graphics support to the plug-ins. (effEditOpen/effEditClose dispatch opcodes works.) -Fixed the makefile a bit. 0.0.1 -> 0.0.2: -Fixed the process function in vstlib. -Fixed the problem with processreplace could fail if sampleframes was to high. -Added processreplace simulation to vstlib, in case plugin doesnt implement processreplace itself. CREDITS vstserver and vstlib are made by Kjetil S. Matheussen / Notam. k.s.matheussen(a)notam02.no Some programming hints is gathered by looking at the pd vst-object plugin~ source and the jack soundserver source. --

1 0

Re: The conformance tests need you!
by Martin Wilck 04 Dec '02

04 Dec '02

Am Mon, 2002-12-02 um 19.12 schrieb Francois Gouget: > > Am Sam, 2002-11-30 um 04.02 schrieb Francois Gouget: > > > > > > Come on people, we can do better. > > > Send fixes to wine-patches, and send me emails to so that I update this > > > table. > > > > I'll have a look at the winsock stuff. > > Thanks :-) I am currently having trouble with running stuff natively on Windows. Can anybody run the winsock test with verbose output (trace enabled) on Windows NT and send me the result ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

3 3

Re: Fix winsock conformance test on Windows NT
by Francois Gouget 04 Dec '02

04 Dec '02

On 3 Dec 2002, Martin Wilck wrote: > > With the following fixes, the winsock test runs fine (0 errors) on Win > NT (and Wine!). I applied the patch but the test still fails and gets stuck on NT4: sock.c:694: **** STARTING TEST 0 **** sock.c:332:simple_server (d3) starting sock.c:341:simple_server (d3) ready sock.c:346:simple_server (d3): waiting for client sock.c:391:simple_client (dd): starting sock.c:394:simple_client (dd): server ready sock.c:391:simple_client (b9): starting sock.c:394:simple_client (b9): server ready sock.c:406:simple_client (dd) connected sock.c:346:simple_server (d3): waiting for client sock.c:427:simple_client (dd) exiting sock.c:406:simple_client (b9) connected sock.c:374:simple_server (d3) exiting sock.c:427:simple_client (b9) exiting sock.c:696: **** TEST 0 COMPLETE **** sock.c:694: **** STARTING TEST 1 **** sock.c:332:simple_server (ec) starting sock.c:341:simple_server (ec) ready sock.c:346:simple_server (ec): waiting for client sock.c:445:event_client (ea): starting sock.c:445:event_client (e3): starting sock.c:447:event_client (ea): server ready sock.c:456: Test failed: event_client (ea): connect error: 10022 sock.c:447:event_client (e3): server ready sock.c:456: Test failed: event_client (e3): connect error: 10022 It stays there for a long time and then prints: sock.c:456: Test failed: event_client (e3): connect error: 10022 sock.c:614: Test failed: some threads have not completed: 102 sock.c:621:terminating thread 000000ec sock.c:621:terminating thread 000000ea sock.c:621:terminating thread 000000e3 sock.c:696: **** TEST 1 COMPLETE **** But then the process does not terminate... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

2 1

Re: Direct3D8 regression/bug
by Sylvain Petreolle 04 Dec '02

04 Dec '02

--- Greg Turner <gmturner007(a)ameritech.net> a écrit : > On Tuesday 03 December 2002 02:34 pm, Sylvain Petreolle wrote: > > NVidia and its bugged binary shit... > > yuck. doesn't xfree or drm-kernel project provide a decent driver > for > you guys? the nv driver provided with Xfree is way too slow to use it on Wine. and I don't want to have to compile Xfree myself. You wrote exactly what I wanted to avoid when I put "mplayer.exe" It isn't mplayer from mplayerhq.hu, but windows mplayer.exe from Windows ME. I need it to test midi with winealsa.drv. Now I didn't succeed because of Registry glitch: couldn't find midi out (%s)\n > > Note : it crashes even with mplayer.exe !! > > mplayer is very, very agressive and takes wierd liberties with > compiler > flags. compile it yourself, disable stuff you don't want, and pay > attention to the compiler flags you get. when all is said and done > ... ===== 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. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

3 4

Cygwin/wine : partial success
by Sylvain Petreolle 04 Dec '02

04 Dec '02

Making only one tweak to /etc/profile, cygwin manages to launch partially. If you comment the line USER="`id -un`", bash -l -i displays : (I placed "I'm here!" at the end of .bahrc) C>bash -l -i I'm here! syl@snoop ~ $ logout C> The next step will be identify the reason why it just logs out. I tried zsh but it says zsh: error on TTY read: permission denied and then I have no keyboard in wcmd. mc begin to display itself,then makes disappear the wcmd window, the program doesn't terminate. (??) ===== 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. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

1 0

Re: Direct3D8 regression/bug
by Jeff Smith 04 Dec '02

04 Dec '02

>From: Greg Turner <gmturner007(a)ameritech.net> > > > I need it to test midi with winealsa.drv. > > Now I didn't succeed because of Registry glitch: couldn't find midi > > out (%s)\n > >gotcha. I run winealsa too... but I've never tried midi. My buddy owns >cakewalk, I should give it a whorl sometime, and see what happens. >From what I can see in the source, winealsa only supports wave out at this time. I just recently started running ALSA (because its MIDI implementation is much better for my card than OSS), but am using OSS emulation + wineoss for midi from wine. It worked beautifully for me (after I made a couple of fixes, now in CVS). -- Jeff S _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

Re: rpc_J_PL4
by Francois Gouget 04 Dec '02

04 Dec '02

On Tue, 3 Dec 2002, Greg Turner wrote: > License: X11-MIT > > Changelog: > > * programs/rpcss/tests: rpc.c: > Greg Turner <gmturner007(a)ameritech.net> > - W9x doesn't support widechar uuids (crashes on test) That surprises me. I ran these tests on Win95 and Win98 and they failed but did not crash. Thus I think it would be better to apply this patch instead: Index: dlls/rpcrt4/tests/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/rpcrt4/tests/rpc.c,v retrieving revision 1.1 diff -u -r1.1 rpc.c --- dlls/rpcrt4/tests/rpc.c 7 Oct 2002 21:54:07 -0000 1.1 +++ dlls/rpcrt4/tests/rpc.c 4 Dec 2002 07:29:22 -0000 @@ -101,7 +101,12 @@ /* Uuid to String to Uuid (wchar) */ for (i1 = 0; i1 < 10; i1++) { Uuid1 = Uuid_Table[i1]; - ok( (UuidToStringW(&Uuid1, &wstr) == RPC_S_OK), "Simple UUID->WString copy" ); + rslt=UuidToStringW(&Uuid1, &wstr); + if (rslt==RPC_S_CANNOT_SUPPORT) { + /* Must be Win9x (no Unicode support), skip the tests */ + break; + } + ok( (rslt == RPC_S_OK), "Simple UUID->WString copy" ); ok( (UuidFromStringW(wstr, &Uuid2) == RPC_S_OK), "Simple WString->UUID copy from generated UUID String" ); ok( UuidEqual(&Uuid1, &Uuid2, &rslt), "Uuid -> WString -> Uuid transform" ); /* invalid uuid tests -- size of valid UUID string=36 */ With this patch, all tests are run on NT and Wine platforms, and on Win9x platforms, all tests are skipped after the first first Unicode call. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

2 1

spec file definitions
by Rolf Kalbermatter 04 Dec '02

04 Dec '02

I have seen some definitions of functions in a spec file where a string was defined as str or wstr. I do remember that there was an issue with this depending if the string parameter was input only (eg. const) or an input/output parameter. Is this still valid and if yes how are the rules? Rolf Kalbermatter

2 1

Installing Internet Explorer without windows
by Boris 04 Dec '02

04 Dec '02

I just tried installing IE 5.5 from setup.exe and it never seems to install properly without windows being installed or modifying files. It would be nice to install Internet Explorer without patching anything. I hope more people work towards that.

3 2

HTML Help and IWebBrowser status
by Ender 04 Dec '02

04 Dec '02

Hi all, I'm just posting a quick update on my various WINE work for those intrested. I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet). Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :) That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy. Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes. I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider: - It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's. - It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out. Cheers, Ender

6 5

Reducing the header maze (warning: long, unsuitable for children)
by Greg Turner 04 Dec '02

04 Dec '02

I'm working on Ove's comhdr1 & comhdr2 patches. So far, so good, btw -- I have it compiling against yesterday's CVS (recent commits are not folded in yet). I'll submit after I kick the tires a bit and make sure everything seems to be working (otherwise, I'll probably post it here and ask for help). Anyhow, this project has served to remind me just how deep, and how confusing, the maze of wine headers can really be. It's clear to me that lots of header inclusions are just historical remnants, that no longer serve any purpose, and, conversely, that many implicit header dependencies exist that happen to be hidden, and missing (i.e., X.h needs Y.h, but all references to X.h happen to occur after Y.h was already included, so there's no compile failure). A third kind of unnecessary (but arguably correct, in many cases) dependency is created when an include file is pulled in that is already pulled in by some prior include... This negatively affects wine development because (a) it's hard to change things, the headers break too easily, and (b) the make process rebuilds stuff that doesn't need rebuilding when things change (unavoidable, to an extent, of course, but perhaps it's too much right now). Now, here's my question: couldn't we build a script to automatically fix some of these problems? Imagine this pseudocode as a bash script, makefile, or something along those lines: o gather and create a table of all .c -> .h and .h -> .h dependencies o for each file: o one by one, try removing each reference to a header, and see if the affected units still compile. If they all do, permanently remove that reference, but remember it was there at this point we should have approximately the minimum number of header references in the code to compile wine. But some of the header references we eliminated were probably legitimate dependencies, event though we compiled OK, as mentioned above... so now we: o for each header, try to compile a "Hello World" which includes just that header file. If it fails (or even generates warnings): o for each header reference that was eliminated, try putting it back in. If still failing, try different combinations (this could become a really nasty computation with all kinds of permutations possible, but if certain simple tricks don't work, we can just give up). o if we couldn't find any way to fix it, mark the header for human review. This should ensure that each header can actually be run through the compiler all by itself -- that is, that it #include's any headers it relies on to compile. Finally... o A human picks up the pieces and fixes the breakages o The whole heuristic can start over, now, until the results start to look repetitive or trivial... I can think of some reasons this might not work out so well as I might hope, but... what do you guys think? is such a test meaningful? Is there some tool that already automates this type of investigation, or some better way to achieve the same thing? Would it be, in your opinion, too much work for too little benefit? FWIW, I can probably think of more enjoyable tasks to spend my time on... but OTOH I am really tired of waiting for wine to build on my aging pc -- anything that could speed up the build process would probably save me some from some discomfort, and others too. (At least there's no C++ in there; I'm rebuilding my system lately (I killed it over the holidays messing with glibc), and building stuff like KDE, mozilla, sun-java, and openoffice makes wine look pretty darn svelte! g++ 3.2.1 just crawls; the more "object oriented" the source is, the longer it seems to take to compile... :( ) Just "thinking out loud," probably a terrible idea, but let me know what you think, anyways... -- gmt p.s., I was kidding about unsuitable for children... but then, not sure why children should want to read this -- or adults, for that matter :P

4 4

Re: Fwd: Re: [putty]Winelib support + patch
by Alexandre Julliard 04 Dec '02

04 Dec '02

Francois Gouget <fgouget(a)free.fr> writes: > I am not sure but I suspect the compiler generates indirect accesses for > these. I'm not sure what gcc does for variables exported from another > library. It seems like it has to be doing something similar. So if we > could get access to that indirection we may be able to make things work. Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Fwd: Re: [putty]Winelib support + patch
by Dan Kegel 04 Dec '02

04 Dec '02

Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> I am not sure but I suspect the compiler generates indirect accesses for >> these. I'm not sure what gcc does for variables exported from another >> library. It seems like it has to be doing something similar. So if we >> could get access to that indirection we may be able to make things work. > > Yes, it would be possible to resolve imports directly through the ELF > tables and avoid our own separate import mechanism; basically this > would be a PE-aware ld.so. It's quite a bit of work though, and > portability is an issue. In any case it's for after 1.0 IMO. Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/ http://groups.google.com/groups?selm=20020516061929.5DA943C110%40gabi-n.hau… et seq. http://www.freebsd.org/cgi/man.cgi?query=compat_pecoff&manpath=NetBSD+1.6 - Dan

3 5

RE: Compiling out the debug messages
by Medland, Bill 03 Dec '02

03 Dec '02

> -----Original Message----- > From: Jeff Smith [mailto:whydoubt@hotmail.com] > Sent: Tuesday, December 03, 2002 2:13 PM > To: Bill.Medland(a)accpac.com; wine-devel(a)winehq.com > Subject: Re: Compiling out the debug messages > > > Bill, > > Unless I missed the whole point, you gave the answer before asking the > question. > > ./configure > > should have been > > ./configure --disable-debug You are correct; I made a right fist of writing the email. I did actually remember the --disable-debug. > > -- Jeff S > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus >

1 0

Re: Compiling out the debug messages
by Jeff Smith 03 Dec '02

03 Dec '02

Bill, Unless I missed the whole point, you gave the answer before asking the question. ./configure should have been ./configure --disable-debug -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Compiling out the debug messages
by Medland, Bill 03 Dec '02

03 Dec '02

I know I don't know what I am doing, but.. The documentation says that to compile out the trace, warning and fixme messages I should specify --disable-debug when running configure. So I try ./configure make depend make <build an rpm and install it on another machine> <run wine> <stare at the fixme messages, swear etc.> I presume that if I look for example in the dlls/user/Makefile at this stage I should see NO_DEBUG_MSGS and NO_TRACE_MSGS somewhere, but I don't. Please can someone explain how this is supposed to work and where I have probably gone wrong. (e.g. where should I see the NO_DEBUG_MSGS) Bill Medland

2 1

Re: wtypes.idl patch
by Alexandre Julliard 03 Dec '02

03 Dec '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > You need to regenerate wtypes.h (and it's best to apply my latest widl > patch first). Should regenerated .h files be part of submitted patches in > the future? For me that's not necessary; maybe for others who would like to review the patch, but I doubt many people are going to review the auto-generated stuff anyway. Just do what's easiest for you. -- Alexandre Julliard julliard(a)winehq.com

1 0

Direct3D8 regression/bug
by Roderick Colenbrander 03 Dec '02

03 Dec '02

Hi, Just to see how well Wine's Direct3D8 support is working, I played with some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades used when he started Wine's Direct3D8 implementation) A few weeks ago all those demo's worked. Perhaps some things where not rendered correctly but they worked. A few days ago I rechecked those demo's but now all d3d8 apps I try crash. Immedeately winedbg is launched. The app seems to crash in libGL.so.1. Here's the error with a backtrace: Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x40bf4a06). In 32-bit mode. 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) Lionel suggested that his OpenGL patches may have caused this problem. He had the same crashes on his pc. I reversed his patches but it still had problems. (perhaps I made some misstakes somewhere ..) Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's OpenGL drivers (1.0-3123). I hope this helps a bit, Roderick Colenbrander

2 2

WIN_FindWndPtr
by Dustin Navea 03 Dec '02

03 Dec '02

Hey just out of curiosity, now that we are working toward v1.0 (not like we werent before) shouldnt this error be changed over to a fixme? It doesnt seem like all that much needs to be done (aside from marshalling and whatnot). Just wondering if we were planning on fixing it before v1.0, as it would be a big boon to have it still there in v1.0... -Dustin

1 0

bug (regression) in ddraw/d3d
by J. Hoffmann 03 Dec '02

03 Dec '02

Hi, I wanted to play around with the improvements to ddraw/d3d, and tried to run Final Fantasy 8 which worked before in software rendering mode with the native direct music dlls. Unfortunately FF8Config (and FF8 itself) crashes now with the recent changes. The patch which introduces the regression is: http://www.winehq.com/hypermail/wine-cvs/2002/11/0231.html (cvs version just before the patch works, applying the patch results in a pagefault.) The problem appears to be that GL_IDirect3DImpl_3_CreateDevice gets called with an rclsid = IID_D3DDEVICE2_OpenGL instead of IID_D3DDEVICE3_OpenGL, so that an D3DDevice2 gets created for the Direct3D3 interface (which results in a pagefault later, when the device is used.) See traces below. Im still trying to find the bug (and then a fix :-), but it would help me a lot, if someone could tell me where the GL_IDirect3DImpl_3_CreateDevice gets called from. (I see that it is an entry in the vtable but haven't found the function there it gets gets called yet..) regards, Jens Hoffmann ** trace for the old version: (cvs 11/24/02 16:14:09 CST) ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4568)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x40852 3cc) trace:ddraw:direct3d_create creating implementation at 0x403a5380. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a5384. trace:ddraw:Main_DirectDraw_AddRef (0x403a4568)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a5380/0x403a5384)->({31416d44-86ae-11d2-822d-a8d53187cafc},0x403a4e28,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4e28, d3d = 0x403a5380 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x80a0260) trace:ddraw:d3ddevice_create setting current context err:ddraw:set_context This function should not be called in the current state of the code... trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a5770. trace:ddraw:create_device_helper returning OpenGL D3DDevice3 (nil) trace:ddraw:Thunk_IDirect3DDeviceImpl_3_EnumTextureFormats (0x403a5774)->(0x405393,0x42e014) thunking to IDirect3DDevice7 interface. ... ** trace for cvs head: ** ... trace:ddraw:Main_DirectDraw_QueryInterface (0x403a4540)->({bb223240-e72b-11d0-a9b4-00aa00c0993e},0x408523cc) trace:ddraw:direct3d_create creating implementation at 0x403a54b0. trace:ddraw:Main_DirectDraw_QueryInterface returning Direct3D3 interface at 0x403a54b4. trace:ddraw:Main_DirectDraw_AddRef (0x403a4540)->() incrementing from 2. trace:ddraw:GL_IDirect3DImpl_3_CreateDevice (0x403a54b0/0x403a54b4)->({31416d44-86ae-11d2-822d-a8d53187cafb},0x403a4f18,0x408523d0) trace:ddraw:d3ddevice_create creating OpenGL device for surface = 0x403a4f18, d3d = 0x403a54b0 trace:ddraw:d3ddevice_create visual found trace:ddraw:d3ddevice_create context created (0x809f818) trace:ddraw:d3ddevice_create setting current context trace:ddraw:set_context glxMakeCurrent 0x80690c0, 62914563, 0x809f818 trace:ddraw:d3ddevice_create current context set trace:ddraw:d3ddevice_create creating implementation at 0x403a55e8. trace:ddraw:create_device_helper returning OpenGL D3DDevice2 0x403a55f0 trace:ddraw:Thunk_IDirect3DDeviceImpl_2_NextViewport (0x403a55f0)->(0x405393,0x42cb40,00000000) thunking ...

2 3

Re: Wine 0.9 TODO v0.6
by Z_God 03 Dec '02

03 Dec '02

First, would it be an idea to say at least *insert any number* of Windows apps should be working perfectly with Wine before it is called 0.9? For example, we at least want to have 200 known perfectly working apps. And why not start at version 0.6 or something and calling Wine beta software instead of alpha when these TODOs are done? Then it would be possible to work towards a great 1.0 release. Just look at Mozilla, they post-poned their 1.0 release more than a year to become really great. Keep up the great work!! Z_God Op maandag 2 december 2002 19:40, schreef Dimitrie O. Paun: > Hi folks, > > Version 0.6 of the TODO for Wine 0.9 is available at: > http://www.dssd.ca/wine/Wine-0.9-TODO-0.6.html > As always, you can find the work-in-progress one here: > http://www.dssd.ca/wine/Wine-0.9-TODO.html > > As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment > -- A5: New FAQ is done, waiting to be promoted to WineHQ > -- D2: Alexandre got rid of the rsrc directive in .spec files > -- E4: Lionel made OpenGL detection dynamic > -- E9: New TODO item for fixing header location as discussed on > wine-devel > > Enjoy!

2 1

Programs to test D3D
by J C 02 Dec '02

02 Dec '02

Hi all, I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help. This first is a demo called Bleam: http://www.bluespoon.com/banjoh/ This page has a binary of the demo and source code as well. The second is an older benchmark/demo called Tirtanium: http://www.tirtanium.de/prog3d.html The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror: http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip Both display stuff on screen and will run through to the end with no crashes. Justin Chevrier PS. Great work guys! _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

W->A calling and 32->16 calling
by Rolf Kalbermatter 02 Dec '02

02 Dec '02

While going through the shell32 sources I found several issues with respect of this and at least one of them I couldn't find in the Janitorial list. ExtractIconW calls ExtractIconA which is mentioned but ExtractIconA calls InternalExtractIcon16 which is a 16 bit undocumented but exported function. I guess this should also go into the 32->16bit list somehow. I have worked on some fix for this but have to admit that this seems a little bit tricky. InternalExtractIcon16 also tries to open the file name with LoadLibrary16 so if it is a 16bit DLL the requested icons will still be extracted. PrivateExtractIcon and friends which are similar but also can handle negative icon indices which indicates that it should be treated as icon identifier, do as far as I can see not deal with 16bit libraries (they ultimatively call ICO_ExtractIconExW. This of course poses the question if the 32bit function ExtractIcon is supposed to return icons for 16bit libraries and if so, ExtractIconEx may actually also be required to do so. Below is a first attempt for a patch which does most probably not try to load resources from 16bit libraries yet. Also how about going with InternalExtractIcon16? Any comments to this? Rolf Kalbermatter Index: dlls/shell32/shell32_main.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shell32_main.c,v retrieving revision 1.108 diff -u -r1.108 shell32_main.c --- dlls/shell32/shell32_main.c 21 Nov 2002 23:56:42 -0000 1.108 +++ dlls/shell32/shell32_main.c 2 Dec 2002 20:43:23 -0000 @@ -544,19 +544,18 @@ * FIXME * if the filename is not a file return 1 */ -HICON WINAPI ExtractIconA( HINSTANCE hInstance, LPCSTR lpszExeFileName, - UINT nIconIndex ) -{ HGLOBAL16 handle = InternalExtractIcon16(HINSTANCE_16(hInstance),lpszExeFileName,nIconIndex, 1); - TRACE("\n"); - if( handle ) - { - HICON16* ptr = (HICON16*)GlobalLock16(handle); - HICON16 hIcon = *ptr; - - GlobalFree16(handle); - return HICON_32(hIcon); - } - return 0; +HICON WINAPI ExtractIconA(HINSTANCE hInstance, LPCSTR lpszFile, UINT nIconIndex) +{ + HICON ret; + INT len = MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, NULL, 0); + LPWSTR lpwstrFile = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); + + TRACE("%p %s %d\n", hInstance, lpszFile, nIconIndex); + + MultiByteToWideChar(CP_ACP, 0, lpszFile, -1, lpwstrFile, len); + ExtractIconW(hInstance, lpwstrFile, nIconIndex); + HeapFree(GetProcessHeap(), 0, lpwstrFile); + return ret; } /************************************************************************* @@ -564,18 +563,21 @@ * * FIXME: if the filename is not a file return 1 */ -HICON WINAPI ExtractIconW( HINSTANCE hInstance, LPCWSTR lpszExeFileName, - UINT nIconIndex ) -{ LPSTR exefn; - HICON ret; - TRACE("\n"); +HICON WINAPI ExtractIconW(HINSTANCE hInstance, LPCWSTR lpszFile, UINT nIconIndex) +{ + HICON hIcon = NULL; + + TRACE("(%p %s %d\n", hInstance, debugstr_w(lpszFile), nIconIndex); - exefn = HEAP_strdupWtoA(GetProcessHeap(),0,lpszExeFileName); - ret = ExtractIconA(hInstance,exefn,nIconIndex); + if (nIconIndex == -1) + return (HICON) PrivateExtractIconsW(lpszFile, -1, 0, 0, NULL, 0, 0, 0); - HeapFree(GetProcessHeap(),0,exefn); - return ret; + ExtractIconExW (lpszFile, nIconIndex, &hIcon, NULL, 1); + if (hIcon) + return hIcon; + return (HICON)1; } + typedef struct { LPCSTR szApp;

1 0

Re: Wine 0.9 TODO v0.6
by Hetz Ben-Hamo 02 Dec '02

02 Dec '02

> As a departure from previous release, this time I'm only going > to include a small summary of changes since the last release: > -- A4: New screenshots page is available for comment I looked at the screenshots. Looks very impressive but very problematic.. Why problematic? simple: most of those applications requires many tweaks to run. Example: try to install Office 2k on the latest wineHQ. You'll have lots of problems installing it, and even if you install, you'll need to do "reboot" - which is not available unless you have CrossOver office. Same goes to many applications which have screenshots there.... So think what will happend if users will download wine-snapshot and won't be able to install the apps that appears in the screenshots? lots of anger, flames, false bug reports, you name it ;) Thanks, Hetz

2 1

Re: Cabinet update
by Alexandre Julliard 02 Dec '02

02 Dec '02

Patrik Stridvall <ps(a)leissner.se> writes: > *** cabinet > > * include/fci.h, > include/fdi.h, > dlls/cabinet/Makefile.in, > dlls/cabinet/fci.c, > dlls/cabinet/fdi.c, > dlls/cabinet/main.c: > - Added previously forgotten file main.c. There is no reason to have a stub DllMain, it only slows things down and makes no difference for the app. We should only add it if/when we really need it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Winelib - MFC application
by Ronald MALLET 02 Dec '02

02 Dec '02

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

3 3

RE: strcat+strcat+strcat == baaad
by Medland, Bill 02 Dec '02

02 Dec '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. I think this statement has to be tightened. I am sure you know exactly what you mean, Alexandre, and I believe that I and many others do. However I think we need to mention that one needs to consider that the strings passed in may be bad, e.g. unterminated. Either one uses that actual measured lengths of the strings when allocating or one checks the lengths of the strings against the allocated space. In particular one DOES NOT allocate on the basis of some wishy-washy documentation statement or a hard-coded constant that the caller may well have ignored. > > -- > Alexandre Julliard > julliard(a)winehq.com > > Bill Medland

3 2

How to fix display errors?
by Ferenc Wagner 02 Dec '02

02 Dec '02

Hello, I decided to forward a previous post of mine from the users' newsgroup, since I got no answers there, and consider this a developer question: I'd like to correct some bugs. Having read the Developers' Guide didn't help me much: the relevant topic was empty (the program runs, but shows some errors). Perhaps you can point me in the right direction (I mean: source file in the tree)? Below is the article. See a screenshot at http://afavant.elte.hu/~wferi/wine.png (25K). It exhibits several slight problems. 1. The scrollable list has no border (Suchanfrage window, above the Phrasensuche checkbox). 2. The text input field (with Goethe in it) has no border, too. 3. The "Minimize" button is misplaced: clicking to the right of it invokes its action, the button itself is not clickable. 4. The little toolbar window to the right looks strange, but what is worse, it is sticky: appears on every viewport (It's not managed by fvwm2, like the main window.) The Suchanfrage subwindow is not sticky. While executing the program, I get the following messages: err:toolbar:ToolbarWindowProc unknown msg 0465 wp=0000004c lp=412c1d70 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:statusbar:StatusWindowProc unknown msg 0486 wp=0000 lp=00000000 err:toolbar:ToolbarWindowProc unknown msg 0486 wp=00000000 lp=00000000 fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub Is there anything I can do about the above (cosmetic) errors? I use a recent CVS checkout (Wine 20021125), and I know C programming, but have no experience with graphics and Windows. Feri.

1 0

Winelib - MFC application
by jaymz＠free.fr 02 Dec '02

02 Dec '02

I'm currently trying to build an MFC based-applications using Winelib. I (almost) successfully compiled the MFC, and get an mfc.dll.so file. Here are the few troubles I had or still have: First for compiling the MFC: --------------------------------------- - I had to uncomment PSH_WIZARD97 in /wine/prsht.h - The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker - I had to force winnt.h to use nameless struct and unions - I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h - I linked _alloca() to alloca() function - There was a conflict on HKEY type between <afxres.h> and <wine/windef.h> - Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString ==> it worked then, using some additional defines as suggested in the Winelib documentation page. Then for my MFC-based application: ------------------------------------------------- - Winemaker tries to link with libmfc.so, but by default we have a dll, so i just symlink it to mfc.dll.so - I first tried winemaker default settings on my app, but it creates two targets with the same name (the dll and the executables), so I had to override this using interactive mode - Then I encountered the MFC initialization problems (a crash in dllname() when loading my application .so), so I added the wrapper using winemaker - Even when using the wrapper, it crashes at startup when trying to load my application dll. - The backtrace is something like dllname (from libmfc.so) operator new ... Init (from /gcc-3.2.1/libstdc++-v3/src/ios.cc:211) ___static_initialization_and_destruction_ ... _dl_open ... WinMain (from myapp.exe_wrapper.c:83) __wine_exe_main (from myapp.exe.spec.c:129) start_process call_on_thread_stack - Winelib must have been initialized, but the problem stills here ? Any suggestion ? - I then tried to remove linking with libmfc.so but using only the mfc.dll.so (I had to fill the mfc.dll.spec file to export all the symbols, using weird mangling rules), but it then hook in the msvcrt.dll in an infinite _lock loop ? I'm a bit lost with this error, as it's not in an easy-to-debug code area.... Any advices are welcomed !

1 0

Screenshots v0.1
by Brian Vincent 02 Dec '02

02 Dec '02

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here: http://www.theshell.com/~vinn/ss/preview.html Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money. Random notes: - there's lots of great shots not on the thumbnails page - most likely there's a reason, not 800x600, didn't scale well, or I simply overlooked it - you can find all of the screenshots at: http://www.theshell.com/~vinn/ss - the images predominantly are PNG, though there are quite a few JPEGs. No GIF. - Special thanks to: Thomas Wickline Carlos Lozano David Buchmann Guido Grazioli Ender Juliasz Gonera Michael Krasucki Mike Hearn Rick Romero Robert Shade Rory King Tony Lambregts tavis Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those. Also, a few weeks ago there was a lot of discussion of a new WineHQ site. Any progress on that front? -Brian Vincent

3 2

RE: strcat+strcat+strcat == baaad
by Patrik Stridvall 02 Dec '02

02 Dec '02

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I > can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static > func), or in > some library that will be linked (statically, I hope). Ideas? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

1 0

Adding support for xxx_test.exe all
by Francois Gouget 02 Dec '02

02 Dec '02

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

2 2

Wine/FF7 midi help request
by Robotech_Master 02 Dec '02

02 Dec '02

On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a discussion about midi in WINE in which FF7 was mentioned): > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > modification to wine at all, and the OSS emulation of ALSA makes the > thing transparent to WINE. Can you, or someone, please let me know how to set up wine to use this? I'm running Debian Linux; these are the versions of timidity and wine that I have: ii timidity 2.11.2-1.3 Software-only MIDI sequencer. ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a Soundblaster live card. On the FF7 config program, it gives me the choices Wine OSS midi out (#0) - disabled EMU10K1 midi Under "midi data" it gives me the choises General midi Soundfont midi (Creative AWE32/AWE64) Yamaha XG midi No matter what I try, in whatever combination, I get "Error opening device" and the wine console says fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ab930,0001003c,3):stub Can someone help me out--or point me at somewhere else I can find help? Thanks. -- Chris Meadows aka | Co-moderator, rec.toys.transformers.moderated Robotech_Master | Homepage: <URL:http://www.eyrie.org/~robotech/> robotech(a)eyrie.org | And now I've started a weblog: | http://robotech_master.livejournal.com

1 0

Wine REALLY emulates Windows (was: Texture corruption in Wine)
by David D. Hagood 02 Dec '02

02 Dec '02

I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole "Just re-install it, it will fix it" thing down pat! 8^> To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows "mysterious changes" thing down pat! But it works. As Bugs Bunny said, "I don't ask questions, I just have fun." So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it....

1 0

DIB engine
by Johan Gill 01 Dec '02

01 Dec '02

Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, johane(a)lysator.liu.se

3 2

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > > That solves the libc problem however compiling with -flong-int also > > means that it will be impossible to call other libraries, which > > means that it will be a little hard to use Unix specific library > > to have extra functionallity under Unix. > > But those apps will be aware of the issue, and can use explicit types, > just like we're going to do in Wine. Sure, they will not be able to > use the header files directly (actually, they might by having some > compat files that are not compiled with said flag on), but I don't > think it's a big deal anyway. It's workable, A better solution would be to port the source code to the LP64 model. It is entirely possible for to support all of LP32 (Win32 and "Unix32"), LLP64 (Win64) and LP64 ("Unix64") in a sane way. I don't think it is worth the effort to support LLP64 beyond having a "-flong-int" flag to get a working version to show as a prototype that porting is indeed possible. > and Win64 will not > bother us for some time... True. Microsoft doesn't seems that eager pushing Win64 either...

1 0

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> On December 1, 2002 11:36 am, Patrik Stridvall wrote: > > So that is why we "never" will support 100% Win64 source > compatibillity > > on 64bit platforms. We can (and presumably) will support a > LP64 variant > > of Win64 but it won't be 100% source compatible. > > I don't think it's nearly as bad as you make it. In the Wine sources, > we'll just use explicit types that don't depend of compiler switches, > while Winelib apps will just use the -flong-int flag, and get > what they > expect. Of course, they'll have to use our msvcrt lib instead of the > native libc, but that's largely true today anyway (for > different reasons). That solves the libc problem however compiling with -flong-int also means that it will be impossible to call other libraries, which means that it will be a little hard to use Unix specific library to have extra functionallity under Unix. But sure having a -flong-int flags is nice but it doesn't solve all problems. Perhaps would be good to push for its addition even now, it might take a few years before standard GNU C installation supports it.

2 1

"not enough space in GDI heap" / forking vstlib programs
by Kjetil S. Matheussen 01 Dec '02

01 Dec '02

Hello, as I just announced I'm developing a vst-server, that loads and runs windows vst plugins. But after loading and unloading a lot of plugins, I get lots of "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" errors. I understand that the cause of this error is caused by a memory leak in a windows program. However, in the vst-server, there is no way to control memory leaks in the plug-ins, as those are made by various groups and persons. So is there a way around this error. Doing a fork for each new plug-in perhaps? Is that safe? I want to do that also to avoid having a plug-in crash the vst-server. --

2 2

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> On November 29, 2002 01:43 pm, Patrik Stridvall wrote: > > On 64 bit platforms we can never get 100% Win32 source compabillity > > because of compiler problems. If fact we can't get 100% > Win64 support > > either for the same reasons so I guess Wine on 64-bit platforms will > > be some kind of pseudo mode. > > Why are you saying that? What about the current difference between the > sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags > in the great tradition of -fwchar-short? It is a little worse that that. The C programming langauge doesn't really specify the sizes of the various integer types. It it up to the ABI. In Win32 the only really problematic difference I the one you meantion above ie the size(wchar_t) problem. It can be "solved" as specified above with -fwchar-short. The price is that you can't call the C library "wchar" functions or for that matter any library functions that depend of wchar. Not that big deal though. In the Win64 ABI Microsoft in it infinity "wisdom" has choosen the type long to be 32 bit instead of 64 bit like in most (all?) Unix API on 64 bit platforms. The Microsoft Win64 choice is called LLP64. That is long long and pointers are 64 bit. The Unix64 choice is called LP64. That is long and pointers are 64 bits. So this means that if we add an option similar to -fwchar-short, say -flong-int or -flong-32bit or whatever we can call we can't call the any library on the platform since it would could ABI problems. :-) So that is why we "never" will support 100% Win64 source compatibillity on 64bit platforms. We can (and presumably) will support a LP64 variant of Win64 but it won't be 100% source compatible.

2 1

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

2 1

Fwd: Re: [putty]Winelib support + patch
by Dimitrie O. Paun 01 Dec '02

01 Dec '02

This is a very valid question. Alexandre, do we support generating regular executables for the apps we don't necessarily need the wrapper stuff for initialization purposes? ---------- Forwarded Message ---------- Subject: Re: [putty]Winelib support + patch Date: Mon, 25 Nov 2002 10:17:18 +0000 From: Simon Tatham <anakin(a)pobox.com> To: dpaun(a)rogers.com Cc: putty(a)projects.tartarus.org "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > FYI: the way it works is that instead of compiling the app as an > executable, we generate a .so that's loaded by wine. Now, > wine is simply a one page program that loads the libraries > that the program expects (like kernel, gdi, user), and then > loads the program itself. This is required by some apps which > have C++ static initializers, which expect to be able to call > Win32 functions, and they do so before we get a chance to > initialize them, if we were to have the app load the libs. OK, I've now read the docs and I understand this a bit better now. My next awkward question is: I can see that this is necessary for some apps which have C++ static initialisers, or which load libraries that have C++ static initialisers, but why does that mean it's necessary for PuTTY? PuTTY contains no C++, and as far as I know it uses no libraries _except_ standard Win32 API ones. Surely it should be possible _for these particular applications_ to compile them as standalone binaries? Or does Winelib currently only support doing things the inconvenient way? Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the <anakin(a)pobox.com> terminally confused is only apparent to the latter." ------------------------------------------------------- -- Dimi.

3 5

Texture problems under Wine - more info
by David D. Hagood 01 Dec '02

01 Dec '02

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

2 2

SetWindowHookEx
by steve.lustbader＠philips.com 01 Dec '02

01 Dec '02

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

Compilation with -DSTRICT
by Thomas Wickline 01 Dec '02

01 Dec '02

Hello, I just want to say Thank you to all the people who put work into the Compilation with -DSTRICT Tom

1 0

Reopened a bug
by Dustin Navea 30 Nov '02

30 Nov '02

I have reopened bug #15 due to the fact that the bug still exists to a certain extent and in a different form. When sending an IM in AIM with any recent version of wine (including a couple of days before the latest cvs snapshot), I can resize the window and when the buttons go to reposition themselves, they move much slower than the border of the window, and you can see them updating their position. Would there be any debug traces I could post to the bug to help resolve this? -Dustin

1 0

RE: strcat+strcat+strcat == baaad
by Medland, Bill 30 Nov '02

30 Nov '02

> -----Original Message----- > From: wine-patches-admin(a)winehq.com > [mailto:wine-patches-admin@winehq.com]On Behalf Of Francois Gouget > Sent: Friday, November 29, 2002 10:11 PM > To: wine-patches(a)winehq.com > Subject: strcat+strcat+strcat == baaad > > > > I don't like pieces of code that go: > > strcpy(foo, bar1); > strcat(foo, bar2); > strcat(foo, bar3); > strcat(foo, bar4); > strcat(foo, bar5); > strcat(foo, bar6); > > It's really inefficient: the cost increases quadratically > with the size > of the resulting string. It's more efficient to do: > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); > > Here the cost is proportional to the size of the resulting string. And surely when the opportunity arises it would be better to use snprintf (i.e. when you know the size of the buffer). (I doubt that the code has already checked the size of the strings being pasted together) > > For for various reasons I came accross a couple of instances of > strcat+strcat badness and replaced them with a sprintf. So here's the > patch. > > Changelog: > > * memory/environ.c, > tools/makedep.c > > Use sprintf rather than calling strcat over and over > > > Index: memory/environ.c > =================================================================== > RCS file: /home/wine/wine/memory/environ.c,v > retrieving revision 1.38 > diff -u -r1.38 environ.c > --- memory/environ.c 9 Oct 2002 18:35:02 -0000 1.38 > +++ memory/environ.c 30 Nov 2002 05:20:12 -0000 > @@ -641,12 +641,7 @@ > > /* Set the new string */ > > - if (value) > - { > - strcpy( p, name ); > - strcat( p, "=" ); > - strcat( p, value ); > - } > + if (value) sprintf( p, "%s=%s", name, value ); > current_envdb.env = new_env; > ret = TRUE; > > Index: tools/makedep.c > =================================================================== > RCS file: /home/wine/wine/tools/makedep.c,v > retrieving revision 1.13 > diff -u -r1.13 makedep.c > --- tools/makedep.c 17 Aug 2002 18:28:43 -0000 1.13 > +++ tools/makedep.c 30 Nov 2002 06:10:17 -0000 > @@ -192,9 +192,7 @@ > if (SrcDir) > { > pFile->filename = xmalloc( strlen(SrcDir) + > strlen(pFile->name) + 2 ); > - strcpy( pFile->filename, SrcDir ); > - strcat( pFile->filename, "/" ); > - strcat( pFile->filename, pFile->name ); > + sprintf( pFile->filename, "%s/%s", SrcDir, pFile->name ); > } > else pFile->filename = xstrdup( pFile->name ); > > @@ -218,9 +216,7 @@ > for (path = firstPath; path; path = path->next) > { > char *filename = xmalloc(strlen(path->name) + > strlen(pFile->name) + 2); > - strcpy( filename, path->name ); > - strcat( filename, "/" ); > - strcat( filename, pFile->name ); > + sprintf( filename, "%s/%s", path->name, pFile->name ); > if ((file = fopen( filename, "r" ))) > { > pFile->filename = filename; > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > >

1 0

Re: somebody help me identify this bug please
by ezra daniel 30 Nov '02

30 Nov '02

that I have tried and needed yes, only valves with "acute accent" like you call it, excuse my english.. :) And I dont understand what you mean by dead key... but anyway... in every linux app I can type that right, only the new wine version breaks that, but I know it was fixed on 20021031 cause it worked great. To make an example of what I can't type : canción = in the wine version appears as cancion without the ó In my language this is very important or they will think I dont know how to write my language, hehehe Thanks :) -daniel http://www.debian-gnu.com >From: "Jeff Smith" <whydoubt(a)hotmail.com> >To: ezra_daniel(a)hotmail.com, wine-devel(a)winehq.com >Subject: Re: somebody help me identify this bug please >Date: Fri, 29 Nov 2002 13:31:46 -0600 > >Is it only characters with the acute accent? Is it that your are >attempting this using 'dead key' entry on a Spanish keyboard? > >If this is the case, the problem may be in a recent correction to >the Spanish keyboard layout. > >I will work on this some more when I get a chance, but hopefully >someone else will find something sooner. > > -- Jeff S > > >>From: "ezra daniel" <ezra_daniel(a)hotmail.com> >> >>Hello, >> >>At work I use Lotus Notes under Wine. >> >>I downloaded compiled and installed the new wine version 20021125 and I am >>no longer able to type accecented valves, like á é í ó ú. >> >>Ñ can be typed though correctly. >> >>With the other version 20021031 I could type accented valves.In fact I >>went back to using the older version and worked again so it is obvious it >>is a problem in the new wine version. >> >>Though I am a newbie and know nothing of developing, but I would like to >>submit the bug to the proper person so it fixes it back again but I dont >>know which section of wine or person deals with this character typing >>problem. >> >>Can anyone point me in the right direction? Thanks in advance. >> >>-daniel >>http://www.debian-gnu.com > _________________________________________________________________ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx

1 0

Re: Yet another D3D patch....
by Christian Costa 30 Nov '02

30 Nov '02

Lionel Ulmer wrote: >Hi all, > >This patch should not be dependant of any others... But to prevent line >number errors, better to commit it after the 5 -> 9 series (yeah, the >attachements are numbered to ease tracking :-) ). > >Changelog: > - start of support for device locking / unlocking via glReadPixels / > glDrawPixels interface (slow but should be enough for a start) > - implement one vertex case for the D3D3/7 DrawPrimitive functions > - fix a missing \n in a TRACE call > > Lionel > This patch breaks the TWIST demo that was working fine. I think the changes in d3ddevice_create are responsible of that.

2 2

DPMI_CallRMProc trouble
by György 'Nog' Jeney 30 Nov '02

30 Nov '02

I realy need help with this. Whenever I call a DOSDEV_ function then that function eventually calls DOSDEV_DoReq. This function calls DPMI_CallRMProc. Now that function call DOSMEM_GetBlock( 64, (UINT16 *)&(context->SegSs) ) to try and allocate a stack. This fails for some reason but I dont understand why because it succeds if called from int21/48. Anyone know whats going on? nog.

1 0

Re: Janitorial Projects
by Rolf Kalbermatter 30 Nov '02

30 Nov '02

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: >I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > >with the list of cross calls from 32->16, and W->A. > >There are currently 13 cross calls from 32->16 bit code, >and 194 cross calls from Unicode to ASCII. I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version. But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions? Rolf Kalbermatter

2 1

MIDI Mapper fix
by Jeff Smith 30 Nov '02

30 Nov '02

I'm so happy, I just had to share it with everyone :-D Changelog: Fix for MIDI Mapper. Notes: Finally found it! This was the last thing keeping sound from working in Auralia. With just this simple patch, it now works. Auralia still has a few problems, but they are minor in comparison. It *is* kind of important for sound to work in an ear training program ;-) BTW, Thanks to Eric P. for his help getting me off to a running start with his fixes to the OSS MIDI driver a couple of weeks back. (patch is attached - Hotmail has not been kind to my inlined patches the past few days) _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0

The conformance tests need you!
by Francois Gouget 30 Nov '02

30 Nov '02

Hi, I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms. That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine). You can see things more graphically at the following URL: http://fgouget.free.fr/wine/tests-en.shtml Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

1 0

[RFC] Wine headers
by Dimitrie O. Paun 30 Nov '02

30 Nov '02

Alexandre, Patrik brought up the header location sometime ago, in this thread: http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 At the time, I thought it is a bit premature, that we have other things to do. Now I realize that this is one of those highly visible external things, that would be a _lot_ better to fix before people start using Winelib. Otherwise will piss people off when we change, or we will not change because people are already using the headers. Both versions are not good, and I think we can fix them now without too much pain. Here is my proposal: ${prefix}/include/win32 -- standard Win32 headers ${prefix}/include/msvcrt -- MS Visual C Runtime library ${prefix}/include/wine -- Wine specific headers It is simple (to understand & implement), clean, and pretty. And I think it solved Patrik's problem (even if I can't quite understand what the problem is from the first message :)), plus a bunch of other things (like making it easy to use other headers for the Win32 API, etc). And best of all, it seems to be easily implementable, no? -- Dimi.

2 1

Partial success report: Toshiba 220CDS electronic manual
by Dan Kegel 30 Nov '02

30 Nov '02

http://cdgenp01.csd.toshiba.com/content/support/downloads/220guide.exe is an "online manual" for the Toshiba 220CDS laptop. I unzipped it with Linux unzip, then ran its setup and the app itself with Wine20020605-2 from Red Hat 8. Both ran acceptably well, although I did get a few warnings like: err:ntdll:RtlpWaitForCriticalSection section 0x4011a4a8 "../../scheduler/syslevel.c: Win16Mutex" wait timed out, retrying (60 sec) tid=08078300 fixme:scroll:ScrollBarWndProc Unimplemented style SBS_SIZEBOX. and there were display anomolies (mostly, areas of the window not being cleared, so old text piled up). Also, I had to grep through the registry for 'toshiba' to see where the darn thing installed itself. I'm looking forward to trying with a more modern wine, but don't have time at the moment. - Dan

2 2

[RFC] Winelib enhancements
by Dimitrie O. Paun 29 Nov '02

29 Nov '02

Folks, You are probably familiar with the Winelib page: http://www.dssd.ca/wine/Winelib-Apps.html where I describe what one needs to do to compile a Win32 application under Winelib. My original motivation for doing the work was to better understand what inconveniences one has to go through to do the port, and what we can do to eliminate them. Here are my thoughts on the subject, in the build order: Compilation This step require the addition of some flags, and the potential removal of others. Simple to do, and if there is a configure script, quite doable. However, these tweaks are really annoying in the initial stages of the port, and would be so nice if we had a nice compiler wrapper (call it wcc) that would do that behind the scenes, so that the only modification to the makefile would be: -CC=gcc +CC=wcc Q: Alexandre, would you accept such a utility in the tree? Resources These ones are nasty. Programs typically use the windres compiler that compiles a .rc file into a .o file directly, which is later simply linked into the application. We go a different route, by sticking the resources in the .spec.c files, and this entails non-trivial modifications to the makefiles. The ideal option would be to provide a windres compatible command line mode for wrc, so that we can do: -RC=windres +RC=wrc This would mean moving the resources out of the .spec.c file, and exporting the resources variable so we can link it into the .spec.c file. Q: Alexandre, is this acceptable? Does it warrant discussion? Linking Another tricky step, with multiple problems 1. We are missing import libraries. As a result, we can not link with -lwinspool, we need to link with -lwinspool.drv Small change, but it can present nasty problems if you want to submit the patch upstream, to the application maintainers. I understand this one is already on Alexandre's TODO, so we should have a solution to it not before too long. 2. Our linking process is quite different from the "standard" one which uses gcc/ld to do the linking. We generate intermediate files (.spec.c files), and use different flags. Again, the solution for this (to at least help initial porting efforts) would be a wrapper script that does this, that can be used instead of ld. And so the question comes back again, to haunt us: is this needed/wanted/acceptable? Running This is a new step in the process that we introduce. Currently we produce a shared library that requires a wrapper script to start it up. Many considers this (and I might say rightfully so) ugly/bloat/etc. The ideal situation would be to generate regular executables, like all well behaved libraries. Here are a few solutions: 1. An interim step is to improve the wineapploader script so that it can be used by all apps. This is a simple thing to do at the moment, but does not solve the root cause, it just ease the pain a bit. This way you don't need to fight the application maintainers to get such script included in their tree, and having to answer the eternal questions: "WTF is this? I thought that compiling under Winelib would yield an executable that did not need wine. What's the difference as compared to running the Win32 binary directly?" 2. Fix the build process so that we can actually generate regular executables. Thing is, I don't know what's involved in doing so, and I'm afraid only Alexandre knows the answer (hint, hint :)). So a discussion on this topic is needed, just to figure where we want to go from here. Now, this message is meant to elicit discussion on these topics, so that at the end of the day I can gather the conclusions, and track them on TODO page. So do not hesitate to send in your comments. :))) Thanks for your attention, and sorry for the long message. -- Dimi.

5 14

ppdebug
by Michael Sauer 29 Nov '02

29 Nov '02

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2 mIc P.S.: sorry if this mail reaches the list twice, but the first one i send with some private e-mail address and the list moderator will (hopefully) erase it (as he does it every time).

2 1

RE: Janitorial Projects
by Patrik Stridvall 29 Nov '02

29 Nov '02

> "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > >I have updated the Janitorial section: > > http://www.dssd.ca/wine/Wine-Fun.html#janitorial > > > >with the list of cross calls from 32->16, and W->A. > > > >There are currently 13 cross calls from 32->16 bit code, > >and 194 cross calls from Unicode to ASCII. [snip] > But what the heck do the errors about AW functions calling Unicode > mean? It means that winapi_check has a bug. Fixed in my tree. > Isn't that the actual idea about the AW functions? Yes. :-)

1 0

RE: Wine conformance tests with MSVC headers
by Patrik Stridvall 29 Nov '02

29 Nov '02

> I tried to compile the various conformance tests with MSVC 6.0. There > are two different configurations for each project: with MSVC or Wine > headers. With the MSVC headers configuration, it doesn't find > "wine/test.h" (since wine/include is not in the include > path). Is it a > known behavior? With the Wine headers configuration, I don't > get those > errors It is bug. Fixed in my tree. Patch comming soon. > (but there are a bunch of warnings concerning signed/unsigned > comparisons, for which I'll try to send a patch tonight). OK.

1 0

Wine conformance tests with MSVC headers
by Vincent Béron 29 Nov '02

29 Nov '02

Hello, I tried to compile the various conformance tests with MSVC 6.0. There are two different configurations for each project: with MSVC or Wine headers. With the MSVC headers configuration, it doesn't find "wine/test.h" (since wine/include is not in the include path). Is it a known behavior? With the Wine headers configuration, I don't get those errors (but there are a bunch of warnings concerning signed/unsigned comparisons, for which I'll try to send a patch tonight). Vincent

1 0

ppdebug
by Michael Sauer 29 Nov '02

29 Nov '02

since some versions of wine (actually i checked today's version out) I get the following error messages while compiling (i ignored them the last two times, assuming i want ppdebug set to 0 and patching the code that way) : gcc -g -O2 -Wall -mpreferred-stack-boundary=2 -o widl header.o proxy.o utils.o widl.o y.tab.o lex.yy.o -L../../tools/wpp -lwpp -L../../library -lwine -L../../u nicode -lwine_unicode -lfl ../../tools/wpp/libwpp.a(wpp.o)(.text+0x14b): In function `wpp_set_debug': /opt/src/build/wine/tools/wpp/wpp.c:74: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x3533): In function `push_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1147: undefined reference to `ppdebug' ../../tools/wpp/libwpp.a(lex.yy.o)(.text+0x38c0): In function `pop_buffer': /opt/src/build/wine/tools/wpp/./ppl.l:1232: undefined reference to `ppdebug' collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/opt/src/build/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/opt/src/build/wine/tools' make: *** [tools] Error 2

1 0

RE: msvcmaker
by Patrik Stridvall 29 Nov '02

29 Nov '02

> program/winetest doesn't exist anymore. Creating it empty is > enough for > msvcmaker to work, but is not the proper fix. I don't have the time > right now to check all the winetest references in msvcmaker > (there are > more than i thought). Working on it.

1 0

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
by Dan Kegel 29 Nov '02

29 Nov '02

Sylvain wrote: >> Thanks! >> It works fine with the version 2.96 I use. > Do you know RedHat's gcc 2.96 has SERIOUS bugs and that its support has > been totally dropped ? Support has been dropped by whom? Not Red Hat; they are still releasing updates for gcc-2.96-RH. The latest was 18 days ago, https://rhn.redhat.com/errata/RHBA-2002-200.html > It's update time. I agree, gcc 3.2[.1] is a better choice than gcc-2.96-RH these days. It is very close to compliance with the C++ ABI, and it's an official Gnu release rather than a vendor snapshot. (I'm building wine for the first time with gcc3.2 today, I hope I'm right about it being a better choice :-) - Dan

1 0

msvcmaker
by Vincent Béron 29 Nov '02

29 Nov '02

Hi all, program/winetest doesn't exist anymore. Creating it empty is enough for msvcmaker to work, but is not the proper fix. I don't have the time right now to check all the winetest references in msvcmaker (there are more than i thought). Vincent

1 0

RE: Janitorial Projects
by Patrik Stridvall 29 Nov '02

29 Nov '02

> What we need next: > 1. a way to run all tests. A batch file would do the job nicely. > Patrik, can that be added to msvcmaker? Planned but not done. However, since you asked for it, I will look into it right away.

1 0

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> On November 29, 2002 01:53 pm, Patrik Stridvall wrote: > > Not really, you haven't run ./configure on that tree have you? > > winapi_check assumes that this is done, but I can fix it if > > it irritates you. > > Oh, I have separate src/build trees, and I was running it in > the source tree. In fact, I _have_ to run it in the source > tree, and then I get the errors... OK. I will fix winapi_check to support that.

1 0

Re: somebody help me identify this bug please
by Jeff Smith 29 Nov '02

29 Nov '02

Is it only characters with the acute accent? Is it that your are attempting this using 'dead key' entry on a Spanish keyboard? If this is the case, the problem may be in a recent correction to the Spanish keyboard layout. I will work on this some more when I get a chance, but hopefully someone else will find something sooner. -- Jeff S >From: "ezra daniel" <ezra_daniel(a)hotmail.com> > >Hello, > >At work I use Lotus Notes under Wine. > >I downloaded compiled and installed the new wine version 20021125 and I am >no longer able to type accecented valves, like á é í ó ú. > >Ñ can be typed though correctly. > >With the other version 20021031 I could type accented valves.In fact I went >back to using the older version and worked again so it is obvious it is a >problem in the new wine version. > >Though I am a newbie and know nothing of developing, but I would like to >submit the bug to the proper person so it fixes it back again but I dont >know which section of wine or person deals with this character typing >problem. > >Can anyone point me in the right direction? Thanks in advance. > >-daniel >http://www.debian-gnu.com _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

RE: Winapi_check warnings
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Hi Patrik, > > I get these hundreds of warnings about "config.h": [snip] > First of all, I think they are bogus. Not really, you haven't run ./configure on that tree have you? winapi_check assumes that this is done, but I can fix it if it irritates you. > Second, if I specify the > --cross-call-win32-win16 flag, I expect to see only the problems > I am asking for, no? Shouldn't we silence all other warnings, if > we ask for something in particular? There is a --none option. winapi_check --none --cross-call-win32-win16 It doesn't always work though. Beware. However I fixed --cross-call-win32-win16 to support with my last patch, since I assumed somebody would ask. I was right it seems. Presumably you want the --progress option on as well: winapi_check --none --progress --cross-call-win32-win16

2 1

Winapi_check warnings
by Dimitrie O. Paun 29 Nov '02

29 Nov '02

Hi Patrik, I get these hundreds of warnings about "config.h": [dimi@dimi wine.src]$ tools/winapi_check/winapi_check --cross-call-win32-win16 dlls/d3d8/d3d8_private.h: #include "config.h" is not a local include dlls/ddraw/d3ddevice/main.h: #include "config.h" is not a local include dlls/ddraw/direct3d/main.h: #include "config.h" is not a local include controls/desktop.c: #include "config.h": file not found controls/desktop.c: #include "config.h" is not a local include controls/edit.c: #include "config.h": file not found controls/edit.c: #include "config.h" is not a local include controls/icontitle.c: #include "config.h": file not found controls/icontitle.c: #include "config.h" is not a local include controls/menu.c: #include "config.h": file not found controls/menu.c: #include "config.h" is not a local include dlls/advapi32/advapi.c: #include "config.h": file not found First of all, I think they are bogus. Second, if I specify the --cross-call-win32-win16 flag, I expect to see only the problems I am asking for, no? Shouldn't we silence all other warnings, if we ask for something in particular? -- Dimi.

1 0

RE: [RFC] Wine headers
by Patrik Stridvall 29 Nov '02

29 Nov '02

> Alexandre, > > Patrik brought up the header location sometime ago, in this thread: > http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540 > > At the time, I thought it is a bit premature, that we have other > things to do. Now I realize that this is one of those highly visible > external things, that would be a _lot_ better to fix before people > start using Winelib. Otherwise will piss people off when we change, > or we will not change because people are already using the headers. True. > Both versions are not good, and I think we can fix them now without > too much pain. > > Here is my proposal: > ${prefix}/include/win32 -- standard Win32 headers > ${prefix}/include/msvcrt -- MS Visual C Runtime library > ${prefix}/include/wine -- Wine specific headers > > It is simple (to understand & implement), clean, and pretty. > And I think it solved Patrik's problem (even if I can't quite > understand what the problem is from the first message :)), It not easy to mix different flavours of the Win32 headers because of include problems. The problem is that is you have since we include wine specific files like: #include "wine/debug.h" we need to have a include path like -I${prefix}/include However now since the Wine version of the standard Win32 header are in ${prefix}/include we get them included as well if we do -I${prefix}/include So if we do for example -I/opt/microsoft/windows/include we get header include collisions. Sure with GNU C on Linux (and presumably) on Windows we can fix that by specifing a correct include order. However with Microsoft C++ we can't do it in a portable way. With your suggestion above we can, so I like it. :-) > plus a bunch of other things (like making it easy to use other > headers for the Win32 API, etc). And best of all, it seems to > be easily implementable, no? "mv" is your friend however the CVS versioning doesn't like it though...

2 1

wglCreateLayerContext?
by Mike Hearn 29 Nov '02

29 Nov '02

Hi, This OpenGL method is currently a stub, looking at the MSDN documentation I can't see why this is the case given the fairly complete GL implementation Wine has. Is it that we cannot handle layering properly in X or something? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 4

somebody help me identify this bug please
by ezra daniel 29 Nov '02

29 Nov '02

Hello, At work I use Lotus Notes under Wine. I downloaded compiled and installed the new wine version 20021125 and I am no longer able to type accecented valves, like á é í ó ú. Ñ can be typed though correctly. With the other version 20021031 I could type accented valves.In fact I went back to using the older version and worked again so it is obvious it is a problem in the new wine version. Though I am a newbie and know nothing of developing, but I would like to submit the bug to the proper person so it fixes it back again but I dont know which section of wine or person deals with this character typing problem. Can anyone point me in the right direction? Thanks in advance. -daniel http://www.debian-gnu.com _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: final int21 move
by Jukka Heinonen 29 Nov '02

29 Nov '02

This patch series starts to look more like what it should be. Previous bugs seem to have been fixed and dependencies between winedos and other dlls have been reduced close to minimum. However, I still find some things that I don't particularly like: - The series is actually one big patch divided into multiple files and not a series of incremental changes. The first patch in series breaks DOS3Call and error reporting of some functions and these are only fixed in later patches. - Old int21 functions contain some obvious bugs that really should be fixed at the same time the code is migrated to winedos. - Move to winedos should not only migrate code but it should also try to rewrite code so that it has better comments, it is more readable and it uses simpler constructs. This patch series really messes up already complicated code. Intendations are irregular and weird. Many newlines are missing. Some internal functions use INT21_ prefixes and some don't. Functions that were implemented as separate helper functions are moved inside int21 main switch case. Three nested levels of switches are used without even proper indentation. And that comment about shooting people is tasteless and really doesn't belong to Wine. I just don't find the quality of this patch acceptable. I don't decide these things but my personal opinion is that I would rather rewrite this patch series than see it accepted in its current state. I wouldn't mind if Nog or someone else works on int21 migration (that's why I haven't posted int21 patches already) but I don't see why I ought to lower my quality requirements due to this fact. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: cabinet.dll broken?
by Tapio Kautto 29 Nov '02

29 Nov '02

Could cabinet be set to: "cabinet" = "native,builtin" automatically by wineinstall as long as it does not work the way expected? Tapio On Thursday 28 November 2002 12:59, Patrik Stridvall wrote: > > I'm trying to install MS Office 2000 on wine-20021125. > > > > I get an error from Office installer: > > > > Internal error 2352. Please contact Product support. > > > > I found an advice to repair my cabinet.dll in Microsoft Support pages. > > > > The file is in ~/c/windows/system, and it's readable. Does > > anyone else have > > problem with this? > > Well. It might be that since very recently, Wine has builtin > stub implementation of cabinet.dll. > > Of course it shouldn't be used automatically if have a cabinet.dll, > since I guess most people (including you) have a: > > [DllOverrides] > ; default for all other dlls > "*" = "native, builtin, so" > > entry in their config file. > > You can force cabinet to native with > wine --dll cabinet=n > though.

1 0

Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
by Dustin Navea 29 Nov '02

29 Nov '02

Vincent, Alexandre, and Dimi Grrr, Im really starting to not like Linux's PPPoE support... I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that they fix problems with my setup... so until next Wednesday I will probably just lurk on the lists -Dustin

2 2

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch 29 Nov '02

29 Nov '02

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

Re: Last one for today :-)
by Vincent Béron 28 Nov '02

28 Nov '02

Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit : > re-reHi... > > This patch implements the 'GetRenderTarget' method for the IDirect3DDevice > COM object. It is independant from all previously submitted patches (but to > prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix). > > With this series of patch, the Boids demo from the DX6 SDK is now running > (it's not working because we are lacking some D3D code, but at least it does > not crash :-) ). > > Changelog: > - implement GetRenderTarget A bit too much work on your part I bet, as you forgot to attach the patch ;-) Vincent

1 0

wine & preempt patch (fwd)
by Matthias Rieber 28 Nov '02

28 Nov '02

Hi, is there are known issue with the preempt patch for the kernel? When I apply that patch, non-open-gl games doesn't run smooth, without the patch they run nearly smooth (especially StarCraft & BaldursGate). OpenGL games are alway fine. matthias

1 0

How to debug wineserver
by Rajesh Akkineni 28 Nov '02

28 Nov '02

hi, is there any way we can debug the wineserver? thanks Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

3 2

Modifying registers
by Fabian Cenedese 28 Nov '02

28 Nov '02

Hi Is there already a possibility to view/set the actual program counter in winedbg? I couldn't find anything in the manual. And it's not possible to work with EIP. This would be useful e.g. to jump over some unwanted code or call a function a second time. Generally, is there a way to modify registers? Must be obvious but I'm blind. Thanks bye Fabi

3 3

Chronic crash on Photoshop
by Robert North 28 Nov '02

28 Nov '02

Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.

1 0

compiling wine under cygwin - status
by David Fraser 28 Nov '02

28 Nov '02

Hi all This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully. The significant compilation problem is in server/context_i386.c: You must implement get/set_thread_context for your platform. Basically there's some code that does the threading stuff which is platform-specific. There are Linux and BSD and Sun variants, none of which work under cygwin ... Basically sys/ptrace.h is what's missing. This lets the process interrupt a child process and get/set its registers. Does anyone have any idea what the best way to write a replacement for cygwin would be? Maybe I need to ask the cygwin list. My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-) David dlls/ advapi32 has errors avicap32 has errors avifil32 has errors cabinet has errors comcat links comctl32 links commdlg has errors crtdll has errors crypt32 links d3d8 has errors dciman32 links ddraw has errors devenum links dinput links dinput8 links dplay links dplayx links dsound has errors gdi has errors glu32 links icmp links imagehlp links imm32 links kernel has errors lzexpand has errors mapi32 links mpr links msacm has errors msdmo links msimg32 links msisys has errors msnet32 links msvcrt has errors msvcrt20 has errors msvideo has errors netapi32 links ntdll has errors odbc32 links ole32 has errors oleaut32 has errors olecli has errors oledlg links olepro32 links olesvr has errors opengl32 has errors psapi has errors qcap links quartz links rasapi32 links richedit has errors rpcrt4 links serialui links setupapi has errors shdocvw links shell32 has errors shfolder links shlwapi links snmpapi links sti links tapi32 links ttydrv has errors twain has errors url links urlmon has errors user has errors version has errors win32s has errors winaspi has errors winedos has errors wineps has errors wininet has errors winmm has errors winnls has errors winsock has errors winspool has errors wintrust links wow32 links wsock32 links x11drv has errors library/ libwine.dll links successfully miscemu/ requires ntdll.dll ole/ libwine_uuid.a links successfully programs/ avitools/aviinfo.exe links avitools/aviplay.exe links clock/clock.exe links cmdlgtst/cmdlgtst.exe links control/control.exe links expand/expand.exe links osversioncheck/osversioncheck.exe links progman/progman.exe links regapi.exe/regapi.exe links regsvr32/regsvr32.exe links regtest/regtest.exe links uninstaller/uninstaller.exe links view/view.exe links wcmd/wcmd.exe links winefile/winefile.exe links winemine/winemine.exe links winepath/winepath.exe links winhelp/winhelp.exe links winhelp/hlp2sgml.exe links winver/winver.exe links winhelp.exe links server/ context_i386.c has compile error (You must implement get/set_thread_context for your platform) tools/ bin2res.exe links fnt2bdf.exe links makedep.exe links widl/widl.exe links winebuild/winebuild.exe links winedump/winedump.exe links wmc/wmc.exe links wpp/libwpp.a links wrc/wrc.exe links unicode/ libwine_unicode.dll links libwine_unicode.a links

2 3

RE: Missing SignalObjectAndWait
by Sean Mitchell 28 Nov '02

28 Nov '02

> I think that the first problem is that if foo.exe.so links with > libpthread.so, then libpthread.so gets loaded and initialized before > ntdll.dll.so is loaded and overrides the pthread functions in the C > library -> big trouble. > > This migh conceivable be worked around using a wrapper like I > described > for libmfc.so except this time the wrapper would just load libntdll.so > and the wrapped executable would link with libpthread.so. > > Then I guess it should work since threaded opengl libraries > are supposed > to work. > > But is there really an advantage to using pthread rather than > the Win32 > threading functions when porting a Windows application? After all one > should not have to change the code when porting with Winelib... Without SignalObjectAndWait() I imagine that many medium sized to large apps would have to consider alternative threading libraries... the app I'm trying to port uses it quite a bit to prevent race conditions. As an interested party rather than a developer I'd suggest that the effort would be best spent implementing SignalObjectAndWait() before worrying about pthread compatibility, but I don't know the extent of the work involved. For my own porting project I'm now considering at a "clean" port without any Windows calls - fortunately we only use the thread calls and some file system calls from the Win32 API - but I suspect that this might present a roadblock to other projects hoping for a painless port. In any case, you folks have done a great job with Wine and winelib, and I thank you for it. Cheers, Sean

1 0

Access Database
by Fabian Cenedese 28 Nov '02

28 Nov '02

Hi My app works with an Access mdb. Opening and reading goes fine. The problem comes with writing. There is a table called "Nodes". I delete it and then create a new one to fill in my data. For some strange reason the table gets created but with a name "Node", the s was munched. Even more strange that it works with other tables after this one. I already stepped through the MFC.dll and checked critical places (strlen, SysAllocString etc) but it always looked fine. Did anyone ever had something similar? Or can work with mdbs without problems? Thanks bye Fabi

1 0

SystemTimeToTzSpecificLocalTime()
by Martin Fuchs 28 Nov '02

28 Nov '02

Hello, what has happend with my patch for SystemTimeToTzSpecificLocalTime() and TzSpecificLocalTimeToSystemTime()? It has not been commited yet, and I didn't see any comments on it. Are there any problems with it? -- Martin Fuchs martin-fuchs(a)gmx.net

1 0

RE: Missing SignalObjectAndWait
by Sean Mitchell 28 Nov '02

28 Nov '02

> Sent a patch to wine-patches for this one and the _set_error_mode() > constants. With the patch applied your application should > compile fine. > > However note that _set_error_mode() and SignalObjectAndWait() are both > stubs currently, which means that functionality is not implemented. So > if your application calls either of them it will crash... Ah... gotcha. I may just port the thread object to pthreads and be done with anyway. Thanks. Sean

3 4

What about the MONITORINFOEX fix?
by Dimitrie O. Paun 28 Nov '02

28 Nov '02

Alexandre, What happened with this patch by Patrik: http://www.winehq.com/hypermail/wine-patches/2002/11/0241.html I still have an ugly hack in my tree, and I was curious what you have in mind for that? -- Dimi.

2 2

Doc building update, finally
by Dustin Navea 28 Nov '02

28 Nov '02

Vincent, I finally got SGMLtools installed and went to build the doc. Only problem is that instead of it outputting to files it prints the output on screen. Is there a flag that I may be missing or what? I'm using SGMLTools pre-compiled and built.. Downloaded from ftp://ftp.slackware.com/pub/slackware/slackware-current/extra/sgml-tools-1.… and installed using pkgtool which comes with slackware.. -Dustin P.S. Any outputs you need say from man or --help on docbook2html?

4 4

Re: A few trivial Unicode-Ascii fixes
by Dmitry Timoshkov 28 Nov '02

28 Nov '02

"Matthew Davison" <m.davison(a)virgin.net> wrote: > changelog: > A few Trivial Unicode-Ascii cross-call fixes Actually, since our loader code is not using unicode internally at all and therefore your "fixes" just add superfluous conversions from ANSI to Unicode and back, I think that real fix would be to convert loader to unicode first and only then clean things up. -- Dmitry.

1 0

Re: Again Warcraft 3 - Wine CVS 20021125
by Sylvain Petreolle 28 Nov '02

28 Nov '02

I say to you it isn't the case. :) > Do not hate me, please. > > After download of CVS snapshot I compiled it from a dir in my home > (/home/leo/wine). There is winedefault.reg, but I do not understand > if wine > reads it or the user.reg and system.reg in my .wine/ dir The emulation of registry is based on .wine/system.reg =>HKEY_LOCAL_MACHINE and user.reg => HKEY_CURRENT_USER. At the very start of wine these 2 files are empty/nonexistent => the registry is empty. To initiate it, you must import values into it via the program regedit. Default values that works well are in winedefault.reg. When you issue 'regedit winedefault.reg', this file is read and its values are imported into system.reg and user.reg. Now your debugger problem : you have installed a previous version some months ago and wine architecture changed. winedbg isn't at the same place as before. You have the old value in system.reg so wine doesn't find it anymore. running 'regedit winedefault.reg' will update your old values with new ones and set the correct location for the debugger. (and many others) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Doc building update, finally
by Dustin Navea 28 Nov '02

28 Nov '02

----- Original Message ----- From: Tony Lambregts <tony_lambregts(a)telusplanet.net> To: Dustin Navea <speeddymon(a)ev1.net> Cc: <wine-devel(a)winehq.com> Sent: Wednesday, November 27, 2002 11:30 AM Subject: Re: Doc building update, finally > Dustin Navea wrote: > > >Vincent, > > > >I finally got SGMLtools installed and went to build the doc. Only > >problem is that instead of it outputting to files it prints the output > >on screen. Is there a flag that I may be missing or what? I'm using > >SGMLTools pre-compiled and built.. Downloaded from > >ftp://ftp.slackware.com/pub/slackware/slackware-current/extra/sgml-tools-1. 0.9-i386.tgz > >and installed using pkgtool which comes with slackware.. > > > >-Dustin > > > >P.S. Any outputs you need say from man or --help on docbook2html? > > > > > > > Well you are not the only one. I manually changed "SRCDIR = ." to RCDIR > = .." in Makefile to make it work for me. The problem has shown up on > bugzilla too. (bug 1164) http://bugs.winehq.com/show_bug.cgi?id=1164 > > Ahh, I knew I remembered seeing something about that issue here but couldnt > remember the fix. I will try that tonight when I get home from work.. > > > > > I think that Vincent has not given up on this (yet?) However its not a > simple fix since various distributions have thier db2html and docbook2html > set up differently. he mentioned bypassing the whole issue by using our own > db2html-winehq instead. I have mixed feelings about this but I see no other > solution other than making configure unbearably complicated. > > Hmm, I remember that someone had a copy of *2html that had -d set up to > putput to dvi, what version of *2html was it? Maybe its the fact that it is > an old version or that it isnt the standard jadewrapper? Either way, why > not have configure check how to specify the .dsl file in much the same way > we check for certain gcc flags? Or is that not possible? > > > > > As far as your output what are the first couple of lines from "make html > > make.log" > > I will post it when I get home from work.. > > -Dustin >

2 1

RE: Coding standards
by Medland, Bill 27 Nov '02

27 Nov '02

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin@winehq.com]On > Behalf Of David Laight > Sent: Wednesday, November 27, 2002 1:34 AM > Cc: wine-devel(a)winehq.com > Subject: Re: Coding standards > > > > >Probably vi with autoindent, tabstop=8 and shiftwidth=4 > (my preferred indent). > > > > Of course everyone has his own taste and there's nothing > wrong with 8. We > > just found that with 8 spaces there's very much indentation > if you have quite > > some nested ifs/whiles/fors/whatevers. While still trying > to stay under 80 > > chars per line (for a nice printing) you don't have much space left > > to put code on :) > > Indeed - printing in one reason you should not set the tab size to > anything other than 8. > > With vi and sw=4,ts=8,ai you indent with ^T and outdent with ^D. > vi adds the correct number of tabs and spaces to end up in the > right position. which is what I hate. This is the worst of both worlds. Either use Tabs throughout so that a tab equals an indent and so people can set the tab size to whatever they like or else don't use tabs at all and use explicit spaces. (The usual argument for using tabs relates to the fact that they line up with proportionally spaced fonts but I don't think that worries us does it; I almost always use a fixed font for code display). I would argue in favour of using tabs for indent if it were not for the fact that we already have an enormous amount of code that doesn't and I doubt if we would refuse code that didn't. > > 8 char indents (as used by netbsd) to tend to leave you trying to > pretify code in about 16 colums sometimes. > Made more likely if your style involves 2 indents for a switch > statement, eg: > switch (...) { > case ...: > break; > > David > > -- > David Laight: david(a)l8s.co.uk > > Bill Medland

3 3

Warcraft 3 - Wine CVS 20021125
by Leonardo Giordani 27 Nov '02

27 Nov '02

Hi, I'm trying to run Warcraft 3 with wine CVS build 20021125. I followed the Jesse Allen HOWTO but I get these messages -bash-2.05b$ winelauncher War3.exe Loading required GL library /usr/X11R6/lib/libGL.so.1.2 err:ntdll:RtlpWaitForCriticalSection section 0x400f7190 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=096b7c00 wine: Unhandled exception, starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 134696360 96") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger Wine failed with return code 1 I do not understand what is wrong... Here is my config file (only relevant sections). Someone is experiencing the same problem? Thanks Leo config: [wine] "Windows" = "C:\\Windows" "System" = "C:\\Windows\\System" "Temp" = "X:\\" "Path" = "C:\\Windows;C:\\Windows\\System;X:\\;Y:\\" "GraphicsDriver" = "x11drv" ; Wine doesn't pass directory symlinks to Windows programs by default. ; Enabling this may crash some programs that do recursive lookups of a whole ; subdir tree in case of a symlink pointing back to itself. ;"ShowDirSymlinks" = "1" "ShellLinker" = "wineshelllink" # <wineconf> [version] "windows" = "win98" [DllOverrides] "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "ver" = "builtin, native" "version" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "lzexpand" = "builtin, native" "lz32" = "builtin, native" "comctl32" = "builtin, native" "commctrl" = "builtin, native" "advapi32" = "builtin, native" "crtdll" = "builtin, native" "mpr" = "builtin, native" "winspool.drv" = "builtin, native" "ddraw" = "builtin, native" "dinput" = "builtin, native" "dsound" = "builtin, native" "opengl32" = "builtin, native" "msvcrt" = "native, builtin" "rpcrt4" = "native, builtin" "msvideo" = "builtin, native" "msvfw32" = "builtin, native" "mcicda.drv" = "builtin, native" "mciseq.drv" = "builtin, native" "mciwave.drv" = "builtin, native" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msacm.drv" = "builtin, native" "msacm" = "builtin, native" "msacm32" = "builtin, native" "midimap.drv" = "builtin, native" ; you can specify applications too "notepad.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native, so" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens "ScreenDepth" = "16" ; Name of X11 display to use ;;"Display" = ":0.0" ; Allow the window manager to manage created windows "Managed" = "N" ; Use a desktop window of 640x480 for Wine "Desktop" = "1024x768" ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) "UseDGA" = "Y" ; Use XShm extension if present "UseXShm" = "Y" ; XVid "UseXVidMode" = "N" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "Y" ; Code page used for captions in managed mode ; 0 means default ANSI code page (CP_ACP == 0) "TextCP" = "0" ; Use this if you have more than one port for video on your setup ; (Wine uses for now the first 'input image' it finds). ;; "XVideoPort" = "43" ; Run in synchronous mode (useful for debugging X11 problems) "Synchronous" = "N" [fonts] ;Read documentation/fonts before adding aliases ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" ;; default TrueType fonts with russian koi8-r encoding ;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;; default cyrillic bitmap X fonts ;"Default" = "-cronyx-helvetica-" ;"DefaultFixed" = "fixed" ;"DefaultSerif" = "-cronyx-times-" ;"DefaultSansSerif" = "-cronyx-helvetica-" [serialports] "Com1" = "/dev/ttyS0" "Com2" = "/dev/ttyS1" [parallelports] "Lpt1" = "/dev/lp0" [spooler] "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;"read" = "0x779,0x379,0x280-0x2a0" ; "write" = "0x779,0x379,0x280-0x2a0" [spy] "Exclude" = "WM_SIZE;WM_TIMER;" [registry] ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Tweak.Layout] ;; supported styles are 'Win31'(default), 'Win95', 'Win98' "WineLook" = "Win95" [Console] ;"Drivers" = "tty" ;"XtermProg" = "nxterm" ;"InitialRows" = "25" ;"InitialColumns" = "80" ;"TerminalType" = "nxterm" [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" ; List of all directories directly contain .AFM files [afmdirs] "1" = "/usr/share/ghostscript/fonts" "2" = "/usr/share/a2ps/afm" "3" = "/usr/share/enscript" "4" = "/usr/X11R6/lib/X11/fonts/Type1" [WinMM] "Drivers" = "wineoss.drv" "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" # </wineconf> ------------ Leonardo Giordani leo.giordani(a)libero.it

2 3

Winelib Apps page
by Jeff Smith 27 Nov '02

27 Nov '02

Dimi, I like the idea of color-coding the apps for their status. But if you are going to change the background, you need to change the foreground as well. Many browsers make links blue or red (and other colors for 'active' and 'visited' links) by default. In some cases, these clash with the background (blue on red). In others there is not enough contrast (blue on grey). Please find colors that work well and integrate that info into your stylesheet. My vote is for black for all. For example (please note that this is untested, so I may have indicated the wrong attribute for this case): .todo {background-color: red; color: black} -- Jeff S _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

RE: Coding standards
by Medland, Bill 27 Nov '02

27 Nov '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dpaun@rogers.com] > Sent: Wednesday, November 27, 2002 10:04 AM > To: Medland, Bill; Wine devel (E-mail) > Subject: Re: Coding standards > > > On November 27, 2002 12:45 pm, Medland, Bill wrote: > > which is what I hate. This is the worst of both worlds. > Either use Tabs > > throughout so that a tab equals an indent and so people can > set the tab > > size to whatever they like or else don't use tabs at all > and use explicit > > spaces. > > And what's so bad about mixing spaces and tabs? Using only tabs is > (1) hard/impossible to enforce, and (2) still suffers from deviation > from the standard. It maybe workable in a company, but not on the > internet. > > On the other hand, what's the big deal with mixing tabs and spaces? > What's the big loss as compared to only spaces? This is just trying > to impose (silly) policy on people. As long as we stick to the > standard meaning of tab (which is 8, there's no question about it. > What do you get when you send a file to the printer? Or open it in > a non-customized editor?), there is no need whatsoever to force > people into this or that way. And this without a loss for anyone! > > Why do people feel a need to force others into certain way of doing > things, when the end result is the same?!? This is like forcing > people to QWERTY instead of DVORAK... I'm not against standards, > I would actually like if we had more uniform looking code, but this > is really unnecessary, as it serves no purpose. > > -- > Dimi. > Sorry if you thought I wanted to force people to do something "my way"; that is far from the truth. Personally I work hard at using four space indent and no tabs at all. (I have experience of working with a lot of code maintained by some people who work with a four-space tab and some who work with 8 and so am fed up with having to keep swapping between two settings. Therefore I try and avoid tabs.) However my own opinion is that one should fit in with the existing local conventions. You are right; provided everyone sticks to 8-space tabs then it doesn't matter. But if one only uses spaces then it doesn't matter one way or the other. I merely offer this as a suggestion for people to consider. Bill

2 1

RE: Whither SwitchToThread()?
by Patrik Stridvall 27 Nov '02

27 Nov '02

> On November 27, 2002 10:55 am, Sean Mitchell wrote: > > I told my boss that I posted the query last night and had a > response with a > > fix waiting for me this morning. He is lukewarm about Open > Source, but when > > I told him about this he was very, very impressed. He's > never seen that > > sort of response from a commercial vendor except in a few emergency > > situations. > > It's hard to explain this to people without them experiencing > it, isn't it? > I have tried several times to explain it, but I sound as I'm > exagerating > every time... :) On the other hand, response from commercial > vendors of > large apps has always been bad for me. Real bad. Oh well... > > > Incidentally, should I open a bug for this, or is it > already committed to > > the tree? > > It's not commited, but I would not bother with it. The patch is in > Alexandre's queue, and it should make it in the tree anytime now. Hmm. Which reminds me. In theory we could do even better. Since Alexandre has to approve each patch we get a slightly larger "turnaround" time for "obvious" fixes like the one this thread is about. So why not have a special CVS tree (or perhaps branch of the current tree) for Winelib users where anybody of the regular Wine developers could check in "obvious" fixes for immediate use. Lets impress even more people of our quick response. :-) While this perhaps is 1. Perhaps something CVS is unsuited for (but Alexandre said we might switch to Subversion eventually). 2. Perhaps something that should wait until post 1.0 it might be worth discussing.

4 3

Whither SwitchToThread()?
by Sean Mitchell 27 Nov '02

27 Nov '02

My apologies if this is the wrong list for this question... it seemed the most appropriate on the list. I'm doing a proof-of-concept for my boss to demonstrate that we can port a large-ish application developed on Windows (using mostly crossplatform libraries like wxWindows, STLport, Xerces) to Linux using winelib to cover a few WIN32 API calls we've made. I've just started into it, and have compiled a dozen files so far, but ran into trouble with the thread code. I cannot find SwitchToThread anywhere, not even in the winbase.h header file I expected it in. There are some changelogs to indicate that it exists, and the symbol does live in libntdll.dll.so, but I cannot find a header file that defines it. Can anyone point me in the right direction? Cheers, Sean +----------------------------------------------------------+ | Sean Mitchell Phoenix Interactive Design | | Software Engineer 137 Dundas St | | smitchell(a)phoenix-interactive.com London, ON | | 519-679-2913 x237 Canada | | 519-679-6773 fax N6A 1E9 | +----------------------------------------------------------+

5 5

MS MediaPlayer
by Rajesh Akkineni 27 Nov '02

27 Nov '02

Hi all, Just today i have joined the mailing list. I hope i can find solutions for my problems here. Actually i am working with MS MediaPlayer (v7 I think). When i try that progam with debugger, the program is stopping with some 7 to 8 hreads running..and all the threads are stpping in the method "ConnectNamedPipe" When I have searched the MSDN about it..i came to know that it will return only when one of the two methods("CreateFile", CallNamedPipe") are called. I have kept a Break point on the "ConnectNamedPipe" and the program is stopping at that medhod.. But when i tried to set a BreakPoint in "CreateFile" and "CallNamedPipe" it dose not find the method in any of the DLLs. In which DLL the both methods are present? Why i am not able to find their definition to set the BreakPoint. How to make the program to procede further?? Any one working on the same program? (MS Media Player) thank all for any help, Rajesh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

RE: Missing SignalObjectAndWait
by Sean Mitchell 27 Nov '02

27 Nov '02

> Wine and pthreads don't play well together. You are quite > likely to get into trouble if you try to use pthreads from a > Winelib application. Ack! Good to know that now... what about other native Linux libraries (like wxgtk, stlport, boost) than might link with pthreads? Am I in for big trouble here? Surely other projects using winelib must be threaded? Sean

1 0

Missing SignalObjectAndWait
by Sean Mitchell 27 Nov '02

27 Nov '02

No sign of SignalObjectAndWait() in header files either :-( Sean

2 1

Re: final int21 move (2/11)
by Dimitrie O. Paun 27 Nov '02

27 Nov '02

On November 27, 2002 12:37 pm, György 'Nog' Jeney wrote: > ChangeLog: > * dlls/winedos/int21.c > * msdos/int21.c > * include/msdos.h > * files/dos_fs.h > * include/file.h > Move Find{First|Next}{FCB|} fucntions to winedos. Dude, where's the patch? :) -- Dimi.

2 1

Re: final int21 move (7/11)
by György 'Nog' Jeney 27 Nov '02

27 Nov '02

> ChangeLog: > * dlls/winedos/int21.c > * msdos/int21.c > * dlls/ntdll/Makefile.in > * dlls/winedos/Makefile.in > * include/miscemu.h > * dlls/winedos/dosexe.h > * dlls/winedos/dosconf.c > Move fucntion 33h to winedos. > > nog. That mail had the wrong file attached. Use this one instead. I also forgot to state that you should remove msdos/dosconf.c. nog.

1 0

complie fails on _set_error_mode(_OUT_TO_STDERR)
by Sean Mitchell 27 Nov '02

27 Nov '02

Hullo All.... I think I've found another missing bit. My compile fails on _set_error_mode(_OUT_TO_STDERR) because it seems that none of the modevals are defined in msvcrt/stdlib.h http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/ vcref_set_error_mode.asp I'll just use an integer for now, but this might warrant looking at... again, is it appropriate for me to open a bug for this? Cheers, Sean +----------------------------------------------------------+ | Sean Mitchell Phoenix Interactive Design | | Software Engineer 137 Dundas St | | smitchell(a)phoenix-interactive.com London, ON | | 519-679-2913 x237 Canada | | 519-679-6773 fax N6A 1E9 | +----------------------------------------------------------+

1 0

Announce: Vstserver, vstlib, vstladspa and k_vst~
by Kjetil S. Matheussen 27 Nov '02

27 Nov '02

VSTServer V0.0.1. ----------------- First release. Beta, but usable. ABOUT Vstserver is a wine program that must be running when using programs using vstlib. Vstlib is a library that can be used by programs to run windows vst audio plugins under linux/freebsd/i386solaris/etc. RUNNING Vstserver is started like this: "wine vstserver.so". You probably want to set the "VST_PATH" environment variable pointing to your plugins first. DEVELOPMENT Vstserver is released under the GPL, and vstlib under LGPL. If there comes many source-contributions, I will probably make it a sourceforge project. To use vstlib in a program, look at the tests/exampleclient program, and various vst plug-in documentation. The interface to the vstlib consists only of two functions (new/delete), the rest is like you would do when programming for windows, macos(X), beos, irix, etc. CURRENT STATUS Vstserver seems to be very stable. I have not found any plug-ins that wont run, and I am not able to hear any latency. And plug-ins does not seem to cause more cpu-power than under windows. No GUI or graphics-support yet. BUGS 1. When running the ladspa "listplugins" program many times in a row, I get the following errors before the server freeze: err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn=0000 err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. I dont know what this is. Its not errors coming from the vstserver program. It seems to be related to X, allthough no graphics is used in the vstserver. I hope its just the buggy libXrender.so library that wine shouts about each time it starts. 2. Shared memory handlig might be faulty. I suspect that it doesnt free resources. (see server/shmhandler.c) 3. I havent read the vst plug-in documentation yet, and dont know everything about it. This especially goes for the "AudioMasterCallback" function, which for now just returns 1. I guess some more work needs to be done in this area, and for the various dispatch opcodes too. 4. The processReplacing function in vstlib should perhaps be made just by calling the process fuction. But I dont understand the difference between processReplacing and processing. FUTURE Add GUI and graphics support to the server (help wanted). And maybe make a DX-plugin server. (would be fun running pi-warp under linux). CREDITS vstserver and vstlib are made by Kjetil S. Matheussen / Notam. k.s.matheussen(a)notam02.no Some programming hints is gathered by looking at the pd vst-object plugin~ source and the jack soundserver source. vst ladspa plugin v0.0.1 - alpha --------------------------------- Makes vst plugins located in $VST_PATH appear as ladspa plugins. I'm not sure how well this one actually works. The northpole plugin seems to work, but others don't. Oh well, its alpha for now. k_vst~, a Pd tilde object for hosting VST plug-ins. --------------------------------------------------- This is really just the plugin~ source made by Jarno Seppänen, but with a few lines changed (very few that is) to make it work with vst-plugins using the vstlib. The name was changed from plugin~ to k_vst~ to avoid nameclash with the plugin~ object running ladspa plugins. This object is for i386 non-windows (ie. linux/freebsd) only. This one works very well! ------------------------- vstserver, ladspavst and k_vst~ are open-source programs made at Notam / Oslo, and can be downloaded from from http://www.notam02.no/arkiv/src/ --

1 1

Help needed - CreateScalableFontResource
by Shachar Shemesh 27 Nov '02

27 Nov '02

Hi list, We have in Israel a lawyer who has cought on to the idea of open source, and is helping "The Cause"(tm) here quite a lot. As part of his activities he is wants to demonstrate a Hebrew law and precedance lookup program at a conference on Dec 2nd using Wine, and he asked for my help. When trying to run the program, I get the following error: sun@sun:~/c/PD_OR/EXE$ LANG=he_IL wine PDWIN G Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.485, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for USER.491, setting to 0xdeadbeef fixme:win:stub_USER_490 stub fixme:font:CreateScalableFontResourceA (0,"C:\\PD_OR\\FONTS/AMIR____.FOT","C:\\PD_OR\\FONTS/AMIR____.TTF",(null)): stub fixme:font:CreateScalableFontResourceA (0,"C:\\PD_OR\\FONTS/AMIRBLD_.FOT","C:\\PD_OR\\FONTS/AMIRBLD_.TTF",(null)): stub fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. The application then goes on to display a error message saying (In hebrew) "The fonts for the application could not be found, please reinstall...". The fonts are indeed available in C:\PD_OR\FONTS as TTF files. It seems the application calls CreateScalableFontResource, and then tries to register the fonts. Copying the TTF fonts to the fonts directory did not solve this problem. I am looking for some solution, even a workaround, that will solve this problem for me. I have contact with the application's developers, and they are very interested in getting this to work (not interested enough to actually install Linux, but they are interested enough to answer technical questions about the app). My questions: A. Is there any way I can patch Wine to fool the app into thinking that part succeeds? Or is performing this test necessary, for some strange reason, in order to use the TTF fonts? B. It MAY be possible to ask the developers to actually modify their code to a moderate degree, in order to get this app to work. Is there anything in particular I can ask them? C. Is anyone working on this API? I don't know the first thing about font files and resources, and while I CAN learn, is someone with already existing knowledge can do something about it, it would be much preferable. Thanks, Shachar

3 8

Getting DirectX emulation to work
by David D. Hagood 27 Nov '02

27 Nov '02

Since I can no longer get OpenGL textures to work under Wine, I'd like to try to get the DirectX emulation working. However, when I configure an app to use DirectX, I get a "You have selected a mode your graphics card does not support" message. Since the color depth and resolution are the same as OpenGL settings that work (save for the hosed textures), I would think this should work. Are there some magic registry entries that need to be created?

3 2

RE: Whither SwitchToThread()?
by Sean Mitchell 27 Nov '02

27 Nov '02

> -----Original Message----- > From: Francois Gouget [mailto:fgouget@free.fr] > To: Sean Mitchell > Because someone forgot to update winbase.h, that's all. Use > this patch: Thanks so much! I told my boss that I posted the query last night and had a response with a fix waiting for me this morning. He is lukewarm about Open Source, but when I told him about this he was very, very impressed. He's never seen that sort of response from a commercial vendor except in a few emergency situations. Incidentally, should I open a bug for this, or is it already committed to the tree? Cheers, Sean

2 1

Re: Winelib Apps v0.1
by Mark Hannessen 27 Nov '02

27 Nov '02

very nice site. but there is one ( very ) small i would like to see. i think colors should represent the status of winelibs mozilla has a yellow color ( but does not run ) once a prog runs ( putty ) it should be green ( or some other color ) this way we can easily see what works and what does not perhaps we could include a link to the project website as well ? Mark Hannessen On Tuesday 26 November 2002 06:04, wine-devel-request(a)winehq.com wrote: > Folks, > > Version 0.1 of the Winelib Applications page is available here: > http://www.dssd.ca/wine/Winelib-Apps-0.1.html > > The current version is always available at this address > http://www.dssd.ca/wine/Winelib-Apps.html > > Your comments, and suggestions are highly appreciated.

6 13

IKernel fails
by Uwe Bonnes 27 Nov '02

27 Nov '02

Hallo, Altera's Quartus Web-Edition https://www.altera.com/support/software/download/altera_design/quartus_we/d… (110 MByt Download) fails: fixme:ole:_xread Read only 0 of 4 bytes from 0x50. fixme:ole:_StubReaderThread Failed with hres 80004005 Any help welcome! Are more Info needed? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 3

tools/wpp, ppdebug
by Tapio Kautto 27 Nov '02

27 Nov '02

Hi! I'm trying to compile recent versions of wine with Debian Sid. My compile stops in wpp saying that variable ppdebug is not defined. I added line int ppdebug=1; in wpp.c, and it compiles. Am I missing something, or is this a bug? Thanks, Eleknader

1 0

Re: Coding standards
by David Laight 27 Nov '02

27 Nov '02

> I found a couple that used ~4space indent, and used tabs too (they > seemed to expect 1tab = 8, as the code looked neat in a standard text > editor). Probably vi with autoindent, tabstop=8 and shiftwidth=4 (my preferred indent). More fun can be had arguing over whether to do: if (...) { ... } else { ... } or: if (...) { ... } else { ... } or: if (...) { ... } else { ... } If you have a paper listing you definitely need '} else {' on a single line. Otherwise you lose track of the control flow when reading it. (Never mind that you get many more lines on a page/screen.) Of course the opening '{' for a function MUST be in column 1. A coding standard really ought to discuss namespace usage and pollution. Any reasonable layout is usually ok. (OTOH I much prefer that tab stops be at 8 character intervals.) David -- David Laight: david(a)l8s.co.uk

6 8

Performance issues
by João Alfredo 27 Nov '02

27 Nov '02

Hello people, How can i improve performance in GUI applications under wine? I have a cobol application here made with microfocus netexpress and I can see the button icons reloading every type I refresh the screen. I'm using wine from CVS with a PIII 900Mhz redhat 7.3 box. Thanks in advance! -- João Alfredo G. Batista <joaoalf(a)dotx.com.br> ou <jagbdotx(a)yahoo.com.br> * dotX Consultoria, Serviços e Conectividade * http://www.dotx.com.br * Departamento de Desenvolvimento

1 0

Wine app
by Fabian Cenedese 27 Nov '02

27 Nov '02

Hi I came across this page: http://www.unrealized.com/references/ "Unfortunately we have no information on running UnrealEd in Linux. Perhaps someone has had success running it under WINE? If so, please let us know about it so we can get more information for others trying to run UnrealEd on their Linux box." So I guess they would like to hear if someone had success and would also put a "works with wine" on their page once it's running. bye Fabi

1 0

Run .bat files
by Fabian Cenedese 27 Nov '02

27 Nov '02

Hi I found out that I can't run batch files directly. It gives me "cannot determine executable type". Maybe there is a possibility to start it right away with wcmd or wineconsole. The problem is that it must also work if a running app calls the batch files with CreateThread. Could it be a solution to add a new type to MODULE_GetBinaryType and then start a console with the batch file argument? If this is already too late, is there another possibility inside wine? Would it work if I change the call to CreateThread("cmd file.bat")? But then it has to work on all Windows95, NT and wine (command.com, cmd.exe, wcmd). Thanks bye Fabi

3 3

Problem in winemaker
by Sylvain Petreolle 27 Nov '02

27 Nov '02

Trying to debug the cygwin installer that isn't able to reread where it saves the pakages, I wanted to compiler the installer as Winelib. running 'winemaker .' in setup source dir fails when analysing IOStreamProvider.h, at line 1193 in winemaker. I attached the file. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com /* * Copyright (c) 2002, Robert Collins. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * A copy of the GNU General Public License can be found at * http://www.gnu.org/ * * Written by Robert Collins <rbtcollins(a)hotmail.com> * */ #ifndef _IOSTREAMPROVIDER_H_ #define _IOSTREAMPROVIDER_H_ #include "io_stream.h" #include "String++.h" /* An IOStreamProvider provides the interface for io_stream::open and * related calls to operate. */ class IOStreamProvider { public: virtual int exists (String const &) const = 0; virtual int remove (String const &) const = 0; virtual int mklink (String const &, String const &, io_stream_link_t) const = 0; virtual io_stream *open (String const &,String const &) const = 0; virtual ~IOStreamProvider (){} virtual int move (String const &,String const &) const = 0; virtual int mkdir_p (enum path_type_t isadir, String const &path) const = 0; String key; // Do not set - managed automatically. protected: IOStreamProvider(){} // no base instances IOStreamProvider(IOStreamProvider const &); // no copy cons IOStreamProvider &operator=(IOStreamProvider const &); // no assignment }; #endif /* _IOSTREAMPROVIDER_H_ */

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel