May 2011 - Wine-Devel - list.winehq.org

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]

by Adam Martinson

On 05/26/2011 06:47 AM, Huw Davies wrote: > On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: >> On 05/25/2011 12:36 PM, Adam Martinson wrote: >>> The AddRef is done in WrapDropTarget(), seems like the appropriate >>> place for it. Quite right on the rest though, thanks. >> Oops no, the window prop should be pDropTarget, not the wrapper. >> The wrapper is only used for the marshalling. > That window prop could probably go away, I only put it there because > that's what Windows does, I doubt there's an app that relies on it > though. However if it stays you do need the AddRef! > > Huw. Best to mirror Windows as close as possible. The AddRef() is done in WrapDropTarget(). On failure IDropTarget::Release() is done on the wrapper, which removes the ref on the original.

May 26, 2011

Re: ole32/ole2: Don't call IDropTarget::QueryInterface() in RegisterDragDrop(). [whitespace fixed]

by Huw Davies

On Wed, May 25, 2011 at 12:45:15PM -0500, Adam Martinson wrote: > On 05/25/2011 12:36 PM, Adam Martinson wrote: > >The AddRef is done in WrapDropTarget(), seems like the appropriate > >place for it. Quite right on the rest though, thanks. > > Oops no, the window prop should be pDropTarget, not the wrapper. > The wrapper is only used for the marshalling. That window prop could probably go away, I only put it there because that's what Windows does, I doubt there's an app that relies on it though. However if it stays you do need the AddRef! Huw.

May 26, 2011

Re: kernel32/toolhelp: PROCESSENTRY32::szExeFile is the full path in Win9x.

by Saulius Krasuckas

* On Wed, 25 May 2011, Adam Martinson wrote: > > Dragon NaturallySpeaking 7 expects this in Win98 mode. > --- > dlls/kernel32/tests/toolhelp.c | 19 +++++++++++++++- > dlls/kernel32/toolhelp.c | 48 +++++++++++++++++++++++++++++---------- > 2 files changed, 53 insertions(+), 14 deletions(-) I am not sure you do it right (now that new testing strategy is taken): * On Tue, 30 Nov 2010, Alexandre Julliard wrote: > > The value of running tests on Win9x these days is certainly > questionable. We don't try to emulate the Win9x behavior anyway, except > in a very few cases (which most likely don't have tests...) so it only > serves to document historical behavior that nobody cares about any > longer. WRT doesn't test win9x any longer, so what's the point of putting such check in the test? > --- a/dlls/kernel32/tests/toolhelp.c > +++ b/dlls/kernel32/tests/toolhelp.c ... > @@ -106,6 +108,10 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > unsigned found = 0; > int num = 0; > int childpos = -1; > + OSVERSIONINFO osver; > + > + osver.dwOSVersionInfoSize = sizeof(osver); > + pGetVersionEx(&osver); > > hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 ); > ok(hSnapshot != NULL, "Cannot create snapshot\n"); > @@ -116,10 +122,15 @@ static void test_process(DWORD curr_pid, DWORD sub_pcs_pid) > { > do > { > + TCHAR* bslash = strchr(pe.szExeFile, '\\'); > if (pe.th32ProcessID == curr_pid) found++; > if (pe.th32ProcessID == sub_pcs_pid) { childpos = num; found++; } > trace("PID=%x %s\n", pe.th32ProcessID, pe.szExeFile); > num++; > + if (osver.dwMajorVersion < 5) > + ok(bslash != NULL, "szExeFile is not a full path: %s\n", pe.szExeFile); > + else > + ok(bslash == NULL, "szExeFile is a full path: %s\n", pe.szExeFile); > } while (pProcess32Next( hSnapshot, &pe )); > } > ok(found == 2, "couldn't find self and/or sub-process in process list\n"); Now such check is pointless, IMHO. Here goes question to Alexandre: what about (testing in) such cases? S.

May 26, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Joris Huizer

On 05/26/2011 10:33 AM, Michael Mc Donnell wrote: > > I've added some more tests to see if I could make it fail. Microsoft's > UpdateSemantics is not very picky. I can't get it to return anything > but D3D_OK except for when I pass a null pointer. My implementation > follows this behavior except for two cases: it returns E_FAIL when > passing an undefined type and when the offset is not 4 byte aligned. > This is because the values are checked inside vertexdeclaration_init. > So Wine is stricter. I don't think that it is necessarily a problem > because applications that pass bogus declarations like those will > likely not work anyway. My own tests with a small interactive demo > show that in those cases the application will crash with an access > violation when it tries to re-draw the scene. > > > I don't know whether it applies here, but if I understand correctly, there have been cases before that Wine must not be stricter than Windows. Tthe reason is that a program may 'depend' on a function crashing (it having an exception caught in that case). In such a situation, Wine's version of the function not crashing would cause a code path being executed that normally never is (causing incorrect behavior even) Again I don't know whether it is relevant in this cause. HTH, Joris

May 26, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Wed, May 25, 2011 at 9:53 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Tue, May 24, 2011 at 8:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> On Tuesday 24 May 2011 19:56:06 Michael Mc Donnell wrote: >>> > *) In your first test you forgot to check the HeapAlloc result. >>> >>> Ok, I'll return E_OUTOFMEMORY in that case. >> I guess the callers will only abort the tests if NewTestContext fails, so I >> think the NULL / non-NULL return value was better. I've reverted those changes, so it's back to NULL / non-NULL. I've also moved it near the top of the file, so that other tests will be able to re-use the test context creation. >>> Should I try to make some more invalid >>> D3DVERTEXELEMENT9 arrays to see if I can provoke an error? >> I was thinking about something that would make CreateVertexDeclaration fail, >> e.g. declaring a usage+usage index twice or using an undefined type. >> dlls/d3d9/vertexdeclaration.c and dlls/wined3d/vertexdeclaration.c check for a >> few error conditions in their vertexdeclaration_init functions. Just pick one >> of them(no need to check all of them) >> But watch out that you don't open a can of worms here. Our >> CreateVertexDeclaration probably doesn't catch all error conditions. I >> recommend that you pick one it does catch, otherwise you'll have to fix >> d3d9.dll and wined3d.dll too for a small test. > > Ok thanks I'll do that. I've added some more tests to see if I could make it fail. Microsoft's UpdateSemantics is not very picky. I can't get it to return anything but D3D_OK except for when I pass a null pointer. My implementation follows this behavior except for two cases: it returns E_FAIL when passing an undefined type and when the offset is not 4 byte aligned. This is because the values are checked inside vertexdeclaration_init. So Wine is stricter. I don't think that it is necessarily a problem because applications that pass bogus declarations like those will likely not work anyway. My own tests with a small interactive demo show that in those cases the application will crash with an access violation when it tries to re-draw the scene.

May 26, 2011

Re: Tahoma Font License

by Scott Ritchie

On 05/25/2011 09:27 AM, Maarten Lankhorst wrote: > Hi mark, > > 2011/5/25 Mark Page <rombust(a)hotmail.co.uk>: >> >> I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... GNU Lesser General Public License 2.1 >> >> It would be useful to add the font to the ClanLib SDK resources (ClanLib has a zlib style license) >> >> It is not clear how a font can be licensed using LGPL, since LGPL is based around software libraries. >> >> Ideally I feel it should have a creative commons license >> >> I believe Creative commons did not exist when that font was created > tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on > Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed > in accordance with former's license. Please do not contact Bitstream > Inc. for any reason regarding this font. > > So just look up the original without contacting bitstream inc. ? > The topic of relicensing wine fonts has come up before. Usually the discussion ends with "our fonts aren't as good as you think, and you probably don't want them so don't worry about licensing." I'm not so sure it's true anymore. Symbol replacement, for instance, can actually be useful to show special characters on web pages that would otherwise come up as question marks. -Scott Ritchie

May 25, 2011

Re: extern char **environ and msvc

by Stefan Dösinger

On Wednesday 25 May 2011 23:04:02 Frank Richter wrote: > The underlying issue is probably the _CRTIMP - that's most likely > _declspec(dllimport) in MSVC. I suspected something like this, but msvc didn't want to tell me what _CRTIMP was. Either way it doesn't get me much closer to a fix.

May 25, 2011

Re: [2/2] user32: Add message test for hotkeys.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11184 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

May 25, 2011

Re: extern char **environ and msvc

by Frank Richter

On 25.05.2011 22:52, Stefan Dösinger wrote: > I'm sorry for the German, I don't know how to change this. Google finds only > other clueless people. Either way it says something like "Inconsistent DLL > binding" I believe the English translation is “inconsistent DLL linkage”. > > The line in stdlib.h declares _environ as > > _CRTIMP extern char ** _environ; /* pointer to environment table */ > > The compiler just writes a warning, but afterwards linking fails: > > 1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ". > > The linker complains about an "unresolved external symbol __environ". Removing > our declaration of environ fixes the warning, link error and libwine seems to > work OK. > > I don't know what the proper fix is, please advise. Maybe this code shouldn't > be compiled at all? I don't think I need the loader code on Windows. The underlying issue is probably the _CRTIMP - that's most likely _declspec(dllimport) in MSVC. This matters, as DLL-imported and “plain” extern variables are handled differently on Windows. IIRC DLL export/import of variables is indirect - when DLL-importing a variable you really import a _pointer_ to the variable. So accessing the variable dereferences some pointer. “extern” variables, otoh, are accessed directly (resolving the actual variable location is handled at link-time). -f.r.

May 25, 2011

Re: [1/2] user32: Add test for RegisterHotKey/UnregisterHotKey.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11183 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

May 25, 2011