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

Re: X developer's conference, April 16-18

by Tijl Coosemans

On Monday 25 February 2008 17:49:42 Stefan Dösinger wrote: > * Other things? Display settings at the window manager level: http://bugs.winehq.org/show_bug.cgi?id=3230 http://bugs.winehq.org/show_bug.cgi?id=10115 http://bugs.winehq.org/show_bug.cgi?id=10841

Feb. 26, 2008

Re: X developer's conference, April 16-18

by Stefan Dösinger

Am Montag, 25. Februar 2008 19:21:18 schrieb Roderick Colenbrander: > > Did someone mention a nice way to query amount of video card's onboard > > VRAM? > > I talked about that with some X developers a while ago and they felt (and I > agree with them) that this is something that should not be exported. OpenGL > hides it from us for a reason. It is against the philosophy of GL. DirectX > allows it but the same as exporting the pci id, it is not something that > should be exported in my opinion. There's GL_ATI_meminfo, but no spec about it. I think I found a way to find the current free video memory, but not the total one. The current free vidmem is comparably uninteresting because it is managed by opengl anyway and we cannot implement a proper D3DPOOL_DEFAULT pool due to that. I haven't seen any equivalent to this on the nvidia side

Feb. 26, 2008

Re: GSoC project ideas

by Kai Blin

On Monday 25 February 2008 22:54:57 Scott Ritchie wrote: > Write a case insensitive FUSE filesystem for us to put the entire > ~/.wine directory in. See http://wiki.winehq.org/CaseInsensitiveFilenames > > There are two main advantages to this: > Sometimes applications break because users need to install a patch by > hand into the filesystem (say, a zip file), and the files within have a > different case then the files they're supposed to overwrite. This leads > to multiples of the same file, and Wine sometimes chooses the older one, > leading to weird breakages. > > More importantly, a FUSE filesystem like this would allow us to finally > get some speedups by no longer having to prove case-insensitive files > don't exist. This is a direct cause of some apps working very very > slowly, including install shield (see > http://bugs.winehq.org/show_bug.cgi?id=3817) > > Interestingly, this doesn't strictly have to be a Wine SOC project. It > could fairly easily stand on its own. We'd probably be the only user > though, so I mention it here. Sounds like an interesting project. I see you've already added it to the wiki page. I think the effort is in scope for SoC, though I haven't really played with this yet. Thanks, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 26, 2008

gdi32: Patch review request

by Daniel Mario Vega

Hi! A few days ago I sent 2 patches for gdi32 to wine-patches that passed unnoticed. I would like if someone could give me some feedback on them. Let me first give you some background about these patches. There is an application called "Compumap" that is a street map of some Argentine cities. It is rather popular here because some years ago it was distributed with a newspaper. The program works quite well under Wine (although the installer still has some problems), but when you try to print a map it crashes. A few weeks ago I had some free time and I decided to try to find out why it crashes. I run it through the Wine Debugger and also under a debugger in Windows XP. The problem happened to be two API calls with incomplete/invalid parameters. Windows XP returned NULL or ignore the wrong data, while Wine crashes. 1) gdi32: Protect against short sized LOGPALETTE in CreatePalette. http://www.winehq.org/pipermail/wine-patches/2008-February/050354.html This crash was caused by "CreatePalette(HDC, LOGPALETTE)" being called with a short allocated palette. Windows XP returned NULL in that case. I tried to reproduce that behavior by first checking the parameter with "IsBadReadPtr()" function. 2) gdi32: StartDocA support for legacy apps with incomplete DOCINFOA parameter. http://www.winehq.org/pipermail/wine-patches/2008-February/050357.html This issue was a call to "StartDocA(HDC, DOCINFOA)" with structure DOCINFOA not completely initialized (there is garbage in the last 2 fields). I debugged this API and found that Windows XP ignored those fields when the data "seems to be invalid". I think that the last 2 fields were introduced in Win32 and some applications ported from Win16 "forget" to clear them. I simulated Windows XP behaviour by putting some safe checks on those fields. With those 2 fixes, the application is able to print under Wine. Both patches are short and rather easy to review. I will appreciate if someone could give me some feedback on them. Thanks ... -- Daniel Mario Vega

Feb. 26, 2008

Re: marshalled ITypeComp

by Robert Shearman

Guillermo Winkler wrote: > Hi, > I'm having some problems regarding ITypeInfo/ITypeComp implementation. > > IDispatch* pdisp; > ITypeInfo* ptinfo; > > HRESULT hr = pdisp->GetTypeInfo(0, LOCALE_SYSTEM_DEFAULT, &typeinfo); > hr = ptinfo->GetTypeComp(&ptcomp); > > > pdisp is created from > > hr = CoCreateInstance(clsid, > NULL, > CLSCTX_SERVER, > IID_IDispatch, > (void**)&pdisp); > > That is, the server is an outprocess exe. > > In this case marshalling of ITypeComp fails in first instance because > > ITypeComp_fnQueryInterface (oleaut32\typelib.c) > resolves on -> ITypeInfo_QueryInterface (oleaut32\typelib.c) > > That is not considering IID_ITypeComp as a valid alternative(but it is) > > if(IsEqualIID(riid, &IID_IUnknown) || > IsEqualIID(riid,&IID_ITypeInfo)|| > IsEqualIID(riid,&IID_ITypeInfo2)) > *ppvObject = This; > > When I fixed this, I have a different problem now: > > fixme:ole:DllGetClassObject > CLSID: {00020425-0000-0000-C000-000000000046} > IID: {D5F569D0-593B-101A-B569-08002B2DBF7A} > > That is PSTypeComp to be marshalled asking for factory buffer > IID_IPSFactoryBuffer. Yes, CLSID_PSTypeComp should be added to the cases in which OLEAUTPS_DllGetClassObject is called in dlls/oleaut32/oleaut.c:DllGetClassObject. -- Rob Shearman

Feb. 26, 2008

Re: opengl32/tests: Add the trailing '\n' to an ok() call and make a spelling fix.

by Paul Vriens

Francois Gouget wrote: > --- > dlls/opengl32/tests/opengl.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/opengl32/tests/opengl.c b/dlls/opengl32/tests/opengl.c > index 3836ba7..344e2c6 100644 > --- a/dlls/opengl32/tests/opengl.c > +++ b/dlls/opengl32/tests/opengl.c > @@ -384,9 +384,9 @@ START_TEST(opengl) > > /* We shouldn't be able to create a context from a hdc which doesn't have a pixel format set */ > hglrc = wglCreateContext(hdc); > - ok(hglrc == NULL, "wglCreateContext should fail when no pixel format has been set, but it passed"); > + ok(hglrc == NULL, "wglCreateContext should fail when no pixel format has been set, but it passed\n"); > error = GetLastError(); > - ok(error == ERROR_INVALID_PIXEL_FORMAT, "expected ERROR_INVALID_PIXEL_FORMAT for wglCreateContext without a pixelformat set, but recevied %#x", error); > + ok(error == ERROR_INVALID_PIXEL_FORMAT, "expected ERROR_INVALID_PIXEL_FORMAT for wglCreateContext without a pixelformat set, but recieved %#x\n", error); So where is the spelling fix ;-) Shouldn't that be "received"? -- Cheers, Paul.

Feb. 26, 2008

Re: d3dx9: Add IMPORTLIB to every Makefile.in [PATCH 4/9]

by Alexandre Julliard

tony.wasserka(a)freenet.de writes: >>From 881b8de1e044ff90bcb543501208a9cd879cbc16 Mon Sep 17 00:00:00 2001 > From: Tony Wasserka <tony.wasserka(a)freenet.de> > Date: Sat, 23 Feb 2008 13:55:40 +0100 > Subject: [PATCH] d3dx9: Add IMPORTLIB to every Makefile.in That shouldn't be needed, there are no such import libs on Windows. -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2008

Re: d3dx9: Implement D3DXCheckVersion [PATCH 1/9]

by Alexandre Julliard

tony.wasserka(a)freenet.de writes: > D3DXCheckVersion doesn't check for one specific D3DX version, but > for all that are compatible with our Wine code (i.e. d3dx9_24 to d3dx9_36) > The reasons for that were explained in these mails by me: > http://www.winehq.org/pipermail/wine-devel/2008-February/062290.html > and http://www.winehq.org/pipermail/wine-devel/2008-February/062292.html This is wrong, you should have a separate version check for each dll that checks the exact version of that dll. -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2008

Re: msvcrt: Implemented wcscpy_s (try 2)

by Alexandre Julliard

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> writes: > Is there any thing wrong with this patch? >> + /* Test invalid size */ >> + szDest[0] = 'A'; >> + ret = p_wcscpy_s(szDest, 0, szLongText); >> + ok(ret == EINVAL, "expected ERANGE got %d\n", ret); >> + ok(szDest[0] == 0, "szDest[0] not 0\n"); >> + >> + /* Copy same buffer size */ >> + ret = p_wcscpy_s(szDest, 18, szLongText); >> + ok(ret == 0, "expected 0 got %d\n", ret); >> + ok(lstrcmpW(szDest, szLongText) == 0, "szDest != szLongText\n"); >> + >> + /* Copy smaller buffer size */ >> + szDest[0] = 'A'; >> + ret = p_wcscpy_s(szDestShort, 8, szLongText); >> + ok(ret == ERANGE, "expected EINVAL got %d\n", ret); >> + ok(szDestShort[0] == 0, "szDest[0] not 0\n"); The error messages don't match the tests. >> + if(numElement <= 0) >> + { >> + wcDest[0] = 0; >> + >> + if(numElement < 0) >> + return ERANGE; >> + else >> + return EINVAL; The variable is unsigned so the comparison is useless. Also its type should be MSVCRT_size_t. -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2008

Re: [6/6] msxml3: Tests for put_data

by Alexandre Julliard

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> writes: > Hi, > Im a little confused, IXMLDOMComment_put_data wasnt compiling on my > machine, and yet > Alexandre changed to include this code and now it compiles correctly? > I event tried a >>make clean; ./configure; make depend;make > which didnt work either. > > Can anybody explain what was fixed? http://source.winehq.org/git/wine.git/?a=commit;h=72cbaa8fbfaeff2b6e907222c… -- Alexandre Julliard julliard(a)winehq.org

Feb. 26, 2008