wine-devel July 2005

wine-devel@winehq.org

152 participants
298 discussions

TR: wine on FreeBSD with patch
by jean-marc DETREZ 29 Jul '05

29 Jul '05

_____ De : jean-marc DETREZ [mailto:jm.detrez@cegetel.net] Envoyé : vendredi 29 juillet 2005 20:28 À : 'Alexandre Julliard' Cc : 'barner(a)FreeBSD.org'; 'wine-devel(a)winehq.com'; 'emulation(a)freebsd.org'; 'Dmitry Timoshkov'; 'Gerald Pfeifer' Objet : TR: wine on FreeBSD with patch _____ De : jean-marc DETREZ [mailto:jm.detrez@cegetel.net] Envoyé : vendredi 29 juillet 2005 20:18 À : 'Alexandre Julliard' Cc : 'barner(a)FreeBSD.org'; 'Gerald Pfeifer'; 'wine-devel(a)winehq.com'; 'emulation(a)freebsd.org'; 'Dmitry Timoshkov' Objet : wine on FreeBSD Hi, With the differents mails i receive from users or wines developers, i think that: - Dislike OpenBSD or SRV4, mincore didnt fail if the page is not mapped no [ENOMEM] error condition. - the FreeBSD man pages say that mmap would fail with [ENOMEM] error condition if address is in use but in the reality it seems always return the start address. So for to use wine on FreeBSD before doing a more clean patch i propose to add this to mmap . I know that it would map memory pages without verify before that the pages isnt already map but the man pages say it must failed so Im just verify that the result is equal to start address the mmap call asking for. I do that only when creating System heap because requesting mmap for 0x800000 start address (without MAP_FIXED) always fail and prevent wine running on FreeBSD. Ill do more test to implement a try_mmap_fixed function working on FreeBSD like this done for SRV4,NetBSD and DARWIN. Jean-marc

1 0

[Fwd: Re: [Fwd: Re: [Wine]wine-20050725 feedback : lots of graphical glitches]]
by Vincent Rubiolo 29 Jul '05

29 Jul '05

Sending to the devel-list as suggested by people on wine-users. Just wasn't sure whther those kind of reports would be welcome on the devel ML. The issues mentioned below seem to be regressions. Thanks for your attention, I am willing to help but am just beginning to grasp everything wine-related. Vincent -------- Original Message -------- Subject: Re: [Fwd: Re: [Wine]wine-20050725 feedback : lots of graphical glitches] Date: Fri, 29 Jul 2005 14:03:50 +0200 From: Vincent Rubiolo <vincent.rubiolo(a)free.fr> To: wine-users(a)winehq.org References: <42E9DEFD.6090508(a)free.fr> Hello, I have submitted three bugs relative to these problems : + http://bugs.winehq.org/show_bug.cgi?id=3169 + http://bugs.winehq.org/show_bug.cgi?id=3170 + http://bugs.winehq.org/show_bug.cgi?id=3171 Vincent Vincent Rubiolo wrote: > Ths list was forgotten. Forwarding. > > Vincent > > -------- Original Message -------- > Subject: Re: [Wine]wine-20050725 feedback : lots of graphical glitches > Date: Thu, 28 Jul 2005 17:45:44 -0700 > From: George Lober <glober(a)telus.net> > To: Vincent Rubiolo <vincent.rubiolo(a)free.fr> > References: <42E8D1CC.5010006(a)free.fr> > > Vincent Rubiolo wrote: > >> Hello wine-users, >> >> I built and installed (with wineinstall) wine-20050725 [see system >> info at end of mail]. >> While it works OK for most of the applications that I use (I still >> have some crashes, I will investigate them), I have lots of graphical >> glitches, some of which greatly reduce the usability of the >> applications : >> >> Firefox : >> ---------- >> + Installation problems, esp. with respect to icons and text. I am >> attaching small screenshots for you to see the problems. During the >> installation, the console returns : >> fixme:win:SetWindowTextW setting text L"Extracting" of other process >> window 0x10022 should not use SendMessage >> err:static:STATIC_SetIcon huh? hicon!=0, but info=0??? >> >> + Main page display problem. Black boxes in rendered page (which is >> perfect on native Linux FF). Menubar scrambled. It clears up a little >> (not perfect though) when my mouse passes over it. Console says : >> err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} >> not registered >> fixme:ole:CoCreateInstance no classfactory created for CLSID >> {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 >> err:clipboard:CLIPBOARD_CloseClipboard Failed to set clipboard. >> >> 7-Zip: >> ------ >> The combo box under the icons is almost not appearing at all, making >> it impossible to navigate in directories (see small screenshot). >> >> >> This is just to show the problems I am encountering. I tried searching >> in the Bugzilla but the search (keyword firefox) returned no replies. >> I have to say that the search is quite cumbersome. I use Bugzilla >> almost daily (Mozilla project for instance), and searches are a lot >> easier because there is a simple search box, instead of having >> everyone to use the advanced search function. >> >> I also have opened an account on the AppDB. Should I report these >> problems to the apps maintainers instead (it seems so)? >> There is so much documentation that I don't know what to do : you seem >> to welcome bug reports but I am not sure whether apps bugs are helpful >> to you. Are they? >> >> Could you give me some pointers please? >> >> Thank you. I am willing to participate and help but don't know what to >> report exactly as I am not familiar with Wine internals. >> >> Vincent >> >> System information as requested on >> http://www.winehq.com/site/docs/wine-user/bug-reporting : >> --------------------------------------------------------- >> + Wine 20050725 (note that wine -v does not work anymore, contrary to >> what the page says) >> + kernel : i686 GNU/Linux 2.4.21-27.0.1.EL (this is Redhat Entreprise >> WS3) >> + compiler : gcc (GCC) 3.4.3 >> + windows : no windows installed or used >> + program : firefox 1.0.5, available at www.mozilla.org >> + cmdline : wine firefox.exe (in fake_c\Program Files\Mozilla Firefox) >> + X server : 4.3.0 shipped by Redhat >> + steps to reproduce : simply start firefox after installing. Same for >> 7zip. >> > > Hello, > > I would also like to add that I am having similar problem with my > install of wine-20050725, where the Toolbar buttons of an application > called DietPower are incorrectly sized smaller (about 26pix compared to > normal size of about 37pix). The Toolbutton Images are sized correctly > resulting in a mess. Version 20050628 and previous versions don't have > this problem. Would it help to post this on the bug-tracker ? > > Regards, George > -- Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird -- Reclaim Your Inbox! http://www.mozilla.org/products/thunderbird

1 0

Re: [wined3d] tidy up draw prim and add strided data new to d3d9
by Felix Nawothnig 29 Jul '05

29 Jul '05

Oliver Stieber wrote: > use ++x instead of x++ since x++ potentially requires a temporary variable. I seriously doubt this will actually have an effect on the resulting assembly code generated by any semi-serious compiler (regardless of the -O level) as for(i = 0; i < x; i++) is a quite common idiom... Felix

1 0

Impressive! Installshield actually almost worked!
by Hans Kristian Rosbach 29 Jul '05

29 Jul '05

For the very first time I the AltiAgent 5.0 installer actually managed to show a spash screen and even a progress bar that shows the loading of Installshield. I think the progressbar got to 100%, but then wine crashed. Good work, I'm seriously impressed and will be testing a few other installers too now. Btw, anyone know a good IE5/5.5/6 installer? One of my other programs depends on it beeing installed. I'm running a cvs checkout of about an hour old. This is the complete unedited output (ignore the libGL warnings): [root@linux AltiAgent 5.0]# wine setup.exe libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 fixme:msi:MsiGetProductInfoW L"{87E06BA6-48C0-4793-9382-6945EF684D96}" L"PackageCode" 0x6e4ac070 0x7fddd884 fixme:msi:MsiInstallProductW L"Z:\\home\\hk\\.wine\\drive_c\\AltiAgent 5.0\\ISScript9.Msi" L"REBOOT=ReallySuppress ADDLOCAL=All" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"SelfUnregModules" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveFiles" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MoveFiles" fixme:msi:ACTION_InstallFiles Write DiskPrompt fixme:msi:ITERATE_DuplicateFiles We should track these duplicate files as well fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveRegistryValues" fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"RemoveFolders" libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 fixme:msi:MsiInstallProductW L"Z:\\home\\hk\\.wine\\drive_c\\AltiAgent 5.0\\AltiAgent 5.0.msi" L" REINSTALLMODE=vemus REINSTALL=ALL SETUPEXEDIR=\"Z:\\home\\hk\\.wine\\drive_c\\AltiAgent 5.0\"" libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 fixme:ole:RpcChannelBuffer_GetDestCtx (0x19445734,0x19445738), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x19445730,0x19445734), stub! fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window (nil) should not use SendMessage fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fdcef00,0x7fdcef04), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fdcee04,0x7fdcee08), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fdcee88,0x7fdcee8c), stub! [root@linux AltiAgent 5.0]# wine: Unhandled exception (thread 000c), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:11ff GS:0033 EIP:00000000 ESP:5a9ec654 EBP:5a9edb24 EFLAGS:00210202( - 00 - -RI1) EAX:7c47a010 EBX:00000000 ECX:00010020 EDX:006486ee ESI:10014d10 EDI:7cfb0fe0 Stack dump: 0x5a9ec654: 10005639 7c47a010 10017b48 10003baf 0x5a9ec664: 10014d10 5a9edb18 5a9edb24 10011a00 0x5a9ec674: 5a9edb18 10003a03 10017b48 7be3e1a0 0x5a9ec684: 0017b1d8 00175720 00000000 00000000 0x5a9ec694: 00000000 00000000 00000000 00000000 0x5a9ec6a4: 00000000 00000000 00000000 00000000 023f: sel=11ff base=7d50e000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00000000 (0x5a9edb24) 2 0x0013fc44 DllThread+0x280(info=0x7be52270) [/usr/src/wine-cvs/wine/dlls/msi/custom.c:442] in msi (0x5a9edb48) 3 0x00b7ce85 THREAD_Start+0xd1(ptr=0x7be52c80) [/usr/src/wine-cvs/wine/dlls/kernel/thread.c:108] in kernel32 (0x5a9edc14) 4 0x006287ee start_thread+0x12e(info=0x7be53028) [/usr/src/wine-cvs/wine/dlls/ntdll/thread.c:235] in ntdll (0x5a9ee458) 5 0x00440b80 start_thread+0x80 in libpthread.so.0 (0x5a9ee4c8) 6 0x00398dee __clone+0x5e in libc.so.6 (0x00000000) 0x00000000: addb %al,0x0(%eax) Modules: Module Address Debug info Name (71 modules) ELF 0x00111000-0017c000 Stabs msi<elf> \-PE 0x00130000-0017c000 \ msi ELF 0x0017c000-00233000 Deferred shell32<elf> \-PE 0x001a0000-00233000 \ shell32 ELF 0x00233000-00287000 Deferred shlwapi<elf> \-PE 0x00250000-00287000 \ shlwapi ELF 0x00287000-002a1000 Deferred version<elf> \-PE 0x00290000-002a1000 \ version ELF 0x002b0000-002cc000 Deferred ld-linux.so.2 ELF 0x002cc000-002ce000 Deferred xlcutf8load.so.2 ELF 0x002ce000-003f8000 Export libc.so.6 ELF 0x003fa000-0041e000 Deferred libm.so.6 ELF 0x00420000-00424000 Deferred libdl.so.2 ELF 0x00424000-00437000 Deferred libz.so.1 ELF 0x0043b000-0044d000 Export libpthread.so.0 ELF 0x0044d000-00489000 Deferred advapi32<elf> \-PE 0x00460000-00489000 \ advapi32 ELF 0x0044f000-00523000 Deferred libx11.so.6 ELF 0x0044f000-00523000 Deferred libx11.so.6 ELF 0x0044f000-00523000 Deferred libx11.so.6 PE 0x004c0000-0051e000 Deferred ole32 ELF 0x0052e000-00544000 Deferred msiexec<elf> \-PE 0x00530000-00544000 \ msiexec ELF 0x00544000-005c2000 Deferred gdi32<elf> \-PE 0x00560000-005c2000 \ gdi32 ELF 0x005d9000-0064b000 Stabs ntdll<elf> \-PE 0x005f0000-0064b000 \ ntdll \-PE 0x005f0000-0064b000 \ ntdll \-PE 0x005f0000-0064b000 \ ntdll ELF 0x00628000-00690000 Deferred libfreetype.so.6 ELF 0x0064b000-00655000 Deferred libgcc_s.so.1 ELF 0x00751000-00860000 Deferred user32<elf> \-PE 0x00770000-00860000 \ user32 \-PE 0x00770000-00860000 \ user32 ELF 0x00860000-008a7000 Deferred rpcrt4<elf> \-PE 0x00880000-008a7000 \ rpcrt4 ELF 0x008a7000-0094e000 Deferred comctl32<elf> \-PE 0x008c0000-0094e000 \ comctl32 \-PE 0x008c0000-0094e000 \ comctl32 \-PE 0x008c0000-0094e000 \ comctl32 ELF 0x00952000-0095a000 Deferred libxrender.so.1 ELF 0x0095c000-00960000 Deferred libxrandr.so.2 ELF 0x009b9000-009cd000 Deferred lz32<elf> \-PE 0x009c0000-009cd000 \ lz32 ELF 0x009d1000-009dc000 Deferred libnss_files.so.2 ELF 0x00a25000-00a44000 Deferred ximcp.so.2 ELF 0x00a46000-00a6e000 Deferred cabinet<elf> \-PE 0x00a50000-00a6e000 \ cabinet \-PE 0x00a50000-00a6e000 \ cabinet ELF 0x00a57000-00ad2000 Deferred libgl.so.1 PE 0x00a90000-00af4000 Deferred oleaut32 ELF 0x00afc000-00bf6000 Stabs kernel32<elf> \-PE 0x00b20000-00bf6000 \ kernel32 \-PE 0x00b20000-00bf6000 \ kernel32 ELF 0x00bf6000-00c70000 Deferred winex11.drv<elf> \-PE 0x00c10000-00c70000 \ winex11.drv ELF 0x00c70000-00c8c000 Deferred imm32<elf> \-PE 0x00c80000-00c8c000 \ imm32 ELF 0x00c8c000-00cca000 Deferred riched20<elf> \-PE 0x00ca0000-00cca000 \ riched20 PE 0x00cf0000-00d0d000 Deferred msi1450.tmp ELF 0x00d24000-00d29000 Deferred libxxf86vm.so.1 ELF 0x00d35000-00d4f000 Deferred libice.so.6 ELF 0x00d66000-00d70000 Deferred libxcursor.so.1 ELF 0x00e0d000-00e2d000 Deferred iphlpapi<elf> \-PE 0x00e20000-00e2d000 \ iphlpapi ELF 0x00f01000-010ee000 Deferred mga_dri.so PE 0x10000000-1001d000 Deferred msi144a.tmp ELF 0x57908000-57963000 Deferred winedos<elf> \-PE 0x57910000-57963000 \ winedos ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000e 0000002e 0 0000000a (D) C:\windows\system\msiexec.exe 0000002b 0 0000000e 0000002a 0 0000000a (D) C:\windows\system\msiexec.exe 00000023 0 0000000e 00000020 0 0000000a (D) C:\windows\system\msiexec.exe 0000001f 0 0000001e 0 0000000e 0000001d 0 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 0000000a (D) C:\windows\system\msiexec.exe 0000000d 0 0000000c 0 <== 0000000b 0 WineDbg terminated on pid 0xa err:ole:xCall RpcChannelBuffer SendReceive failed, 800706c0 fixme:ole:RpcChannelBuffer_GetDestCtx (0x19445794,0x19445798), stub! wine: Unhandled exception (thread 000f), starting debugger... WineDbg starting on pid 0xe Unhandled exception: page fault on read access to 0x00000024 in 32-bit code (0x7ce87d20). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7ce87d20 ESP:7fdcf38c EBP:7fdcf3e0 EFLAGS:00210206( - 00 - RIP1) EAX:00000024 EBX:00000000 ECX:00000000 EDX:7ce87e88 ESI:7be9f330 EDI:7fdcf3d0 Stack dump: 0x7fdcf38c: 00451111 7be9f330 00000000 00000000 0x7fdcf39c: 00000000 00000000 7d4a5040 00496030 0x7fdcf3ac: 0044ffe0 7be9f330 00496030 7fdcf3d0 0x7fdcf3bc: 0082928c 7d4a5040 00000000 00000000 0x7fdcf3cc: 7fdcf3ec 00000000 7fdcfc48 00478ee4 0x7fdcf3dc: 00000001 7fdcfc54 0045374d 7fdcfc64 0200: sel=1007 base=7befe000 limit=00001f97 32-bit rw- Backtrace: =>1 0x7ce87d20 (0x7fdcf3e0) 2 0x0045374d in idriver (+0x5374d) (0x7fdcfc54) 3 0x006da18e _invoke+0x16e(func=0x453337, callconv=0x4, nrargs=0x3, args=0x7ce8a190) [/usr/src/wine-cvs/wine/dlls/oleaut32/typelib.c:4480] in oleaut32 (0x7fdcfc7c) 4 0x006d890f TMStubImpl_Invoke+0x5a3(iface=0x7be9e640, xmsg=0x7ce8c340, rpcchanbuf=0x0) [/usr/src/wine-cvs/wine/dlls/oleaut32/tmarshal.c:2145] in oleaut32 (0x7fdcfd58) 5 0x0028091f RPC_ExecuteCall+0x23(params=0x7ce8a6a8) [/usr/src/wine-cvs/wine/dlls/ole32/rpc.c:439] in ole32 (0x7fdcfd78) 6 0x00262de2 apartment_wndproc+0x3a(hWnd=0x2002e, msg=0x400, wParam=0x0, lParam=0x7ce8a6a8) [/usr/src/wine-cvs/wine/dlls/ole32/compobj.c:426] in ole32 (0x7fdcfd88) 7 0x0056e5ef WINPROC_wrapper+0x17 in user32 (0x7fdcfdac) 8 0x0056f003 WINPROC_CallWndProc+0x57(wParam=0x0, lParam=0x7ce8a6a8) [/usr/src/wine-cvs/wine/dlls/user/winproc.c:415] in user32 (0x7fdcfddc) 9 0x00571e1c CallWindowProcA+0x180(func=0x5cde48, hwnd=0x2002e, msg=0x400, wParam=0x0, lParam=0x7ce8a6a8) [/usr/src/wine-cvs/wine/dlls/user/winproc.c:2958] in user32 (0x7fdcfe04) 10 0x00548fc3 DispatchMessageA+0x127(msg=0x7fdcfe60) [/usr/src/wine-cvs/wine/dlls/user/message.c:2910] in user32 (0x7fdcfe48) 11 0x00449ac3 in idriver (+0x49ac3) (0x7fdcfea0) 12 0x00467bd8 EntryPoint+0xe0 in idriver (0x7fdcff2c) 13 0x00818012 start_process+0xb6(arg=0x0) [/usr/src/wine-cvs/wine/dlls/kernel/process.c:996] in kernel32 (0x7fdcfff4) 14 0x00ce3939 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7ce87d20: addb 0x0(%eax),%al Modules: Module Address Debug info Name (78 modules) ELF 0x0014b000-00192000 Deferred rpcrt4<elf> \-PE 0x00160000-00192000 \ rpcrt4 ELF 0x00192000-001b2000 Deferred iphlpapi<elf> \-PE 0x001a0000-001b2000 \ iphlpapi ELF 0x001b2000-00230000 Deferred gdi32<elf> \-PE 0x001d0000-00230000 \ gdi32 ELF 0x00230000-002ac000 Stabs ole32<elf> \-PE 0x00250000-002ac000 \ ole32 ELF 0x002b0000-002cc000 Deferred ld-linux.so.2 ELF 0x002cc000-002ce000 Deferred xlcutf8load.so.2 ELF 0x002ce000-003f8000 Deferred libc.so.6 ELF 0x003fa000-0041e000 Deferred libm.so.6 PE 0x00400000-004cf000 Export idriver PE 0x00400000-004cf000 Export idriver PE 0x00400000-004cf000 Export idriver PE 0x00400000-004cf000 Export idriver ELF 0x0044f000-00523000 Export libx11.so.6 PE 0x004f0000-005de000 DIA user32 ELF 0x005de000-00695000 Deferred shell32<elf> \-PE 0x00600000-00695000 \ shell32 \-PE 0x00600000-00695000 \ shell32 \-PE 0x00600000-00695000 \ shell32 ELF 0x00695000-0071b000 Stabs oleaut32<elf> \-PE 0x006b0000-0071b000 \ oleaut32 ELF 0x0071b000-00786000 Deferred msi<elf> \-PE 0x00730000-00786000 \ msi ELF 0x00786000-007ae000 Deferred cabinet<elf> \-PE 0x00790000-007ae000 \ cabinet \-PE 0x00790000-007ae000 \ cabinet ELF 0x00795000-007bf000 Export libfontconfig.so.1 PE 0x007d0000-008a8000 DIA kernel32 ELF 0x008a8000-008c2000 Deferred version<elf> \-PE 0x008b0000-008c2000 \ version ELF 0x008dd000-009d2000 Deferred libwine_unicode.so.1 ELF 0x00936000-00945000 Deferred libxext.so.6 ELF 0x00947000-00950000 Deferred libsm.so.6 ELF 0x00952000-0095a000 Deferred libxrender.so.1 ELF 0x0095c000-00960000 Deferred libxrandr.so.2 ELF 0x00a30000-00a44000 Deferred lz32<elf> \-PE 0x00a40000-00a44000 \ lz32 ELF 0x00a57000-00ad2000 Deferred libgl.so.1 ELF 0x00a57000-00ad2000 Deferred libgl.so.1 ELF 0x00a5e000-00a7d000 Deferred ximcp.so.2 ELF 0x00afd000-00b19000 Deferred imm32<elf> \-PE 0x00b10000-00b19000 \ imm32 ELF 0x00b19000-00b57000 Deferred riched20<elf> \-PE 0x00b30000-00b57000 \ riched20 ELF 0x00b62000-00c09000 Deferred comctl32<elf> \-PE 0x00b70000-00c09000 \ comctl32 \-PE 0x00b70000-00c09000 \ comctl32 ELF 0x00c09000-00c83000 Deferred winex11.drv<elf> \-PE 0x00c20000-00c83000 \ winex11.drv ELF 0x00caa000-00cc2000 Deferred msacm.drv<elf> \-PE 0x00cb0000-00cc2000 \ msacm.drv ELF 0x00cc2000-00cd7000 Deferred midimap<elf> \-PE 0x00cd0000-00cd7000 \ midimap ELF 0x00cdf000-00cf7000 DIA libwine.so.1 ELF 0x00cf7000-00d18000 Deferred msacm32<elf> \-PE 0x00d00000-00d18000 \ msacm32 ELF 0x00d24000-00d29000 Deferred libxxf86vm.so.1 ELF 0x00d24000-00d29000 Deferred libxxf86vm.so.1 ELF 0x00d35000-00d4f000 Deferred libice.so.6 PE 0x00d40000-00d78000 Deferred shlwapi PE 0x00d40000-00d78000 Deferred shlwapi PE 0x00d90000-00d98000 Deferred objpscnv ELF 0x00d99000-00e0b000 Deferred ntdll<elf> \-PE 0x00db0000-00e0b000 \ ntdll PE 0x00e10000-00e40000 Deferred iusercnv ELF 0x00e86000-00e99000 Deferred libz.so.1 ELF 0x00f91000-00fcd000 Deferred advapi32<elf> \-PE 0x00fa0000-00fcd000 \ advapi32 ELF 0x068a7000-06920000 Deferred winmm<elf> \-PE 0x068c0000-06920000 \ winmm PE 0x10000000-10042000 Deferred iscrcnv ELF 0x4607e000-4626b000 Deferred mga_dri.so ELF 0x549ff000-54a3f000 Deferred wineoss.drv<elf> \-PE 0x54a10000-54a3f000 \ wineoss.drv ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000000e (D) C:\Program Files\Common Files\InstallShield\Driver\9\Intel 32\IDriver.exe 0000002e 0 0000001d 0 00000016 0 00000013 0 00000012 0 00000011 0 00000010 0 0000000f 0 <== WineDbg terminated on pid 0xe -HK

2 1

Re: WLDAP32: implement ldap_err2string
by Dmitry Timoshkov 29 Jul '05

29 Jul '05

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > +static const char *errorstring[] = { > + "Success", ... > +static const WCHAR error00[] = { 'S','u','c','c','e','s','s',0 }; I'd suggest to move all strings into a stringtable and load them by LoadStringA/W. That way you get internationalization for free. -- Dmitry.

3 4

Theming & code duplication
by Frank Richter 29 Jul '05

29 Jul '05

Hi, somewhat recently I sent some code to wine-patches to add button theming; if you have glanced at it, despite utilizing subclassing, code was duplicated from the button code in user. In particular, the themed button does its own state management. The reason is that upon state changes, the user32 button control does some repaints internally, ie calling the paint function directly - those can't obviously be hooked by subclassing alone. In early versions I had the themed button painted over after state-changing messages, but that causes visible flickering (since the button is first painted in "classic" style and the themed style is painted above that). The basic problem - painting that is hard to hook into - will probably also arise on other controls. There are some ideas and approaches to deal with the problem that came up (and the results from discussion with Kevin): - Ignore. Have ugly flickering. - Change the classic controls to use InvalidateRect() instead when internal painting functions are called, so painting messages can be hooked. That would deviate from native behaviour, though (and also occasionally less efficient when the control just paints some change). - Use some magic message the control sends to itself to do some painting which is then hooked. Makes things more complex, could cause compatibility issues with apps that may not handle this message and is incompatible with native. - Code duplication - e.g. in the case of buttons, do state management in the themed class as well. - Static libraries - implement the standard controls in a static library and allow for hooks to override painting (in C++ you'd use virtual methods). Both user32 and comctl32 would link against that lib, and the latter would provide alternative painting functions. Binarily equivalent to code duplication, but not that bad in the source code. For me it looks like a good compromise, though, Kevin noted that "Historically static libs have not gone over very well". I don't like the current code duplication for theming that much, but I'm a bit unsure what else could be done. Perhaps you have some comments or suggestions, and hopefully there will be some consent of what approach would be best for Wine. Thanks for reading, -f.r.

2 4

Re: DINPUT: Detect force feedback joysticks (FF #1)
by Alexandre Julliard 29 Jul '05

29 Jul '05

Daniel Remenak <dtremenak(a)gmail.com> writes: > 1. Configure checks for the availability of a new enough linux/input.h > to support force feedback. This pretty much means any kernel 2.6 or > kernel 2.4.x with the ff patchset found at > http://sourceforge.net/projects/libff/. Some of the structures were > changed without changing the version define, so this check is > necessary. Why do you need to check the structure since you are not using it? Shouldn't you simply do a #ifdef on the ioctl code or whatever else that you use and may not be defined? -- Alexandre Julliard julliard(a)winehq.org

3 4

Another AppDB screenshot problem...
by James Liggett 28 Jul '05

28 Jul '05

Hi, Tonight I tried to submit a shot for Palm Desktop 4.1 and it gave me this error: Unable to move screenshot from to data/screenshots/originals/781 What's going on? Thanks a lot, James Liggett

3 5

Re: KERNEL32: Re: Fix thread tests on WinME
by Saulius Krasuckas 28 Jul '05

28 Jul '05

* On Fri, 22 Jul 2005, Saulius Krasuckas wrote: > * Felix Nawothnig wrote: > > > > Tested on Wine and WinXP. I couldn't verify it on WinME since I don't > > have it but since this is quite trivial... *crosses fingers* > > Though three tests are still failing: > > | thread.c:293:not restricted, assuming consistent behaviour > | thread.c:412: Test failed: access restrictions obeyed > | thread.c:414: Test failed: access restrictions obeyed > | thread.c:488: Test failed: access restrictions obeyed Felix, I have reverted part of your patch and tested this. Reversion is doing fine on WinME -- zero failed tests. Didn't tested on XP or so. Is this acceptable? If so, feel free to submit it under own name. Or correct the code. :-) Index: dlls/kernel/tests/thread.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/thread.c,v retrieving revision 1.22 diff -p -u -r1.22 thread.c --- dlls/kernel/tests/thread.c 25 Jul 2005 11:07:54 -0000 1.22 +++ dlls/kernel/tests/thread.c 28 Jul 2005 21:55:41 -0000 @@ -409,9 +409,11 @@ static VOID test_thread_priority(void) obey_ar(SetThreadPriority(access_thread,1)==0); obey_ar(GetThreadPriority(access_thread)==THREAD_PRIORITY_ERROR_RETURN); if (pSetThreadPriorityBoost) - obey_ar(pSetThreadPriorityBoost(access_thread,1)==0); + ok(pSetThreadPriorityBoost(access_thread,1)==0, + "SetThreadPriorityBoost did not obey access restrictions\n"); if (pGetThreadPriorityBoost) - obey_ar(pGetThreadPriorityBoost(access_thread,&disabled)==0); + ok(pGetThreadPriorityBoost(access_thread,&disabled)==0, + "GetThreadPriorityBoost did not obey access restrictions\n"); obey_ar(GetExitCodeThread(access_thread,&exitCode)==0); ok(CloseHandle(access_thread),"Error Closing thread handle\n"); } @@ -485,7 +487,7 @@ static VOID test_GetThreadTimes(void) if(access_thread!=NULL) { error=GetThreadTimes(access_thread,&creationTime,&exitTime, &kernelTime,&userTime); - obey_ar(error==0); + ok(error==0, "GetThreadTimes did not obey access restrictions\n"); ok(CloseHandle(access_thread)!=0,"CloseHandle Failed\n"); } creationTime.dwLowDateTime=99; creationTime.dwHighDateTime=99;

2 1

Const Function Parameters?
by Michael Carlson 28 Jul '05

28 Jul '05

I've been doing some oprofille tests with wine running fce ultra, the 8-bit Nintendo emulator. I found that when running a rom for 60 seconds, more than 99% of the CPU utilization for winex11drv (which uses the most of all components of wine in this case) is in the same function : convert_888_to_0888_asis (in dlls/x11drv/dib_convert.c). I've also found that marking a couple of parameters of that function const (that I believe should be marked const anyways), CPU usage in that function drops measurably with oprofile. As far as I know, parameters that aren't modified in a function should be marked const anyways, to send the right hint to the compiler. Since it actually turns out to be faster too, it seems worth it to me. Here are the results from oprofile before the change: 21982 99.2012 convert_888_to_0888_asis 22078 99.1735 convert_888_to_0888_asis 22207 99.1605 convert_888_to_0888_asis 22161 99.1544 convert_888_to_0888_asis 22158 99.2253 convert_888_to_0888_asis and after: 21828 99.1731 convert_888_to_0888_asis 21769 99.2296 convert_888_to_0888_asis 21835 99.3313 convert_888_to_0888_asis 21868 99.1027 convert_888_to_0888_asis 21601 99.1508 convert_888_to_0888_asis On average, it went from 22117 (context switches I believe?) to 21780, about a 1.5% improvement. The same test was run with a script each time (run fceu with the same rom, kill it after 60 seconds). I'm assuming the percentages (the second column in this chart) don't matter much, because this function we're examining takes up an overwhelming amount of the function's CPU (> 99%), so its percentage depends largely on how many context switches other functions took up. I've taken the liberty of providing a diff that patches all the functions in this file to use const parameters where appropriate. I don't get any compiler warnings with this compiling with gcc 4.0.1. Should I submit this to wine-patches? This would be my first patch to wine (or any open-source project, period). I'd appreciate some feedback before I try for it. Thanks in advance!

5 6

More insatllers
by Oliver Stieber 28 Jul '05

28 Jul '05

Hi, The axis and allies 2 demo installer requires native ole to install. (http://www.atari.com.au/games/downloads.do?id=24) On the up side, The bards Tale and Juiced demos now install more-or-less correctly. The Bards Tale uses a WISE + MSI installer and has some problems with labels being prefixes with things like {Arial_80} which is a little annoying.(http://www.download.com/The-Bard-s-Tale-updated-demo/3000-8024_4-… Juiced has some problems with bitmaps in the installer. (http://www.download.com/Juiced-final-demo/3000-7534_4-10302658.html?tag=lst…) ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

1 0

Use Gecko to render HTML
by Jacek Caban 28 Jul '05

28 Jul '05

Hello. I've sent a patch that makes MSHTML use Gecko to render HTML. Unfortunately, it uses Windows Gecko, not Linux one. Alexandre wrote me that it's impossible to get perfect support for XEmbed container, so, although my implementation was enough for Gecko, it can't go to CVS and I should use Windows one. So, as of now, support for the Linux version went into trash and I've sent this patch. Well, I don't give up with Linux version, I have an other idea, but that's not for the nearest future. One plus is that the Windows version is much simpler... Now it's time to write about this patch. For now it can use Gecko installed with Mozilla Suite or Mozilla ActiveX Control - it could use any Gecko-based product, but we have to be able to search for it (every Gecko-based product has its own registry settings for Gecko path). I'm planning to add Firefox support, but it doesn't work yet and I have to find why. If you think there should be support for any other application, please let me know. As our shdocvw still uses Mozilla ActiveX Control, I think it should be preferred (it's the first one on the search list and it's smallest). In future, when we'll implement shdocvw on top on MSHTML and get rid of Mozilla ActiveX Control dependency, I think it will be better to have a package like wine-gecko with an installer, downloaded automatically when needed (well, not automatically in MS sens, user will be informed about it ;-) ). We need a very limited version of Gecko, so it will be just small package. What does this patch change? You may see IE working on Gecko engine! Not much of its functionality is implemented yet, but a HTML document is displayed. Soon there will be more! To see how it works for your program, probably you will have to set shdocvw to native (and usually urlmon, maybe wininet) and mshtml as builtin. Thanks, Jacek

1 0

[WINEHQ] Lots of buggy < and >
by Francois Gouget 28 Jul '05

28 Jul '05

Reading WWN 284 I noticed the following line: > stabilizing for release &. And sure enough the source XML is buggy: > stabilizing for release &<g&>. I believe the intent was the following to deal with the double parsing: > stabilizing for release &lt;g&gt;. But really this double parsing is a major pain. Can't we get rid of it? Because it's causing a lot of bugs: $ egrep "<.*>" wwn/*.sgml | grep -v "who=" | wc -l 190 And it's not just missing grins either. For instance in WWN 125: > gdb <gdb remote protocol> winedbg <Win32 debug API> wineserver and all the reader sees is: > gdb winedbg wineserver which is totally wrong of course. And in WWN 149: > #include <comcat.h> <br /> > #include <oaidl.h><br /> > #include <objbase.h><br /> > #include <objidl.h><br /> ... all the reader sees is: > #include > #include > #include > #include ... Not very informative! -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

2 1

Re: patch for libs/wine/mmap.c making wine running on FreeBSD 5.x
by Alexandre Julliard 28 Jul '05

28 Jul '05

"jean-marc DETREZ" <jm.detrez(a)cegetel.net> writes: > I made a little correction of "try_mmap_fixed" because it's seems to me > that the function didn't really test the result (vec). That's the way it should be, we don't care if the page is in core or not, we only want to know if something is mapped there. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [wined3d] repack nonpower2 textures
by Lionel Ulmer 28 Jul '05

28 Jul '05

On Thu, Jul 28, 2005 at 01:13:02PM +0100, Oliver Stieber wrote: > repacking can be quite CPU intensive and warhammer 40k is the only game so far > that needs nonpower2 texture repacking so it's turned off by default but can be turned > on via the following registry key: > HKEY_CURRENT_USER/Software/Wine/Direct3D Nonpower2Mode [repack] Is there a way to automagically detect the need for this feature ? If not, how are we going to maintain the list of 'game-specific' WineD3D configurations ? Should we ship this as part of 'wine.inf' or create a new .inf that would install automatically the correct keys ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Process Explorer and 16-bit windows applications
by Paul Vriens 28 Jul '05

28 Jul '05

Hi, I've reported before that I still had an issue with the version of 16bit windows applications (and hence 16bit resource) reported by Process Explorer. I've emailed the developer about this. His answer: On Thu, 2005-07-21 at 00:20, Mark Russinovich wrote: > Hi Paul, > > I make no effort to support 16-bit programs in Process Explorer. On Windows > NT-based OSes the run within Ntvdm.exe processes and not as "real" > processes. > > -Mark So there was no issue after all. All other version information tools I've used so far, show the correct versions for both win16 and win32 resources. Just to let you know (if you're interested at all in this :-) ) Cheers, Paul.

1 0

Re: ntdll: Try2: Fix IOCTL_SCSI_GET_ADDRESS and HKLM\HARDWARE\DEVICEMAP\Scsi entries
by Alexandre Julliard 28 Jul '05

28 Jul '05

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > @@ -235,14 +249,18 @@ static void create_hardware_branch(void) > int i; > HANDLE handle; > char drive[] = "\\\\.\\A:"; > + char drive1[] = "A:\\"; > + UINT uNumber = 0; > > /* create entries for cdroms (skipping A: and B:) */ > for (i = 2; i < 26; i++) > { > drive[4] = 'A' + i; > + drive1[0] = 'A' + i; > + if (GetDriveTypeA(drive1) != DRIVE_CDROM) continue; > handle = CreateFileA( drive, 0, 0, NULL, OPEN_EXISTING, 0, 0 ); > if (handle == INVALID_HANDLE_VALUE) continue; You shouldn't use GetDriveType here, you should determine the device type from the ioctls you do on the handle. The GetDriveType result doesn't necessarily correspond to the device since it can be changed in the registry. -- Alexandre Julliard julliard(a)winehq.org

1 0

winecfg in 640x480
by Oliver Stieber 28 Jul '05

28 Jul '05

I know this isn't going to be too big an issue with many people but it would be nice if winecfg was usable with a 640x480 desktop, at the moment it's 20 or so pixels to tall and you can't see the ok/cancel buttons. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 1

Wine compatibility sponsoring
by Christian Siegert 28 Jul '05

28 Jul '05

Hi *, although I am not quite sure if this is the right list for my question, I will try it anyway as I did not find a better list (e.g. jobs)... Being a software development company with limited wine know-how, we are would like to request if there is any interest at any of the developers around to assist us in a wine-customization related project. For one of our customers, we will have to customize a wine system to support a special windows application (a rather complex one from the finance sector) which is currently not *fully* supported (This is the results of recent tests with standard-wine). The results of this special cutomization will be GPLed again, so this could be integrated in the next wine release if wanted by the project. The project will be split in three phases: - Testing of earlier results of wine/application interaction in cooperation with our customer - Modification of wine - Packaging to single launchable application Payment will be subject of negotiation. Anyone of the developers who is interested should contact me directly via phone or mail. -- Viele Grueße / Best regards, Christian Siegert Geschaeftsfuehrer / Executive director ___________________________________________________ Open Source Factory GmbH Stefan-George-Ring 8 81929 Muenchen GERMANY Tel.: +49 (0)89 99 34 13-50 Fax: +49 (0)89 99 34 13-69 E-Mail: info(a)opensourcefactory.com www: http://www.opensourcefactory.com

1 0

Re: Fix Using DDraw to Access the Desktop
by Alexandre Julliard 28 Jul '05

28 Jul '05

Robert Shearman <rob(a)codeweavers.com> writes: > Previously, using ddraw to write to a small area of the desktop (or > even none at all) would cause the screen to go black because the > contents of the screen wasn't copied to the surface before the surface > was copied back to the screen. This patch fixes that. Of course it's still corrupting the screen, it's just less obvious... -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: Try 2:Implement IOCTL_SCSI_GET_INQUIRY_DATA
by Dmitry Timoshkov 28 Jul '05

28 Jul '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > Check for HAVE_SG_IO_HDR_T_INTERFACE_ID instead of defined Linux > +static NTSTATUS GetInquiryData(int fd, PSCSI_ADAPTER_BUS_INFO BufferOut, DWORD OutBufferSize) > +{ > + PSCSI_INQUIRY_DATA inquirydata = NULL; > + sg_io_hdr_t iocmd; ^^^^^^^^^^^^^^^^^ > + UCHAR inquiry[INQ_CMD_LEN] = {INQUIRY, 0, 0, 0, INQ_REPLY_LEN, 0}; > + UCHAR sense_buffer[32]; > + struct hd_driveid; > + int iochk, version; > + > +#ifdef HAVE_SG_IO_HDR_T_INTERFACE_ID > + /* Check we have a SCSI device and a supported driver */ > + if(ioctl(fd, SG_GET_VERSION_NUM, &version) != 0) This won't compile if sg_io_hdr_t doesn't present. Underlined structure declaration needs to be protected as well. Just add '#undef HAVE_SG_IO_HDR_T_INTERFACE_ID' after config.h include and try to compile. -- Dmitry.

1 0

Version
by jstrupeni 28 Jul '05

28 Jul '05

Hello, I'm using a Novell Linux Desktop Version 9 and I don't know which version of Wine I should install. Thank you very much in advance, Juan

2 1

Re: patch for libs/wine/mmap.c making wine running on FreeBSD 5.x
by Dmitry Timoshkov 28 Jul '05

28 Jul '05

"jean-marc DETREZ" <jm.detrez(a)cegetel.net> wrote: > @@ -207,6 +207,13 @@ void *wine_anon_mmap( void *start, size_ > #elif defined(__svr4__) || defined(__NetBSD__) || defined(__APPLE__) > if ( try_mmap_fixed( start, size, prot, flags, fdzero, 0 ) ) > return start; > +#elif defined(__FreeBSD__) > + /*for FreeBSD assure system heap adress of 0x80000000*/ > + if (start == (void *)0x80000000) > + { > + if (try_mmap_fixed( start, size, prot, flags, fdzero, 0 ) ) > + return start; > + } > #endif > } > return mmap( start, size, prot, flags, fdzero, 0 ); Why didn't you simply add __FreeBSD__ to the '#elif defined(__svr4__) || defined(__NetBSD__) || defined(__APPLE__)' case? -- Dmitry.

1 0

Re: Implement IOCTL_SCSI_GET_INQUIRY_DATA
by Dmitry Timoshkov 28 Jul '05

28 Jul '05

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> wrote: > +static NTSTATUS GetInquiryData(int fd, PSCSI_ADAPTER_BUS_INFO BufferOut, DWORD OutBufferSize) > +{ > + PSCSI_INQUIRY_DATA inquirydata = NULL; > + sg_io_hdr_t iocmd; > + UCHAR inquiry[INQ_CMD_LEN] = {INQUIRY, 0, 0, 0, INQ_REPLY_LEN, 0}; > + UCHAR sense_buffer[32]; > + struct hd_driveid; > + int iochk, version; > + > +#if defined(linux) > + /* Check we have a SCSI device and a supported driver */ Please use appropriate configure checks instead of a blind '#if defined(linux)'. -- Dmitry.

1 0

Re: [wined3d] support get vertexdeclaration with pnumelements set to zero
by Oliver Stieber 27 Jul '05

27 Jul '05

With the patch this time --- Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > Hi, > This patch returns all elements when getDeclaration is called with > pnumelements set to 0. This fixes bugs in Teeage mutant ninja turtles and The > Increadibles. > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail > http://uk.messenger.yahoo.com > > ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

2 1

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 July 2005