July 2007 - Wine-devel - list.winehq.org

ntdll: add bolivian time zone info
by Lei Zhang 30 Jul '07

30 Jul '07

Hi, A user requested this in bug 9083.

1 1

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
by Vitaliy Margolen 29 Jul '07

29 Jul '07

Peter Dons Tychsen wrote: > On Sun, 2007-07-29 at 13:40 -0600, Vitaliy Margolen wrote: >> Peter Dons Tychsen wrote: >>> On Sun, 2007-07-29 at 11:15 -0600, Vitaliy Margolen wrote: >>> I have re-sent the patch with all your remarks fixed, except for the one >>> regarding joystick_linuxinput.c, which cannot be done with the current >>> code as alloc_device() is too different in the two versions for the >>> patch to work. I have however made sure that the version in >>> joystick_linuxinput.c does not have this problem. >>> >> Why do you think they are so different? Looks almost the same to me. >> Few more things to fix: > They are almost the same... but different for exactly the thing i am > changing. Notice the difference in the way the device is found. > One implementation uses Data3 to look it up, the other loops through all > devices and compares with the GUID. Well yeah, but the way they identifying which device is which is about the same. If you look at the find_joydevs() you'll see what it's doing with that giud.Data3 field. So you need to pick which way you want to do it (the way it's done in joystick_linux.c or joystick_linuxinput.c). And modify the other one accordingly. I don't like iterating over the whole array, and doing whole GIUD comparison, when you can get the index (the way you have it). Just make sure it doesn't overflow >>> -#undef MAX_JOYSTICKS >> You removed this, but you haven't added it back. > Why? I removed it so the rest of the file could use it. > I don't understand why it was undef'ed to begin with. > Probably a copy/paste remnant. There is no reason to keep it. It usually a good idea to undef anything that you no longer need. Otherwise it stays around for some time and might cause some problems in the future. > What things should i change for the re-submit? Don't send the same patch more the 3 times. Alexandre doesn't like it ;-) You should work out all the problems then resubmit. You can send patches to wine-devel for review in the main time. Vitaliy.

1 0

[msi] Is there a potential problem with squash_guid in msi/registry.c ?
by Paul Vriens 29 Jul '07

29 Jul '07

Hi, I'm still looking into the fact why the msi.c tests fails for me (and succeeds when running with WINEDEBUG=+msi). A trace (+msi,+reg,+ole) revealed: trace:msi:MsiQueryProductStateW L"A938G02JF-2NF3N93-VN3-2NNF-3KGKALDNF93" trace:msi:MSIREG_OpenUserProductsKey L"A938G02JF-2NF3N93-VN3-2NNF-3KGKALDNF93" trace:reg:NtOpenKey (0x48,L"A938G02JF-2NF3N93-VN3-2NNF-3KGKALDNF93\\CLSID",f003f,0x34f37c) trace:reg:NtOpenKey <- (nil) warn:ole:CLSIDFromProgID couldn't open key for ProgID L"A938G02JF-2NF3N93-VN3-2NNF-3KGKALDNF93" trace:msi:squash_guid Returning FALSE trace:msi:MSIREG_OpenUserProductsKey squished (L"\7bc9\0480\0011\f8c84\2f47\7bc3\c7ea\7ecd\f9204\7139\7ecf\c89a\7ecd\00ff") (the 'Returning FALSE' is my doing). The squished_pc variable in MSIREG_OpenUserProductsKey is filled with garbage. I think that we should patch msi/registry.c: diff --git a/dlls/msi/registry.c b/dlls/msi/registry.c index b9c0af4..24a3def 100644 --- a/dlls/msi/registry.c +++ b/dlls/msi/registry.c @@ -233,6 +233,8 @@ BOOL squash_guid(LPCWSTR in, LPWSTR out) DWORD i,n=1; GUID guid; + out[0] = 0; + if (FAILED(CLSIDFromString((LPOLESTR)in, &guid))) return FALSE; So 'out' is always clean at the start. Adding this patch makes the test fail consistently :-). So it's not the fix. Any comments/remarks/suggestions ? Cheers, Paul.

1 1

Re: wine3d3: Check the destination recangle when for FastBlt().
by Vitaliy Margolen 29 Jul '07

29 Jul '07

Peter Dons Tychsen wrote: > Hello Wine! > > I have fixed a small bug in FastBlt(), which caused Wine to crash if the > application tried to do FastBlt() to a surface using a bad destination > setup. The problem is already fixed in normal Blt(), but was broken for > FastBlt(). > > This fixes a crash for the little game "Treasure Mole Winter Vacations": > > http://www.alawar.com/games/treasuremolewv/ > > The game is now fully playable. > > /Pedro > > > + if (((lock_dst.bottom > This->currentDesc.Height) || (lock_dst.bottom < 0) || > + (lock_dst.top > This->currentDesc.Height) || (lock_dst.top < 0) || > + (lock_dst.left > This->currentDesc.Width) || (lock_dst.left < 0) || > + (lock_dst.right > This->currentDesc.Width) || (lock_dst.right < 0) || > + (lock_dst.right < lock_dst.left) || (lock_dst.bottom < lock_dst.top))) This check doesn't look right to me. Something like this should be much closer and much easier to read and understand. Also it doesn't have any redundant checks: + if (IsRectEmpty(&lock_dst) || + lock_dst.left >= This->currentDesc.Width || lock_dst.right < 0 || + lock_dst.bottom >= This->currentDesc.Height || lock_dst.top < 0) ">=" because you comparing coordinates against width/height. Vitaliy.

1 0

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
by Vitaliy Margolen 29 Jul '07

29 Jul '07

Peter Dons Tychsen wrote: > On Sun, 2007-07-29 at 11:15 -0600, Vitaliy Margolen wrote: >> Peter Dons Tychsen wrote: >>> Hello again Wine! >>> >>> Here is a small fix for dinput which fixes application which call >>> CreateDevice with the standard Joystick GUID instead of the GUID >>> supplied in the enumeration callback. >> The patch looks good, and I see what you trying to fix. It would be >> nice if you add some tests for this. MSDN is pretty explicit about >> what GUIDs could be used there. >> >> Few nitpicks about your patch: >> >>> -static BOOL IsJoystickGUID(REFGUID guid) >>> +/****************************************************************************** >>> + * Acquire : gets exclusive control of the joystick >>> + */ >>> +static CHAR IsJoystickGUID(REFGUID guid) >>> { >>> >> Comment are good, but only when they are correct. Also you probably should >> rename this function to something like get_joystick_index. >> >>> + return -1; >>> } >>> >>> static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev) >>> { >>> - if ((IsEqualGUID(&GUID_Joystick,rguid)) || >>> - (IsJoystickGUID(rguid))) { >>> + CHAR index; >> Why CHAR? the Data3 defined as "unsigned short Data3;". That is what >> you really should use. BTW be careful with that "return -1;" it won't >> be < 0 for unsigned anymore. >> >>> - GUID wine_joystick = DInput_Wine_Joystick_GUID; >>> - GUID dev_guid = *guid; >>> + GUID wine_joystick = DInput_Wine_Joystick_GUID; >>> + GUID dev_guid = *guid; >> Please do not reformat the code. It should be 4-spaces indentation, not 2. >> >> And while you changing this, don't forget to change joystick_linuxinput.c as well. >> They should be kept in sync. >> >> >> Vitaliy. > > Hi Vitaliy. > > OK, thanks for the input: First of all, please bottom post on this list. We are not business. > > I have re-sent the patch with all your remarks fixed, except for the one > regarding joystick_linuxinput.c, which cannot be done with the current > code as alloc_device() is too different in the two versions for the > patch to work. I have however made sure that the version in > joystick_linuxinput.c does not have this problem. > Why do you think they are so different? Looks almost the same to me. Few more things to fix: > -#undef MAX_JOYSTICKS You removed this, but you haven't added it back. > GetJoystickIndex All the functions around that place named properly. Don't use up-casing names. I suggested using "get_joystick_index" - all lover case, with underscores. > -static HRESULT alloc_device(REFGUID rguid, const void *jvt, IDirectInputImpl *dinput, LPDIRECTINPUTDEVICEA* pdev) > +static HRESULT alloc_device(REFGUID rguid, const void *jvt, IDirectInputImpl *dinput, LPDIRECTINPUTDEVICEA* pdev, unsigned short index) This is a really long line, please make it shorter.

1 0

Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
by Vitaliy Margolen 29 Jul '07

29 Jul '07

Peter Dons Tychsen wrote: > Hello again Wine! > > Here is a small fix for dinput which fixes application which call > CreateDevice with the standard Joystick GUID instead of the GUID > supplied in the enumeration callback. The patch looks good, and I see what you trying to fix. It would be nice if you add some tests for this. MSDN is pretty explicit about what GUIDs could be used there. Few nitpicks about your patch: > -static BOOL IsJoystickGUID(REFGUID guid) > +/****************************************************************************** > + * Acquire : gets exclusive control of the joystick > + */ > +static CHAR IsJoystickGUID(REFGUID guid) > { > Comment are good, but only when they are correct. Also you probably should rename this function to something like get_joystick_index. > + return -1; > } > > static HRESULT joydev_create_deviceA(IDirectInputImpl *dinput, REFGUID rguid, REFIID riid, LPDIRECTINPUTDEVICEA* pdev) > { > - if ((IsEqualGUID(&GUID_Joystick,rguid)) || > - (IsJoystickGUID(rguid))) { > + CHAR index; Why CHAR? the Data3 defined as "unsigned short Data3;". That is what you really should use. BTW be careful with that "return -1;" it won't be < 0 for unsigned anymore. > - GUID wine_joystick = DInput_Wine_Joystick_GUID; > - GUID dev_guid = *guid; > + GUID wine_joystick = DInput_Wine_Joystick_GUID; > + GUID dev_guid = *guid; Please do not reformat the code. It should be 4-spaces indentation, not 2. And while you changing this, don't forget to change joystick_linuxinput.c as well. They should be kept in sync. Vitaliy.

1 0

Re: Usual non microsoft dlls
by Stefan Dösinger 29 Jul '07

29 Jul '07

Am Sonntag, 29. Juli 2007 11:10 schrieb Luis C. Busquets PÃ©rez: > Hello, > > There are a number of dlls which are of common us, e.g. mss32.dll or > binkw32.dll in the gaming industry. > > These are usually distributed with the game. Nevertheless, they relay in > other dlls of the system, e.g. zlib1.dll goes through msvcrt.dll to > perform its activities. > > Therefore, I propose to include in the source tree a directory for > "commonly used dlls not included in Windows" This does not sound bad, and indeed we've had a discussion about that concerning openal.dl, and we have decided that an openal thunk to Linux is a good thing. Someone started a stub which didn't make its way in because of implementation problems, but I think Chris Robinson is continueing the work on it. But in general it raises some further concernes regarding the compatiblity of the libs. E.g. if zlib1.dll takes a pathname to a file, and the game passes "C:\myfunkyfile.zip", linux zlib will complain that it can't find the file. Simmilarly, Windows apps won't find "/tmp/myextactedfile/". Other issues may occur too, depending on what the libs do. E.g. if we make a qt thunk and the application tries to retrieve the Win32 HWND from a window created with qt, it will lead to problems if we just call Linux qt. For the performance, it may help in some areas, but the linux lib is not necessarily faster. Wine does not emulate anything, Win32 code(and thus the dlls) run natively on the CPU. using zlib.dll isn't slower than zlib.so. Simmilarly msvcrt.dll isn't slower than libc.so. Implementation differences between the libs may occur, but Wine does not impose any performance impact. There are exceptions, like openal, which does not do the work on its own, but rather calls the sound hardware. A openal->dsound->alsa->hardware conversion on the fly is not as efficient as openal->alsa->hardware, or even openal->hardware. It depends on the libs wether a direct thunk to the Linux lib is possible or not. Solid understanding of the library is needed to decide if a thunk is possible and makes sense.

1 0

dinput: Regression since commit 233cd46a22d9c53e8a7a7306a88756cb78ada47a
by Maxime Bellengé 28 Jul '07

28 Jul '07

Hi, For a couple of days now, I have two mouse cursors in the game Ankh, the one from the game and the one from X. I have done a git bisect and found that the following patch is responsible for that. I hope it will help dinput developers and especially Vitaliy. Maxime 233cd46a22d9c53e8a7a7306a88756cb78ada47a is first bad commit commit 233cd46a22d9c53e8a7a7306a88756cb78ada47a Author: Vitaliy Margolen <wine-patches(a)kievinfo.com> Date: Sun Jul 15 10:38:05 2007 -0600 dinput: Use PostMessage instead of SendMessage. Remove message window. :040000 040000 84294e3b119b459f4f415ebaa9e79a693a106804 73d6ab55abf513c0fa96b685e032e6a02c6ce409 M dlls

2 1

Re: [PATCH] thread safety FIXMEs
by Stefan Dösinger 28 Jul '07

28 Jul '07

Am Samstag, 28. Juli 2007 21:17 schrieb Robert Millan: > Hi, > > After the recent fixes that implement thread safety in D3D (thanks > Stefan!), I think these FIXMEs aren't necessary. Yes, this is correct, the FIXMEs are obsolete.

1 0

Re: [PATCH] x11drv: Allow to disable focus to desktop window after last wine window looses focus.
by Vitaliy Margolen 28 Jul '07

28 Jul '07

Tomas Carnecky wrote: > This patch introduces a new registry key, "FocusDesktopWindow", that can > be used to specify whether wine should set the foreground window to the > desktop window after the last wine app looses focus. The default is > enabled (the same behavior as now). This is a bad hack. The reason I *fixed* the focus lose so Wine can grab pointer inside it's window and release it when the focus is lost. With what you proposing, it will be impossible. Then I'd like to see what would you say when Wine will not be releasing the mouse when you switch away from app? Also I don't know how many apps did you really test, but lots and lots of apps can't get the focus because they think they never lost it. Which IMHO is the reason for most bugs where input goes into terminal not Wine. > For example World of Warcraft stops sound if it finds out it lost focus and > there's currently a bug in wine that makes WoW unaware that it regained focus, > which effectively disables sound. Then you should fix this bug and not create hacks. Vitaliy

2 1