July 2008 - Wine-Devel - list.winehq.org

re: xinput implementation

by Dan Kegel

chourmovs wrote: > I'd like to participate to wine improvement instead of > always requesting for new features > > ... xinput support lack for new games and its > implementation is maybe not the hardest thing to do Please start by writing conformance tests. See http://www.winehq.org/site/docs/winedev-guide/testing - Dan

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Aric Stewart

Yes, I have verified those vkeys in windows. the VK_OEM_* keys are specificaly VK codes that vary from keyboard to keyboard. VK_OEM_3 is just one example. -aric Vitaliy Margolen wrote: > Aric Stewart wrote: >> vkey codes similarly do not produce a clean 1 to 1 correspondance. >> the '@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' >> key on the us keyboard. > This is needs to be fixed in x11drv then. Not in dinput. Have you > verified what v_keys you getting from windows for these keys? > > Vitaliy. >

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Vitaliy Margolen

Aric Stewart wrote: > vkey codes similarly do not produce a clean 1 to 1 correspondance. the > '@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' key on > the us keyboard. This is needs to be fixed in x11drv then. Not in dinput. Have you verified what v_keys you getting from windows for these keys? Vitaliy.

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Michael Karcher

Am Donnerstag, den 31.07.2008, 08:53 +0200 schrieb Michael Karcher: > SDL uses something like the DIK codes seem to be with their SDLK > constants. Argl! That sentence sense no make does. I meant to say: "SDL's SDLK_* constants seem to be conceptually what Window's DIK_* are." Regards, Michael Karcher

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Aric Stewart

Yes this is a specific problem I am seeing. In a Japanese online Mahjong game, there appears to be no way to remap the keys and the game is using the top 2 rows of the keyboard to control the movement of the tiles in the game. the top row scan codes for a japanese keyboard are: 1 2 3 4 5 6 7 8 9 0 - ^ \ 0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x29, second row q w e r t y u i o p @ [ 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B Notice how 0x0C (-) 0x0d(^) 0x1A(@) and 0x1B([) have scan codes that do not correspnd to the character on the qwerty keyboard. This means with the current code if the user presses the key to the right of 'P' it generates a DIK_LBRACKET which is actaully they key two to the right, so the wrong tile gets highlighted. The program is looking for DIK_AT for that key. vkey codes similarly do not produce a clean 1 to 1 correspondance. the '@' key (0x1a) is vkey (VK_OEM_3) which is the vkey of the '`' key on the us keyboard. So I am seeing a real world problematic behavior in wine that I am trying to correct. Your presumption that ALL programs let the user remap their keys seem overly broad. I like Michael's idea of initializing this lookup array on initialization of the keyboard. Then we only have to worry about it if the user switches keyboard layouts mid program and since last i looked wine does not support that anyway we would be ok. If i built the lookup table at that point would you have any objection to that? -aric Michael Karcher wrote: > Am Mittwoch, den 30.07.2008, 18:12 -0600 schrieb Vitaliy Margolen: > Disclaimer: I didn't thoroughly read the thread, but if I understood > the problem area correctly, the following comments apply: > >> And even if Wine returns different DIKs on different keyboard layouts for >> some questionable keys. Why is it a problem? In all the programs and games >> I've seen one can remap their keys to whatever they want. > It is a problem, because Wine should be compatible to Windows. Also, I > wouldn't understand why the key containing minus and underscore would be > called "slash" in the game. > >> The reason I'm so against adding extra X calls - it dramatically affects >> latency of the input. We already have horrid latency with mouse. All because >> thread that talks to X is busy doing other things. > Thats why you should not look up what DIK code to use on each key event, > but once on DirectInput initialization you should create a map from vkey > do DIK. SDL uses something like the DIK codes seem to be with their SDLK > constants. As SDL is also LGPL one might take a look into SDL how it is > implemented there. > > Regards, > Michael Karcher > >

July 31, 2008

Re: [resent] Fix some hackish usages of WideCharToMultiByte

by Alexandre Julliard

"Colin Finck" <mail(a)colinfinck.de> writes: > @@ -947,7 +947,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const CREDENTIALW *CredentialW, > if (CredentialW->TargetName) > { > CredentialA->TargetName = buffer; > - string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, -1, NULL, NULL); > + /* Buffer is guaranteed to be large enough */ > + string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, 0x7FFFFFFF, NULL, NULL); It would be cleaner to pass the actual buffer size to the function, it's complex enough that it would be easy to inadvertently break the guarantee that the allocated space is large enough. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2008

Re: shdocvw(2/2): rudimentary implementation of CLSID_InternetShortcut (try 3)

by Alexandre Julliard

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > +static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out) > +{ The usual pattern is to return the new pointer, not an HRESULT. The only possible error is E_OUTOFMEMORY anyway. > +static HRESULT WINAPI UniformResourceLocatorA_SetUrl(IUniformResourceLocatorA *url, LPCSTR pcszURL, DWORD dwInFlags) > +{ > + HRESULT hr; > + LPWSTR wideURL; > + InternetShortcut *This = impl_from_IUniformResourceLocatorA(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_a(pcszURL), dwInFlags); > + hr = strdupAtoW(pcszURL, &wideURL); > + if (SUCCEEDED(hr)) > + { > + hr = This->uniformResourceLocatorW.lpVtbl->SetURL(&This->uniformResourceLocatorW, wideURL, dwInFlags); In general you shouldn't access lpVtbl. You should either use the COM macros, or if you know the target function like in this case, call it directly. Here it would be even better to not call anything and simply store the pointer to avoid duplicating the string twice. > +static HRESULT WINAPI UniformResourceLocatorW_SetUrl(IUniformResourceLocatorW *url, LPCWSTR pcszURL, DWORD dwInFlags) > +{ > + InternetShortcut *This = impl_from_IUniformResourceLocatorW(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_w(pcszURL), dwInFlags); > + if (dwInFlags != 0) > + FIXME("ignoring unsupported flags 0x%x\n", dwInFlags); > + This->isDirty = TRUE; > + HeapFree(GetProcessHeap(), 0, This->url); > + if (pcszURL == NULL) > + This->url = NULL; > + else > + { > + This->url = heap_strdupW(pcszURL); > + if (This->url == NULL) > + return E_OUTOFMEMORY; You should preserve the old value on error. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2008

Re: [resent] [WideChar conversion improvements - 5/5] Add a lot of WideCharToMultiByte tests

by Jeff Latimer

Colin Finck wrote: > Add a lot of new tests for the actual WideCharToMultiByte string > conversion as well. Are you planning to move on to MultiByteToWideChar tests? I was planning on adding a few and don't want to get into your way. Jeff

July 31, 2008

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path. (try 2)

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > @@ -143,9 +143,9 @@ HKCR,lnkfile\CLSID,,2,"{00021401-0000-0000-C000-000000000046}" > HKCR,lnkfile\shellex\IconHandler,,2,"{00021401-0000-0000-C000-000000000046}" > HKCR,lnkfile\shellex\ContextMenuHandlers\{00021401-0000-0000-C000-000000000046},,0x10, > HKCR,Msi.Package\DefaultIcon,,2,"msiexec.exe" > -HKCR,Msi.Package\shell\Open\command,,2,"msiexec /i ""%1""" > -HKCR,Msi.Package\shell\Repair\command,,2,"msiexec /f ""%1""" > -HKCR,Msi.Package\shell\Uninstall\command,,2,"msiexec /x ""%1""" > +HKCR,Msi.Package\shell\Open\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /i ""%1"" %*" > +HKCR,Msi.Package\shell\Repair\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /f ""%1"" %*" > +HKCR,Msi.Package\shell\Uninstall\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /x ""%1"" %*" You should be using %11% instead of hardcoding system32, but it shouldn't make any difference either way. Why do you need to change this? -- Alexandre Julliard julliard(a)winehq.org

July 31, 2008

Re: ole32: don't crash when running the marshal tests on Vista.

by Reece Dunn

2008/7/31 Rob Shearman <robertshearman(a)gmail.com>: > 2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: >> When running the ole32:marshal tests on Vista, the call to >> CoUnmarshalInterface fails. This results in pProxy being NULL which >> then causes the crash on the QueryInterface call. >> >> This patch makes sure that the pProxy-dependant tests are only called >> when pProxy is valid. > > We need to work out why the test is failing - possibly it requires > more implementation of the object we are marshalling than in previous > versions of Windows. Looking at this in more detail, from (http://test.winehq.org/data/daafda22f840edc9a584abc7925f9ee17ef18228/vista_…) marshal.c:2337: Test failed: "CoUnmarshalInterface" failed with error 0x80040154 marshal.c:2340: Test failed: Number of locks should be > 0, but actually is 0 test failed: timed out on my current setup, I get the first two, but the test crashes. This may be because I have SP1 installed which makes it like the 2008 results in most cases. This is backed up by the results at http://test.winehq.org/data/a0289148e14728e45587b8cb17f90862d8400939/, where there are Vista, Vista SP1 and 2008 test results. NOTE: 0x80040154 is "class no registered", so I suspect that this is due to the IWineTest interface not being registered. > Also, the typical way of detecting failure in our COM code in Wine is > to check the return value rather than whether a output object is NULL > or not. The test_marshal_and_unmarshal_invalid test in marshal.c has a similar check (line 405), so there is already a presedence for this. - Reece

July 31, 2008