- wine-devel - winehq.org

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Dan Kegel 16 Jan '06

16 Jan '06

On 1/15/06, Ge van Geldorp <gvg(a)reactos.org> wrote: > > The Mozilla ActiveX control download feature is cool and all, > > but until we repackage the sucker to include MSVCP60.DLL to fix > > http://bugs.winehq.org/show_bug.cgi?id=4064 ... > > I could have sworn I saw somebody post a note saying they had > > done said repackaging, but I can't find it now... > > http://www.winehq.org/pipermail/wine-patches/2005-December/022795.html > Instructions on how to repackage can be found at > svn://svn.reactos.org/trunk/tools/MozillaControl/ Thanks! I've updated bug 4064. Now can somebody update winehq.org's copy of the control so we can close that bug? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

(no subject)
by Ananth M 16 Jan '06

16 Jan '06

Hi Maintainers, For the recent wine releases , is there any binary rpm's are available ? In the winehq.com I am able to get the following message only.. Binary packages are in the process of being built, but the source is available now. You can find out more about this release in the announcement. Check out our download page for packages for your favorite distribution. Even in the downloads, installation of the RPM's ( otherthan Source RPM ) is giving problems mainly ( dependancy problems ) . One more question : Is development RPM includes all the required S/W ? or Do I need to download other RPMs also ( i386 or i686 ) ? Thank you

2 1

SJphone crashing
by Pavel Troller 16 Jan '06

16 Jan '06

Hi! I would like to test a free softphone application called "SJphone" (free download from http://www.sjlabs.com ). I know there is a native Linux version, but it's much less featured than the windows one (mainly missing skin support and generally less options) and because I need to train other users how to use the windows version, I have to try it for myself first :-). Installation is working well, no errors encountered. However, after trying to run the program, its GUI appered for a while with a sandclock cursor and then the following crash occured. I don't have access to real windows so I don't have any windows DLLs available. Would it be possible to fix wine's ones to make the program working ? With regards, Pavel Troller P.S. running CVS wine from 06/01/15 (yesterday). patrol@arcus:~/.wine/drive_c/Program Files/SJLabs/SJphone$ wine SJphone.exe err:wave:OSS_WaveOutInit open(/dev/mixer2) failed (No such file or directory) err:wave:OSS_WaveInInit open(/dev/mixer2) failed (No such file or directory) fixme:ole:CoRegisterMessageFilter stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff51ee8)->((nil),00000008) fixme:ras:RasEnumConnectionsA (0x7f7b10a0,0x7fc68e34,0x7fc68e40),stub! fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program to use LAN connection/winsock instead! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff64d48)->((nil),00000008) err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 fixme:win:LockWindowUpdate (0x2002a), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:keyboard:RegisterHotKey (0x2002a,1,0x00000006,81): stub fixme:keyboard:RegisterHotKey (0x2002a,2,0x00000006,66): stub fixme:keyboard:RegisterHotKey (0x2002a,3,0x00000006,76): stub fixme:keyboard:RegisterHotKey (0x2002a,4,0x00000006,78): stub fixme:keyboard:UnregisterHotKey (0x2002a,5): stub fixme:keyboard:RegisterHotKey (0x2002a,6,0x00000006,83): stub fixme:keyboard:RegisterHotKey (0x2002a,7,0x00000006,77): stub err:msacm:MSACM_GetRegistryKey No alias needed for registry entry wine: Unhandled page fault on write access to 0x59be0000 at address 0x3f6dbd50 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x59be0000 in 32-bit code (0x3f6dbd50). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:3f6dbd50 ESP:7fc68248 EBP:7fc689ec EFLAGS:00210246( - 00 -RIZP1) EAX:015000d4 EBX:3f6e4e04 ECX:209c0000 EDX:54da0020 ESI:009c7ffc EDI:7fa403d0 Stack dump: 0x7fc68248: 7fc68250 7fa40408 00000078 009c7ffc 0x7fc68258: 015000d4 00d700d6 016e0158 017000da 0x7fc68268: 00dd00dc 00df0162 00e10155 010300e2 0x7fc68278: 013a00e4 00e70107 00e9010d 00eb0119 0x7fc68288: 00ed011b 010f00ee 01440111 00f30148 0x7fc68298: 015100f4 00f700f6 016f0159 017100fa Backtrace: =>1 0x3f6dbd50 in msacm32 (+0xbd50) (0x3f6dbd50) 2 0x3f6dc2d9 MSACM_RegisterDriver+0x139 in msacm32 (0x3f6dc2d9) 3 0x3f6d88fb acmDriverAddA+0x4b in msacm32 (0x3f6d88fb) 4 0x0057dea5 in sjphone (+0x17dea5) (0x0057dea5) 5 0x00000000 (0x00000000) 6 0x005781e0 in sjphone (+0x1781e0) (0x005781e0) 0x3f6dbd50: movl %eax,0x0(%edx,%esi,8) Modules: Module Address Debug info Name (131 modules) PE 0x00400000-0085e000 Export sjphone PE 0x10000000-10006000 Deferred mozctlx ELF 0x20000000-20015000 Deferred ld-linux.so.2 ELF 0x20015000-2002f000 Deferred libwine.so.1 ELF 0x2002f000-20040000 Deferred libpthread.so.0 ELF 0x20040000-20149000 Deferred libc.so.6 ELF 0x20149000-2014c000 Deferred libdl.so.2 ELF 0x2014c000-20169000 Deferred iphlpapi<elf> \-PE 0x20150000-20169000 \ iphlpapi ELF 0x20169000-201af000 Deferred rpcrt4<elf> \-PE 0x20180000-201af000 \ rpcrt4 ELF 0x201af000-20257000 Deferred comctl32<elf> \-PE 0x201c0000-20257000 \ comctl32 ELF 0x20257000-202e3000 Deferred oleaut32<elf> \-PE 0x20270000-202e3000 \ oleaut32 ELF 0x202e3000-202fb000 Deferred version<elf> \-PE 0x202f0000-202fb000 \ version ELF 0x202fb000-20374000 Deferred winex11<elf> \-PE 0x20310000-20374000 \ winex11 ELF 0x20374000-2037a000 Deferred libxxf86dga.so.1 ELF 0x2037a000-20380000 Deferred libxxf86vm.so.1 ELF 0x20380000-20390000 Deferred libxext.so.6 ELF 0x20390000-20393000 Deferred xlcdef.so.2 ELF 0x20393000-203af000 Deferred imm32<elf> \-PE 0x203a0000-203af000 \ imm32 ELF 0x203af000-203b9000 Deferred libxcursor.so.1 ELF 0x203b9000-203ce000 Deferred midimap<elf> \-PE 0x203c0000-203ce000 \ midimap ELF 0x203ce000-203fa000 Deferred libssl.so.0.9.6 ELF 0x203fa000-204b0000 Deferred libcrypto.so.0.9.6 ELF 0x205c0000-205d9000 Deferred rasapi32<elf> \-PE 0x205d0000-205d9000 \ rasapi32 ELF 0x206e9000-20717000 Deferred shdocvw<elf> \-PE 0x20700000-20717000 \ shdocvw PE 0x20720000-20750000 Deferred mozctl PE 0x20750000-207af000 Deferred xpcom PE 0x207b0000-207ce000 Deferred embedcomponents PE 0x207d0000-207dd000 Deferred mozz PE 0x207e0000-207e7000 Deferred xpcom_compat_c PE 0x207f0000-20800000 Deferred chrome PE 0x20800000-2081a000 Deferred rdf PE 0x20820000-20854000 Deferred gkparser PE 0x20860000-20888000 Deferred docshell PE 0x20890000-208a7000 Deferred gkgfx PE 0x209c0000-209cf000 Deferred gsm332 ELF 0x24326000-2433a000 Deferred lz32<elf> \-PE 0x24330000-2433a000 \ lz32 ELF 0x24969000-24999000 Deferred uxtheme<elf> \-PE 0x24970000-24999000 \ uxtheme ELF 0x2542a000-25447000 Deferred mpr<elf> \-PE 0x25430000-25447000 \ mpr ELF 0x28146000-2815d000 Deferred msacm<elf> \-PE 0x28150000-2815d000 \ msacm ELF 0x28bf6000-28c26000 Deferred dmusic<elf> \-PE 0x28c10000-28c26000 \ dmusic PE 0x30000000-30026000 Deferred nspr4 ELF 0x338f8000-33911000 Deferred wsock32<elf> \-PE 0x33900000-33911000 \ wsock32 PE 0x38450000-38460000 Deferred caps PE 0x38900000-3890a000 Deferred jar50 ELF 0x3b28f000-3b297000 Deferred libxrender.so.1 PE 0x3ca40000-3ca61000 Deferred imglib2 PE 0x3cd00000-3cf50000 Deferred gklayout ELF 0x3d9dd000-3d9f6000 Deferred oledlg<elf> \-PE 0x3d9e0000-3d9f6000 \ oledlg ELF 0x3de7a000-3deba000 Deferred wininet<elf> \-PE 0x3de80000-3deba000 \ wininet ELF 0x3e5a7000-3e5bb000 Deferred olepro32<elf> \-PE 0x3e5b0000-3e5bb000 \ olepro32 ELF 0x3e65f000-3e6b3000 Deferred shlwapi<elf> \-PE 0x3e670000-3e6b3000 \ shlwapi ELF 0x3f6c4000-3f6e5000 Export msacm32<elf> \-PE 0x3f6d0000-3f6e5000 \ msacm32 ELF 0x3f879000-3f89b000 Deferred libm.so.6 ELF 0x3f94d000-3fa43000 Deferred libwine_unicode.so.1 ELF 0x3fefe000-3ff86000 Deferred ole32<elf> \-PE 0x3ff10000-3ff86000 \ ole32 ELF 0x43323000-43327000 Deferred libxrandr.so ELF 0x43347000-4334a000 Deferred iso8859-2.so ELF 0x44b24000-44b67000 Deferred wineoss<elf> \-PE 0x44b30000-44b67000 \ wineoss PE 0x45ea0000-45f5a000 Deferred uconv ELF 0x46a3c000-46a45000 Deferred libgcc_s.so.1 ELF 0x4a078000-4a0a0000 Deferred winspool<elf> \-PE 0x4a080000-4a0a0000 \ winspool ELF 0x4ae7a000-4aed7000 Deferred msvcrt<elf> \-PE 0x4ae90000-4aed7000 \ msvcrt ELF 0x4b474000-4b4ae000 Deferred advapi32<elf> \-PE 0x4b480000-4b4ae000 \ advapi32 ELF 0x4c9a7000-4caba000 Deferred user32<elf> \-PE 0x4c9c0000-4caba000 \ user32 PE 0x59bf0000-59c1f000 Deferred xpc3250 PE 0x5aa60000-5aa7e000 Deferred gkwidget PE 0x5edd0000-5eddd000 Deferred xppref32 ELF 0x5f0b0000-5f0b9000 Deferred libnss_files.so.2 PE 0x5f920000-5f928000 Deferred pipboot ELF 0x605d2000-605ed000 Deferred libcups.so.2 PE 0x60f80000-60fa4000 Deferred gkgfxwin PE 0x61130000-61184000 Deferred js3250 ELF 0x61f10000-61f80000 Deferred libfreetype.so.6 PE 0x62eb0000-62ebf000 Deferred profile PE 0x64000000-6402e000 Deferred i18n ELF 0x6594e000-65998000 Deferred dsound<elf> \-PE 0x65960000-65998000 \ dsound PE 0x69540000-69554000 Deferred xpcom_compat PE 0x69ca0000-69ca6000 Deferred embed_lite ELF 0x6a642000-6a6bf000 Deferred libgl.so.1 ELF 0x6a86c000-6a8ea000 Deferred winmm<elf> \-PE 0x6a880000-6a8ea000 \ winmm ELF 0x6ccbc000-6ccc5000 Deferred libsm.so.6 ELF 0x6ccca000-6cce1000 Deferred libice.so.6 ELF 0x6cd7d000-6ce47000 Deferred libx11.so.6 ELF 0x6d252000-6d26e000 Deferred ximcp.so.2 ELF 0x6f831000-6f8ef000 Deferred shell32<elf> \-PE 0x6f850000-6f8ef000 \ shell32 ELF 0x72245000-722d7000 Deferred comdlg32<elf> \-PE 0x72250000-722d7000 \ comdlg32 PE 0x73fb0000-73fb7000 Deferred plc4 PE 0x747b0000-747b6000 Deferred plds4 PE 0x75b70000-75be1000 Deferred necko ELF 0x767a6000-7682a000 Deferred gdi32<elf> \-PE 0x767c0000-7682a000 \ gdi32 PE 0x780c0000-78121000 Deferred msvcp60 PE 0x78ca0000-78cad000 Deferred webbrwsr ELF 0x7b26c000-7b294000 Deferred ws2_32<elf> \-PE 0x7b270000-7b294000 \ ws2_32 ELF 0x7b800000-7b8f7000 Deferred kernel32<elf> \-PE 0x7b820000-7b8f7000 \ kernel32 ELF 0x7bc00000-7bc73000 Deferred ntdll<elf> \-PE 0x7bc10000-7bc73000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\SJLabs\SJphone\SJphone.exe 00000010 0 0000000f 0 0000000e 0 0000000b 0 00000009 0 <== WineDbg terminated on pid 0x8

1 0

Re: shell32: Add the right SHFileOperation flags to fix some failing test on windows
by Mike McCormack 16 Jan '06

16 Jan '06

James Hawkins wrote: > Changelog: > * Add the right SHFileOperation flags to fix some failing tests on windows. > * Add a newline to the end of the file to avoid a warning. > > dlls/shell32/tests/shlfileop.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) This causes a number of MessageBoxes to appear during the tests for me: "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test2.txt?" "OverWrite File testdir2\test3.txt?" "OverWrite File testdir2\a.txt?" "OverWrite File testdir2\b.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\test1.txt?" "OverWrite File testdir2\test4.txt\a.txt?" "OverWrite File testdir2\a.txt?" Answering OK to each one lets the tests pass, but I don't think we want these tests to be interactive. Mike

1 0

Re: shell32: Reimplement a factored SHFileOperation [RESEND]
by Mike McCormack 16 Jan '06

16 Jan '06

James Hawkins wrote: > This version initializes all memory so we don't crash when freeing the > file list, as spotted by Mike. I also corrected the return types from > int to HRESULT. > > Changelog: > * Reimplement a factored SHFileOperation. Hey James, Great work, but the tests still fail for me: make[1]: Entering directory `/home/mike/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:707: Test failed: Files and directories are moved to directory shlfileop.c:708: Test failed: The file is moved shlfileop.c:709: Test failed: The directory is moved shlfileop.c:710: Test failed: The file in subdirectory is moved Mike

1 0

Debugging a null pointer dereference
by Christer Palm 15 Jan '06

15 Jan '06

Hi! I'm new to this list, but a long time Wine user and regular WWN reader. The other day I decided to try out Semiolog, a free as-in-beer piece of software to create labels from electric equipment manufacturer Hager, under wine. The software can be downloaded from here: http://www.hager.se/files/download/0/482_1/0/SemiologSue40a.exe Unfortunately it doesn't work. So although I haven't been doing any Windows programming in the last 15 years I decided to try to do something useful and try find out why it doesn't work. I figured that this application would be a good thing to try to get to work as it is supposedly rather trivial. So what follows is a description of a newbies attempt at some wine debugging: The application installs and starts up just fine, but when I try to create a new document, I get a null pointer dereference in mfc42.dll. After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: =================================================================== wine: Unhandled page fault on read access to 0x0000003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x0000003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump 00000000: 06 00 0a 00 01 00 50 f1 ......P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 [1000's of codeview_parse_type_table messages snipped] fixme:dbghelp_msc:codeview_snarf No current function for label $L101060 [1000's of codeview_snarf messages snipped] Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:5f4056dd ESP:7fc9d004 EBP:7fc9d0b8 EFLAGS:00010206( - 00 - RIP1) EAX:00000000 EBX:00000001 ECX:00000000 EDX:00000000 ESI:00449180 EDI:00000000 Stack dump: 0x7fc9d004: 004125f2 00000000 7ff38140 00000000 0x7fc9d014: 7ff38140 0042bb1f 00000000 00000001 0x7fc9d024: 004181b3 00000000 7ff38140 00030080 0x7fc9d034: 00418130 5f401e5c 00000001 7ff38140 0x7fc9d044: 00000000 7ff38140 7ff38140 7ff0f300 0x7fc9d054: 201cc2f0 7fc9d728 00000000 7fc9d0e8 0200: sel=1007 base=7ffdc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) 2 0x5f401b2c CDC::RectVisible+0x3(lpRect=0x5f401ab5) [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:647] in mfc42 (0x5f401b2c) 3 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 4 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 5 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 6 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 7 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 8 0x62a7336e CallWindowProcW+0x122 in user32 (0x62a7336e) 9 0x62a3ba2e in user32 (+0x6ba2e) (0x62a3ba2e) 10 0x62a3f8c2 SendMessageTimeoutW+0x186 in user32 (0x62a3f8c2) 11 0x62a3f91f SendMessageW+0x50 in user32 (0x62a3f91f) 12 0x62a2d1be in user32 (+0x5d1be) (0x62a2d1be) 13 0x62a2e4f7 DefMDIChildProcW+0x36e in user32 (0x62a2e4f7) 14 0x62a2e801 DefMDIChildProcA+0xf2 in user32 (0x62a2e801) 15 0x5f413511 COleControl::GetMetafileData+0x87(lpFormatEtc=0x22, lpStgMedium=0x0, hAttribDC=0x22, cy=0x0, hMF=0x22) [ctlcore.cpp:827] in mfc42 (0x5f413511) 16 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 17 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 18 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 19 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 20 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 21 0x62a70f2d CallWindowProcA+0x1b5 in user32 (0x62a70f2d) 22 0x62a3b99f in user32 (+0x6b99f) (0x62a3b99f) 23 0x62a3f674 SendMessageTimeoutA+0x226 in user32 (0x62a3f674) 24 0x62a3f72f SendMessageA+0x50 in user32 (0x62a3f72f) 25 0x59a9462e X11DRV_SetWindowPos+0xf33 in winex11 (0x59a9462e) 26 0x62a6bbe3 SetWindowPos+0xb1 in user32 (0x62a6bbe3) 27 0x62a6c63a BringWindowToTop+0x4d in user32 (0x62a6c63a) 28 0x5f408ae3 COleControlContainer::CreateControl+0x31(pWndCtrl=0x0, clsid=0x0, lpszWindowName=0x0, dwStyle=0x1, ppt=0x0, psize=0x7ff11458, nID=0x10026, pPersist=0x0, bStorage=0x0, bstrLicKey=0x62a086dc, ppNewSite=0x0) [occcont.cpp:175] in mfc42 (0x5f408ae3) 29 0x00000001 (0x00000001) 30 0x00418d70 in semiolog (+0x18d70) (0x00418d70) 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42: movl 0x3c(%ecx),%eax Unable to open file 'oleverb.cpp' Modules: Module Address Debug info Name (83 modules) ELF 0x00165000-00272000 Deferred libcrypto.so.5 [boring load map snipped] Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\hager\Semiolog\Apps\Semiolog.exe 00000009 0 <== WineDbg terminated on pid 0x8 =================================================================== Now, I'm stuck with a couple of problems. 1. Looking at the first couple of lines in the backtrace, I can't really get it to make sense when I compare it to the MFC source code, i.e., I can't see how CDC::RectVisible() would end up calling ~CEnumOleVerb(), etc. 2. I can't get it to run under winedbg. Running "winedbg --auto Semiolog" causes winedbg to croak with the following output before the app even starts: WineDbg starting on pid 0xa In 32 bit mode. 0x00345c6e: movl %edi,0x0(%esp) Modules: Module Address Debug info Name (80 modules) ELF 0x00165000-00272000 Deferred libcrypto.so.5 ELF 0x00165000-00272000 Deferred libcrypto.so.5 PE 0x00240000-00269000 Deferred dzip32 PE 0x00270000-00288000 Deferred mpr ELF 0x0028a000-002a2000 Deferred libgssapi_krb5.so.2 PE 0x00290000-002b7000 Deferred dunzip32 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 ELF 0x002c5000-002e9000 Deferred libk5crypto.so.3 PE 0x002f0000-003ea000 Export kernel32 PE 0x002f0000-003ea000 Export kernel32 PE 0x002f0000-003ea000 Export kernel32 PE 0x00400000-004c3000 Deferred semiolog ELF 0x004c3000-00558000 Deferred gdi32<elf> \-PE 0x004d0000-00558000 \ gdi32 ELF 0x0055e000-0057a000 Deferred ld-linux.so.2 ELF 0x0057a000-005a6000 Deferred winspool<elf> \-PE 0x00580000-005a6000 \ winspool ELF 0x0057a000-005a6000 Deferred winspool<elf> \-PE 0x00580000-005a6000 \ winspool ELF 0x0057c000-006a5000 Deferred libc.so.6 PE 0x005b0000-005c3000 Deferred common PE 0x005d0000-005e6000 Deferred listctrlex ELF 0x00614000-0067a000 Deferred msvcrt<elf> \-PE 0x00620000-0067a000 \ msvcrt ELF 0x006a7000-006cc000 Deferred libm.so.6 ELF 0x006ce000-006d2000 Deferred libdl.so.2 ELF 0x006d2000-0080e000 Deferred user32<elf> \-PE 0x006d4000-006e7000 \ libz.so.1 \-PE 0x006e9000-007bd000 \ libx11.so.6 \-PE 0x006f0000-0080e000 \ user32 ELF 0x00826000-0082c000 Deferred libxxf86dga.so.1 ELF 0x0084a000-00859000 Deferred libxext.so.6 ELF 0x0084a000-00859000 Deferred libxext.so.6 PE 0x00860000-0086f000 Deferred iphlpapi ELF 0x0086f000-0088e000 Deferred ximcp.so.2 ELF 0x00899000-008ab000 Deferred libpthread.so.0 ELF 0x008ab000-00946000 Deferred comdlg32<elf> \-PE 0x008b3000-008d2000 \ libexpat.so.0 \-PE 0x008c0000-00946000 \ comdlg32 \-PE 0x008c0000-00946000 \ comdlg32 \-PE 0x008c0000-00946000 \ comdlg32 ELF 0x0093e000-00968000 Deferred libfontconfig.so.1 PE 0x00960000-00a19000 Deferred shell32 PE 0x00960000-00a19000 Deferred shell32 ELF 0x00a1d000-00a21000 Deferred libxrandr.so.2 ELF 0x00a2d000-00a38000 Deferred libnss_files.so.2 ELF 0x00a38000-00a55000 Deferred imm32<elf> \-PE 0x00a40000-00a55000 \ imm32 ELF 0x00a55000-00a88000 Deferred uxtheme<elf> \-PE 0x00a60000-00a88000 \ uxtheme ELF 0x00a95000-00ad8000 Deferred advapi32<elf> \-PE 0x00aa0000-00ad8000 \ advapi32 ELF 0x00b1a000-00c10000 Deferred libwine_unicode.so.1 ELF 0x00b36000-00bb1000 Deferred libgl.so.1 ELF 0x00b81000-00b9f000 Deferred libcups.so.2 ELF 0x00c10000-00ca9000 Deferred ole32<elf> \-PE 0x00c20000-00ca9000 \ ole32 ELF 0x00cb8000-00d18000 Deferred shlwapi<elf> \-PE 0x00cd0000-00d18000 \ shlwapi ELF 0x00d18000-00d61000 Deferred rpcrt4<elf> \-PE 0x00d1c000-00d26000 \ libxcursor.so.1 \-PE 0x00d28000-00d60000 \ libssl.so.5 \-PE 0x00d30000-00d61000 \ rpcrt4 ELF 0x00d61000-00e29000 Deferred comctl32<elf> \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 \-PE 0x00d70000-00e29000 \ comctl32 ELF 0x00e67000-00ee5000 Deferred ntdll<elf> \-PE 0x00e80000-00ee5000 \ ntdll ELF 0x00ee5000-00f83000 Deferred oleaut32<elf> \-PE 0x00f00000-00f83000 \ oleaut32 ELF 0x00feb000-01073000 Deferred winex11<elf> \-PE 0x01000000-01073000 \ winex11 ELF 0x068a4000-06916000 Deferred libkrb5.so.3 ELF 0x06c20000-06c25000 Deferred libxxf86vm.so.1 PE 0x10000000-1000b000 Deferred hcore PE 0x5f400000-5f4f2000 Deferred mfc42 ELF 0x5fa38000-5fc15000 Deferred i915_dri.so ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000a (D) C:\hager\Semiolog\Apps\Semiolog.exe 0000000b 0 <== WineDbg terminated on pid 0xa wine client error:b: write: Bad file descriptor [100's of Bad file descriptor errors just like the one above] wine client error:b: err:seh:setup_exception stack overflow 292 bytes in thread 000b eip 0014bb0e esp 7fb80edc stack 0x7fb81000-0x7fc90000 Any clues? Cheers, -- Christer Palm

2 2

Re: Static control [10/10]: Support the Windows XP mode of the static control
by Filip Navara 15 Jan '06

15 Jan '06

Michael Kaufmann wrote: > Changelog: > - Detect if the image of the current process has a manifest. If yes, > enable some Windows XP-specific features (as described in MSDN) > - Destruction of the control window: Destroy bitmaps loaded at control > creation time (removed a resource leak) > - Always stretch bitmaps and icons to the whole client area > - Windows XP mode: Different bitmap background, different icon > background. > - Add some notes This doesn't seem right. User32 shouldn't be checking manifests, I would expect the STATIC control to be subclassed in COMCTL32 and the WinXP functionality implemented there. - Filip

2 2

winehq on osx-intel?
by Bob Hunter 15 Jan '06

15 Jan '06

Hello, There are winehq binaries for unix except osx unix, being apple mac os. As Apple shifted to intel cpu, winehq has one more platform to go. The old VirtualPC by connectix was purchased by microsoft, and there are no news about its conversion to the new platform. Further, no one really wants to run an emulation of the windows desktop. Are there any plans to extend winehq to osx, possibly for a fee? I would be happy to pay for a copy. Bob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Problem with older wgl patch
by Tim Savannah 15 Jan '06

15 Jan '06

On the newest wine, trying to start opengl programs such as World of Warcraft yields an error such as this: trace:opengl:wine_glCullFace (1029) trace:opengl:wine_glMatrixMode (5889) trace:opengl:wine_glLoadMatrixf (0x7fbafbb8) trace:opengl:wglMakeCurrent (0x368,0x7fd7b7d0) trace:opengl:create_glxpixmap return 1800054 trace:opengl:wglMakeCurrent make current for dis 0x7c01baf8, drawable 0x1800054, ctx 0x7c1c01d8 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 412 Current serial number in output stream: 413 I don't know enough about wgl to offer any suggestions to the problem, other than the source seems to be this patch: http://cvs.winehq.org/cvsweb/wine/dlls/opengl32/wgl.c.diff?r1=1.71&r2=1.72&… Reverting that patch and adding + DWORD type = GetObjectType(hdc); where that patch placed it in the file allows opengl to work again.

4 3

Re: user: Implement scrolling in popup menus
by Phil Krylov 15 Jan '06

15 Jan '06

Hi, Anything wrong with that patch? (Yes I know that separate arrow bitmaps should be used instead of the scrollbar ones. But I can't draw ;) On Sat, 7 Jan 2006 16:54:15 +0300 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > ChangeLog: > > Added scrolling support to popup menus which don't fit on the desktop. -- Ph.

1 0

Re: Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Filip Navara 15 Jan '06

15 Jan '06

1 0

Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
by Dan Kegel 15 Jan '06

15 Jan '06

The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... Can somebody take care of this? It's kind of important. I would, but I'm zooming around getting my CS 130 project going, preparing a couple talks for Scale 4x, chasing after my two year old, and trying to hold down my day job... For the curious, my slids for the cs130 kickoff talk are up at http://kegel.com/wine/sweng/cs130/ I chose "add a feature to riched20.dll " as the basic task the students will be trying to carry out. No idea yet how it'll work out. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

Re: winetest: Only test d3d9 if it is being built.
by H. Verbeet 15 Jan '06

15 Jan '06

On 23/12/05, Yuval Fledel <yuvalfl(a)gmail.com> wrote: > winetest: Only test d3d9 if it is being built. > > -- Yuval Fledel > > diff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in > index 4208b94..8602f66 100644 > --- a/programs/winetest/Makefile.in > +++ b/programs/winetest/Makefile.in > @@ -19,14 +19,15 @@ RC_BINSRC = winetest.rc > RC_BINARIES = wine.ico > > XFILES = ddraw_test.exe$(DLLEXT) > +OPENGLFILES = d3d9_test.exe$(DLLEXT) > > TESTBINS = \ > @XFILES@ \ > + @OPENGLFILES@ \ > advpack_test.exe$(DLLEXT) \ > advapi32_test.exe$(DLLEXT) \ > comctl32_test.exe$(DLLEXT) \ > crypt32_test.exe$(DLLEXT) \ > - d3d9_test.exe$(DLLEXT) \ > dinput_test.exe$(DLLEXT) \ > dsound_test.exe$(DLLEXT) \ > gdi32_test.exe$(DLLEXT) \ Would this prevent the tests from getting built on Windows?

1 0

re: Regression in ntdll/virtual.c
by Dan Kegel 14 Jan '06

14 Jan '06

>I mentioned that the setup program of AstroWorld will not work any longer >since a few days. Regression testing resulted in the change of >ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry >in wine.patches... Ah, but did you look in the archives of the wine-cvs mailing list? A little google search for the longest line of that change turned up: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

IWineD3DSurface::GetDC
by Stefan Dösinger 14 Jan '06

14 Jan '06

Hello, I am trying to implement the GetDC method for wine d3d surfaces, as it is used by much d3d7 apps to load the textures. I took the code from ddraw/surface_dib.c and modified it, but I am stuck with a heap corruption. Basically, what I am doing is: 1) Lock the surface 2) Create a DIB section with DIB_CreateDIBSection. Use the currentDesc. {Width / Height} as the dimension and bytesPerPixel * 8 for the bitcount. The memory for the DC is the pBits returned from LockRect() 3) Create a DC, and attach it to the dib section 4) Set the palette, if necessary. In ReleaseDC I release the DC, destroy the DIB section and unlock the surface. Looks nice so far, but it doesn't work. I get a heap corruption eighter when using the DC or when deleting it. An example winedbg output: err:d3d_surface:IWineD3DSurfaceImpl_GetDC (0x7fd8fb08)->(0x7fbafd94): This does not work yet trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) : rect@(nil) flags(00000000), output lockedRect@0x7fbaf4a8, memory@(nil) trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locked Rect (0x7fd8fb78) = l 0, t 0, r 640, b 480 trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locking non-power 2 texture trace:d3d_surface:IWineD3DSurfaceImpl_LockRect locking an ordinarary surface trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) Locking rect trace:d3d_surface:IWineD3DSurfaceImpl_AddDirtyRect (0x7fd8fb08) : Dirty?1, Rect:(0,0,640,480) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf3fc (nil) trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to queryInterface 0x7fbaf454 0xb7effbda trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Surface is standalone, no need to dirty the container trace:d3d_surface:IWineD3DSurfaceImpl_LockRect returning memory@0x7dfa0020, pitch(4096) dirtyfied(1) trace:d3d_surface:IWineD3DSurfaceImpl_GetDC Creating dip section 640x480x32. memory at 0x7dfa0020 is 2097152 bytes of size trace:d3d_surface:IWineD3DSurfaceImpl_GetDC returning 0x278 trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC (0x7fd8fb08)->(0x278) trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC Selecting the object DC First chance exception: page fault on read access to 0x7dfa0000 in 32-bit code (0x7ff99374). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ff99374 ESP:7fbaf714 EBP:7fbaf718 EFLAGS:00010206( - 00 - RIP1) EAX:7fce0000 EBX:7ffd5540 ECX:7e5c0250 EDX:7dfa0000 ESI:7e5c0248 EDI:7fce0040 Stack dump: 0x7fbaf714: 00000030 7fbaf754 7ff99c0b 7fce0000 0x7fbaf724: 7e5c0248 7f712cd0 00000000 00004f4c 0x7fbaf734: 7ff99294 7fd8fee8 7e5c0248 7ff8dffa 0x7fbaf744: 7f6edf2b 7ffd5540 00000030 00000030 0x7fbaf754: 7fbaf798 7ff9a954 7fce0000 00000030 0x7fbaf764: 7fbaf788 7f70253b 0000027c 00004f4c Backtrace: =>1 0x7ff99374 HEAP_FindSubHeap+0x14(heap=0x7fce0000, ptr=0x7e5c0248) [heap.c:375] in ntdll (0x7ff99374) 2 0x7ff99c0b HEAP_FindFreeBlock+0x7b(heap=0x7fce0000, size=0x30, ppSubHeap=0x7fbaf788) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:390] in ntdll (0x7ff99c0b) 3 0x7ff9a954 RtlAllocateHeap(heap=0x7fce0000, flags=0x2, size=0x30) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:1163] in ntdll (0x7ff9a954) q 4 0x7f263905 X11DRV_GetRegionData+0x55(hrgn=0x27c, hdc_lptodp=0x0) [/usr/src/wine-wined3d/dlls/x11drv/../../include/winbase.h:2250] in winex11 (0x7f263905) 5 0x7f263aa6 X11DRV_SetDeviceClipping+0x56(physDev=0x7fd8fe68, vis_rgn=0x280, clip_rgn=0x0) [/usr/src/wine-wined3d/dlls/x11drv/clipping.c:118] in winex11 (0x7f263aa6) 6 0x7f6c6a1e CLIPPING_UpdateGCRegion+0xae(dc=0x7e1a0028) [clipping.c:80] in gdi32 (0x7f6c6a1e) 7 0x7f6c84fa DC_InitDC+0x9a(dc=0x7e1a0028) [/usr/src/wine-wined3d/dlls/gdi/dc.c:205] in gdi32 (0x7f6c84fa) 8 0x7f6c5c06 BITMAP_SelectObject(handle=0x6c, obj=0x7fce5d20, hdc=0x278) [/usr/src/wine-wined3d/dlls/gdi/bitmap.c:568] in gdi32 (0x7f6c5c06) 9 0x7f6eea05 SelectObject(hdc=0x278, hObj=0x6c) [/usr/src/wine-wined3d/dlls/gdi/gdiobj.c:1164] in gdi32 (0x7f6eea05) 10 0x7f5ecd10 IWineD3DSurfaceImpl_ReleaseDC+0x50(iface=0x7fd8fb08, hDC=0x278) [/usr/src/wine-wined3d/dlls/wined3d/surface.c:1068] in wined3d (0x7f5ecd10) q 11 0x7fa7e0e8 IDirectDrawSurfaceImpl_ReleaseDC+0x38(iface=0x7fd8fa48, hdc=0x278) [/usr/src/wine-wined3d/dlls/ddraw/surface.c:472] in ddraw (0x7fa7e0e8) 12 0x7fbd5fe6 main in ddrawex (0x7fbd5fe6) 13 0x7fbd63a7 __wine_spec_exe_entry(peb=0x7ffdf540) [exe_entry.c:37] in ddrawex (0x7fbd63a7) 14 0x7fc490a0 start_process(arg=0x0) [/usr/src/wine-wined3d/dlls/kernel/process.c:1027] in kernel32 (0x7fc490a0) 15 0xb7f020fb wine_switch_to_stack+0x17 in libwine.so.1 (0xb7f020fb) 0x7ff99374 HEAP_FindSubHeap+0x14 [heap.c:375] in ntdll: movl 0x0(%edx),%ecx Unable to open file 'heap.c' Wine-dbg> I am lost here, can someone help me? Can this code work at all? I've attached my copy of dlls/wined3d/surface.c, so you can see the code(Watch out, it won't compile as such in the CVS tree). The dib member of WineD3DSurface is taken from ddraw: typedef struct wineD3DSurface_DIB { HBITMAP DIBsection; void* bitmap_data; HGDIOBJ holdbitmap; BOOL client_memory; DWORD d3d_data[4]; /* room for Direct3D driver data */ } wineD3DSurface_DIB; Stefan

1 0

Re: x11drv: Allow WM to manage more windows.
by Dmitry Timoshkov 14 Jan '06

14 Jan '06

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > @@ -67,6 +67,8 @@ static const char visual_id_prop[] = > inline static BOOL is_window_managed( HWND hwnd ) > { > DWORD style, ex_style; > + char class_name[7]; > + static const char menu_class[] = "#32768"; > + /* menu windows are not managed */ > + if (GetClassNameA(hwnd, class_name, sizeof(class_name)) && > + !memcmp(class_name, menu_class, sizeof(menu_class))) > + return FALSE; This won't work for subclassed or custom (OfficeXP like) menus. -- Dmitry.

2 1

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX
by Aric Cyr 14 Jan '06

14 Jan '06

Hi all, Just wanted to chime in with a status update on my porting of wined3d to WGL. Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that. Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. I'm currently in the process of cleaning everything up and then I will post a patch on my site for people to download. Due to the scope of the changes, I really hope that people can help me test this sucker... once that's done I'll chop up the patch into logical pieces and submit them. That's all for now! - Aric P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.

6 10

Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
by Dan Kegel 14 Jan '06

14 Jan '06

Rob wrote: >This very much looks like a use-after-free bug. The first two >instructions are probably a COM *_Release call. Judging by the fact that >this is a regression I would also guess that it is a Wine object. This sounds like a job for valgrind! But, er, does valgrind still work with wine? Rob said it did in March: http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html It was too hard for one guy back in July: http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html but that was probably because he didn't see Rob's message from March. Maybe we need to put better instructions on how to use Valgrind with Wine on winehq.org... or, dare I suggest it, bundle valgrind with Wine so anybody could easily use it be setting WINEDEBUG=+valgrind or something like that... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Fwd: Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasembly To: Eric Pouech <eric.pouech(a)wanadoo.fr> On 1/14/06, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > > James Trotter wrote: > > Hi! > > > > A few days ago I filed this bug: > http://bugs.winehq.org/show_bug.cgi?id=4289 > > > > Alexandre commented that there most likely was some stack corruption, > > and that I should try and disassemble a few instructions before the > > crash and look for API calls. > > > > Now, I haven't used gdb or winedbg that much before, and I'm a bit > > uncertain what to do. I understand that using the disassemble > > [<addr>][,<addr>] command, the debugger will disassemble that address > > space. Given the stack trace as in the bug report, which addresses, > > exactly, should I disassemble? > before 0x007ab8f1 > A+ > > > -- > Eric Pouech > > Sure, but how much before 0x007ab8f1? For instance, Is this helpful? WineDbg starting on pid 0xa In 32 bit mode. 0x7fcfba16 start_process+0xb6 [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/kernel/process.c:996] in kernel32: pushl %edi 996 ExitProcess( entry( peb ) ); Wine-dbg>cont First chance exception: page fault on read access to 0x20202020 in 32-bit code (0x007ab8f1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7facaba4 EBP:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:00000001 ECX:7facb450 EDX:00000000 ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 00002711 00000000 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 00000000 00002711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 00000007 7fd0e900 0x7facabe4: 0078e3ca 00000000 7facaf60 00400000 0x7facabf4: 7fd39206 7facaf60 00000000 7fd39206 0200: sel=1007 base=b7f81000 limit=00001f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x00000000) 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg>disassemble 0x007ab800, 0x007ab8f1 0x007ab800: addb %bh,0x0(%ebx) 0x007ab802: int $0x74 0x007ab804: pop %ss 0x007ab805: cmpl %ebx,0x390(%ecx) 0x007ab80b: jz 0x007ab81c 0x007ab80d: addl $0x394,%ecx 0x007ab813: pushl %ecx 0x007ab814: call *%edi 0x007ab816: movl 0x008cf6d8,%ecx 0x007ab81c: movl 0x13c(%esi),%eax 0x007ab822: cmpl %ebp,%eax 0x007ab824: jz 0x007ab838 0x007ab826: movl 0x0(%eax),%ecx 0x007ab828: pushl %eax 0x007ab829: call *0x8(%ecx) 0x007ab82c: movl %ebp,0x13c(%esi) 0x007ab832: movl 0x008cf6d8,%ecx 0x007ab838: cmpl %ebp,%ecx 0x007ab83a: jz 0x007ab84d 0x007ab83c: cmpl %ebx,0x390(%ecx) 0x007ab842: jz 0x007ab84d 0x007ab844: addl $0x394,%ecx 0x007ab84a: pushl %ecx 0x007ab84b: call *%edi 0x007ab84d: leal 0x128(%esi),%ecx 0x007ab853: call 0x007c22d0 0x007ab858: movl %ebp,0x140(%esi) 0x007ab85e: movl 0x008cf6d8,%eax 0x007ab863: cmpl %ebp,%eax 0x007ab865: jz 0x007ab87b 0x007ab867: cmpl %ebx,0x390(%eax) 0x007ab86d: jz 0x007ab87b 0x007ab86f: addl $916,%eax 0x007ab874: pushl %eax 0x007ab875: call *0x8472c8 -> 0x7beb4180 RtlLeaveCriticalSection [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/ntdll/critsection.c:407] in ntdll 0x007ab87b: cmpl %ebp,0x90(%esi) 0x007ab881: jz 0x007ab8a4 0x007ab883: leal 0x84(%esi),%edi 0x007ab889: movl %edi,%ecx 0x007ab88b: call 0x007fbe77 0x007ab890: cmpl %ebp,%eax 0x007ab892: jz 0x007ab89c 0x007ab894: movl 0x0(%eax),%edx 0x007ab896: pushl %ebx 0x007ab897: movl %eax,%ecx 0x007ab899: call *0x4(%edx) 0x007ab89c: cmpl %ebp,0x90(%esi) 0x007ab8a2: jnz 0x007ab889 0x007ab8a4: cmpl %ebp,0xac(%esi) 0x007ab8aa: jz 0x007ab8d8 0x007ab8ac: leal 0xa0(%esi),%ebx 0x007ab8b2: movl %ebx,%ecx 0x007ab8b4: call 0x007fbe77 0x007ab8b9: movl %eax,%edi 0x007ab8bb: movl 0x58(%edi),%eax 0x007ab8be: cmpl %ebp,%eax 0x007ab8c0: jz 0x007ab8cb 0x007ab8c2: movl 0x0(%eax),%ecx 0x007ab8c4: pushl %eax 0x007ab8c5: call *0x8(%ecx) 0x007ab8c8: movl %ebp,0x58(%edi) 0x007ab8cb: cmpl %ebp,0xac(%esi) 0x007ab8d1: jnz 0x007ab8b2 0x007ab8d3: movl $0x1,%ebx 0x007ab8d8: cmpl %ebp,0x4(%esi) 0x007ab8db: jz 0x007ab8f9 0x007ab8dd: movl 0x8(%esi),%eax 0x007ab8e0: cmpl %ebp,%eax 0x007ab8e2: jz 0x007ab8ed 0x007ab8e4: movl 0x0(%eax),%edx 0x007ab8e6: pushl %eax 0x007ab8e7: call *0x8(%edx) 0x007ab8ea: movl %ebp,0x8(%esi) 0x007ab8ed: movl 0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg> Thanks, James

2 3

Re: RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso 14 Jan '06

14 Jan '06

Eric Pouech wrote: > Alex Villacís Lasso wrote: > >> Eric Pouech wrote: >> >>>> * Implementation of broadcasts to notification windows on driver >>>> add/remove, enabling/disabling, and priority changes >>> >>> >>> >>> - MSDN seems to state that differed notification is actually a >>> counter, not a simple boolean (whereas enable/disable is a boolean) >> >> >> >> I have just read the MSDN web page, and I see no remark that suggests >> that deferred notification should behave as a counter instead of a >> simple on/off flag. Or maybe I am reading the page incorrectly... > > well... > ACM_DRIVERPRIORITYF_END Calling task wants to reenable change > notification broadcasts. An application must call acmDriverPriority > with ACM_DRIVERPRIORITYF_END for each successful call with the > ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL, > dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can > be set. > ... then I need new glasses :-) >> >>>> * Fix for implementation quirks of acmDriverMessage() in order to >>>> allow native codecs to display configuration dialogs >>> >>> >>> >>> this seems rather hackish. did you actually tested this on Windows ? >>> Moreover, the size bits look especially suspicious. Where did you >>> get the 16 value from ? >> >> >> >> I tested the native msacm32.dll from Windows 98 SE on Wine, and it >> reported a 16-byte struct size to the winemp3 codec. > > how do you know it's a 16 byte struct? there's nothing in the passed > information that tells you it's 16 bytes AFAICS Yes, there is: (begin MSDN quote) DRV_CONFIGURE Directs the installable driver to display its configuration dialog box and let the user specify new settings for the given installable driver instance. *Parameters* /dwDriverId/ Identifier of the installable driver. This is the same value previously returned by the driver from the *DRV_OPEN* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp> message. /hdrvr/ Handle of the installable driver instance. /lParam1/ Handle of the parent window. This window is used as the parent window for the configuration dialog box. /lParam2/ Address of a *DRVCONFIGINFO* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_s…> structure or NULL. If the structure is given, it contains the names of the registry key and value associated with the driver. DRVCONFIGINFO Contains the registry key and value names associated with the installable driver. |typedef struct tagDRVCONFIGINFO { DWORD dwDCISize; LPCWSTR lpszDCISectionName; LPCWSTR lpszDCIAliasName; } DRVCONFIGINFO; | *Members* *dwDCISize* Size of the structure, in bytes. *lpszDCISectionName* Address of a null-terminated, wide-character string specifying the name of the registry key associated with the driver. *lpszDCIAliasName* Address of a null-terminated, wide-character string specifying the name of the registry value associated with the driver. (end MSDN quote) I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to codecs, in particular the dwDCISize field. Even when the sum of all fields in the structure declaration yields 12 bytes, dwDCISize holds a value of 16 when supplied by native msacm32.dll. So, I used the same value in order to mimic native as close as possible. Alex Villacís Lasso

2 1

Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

Hi! A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 Alexandre commented that there most likely was some stack corruption, and that I should try and disassemble a few instructions before the crash and look for API calls. Now, I haven't used gdb or winedbg that much before, and I'm a bit uncertain what to do. I understand that using the disassemble [<addr>][,<addr>] command, the debugger will disassemble that address space. Given the stack trace as in the bug report, which addresses, exactly, should I disassemble? Thanks, James

1 0

FAQ outdated in one point
by CS 13 Jan '06

13 Jan '06

In the FAQ you write under "2.12. When will Wine be finished?": "Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005." maybe that should be updated or removed altogether so there don't need to be updates to this entry in the future. sorry that I can't do more to contribute :-) clem

2 1

RFC: pch support
by Steven Edwards 13 Jan '06

13 Jan '06

Hi, Alexandre did not like the needed changes required to add support for this but I figured I would throw it out for debate anyway in case anyone else can make him change his mind (duck). The issue is he does not like needing a single header per-program or per dll. After doing some research it seems to me that even MSVC does not support multiple PCH files per project so I don't know how it could be fixed in gcc to do it Microsoft has not figured it out. problem: ccache works great for speeding up compiles but seems to still have issue with some header changes. Also the ReactOS guys really want to add pch support to the Wine dlls that are shared so the job falls to me to sell it to Wine. Solution: Below are the benchmarks from my box and a patch. Simply patch your tree and then ./configure and cd to the regedit folder and do a 'time make','make clean','make pch', and 'time make' if you want to see the speedup on your box. I expect we could get a 2x speedup in fresh compiles of Wine with pch support Regedit compile without pch real 0m5.632s user 0m5.000s sys 0m0.524s Regedit compile with pch real 0m2.797s user 0m2.352s sys 0m0.428s -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 12

re: richedit's RTF writer writes only 8 kBi
by Dan Kegel 13 Jan '06

13 Jan '06

In June '05, Tobias Burnus complained in http://www.winehq.com/hypermail/wine-devel/2005/06/0536.html that there seemed to be an 8kB size limit on rich text output from richedit... but nobody replied to his message. Tobias, did you ever resolve that problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Regression in ntdll/virtual.c
by Markus G�mmel 13 Jan '06

13 Jan '06

I mentioned that the setup program of AstroWorld will not work any longer since a few days. Regression testing resulted in the change of ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry in wine.patches, so here is the diff result: 37a38 > #include <sys/stat.h> 837a839 > struct stat st; 859a862,866 > if (fstat( fd, &st ) == -1) > { > status = FILE_GetNtStatus(); > goto error; > } 860a868 > if (header_size > st.st_size) goto error; 999c1007,1009 < if (map_file_into_view( view, fd, sec->VirtualAddress, file_size, sec->PointerToRawData, --- > end = sec->PointerToRawData + file_size; > if (sec->PointerToRawData >= st.st_size || end > st.st_size || end < > sec->PointerToRawData || > map_file_into_view( view, fd, sec->VirtualAddress, file_size, > sec->PointerToRawData, The program can be downloaded for free at http://www.astroworld.de/ger/. Simply select "AW2001 v.6.2 (English)" in the first selection box and press "Download Demo". With the new version of aw61eng.exe it stuck somewhere at 22% with an error message like "~TMD61.tmp" is not a Win32 binary". With the old version the setup run ok. Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

1 0

Re: winspool: updated some traces for bug 4268
by Huw D M Davies 13 Jan '06

13 Jan '06

On Fri, Jan 13, 2006 at 03:51:36PM +0100, Detlef Riekenberg wrote: > Changelog: > > - winspool: updated some traces for bug 4268 > > > -- > By By ... > ... Detlef > diff --git a/dlls/winspool/info.c b/dlls/winspool/info.c > index 9b1771d..a4caa39 100644 > --- a/dlls/winspool/info.c > +++ b/dlls/winspool/info.c > @@ -247,13 +247,16 @@ static BOOL CUPS_LoadPrinters(void) > HKEY hkeyPrinter, hkeyPrinters, hkey; > > cupshandle = wine_dlopen(SONAME_LIBCUPS, RTLD_NOW, NULL, 0); > + TRACE("%p: CUPS loaded (%s)\n", cupshandle, SONAME_LIBCUPS); > if (!cupshandle) > return FALSE; > - TRACE("loaded %s\n", SONAME_LIBCUPS); That's a very confusing TRACE. If wine_dlopen fails then why not print out something like "CUPS not loaded" ? > @@ -439,6 +442,8 @@ PRINTCAP_LoadPrinters(void) { > BOOL had_bash = FALSE; > > f = fopen("/etc/printcap","r"); > + TRACE("%p: using /etc/printcap\n", f); > + > if (!f) > return FALSE; > The same applies to this too. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Linuxtag 2006
by Uwe Bonnes 13 Jan '06

13 Jan '06

Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. 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: advpack: Implement LaunchINFSection on top of DoInfInstall
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSection on top of DoInfInstall > I'm afraid this implementation isn't correct. DoInfInstall calls SetupInstallFromInfSection which only concerns the Install section of an INF file. SetupInstallFromInfSection and consequently DoInfInstall cannot provide enough functionality for LaunchINFSection/Ex. LaunchINFSection/Ex also takes into acount reg and file saves (see Reg/FileSaveRestore), per user sections (see SetPerUserSecValues), registering ocx's, extracting cabinets, and a whole mush of other intricacies. LaunchINFSection/Ex basically combines all the other functions of advpack into a monstrosity of functionality. I'm working my way towards fully implementing LaunchINFSection/Ex, but I've got to finish the lower levels first, so if you'd like to help in this direction, take a look at the stubs I've mentioned in advpack. I appreciate your effort in this implementation, but it will do more harm than good because we'll have to take it out when it comes time to fully implement LaunchINFSection. -- James Hawkins

2 2

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by Markus Amsler 13 Jan '06

13 Jan '06

James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus

1 0

New wannabe developer
by Dan Kegel 13 Jan '06

13 Jan '06

Zoe wrote: > Hi, I've got nothing better to do at the moment so I was wondering what > the best way to help move things forwards and contribute back to the > project. :-) Glad to meet you :-) I have a page that might help: http://kegel.com/wine/sweng/ Hope it helps. Let me know if there's anything unclear there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Alexandre Julliard : server: Don't round up the header size for image mappings.
by Michael Jung 13 Jan '06

13 Jan '06

Hi, On Wednesday 11 January 2006 21:34, Alexandre Julliard wrote: > http://source.winehq.org/git/?p=wine.git;a=commit;h=b54e9e94e98624acde1bb00 > e10c2055dfed9c2d7 > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Jan 11 20:59:26 2006 +0100 > > server: Don't round up the header size for image mappings. This patch prevents certain executables (at least those generated with Borland C++ 5.02) from being loaded. I've attached a small example. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: advpack: Implement RunSetupCommand on top of DoInfInstall.
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement RunSetupCommand on top of DoInfInstall. > The same comments for LaunchINFSection apply here as well. If these three APIs just call DoInfInstall, then what's the point in having them? We need to implement these correctly the first time around. -- James Hawkins

1 0

Re: advpack: Implement LaunchINFSectionEx on top of DoInfInstall.
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSectionEx on top of DoInfInstall. > The same comments for LaunchINFSectionEx apply here as well. LaunchINFSectionEx also needs the backup and restore capabilities that DoInfInstall can't provide. -- James Hawkins

1 0

Trying to debug a crash
by Aaron Conole 13 Jan '06

13 Jan '06

I'm trying to figure out what's going on with my system, as I'm looking to get Steam + Counter Strike: Condition Zero working as correctly as possible under my system. After fighting with the Steam updater, I finally figured out exactly how Steam is doing updates, and can reliably get past the 26%/27% mark (I'll post something to the master wine-users list once I know how to solve the bulk of problems). So, steam now loads, I can activate my products, and for a while I was able to play CZ. That changed, however, and now I can't launch any games without a crash. The following is my wine ver, a backtrace, and register dump. If you could let me know what I should be looking for when I'm debugging this (like, how I can figure out whether I'm in a native or builtin library, etc..) it would be much appreciated. Thanks, Aaron Wine 20040813 ==================== Wine-dbg>bt Backtrace: 1 0xffffe410 (0x401feb4c) =>2 0x401dce63 .L133+0x23 in ntdll (0x401fecf8) 3 0x401dbc17 usr1_handler+0x47 in ntdll (0x401fed1c) 4 0xffffe420 (0x406fe6bc) 5 0x401dce63 .L133+0x23 in ntdll (0x406fe868) 6 0x401dd076 NtWaitForMultipleObjects+0x66 in ntdll (0x406fe890) 7 0x40515899 WaitForMultipleObjectsEx+0xc9 in kernel32 (0x406fe9c0) 8 0x40515ab8 WaitForSingleObject+0x38 in kernel32 (0x406fe9e0) 9 0x404d5a6f UnhandledExceptionFilter+0xa9f in kernel32 (0x406fec78) 10 0x014073f1 (0x406fec90) 11 0x0140390b (0x406fff20) 12 0x40504462 start_process+0xf2 in kernel32 (0x406ffff4) 13 0x40042db1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) ==================== Wine-dbg>info registers Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:ffffe410 ESP:401feb0c EBP:401feb4c EFLAGS:00200246( - 00 - IZP1) EAX:fffffe00 EBX:00000007 ECX:401feb38 EDX:00000008 ESI:401fd000 EDI:401feb38 ==================== Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000034 1 00000032 'C:\windows\system\winedbg.exe' 00000032 1 00000008 'C:\Program Files\Valve\Steam\SteamApps \orgcandman\condition zero\hl.exe' 00000008 34 00000000 'C:\Program Files\Valve\Steam\Steam.exe'

2 1

Re: advpack: Implement RunSetupCommand on top of DoInfInstall.
by Marcelo Duarte 13 Jan '06

13 Jan '06

Markus Amsler escreveu: > ChangeLog: > Implement RunSetupCommand on top of DoInfInstall. You forgot to remove "stub": > + TRACE("(%p, %s, %s, %s, %s, %p, 0x%08lx, %p): stub\n", > hWnd, debugstr_a(szCmdName), debugstr_a(szInfSection), > debugstr_a(szDir), debugstr_a(lpszTitle), > phEXE, dwFlags, pvReserved); >

1 0

Re: Still need help fixing deadlock (GDI/metafile)
by Cihan Altinay 13 Jan '06

13 Jan '06

Huw, I put you on Cc for this thread in the hope to get some information on this issue. Is there any side effect if undefining STRETCH_VIA_DIB? Also, do you know where the problem might be? Regards, Cihan Walt Ogburn wrote: > Hi Cihan, > > I'm glad it works. It looks like Huw D M Davies changed STRETCH_VIA_DIB > from being unset to set in 2002. I think he's still around at > huw(a)codeweavers.com. Maybe you could ask him whether it could be changed > back to the other method. > > - Walter > > On Thu, 12 Jan 2006, Cihan Altinay wrote: > > >>Hi Walter, >> >>Walt Ogburn wrote: >> >>>Hi Cihan, >>> >>>What happens if you comment out #define STRETCH_VIA_DIB in >>>dlls/gdi/mfdrv/bitblt.c? This will make it use GetBitmapBits instead of >>>GetDIBits. >> >>Indeed, this does the trick! >>No locking problems... Will try to look into that. >> >> >>>- Walter >> >>Thanks a lot, >>Cihan >> >> >>>On Wed, 11 Jan 2006, Cihan Altinay wrote: >>> >>> >>> >>>>Since nobody seems to be able to help me with this problem at the moment >>>>I opened a bug report[1] for it. I would appreciate if somebody with >>>>more knowledge could take a quick look at it. Thanks! >>>> >>>>Cihan >>>> >>>>[1] http://bugs.winehq.org/show_bug.cgi?id=4284 >>>> >>>> >>>>Cihan Altinay wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I am still trying to finding the reason for PowerPoint 2000 causing a >>>>>deadlock if a file is opened that contains a preview which itself >>>>>contains a bitmap >90x90 pixels (ie. on the first slide). >>>>>After inserting some traces I feel I am pretty close but I'm >>>>>stuck since before the holidays. The problem is connected to GDI's >>>>>and/or metafile's StretchBlt (bitblt.c). >>>>>It calls MFDRV_StretchBlt and then the trouble begins as can be seen >>>> >>>>>from the output: >>>> >>>>><snip> >>>>>trace:bitblt:StretchBlt --Start-- >>>>>trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 >>>>>trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 >>>>>trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 >>>>>PixYPM=3780 Caps=96 >>>>>trace:bitmap:GetDIBits >>>>>trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec >>>>>err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 >>>>></snip> >>>>> >>>>>Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. >>>>>There is a comment "FIXME: there is a race condition here". Could that >>>>>be the cause for the deadlock? >>>>>Btw. this might be the same problem as bug #3125 as both refer to the >>>>>preview and both cause a deadlock. >>>>> >>>>>Can somebody give me a hint on how to tackle this? It is really important >>>>>for us... If you need more output please let me know. >>>>> >>>>>Thanks a lot, >>>>>Cihan >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >>

1 0

Mozilla ActiveX Control -- Browser not in a valid state
by Phil Lodwick 12 Jan '06

12 Jan '06

Hi, I have a Borland C++ Builder app that is a simple FORM with a TCppWebBrowser and a button. I have two callbacks, one when the form is created, and one when the user pushes the button. Both callbacks just navigate to google. ================================ __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { CppWebBrowser1->Navigate(WideString("http://www.google.com")); } void __fastcall TForm1::DoIt1Click(TObject *Sender) { CppWebBrowser1->Navigate(WideString("http://www.google.com")); } ================================ On Windows this works as expected. When the form is displayed, google is displayed in the browser. Whenever you push the button the browser is reloaded. On Wine with the Mozilla ActiveX Control v1.7.12, when the form is first loaded nothing is displayed. WINEDEBUG=+ole shows "Browser is not in a valid state". Pushing the button subsequent times reloads the web site as expected. Before I start digging deeper, I was hoping somebody might have some insight to lead me down the correct path. Thanks! Phil

2 1

New wannabe developer
by Zoe Parsons 12 Jan '06

12 Jan '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got nothing better to do at the moment so I was wondering what the best way to help move things forwards and contribute back to the project. :-) - -- Zoe Parsons | skype:mpsonscix zoe(a)theasylum.demon.co.uk | http://livejournal.com/~zoep mpsons(a)cix.compulink.co.uk | ICQ:97984995 aim:mpsonscix | yim:mpsons_cix | msn:zoe@theasylum.demon.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxqIAbbnfPjpiTWURArEMAKCWH2i3rAHqfPmcFLnZI78XjFJVNwCgh44G hGMVPYk008XHB34dJyr9Gik= =LJPa -----END PGP SIGNATURE-----

2 1

Re: Preserve gcc 2.95 compatibility in crypt32
by Michael Stefaniuc 12 Jan '06

12 Jan '06

Jeremy White wrote: > Changelog: > * Use the U() macros to preserve gcc 2.95 compatibility Heh, and linux just dropped support for anything below gcc 3.2: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm… Maybe we want to drop that too. Let the flame war begin ... bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Re: MSACM: implement honouring of driver priority and enabled status at load time
by Mike McCormack 12 Jan '06

12 Jan '06

Alex Villacís Lasso wrote: > + } > + } > + } > + } > + } > + } > + } > + } > +} Hmm. A 100 line function with 10 levels of indent... Any chance of rewriting this to reduce the level of indent? Try using some helper functions or return early. You might understand it all well, but this kind of code is difficult to follow and maintain. Mike

1 0

crash in GetKerningPairs
by Piotr Pawłow 12 Jan '06

12 Jan '06

Hello, Wine's implementation of GetKerningPairs in dlls/gdi/font.c behaves incorrectly (crashes) if lpkrnpair is NULL and nNumPairs is not zero. Test program: ---------- #include <windows.h> int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { HDC hdc = GetDC(NULL); int kp = GetKerningPairs(hdc, 1, NULL); char msg[200]; sprintf(msg, "GetKerningPairs returns: %d\n", kp); MessageBox(NULL, msg, "success", MB_OK); return 0; } ---------- On Windows (tested on XP SP2) this program displays a message box and exits cleanly. On Wine it causes a page fault trying to write to address 0x00000004. It's probably a trivial problem, but unfortunately I don't have time right now to investigate the issue and make a patch against current CVS. Best regards, -- Piotr Pawłow mailto:pp@siedziba.pl

2 1

Symbol fonts bug
by David Moore 12 Jan '06

12 Jan '06

Hi, I submitted a patch (attached) on the 15th of December. Without my patch, Solar Fire is broken on Wine, as it can't display its symbol font (codepage 42) correctly. As far as I can tell, according to this documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unico…, my patch does the right thing in freetype.c to make sure UTF7, UTF8 and Symbol fonts will be displayed properly after going through the affected function call. My patch has not been included yet. I was wondering whether this had anything to do with the format of the patch, the coding style or something else I can fix to get the patch included. This patch is very important to me, so I'm happy to take suggestions to fix it if necessary. thanks, David Moore

1 0

Re: Static control [06/10]: STN_ENABLE and STN_DISABLE notifications
by James Hawkins 12 Jan '06

12 Jan '06

On 1/11/06, Michael Kaufmann <hallo(a)michael-kaufmann.ch> wrote: > > > --- static-old.c 2006-01-11 22:43:23.000000000 +0100 > +++ static.c 2006-01-11 22:44:20.000000000 +0100 > @@ -31,10 +31,6 @@ Think you forgot the changelog. -- James Hawkins

2 1

Still need help fixing deadlock (GDI/metafile)
by Cihan Altinay 12 Jan '06

12 Jan '06

Hi, I am still trying to finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some traces I feel I am pretty close but I'm stuck since before the holidays. The problem is connected to GDI's and/or metafile's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is a comment "FIXME: there is a race condition here". Could that be the cause for the deadlock? Btw. this might be the same problem as bug #3125 as both refer to the preview and both cause a deadlock. Can somebody give me a hint on how to tackle this? It is really important for us... If you need more output please let me know. Thanks a lot, Cihan

2 3

Regression caused by "ntdll: Check file size when mapping image sections to avoid SIGBUS errors."
by Troy Rollo 11 Jan '06

11 Jan '06

On Wed, 4 Jan 2006 08:21, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 67f29999a36ce3725a52b79ed618964244cc96ae ... > status = STATUS_INVALID_IMAGE_FORMAT; /* generic error */ > + if (header_size > st.st_size) goto error; > if (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED | ... This change prevents Wine from loading Win32 executables that are less than 64K long. header_size is 65536, but st.st_size is less than that. -- Troy Rollo - wine(a)troy.rollo.name

2 3

Re: ntdll/tests: Load test on win95 again
by Alexandre Julliard 11 Jan '06

11 Jan '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > Changelog: > > - ntdll/tests: Load test on win95 again > (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: A modest proposal
by gslink 11 Jan '06

11 Jan '06

The whole point of what I am proposing is a collaboration with RH so that new features are in the distributed Wine. If they are willing to undertake one of the tasks that Wine HQ is now doing then we should let them. At least they are supposed to know RH so they should be capable of the task. This would free manpower for some sorely needed other tasks.

1 0

Re: modifying _fullpath test
by Alexandre Julliard 11 Jan '06

11 Jan '06

Aric Stewart <aric(a)codeweavers.com> writes: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. It would be better to use something like GetTempPath instead of hardcoding the directory name. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: modifying _fullpath test
by Dmitry Timoshkov 11 Jan '06

11 Jan '06

"Aric Stewart" <aric(a)codeweavers.com> wrote: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. > - SetCurrentDirectory("C:\\Windows\\System\\"); > + free1=free2=TRUE; > + rc = CreateDirectory("C:\\msvcrt-test\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free1=FALSE; > + rc = CreateDirectory("C:\\msvcrt-test\\nextlevel\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free2=FALSE; > + SetCurrentDirectory("C:\\msvcrt-test\\nextlevel\\"); Drive C: root directory is not the best place to create temporary directories, I'd suggest to use GetTempPath (and maybe GetTempFileName) to get a more appropriate starting point. -- Dmitry.

1 0

Re: advpack: Implement ExtractFiles
by Mike McCormack 11 Jan '06

11 Jan '06

James Hawkins wrote: > What is the policy about attaching changes to tests that pass because > of a patch sent in? Should I also diff the tests? There's a higher level policy of "all changes should be atomic", which requires Wine to be in a working state before and after each change, so yes, you should update tests that pass with the patch that makes them pass. If you're adding new tests, it makes sense to send them in a seperate patch after the patch that implements functionality to make the new tests pass. Mike

1 0

Need help to fix a failing test
by Kai Blin 10 Jan '06

10 Jan '06

Hi folks, As far as I can see, secur32 tests are failing on all windows platforms right now. (http://test.winehq.org/data/200601101000/) Now, this seems to be due to the following: main.c:475: Test failed: cbMaxToken for NTLM is 1904, not 12000. I'm pretty sure that I got the 12000 from my win2k system when I compiled the test code there using the platform sdk that was current this july. Now, I have no clue where the 1904 comes from, but if windows really uses a cbMaxToken of 1904, I need to fix that in my code (I couldn't use the 12000 I thought I had to implement before due to implementation restrictions. I can easily work with 1904, if those are correct.) Still, I'm sure I didn't pull the 12000 out of my sleeve. Could I ask someone who runs msvc and a platform sdk to build the secur32 tests, run them on any windows box and send the results to me? Thanks in advance, Kai -- Kai Blin, (blin at gmx dot net) Are you mentally here at Pizza Hut??

1 0

Re: RESEND: winecfg: Added "Use PRIMARY selection" option
by Alexandre Julliard 10 Jan '06

10 Jan '06

Phil Krylov <phil(a)newstar.rinet.ru> writes: > ChangeLog: > > Added support for "Use PRIMARY selection" clipboard option. I don't think we want a new property sheet page for that, it should go with the other X11 options. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: WineDbg: Implemented harware assisted breakpoints.
by Eric Pouech 10 Jan '06

10 Jan '06

Eric Pouech wrote: > one can now set a hardware breakpoint in winedbg (it will not insert an > INT 3 command in the code, but rather use the x86 debug registers). > handy for debugging trashed code for example > > all the syntaxic forms of the 'break' command can be used for this new > hbreak command. > (only works on x86 for now) > > ChangeLog: > Implemented harware assisted breakpoints > merci de ne pas appliquer tel quel. J'ai une nouvelle version moins buggée. A+ -- Eric Pouech

1 0

RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso 10 Jan '06

10 Jan '06

(resent because previous attempt never appeared in wine-devel) This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso

2 2

Starter projects for new Wine contributors?
by Dan Kegel 10 Jan '06

10 Jan '06

Hi all! I'm looking for suggestions for starter projects for new contributors that would take something like a week to do, and wouldn't require much knowledge of Wine ahead of time. http://wiki.winehq.org/TodoList is the place we've gathered that stuff, but nothing there really grabs me. I suppose the tasks http://wiki.winehq.org/CrossCallsWtoA http://wiki.winehq.org/ConstifyData http://wiki.winehq.org/SpecDiscrepencies might qualify. Do they still need doing? http://winehq.org/site/fun_projects has some cool stuff on it, particularly the idea of using Mono's libgdiplus to implement gdi+ in Wine. (That's probably more than a week's worth of work, though.) http://wiki.winehq.org/SummerOfCode has very cool stuff in it, but that's all about 100x times harder than what I'm looking for. And then there's riched20. It's missing quite a few little features; see the 11 open bugs here: http://bugs.winehq.org/buglist.cgi?product=Wine&component=wine-richedit&bug… Might some of those be doable in a couple days? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 4

static COM VTables?
by Stefan Dösinger 10 Jan '06

10 Jan '06

Hello, I just read the "constify data" todo, and I thought it would be good to make the VTables in my ddraw implementation const. The old ddraw implementation also declares them static. Is there any advantage in it? My C book just says that they can only be referenced from the local module, which is correct. But are there any other effects? Stefan

2 1

RFC: implementation of driver functionality in msacm
by Alex Villacís Lasso 10 Jan '06

10 Jan '06

This patch is the preliminary result of some work I have been doing in order to add missing functionality to builtin msacm32.dll. I am submitting this to wine-devel rather than wine-patches, and in one big patch rather than several because I would like comments on some choices I made while adding features. The following is the list of features added by the patch: * Implementation of acmDriverAddW(), and delegation of acmDriverAddA() to acmDriverAddW() * Working implementation of modes of operation of acmDriverAdd[AW]: add driver by new registry entry (ACM_DRIVERADDF_NAME), add (local) driver by combination of hModule/acmDriverProc (ACM_DRIVERADDF_FUNCTION), add notification window for event broadcasts (ACM_DRIVERADDF_NOTIFYHWND) * Implementation of broadcasts to notification windows on driver add/remove, enabling/disabling, and priority changes * Fix for implementation quirks of acmDriverMessage() in order to allow native codecs to display configuration dialogs * Working implementation of acmDriverPriority(), with support of delayed notification broadcasts (for one process only). Includes saving new priorities and enabled status to registry * Loading of codec priorities and enabled status from registry * Support for ACM_METRIC_DRIVER_SUPPORT in acmMetrics() I must note that in order to provide support for acmDriverAddW() in ACM_DRIVERADDF_FUNCTION mode, it is necessary to treat an application-supplied module with an application-supplied driverProc as a full-blown winmm driver. Therefore, the patch includes a new procedure in winmm called wineAddDriver(), that instructs winmm to build a hDrvr from a supplied hModule/driverProc pair, rather than loading both from a DLL, as OpenDriver() does. This allows the rest of the code to continue using SendDriverMessage() as usual. Alex Villacís Lasso

1 0

test exploit for WMF / SETABORTPROC vulnerability
by Marcus Meissner 10 Jan '06

10 Jan '06

Hi, If someone needs an exploit for the WMF / SETABORTPROC vulnerability that works under WINE (<0.9.5) to verify fixed packages, feel free to mail me offline. Ciao, Marcus

1 0

Re: COMCTL32: Invalidate the entire progress bar any time it changes.
by Dmitry Timoshkov 10 Jan '06

10 Jan '06

"Mike McCormack" <mike(a)codeweavers.com> wrote: > This is an old patch, but the code that is in comctl32 now is wrong. > This fixes it, and there's no known regressions. Unfortunately there's > no way to fix this "efficiently". > > Mike > > > ChangeLog: > Invalidate the entire progress bar any time it changes. > Fixes the progress bar so it paints properly in InstallShield. My (old) tests show that native comctl32 invalidates the entire progress bar once it changes, so that change is OK. But it's smart enough to not invalidate the background if new bar position is larger than an old one, that reduces the flicker. -- Dmitry.

1 0

Loader Optimization Benchmarks
by Robert Shearman 10 Jan '06

10 Jan '06

Hi, I thought it would be good to post some benchmarks for the patch I just sent to wine-patches: http://www.winehq.org/pipermail/wine-patches/2006-January/023323.html I tested the loader code using the following in both cases: int i; DWORD dwTicksAfter; DWORD dwTicksBefore = GetTickCount(); for (i = 0; i < 1000; i++) LoadLibrary("ole32"); dwTicksAfter = GetTickCount(); trace("time taken = %ld ms\n", dwTicksAfter - dwTicksBefore); Before the patch: time taken = 658 ms time taken = 661 ms time taken = 661 ms time taken = 658 ms time taken = 659 ms After the patch was applied: time taken = 12 ms time taken = 12 ms time taken = 12 ms time taken = 13 ms time taken = 12 ms So it should be obvious that there are some very real gains from using this patch in the test case. You might think that an application loading a DLL 1000 times is very unlikely, but bear in mind that the ole32 marshal tests load ole32 76 times. It is therefore conceivable that something more complex like InstallShield could load ole32 over 100 times. -- Rob Shearman

1 0

(no subject)
by Curro Amores 10 Jan '06

10 Jan '06

I get this error when trying to install j2se with wine, i think is has something to do with windows installer, but ihave installed InstMSIA.exe manually with wine ( i dont get any error or see any installation box with "wine InstMSI.exe"). Has somebody tried to install JAva with wine? This is the output WINEDBG=+loaddll wine jdk-1_5_0_06-windows-i586-p.exe wine: Unhandled page fault on read access to 0x80002b1c at address 0x4d5d5b (thread 000c), starting debugger... WineDbg starting on pid 0x9 Unhandled exception: page fault on read access to 0x80002b1c in 32-bit code (0x004d5d5b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:004d5d5b ESP:7fc8fd24 EBP:7fc8fd64 EFLAGS:00010282( - 00 - RIS1) EAX:00000009 EBX:00000000 ECX:80002b08 EDX:0000000c ESI:80002b08 EDI:00000000 Stack dump: 0x7fc8fd24: 00000048 004d5b8f 00000000 004d17c6 0x7fc8fd34: 7fec0b40 004d15a4 00bfd1b0 00911f7c 0x7fc8fd44: 7fc8fd64 00911fa2 7fc8fd34 7fc8f8e0 0x7fc8fd54: 7fc8ff2c 004d53e8 00514a70 ffffffff 0x7fc8fd64: 7fc8fd84 00bcc611 004d0000 00000001 0x7fc8fd74: 00000001 00000001 00000001 00bfd1b0 0200: sel=1007 base=7befc000 limit=00001fff 32-bit rw- Backtrace: =>1 0x004d5d5b in rpcrt4 (+0x5d5b) (0x004d5d5b) 2 0x00bcc611 call_dll_entry_point+0x15 in ntdll (0x00bcc611) 3 0x00bcd252 MODULE_InitDLL+0x12a [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:816] in ntdll (0x00bcd252) 4 0x00bcda98 process_attach+0x98 [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:891] in ntdll (0x00bcda98) 5 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 6 0x00bcda6e process_attach+0x6e [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:883] in ntdll (0x00bcda6e) 7 0x00bcfe19 LdrInitializeThunk+0x319(main_file=0x0, unknown2=0x0, unknown3=0x0, unknown4=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/ntdll/loader.c:2001] in ntdll (0x00bcfe19) 8 0x005eff1f start_process+0x8b(arg=0x0) [/home/curro/WineHQrpm/wine-0.9.5/dlls/kernel/process.c:1017] in kernel32 (0x005eff1f) 9 0x0033185b _IO_vfprintf_internal in libc.so.6 (0x0033185b) 0x004d5d5b: cmpl 0x14(%esi),%eax Modules: Module Address Debug info Name (43 modules) ELF 0x0025f000-00299000 Deferred advapi32<elf> \-PE 0x00270000-00299000 \ advapi32 ELF 0x002c8000-002cd000 Deferred libxxf86vm.so.1 ELF 0x002d2000-002ee000 Deferred ld-linux.so.2 ELF 0x002ee000-0031c000 Deferred libfontconfig.so.1 ELF 0x002ee000-0031c000 Deferred libfontconfig.so.1 ELF 0x002f4000-0041e000 Export libc.so.6 ELF 0x00346000-0043c000 Deferred libwine_unicode.so.1 ELF 0x00420000-00426000 Deferred libxxf86dga.so.1 ELF 0x00420000-00426000 Deferred libxxf86dga.so.1 ELF 0x00446000-0044a000 Deferred libdl.so.2 ELF 0x0044a000-004cb000 Deferred gdi32<elf> \-PE 0x0044c000-0045f000 \ libz.so.1 \-PE 0x00460000-004cb000 \ gdi32 \-PE 0x00460000-004cb000 \ gdi32 PE 0x004d0000-00522000 Deferred rpcrt4 ELF 0x00537000-00549000 Deferred libpthread.so.0 ELF 0x0054b000-0055a000 Deferred libxext.so.6 ELF 0x0055c000-00565000 Deferred libsm.so.6 ELF 0x00567000-00581000 Deferred libice.so.6 ELF 0x00583000-005a2000 Deferred libexpat.so.0 ELF 0x00583000-005a2000 Deferred libexpat.so.0 PE 0x005b0000-0067e000 DIA kernel32 PE 0x005b0000-0067e000 DIA kernel32 PE 0x005b0000-0067e000 DIA kernel32 PE 0x00680000-0086c000 Deferred msi ELF 0x0086c000-0097a000 Deferred user32<elf> \-PE 0x00890000-0097a000 \ user32 \-PE 0x00890000-0097a000 \ user32 ELF 0x00975000-009f0000 Deferred libgl.so.1 ELF 0x00975000-009f0000 Deferred libgl.so.1 PE 0x009f0000-00a59000 Deferred winex11 ELF 0x00b2d000-00b4c000 Deferred ximcp.so.2 ELF 0x00b4c000-00b67000 Deferred imm32<elf> \-PE 0x00b50000-00b67000 \ imm32 ELF 0x00b99000-00c09000 Stabs ntdll<elf> \-PE 0x00bb0000-00c09000 \ ntdll ELF 0x00ea3000-00ea5000 Deferred xlcutf8load.so.2 ELF 0x00ef1000-00f07000 Deferred msiexec<elf> \-PE 0x00f00000-00f07000 \ msiexec ELF 0x00fed000-00ff8000 Deferred libnss_files.so.2 PE 0x65f00000-65fc2000 Deferred ole32 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000009 (D) C:\windows\system32\MSIEXEC.EXE 0000000c 0 <== 00000047 00000008 0 0000001e 00000026 2 0000001f 0 WineDbg terminated on pid 0x9

4 4

A modest proposal
by gslink 10 Jan '06

10 Jan '06

I noticed that for FC4 Red Hat is providing a copy of Wine in extras. This is something that THEY are producing and it is in a different form from the one put out by Wine HQ. It appears to me that there is no reason for Wine HQ to duplicate their effort and suggest some sort of collaboration. The version posted by RH seems to be later than what is posted by Wine HQ. I think this should be investigated.

2 1

daily winetest generation
by Saulius Krasuckas 09 Jan '06

09 Jan '06

I may perfectly repeat someones else question, but why in the world winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the patches arrives too late during partical day? I think compiled EXEs should be released regardless of their generation date. No?

3 5

Regression in Icewind Dale II
by James Trotter 09 Jan '06

09 Jan '06

I've been trying to run the game Icewind Dale II under wine 0.9.4, but it crashes before the game starts. In earlier versions of wine it worked fine. I've found that the regression was caused by this patch: http://cvs.winehq.org/patch.py?id=17222 Here's the output from running the game in wine 0.9.4: james@james:~/Wine/Games/Icewind Dale II$ wine IWD2.exe BEGIN LOGGING SESSION wine: Unhandled page fault on read access to 0x31303635 at address 0x7ab8f1 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x31303635 in 32-bit code (0x007ab8f1). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7fabab94 EBP:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:31303635 EBX:00000001 ECX:7fabb444 EDX:00000000 ESI:7fabb31c EDI:7beb3820 Stack dump: 0x7fabab94: 31303635 00002711 00000000 7fabb31c 0x7fababa4: 7fababd4 007aaf30 7fabb20c 7fabaf54 0x7fababb4: 00000000 00002711 40c38800 7fabb31c 0x7fababc4: 7fabac84 0084566a 00000007 7fcf0690 0x7fababd4: 7fcf0690 0078e3ca 00000000 7fabaf54 0x7fababe4: 00400000 7fd12606 7fabaf54 00010000 0200: sel=1007 base=7fec4000 limit=00001fff 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x007ab8f1) 0x007ab8f1: movl 0x0(%eax),%ecx Modules: Module Address Debug info Name (95 modules) PE 0x00400000-00a21000 Export iwd2 ELF 0x7391a000-73922000 Deferred libxrender.so.1 ELF 0x7be8c000-7bf00000 Deferred ntdll<elf> \-PE 0x7bea0000-7bf00000 \ ntdll ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7c9b5000-7ca01000 Deferred libgcrypt.so.11 ELF 0x7ca01000-7ca11000 Deferred libtasn1.so.2 ELF 0x7ca11000-7ca73000 Deferred libgnutls.so.11 ELF 0x7ca73000-7ca90000 Deferred libcups.so.2 ELF 0x7db8b000-7dbbb000 Deferred uxtheme<elf> \-PE 0x7db90000-7dbbb000 \ uxtheme ELF 0x7dbbb000-7dbd0000 Deferred midimap<elf> \-PE 0x7dbc0000-7dbd0000 \ midimap ELF 0x7dce6000-7dd08000 Deferred msacm32<elf> \-PE 0x7dcf0000-7dd08000 \ msacm32 ELF 0x7dd08000-7dd1f000 Deferred msacm<elf> \-PE 0x7dd10000-7dd1f000 \ msacm ELF 0x7dd1f000-7ddd2000 Deferred libasound.so.2 ELF 0x7ddd2000-7ddfa000 Deferred winealsa<elf> \-PE 0x7dde0000-7ddfa000 \ winealsa ELF 0x7de18000-7de21000 Deferred libxcursor.so.1 ELF 0x7de2c000-7de48000 Deferred ximcp.so.2 ELF 0x7de48000-7de50000 Deferred librt.so.1 ELF 0x7df0a000-7e64d000 Deferred fglrx_dri.so ELF 0x7e64d000-7e6ec000 Deferred libgl.so.1 ELF 0x7e6ec000-7e769000 Deferred winex11<elf> \-PE 0x7e700000-7e769000 \ winex11 ELF 0x7e769000-7e788000 Deferred libexpat.so.1 ELF 0x7e788000-7e7b6000 Deferred libfontconfig.so.1 ELF 0x7e7b6000-7e7ca000 Deferred libz.so.1 ELF 0x7e7ca000-7e834000 Deferred libfreetype.so.6 ELF 0x7e834000-7e85c000 Deferred winspool<elf> \-PE 0x7e840000-7e85c000 \ winspool ELF 0x7e85c000-7e90b000 Deferred comctl32<elf> \-PE 0x7e870000-7e90b000 \ comctl32 ELF 0x7e90b000-7e960000 Deferred shlwapi<elf> \-PE 0x7e920000-7e960000 \ shlwapi ELF 0x7e960000-7ea1f000 Deferred shell32<elf> \-PE 0x7e980000-7ea1f000 \ shell32 ELF 0x7ea1f000-7eab1000 Deferred comdlg32<elf> \-PE 0x7ea30000-7eab1000 \ comdlg32 ELF 0x7eab1000-7eada000 Deferred ws2_32<elf> \-PE 0x7eac0000-7eada000 \ ws2_32 ELF 0x7eada000-7eaf5000 Deferred imm32<elf> \-PE 0x7eae0000-7eaf5000 \ imm32 ELF 0x7eaf5000-7eb09000 Deferred lz32<elf> \-PE 0x7eb00000-7eb09000 \ lz32 ELF 0x7eb09000-7eb21000 Deferred version<elf> \-PE 0x7eb10000-7eb21000 \ version ELF 0x7eb21000-7eb25000 Deferred libxdmcp.so.6 ELF 0x7eb25000-7ebe5000 Deferred libx11.so.6 ELF 0x7ebe5000-7ebf2000 Deferred libxext.so.6 ELF 0x7ebf2000-7ebf7000 Deferred libxxf86vm.so.1 ELF 0x7ebf7000-7ec10000 Deferred libice.so.6 ELF 0x7ec10000-7ec88000 Deferred ddraw<elf> \-PE 0x7ec30000-7ec88000 \ ddraw ELF 0x7ec88000-7ecd3000 Deferred dsound<elf> \-PE 0x7eca0000-7ecd3000 \ dsound ELF 0x7ecd3000-7ecf1000 Deferred iphlpapi<elf> \-PE 0x7ece0000-7ecf1000 \ iphlpapi ELF 0x7ecf1000-7ed35000 Deferred rpcrt4<elf> \-PE 0x7ed00000-7ed35000 \ rpcrt4 ELF 0x7ed35000-7edbb000 Deferred ole32<elf> \-PE 0x7ed50000-7edbb000 \ ole32 ELF 0x7edbb000-7edf7000 Deferred advapi32<elf> \-PE 0x7edd0000-7edf7000 \ advapi32 ELF 0x7eedd000-7f7dd000 Deferred gdi32<elf> \-PE 0x7ef20000-7f7dd000 \ gdi32 ELF 0x7f7dd000-7f8f6000 Deferred user32<elf> \-PE 0x7f800000-7f8f6000 \ user32 ELF 0x7f8f6000-7f977000 Deferred winmm<elf> \-PE 0x7f900000-7f977000 \ winmm ELF 0x7f977000-7f9b0000 Deferred dplayx<elf> \-PE 0x7f990000-7f9b0000 \ dplayx ELF 0x7fac0000-7fac5000 Deferred libxxf86dga.so.1 ELF 0x7fac5000-7fad0000 Deferred libgcc_s.so.1 ELF 0x7fc74000-7fd70000 Deferred kernel32<elf> \-PE 0x7fc90000-7fd70000 \ kernel32 ELF 0x7fe81000-7fe88000 Deferred libsm.so.6 ELF 0x7fe88000-7fe92000 Deferred libnss_files.so.2 ELF 0x7fe92000-7fe9b000 Deferred libnss_nis.so.2 ELF 0x7fe9b000-7feb0000 Deferred libnsl.so.1 ELF 0x7feb0000-7feb9000 Deferred libnss_compat.so.2 ELF 0x7feba000-7febe000 Deferred libgpg-error.so.0 ELF 0x7febe000-7fec2000 Deferred libxfixes.so.3 ELF 0x7fec2000-7fec4000 Deferred xlcutf8load.so.2 ELF 0x7fec7000-7fee9000 Deferred libm.so.6 ELF 0x7fee9000-7ffe0000 Deferred libwine_unicode.so.1 ELF 0xb7e00000-b7e03000 Deferred libxrandr.so.2 ELF 0xb7e11000-b7e14000 Deferred libdl.so.2 ELF 0xb7e14000-b7f42000 Deferred libc.so.6 ELF 0xb7f42000-b7f54000 Deferred libpthread.so.0 ELF 0xb7f54000-b7f6e000 Deferred libwine.so.1 ELF 0xb7f6e000-b7f71000 Deferred libxau.so.6 ELF 0xb7f7c000-b7f92000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Games\Icewind Dale II\IWD2.exe 00000009 0 <== WineDbg terminated on pid 0x8

4 6

Re: shlwapi: Finnish translation (resent)
by Alexandre Julliard 09 Jan '06

09 Jan '06

"Ge van Geldorp" <gvg(a)reactos.org> writes: > Previously sent > http://www.winehq.org/pipermail/wine-patches/2005-December/023112.html > > (shlwapi_Fi.rc sent as attachment instead of inline in the hope it won't get > mangled then) Could you please send it as a proper patch? It makes things a lot easier for me (you can still send the whole patch as an attachment if you think it will get mangled). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cabinet: Implement Extract on top of FDI
by Alexandre Julliard 09 Jan '06

09 Jan '06

James Hawkins <truiken(a)gmail.com> writes: > @@ -30,6 +30,7 @@ > #define NO_SHLWAPI_REG > #include "shlwapi.h" > #undef NO_SHLWAPI_REG > +#include "msvcrt/fcntl.h" You shouldn't use msvcrt headers if you are not importing msvcrt, this will cause trouble. Simply copy the definitions you need, like we already do for S_IREAD/IWRITE. -- Alexandre Julliard julliard(a)winehq.org

1 0

Implementing SYS-files for Wine
by Anton Litvinov (wine_user) 09 Jan '06

09 Jan '06

I want to run a proprietary program which does the following things: ... fh = CreateFileA("C:\WINDOWS\system32\DRIVERS\BIOSMAP.SYS", ...); ... dh = CreateFileA("\\.\BIOSMAP", ...); ... r = DeviceIoControl(dh, 0x10000000, ...); ... On recieving 0x10000000 code BIOSMAP maps BIOS content (brand, creation date, etc) to some area and returns address of one null-terminated string from it to main program. Is there a way to re-implement a SYS-file (so that main program would run w/o any change) like it's done with some VXD's in Wine-tree? Can I get some examples? Hope to get your answer, Anton Litvinov

2 1

Re: user: Fix dropdown combo creation when there is no space for an edit control
by Phil Krylov 09 Jan '06

09 Jan '06

Hi, Sorry, I meant: ChangeLog: Fixed dropdown combo creation when there is NO space for an edit control. -- Ph.

1 0

Re: shell32: fix folder icon index when read from registry
by Vitaliy Margolen 09 Jan '06

09 Jan '06

Saturday, January 7, 2006, 9:30:34 AM, Martin Fuchs wrote: > Changelog: > - fix folder icon index when read from registry > - change "DWORD dwNr" into "int icon_idx" at several places Any reason you using int* instead of LPINT? > Index: shell32_main.h > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shell32_main.h,v > retrieving revision 1.110 > diff -u -p -d -r1.110 shell32_main.h > --- shell32_main.h 28 Nov 2005 11:04:35 -0000 1.110 > +++ shell32_main.h 7 Jan 2006 16:19:07 -0000 Please rediff from the top of the tree.

3 2

Re: Question regarding the Wine Vs WineLib performance
by wine-devel-bounces＠winehq.org 09 Jan '06

09 Jan '06

{\rtf1\ansi\ansicpg1252\fromtext \deff0{\fonttbl {\f0\fswiss Arial;} {\f1\fmodern Courier New;} {\f2\fnil\fcharset2 Symbol;} {\f3\fmodern\fcharset0 Courier New;}} {\colortbl\red0\green0\blue0;\red0\green0\blue255;} \uc1\pard\plain\deftab360 \f0\fs20 On 1/3/06, Ananth M <mekaananth(a)gmail.com> wrote:\par > Then I converted the dll into .so and compiled and linked this .so\par > with win32 program using WineLib and Wineg++\par > The timing that was taken to execute the function exported by the\par > dll ( through .so ) is almost two times, compread with executing using wine.\par >\par > Does any one has any reference for further investigation on this\par > problem or any information\par \par I'm not sure if this is the reason or not, but we discussed this a bit\par at WineConf last year. The concensus was that MSVC produces much\par faster code compared to GCC. Maybe try compiling with MinGW on\par Windows and see what happens with the DLL in Windows?\par \par -Brian\par \par }

4 3

Need help in debugging a stack corruption
by Stefan Dösinger 07 Jan '06

07 Jan '06

Hello, I am working on a DDraw rewrite with WineD3D, and I've hit a problem with Half-Life, which looks like a stack corruption. HL makes a ret from a function which leads into sensless code, and I wasn't able to debug it. That's what happens: From 0x00428a35 there's a call to a function at 0x00408b70. This function calls a lot of DDraw calls, which seem to work fine, but on return, it doesn't return to 0x00428a3a, as it should, but to 0x7fbcd888, which is valid, but contains only garbage code. I assumed that some call runs amok on the stack, and I've set tried setting breakpoints at 0x00428a35, 0x00408b70 and some other addresses. Oddly, this doesn't work(winedbg disables them when continuing), although I can access the code right after start. I can set a DebugBreak() in the last called function(IDirectDraw::FlipToGDISurface), but there it is too late. Are there any other ways to debug this? Does anyone know why setting the breakpoints fails? Well, that's my suspicion for the problem: (an any COM expert comment on this?) To create interfaces for IDirectDraw1 to 7, I created 4 lpVtbl structures for each version, and I cast most DD7 funtions info the older versions. Only where the type or the number of parameters is different, I use a wrapper function. At DD creation, I use whatever version was requested by the app for the new object. The old dd version used a number of macros to cast the various interfaces(defined in ddcomimpl.h). I don't use them. Might this cause the problem? Thanks for your help, Stefan

4 7

Re: Rein Klazes : user32: Separate menu bitmaps and strings.
by paul 07 Jan '06

07 Jan '06

Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: b34868dffa0df144ea9d6e1586a67cff70ae9c4e > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=b34868dffa0df144ea9d6e1… > > Author: Rein Klazes <wijn(a)wanadoo.nl> > Date: Tue Jan 3 13:23:28 2006 +0100 > > user32: Separate menu bitmaps and strings. > Store bitmaps and bitmaps always in separate fields in the internal > menu structure. Get rid of a lot of assumptions in the code that the > menu can have strings only when it is not some other type and that > bitmaps come in two flavors. > Add a lot of conformance tests, including some submitted by Jason > Edmeades. > > --- > > dlls/user/menu.c | 317 ++++++++++++++++---------- > dlls/user/tests/menu.c | 593 ++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 785 insertions(+), 125 deletions(-) > > > > Regression see http://bugs.winehq.org/show_bug.cgi?id=4250 The set last error function added to GetMenuStringA and GetMenuStringW removed this check which seems to be still needed. if (!IS_STRING_ITEM(item->fType)) return 0; I have tried several times to make a patch of the changes required but I get a lot of white space changes. Paul R.

3 2

Microsoft Office on FreeBSD
by Tom Wickline 07 Jan '06

07 Jan '06

Hello, I've put together a little Microsoft Office on BSD howto on the Wiki, If anyone here uses OpenBSD, NetBSD or DragonFlyBSD I would be interested to know if you can get Office 2000 to install and run with Wine out of the box or with my cheats. :D So others who read the howto in the future will know the status of there distro. http://wiki.winehq.org/Office-BSD?action=show Tom

1 0

Re: shell32: Reimplement a factored SHFileOperation [RESEND 2]
by Mike McCormack 07 Jan '06

07 Jan '06

James Hawkins wrote: > Haven't received any comments yet. Is there anything wrong with this > patch? I know it's large, but it can't be sent in pieces. The new > implementation passes all the tests. > > Changelog: > * Reimplement a factored SHFileOperation. > > dlls/shell32/shlfileop.c | 1131 +++++++++++++++++++--------------------- > dlls/shell32/tests/shlfileop.c | 242 ++------- Hi James, That's a lot of great work! Try submit the tests first with todo_wine {} blocks around the stuff that fails now, then submit a further change with your main patch that shows with tests now pass. That should reduce the size of your patch a little, and show how messed up the old implementation of SHFileOperation is. thanks, Mike

1 0

Re: commit 15667b36e43a571f6bb8726b9dec4f1099d2b4f9 (_fullpath)
by Detlef Riekenberg 06 Jan '06

06 Jan '06

Am Freitag, den 06.01.2006, 10:01 -0600 schrieb Aric Stewart: > ChangeLog: > Additional add a regression test for _fullpath > > dlls/msvcrt/tests/dir.c | 58 + + SetCurrentDirectory("C:\\Windows\\System\\"); + Please do not use a fixed Path. This will not work on many Systems: nt351: "c:\winnt351" nt4.0 + w2k: "c:\winnt" and every windows with a custom Install-Directory. + + ok(_fullpath(full,"test", MAX_PATH)>0,"_fullpath failed\n"); + ">0" is not correct for "char *". The Text in your Tests are useless. Please print error-values and received buffer-content. -- By By ... ... Detlef

1 0

Re: winspool: Printing-Environment-Support for GetPrinterDriverDirectory
by Detlef Riekenberg 06 Jan '06

06 Jan '06

Am Dienstag, den 03.01.2006, 00:51 +0100 schrieb Detlef Riekenberg: What can I do with this Patch ? > Changelog: > - Add Function "validate_envW" to validate the user-supplied > Printing Environment (respect "Windows Version" - Setting) > - Change GetPrinterDriverDirectoryW on top of "validate_envW" > to Report the native Path for NT and Win9x > - 2 Tests are now working in Wine > > > Synced to current git-version with suggestions from Alexandre: > Use a struct to handle the environment-specific parts > > > "validate_envW" / printenv_t will be used by more Functions later. > (WINSPOOL_OpenDriverReg as Example) > -- By By ... ... Detlef

1 0

Re: shell32: fix folder icon index when read from registry
by Martin Fuchs 06 Jan '06

06 Jan '06

Any thing wrong with this patch? On 31.12.2005 21:31:25 Martin Fuchs wrote: > Changelog: > fix folder icon index when read from registry > Index: folders.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/folders.c,v > retrieving revision 1.66 > diff -u -p -d -r1.66 folders.c > --- folders.c 26 Aug 2005 10:05:35 -0000 1.66 > +++ folders.c 31 Dec 2005 20:29:30 -0000 > @@ -166,7 +166,7 @@ static HRESULT getIconLocationForFolder( > LPWSTR szIconFile, UINT cchMax, int *piIndex, UINT *pwFlags) > { > IExtractIconWImpl *This = (IExtractIconWImpl *)iface; > - DWORD dwNr; > + DWORD dwNr; /*TODO: change to int type */ > WCHAR wszPath[MAX_PATH]; > WCHAR wszCLSIDValue[CHARS_IN_GUID]; > static const WCHAR shellClassInfo[] = { > '.','S','h','e','l','l','C','l','a','s','s','I','n','f','o',0 }; > @@ -202,9 +202,13 @@ static HRESULT getIconLocationForFolder( > if (!HCR_GetDefaultIconW(folder, szIconFile, cchMax, &dwNr)) > { > lstrcpynW(szIconFile, swShell32Name, cchMax); > - dwNr = IDI_SHELL_FOLDER; > + dwNr = (DWORD)-IDI_SHELL_FOLDER; > } > - *piIndex = -((uFlags & GIL_OPENICON) ? dwNr + 1 : dwNr); > + > + if (uFlags & GIL_OPENICON) > + *piIndex = (int)dwNr<0? (int)dwNr-1: dwNr+1; > + else > + *piIndex = dwNr; > } > return S_OK; > }

2 1

Re: commctl32 datetime fields mad editable with keyboard
by Robert Shearman 06 Jan '06

06 Jan '06

Siim Karus wrote: >@@ -962,6 +1037,33 @@ > DATETIME_IncreaseField (infoPtr, fieldNum, INT_MAX); > DATETIME_SendDateTimeChangeNotify (infoPtr); > break; >+ case VK_NUMPAD0: >+ case VK_NUMPAD1: >+ case VK_NUMPAD2: >+ case VK_NUMPAD3: >+ case VK_NUMPAD4: >+ case VK_NUMPAD5: >+ case VK_NUMPAD6: >+ case VK_NUMPAD7: >+ case VK_NUMPAD8: >+ case VK_NUMPAD9: >+ DATETIME_EditField (infoPtr, fieldNum, vkCode-VK_NUMPAD0); >+ DATETIME_SendDateTimeChangeNotify (infoPtr); >+ break; >+ case (WORD)'0': >+ case (WORD)'1': >+ case (WORD)'2': >+ case (WORD)'3': >+ case (WORD)'4': >+ case (WORD)'5': >+ case (WORD)'6': >+ case (WORD)'7': >+ case (WORD)'8': >+ case (WORD)'9': >+ DATETIME_EditField (infoPtr, fieldNum, vkCode-(WORD)('0')); >+ DATETIME_SendDateTimeChangeNotify (infoPtr); >+ break; >+ > case VK_LEFT: > do { > if (infoPtr->select == 0) { > > I think this would be better done in the processing for the WM_CHAR message instead. Then you wouldn't have the mess of having to handle the numpad keys as well. -- Rob Shearman

1 0

bug in dlls/wined3d/device.c?
by Daniel Skorka 06 Jan '06

06 Jan '06

Hi, I have a question regarding the function IWineD3DDeviceImpl_ActiveRender at lines 5806-5807 (that is in wine 0.9.5). If I read [1] correctly, these two lines: PUSH2(GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT); PUSH2(GLX_X_RENDERABLE, TRUE); are illegal, as GLX_X_RENDERABLE must be FALSE when GLX_PBUFFER_BIT is set. Comments? Daniel [1] http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.…

1 0

WINE 0.9.3 and Photoshop 7 & CS
by Aleksey 06 Jan '06

06 Jan '06

Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop 7. Photoshop gave me a hardware error. I thought, no problem, I'll just reinstall it, same result. Then I reconfigured WINE using winetools and tried again, same thing. Here is what I got in the Terminal when running Photoshop 7: fixme:actctx:QueryActCtxW stub! fixme:font:WineEngRemoveFontResourceEx :stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de2c,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de2c,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e694, 0x7fa7e1ac, 0x7fa7e6f4, 0x7fa7e704 ) stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de34,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de34,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e69c, 0x7fa7e1b4, 0x7fa7e6fc, 0x7fa7e70c ) stub err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be called for simple PIDL's only! fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub Then I tried installing Photoshop CS, knowing that it worked fine with 0.9.2. Photoshop CS told me that certain required files was missing, but I forgot to get down the results from the Terminal. After that I downgraded to WINE 0.9.2 and both versions of Photoshop work great. A little side note: ImageReady 7 works great under 0.9.3, I did not test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but ImageReady CS crashes. God Bless. - Aleksey

6 8

Re: commctl32 datetime fix for certain VC++ AppWizard generated applications
by Robert Shearman 06 Jan '06

06 Jan '06

Siim Karus wrote: > As requested, I split my patches as I could. > > This patch causes Datetime and Calendar to be registered in DllMain > (as the tested applications never called InitCommonControls or > InitCommonControlsEx). I don't think this change is correct for ComCtl32 v5 or below. I am not sure about v6. I am pretty sure all that are registered are the ICC_WIN95_CLASSES as listed on MSDN. Please check your test applications. -- Rob Shearman

1 0

Labels on rotated display not drawing in 0.9 release
by Phil Lodwick 06 Jan '06

06 Jan '06

Hi, I have a display in the portrait position. I am using Option "Rotate" "90" in my XF86Config-4 file. When I rotate the screen like this, labels on Menus, Buttons, Dialog Boxes, etc do not display until after an expose event (eg. running a cursor over them). I have tried Wine 0.9, Wine 0.9.4 and CrossOver 5.0. I use winemine to test Wine, and NotePad in the CrossOver Office distribution to test that configuration -- all fail. If I don't rotate OR if I revert to the 20050524 release of Wine, the problem goes away. Any suggestions on where to start the hunt? Thanks, Phil

1 0

Re: Wine 0.9.5 no longer runs Dragon Naturally Speaking
by Scott Ritchie 06 Jan '06

06 Jan '06

There's no apt repository for old packages, however old debs are available here: http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=174803 I'll put a link to there on the download-deb page at winehq soon. I've forwarded this message to wine-devel as that's the proper place to report regressions, rather than emailing me. Thanks, Scott Ritchie On Fri, 2006-01-06 at 07:36 +0100, Emmanuel Charpentier wrote: > Dear Scott, > > As stated in the title, Wine 0.9.5 no longer runs Dragon Naturally > Speaking (voice recognition). I Cc this mail to peter(a)piments.com, > because he's seriously interested with this program (he published the > how-to-install document...). The program stops early in the setup > process (an error dialog box pops up *behind* DNS' flash screen) : the > error message refers to an "Access violation" error and points to > Dragon's own log (which reports a segment violation and barfs a somewhat > largish stack dump). > > Using DNS on a daily basis, I wish to revert to wine 0.9.4 or 0.9.3, but > I am unable to find a repository for the older Debian packages. Is there > a repository for these packages ? > > Sincerely yours, > > Emmanuel Charpentier

2 1

Re: OLEAUT32: Output a FIXME message only once.
by Cihan Altinay 06 Jan '06

06 Jan '06

Hi, Mike McCormack wrote: > > Unless somebody is planning to fix this soon, it would be nice to just > output it once to remind us that it needs to be fixed later. It's a > memory leak, so it's not worth frightening our users more than once over. > > Mike > > > ChangeLog: > Output a FIXME message only once. > > dlls/oleaut32/typelib.c | 7 ++++++- > 1 files changed, 6 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > a06a1b1d8dbb246eede84fd894e273641477d1fc > diff --git a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c > index 4ef590e..70c1d1f 100644 > --- a/dlls/oleaut32/typelib.c > +++ b/dlls/oleaut32/typelib.c > @@ -4287,7 +4287,12 @@ static ULONG WINAPI ITypeInfo_fnRelease( > it means that function is called by ITypeLib2_Release */ > ITypeLib2_Release((ITypeLib2*)This->pTypeLib); > } else { > - FIXME("destroy child objects\n"); > + static int once = 0; > + if (once) I think it should read if (!once) :-) > + { > + once = 1; > + FIXME("destroy child objects\n"); > + } > > TRACE("destroying ITypeInfo(%p)\n",This); > if (This->Name) Cihan

1 0

Re: commctl32 datetime usability fixes
by James Hawkins 06 Jan '06

06 Jan '06

On 1/4/06, Siim Karus <siim04(a)ut.ee> wrote: > Hi! > > I modified datetime control to work with some Visual C++ wizard > generated applications. Also some usability fixes were made (typable > time, updown control notifications processing, calendar popup without > dropdown button disabled, style information synchronisation improved). Please send one fix/modification per patch and one patch per email. -- James Hawkins

1 0

wcmd & start
by Stefan Leichter 06 Jan '06

06 Jan '06

Hello, i found a problem during running a batch file. The problem is the start command. Win9x has it as separate comand (as we currently have it in wine). The Nt based Windows Versions have it as builtin comand in cmd. Wcmd does not know the start command because the start command ist installed in windows/comand directory, but the directory ist not in the path known by wcmd. An easy fix might be to add the windows/comand directory to the path variable on startup of wcmd. Is the fine for everyone? If not please suggest a better solution. Bye Stefan

5 4

Re: [comctl32] Reduce memory usage of the syslink control (Take 5)
by Robert Shearman 05 Jan '06

05 Jan '06

Thomas Weidenmueller wrote: >Reduce memory usage of the syslink control and fix dependent code. > > > Alexandre has already said what he doesn't like about the patch, but I'll be a bit more specific. Put the below changes into a separate patch plus the moving around of the LIF_STATE case in SYSLINK_SetItem, because they are really separate changes. >@@ -878,7 +879,7 @@ > if((Current->Type == slLink) && (Current->u.Link.state & LIS_FOCUSED) && infoPtr->HasFocus) > { > COLORREF PrevColor; >- PrevColor = SetBkColor(hdc, OldBkColor); >+ PrevColor = SetTextColor(hdc, OldBkColor); > DrawFocusRect(hdc, &bl->rc); > SetBkColor(hdc, PrevColor); > } >@@ -972,8 +973,7 @@ > /* clear the document */ > SYSLINK_ClearDoc(infoPtr); > >- textlen = lstrlenW(Text); >- if(Text == NULL || textlen == 0) >+ if(Text == NULL || (textlen = lstrlenW(Text)) == 0) > { > return TRUE; > } >@@ -984,8 +984,9 @@ > /* Render text position and word wrapping in memory */ > HDC hdc = GetDC(infoPtr->Self); > SYSLINK_Render(infoPtr, hdc); >- SYSLINK_Draw(infoPtr, hdc); > ReleaseDC(infoPtr->Self, hdc); >+ >+ InvalidateRect(infoPtr->Self, NULL, TRUE); > } > > return TRUE; >@@ -1531,11 +1553,8 @@ > case WM_SIZE: > { > HDC hdc = GetDC(infoPtr->Self); >- if(hdc != NULL) >- { >- SYSLINK_Render(infoPtr, hdc); >- ReleaseDC(infoPtr->Self, hdc); >- } >+ SYSLINK_Render(infoPtr, hdc); >+ ReleaseDC(infoPtr->Self, hdc); > return 0; > } > > > -- Rob Shearman

1 0

Re: gdi32 test
by Dmitry Timoshkov 05 Jan '06

05 Jan '06

"Stefan Leichter" <Stefan.Leichter(a)camLine.com> wrote: > ChangeLog > --------------- > add a test for CreateDCW 1. there is no need to import CreateDCW dynamically, it always exists 2. dlls/user/tests/monitor.c,test_enumdisplaydevices() test already does this, so your test is redundant. -- Dmitry.

3 3

Question regarding the Wine Vs WineLib performance
by Ananth M 05 Jan '06

05 Jan '06

Hi All, This question is related to the performance of wine using wine and WineLib I have a win32 program that uses a dll. I am checking the timing to execute a function that is exported by the dll I wanted to execute this program in Linux (using wine and WineLib) and check the performance. When I executed the win32 program in Linux using wine <win32program> The execution time of the function exported by the dll is as same as in direct execution of the program in windows Then I converted the dll into .so and compiled and linked this .so with win32 program using WineLib and Wineg++ The timing that was taken to execute the function exported by the dll ( through .so ) is almost two times, compread with executing using wine. Does any one has any reference for further investigation on this problem or any information Thank you Ajay

4 3

PATCH: assembler _invoke
by Marcus Meissner 05 Jan '06

05 Jan '06

On Wed, Jan 04, 2006 at 09:14:18PM -0800, Dan Kegel wrote: > This would definitely be better handled in assembly... Here is the first try. It leaves the old version for non-intel and non-gcc compilers. Ciao, Marcus Index: typelib.c =================================================================== RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v retrieving revision 1.200 diff -u -r1.200 typelib.c --- typelib.c 3 Jan 2006 12:42:34 -0000 1.200 +++ typelib.c 5 Jan 2006 09:07:25 -0000 @@ -4843,7 +4843,33 @@ switch (callconv) { case CC_STDCALL: +#if defined(__i386__) && defined(__GNUC__) + __asm__( + /* store all stuff into registers now, since we modify the stack */ + " mov %1, %%ecx\n" + " mov %2, %%edx\n" + " mov %3, %%esi\n" + " test %%ecx, %%ecx\n" + " jz 1f\n" /* no args, nothing to push */ + /* + * Arguments are pushed from right to left. + * We use intel memory move operations. + */ + " std\n" /* direction: backward */ + "2: lodsl\n" /* moves *esi -> eax, esi-= 4 */ + " pushl %%eax\n" + " dec %%ecx\n" + " jnz 2b\n" + "1: cld\n" /* direction: forward (default) */ + " call *%%edx\n" + " mov %%eax, %0\n" + : "=g" (res) + : "g" (nrargs), "g" (func), "g" (args + (nrargs-1)) + : "memory", "cc", "ax", "si", "cx", "dx" + ); + break; +#else switch (nrargs) { case 0: res = func(); @@ -4905,6 +4931,7 @@ break; } break; +#endif default: FIXME("unsupported calling convention %d\n",callconv); res = -1;

1 0

New, flex-related warnings
by Gerald Pfeifer 05 Jan '06

05 Jan '06

Using flex 2.5.4 and GCC 3.4, I started getting the following new warnings for my Wine builds about two days ago (which I never got before): ./ppl.l:176:1: warning: "YY_NO_UNPUT" redefined ./ppl.l:129:1: warning: this is the location of the previous definition ./parser.l:57:1: warning: "YY_NO_UNPUT" redefined warning: this is the location of the previous definition ./parser.l:58:1: warning: "YY_NO_TOP_STATE" redefined ./parser.l:23:1: warning: this is the location of the previous definition ./parser.l:116:1: warning: "YY_NO_UNPUT" redefined ./parser.l:100:1: warning: this is the location of the previous definition ./parser.l:117:1: warning: "YY_NO_TOP_STATE" redefined ./parser.l:101:1: warning: this is the location of the previous definition ./debug.l:73:1: warning: "YY_NO_UNPUT" redefined ./debug.l:22:1: warning: this is the location of the previous definition ./macro.lex.l:42:1: warning: "YY_NO_UNPUT" redefined ./macro.lex.l:22:1: warning: this is the location of the previous definition I'm afraid, this is caused by the following patchset: date: 2006-01-03 12:43:14 +0000; author: julliard; state: Exp; lines: +4 -2 Alexandre Julliard <julliard(a)winehq.org> Added some flex options to avoid compiler warnings. Moved options from the Makefile into the source. Gerald

1 0

Licensing question
by Dominic Wise 05 Jan '06

05 Jan '06

I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? I am currently trying to demonstrate the benefits of Open Source technology to my employer (I have already replaced one proprietary third-party component in our application with a better Open Source implementation) and this could really help to move this process along. Longer-term, I want to try and get the application running on Wine, but that's another story. Regards, Dominic

5 6

Re: PATCH: winspool.spec adjustments
by Detlef Riekenberg 04 Jan '06

04 Jan '06

Am Mittwoch, den 04.01.2006, 18:40 +0100 schrieb Marcus Meissner: -noname is wrong here: > +202 stub -noname SetDefaultPrinterA@4 > +204 stub -noname SetDefaultPrinterW@4 winspool.drv from w2k export this Functions by name. (The Ordinal-Numbers are correct) -- By By ... ... Detlef

1 0

Re: RpcRT4: Implement NdrClientCall2 and NdrServerCall2
by Roderick Colenbrander 04 Jan '06

04 Jan '06

+ * Copyright 2003-5 Robert Shearman (for CodeWeavers) * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public It is 2006 now ;) Roderick

1 0

Re: CRYPTUI: Add an empty cryptui implementation.
by Juan Lang 04 Jan '06

04 Jan '06

> May not want this empty dll in WineHQ, but it makes SmartFTP > start up I don't see any reason not to include it. It is always available, as far as I know, when crypt32.dll is available. Programs that need a real one probably also need native crypt32.dll for now, so people already have to mess with their dll overrides for apps that might get broken by its presence. --Juan __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

1 0

Re: PATCH: winspool ordinal export
by Robert Shearman 04 Jan '06

04 Jan '06

Hi Marcus, Thanks for submitting a patch for this. I also have an application that depends on one of the exports to have a specific ordinal (203 - GetDefaultPrinterW). Marcus Meissner wrote: >-100 stub @ >+100 stub EnumPrinterPropertySheets@16 > > This should be --noname. >+# 101 ClusterSplOpen@20 >+# 102 ClusterSplClose@4 >+# 103 ClusterSplIsAlive@4 >+201 stdcall GetDefaultPrinterA(ptr ptr) >+# 202 _SetDefaultPrinterA@4 >+203 stdcall GetDefaultPrinterW(ptr ptr) >+# 204 _SetDefaultPrinterW@4 >+# 205 _SplReadPrinter@12 >+# 206 _AddPerMachineConnectionA@16 >+# 207 _AddPerMachineConnectionW@16 >+# 208 _DeletePerMachineConnectionA@8 >+# 209 _DeletePerMachineConnectionW@8 >+# 210 _EnumPerMachineConnectionsA@20 >+# 211 _EnumPerMachineConnectionsW@20 >+# 212 _LoadPrinterDriver@4 >+# 213 _RefCntLoadDriver@16 >+# 214 _RefCntUnloadDriver@8 >+# 215 _ForceUnloadDriver@4 >+# 216 _PublishPrinterA@24 >+# 217 _PublishPrinterW@24 >+# 218 _CallCommonPropertySheetUI@16 >+# 219 _PrintUIQueueCreate@16 >+# 220 _PrintUIPrinterPropPages@16 >+# 221 _PrintUIDocumentDefaults@16 >+# 222 _SendRecvBidiData@16 >+# 223 _RouterFreeBidiResponseContainer@4 >+# 224 _ExternalConnectToLd64In32Server@4 >+# 226 _PrintUIWebPnpEntry@4 >+# 227 _PrintUIWebPnpPostEntry@16 >+# 228 _PrintUICreateInstance@8 >+# 229 _PrintUIDocumentPropertiesWrap@28 >+# 230 _PrintUIPrinterSetup@24 >+# 231 _PrintUIServerPropPages@16 >+# 232 _AddDriverCatalog@16 >+ > > We should add this ordinals, not just comment them out. Why? Because they are exported by ordinal only and so if an application (or more likely a Microsoft DLL) tries to use one of them it will end up with the wrong function, rather than just failing to import it and most likely will result in stack corruption. All of these should also be exported with --noname as they are ordinal-only exports. > @ stub ADVANCEDSETUPDIALOG > @ stdcall AbortPrinter(long) > @ stdcall AddFormA(long long ptr) >@@ -89,8 +124,6 @@ > @ stdcall FindFirstPrinterChangeNotification(long long long ptr) > @ stdcall FindNextPrinterChangeNotification(long ptr ptr ptr) > @ stdcall FreePrinterNotifyInfo(ptr) >-@ stdcall GetDefaultPrinterA(ptr ptr) >-@ stdcall GetDefaultPrinterW(ptr ptr) > @ stdcall GetFormA(long str long ptr long ptr) > @ stdcall GetFormW(long wstr long ptr long ptr) > @ stdcall GetJobA(long long long ptr long ptr) > -- Rob Shearman

1 0

winecfg: Problems with audio configuration
by Vitaliy Margolen 04 Jan '06

04 Jan '06

I have noticed significant increase in crashes and lockups in winecfg's audio page. Could we do something about that before the next release? This makes it hard for any first timer to configure wine. Especially knowing that most people will have to change hardware acceleration to "emulation" and they will not be able to do so. -- Best regards, Vitaliy

11 22

re: Licensing question
by Dan Kegel 04 Jan '06

04 Jan '06

dominic.wise(a)ukonline.co.uk wrote: > The application my employer develops is a financial > application designed to work on Win 2K and Win XP, but we > have a need for a Win32 function that is only supported in > XP (TzSpecificLocalTimeToSystemTime). We could write an > implementation of this function ourselves for Win 2K but > I have noticed that there is a full implementation in Wine. > > Is it permissible to use the source for this function in > our application? That function, along with all of Wine, is LGPL'd. Thus to use it in a proprietary app, you just have to put it in its own DLL. > If so, what provisions do we need to make > with regard to recognition of Wine and supply of source > code to our customers ? You need to provide the source code for the LGPL'd DLL you ship. Have a look at the terms of the LGPL for details: http://www.gnu.org/copyleft/lesser.txt Good luck with your project! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

safedisc
by Ivan Leo Puoti 04 Jan '06

04 Jan '06

Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I believe what we have is more or less ready for CVS. However Vitaly told me Alexandre didn't like the object manager Vitaly wrote, mostly he didn't like permanent objects, that drivers depend on. I haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can get Vitaly's OM into wineserver (I mean my original implementation that uses pointers as handles also works, but things look better with a real OM). So let's try and trigger some community discussion, we are talking about the guts of wine after all. Vitaly, what's the OM status currently? Alexandre, what didn't you like about it? Ivan.

4 3

Re: PATCH: winspool ordinal export
by Dmitry Timoshkov 04 Jan '06

04 Jan '06

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: > SecureCRT from bug 4225 imports GetDefaultPrinterA() by > using the ordinal 201. > > Not sure if this fix is correct or if this is even the > correct approach. But it helps SecureCRT. The other > winspool functions are imported by name. This time I ran 'dumpbin /exports' on winspool.lib provided with PSDK and got interesting result: only some APIs are exported by ordinal, here they are sorted by ordinal, I skipped all APIs without ordinals: 100 _EnumPrinterPropertySheets@16 101 _ClusterSplOpen@20 102 _ClusterSplClose@4 103 _ClusterSplIsAlive@4 201 _GetDefaultPrinterA@8 202 _SetDefaultPrinterA@4 203 _GetDefaultPrinterW@8 204 _SetDefaultPrinterW@4 205 _SplReadPrinter@12 206 _AddPerMachineConnectionA@16 207 _AddPerMachineConnectionW@16 208 _DeletePerMachineConnectionA@8 209 _DeletePerMachineConnectionW@8 210 _EnumPerMachineConnectionsA@20 211 _EnumPerMachineConnectionsW@20 212 _LoadPrinterDriver@4 213 _RefCntLoadDriver@16 214 _RefCntUnloadDriver@8 215 _ForceUnloadDriver@4 216 _PublishPrinterA@24 217 _PublishPrinterW@24 218 _CallCommonPropertySheetUI@16 219 _PrintUIQueueCreate@16 220 _PrintUIPrinterPropPages@16 221 _PrintUIDocumentDefaults@16 222 _SendRecvBidiData@16 223 _RouterFreeBidiResponseContainer@4 224 _ExternalConnectToLd64In32Server@4 226 _PrintUIWebPnpEntry@4 227 _PrintUIWebPnpPostEntry@16 228 _PrintUICreateInstance@8 229 _PrintUIDocumentPropertiesWrap@28 230 _PrintUIPrinterSetup@24 231 _PrintUIServerPropPages@16 232 _AddDriverCatalog@16 -- Dmitry.

1 0

CVS build failure
by Robert Reif 04 Jan '06

04 Jan '06

I am getting the following build error on RH9 with todays CVS: make[2]: Entering directory `/home/wine/wine/tools/widl' gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o client.o client.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o hash.o hash.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o header.o header.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o proxy.o proxy.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o server.o server.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o typegen.o typegen.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o typelib.o typelib.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o utils.o utils.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o widl.o widl.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o write_msft.o write_msft.c bison -d -t ./parser.y -o parser.tab.c ./parser.y contains 12 shift/reduce conflicts. gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o parser.tab.o parser.tab.c flex ./parser.l gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o lex.yy.o lex.yy.c ./parser.l:57:1: warning: "YY_NO_UNPUT" redefined ./parser.l:22:1: warning: this is the location of the previous definition ./parser.l:58:1: warning: "YY_NO_TOP_STATE" redefined ./parser.l:23:1: warning: this is the location of the previous definition gcc -g -O2 -o widl client.o hash.o header.o proxy.o server.o typegen.o typelib.o utils.o widl.o write_msft.o parser.tab.o lex.yy.o -L../../libs -lwpp -lwine_port -lfl widl.o(.text+0x2af): In function `main': /home/wine/wine/tools/widl/widl.c:228: undefined reference to `yy_flex_debug' ../../libs/libwpp.a(preproc.o)(.text+0x8b4): In function `pp_push_if': /home/wine/wine/libs/wpp/preproc.c:505: undefined reference to `pp_flex_debug' ../../libs/libwpp.a(preproc.o)(.text+0x976): In function `pp_pop_if': /home/wine/wine/libs/wpp/preproc.c:542: undefined reference to `pp_flex_debug' ../../libs/libwpp.a(wpp.o)(.text+0x223): In function `wpp_set_debug': /home/wine/wine/libs/wpp/wpp.c:128: undefined reference to `pp_flex_debug' ../../libs/libwpp.a(lex.yy.o)(.text+0x2881): In function `expand_special': /home/wine/wine/libs/wpp/./ppl.l:879: undefined reference to `pp_flex_debug' ../../libs/libwpp.a(lex.yy.o)(.text+0x296e): In function `expand_define': /home/wine/wine/libs/wpp/./ppl.l:898: undefined reference to `pp_flex_debug' ../../libs/libwpp.a(lex.yy.o)(.text+0x2b7b):/home/wine/wine/libs/wpp/./ppl.l:1018: more undefined references to `pp_flex_debug' follow collect2: ld returned 1 exit status make[2]: *** [widl] Error 1 make[2]: Leaving directory `/home/wine/wine/tools/widl' make[1]: *** [widl] Error 2

3 2

Unloading implicitly loaded DLLs
by Michael Ost 04 Jan '06

04 Jan '06

I am looking for some expert advice in how to handle unloading "implicitly loaded DLLs". I have found two issues. (1) The first is a crash that happens in dlls/ntdll/loader.c MODULE_FlushModrefs. wine_unload_dll() is called for such a DLL, but SectionHandle is NULL so the call crashes. My solution was to turn off the LDR_WINE_INTERNAL flag in attach_implicitly_loaded_dlls() but I am not real clear what that flag is or whether that approach is good. An alternative is to add a check for a null SectionHeader before calling wine_unload_dll(). (2) Second is that these DLLs are DLL_PROCESS_DETACHED in process_detach() every time _any_ DLL is unloaded. This happens because the LoadCount is 0. I set it to -1 in attach_implicitly_loaded_dlls() which does the trick. But again I don't know what the heck I am messing with. Is that OK? Attached is a diff of the two changes. I'm not looking for points for style. But just a check on the approach for now. Thanks ... mo

2 1

re: Wine on AIX 5.2 (PowerPC)
by Dan Kegel 04 Jan '06

04 Jan '06

ghart(a)siemens-emis.com wrote: > My goal is to port some Windows apps to AIX, so I decided to take as > much Wine (winelib) as I could to help me. Initially I thought only > a small portion would be suitable, but after a few weeks of work I have > all the dlls/libs compiled (as simple AIX .so's) Cool! > My first question is: has anyone tried this before? I don't know about AIX; somebody from CA asked about it last year. But there are a few folks using Winelib with alternate OS's and CPUs. Perhaps some of them would be able to help you past some of the rough spots. A few links from a quick google search: Robert Lunnon got a Solaris/X86 port working; see http://members.optusnet.com.au/bobl/ http://www.blastwave.org/wine/ http://wiki.jswindle.com/index.php/Installing_Wine#Solaris And various people are using Winelib on Solaris/Sparc; see http://www.winehq.org/?issue=302#Building%20Wine%20on%20Sparcs And then there are the folks building Wine for Darwin. http://darwine.opendarwin.org Good luck, and do keep us posted! I bet you're not the only one who wants this. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

Re: ntdll: Implement few Dbg* functions.
by Eric Pouech 03 Jan '06

03 Jan '06

Vitaliy Margolen wrote: > ChangeLog: > ntdll: Implement few Dbg* functions. > kernel32: Use new Dbg* functions instead of server calls. > + status = DbgUiDebugActiveProcess( hProc ); > + status = DbgUiStopDebugging( hProc ); > - if (self) DbgBreakPoint(); I wonder if we shouldn't use NtDbgActiveProcess, NtRemoveProcessDebug instead. A+ -- Eric Pouech

2 6

Re: MSACM: initialize some ACMSTREAMHEADER fields for the sake of native codecs
by Eric Pouech 03 Jan '06

03 Jan '06

Alex Villacís Lasso wrote: > The ACMAPP sample application from MSDN reveals this annoying bug in > playback: with a native ACM codec (such as the Ogg Vorbis one bundled > with some Japanese RPGs), builtin msacm will successfully tell the codec > to decode the first two frames of compressed audio, and then the sound > will loop on these two frames. What is really happening is that winmm is > using double-buffering, and reusing the ACMSTREAMHEADER structures for > playback, and acmStreamConvert simply passes the structures into the > codec, without clearing cb[Src|Dst]LengthUsed (here is the bug) which > was set in the previous call to acmStreamConvert on that > ACMSTREAMHEADER. The native codec *expects* these fields to be set to 0, > and refuses to decode otherwise. well, you should check who is supposed to clear those flags between msacm or winmm (I suppose wavemap). A+ -- Eric Pouech

2 2

MIDI to MP3 Converter
by Andrew Neil Ramage 03 Jan '06

03 Jan '06

Trying to run this program under Wine, I get the following results. The initial screen appears asking for the name of the MIDI file, but when I try to enter any text I get a crash. A listing of the output follows. andrew@apollo:~/.wine/drive_c/Program Files/MIDI to MP3 Converter> wine mid2mp3.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:OleLoadPictureEx (0x4213f904,11182,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bfb00), partially implemented. fixme:mci:mciSendStringW 'new': NIY as device name fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:ole:OLEPictureImpl_SaveAsFile (0x403d1dd8)->(0x404022b0, 0, (nil)), hacked stub. X Error of failed request: RenderBadPicture (invalid Picture parameter) Major opcode of failed request: 153 (RENDER) Minor opcode of failed request: 7 (RenderFreePicture) Picture id in failed request: 0x3a00695 Serial number of failed request: 9517 Current serial number in output stream: 10170 andrew@apollo:~/.wine/drive_c/Program Files/MIDI to MP3 Converter> cat ../../system.ini cat: ../../system.ini: No such file or directory andrew@apollo:~/.wine/drive_c/Program Files/MIDI to MP3 Converter> cat ../../windows/system.ini [mci] MPEGVideo=mciqtz.drv MPEGVideo2=mciqtz.drv avivideo=mciavi.drv cdaudio=mcicda.drv sequencer=mciseq.drv vcr=mcivisca.drv ; videodisc=mcipionr.drv waveaudio=mciwave.drv [drivers32] MSACM.imaadpcm=imaadp32.acm MSACM.msadpcm=msadp32.acm MSACM.msg711=msg711.acm MSACM.winemp3=winemp3.acm VIDC.MRLE=msrle32.dll VIDC.MSVC=msvidc32.dll VIDC.CVID=iccvid.dll ; VIDC.IV50=ir50_32.dll ; VIDC.IV31=ir32_32.dll ; VIDC.IV32=ir32_32.dll andrew@apollo:~/.wine/drive_c/Program Files/MIDI to MP3 Converter> wine mid2mp3.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:OleLoadPictureEx (0x4213f904,11182,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x406bfb00), partially implemented. fixme:mci:mciSendStringW 'new': NIY as device name fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"CAPTURE". If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini fixme:ole:OLEPictureImpl_SaveAsFile (0x403d1dd8)->(0x404022b0, 0, (nil)), hacked stub. X Error of failed request: RenderBadPicture (invalid Picture parameter) Major opcode of failed request: 153 (RENDER) Minor opcode of failed request: 7 (RenderFreePicture) Picture id in failed request: 0x3a00645 Serial number of failed request: 9157 Current serial number in output stream: 9834 andrew@apollo:~/.wine/drive_c/Program Files/MIDI to MP3 Converter> : -- Andrew "Someone set a bad example makes surrender seem alright; The act of a noble warrior who's lost the will to fight And now you're trembling on a rocky ledge Staring out into a heartless sea Facing life on a razor's edge Nothing's what you thought it would be." ----------- Rush, The Pass (Presto, 1989)

3 2

Re: Fix some type definitions for the WORDS_BIGENDIAN case
by Alexandre Julliard 03 Jan '06

03 Jan '06

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > diff -up cvs/hq/wine/include/winnt.h wine/include/winnt.h > --- cvs/hq/wine/include/winnt.h 2005-11-30 23:19:48.000000000 +0800 > +++ wine/include/winnt.h 2006-01-02 15:08:41.000000000 +0800 > @@ -1743,12 +1743,21 @@ typedef struct _IMAGE_DOS_HEADER { > } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER; > #include <poppack.h> > > +#ifdef WORDS_BIGENDIAN > +#define IMAGE_DOS_SIGNATURE 0x4D5A /* MZ */ > +#define IMAGE_OS2_SIGNATURE 0x4E45 /* NE */ > +#define IMAGE_OS2_SIGNATURE_LE 0x4C45 /* LE */ > +#define IMAGE_OS2_SIGNATURE_LX 0x4C58 /* LX */ > +#define IMAGE_VXD_SIGNATURE 0x4C45 /* LE */ > +#define IMAGE_NT_SIGNATURE 0x50450000 /* PE00 */ > +#else > #define IMAGE_DOS_SIGNATURE 0x5A4D /* MZ */ > #define IMAGE_OS2_SIGNATURE 0x454E /* NE */ > #define IMAGE_OS2_SIGNATURE_LE 0x454C /* LE */ > #define IMAGE_OS2_SIGNATURE_LX 0x584C /* LX */ > #define IMAGE_VXD_SIGNATURE 0x454C /* LE */ > #define IMAGE_NT_SIGNATURE 0x00004550 /* PE00 */ > +#endif I'm not sure what you are trying to achieve here. If you want to load little-endian files on big-endian machines, you need to swap everything; swapping only the signature is not going to do any good. -- Alexandre Julliard julliard(a)winehq.org

2 4

run jboss with a mde file as source
by Curro Amores 03 Jan '06

03 Jan '06

hi: i want to run jboss in linux and connect to an Ms Access odbc source. I think it doesnt exist odbc driver for Access in Linux. I Have read something about ODBC-ODBC but i think it is for accessing a mde file in a windows machine from linux. I have created the bridge with ODBC in wine (using the control pane with winetools) Then i have tried to run jboss windows version (run.bat) with wcmd but i got a message that run.jar file cant not be found. Do i have to install java windows version with wine? I have tried as well but the installation crashes Any idea? thanks

2 1

Re: opengl: Add support for rendering on bitmaps
by Tomas Carnecky 03 Jan '06

03 Jan '06

Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Add support for rendering on bitmaps This patch breaks World of Warcraft, reverting this patch makes WoW work again. This is the error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 142 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 410 Current serial number in output stream: 411 tom

3 4

Re: [comctl32] Reduce memory usage of the syslink control (Take 4)
by Alexandre Julliard 03 Jan '06

03 Jan '06

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > @@ -1062,35 +1063,41 @@ > > if(Item->mask & LIF_ITEMID) > { > - if(!di->u.Link.szID) > + if(di->u.Link.szID) > { > - di->u.Link.szID = Alloc((MAX_LINKID_TEXT + 1) * sizeof(WCHAR)); > - if(!Item->szID) > - { > - ERR("Unable to allocate memory for link id\n"); > - Ret = FALSE; > - } > + Free(di->u.Link.szID); > } > + > + nc = min(lstrlenW(Item->szID), MAX_LINKID_TEXT - 1); > + di->u.Link.szID = Alloc((nc + 1) * sizeof(WCHAR)); > if(di->u.Link.szID) > { > - lstrcpynW(di->u.Link.szID, Item->szID, MAX_LINKID_TEXT + 1); > + lstrcpynW(di->u.Link.szID, Item->szID, nc + 1); > + } > + else > + { > + ERR("Unable to allocate memory for link id\n"); > + Ret = FALSE; > } > } You should probably make sure that the new text has been allocated properly before freeing the old one, so that allocation errors don't cause the current contents to be lost. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: RESEND: [comctl32] Reduce memory usage of the syslink control
by Alexandre Julliard 03 Jan '06

03 Jan '06

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > Reduce memory usage of the syslink control. > > Please let me know if there's something wrong with this patch. There are many unrelated changes in there. Please send separate changes as separate patches. -- Alexandre Julliard julliard(a)winehq.org

1 0

Some patch statistics
by Hans Leidekker 03 Jan '06

03 Jan '06

I was curious how we did last year so I dug up some numbers with the help of git. I counted patches applied to the tree starting from 1999: year # patches 1999 2656 2000 2722 2001 1885 2002 3094 2003 3283 2004 3851 2005 6037 Total: 23528 This is almost too good to be true isn't it? I worried for a while that these figures might be influenced by the switch from cvs to git, e.g. that cvs history somehow shows up compressed in git. On second look though it really seems that the past year has seen an impressive increase in productivity, compared to the previous years. -Hans

2 1

RFC/PATCH: avoid metafilevirus problems
by Marcus Meissner 03 Jan '06

03 Jan '06

Hi, requesting comments... This patch reduces the attack vector on metafiles. I originally wanted to filter only SETABORTPROC, but there are a lot of things that might be used to inject code. Comments? Ciao, Marcus Changelog: Only allow whitelisted escape codes when playing metafiles. Index: dlls/gdi/metafile.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/metafile.c,v retrieving revision 1.10 diff -u -r1.10 metafile.c --- dlls/gdi/metafile.c 5 Nov 2005 10:45:02 -0000 1.10 +++ dlls/gdi/metafile.c 2 Jan 2006 20:52:42 -0000 @@ -1121,10 +1121,57 @@ GDIRealizePalette(hdc); break; - case META_ESCAPE: + case META_ESCAPE: { + BOOL passdown = FALSE; + + switch (mr->rdParm[0]) { + case SETABORTPROC: + FIXME("NOTE: Suppressing SETABORTPROC in metafile, possible exploit.\n"); + break; + case STARTDOC: + case ABORTDOC: + case ENDDOC: + case NEWFRAME: + case NEXTBAND: + case SETCOPYCOUNT: + case SETCOLORTABLE: + case FLUSHOUTPUT: + case DRAFTMODE: + case SELECTPAPERSOURCE: + case SETLINECAP: + case SETLINEJOIN: + case SETMITERLIMIT: + case DRAWPATTERNRECT: + case ENABLEDUPLEX: + case EPSPRINTING: + case SETDIBSCALING: + case EXTTEXTOUT: + case ENABLEPAIRKERNING: + case SETCHARSET: + case SETKERNTRACK: + case SETALLJUSTVALUES: + case STRETCHBLT: + case BEGIN_PATH: + case CLIP_TO_PATH: + case END_PATH: + case SET_ARC_DIRECTION: + case SET_BACKGROUND_COLOR: + case SET_POLY_MODE: + case SET_SCREEN_ANGLE: + case SET_SPREAD: + case TRANSFORM_CTM: + case SET_CLIP_BOX: + case SET_BOUNDS: + case SET_MIRROR_MODE: + passdown = TRUE; + break; + default: + FIXME("Ignoring strange Escape code %d in Metafile.\n"); + break; + } Escape(hdc, mr->rdParm[0], mr->rdParm[1], (LPCSTR)&mr->rdParm[2], NULL); break; - + } case META_EXTTEXTOUT: MF_Play_MetaExtTextOut( hdc, mr ); break;

3 2

Re: OLEAUT32: Revert back to an older more informative error message.
by Marcus Meissner 03 Jan '06

03 Jan '06

On Tue, Jan 03, 2006 at 07:00:15PM +0900, Mike McCormack wrote: > > Many installers cause Wine's oleaut32 to output alot of FIXME messages > like this: > > fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion > from 0x4003 -> 0xb) 0000ffff > > This message is somewhat frustrating, as although it warns of a > potential problem, it provides no insight into the solution. > > I found the patch that introduced the problem (using git): > > git-whatchanged -p -C -S'Should not use VariantChangeType' > commit hash -> 49eaa0db2b3f7443ead40ef4a5d5b3d650c11384 > > It removed an (IMO) slightly more useful message: > > "argument was coerced in-place (0x%x -> 0x%x); source data has been > modified!!!\n" > > Can anybody help suggest the real way to fix the problem? Is it that we > have to make a copy of the args array before modifying it? Maybe we can > put a comment in the code about how to fix it, some somebody looking at > it in the future will know how to solve it right? I was not fully sure what problems might arise out of just copying the variant as I wrote this code. Its a pretty messy approach. It should work fine when the variant is self contained at least. I think Rob wants to get rid of this function anyway. Ciao, Marcus

1 0

Re: OLE32: Allow _invoke to handle up to 17 parameters.
by Robert Shearman 03 Jan '06

03 Jan '06

Mike McCormack wrote: > > This looks like it might be better handled in assembly... I agree. We can let these patches go in until it is written in assembly though. -- Rob Shearman

1 0

Re: OLEAUT32: Revert back to an older more informative error message.
by Robert Shearman 03 Jan '06

03 Jan '06

Mike McCormack wrote: > Many installers cause Wine's oleaut32 to output alot of FIXME messages > like this: > > fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion > from 0x4003 -> 0xb) 0000ffff > ... > Can anybody help suggest the real way to fix the problem? Is it that > we have to make a copy of the args array before modifying it? Maybe > we can put a comment in the code about how to fix it, some somebody > looking at it in the future will know how to solve it right? Yes. I have a patch that fixes this and several other problems with the function and I've been sending patches in the last week preparing for this. -- Rob Shearman

1 0

issues compiling ReactOS newdev on wine
by Damjan Jovanovic 03 Jan '06

03 Jan '06

I tried to get the ReactOS NEWDEV.DLL to compile on wine, and there were many problems. Firstly, why can't winelibs include <windows.h> and <tchar.h>? Are TCHARs even usable in winelibs? Secondly, what the whole story with WCHARs? Why do L"Unicode string" type strings work in wine apps but not in winelibs? And NEWDEV.DLL needs GWL_USERDATA, DWL_MSGRESULT and PSH_WIZARD97, all of which are within "#ifndef __WINESRC__" sections. Does wine assume DLLs never do user-interface stuff? __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

3 2

help with bug
by Curro Amores 03 Jan '06

03 Jan '06

hi everbody, i have posted my bug in bugzilla. I know that the process is a bit slow but i would like somebody help me. There you have the links for downloading the standalone application and the process to get the bug. If you have any doubt you can email me. Thanks all Happy new Year! BUG IS 4126

1 0

Success running VistaTask!
by Dan Kegel 03 Jan '06

03 Jan '06

The fourth "automate other windows apps" app I tried, VistaTask, passed the "can control notepad" test with flying colors! A free trial is available at http://www.vista-software.com/ I don't know how close that tool is to being useful for software testing -- it's not specifically aimed at it -- but it's nice to see at least one such app actually working on Wine. Again, kudos to the Wine developers for getting Wine to this point! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

Error running app delphi based.
by Fernando - SuporteInfo 02 Jan '06

02 Jan '06

Hi, I'm trying run an application developed in delphi and receive the follow errors: err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be called for simple PIDL's only! err:syslevel:_CheckNotSysLevel Holding lock 0x7fa4dba0 level 2 wine: Unhandled exception 0x80000003 at address 0x0000:0x7fc5fd60 (thread 0009), starting debugger... WineDbg starting on pid 0x8 In 32 bit mode. 0x00000000: addb %al,0x0(%eax) Modules: Module Address Debug info Name (87 modules) PE 0x00400000-00f3e000 Deferred at PE 0x10000000-10018000 Deferred hhctrlui PE 0x1f430000-1f4a7000 Deferred msado15 PE 0x1f660000-1f67f000 Deferred msdart PE 0x5d300000-5d37f000 Deferred hhctrl PE 0x5f300000-5f329000 Deferred olepro32 PE 0x65340000-653d2000 Deferred oleaut32 PE 0x65f00000-65fc2000 Deferred ole32 PE 0x70100000-70153000 Deferred rpcrt4 PE 0x70bd0000-70c35000 Deferred shlwapi PE 0x78000000-78044000 Deferred msvcrt ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ddcc000-7dde0000 Deferred msimg32<elf> \-PE 0x7ddd0000-7dde0000 \ msimg32 ELF 0x7e47b000-7e490000 Deferred midimap<elf> \-PE 0x7e480000-7e490000 \ midimap ELF 0x7e5b0000-7e5d2000 Deferred msacm32<elf> \-PE 0x7e5c0000-7e5d2000 \ msacm32 ELF 0x7e5d2000-7e5e9000 Deferred msacm<elf> \-PE 0x7e5e0000-7e5e9000 \ msacm ELF 0x7e5e9000-7e630000 Deferred wineoss<elf> \-PE 0x7e600000-7e630000 \ wineoss ELF 0x7ec4f000-7ec80000 Deferred uxtheme<elf> \-PE 0x7ec60000-7ec80000 \ uxtheme ELF 0x7f1ef000-7f1f7000 Deferred libxrender.so.1 ELF 0x7f20a000-7f226000 Deferred imm32<elf> \-PE 0x7f210000-7f226000 \ imm32 ELF 0x7f226000-7f243000 Deferred ximcp.so.2 ELF 0x7f243000-7f246000 Deferred xlcdef.so.2 ELF 0x7f246000-7f2aa000 Deferred libgl.so.1 ELF 0x7f2bd000-7f388000 Deferred libx11.so.6 ELF 0x7f388000-7f39f000 Deferred libice.so.6 ELF 0x7f39f000-7f423000 Deferred winex11<elf> \-PE 0x7f3b0000-7f423000 \ winex11 ELF 0x7f423000-7f443000 Deferred libexpat.so.1 ELF 0x7f443000-7f472000 Deferred libfontconfig.so.1 ELF 0x7f477000-7f485000 Deferred libxext.so.6 ELF 0x7f485000-7f499000 Deferred libz.so.1 ELF 0x7f499000-7f506000 Deferred libfreetype.so.6 ELF 0x7f519000-7f537000 Deferred iphlpapi<elf> \-PE 0x7f520000-7f537000 \ iphlpapi ELF 0x7f537000-7f561000 Deferred ws2_32<elf> \-PE 0x7f540000-7f561000 \ ws2_32 ELF 0x7f561000-7f57b000 Deferred wsock32<elf> \-PE 0x7f570000-7f57b000 \ wsock32 ELF 0x7f57b000-7f5fc000 Deferred winmm<elf> \-PE 0x7f590000-7f5fc000 \ winmm ELF 0x7f5fc000-7f696000 Deferred comdlg32<elf> \-PE 0x7f610000-7f696000 \ comdlg32 ELF 0x7f696000-7f763000 Deferred shell32<elf> \-PE 0x7f6b0000-7f763000 \ shell32 ELF 0x7f763000-7f78e000 Deferred winspool<elf> \-PE 0x7f770000-7f78e000 \ winspool ELF 0x7f78e000-7f843000 Deferred comctl32<elf> \-PE 0x7f7a0000-7f843000 \ comctl32 ELF 0x7f843000-7f857000 Deferred lz32<elf> \-PE 0x7f850000-7f857000 \ lz32 ELF 0x7f857000-7f870000 Deferred version<elf> \-PE 0x7f860000-7f870000 \ version ELF 0x7f870000-7f88d000 Deferred mpr<elf> \-PE 0x7f880000-7f88d000 \ mpr ELF 0x7f88d000-7f8cb000 Deferred advapi32<elf> \-PE 0x7f8a0000-7f8cb000 \ advapi32 ELF 0x7f8cb000-7f958000 Deferred gdi32<elf> \-PE 0x7f8e0000-7f958000 \ gdi32 ELF 0x7f958000-7fa80000 Deferred user32<elf> \-PE 0x7f970000-7fa80000 \ user32 ELF 0x7fbd8000-7fce0000 Deferred kernel32<elf> \-PE 0x7fbf0000-7fce0000 \ kernel32 ELF 0x7fdf2000-7fdfb000 Deferred libxcursor.so.1 ELF 0x7fdfb000-7fe00000 Deferred libxxf86vm.so.1 ELF 0x7fe00000-7fe0c000 Deferred libnss_files.so.2 ELF 0x7fe0c000-7fe16000 Deferred libnss_nis.so.2 ELF 0x7fe16000-7fe2c000 Deferred libnsl.so.1 ELF 0x7fe2c000-7fe35000 Deferred libnss_compat.so.2 ELF 0x7fe37000-7fe40000 Deferred libsm.so.6 ELF 0x7fe42000-7fe48000 Deferred libxxf86dga.so.1 ELF 0x7fe4b000-7fe70000 Deferred libm.so.6 ELF 0x7fe70000-7ff67000 Deferred libwine_unicode.so.1 ELF 0x7ff67000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff80000-7ffe0000 \ ntdll ELF 0xb7db3000-b7db7000 Deferred libdl.so.2 ELF 0xb7db7000-b7eee000 Deferred libc.so.6 ELF 0xb7eee000-b7f00000 Deferred libpthread.so.0 ELF 0xb7f00000-b7f1a000 Deferred libwine.so.1 ELF 0xb7f1a000-b7f1d000 Deferred iso8859-1.so ELF 0xb7f2e000-b7f45000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\callisto\at.exe 0000000a 0 00000009 0 <== WineDbg terminated on pid 0x8 Excuse my english. []'s Fernando.

1 0

What is the proper value for ACM_DRIVERADDF_NAME?
by Alex Villacís Lasso 02 Jan '06

02 Jan '06

I am working on a set of patches for msacm, and I want to add support for ACM_DRIVERADDF_NAME. The problem is that Wine does not have a definition for this value, which is supposed to be used in acmDriverAdd[AW]. It does not appear in any header of MSVC either. I searched MSDN and Google, and it does not appear either. MSDN mentions its use, but does not mention its specific value. Has anybody seen the value for this definition, and if so, can you please forward it to me? Thanks in advance. BTW, what happened to the two MSACM patches sent in December 28? Alex Villacís Lasso

2 2

Re: There is no point to specify both MEM_RESERVE and MEM_COMMIT for VirtualAlloc
by Vitaliy Margolen 02 Jan '06

02 Jan '06

Monday, January 2, 2006, 1:23:22 AM, Dmitry Timoshkov wrote: > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > There is no point to specify both MEM_RESERVE and MEM_COMMIT for > VirtualAlloc. According to MSDN: "To reserve and commit pages in one step, call VirtualAlloc with MEM_COMMIT | MEM_RESERVED. The function fails if you attempt to commit a page that has not been reserved. The resulting error code is ERROR_INVALID_ADDRESS." Why do you want to do something that _should_ fail? Vitaliy Margolen

2 1

Self-extracting zips do not extract themselves
by Ivan Gyurdiev 02 Jan '06

02 Jan '06

> err:virtual:map_image Image was mapped at 0x49910000: standard load address for a Win32 program (0x00400000) not available > err:virtual:map_image Do you have exec-shield or prelink active? > wine: could not load L"H:\\nfsmw\\nfsmwdemo.exe" as Win32 binary Yes I do, is that bad? Should I file a bugzilla (or do something else to help resolve this issue)?

1 0

D3DX9 SDK releases, DLL support (CIV4)
by Andrei Barbu 02 Jan '06

02 Jan '06

Hi, I've been playing with getting CIV4 to run on wine. http://appdb.winehq.org/appview.php?versionId=3632&iTestingId=125 I'm left with just one issue. D3DX9_26.DLL is missing. This is a D3D9 SDK release (they put one out every month or so from what I've seen, with a new DLL that has the number incremented). It's mostly like the original with some minor changes. How would I support this in wine? I don't know the wine build system enough to extend it to do this. Is there a nice way to generate these DLLs and to include the d3dx9 dll so I just have to add in/fix missing calls? This may not be an issue now, but as more and more games get released more will depend on these dlls. Thanks, Andrei

5 5

Running GUI test automation tools with Wine?
by Dan Kegel 02 Jan '06

02 Jan '06

Do any Windows GUI test automation tools run under Wine yet? I've tried two from the list at http://tejasconsulting.com/open-testware/feature/gui-test-driver-survey.html so far, but they both had issues: http://bugs.winehq.org/show_bug.cgi?id=4209 (tester 3 can't record) http://bugs.winehq.org/show_bug.cgi?id=4211 (autoit3 can't play back) It's kind of demanding to expect this kind of application to work properly, since it really gets under the hood of Windows, but Wine has progressed to the point where maybe it's not unrealistic. And I can think of no better way to help ISVs get their apps running on Wine than to get their regression test runner working on Wine! <insert obligatory monkeyboy reference here> - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)
by L. Lenders 02 Jan '06

02 Jan '06

Just for the info: after some digging i found a quick hack to get rid of the error: comment line 208 in dlls/x11drv/opengl.c: //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, GLX_STEREO); Somehow setting the PFD_STEREO flag makes doom3 crash and triggers the error mentioned in the subject. After commenting line 208 doom3 starts up just fine. Digging further..... :) (any help appreciated) Louis ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

5 6

Registry entries for serial ports not created
by Pavel Troller 02 Jan '06

02 Jan '06

Hi! I was trying to utilize a program for updating mobile phone's firmware (for Siemens/Benq mobiles, just an original app with encapsulated firmware image). This program immediately told that there are no serial ports present in my machine and terminated. After a bit of seeking in my own memory and wine list mail archive I remembered that there should be some registry entries which a program can examine and get some basic info about the ports. In an old mail I found something, which I converted to the following registry entry and put to system.reg file: [Hardware\\Devicemap\\Serialcomm] 1015709345 "Serial0"="COM1" "Serial1"="COM2" "Serial2"="COM3" "Serial3"="COM4" I think this should go to the standard system.reg by default, maybe in the reduced form with just the first two ports. Together with correct links in .wine/dosdevices, it makes that the program can really find the port. And at the end: How to create such a registry entry by wine's regedit ? I've spent about 15 minutes trying to do so but I've failed and then edited the file manually. Any attempt to create a "folder" called Serialcomm in Hardware\\Devicemap was unsuccessfull; I didn't find how to create a "folder" for keys, and using "Add key" menu entry I always got an error dialog saying "A subkey must be volatile". What does it mean ? With regards, Pavel Troller

2 2

MSVC compilation of DLLs
by Rolf Kalbermatter 01 Jan '06

01 Jan '06

I was just looking to get some of the Wine DLLs compiled under Visual C and run into a number of problems. First msvcmaker seems to only create a wine.dsp file in the loader directory but rather should do that in the libs/wine directory instead it would seem to me. Second it also should create a wine_unicode.dsp project in libs/unicode which it doesn't do at all. I created my own wine.dsp file to create a wine.lib file but run into new problems. First the DECLSPEC_NORETURN position in following declaration does not work with Visual C. It does want the DECLSPEC_NORETURN before the entire function declaration and not before the function pointer name. This: struct wine_pthread_functions { void (*init_process)( const struct wine_pthread_callbacks *callbacks, size_t size ); void (*init_thread)( struct wine_pthread_thread_info *info ); int (*create_thread)( struct wine_pthread_thread_info *info ); void (*init_current_teb)( struct wine_pthread_thread_info *info ); void * (*get_current_teb)(void); void (* DECLSPEC_NORETURN exit_thread)( struct wine_pthread_thread_info *info ); void (* DECLSPEC_NORETURN abort_thread)( long status ); }; should get: struct wine_pthread_functions { void (*init_process)( const struct wine_pthread_callbacks *callbacks, size_t size ); void (*init_thread)( struct wine_pthread_thread_info *info ); int (*create_thread)( struct wine_pthread_thread_info *info ); void (*init_current_teb)( struct wine_pthread_thread_info *info ); void * (*get_current_teb)(void); DECLSPEC_NORETURN void (* exit_thread)( struct wine_pthread_thread_info *info ); DECLSPEC_NORETURN void (* abort_thread)( long status ); }; to compile, but probably won't work for the GNU_C declaration of this macro, or does it? The next problem are the use of BINDIR and DLLDIR in config.c and loader.c respectively. What are those and do they have any function under a Windows compile of these files? Should those parts of the files simply be excluded for such a compile, or are they not necessary at all? Rolf Kalbermatter

1 0

Compiling test application (Notepad) with winelib - executeable segfaults
by Richard Wild 01 Jan '06

01 Jan '06

Hi all, I was trying to compile the test application (Notepad) with winelib to get a feel for how to use it. I followed the instructions in your docs, but ended up with a target file notepad2.exe.so. The instructions imply that I should end up with an executable called notepad2, since they tell me to run it. If I run the .so file it segfaults, so I assume it really is a shared library and not just an executable with a funny name. I want to understand what I've done wrong here, because if I can't get this right I certainly won't be able to port anything complicated. I'm sorry if this has been asked often before, but I couldn't find an easy way of searching the mailing list. I am using WINE-0.9.4 built by Adam Schreiber for Slackware 10.2. Regards, Rich. P.S. Here is my output (so you can see exactly what I did): rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ winemaker --lower-uppercase . Winemaker 0.6.0 Copyright 2000 Francois Gouget <fgouget(a)codeweavers.com> for CodeWeavers Scanning the source directories... Fixing the source files... License_En.c dialog.c license.c main.c Bg.rc Cs.rc Da.rc De.rc En.rc Es.rc Fi.rc Fr.rc Hu.rc It.rc Ja.rc Ko.rc Nl.rc No.rc Pl.rc Pt.rc Ru.rc Si.rc Sk.rc Sw.rc Th.rc Wa.rc Zh.rc rsrc.rc dialog.h license.h main.h notepad_res.h Generating project files... . rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ make winegcc -c -mno-cygwin -I. -o License_En.o License_En.c winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o license.o license.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -foBg.res Bg.rc Bg.rc:21:24: Error: parse error make: *** [Bg.res] Error 1 rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ vi Makefile reading Makefile wrote Makefile, 110 lines, 2368 chars rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ make wrc -I. -forsrc.res rsrc.rc winegcc -mwindows -mno-cygwin -o notepad2.exe.so License_En.o dialog.o license.o main.o rsrc.res -lodbc32 -lole32 -loleaut32 -lwinspool -luuid rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ ll total 520 -rw-r--r-- 1 rich users 5303 2006-01-01 21:02 Bg.rc -rw-r--r-- 1 rich users 5257 2006-01-01 21:02 Cs.rc -rw-r--r-- 1 rich users 5228 2006-01-01 21:02 Da.rc -rw-r--r-- 1 rich users 5495 2006-01-01 21:02 De.rc -rw-r--r-- 1 rich users 5282 2006-01-01 21:02 En.rc -rw-r--r-- 1 rich users 5625 2006-01-01 21:02 Es.rc -rw-r--r-- 1 rich users 4693 2006-01-01 21:02 Fi.rc -rw-r--r-- 1 rich users 5369 2006-01-01 21:02 Fr.rc -rw-r--r-- 1 rich users 5388 2006-01-01 21:02 Hu.rc -rw-r--r-- 1 rich users 5513 2006-01-01 21:02 It.rc -rw-r--r-- 1 rich users 5431 2006-01-01 21:02 Ja.rc -rw-r--r-- 1 rich users 5396 2006-01-01 21:02 Ko.rc -rw-r--r-- 1 rich users 1331 2006-01-01 21:02 License_En.c -rw-r--r-- 1 rich users 2040 2006-01-01 21:02 License_En.o -rw-r--r-- 1 rich users 2368 2006-01-01 21:03 Makefile -rw-r--r-- 1 rich users 5268 2006-01-01 21:02 Nl.rc -rw-r--r-- 1 rich users 5170 2006-01-01 21:02 No.rc -rw-r--r-- 1 rich users 5398 2006-01-01 21:02 Pl.rc -rw-r--r-- 1 rich users 7642 2006-01-01 21:02 Pt.rc -rw-r--r-- 1 rich users 5288 2006-01-01 21:02 Ru.rc -rw-r--r-- 1 rich users 5230 2006-01-01 21:02 Si.rc -rw-r--r-- 1 rich users 4676 2006-01-01 21:02 Sk.rc -rw-r--r-- 1 rich users 5251 2006-01-01 21:02 Sw.rc -rw-r--r-- 1 rich users 4517 2006-01-01 21:02 Th.rc -rw-r--r-- 1 rich users 5256 2006-01-01 21:02 Wa.rc -rw-r--r-- 1 rich users 5179 2006-01-01 21:02 Zh.rc -rw-r--r-- 1 rich users 22737 2006-01-01 21:02 dialog.c -rw-r--r-- 1 rich users 1754 2006-01-01 21:02 dialog.h -rw-r--r-- 1 rich users 14472 2006-01-01 21:02 dialog.o -rw-r--r-- 1 rich users 1321 2006-01-01 21:02 license.c -rw-r--r-- 1 rich users 1528 2006-01-01 21:02 license.h -rw-r--r-- 1 rich users 984 2006-01-01 21:02 license.o -rw-r--r-- 1 rich users 12222 2006-01-01 21:02 main.c -rw-r--r-- 1 rich users 1722 2006-01-01 21:02 main.h -rw-r--r-- 1 rich users 9388 2006-01-01 21:02 main.o -rwxr-xr-x 1 rich users 165396 2006-01-01 21:03 notepad2.exe.so -rw-r--r-- 1 rich users 2629 2006-01-01 21:02 notepad_res.h -rw-r--r-- 1 rich users 1813 2006-01-01 21:02 rsrc.rc -rw-r--r-- 1 rich users 65612 2006-01-01 21:03 rsrc.res rich@radhagovinda:/usr/local/src/wine-0.9.4/programs/notepad2$ ./notepad2.exe.so Segmentation fault

2 2

SPARC assembly won't compile, problems with NT headers
by Troy Rollo 01 Jan '06

01 Jan '06

winegcc from the current WineHQ produces assembly output for SPARC systems that cannot be processed by the assembler. 1. "operation combines symbols in different segments" error. This problem arises because the imports code attempts to generate a relocation involving symbols in different segments (one in the text segment and one in the data segment). SPARC assemblers (including gas on a SPARC) cannot deal with relocations involving symbols in different segments. This only affects position independent code and can be avoided by changing the assembly code output in imports.c to something simpler. 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data section}" This problem is more sinister. It arises from the same limitation as the first problem, but is not susceptible to being worked around. The offending code is the code that attempts to generate the NT header of the executable - specifically the SizeOfImage element. I can't see any way at this point to provide for this calculation to be done until after the linker output is generated. I suspect the solution to this problem is to just output a zero in this location and have winegcc modify the executable image to insert the correct values after the linker has created it. Does anybody have any objections to this solution or another approach to suggest? -- Troy Rollo - wine(a)troy.rollo.name

7 13

Re: winecfg: Added "Use PRIMARY selection" option
by Stefan Dösinger 01 Jan '06

01 Jan '06

> ChangeLog: > > Added support for "Use PRIMARY selection" clipboard option. One question: Why not make this the default? This would be the unix way to use the clipboard. Or use the primary selection on a middle mouse button click, and the other clipboard value on paste / CTRL-V? This is the behavior I'm used to from native apps. Is this possible?

2 2

Re: On creating 16bit windows convert null instances to current process
by Dmitry Timoshkov 01 Jan '06

01 Jan '06

"Joseph Garvin" <k04jg02(a)kzoo.edu> wrote: > + /* Correct if instance is null now, because later we won't > + be able to tell the difference between a 16-bit NULL and > + a 32-bit NULL */ > + > + if (!instance) > + { > + HTASK16 hTask = GetCurrentTask(); > + TDB *tdb = GlobalLock16(x); > + instance = tdb->hInstance; > + GlobalUnlock(tdb); > + } Did you ever test it? GlobalLock16 on x coordinate won't return you anything useful, not mentioning a TDB pointer. Probably you meant GlobalLock(hTask)? And GlobalUnlock(tdb) is not right at all, you want GlobalUnlock16(hTask). -- Dmitry.

3 4

re: ole db conformance tests
by Dan Kegel 01 Jan '06

01 Jan '06

About three years ago, I wrote in http://www.winehq.org/hypermail/wine-devel/2003/01/0208.html : > Say, how close are these kinds of things to being able to run under wine? > http://msdn.microsoft.com/library/en-us/oledb/htm/testtoolsov.asp The MDAC SDK, downloadable from http://msdn.microsoft.com/data/mdac/downloads/ , contains conformance tests for ole db data sources. Seems like we ought to try running them. I just verified that LTM, the test runner app, from MDAC 2.6 SDK, runs under Wine. I haven't tried running any tests, as it looks a bit involved (you have to have visual C++ installed, and you have to build the tests, it seems). Anyway, it seems like MDAC is something we really want to start supporting better, so maybe it's time to start looking into those conformance tests. Even if they only test data sources, heck, that's pretty good right there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: WININET: lpvStatusInfo in INTERNET_STATUS_NAME_RESOLVED, INTERNET_STATUS_CONNECTING_TO_SERVER, and INTERNET_STATUS_CONNECTED_TO_SERVER should be strings, not sockaddr_in.
by Robert Shearman 31 Dec '05

31 Dec '05

Jacek Caban wrote: >+ /* FIXME: inet_ntoa is not thread safe. */ >+ szaddr = WININET_strdup_AtoW(inet_ntoa(lpwhs->socketAddress.sin_addr)); > INTERNET_SendCallback(&lpwhr->hdr, lpwhr->hdr.dwContext, > INTERNET_STATUS_NAME_RESOLVED, >- &(lpwhs->socketAddress), >- sizeof(struct sockaddr_in)); >+ szaddr, strlenW(szaddr)); >+ HeapFree(GetProcessHeap(), 0, szaddr); > > Like the comment says, it is not thread-safe. I don't think it is wise to delibrately introduce race conditions like this and it tends to cause problems with applications that rely heavily on multiple threads (such as iTunes). It would be better to use the thread-safe inet_ntop (which also has the bonus of supporting IPv6) or the ws2_32 version of inet_ntoa. -- Rob Shearman

1 0

Finding patches in wine-cvs mailing list for regression tests using CVS dates
by Daniel Calviño Sánchez 31 Dec '05

31 Dec '05

Hello. First of all, I'm not sure if this message should be posted here, so sorry if it isn't the correct place. I found a regression and made some test to find the patch that caused the problem. I followed the "How to do regression testing using CVS" section in Wine documentation http://winehq.org/site/docs/winedev-guide/x1344, but I think it's outdated. The wine-cvs archive mailing list linked in the documentation is http://www.winehq.org/hypermail/wine-cvs This archive ends in August 2005. I think the archive linked should be http://www.winehq.org/pipermail/wine-cvs/ But the main problem comes now. I used CVS to make the regression test. But when looking in the mailing list messages, the date in them isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem. I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100"). Is there something I'm missing? How could I proceed? Thanks. P.D: I didn't give more information about the crash because the message was mainly focused to the dates in the mailing list question. Of course, I'll fill a bug report when I find the patch that caused the problem.

3 5

Re: Preliminary CD-Rom support on MacOS X #2
by Robert Shearman 31 Dec '05

31 Dec '05

emmanuel maillard wrote: > Changelog : > kernel/proces.c : Initialize darwin removable devices I appreciate you splitting up your patches for easier review, but patches are meant to be independent atomic changes that improve the code. However, if Alexandre applied this patch alone then Wine wouldn't compile any more and this isn't acceptable. -- Rob Shearman

3 3

Re: OLEAUT32: Use the FAILED macro to check for failure of interface methods.
by Robert Shearman 31 Dec '05

31 Dec '05

Mike McCormack wrote: > } > hr=IStream_Read(pStm,header,8,&xread); >- if (hr || xread!=8) { >+ if (FAILED(hr) || xread!=8) { > FIXME("Failure while reading picture header (hr is %lx, nread is %ld).\n",hr,xread); > return hr; > } >@@ -1128,10 +1128,10 @@ static HRESULT WINAPI OLEPictureImpl_Loa > while (xread < origsize) { > hr = IStream_Read(pStm,xbuf+xread,origsize-xread,&nread); > xread+=nread; >- if (hr || !nread) >+ if (FAILED(hr) || !nread) > break; > } >- if (!nread || hr) /* done, or error */ >+ if (!nread || FAILED(hr)) /* done, or error */ > break; > if (xread == origsize) { > origsize += sizeinc; >@@ -1139,7 +1139,7 @@ static HRESULT WINAPI OLEPictureImpl_Loa > xbuf = HeapReAlloc (GetProcessHeap(), HEAP_ZERO_MEMORY, xbuf, origsize); > } > } >- if (hr) >+ if (FAILED(hr)) > TRACE("hr in no-stat loader case is %08lx\n", hr); > TRACE("loaded %ld bytes.\n", xread); > This->datalen = xread; >@@ -1155,7 +1155,7 @@ static HRESULT WINAPI OLEPictureImpl_Loa > ULONG nread; > hr = IStream_Read(pStm,xbuf+xread,This->datalen-xread,&nread); > xread+=nread; >- if (hr || !nread) >+ if (FAILED(hr) || !nread) > break; > } > if (xread != This->datalen) > > > These changes are wrong. IStream_Read can return S_FALSE, which means that the call was successful, but didn't do what was intended. From MSDN: S_FALSE The data cannot be read from the stream object. Depending on the implementation, either S_FALSE or an error code could be returned when reading past the end of the stream. -- Rob Shearman

3 3

Finding patches in wine-cvs mailing list for regression tests using CVS dates
by Daniel Calviño Sánchez 31 Dec '05

31 Dec '05

Hello. First of all, I'm not sure if this message should be posted here, so sorry if it isn't the correct place. I found a regression and made some test to find the patch that caused the problem. I followed the "How to do regression testing using CVS" section in Wine documentation http://winehq.org/site/docs/winedev-guide/x1344, but I think it's outdated. The wine-cvs archive mailing list linked in the documentation is http://www.winehq.org/hypermail/wine-cvs This archive ends in August 2005. I think the archive linked should be http://www.winehq.org/pipermail/wine-cvs/ But the main problem comes now. I used CVS to make the regression test. But when looking in the mailing list messages, the date in them isn't the CVS commit date. Instead, it is the Git commit date (or at least I think so). The Git to CVS gateway seems to get some time to commit the changes to the CVS. So I don't know how can I get the exact patch that caused the problem. I'll try to explain it with my problem. When I update the CVS to "2005-12-21 21:29:02 +0100", the game runs perfectly. However, if I update the CVS to "2005-12-21 21:29:03 +0100", it crashes. However, looking in the mailing list, there are no commits at "2005-12-21 21:29:03 +0100" (the previous was made at "2005-12-21 21:19:47 +0100"). Is there something I'm missing? How could I proceed? Thanks. P.D: I didn't give more information about the crash because the message was mainly focused to the dates in the mailing list question. Of course, I'll fill a bug report when I find the patch that caused the problem.

1 0

Re: MSI: Change some FIXME messages to comments.
by Robert Shearman 31 Dec '05

31 Dec '05

Mike McCormack wrote: > ChangeLog: > Change some FIXME messages to comments. How hard would it be to do the work to really fix these FIXMEs? By changing these to comments I think they are going to be forgotten. -- Rob Shearman

2 1

Re: Preliminary CD-Rom support on MacOS X #5
by Markus Amsler 30 Dec '05

30 Dec '05

Hi, I took a look at your patches, here's what i've found: ntdll_cdrom.diff: > # > > @ cdecl MODULE_DllThreadAttach(ptr) > @ cdecl MODULE_GetLoadOrderW(ptr wstr wstr) >+@ cdecl CDROM_InitCDDevices() >+@ cdecl CDROM_FoundDevices() >+@ cdecl CDROM_BSDPathForMedia(ptr) >+@ cdecl CDROM_GetMountPointForBSDDevice(ptr) >+@ cdecl CDROM_BSDPathForHandle(long) >\ No newline at end of file - You shouldn't add more seperation hacks. Besides that, if _APPLE_ is not defined, the linker doesn't find these symbols. - Gcc spits out warnings about the missing newlines at the end of files. Markus

2 1

potential bug in winecfg
by Segin 30 Dec '05

30 Dec '05

I was attempting to add another override for a program (C:\StarCraft\starcraft.exe), however, when I selected the "Emulate Virtual Desktop" checkbox, winecfg freezes. There is no CPU usage, and there is nothing trown to the console. I am using Linux 2.6.14-gentoo-r3, and the slackware 10.2 binary build of wine 0.9.4 without debug symbols. The latest version of wine available for my distribution is the very last alpha release (20050925, IIRC).

4 5

WineTools is in need of some major house cleaning!
by Tom Wickline 30 Dec '05

30 Dec '05

Hello Everyone, Anyone who reads the posting on this list already knows that I stood up for the wineTools project and almost made a couple enemies... But me and Vitaliy came to a half way agreement on whether or not we should keep the link on our downloads page to WineTools.... I feel I need to ask a couple questions here about the future of WineTools. 1) Are the concerns that Vitaliy brought up being looked into ? 2) On sourceforge there are still downloads of version 1.30 from December 3, 2003 why is this? and do you plan to cancel this project or at least update it? sourceforge site: http://sourceforge.net/project/showfiles.php?group_id=61341 3 )Freshmeat list WineTools latest version at 2.1.0 and last updated 1 year, 4 months ago do you plan to update this site and list new versions as there released? http://freshmeat.net/projects/winetools/?branch_id=51159&release_id=164227 4) Could the maintainers of WineTools help new users in #winehq on irc? or start a new channel #wine-tools (or something to that effect) and help WineTools users? Can you list either the #winehq channel or a new channel on your site and ask experienced users to help new users? You may also want to update this site with new and relevant info on the project: http://linuxemu.retrofaction.com/article.php?story=20040617161145640 WineTools has received a lot of good press over the last couple years! And you guy's should be proud to take over project of it's importance. I would like to know if you plan to take over the sourceforge and freshmeat project sites and keep them up to date as you release new versions? I am not trying to be critical..... I hope winehq keeps the link to your project but you guys may need help more on winehq, and also keep information sites more up to date for this to take place. and also look in to Vitaliy's concerns. Could some one from the WineTools project give us a update on our concerns here? Cheers, Tom

3 2

Re: [comctl32] Reduce memory usage of the syslink control
by Robert Shearman 30 Dec '05

30 Dec '05

Thomas Weidenmueller wrote: >@@ -135,16 +141,16 @@ > SL_ITEM_TYPE type, PDOC_ITEM LastItem) > { > PDOC_ITEM Item; >- Item = Alloc(sizeof(DOC_ITEM) + ((textlen + 1) * sizeof(WCHAR))); >+ >+ textlen = min(textlen, lstrlenW(Text)); >+ Item = Alloc(FIELD_OFFSET(DOC_ITEM, Text[0]) + ((textlen + 1) * sizeof(WCHAR))); > > This line can be written simpler as: Item = Alloc(FIELD_OFFSET(DOC_ITEM, Text[textlen + 1])); -- Rob Shearman

1 0

Re: [oleaut32] Fix for pr4190, "_invoke unsupported number of arguments 15 in stdcall"
by Markus Amsler 30 Dec '05

30 Dec '05

Dan Kegel wrote: >The riched20 test app described in >http://bugs.winehq.com/show_bug.cgi?id=4190 >seems to require the patch >http://kegel.com/wine/pr4190.patch >which adds support for invoking functions with 15 or 16 parameters. >This is similar to the first patch in >http://bugs.winehq.com/show_bug.cgi?id=1912 > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv > > I don't think Alexandre is going to download the patch. For me (thunderbird-linux) attaching the pach works. For testing, you can send a patch to yourself, save the raw message and try* $ **cat raw_mail | patch -p0 or **$ cat raw_mail | patch -p1 According to Alexandre's Bottom Line [1]. If you still have problems I could download the patch and forward the message. [1] http://www.winehq.com/site/docs/winedev-guide/style-notes *

1 0

wine's setupapi.dll / newdev.dll ?
by Damjan Jovanovic 30 Dec '05

30 Dec '05

I've been working on a still image implementation for wine / ReactOS for a while now, and I've only recently realised how impossible it is in wine at the moment... wine's SETUPAPI.DLL is not even in its infancy, it doesn't even let you enumerate non-serial-port devices, and doesn't load class-installers, so you can't even install a scanner's INF file. I see that ReactOS's implementation is better and it is under the right (LGPL) licence; are we planning on including it into wine, and if so, when? wine's NEWDEV.DLL is pure stubs - so you can't even start installing the device INF file. ReactOS's latest SVN version of it is a little closer to what I need, but can we include GPL code in wine? (I've asked the developers to relicense it under the LGPL for us, but they haven't gotten back to me yet). So what should I do - submit my STI.DLL and STI_CI.DLL into wine now, even though they won't be usable for a good while - or wait for wine to mature? And does anyone know any good documentation for writing COM out-of-process servers (that use ncalrpc transport and have some [local] methods)? Thank you Damjan __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com

7 13

Fun with Visual Basic (if you like ole bugs :-)
by Dan Kegel 30 Dec '05

30 Dec '05

Joe Priestley and I have been trying out his Visual Basic 6 app under Wine. He's really been helpful and willing to provide test cases. In particular, see the test program linked to from http://bugs.winehq.com/show_bug.cgi?id=4144 It's a tiny little visual basic app that lets you exercize a couple of Windows APIs in several ways. It seems to be especially good at pointing OLE problems. Could I get one of our esteemed OLE experts to have a look at it? http://bugs.winehq.org/show_bug.cgi?id=4190 is an example of a little OLE problem shown by this app; that one seemed to be simple to fix. (Wine complained that the app was trying to make a 15-parameter call, but oleaut32 didn't support that yet. Adding it seemed easy.) Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

re: a more native host environment
by Dan Kegel 29 Dec '05

29 Dec '05

Justin wrote: > I'd like to see wine produce real PE dll files that > use unix system calls as a back end. For example, a > real kernel32.dll in PE format that maps at the same > addresses as the windows XP version, and so on. I think that would make it hard to link in Linux shared libraries. > PE executables could be seamlessly loaded with an ibcs > extension Er, you may be speaking nonsense here. ibcs has to do with loading system V binaries. > and properly linked against wine's real PE system dlls. They're already properly linked. Are you running into some problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

re: [commdlg] Fix ChooseColor / pr4125
by Dan Kegel 28 Dec '05

28 Dec '05

On 12/26/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > Dan Kegel <dank(a)kegel.com> writes: > > Signed-off-by: dank(a)kegel.com > > Fix for http://bugs.winehq.org/show_bug.cgi?id=4125 > > This lets the color picker respond properly to keystrokes > > This fix was made with only the most superficial understanding of the > > code, but it seems reasonable. > > It doesn't apply, looks like white space is mangled. Sorry - mail clients are getting less and less friendly to me and plain text. Please grab it from http://kegel.com/wine/pr4125.patch instead. Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

a more native host environment
by Justin Lesarge 28 Dec '05

28 Dec '05

I'd like to see wine produce real PE dll files that use unix system calls as a back end. For example, a real kernel32.dll in PE format that maps at the same addresses as the windows XP version, and so on. PE executables could be seamlessly loaded with an ibcs extension and properly linked against wine's real PE system dlls. Adapting wine to that sort of architecture would make it as native as real windows, and the bulk of wine's sources wouldn't need to be edited.

2 1

New trying to debug missing menubar
by Joseph Garvin 28 Dec '05

28 Dec '05

There's an old Windows 3.1 app I'm trying to use under wine, but it's menubar is missing. It was used for in house development for a really old game, but the programmer has asked me not to redistribute it so I can't provide a link/download. The application otherwise looks and acts exactly as it should -- but the File/About/etc. menubar is missing and thus the ability to use any of those options (I don't think the app has any accelerators). Seeing as this is such a "simple" bug (watch me eat my words) I thought it'd be a good chance to try some wine hacking. So I read the wine developer guide and tried my best. But my unfamiliarity with the Windows API / Wine has me stuck :P I've included the results of me running with WINEDEBUG=+menu below. The only thing that sticks out to me is this: warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 Which occurs multiple times. Looking at dlls/user/menu.c (function starts on line 101), it looks like USER_HEAP_LIN_ADDR is returning a 0 pointer which causes the warning. Someone in #winehq said USER_HEAP_LIN_ADDR is for 16<->32 bit conversion because 16bit apps use segment:offset to address memory (I'm still not totally sure how a segment differs from a memory address) while 32bit apps use flat addresses. USER_HEAP_LIN_ADDR itself looks like a very magical macro where to look based on it. strings informs me it's a Borland C++ 1991 app, if that's important. When I did a +relay all that showed up between the warn:menu's was calls to ENABLEMENUITEM. Hints for a newb? :) trace:menu:CreateMenu return 0x50 trace:menu:MENU_GetSysMenu hWnd 0x10022 (hMenu 0x50) trace:menu:LoadMenuIndirectW 0x7f9cea54, ver 0 trace:menu:CreateMenu return 0x94 trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f120, str L"&Restore" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea5c trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf120, Text=L"&Restore" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f010, str L"&Move" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea72 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf010, Text=L"&Move" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f000, str L"&Size" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea82 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf000, Text=L"&Size" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f020, str L"Mi&nimize" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9cea92 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf020, Text=L"Mi&nimize" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f030, str L"Ma&ximize" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaaa trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf030, Text=L"Ma&ximize" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f060, str L"&Close\tAlt-F4" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceac8 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf060, Text=L"&Close\tAlt-F4" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f130, str L"&Switch to ...\tCtrl-Esc" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceaee trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf130, Text=L"&Switch to ...\tCtrl-Esc" } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id f141, str L"&About WINE ..." trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=0x7f9ceb28 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf141, Text=L"&About WINE ..." } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000400, id 0000, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=400 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x0, Type=sep } trace:menu:InsertMenuW hMenu 0x94, pos -1, flags 00000480, id f142, str L"&Put 'Debug mark' in debug log" trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=480 str=0x7f9ceb52 trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0xf142, Text=L"&Put 'Debug mark' in debug log" } trace:menu:SetMenuDefaultItem (0x94,61536,0) trace:menu:MENU_CopySysPopup returning 0x94. trace:menu:InsertMenuW hMenu 0x50, pos -1, flags 00002410, id 0094, str (nil) (not a string) trace:menu:do_debug_print_menuitem MENU_SetItemData from: { ID=0x0, Text=Null } trace:menu:MENU_SetItemData flags=2410 str=(nil) trace:menu:do_debug_print_menuitem MENU_SetItemData to : { ID=0x94, Sub=0x94, Type=sep,pop,rorder } trace:menu:MENU_GetSysMenu hMenu=0x50 (hPopup 0x94) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:EnableMenuItem ((nil), 00ca, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cb, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00c9, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cf, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d1, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cc, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cd, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00ce, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d0, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 012e, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 012d, 0001) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:GetMenu for 0x10026 returning (nil) trace:menu:GetMenu for 0x10026 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:GetMenu for 0x10022 returning (nil) trace:menu:EnableMenuItem ((nil), 00ca, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cb, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00c9, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cf, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d1, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cc, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00cd, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00ce, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:EnableMenuItem ((nil), 00d0, 0000) ! warn:menu:MENU_GetMenu invalid menu handle=(nil), ptr=(nil), magic=0 trace:menu:GetMenuState (menu=0x94, id=f060, flags=0000); trace:menu:do_debug_print_menuitem item: { ID=0xf060, State=default, Text=L"&Close\tAlt-F4" } trace:menu:GetMenuState (menu=0x94, id=f060, flags=0000); trace:menu:do_debug_print_menuitem item: { ID=0xf060, State=default, Text=L"&Close\tAlt-F4" } trace:menu:DestroyMenu (0x50) trace:menu:DestroyMenu (0x94)

1 1

Re: URLMON: Removed not used code.
by Troy Rollo 27 Dec '05

27 Dec '05

On Wed, 28 Dec 2005 03:45, Jacek Caban wrote: > @@ -3,6 +3,7 @@ > * > * Copyright 1999 Ulrich Czekalla for Corel Corporation > * Copyright 2002 Huw D M Davies for CodeWeavers > + * Copyright 2005 Jacek Caban for CodeWeavers > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public Merely removing unused code does not give you any copyright in the file. On related matters, neither does fixing trivial bugs - there must be some substantial additional expression introduced to a file in order to give rise to a copyright claim. "Substantial" in this case means having expressive substance rather than referring to the size of the change. Most of the code you have removed has been intentionally left in because the implementation is still incomplete, but the routines you have removed are there for whoever eventually completes the implementation to build on. I am also not sure why you think the INTERNET_SCHEME_FILE case is unused. -- Troy Rollo - wine(a)troy.rollo.name

2 1

Re: exception.o - Undefined reference to NtCurrentTeb in CVS?
by Evil 27 Dec '05

27 Dec '05

Robert Shearman wrote: > > Are you compiling with -O2? If not, then that is the reason why the > error is occuring for you, but not others (but still needs to be fixed). > You hit the nail on the head, Robert. I removed -O2 from my flags while troubleshooting a problem with a different project (ffmpeg, I think), right before I went on vacation. Without it, the inline optimizations weren't occurring - just as you reckoned. I put it back and it does now compile without any issues. But, as you said, there should probably be a backup function for non-optimized builds. Thanks again for your time! Jesse

1 0

Re: unixfs: Implemented WinXP style pidl-format
by Michael Jung 27 Dec '05

27 Dec '05

Could you please ignore this patch. I'm experiencing some problems with it. I'll send a new version soon. On Tuesday 27 December 2005 16:44, Michael Jung wrote: > Changelog: > Store filenames in CP_ACP and WCHAR in the SHITEMIDs > Removed some wine_todo's for tests that now succeed > > Happy Holidays, Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: Patch for Bug 4159
by Ulrich Czekalla 27 Dec '05

27 Dec '05

I don't think this should fail if size equals 0. This function is also used by StgStreamImpl_Read and it shouldn't fail if it reads 0 bytes. I think a better place to fix it is in the SmallBlocksToBigBlocks() loop. /Ulrich On Mon, Dec 26, 2005 at 09:26:58AM -0500, Howard Selover III wrote: > ChangeLog: > Howard Selover III <selover(a)speakeasy.net> > Added back the end of read detection to eliminate a spin condition. > > > Index: dlls/ole32/storage32.c > =================================================================== > RCS file: /home/wine/wine/dlls/ole32/storage32.c,v > retrieving revision 1.97 > diff -u -p -r1.97 storage32.c > --- dlls/ole32/storage32.c 22 Dec 2005 17:12:52 -0000 1.97 > +++ dlls/ole32/storage32.c 26 Dec 2005 01:47:44 -0000 > @@ -5188,6 +5188,9 @@ HRESULT SmallBlockChainStream_ReadAt( > offsetInBlock = 0; /* There is no offset on the next block */ > } > > + if (size == 0) > + rc = E_FAIL; > + > return rc; > } > > > >

2 1

Should wordpad run yet? It's crashing for me...
by Dan Kegel 26 Dec '05

26 Dec '05

I'm trying to narrow down some riched20 problems so I can file bug reports about them. Thinking that perhaps winme's wordpad would be a good test program for this, I tried it out with wine-0.9.4... only to discover it crashes right after displaying its main window. So I filed http://bugs.winehq.org/show_bug.cgi?id=4160 Is there a better way to test riched20.dll interactively? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

(no subject)
by ethereal＠centrum.cz 26 Dec '05

26 Dec '05

Hi! I have some reminds about your product "Wine" 1. When wine changes screen resolution, it changes resolution of desktop and that move my icons and i must arrange it manually after game exit and that is the problem. Please make that resolution switching like "cedega". Cedega changes the screen resolution, but desktop dimensions are unchanged. 2. Where is the config? Implementation of "winecfg" isn't good choice. Config file was good so why you have removed it? Existence of that config file will be welcomed for many users, which wants to edit some options, which they can't edit now. 3. The "-workdir" option. When i try to run some programs or when i try to install something, sometimes wine can't find files needed by installer or installed game. Cedega uses "-workdir" parameter which sets the directory, where are that files. I couldn't install or run many games and programs because of Wine can't find that files, which are needed. (e.g. wine -workdir "/root/.wine/drive_c/warcraft III/" "C:/warcraft III/Frozen Throne.exe") Thats all what i wanted to write. U have done good work so good luck forever.

2 1

continuosly calling the function from winelib failing - stack overflow
by Ananth M 26 Dec '05

26 Dec '05

Hi I am able to successfully convert the windows dll into .so file and I am able to call the functions exported by dll from the winelib application. But if I call those functions from winelib application continuously for 1000 times , in a loop, then wine is crashing with the following error err:seh:setup_exception stack overflow 28 bytes in thread 0025 Then I tried calling the stub function itself in the loop (commented the code in stub function such that , it wont call the dll function ) Still I am getting the same error. Can any one faced this problem ? Can any one help on the same Thank you Regards aJAY

3 4

debugging help
by Robert Reif 26 Dec '05

26 Dec '05

I'm trying to help someone on wine-bugs (http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game. The problem is that the game is catching and displaying the exception. It also appears that the game won't run in winedbg. Does anyone have any ideas on how to proceed from here.

3 2

Re:[wined3d] D3DXCreateFont
by Louis. Lenders 26 Dec '05

26 Dec '05

I had the same problem. Problem is they crash when version is set to win2000. The default windows version used to be win98 up to a few months ago, if you switch back to win98, the bug you describe is absent. Louis I've been using some dx9 tutorial/demo apps that use the d3dx9.dll. I got this dll off the net somewhere (d3dx9_27.dll to be exact). This is just a utility library that has some helper functions for D3D apps, like font rendering etc. Oliver has mentioned that he uses some of the same apps for testing wined3d, which is why I picked them (http://www.codesampler.com/dx9src.htm). However, about half of them call D3DXCreateFont, which always fails on my system. As such, the return font object is null and so the demo crashes shortly afterwards when it tries to call a member function through the null object. All of these demos just try to load the "Arial" font, which seems to be registered. I'm just curious how Oliver, and maybe others, are running these demos if they always crash at startup. The demos do pop up a message box like "D3DXCreateFont: failed!!!" or something like that, and after you click the "OK" button, the app continues anyways, and then crashes soon after. If anyone knows how to get around this font thing I'd very much like to know! Cheers, Aric ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

2 1

LockWindowUpdate status?
by Dan Kegel 26 Dec '05

26 Dec '05

The last two ISVs I've talked with both had unpleasant flashing while updating rich text boxes. Both call LockWindowUpdate, and one ISV mentioned that he had to do that on Windows to prevent flashing. Poking around a bit, it seems Mike Hearn wrote at patch for this: http://www.winehq.org/hypermail/wine-patches/2004/04/0304.html but it's not yet been applied: http://www.winehq.com/hypermail/wine-devel/2004/07/0483.html What's its current status? Perhaps the time has come. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

Computer down
by Dustin Navea 26 Dec '05

26 Dec '05

Sorry to anyone that was working with me on bugs, any anyone that has written to me in the past few days. I got a bigger hdd, and was xferring data from my windows box onto it, then when I went to put my linux hdd into what was formerly my windows box, it wouldnt boot. Looks to be a bad mobo, so I am stuck with only a win box again temporarily. :-( Tom

1 0

Re: [Bug 4146] first run usability
by wino＠piments.com 26 Dec '05

26 Dec '05

Does someone want to reign in this fuck-wit before she pisses of the whole community? How can this be a dupe of a meta bug ?! The meta is supposed to regroup all such minor bugs. That's why it was created. You say you want feedback, suggestions and bug reports yet this is what happens to constructive input. Open source is about "if it does not do what you want , help fix it". This comment indicates that once again she has not even read the fucking bug before dismissing it . May be you need to make ppl pass an english comprehension test before letting them edit bug reports. Thanks fuck this nerd gets off on ranting on mailing lists, in real life she could do damage , well probably not actually, that's what it's all about. Make of it what you like, I'm tired of pissing into the wind. See you all in 10 years time for 1.0 Best of luck to the majority who have put in all the hard work in creating a potencially excellent tool and dont think they're god's gift because of it. I'm currently helping 5 first time user get used to Linux, my time will be better spent there. Special thanks to Rob for the help he has given me. On Sun, 25 Dec 2005 17:13:16 +0100, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=4146 > > > vitaliy(a)kievinfo.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution| |DUPLICATE > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2005-25-12 10:13 > ------- > This is all belongs in the manual. There were numerous discussions about > this on > wine-devel. Wine is not Windows and we do not do things in windows ways. > It's ap > to packagers to create any link on the desktop or menu. > And Wine should not associate itself with *.exe files - again up to > packagers. > > *** This bug has been marked as a duplicate of 75 *** >

6 5

Building bridges by helping small ISVs
by Dan Kegel 25 Dec '05

25 Dec '05

It's frustrating that large software vendors (Adobe, Intuit, Macromedia, IBM) aren't paying much attention to Wine, even though Wine's the quickest way for them to reach the Linux desktop market. I've been trying to figure out why they're holding back. After talking with a few large vendors and the folks working on the Munich migration project, I got the distinct feeling that Wine simply doesn't have a good reputation yet. To cut through this negative fog, we need more evidence that software vendors can succeed in the Linux market using Wine. So, how do we get that, if the large vendors won't budge? One way would be to focus on the other end of the spectrum: one-person software companies. There are so many of these that Wine already supports some of them reasonably well. I'd like to see the Wine community cultivate relationships with these folks, and coax a few of them to support and promote their apps on Linux using Wine. This will mean a lot of hand-holding on our part, helping them test their apps and file and fix Wine bugs they expose. What's in it for us? Lots of things: a) the micro-ISVs we help will be a great source of bug reports and QA b) some of them will turn into evangelists c) their success will attract the larger ISVs that we're having trouble with (e.g. Intuit, Macromedia, Adobe) who *will* be able to contribute bugfixes (by hiring contractors) d) they will increase the pool of apps available for desktop linux So, what am I doing about this? Well, I'm walking through the lists of successful micro-isvs, trying out their apps, filing bugs and helping resolve them, adding AppDB entries, exchanging emails with micro-isvs that have expressed an interest in working with Wine, and updating my Wine for Windows ISVs page, http://kegel.com/wine/isv Like everything else associated with Wine, there's enough here to keep dozens of people like me busy. I hope I can inspire more folks to follow my example. If you're interested, please jump in! And do consider taking part in my little isv mailing list experiment, http://groups.google.com/group/wine-isv ; I'm going to try to use it as the place where I give ISVs special hand-holding. - Dan --

3 2

Regression in MSI
by Sergei Rozhkov 24 Dec '05

24 Dec '05

I think, I found a regression in msi (0.9.3 -> 0.9.4). When I launch Syberia's setup.exe there was 87: "fixme:ole:ITypeInfo_fnRelease destroy child objects", displayed InstallShield Wizard with empty progress bar and stuck. Than I tryed morrowind - again 87: "fixme:ole:ITypeInfo_fnRelease destroy child objects", displayed InstallShield Wizard with two filled sells in progress bar and stuck with that: err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002 err:ole:marshal_object object doesn't expose interface {be6115a1-7de5-48dc-ad2a-25060e00fce2}, failing with error 0x80004002 err:ole:ClientIdentity_QueryMultipleInterfaces IRemUnknown_RemQueryInterface failed with error 0x80004002 Than I tryed Evil Islands - exactly the same. All this apps installed in previous versions. --- Sorry For My English and if I posted in wrong place || wrong time, or if I'm wrong. Merry Christmas!

2 2

Re: [lostwages] Remove winetools from download page
by Michael Jung 24 Dec '05

24 Dec '05

On Tuesday 20 December 2005 23:23, Vitaliy Margolen wrote: > Thus removing it from the official download page is a wise choice. I'm we > will still get number of users on wine-users and #winehq with winetools > related problems. But at least we will stop spread of "bad habits". I did'nt use winetools for quite a while now, but it was a great tool to get a newbie up and running with wine back then. If it hurts us more than it helps today, then we should take some action. But could we perhaps get in contact with Joachim von Thadden before we remove the link? He has put a lot of effort in winetools and he's a great wine advocate (He wrote a multi page technical article on wine for c't magazine a few months ago, which is one of the big computer publications here in germany. This article was based on winetools, but also did a lot of advertising for CodeWeavers and Wine in general). In my opinion he deserves some respect from our part. We should give him a chance to fix the problems with winetools before we silently remove the link. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

12 34

Accidentally fixed a bug :-)
by Dan Kegel 24 Dec '05

24 Dec '05

I've been helping a couple small ISVs test their apps and file bugs lately. To my surprise, one of the bugs (ChooseColor() not responding to keystrokes, http://bugs.winehq.org/show_bug.cgi?id=4125) was easy enough to fix without any real knowledge of the code, so I posted a patch that seems to fix it (http://www.winehq.org/pipermail/wine-patches/2005-December/023048.html). It was a pleasant surprise to run into something so easy to fix. Guess I should try it more often! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Success: The Journal runs mostly great with 0.9.4...
by Dan Kegel 24 Dec '05

24 Dec '05

While surfing, I ran into a "micro-ISV support blog", http://safarisoftware.typepad.com/mlp_developer_news dedicated to the very small developer. It happened to profile a guy who wrote a little notetaking application in Delphi years back just to learn the language, and who was surprised to find he could make a living selling it. It's called "The Journal", and a free demo is available from http://www.davidrm.com/download/jnl4setup.exe It seems to install and run rather well under wine-0.9.4 except for some richtext glitches, a redraw problem (just flip around between the main mode tabs of the app and watch the legend on the right below the toolbar - it gets pretty corrupt), and a bit of sluggishness. Plus, like many other apps I've tested lately, it constantly spews fixme:win:LockWindowUpdate (0x2003e), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! I wrote up the redraw problem as http://bugs.winehq.org/show_bug.cgi?id=4145 That's the only problem bad enough to kill a demo of the app so far. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

[wined3d] D3DXCreateFont
by Aric Cyr 24 Dec '05

24 Dec '05

I've been using some dx9 tutorial/demo apps that use the d3dx9.dll. I got this dll off the net somewhere (d3dx9_27.dll to be exact). This is just a utility library that has some helper functions for D3D apps, like font rendering etc. Oliver has mentioned that he uses some of the same apps for testing wined3d, which is why I picked them (http://www.codesampler.com/dx9src.htm). However, about half of them call D3DXCreateFont, which always fails on my system. As such, the return font object is null and so the demo crashes shortly afterwards when it tries to call a member function through the null object. All of these demos just try to load the "Arial" font, which seems to be registered. I'm just curious how Oliver, and maybe others, are running these demos if they always crash at startup. The demos do pop up a message box like "D3DXCreateFont: failed!!!" or something like that, and after you click the "OK" button, the app continues anyways, and then crashes soon after. If anyone knows how to get around this font thing I'd very much like to know! Cheers, Aric

1 0

Re: [OLE] Storage
by Sven Paschukat 23 Dec '05

23 Dec '05

Ulrich Czekalla schrieb: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Return error instead of asserting if file is corrupt This patch seems to hang installation of Internet Explorer. If I assign a native ole32.dll to ie6wzd.exe or use the builtin ole32 before this submit then it's running. The freeze happens when completing the component selection dialog. Sven

1 0

Re: Alexandre Julliard : ntdll: More compatible exception information for protection faults.
by Paul Vriens 23 Dec '05

23 Dec '05

Hi, this latest addition to the tests throws an exception on win98. Screenshot attached. Probably Alexandre's area, as he wrote the test. Cheers, Paul.

3 2

Re: [lostwages] Remove winetools from download page
by Chris Morgan 23 Dec '05

23 Dec '05

On 12/23/05, wino(a)piments.com <wino(a)piments.com> wrote: > On Fri, 23 Dec 2005 17:42:14 +0100, Chris Morgan <chmorgan(a)gmail.com> > wrote: > > > I'm going to have to side with Vitaliy on this one. I've helped > > dozens of users in #winehq that have had problems with wine due to > > winetools since we made the changes to remove the .config file. > > Apparently winetools has been upgraded to work with 0.9x versions of > > wine, this is great news although I don't think we want to promote > > winetools to users if the authors aren't going to help out in #winehq > > and provide better overall support. > > > > Chris > > > > > > Fair point Chris but didnt you have to help dozens of NON winetools users > due that change as well? > I did have to explain to a lot of users where the .config went and that they need to use winecfg. This was quite a bit easier than trying to figure out if winetools had messed up their configuration. If the winetools guys want to provide support in #winehq and rapid releases to fix issues then I'm all for keeping the link on the downloads page. Otherwise I'd rather not burden the people in #winehq with many users that require support for winetools issues. Another aspect is the large number of users that come into #winehq asking why app 'X' doesn't work under wine after winetools said it would. We are better off setting expectations at a level we know we can meet and not adding a burden to those in #winehq that are trying to provide some kind of user support. Chris

1 0

mscms: unregistered color profiles?
by Saulius Krasuckas 23 Dec '05

23 Dec '05

Hello devs, I see some XP [1] and W2k3 [2] boxes fail on every GetStandardColorSpaceProfileA() using valid parameters until SetStandardColorSpaceProfileA() is called for the first time. Then all those GetStandardColorSpaceProfileA() tests succeed. I guess that mean SPACE_RGB color profile isn't registered on those boxes. Failures are just because of missing GLE codes, but IMHO we need to test this both cases. (when SPACE_RGB is registered and when it's not) The problem is that if we test the unregistered color profile and we register it later using *A functions, then repeating same tests for the *W functions won't do OK, as I found no way to unregister Standard Color Space Profile. Any ideas on how to do that? [1] http://test.winehq.org/data/200512221000/xp_punt/mscms:profile.txt [2] http://test.winehq.org/data/200512221000/2003_w2k3/mscms:profile.txt

2 2

RE: _itow tests in ntdll/tests
by Thomas Mertes 23 Dec '05

23 Dec '05

Hello, I am the author of the _itow tests and the _itow function. As far as I can remember when I tested the _itow functions under WIN2000 and under XP (No SP or just SP1) it was allowed to call _itow with _itow(123, NULL, 10) and the result of this call was NULL. The wine _itow function implemented this functionality because of "bug by bug" compatibility (Some Applications might be based on this "Feature"). The Test was done to find regressions or changes in the M$ operating systems. In my opinion testing corner cases is important. What does "there is failure" mean. Does it crash or return something different from NULL. When it crashes under XP SP2 the function _itow should remain unchanged. When some other value (different from NULL) is returned it might be necessary to change _itow. By the way. The reason I stopped developing for Wine is: I now have my own project: Seed7 In the Seed7 programming language new statements and operators can be declared easily. Functions with type results and type parameters are more elegant than a template or generics concept. Look at wikipedia: http://en.wikipedia.org/wiki/Seed7 or at sourceforge: http://sourceforge.net/projects/seed7 Just download Seed7 and see the new concepts. Greetings Thomas Mertes -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

2 1

Re: Wine IE6 and JVM
by Dominic Wise 23 Dec '05

23 Dec '05

On Thu, 2005-12-15 at 17:38 +0200, Adrian Munteanu wrote: > Hi guys, > > I am trying to use wine with IE 6. > Most of the pages are displaying fine, however the problem is with pages > requesting JVM running. > So could you please help me find away, if available, to make IE use > installed JVM? > > Thanks and best regards > Adrian > > > Have you tried latest winetools? I ask because it worked for me with IE6 .It has been updated to the 0.9 wine version. Hope this helps, Dom

1 0

Re: msiexec null reference
by Mike McCormack 23 Dec '05

23 Dec '05

Bill Medland wrote: > + static const WCHAR dfv[] = { > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 }; > + if (!dialog->default_font) > + { > + DWORD len = strlenW (dfv) + 1; > + dialog->default_font = msi_alloc(len*sizeof(WCHAR)); > + if (!dialog->default_font) return -1; > + memcpy (dialog->default_font, dfv, len*sizeof(WCHAR)); > + } How about this? if (!dialog->default_font) dialog->default_font = msi_strdupW( dfv ); Mike

2 1

Poser label issue [Bug 2737]
by Vikram Kumar 23 Dec '05

23 Dec '05

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

2 1

Re: Use the new RtlExitUserThread function instead of exporting
by Saulius Krasuckas 23 Dec '05

23 Dec '05

With this change [*] header does not compile under MSVC 6: --- include/winternl.h +++ include/winternl.h @@ -1985,6 +1985,7 @@ BOOL WINAPI RtlEqualPrefixSid(PSID, BOOL WINAPI RtlEqualSid(PSID,PSID); BOOLEAN WINAPI RtlEqualString(const STRING*,const STRING*,BOOLEAN); BOOLEAN WINAPI RtlEqualUnicodeString(const UNICODE_STRING*,const UNICODE_STRING*,BOOLEAN); +void WINAPI RtlExitUserThread(ULONG) DECLSPEC_NORETURN; NTSTATUS WINAPI RtlExpandEnvironmentStrings_U(PWSTR, const UNICODE_STRING*, UNICODE_STRING*, ULONG*); LONGLONG WINAPI RtlExtendedMagicDivide(LONGLONG,LONGLONG,INT); LONGLONG WINAPI RtlExtendedIntegerMultiply(LONGLONG,INT); Moving DECLSPEC_NORETURN to before a WINAPI keyword helps. [*] http://source.winehq.org/git/?p=wine.git;a=blobdiff;h=ee582be9bc8ae5797b762…

1 0

Re: advpack: fix LaunchInfSection[Ex] documentation
by James Hawkins 23 Dec '05

23 Dec '05

On 12/22/05, Markus Amsler <markus.amsler(a)oribi.org> wrote: > > - * show [I] How the window should be shown. > + * show [I] Reboot behaviour: > + * 'A' reboot always > + * 'I' default, reboot if needed > + * 'N' no reboot > * Where are you getting this behavior from? Microsoft's public header advpub.h does not include this information, and while that doesn't mean we shouldn't include it either, it would be nice to see tests for this behavior, either in the form of an app that displays the behavior or preferably tests in wine's test suite. -- James Hawkins

2 2

Re: Bug 3885
by Tom Spear 22 Dec '05

22 Dec '05

Aric Cyr wrote: >>>I took a look at the D3D_OK hack, and I believe the problem to be >>>CheckDeviceFormat in wined3d/directx.c. This function should return an error if >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. Currently >>>it just returns OK for most formats though. This code is really just a stub as >>>it stands, and needs to be converted to check if there are any visuals that meet >>>the requested format's requirements, and if there is, return D3D_OK, otherwise >>>D3D_NOTAVAILBLE. >>> >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 case >>>(you'll need to add it) in wined3d/directx.c in IWineD3DImpl_CheckDeviceFormat() >>>and see if that fixes that issue or not. This would be just another hack >>>though, so a real patch would still be necessary as I decribed above. Well I took a stab at adding the case for D3DFMT_D32, to the bottom of the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes the first one and then goes to do the second one, but crashes in a different spot, so it seems we also have some stack corrupion (as was mentioned in the bug).. So that hack works for now, I would suggest that since the rest of that code is stubbed out, we should probably go ahead and submit a patch so we can at least run the darn thing and then start debugging the stack corruption issue. I should add that on the first run, I disabled the title screens between benchmarks, and changed the "Display and CPU Settings" so that I was using 32-bit textures and triple buffering, and it ran thru several of the tests, while on the 2nd and 3rd runs, I left all settings at defaults; during run 2, it died just after the title screen for mark #2, and during run 3, it died in the middle of mark #2...

4 3

ATI Opengl regression (DRI?)
by Jesse Allen 22 Dec '05

22 Dec '05

Hi, It seems that the patch git-1399edb0925966a802a6a39835025c22c22c18e1.patch found here http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html causes an opengl regression on my system. With the patch loading War3 causes X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) Serial number of failed request: 429 Current serial number in output stream: 429 Which seems to stop the game loading thread and causes the game to use the fail-safe thread "Please insert disc", so the game wont load. Reversing the patch fixes the problem. I have a Radeon 9200 using DRI snapshots about 20051024. X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from X.org tr ee) Release Date: 18 October 2005 + cvs X Protocol Version 11, Revision 0, Release 6.8.99.901 Build Operating System: Linux 2.6.14-rc5 i686 [ELF] Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri Dec 2 17:0 3:32 MST 2005 i686 Build Date: 28 October 2005 Is this a DRI problem? Thanks, Jesse

3 5

Resent: [opengl] fix last wgl regression
by Raphael 22 Dec '05

22 Dec '05

Resent resync patch with little correction Regards, Raphael On Thursday 15 December 2005 23:59, Raphael wrote: > Hi, > > Thix patch should fix last wgl patch regression > anyway i don't understand why ATI drivers don't support older GLX 1.3 specs > (as 1.4 is already here). > > For glXGetFBConfigs i don't plan to support a compatibility code, > it should be too buggy (on pixel format selection) as was older opengl code > as we can't query visuals > > Changelog: > - fix wgl regression: test glx server version and extensions to use (and > not use glXQueryDrawable on older glx implementations) > > Regards, > Raphael

1 0

Poser label issue [Bug 2737]
by Vik Kumar 22 Dec '05

22 Dec '05

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

1 0

Need help fixing deadlock (GDI)
by Cihan Altinay 22 Dec '05

22 Dec '05

Hi, I have spent days finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some more traces I feel I am pretty close but I'm stuck now. The problem is connected to GDI's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is this comment "FIXME: there is a race condition here"... is that the cause? Btw. this might be the same problem as bug #3125. Can somebody give me a hint on how to tackle this? If you need more output please let me know. Thanks a lot, Cihan

1 0

_itow tests in ntdll/tests
by Paul Vriens 21 Dec '05

21 Dec '05

Hi, I was just diving into this as there is failure for months with this test on Winxp-SP2 and W2K3. We call _itow, like this: result = p_itow(ulong2str[0].value, NULL, 10); This however seems not be allowed anymore. Changing it to WCHAR buffer[LARGE_STRI_BUFFER_LENGTH + 1]; result = p_itow(ulong2str[0].value, buffer, 10); make the test succeed, but I don't know what the author wanted with these tests. Any ideas ? Cheers, Paul.

1 0

Poser label issue [Bug 2737]
by Vikram Kumar 21 Dec '05

21 Dec '05

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

1 0

Re: sound enabled but no driver checked
by Cihan Altinay 21 Dec '05

21 Dec '05

Robert Reif wrote: > Cihan Altinay wrote: > >> Quoting Robert Reif <reif(a)earthlink.net>: >> >> >> >>> Cihan Altinay wrote: >>> >>> >>> >>>> With a fresh wine prefix sound is enabled but I can't >>>> see which driver is used because none of them is checked >>>> in the new winecfg sound dialog. >>>> Did we forget to initialize the boxes on first run? >>>> >>>> Cheers, >>>> Cihan >>>> >>>> >>> >>> Use regedit to show HKCU/Software/wine/Drivers/Audio. >>> Chances are it's empty (no drivers checked) so sound is >>> disabled. It could be set to a driver that is not available >>> but winecfg checks for that and should give you an error. >>> >> >> >> Well... the key doesn't exist unless I run winecfg at least once >> and change something. In that case it's not really important because >> a user will probably do that anyway. >> The only minor issue would be that someone runs winecfg for the first >> time and is satisfied with the defaults (no driver checked -> sound off) >> so without any changes he dismisses winecfg. And in this case it seems >> one of the drivers is used by default (sound on). >> >> Cheers, >> Cihan >> >> >> >> > I have a patch to fix this. OSS is the default if there is no registry > key. Great! Will you submit it?

1 0

Re: has the LGPL licence fell through ? (forw)
by Joerg Mayer 21 Dec '05

21 Dec '05

as a simple reply isn't sent to the list.... ----- Forwarded message from Joerg Mayer <jmayer(a)loplof.de> ----- Date: Wed, 21 Dec 2005 09:22:11 +0100 From: Joerg Mayer <jmayer(a)loplof.de> To: Aric Cyr <Aric.Cyr(a)gmail.com> Subject: Re: has the LGPL licence fell through ? In-Reply-To: <loom.20051221T082013-24(a)post.gmane.org> On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > Maybe I'll fire off an email to Turbolinux to see what they have to say, > although technically unless I purchase or receive their product I am not > directly entitled to the GPL/LGPL code from them. Anyone have a copy of Can you please let me know why you think that? ---------------------------- 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... ------------------------------- So I guess if they are using some code of yours that you provided to them under LGPL, you are entiteld to request the source. In case this goes to court you'll need a copy, but for now it is sufficient to be sure that they are distributing a product based on your code which is covered by the LGPL. Again: It is *you* who granted them the right to use your code, and by putting it under LGPL you made sure that you are entitled to any changes they make to *the* code once they start distributing your code (or derivatives) to thrid parties. That way you can reqeust the changes even when the new product costs $10M. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

2 1

Bug 3885
by Tom Spear 21 Dec '05

21 Dec '05

Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things? I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens. I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt. Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel.. Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself. Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there. If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems. If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16.. Tom

2 1

[wined3d] Code questions
by Aric Cyr 21 Dec '05

21 Dec '05

I just have a couple wined3d code questions/comments that I'd like to clear up and possible submit patches if my understanding is correct. If I am misunderstanding the code please correct me. 1) basetexture.c:BindTexture() Just _before_ we call glBindTexture we call glTexParameteri and either set GL_TEXTURE_MAX_LEVEL or GL_TEXTURE_MIN_FILTER. The comment in the code is: "Always need to reset the number of mipmap levels when rebinding as it is a property of the active texture unit, and another texture may have set it to a different value" However, this doesn't make any sense to me and I believe it to be incorrect. glTexParameter affects the currently bound texture object. If the current and next texture to be bound have different mipmaps levels or parameters it should not be necessary to change these settings as all the state is encapsulated correctly in the OpenGL texture object, which should have been initialized correctly in Device::CreateTexture or BaseTexture::ApplyStateChanges. The reason the current code is bad is two-fold: 1) unneeded state changes on a performance critical path, as texture binding is very frequent and 2) changing the state of a _previous_ texture object, not the current one. The next time we go to use that texture object we will have to reapply all of it's state again, another waste of time. I spent a lot of the weekend debugging wined3d (trying to get anisotropic working in World of Warcraft) and just commenting out the block of code greatly cut down on d3d trace messages and makes the code easier to understand (and faster). 2) device.c::SetupTextureStates() Similar to my previous remark, there seems to be an incorrect state change here as well. glTexEnvf(TEXTURE_FILTER_CONTROL, LOAD_BIAS), glBlendColor() and then glTexEnvfv(TEXTURE_ENV, TEXTURE_ENV_COLOR) are called. All of these are called for each texture state update. However these are all global render states, not per-texture contrary to the comment in the code. Since these states are already being set in Device::SetRenderState() I'm pretty sure they don't need to be set here as well. Well that's all for now. Having started to really dig into wined3d, it seems that some effort in cleaning it up (coding style is way off) and stablizing it before it gets much more unwieldy is due. I'm also willing to help with such a task if there is a consensus that it should be done. Regards, Aric

2 2

Re: PATCH: wctime / wasctime
by Robert Shearman 21 Dec '05

21 Dec '05

Marcus Meissner wrote: >@@ -88,6 +88,8 @@ > MSVCRT_unexpected_function unexpected_handler; > MSVCRT__se_translator_function se_translator; > EXCEPTION_RECORD *exc_record; >+ MSVCRT_wchar_t *wctime_buffer; /* buffer for ctime */ >+ MSVCRT_wchar_t *wasctime_buffer; /* buffer for asctime */ > }; > You need to free these buffers on thread destruction. -- Rob Shearman

1 0

has the LGPL licence fell through ?
by Tom Wickline 21 Dec '05

21 Dec '05

Yes I have read the licence just re read it for that matter... So why no patches from SpecOps? should Wine move to GPL to keep from being robbed of its code? If your wondering why I'm ranting : http://news.inq7.net/infotech/index.php?index=1&story_id=60585 Tom

10 15

Re: Bill Medland : msi: Use a default dialog font if nothing is specified.
by Bill Medland 20 Dec '05

20 Dec '05

On December 20, 2005 02:56 am, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: e0d4df6bb7c009c8cbfa579c22c8d9406025f65c > URL: > http://source.winehq.org/git/?p=wine.git;a=commit;h=e0d4df6bb7 >c009c8cbfa579c22c8d9406025f65c > > Author: Bill Medland <billmedland(a)mercuryspeed.com> > Date: Tue Dec 20 11:59:23 2005 +0100 > > msi: Use a default dialog font if nothing is specified. > > --- > > dlls/msi/dialog.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/dlls/msi/dialog.c b/dlls/msi/dialog.c > index 87e14e8..c4f9d2c 100644 > --- a/dlls/msi/dialog.c > +++ b/dlls/msi/dialog.c > @@ -1618,6 +1618,8 @@ static LRESULT msi_dialog_oncreate( HWND > { > static const WCHAR df[] = { > 'D','e','f','a','u','l','t','U','I','F','o','n','t',0 > }; + static const WCHAR dfv[] = { > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 }; > msi_dialog *dialog = (msi_dialog*) cs->lpCreateParams; > MSIRECORD *rec = NULL; > LPWSTR title = NULL; > @@ -1644,6 +1646,11 @@ static LRESULT msi_dialog_oncreate( > HWND dialog->attributes = MSI_RecordGetInteger( rec, 6 ); > > dialog->default_font = msi_dup_property( dialog->package, > df ); + if (!dialog->default_font) > + { > + dialog->default_font = strdupW(dfv); Thanks for tidying and submitting this, Alexandre. Just asking; we are confident that strdupW is symmetric with msi_free, aren't we? That was why I had the three-line "msi_strdupW" > + if (!dialog->default_font) return -1; > + } > > title = msi_get_deformatted_field( dialog->package, rec, > 7 ); SetWindowTextW( hwnd, title ); -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

Re: sound enabled but no driver checked
by Cihan Altinay 20 Dec '05

20 Dec '05

Quoting Robert Reif <reif(a)earthlink.net>: > Cihan Altinay wrote: > > >With a fresh wine prefix sound is enabled but I can't > >see which driver is used because none of them is checked > >in the new winecfg sound dialog. > >Did we forget to initialize the boxes on first run? > > > >Cheers, > >Cihan > > > Use regedit to show HKCU/Software/wine/Drivers/Audio. > Chances are it's empty (no drivers checked) so sound is > disabled. It could be set to a driver that is not available > but winecfg checks for that and should give you an error. Well... the key doesn't exist unless I run winecfg at least once and change something. In that case it's not really important because a user will probably do that anyway. The only minor issue would be that someone runs winecfg for the first time and is satisfied with the defaults (no driver checked -> sound off) so without any changes he dismisses winecfg. And in this case it seems one of the drivers is used by default (sound on). Cheers, Cihan

1 0

Re: [lostwages] Remove winetools from download page
by James Hawkins 20 Dec '05

20 Dec '05

On 12/20/05, Vitaliy Margolen <wine-patch(a)kievinfo.com> wrote: > I can't say how many people have come to #winehq with different problems > that were related to winetools. From what I could see, not a single > person who I talked to had winetools installed and had Wine programs > working properly. > I agree. Winetools goes against our goal of not using native dlls, and takes away needed testing of our builtin dlls. If people decide to use it on their own, then that's cool with me, but we shouldn't promote its use. -- James Hawkins

3 2

PATCH/RFC: defer OLE apartment window creation
by Marcus Meissner 20 Dec '05

20 Dec '05

Hi, RFC ... since its likely not the clean way Robert wants. This defers the appartment window creation until it is actually need. Ciao, Marcus Changelog: Defer OLE apartment window creation until it is actually needed. Index: dlls/ole32/compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.168 diff -u -r1.168 compobj.c --- dlls/ole32/compobj.c 12 Nov 2005 19:11:21 -0000 1.168 +++ dlls/ole32/compobj.c 20 Dec 2005 22:06:39 -0000 @@ -236,9 +236,6 @@ { /* FIXME: should be randomly generated by in an RPC call to rpcss */ apt->oxid = ((OXID)GetCurrentProcessId() << 32) | GetCurrentThreadId(); - apt->win = CreateWindowW(wszAptWinClass, NULL, 0, - 0, 0, 0, 0, - 0, 0, OLE32_hInstance, NULL); } else { @@ -257,6 +254,15 @@ return apt; } +void make_apartment_window(APARTMENT *apt) { + if (apt->win) return; + if (!(apt->model & COINIT_APARTMENTTHREADED)) + return; + apt->win = CreateWindowW(wszAptWinClass, NULL, 0, + 0, 0, 0, 0, + 0, 0, OLE32_hInstance, NULL); +} + /* gets and existing apartment if one exists or otherwise creates an apartment * structure which stores OLE apartment-local information and stores a pointer * to it in the thread-local storage */ Index: dlls/ole32/compobj_private.h =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v retrieving revision 1.60 diff -u -r1.60 compobj_private.h --- dlls/ole32/compobj_private.h 28 Nov 2005 11:04:18 -0000 1.60 +++ dlls/ole32/compobj_private.h 20 Dec 2005 22:06:39 -0000 @@ -253,6 +253,8 @@ return COM_CurrentInfo()->apt; } +void make_apartment_window(APARTMENT *apt); + #define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) /* helpers for debugging */ Index: dlls/ole32/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/rpc.c,v retrieving revision 1.72 diff -u -r1.72 rpc.c --- dlls/ole32/rpc.c 19 Dec 2005 20:24:25 -0000 1.72 +++ dlls/ole32/rpc.c 20 Dec 2005 22:06:39 -0000 @@ -257,6 +257,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); } else @@ -498,6 +499,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); WaitForSingleObject(params->handle, INFINITE); CloseHandle(params->handle);

1 0

Testing WideCharToMultiByte
by Bill Medland 20 Dec '05

20 Dec '05

Has anyone ever done a proper investigation into the edges of WideCharToMultiByte? I was quite surprised to see that given how important it is there is no test for it (or am I blind?) I am investigating a potential off-by-one in msi and want to know very exactly what is supposed to happen in the edge cases (e.g. specifying a length of 0 or a length that does not actually include a terminating null character or ...). If no-one else is involved then I am prepared to do a little investigation and write the tests but I guess we don't want to start adding tests like that at this late stage, or do we? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 1

errors fixed with crossoffice
by Curro Amores 20 Dec '05

20 Dec '05

Hi i have a problem with wine and my access97 reports Letters are show separated and bigger. However using crossoffice i dont have this problem. How can i know where is the problem i have installed freetype, fontconfig last versions, copied all my ttf files... thanks

2 1

Re: WLDAP32: link to the reentrant version of libldap
by Alexandre Julliard 20 Dec '05

20 Dec '05

Hans Leidekker <hans(a)it.vu.nl> writes: > On Monday 19 December 2005 20:47, Alexandre Julliard wrote: > >> It's really not much more work to do it right the first time around, > > Thanks for calling me lazy ;-) I wasn't worried about the amount of > work, I was looking ahead thinking about how distro x version y might > need another check for some missing functions, and they would start > adding up. There was a time when the ldap_*_ext functions didn't > exist for example. This library has quite a long history. All the more reason to check for the functions we are actually using. If there are more library variants to check for, it won't be manageable to only check for a function or two and then attempt to guess which other functions may or may not be defined. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: MSI patch getting some installer working thx deformat_environment did cut off string at beign of it.
by Uwe Bonnes 20 Dec '05

20 Dec '05

>>>>> "Magnus" == Magnus Olsen <magnus(a)itkonsult-olsen.com> writes: Magnus> in function deformat_environment did cut of one letter of Magnus> GetEnvironmentVariableW at beigner in second call. it try found Magnus> example LLUSERSPROFILE but it mean ALLUSERSPROFILE. fixed by me Magnus> and hpussin. in ReactOS Magnus Olsen greatlord(a)reactos.com Magnus> begin 666 format.c.patch Magnus> M26YD97@Z(&1L;',O;7-I+V9O<FUA="YC#0H]/3T]/3T]/3T]/3T]/3T]/3T] Magnus, please follow our patch convention: - unified diffs from below the wine directory - as plain text attachment (makes it easier to read for the list) If patches get not applied, resubmit. You'll get some reaction from Alexandre after some time. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Steam Winsock regression
by James Liggett 20 Dec '05

20 Dec '05

Hi, For a while now I've been noticing a very bad regression in winsock with steam. If I try to view information about a server using the "View game info command," my Internet connection fails completely. Not only that, but sometimes *all* of the machines on my network (both WinXP and Linux) lose their connections as well. I did the usual drudgery and found the offending patch: http://www.winehq.com/pipermail/wine-cvs/2005-November/019293.html Can someone take a look at this one ASAP? Thanks very much! James

5 12

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