March 2009 - Wine-devel - list.winehq.org

Re: [5/5] ws2_32/tests: Tests for invalid conditions in InetNtop
by Paul Vriens 09 Mar '09

09 Mar '09

Jeff Latimer wrote: > MSDN defines an number of conditions that inet_ntop will return errors. > This patch tests for them. > --- > dlls/ws2_32/socket.c | 30 +++++++++++++++- > dlls/ws2_32/tests/sock.c | 83 > ++++++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 109 insertions(+), 4 deletions(-) > > > > ------------------------------------------------------------------------ > > I think you can get rid of these comments: /* MSDN says it returns ERROR_INVALID_PARAMETER in MSDN but Vista returns 0xc000000d - STATUS_INVALID_PARAMETER */ MSDN has proven to be wrong on occasion and there is no need to put that in the code. Secondly you shouldn't use magic number if you no the name: WSASetLastError(0xc000000d); In the tests you do: + ok(WSAGetLastError() == 0xC000000D, + "Should be ERROR_INVALID_PARAMETER not %x\n", WSAGetLastError()); Again the magic number and in this case the ok() message is wrong as that should be STATUS_INVALID_PARAMETER according to your testing. -- Cheers, Paul.

2 3

Re: [2/5] resend ws2_32/tests: add tests for Inet_Ntop and inet_ntoa
by Paul Vriens 09 Mar '09

09 Mar '09

Jeff Latimer wrote: > Note that Inet_Ntop is only available in Vista and Windows 2008. This > patch removes the version testing. This one removes the redundant test > after GetModuleHandle and adds win_skip(). > --- > dlls/ws2_32/tests/sock.c | 68 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 68 insertions(+), 0 deletions(-) > > > > ------------------------------------------------------------------------ > > Hi, There is no need to have two if (pInetNtop) statements right after each other, this could be just one. Maybe it's even better that before you start using pInetNtop, you do: if (!pInetNtop) { win_skip("InetNtop not present, not executing tests\n"); return; } You than don't need to indent the code anymore. -- Cheers, Paul.

2 1

Re: [2/5] resend ws2_32/tests: add tests for Inet_Ntop and inet_ntoa
by Paul Vriens 09 Mar '09

09 Mar '09

Jeff Latimer wrote: > Note that Inet_Ntop is only available in Vista and Windows 2008. This > patch removes the version testing. > --- > dlls/ws2_32/tests/sock.c | 67 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 67 insertions(+), 0 deletions(-) > > > > > ------------------------------------------------------------------------ > > Two minor things: There is no need to to check the return value of GetModuleHandle as ws2_32 is already imported. Could you add a win_skip() somewhere so we know that some tests are skipped on some platforms? -- Cheers, Paul.

2 1

Re: [1/5] vbscript: Added stub DLL
by Jacek Caban 09 Mar '09

09 Mar '09

Hi Robert, Robert Wilhelm wrote: > Third try of my effort to get create vbscript skeleton similar to > jscript one. > Your patch series looks good for me, except one little problem: +#include "windef.h" +#include "winbase.h" +#include "winuser.h" +#include "ole2.h" +#include "dispex.h" +#include "activscp.h" + + + AFAIK VBScript is not based on IDispatchEx (except it uses just IDispatch), so you shouldn't need to include dispex.h. (While we're at this, also empty lines in the end of file should be removed). BTW, are you planning working further on VBScript implementation? Thanks, Jacek

1 0

Re: shlwapi: Correct AssocCreate and tests
by Jacek Caban 09 Mar '09

09 Mar '09

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > The spec file specified 4 parameters but it only takes 3. > Validate parameters to XP. > Added test cases. > > Tested on win98 and XP. > > Changelog: > shlwapi: Correct AssocCreate and tests > + hr = pAssocCreate(IID_NULL, &IID_NULL, NULL); + ok(hr == E_INVALIDARG, "Unexpected result : %08x\n", hr); refiid arguments looks like an interface id (and the whole function looks similar to IClassFactory::CreateInstance), so it would be interesting to add test of IID_IUnknown. Jacek

1 0

Some news about my DIB Engine.....
by Massimo Del Fedele 08 Mar '09

08 Mar '09

I've gone a bit further with my DIB Engine, mostly on gdi32 side, in order to solve the last problems, at least as seen in my favorite app, Autocad 2005. Previous version had a bug related to the *only* .net part of that app (which was obviously written by a 5 years old child, imho), the layer manager. On this one, a bitblt operation is done reading some screen part into a DIB when painting the dialog on screen. Worse than that, there are *many* small bitblt ops (like 40x1 pixels) on *large* source/destination bitmaps (like some hundred kB - MB of pixel data. Well, that stuff showed to me the big limit of the approach taken, the "mixed driver" one with different driver pointers on same DC. That's the approach taken by earlier intents of Jesse Allen and Huw Davies. So I decided to make a break, examining the problems so far and maybe discussing a bit about it. 1) Maintain DCs and bitmaps in sync with correct driver. That problem is fully solved, requiring some small hacks on many parts of gdi32, in detail in bitmap.c, dib.c and dc.c. Well, not really hacks, even if the code isn't as clean as I'd like. Difficulty here was mostly due to bmp funcs that should be identical to DC on which it's selected, on DIB creation and on BITMAP_SetOwnerDC() part. In short, that part should be quite good by now. 2) Now the big (and slow) problem : the "mixed" operations, those which uses both DIBs and DDB; BitBlt(), StretchBlt and so on. On those we can't simply use one driver because it can't handle other driver's bitmap. Well, X11 driver could do it, in theory, but having the DIB created by DIB engine makes it impossible (missing X11 physDev and related pixmap). So the problem, as correctly pointed by Jesse Allen, is to "uniformize" the DCs *before* the BlitBlt operation, *or* to make DIB engine able to deal with DDB stuffs. I discarded latter approach for obvious reasons, the engine would become a copy of X11 driver with added DIB stuffs, which would vanify the (simpler) approach taken. BTW, I'm still convinced that the "right" approach would be to rewrite X11 driver withe the engine embedded, OR to embed the engine on gdi32 taking it off X11 driver. Well, back to first approach, Jesse's one. It means to make a copy of the source bitmap *before* blitting converting it on same format of destination one. That approach is slower because it means to make a copy /conversion of the source bitmap which can be time expensive. Jesse's solution was to make a conversion of the *full* source bitmap which showed it's first limit on my Autocad testings (the layer manager part) on whith very small parts of a big image are Blitted. That means sometimes hundreds of copy/conversions of a MB sized bitmap just to transfer some 40 pixels a time..... not a real speed gain :-) So I decided to limit the copy of the needed lines of source bitmap, with help of GedDIBits/SetDIBits stuffs. Not perfect, but quite faster..... *if* working. SetDIBits seems to have some sort of bug when "startscan" and "scanlines" don't use the full bitmap's size. I'm not able to test the SetDIBits X11 code, so if somebody can check it that would be of great help to me. GetDIBits works good with those parameters selecting a stripe of full bitmap. Now, the second problem on that approach, which emerged testing the same autocad part. When blitting *from* screen device, there's no real BMP selected onto DC, so the GetDIBits approach is useless. The only way to cope with the problem is to make a (third) intermediate conversion, so DEVICE DC ---bitblt (X11 side)--->memory DC (DDB)---GetDIBits---> DIB That means 3 data transfers to make a BitBlt operation from display to a DIB destination bitmap.... Anyways, even with those bottlenecks, autocad application shows great speed improvements on TT fonts (from unusable to about the same windows xp speed) with no visible slow downs. Ciao Max

1 0

Fwd: Sufficient 1.2 release criterion: passing all tests on all platforms?
by David Gerard 08 Mar '09

08 Mar '09

to list as well ---------- Forwarded message ---------- From: David Gerard <dgerard(a)gmail.com> Date: 2009/3/8 Subject: Re: Sufficient 1.2 release criterion: passing all tests on all platforms? To: Dan Kegel <dank(a)kegel.com> 2009/3/8 Dan Kegel <dank(a)kegel.com>: > For graphics cards: > 1st tier: Nvidia 8400 or higher > 2nd tier: < 4 year old Nvidia, < 2 year old ATI, < 2 year old Intel > 3rd tier: older nvidia I would question Nvidia cards being first unless we're talking about the nv or nouveau drivers. The binary drivers are known to crash more with Wine because it puts more demands on them, and Nvidia is known not to care about this. The Intel drivers have the advantage of being good, being open source and being from a company that seriously cares about getting them right. Or, shorter: privileging a closed-source driver doesn't seem like a good idea. - d.

1 0

String expansion (%n %t)
by Rick Jones 08 Mar '09

08 Mar '09

Is there a Windows string function that expands escape sequences such as %n, %t, etc, and which is replicated by Wine? I ask because I have a Windows app that is screwing up because of something like this. It has a private .ini settings file, and some settings are stored in that kind of format, but when it runs on Wine they are wrongly retrieved (this is a 3rd party app, I don't have the source). It looks horribly like %n is being expanded to NL instead of CR-NL. If there's a Windows/Wine function for this then I might be able to use a native DLL to get round it, but I've no idea where it might reside! AFAIK GetPrivateProfileString() doesn't do this expansion inherently. Also if it is the case that the behaviour's different, then I would say it's a Wine bug. Any ideas appreciated. Rick

2 2

Running 16 bit builtin exes fails?
by Dan Kegel 08 Mar '09

08 Mar '09

With Friday's git, I can't run the new winhelp.exe16. $ cd programs/winhelp.exe16 $ wine winhelp.exe16.so fails with err:process:start_process L"Z:\\home\\dank\\wine32\\programs\\winhelp.exe16\\winhelp.exe16" doesn't have an entry point, it cannot be executed Did I miss some memo? This is on a 64 bit intel ubuntu 8.10 box, but wine was built as 32 bits. - Dan

3 5

Re: [wininet/tests 2/2] Skip some tests on IE5
by Paul Vriens 08 Mar '09

08 Mar '09

Paul Vriens wrote: > Hi, > > Ordinal 117 is CreateUrlCacheContainerA so these tests crashed on > systems with IE5. > > I also guess that IsDomainLegalCookieDomainW is only present on IE6 and > higher. > > Changelog > Skip some tests on IE5 > I of course meant to say "Ordinal 117 is CreateUrlCacheContainerA in wininet.dll that comes with IE5". -- Cheers, Paul.

1 0