January 2006 - wine-devel

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

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 January 2006