September 2008 - Wine-devel

Re: gdi32: "StretchDIBits" with value of zero for "xSrc" and "ySrc"
by Vitaliy Margolen 22 Sep '08

22 Sep '08

Mathias Kosch wrote: > This path fixes Bug#13344. > > The function "StretchDIBits" behaves odd in case of "top-down" bitmaps > with values of zero for "xSrc" and "ySrc". Tests using Windows Server > 2003 shew that in this particular case the source rectangle is > selected starting at the upper left corner of the bitmap. In all other > cases the rectangle is aligned to the bottom of the bitmap. > > I provided a test case which tests several combinations, especially > those with some of the values set to zero. > It passes under "Windows Server 2003 R2 SP2" and Wine 1.1.5 (only) > with this path applied. General note - Wine uses 4-spaces indentation, tabs = 8 spaces. Use of tabs discouraged. Mixing spaces and tabs highly not recommended. > +#include <stdbool.h> > +#include <inttypes.h> Please use windows types instead > + struct PIXEL > + { > + uint8_t blue; > + uint8_t green; > + uint8_t red; > + } __attribute__ ((__packed__)); You should use RGBTRIPLE instead. > + HDC hDC = NULL, hMemDC = NULL; > + HBITMAP hBitmap = NULL, hOldBitmap = NULL; What's the point initializing something you will overwrite anyway? Don't do this, it hides bugs. > > + pBitmapData = (struct PIXEL*)malloc(nBitmapWidth*nBitmapHeight*sizeof(struct PIXEL)); Malloc should not be used in winelib apps. Use HeapAlloc/HeapFree. > + if (!pBitmapData) > + ok(0, "Memory allocation failed.\n"); Don't do this. If allocation failed assert or skip the test entirely. Vitaliy.

1 0

Re: kernel32: fix PROFILE_Load to handle mac line endings (try 3)
by Michael Karcher 21 Sep '08

21 Sep '08

Am Sonntag, den 21.09.2008, 02:15 +0200 schrieb Erik Inge Bolsø: > + ok(1, "%s\n", content); Please use trace(...) instead of ok(1,...). Also, outputting a string with newline characters might be irritating, especially as one might need a hex viewer to see the difference between the CR-only and CR/LF variant. You might want to have trace("test_GetPrivateProfileStringA: Run %d\n"); Instead of a run number, you also might want to pass a description like "CR only" or "CR/LF". > - ok(ret == 18, "Expected 18, got %d\n", ret); > + ok(ret == 18, "Run %d: Expected 18, got %d\n", run, ret); Questions to everyone: I suppose if the trace above indicates the run number, these modifications are unneded. Do you agree? Regards, Michael Karcher

2 3

Re: Simplify dlls/atl/registrar.c
by Rob Shearman 21 Sep '08

21 Sep '08

2008/9/7 Gerald Pfeifer <gerald(a)pfeifer.com>: > --- dlls/atl/registrar.c 7 May 2008 12:06:02 -0000 1.29 > +++ dlls/atl/registrar.c 7 Sep 2008 13:42:54 -0000 > @@ -661,7 +661,7 @@ static const IRegistrarVtbl RegistrarVtb > Registrar_ResourceUnregister, > }; > > -static HRESULT Registrar_create(const IUnknown *pUnkOuter, REFIID riid, void **ppvObject) > +static HRESULT Registrar_create(REFIID riid, void **ppvObject) > { > Registrar *ret; > > @@ -711,7 +711,7 @@ static HRESULT WINAPI RegistrarCF_Create > REFIID riid, void **ppvObject) > { > TRACE("(%p)->(%s %p)\n", iface, debugstr_guid(riid), ppvObject); > - return Registrar_create(pUnkOuter, riid, ppvObject); > + return Registrar_create(riid, ppvObject); > } A test needs to be added to see whether or not the Registrar class factory supports aggregation. If it does then a FIXME should be emitted. If not then an ERR may be emitted and CLASS_E_NOAGGREGATION returned. Just removing pUnkOuter isn't the right thing to do. -- Rob Shearman

2 1

Re: [PATCH] [WinHelp]: fix for 5314
by Dmitry Timoshkov 21 Sep '08

21 Sep '08

From: "Eric Pouech" <eric.pouech(a)orange.fr> wrote: > +#include <ctype.h> ... > + if (!ch || !isalpha(ch)) break; Since that's apparently a Windows encoding shouldn't this be GetStringType() instead of isalpha()? -- Dmitry.

2 1

What to do when size of the struct differs on 32 and 64 bit?
by Vitaliy Margolen 21 Sep '08

21 Sep '08

While debugging some force-feedback issues ran into an interesting problem. The size of one struct from include/linux differs between 32-bit and 64-bit. That wouldn't be a major problem except that size is the part of the ioctl() request. Which results in EINVAL. In more details: input.h: #define EVIOCSFF _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct ff_effect)) The simple test program: #include <linux/input.h> #include <stdio.h> int main(int argc, char * argv[]) { printf("sizeof(struct ff_effect) = %d EVIOCSFF=%#x\n", sizeof(struct ff_effect), EVIOCSFF); return 0; } $ gcc test_size.c -o test_size && ./test_size sizeof(struct ff_effect) = 48 EVIOCSFF=0x40304580 $ gcc -m32 test_size.c -o test_size32 && ./test_size32 sizeof(struct ff_effect) = 44 EVIOCSFF=0x402c4580 The question is what do we do about it? I'm sure there are might be more cases like that. Vitaliy

6 6

Re: WineD3D: fix UpdateSurface bug [with patch]
by Henri Verbeet 20 Sep '08

20 Sep '08

2008/9/20 Roderick Colenbrander <thunderbird2k(a)gmx.net>: > Hi, > > Fix a bug in UpdateSurface where we didn't take into account the offset into the memory buffer specified in the source rectangle. > What about the glCompressedTexImage2DARB() call a few lines up and the TRACE?

2 1

Re: msvcrt: scanf fix a typo
by James Hawkins 20 Sep '08

20 Sep '08

On Fri, Sep 19, 2008 at 4:39 PM, Austin English <austinenglish(a)gmail.com> wrote: > Found using -Werror (strangely, didn't occur on ubuntu, but does on > PC-BSD)...Must be the gcc version. > @@ -63,7 +63,7 @@ static void test_sscanf( void ) ok( sscanf("1233", "%p", &ptr) == 1, "sscanf failed\n" ); ok( ptr == (void *)0x1233,"sscanf reads %p instead of %x\n", ptr, 0x1233 ); - ok( sscanf("1234", "%P", &ptr) == 1, "sscanf failed\n" ); + ok( sscanf("1234", "%p", &ptr) == 1, "sscanf failed\n" ); ok( ptr == (void *)0x1234,"sscanf reads %p instead of %x\n", ptr, 0x1234 ); How do you figure that's a typo? The test right above it is exactly the same as what you've changed this one to. I didn't write the test, but I'm pretty sure the original author meant to test both cases. This is a good reason why tests should be commented, so the author's intent is well known. -- James Hawkins

5 6

WebKit vs Gecko and Wine
by Vijay Kiran Kamuju 20 Sep '08

20 Sep '08

Hi, I have a nice idea to discuss at wineconf this year. Is it possible to use webkit for mshtml and jscript implementations of wine? Have been hearing a lotta good reviews about performance of webkit and lotta other browsers adopting it. How much work would it be to support webkit as to provide an alternative for winegecko? Firstly is it feasible. Thanks, VJ --------------------------------------------------------------------------------------------------------------------- Zsa Zsa Gabor - "He taught me housekeeping; when I divorce I keep the house."

3 2

Re: PrintDlgEx [2/7]: Add basic dialog.
by Michael Stefaniuc 19 Sep '08

19 Sep '08

Hello Gal, there is no point in adding new resources in English to the other languages rc files. If a resource doesn't exist Win32 will automatically fail over to use the en_US version. Actually its even detrimental to add the new resources as: a.) http://pf128.krakow.sdi.tpnet.pl/wine-transl/ cannot show those resources as untranslated. b.) The copied English resources have a tendency to bit-rot. c.) The patch is smaller and offers the exact same functionality. You need to only amend existing resources in the language files that have that resource. To make it easy the Wine wrc supports the --verify-translation switch. Just take the wrc command that make is running in that directory and append --verify-translation to it. Do that before and after you applied your patch. If you see additional lines popping up that start with "DIFF" or "ERR" your patch breaks the translations and you'll have to check what resource you need to amend. Gal Topper wrote: > dlls/comdlg32/cdlg_Bg.rc | 38 +++++++ > dlls/comdlg32/cdlg_Cs.rc | 38 +++++++ > dlls/comdlg32/cdlg_Da.rc | 38 +++++++ > dlls/comdlg32/cdlg_De.rc | 38 +++++++ > dlls/comdlg32/cdlg_El.rc | 38 +++++++ > dlls/comdlg32/cdlg_En.rc | 38 +++++++ > dlls/comdlg32/cdlg_Eo.rc | 38 +++++++ > dlls/comdlg32/cdlg_Es.rc | 38 +++++++ > dlls/comdlg32/cdlg_Fi.rc | 38 +++++++ > dlls/comdlg32/cdlg_Fr.rc | 38 +++++++ > dlls/comdlg32/cdlg_It.rc | 38 +++++++ > dlls/comdlg32/cdlg_Ja.rc | 38 +++++++ > dlls/comdlg32/cdlg_Ko.rc | 38 +++++++ > dlls/comdlg32/cdlg_Nl.rc | 38 +++++++ > dlls/comdlg32/cdlg_No.rc | 38 +++++++ > dlls/comdlg32/cdlg_Pl.rc | 38 +++++++ > dlls/comdlg32/cdlg_Pt.rc | 85 +++++++++++++++ > dlls/comdlg32/cdlg_Ro.rc | 40 +++++++ > dlls/comdlg32/cdlg_Ru.rc | 38 +++++++ > dlls/comdlg32/cdlg_Si.rc | 38 +++++++ > dlls/comdlg32/cdlg_Sk.rc | 38 +++++++ > dlls/comdlg32/cdlg_Sv.rc | 38 +++++++ > dlls/comdlg32/cdlg_Th.rc | 38 +++++++ > dlls/comdlg32/cdlg_Tr.rc | 38 +++++++ > dlls/comdlg32/cdlg_Uk.rc | 38 +++++++ > dlls/comdlg32/cdlg_Zh.rc | 38 +++++++ > dlls/comdlg32/printdlg.c | 269 +++++++++++++++++++++++++++++++++++++++++++++- > dlls/comdlg32/printdlg.h | 20 ++++- > 28 files changed, 1323 insertions(+), 3 deletions(-) bye michael

3 3

Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
by Roderick Colenbrander 19 Sep '08

19 Sep '08

Hi, First of all note that glXDestroyContext only destroys a context after no of the other threads is using it (it is in the specs of glXDestroyContext). Second there are some more issues in wglShareLists which shouldn't get fixed in your patch but which I plan to fix at a later stage which you should take into account. Some BAD class of apps calls wglShareLists before making the source context current (so it isn't backed by a GLX context) while it has made the destination one current. In such case we need to perform a swap as right now such programs crash. MSDN clearly mentions that the hglrc2 parameter shouldn't contain any existing display lists, so this situation isn't allowed. This would mean wglShareLists(dest, source) is invalid and second that when perform a legal wglShareLists(source, dest) that dest can't have been current in any thread. Since wglShareLists is a tricky function which might require very ugly hacks I want to keep it as clean as possible. This means that you should write a small wine test case for the behavior of wglShareLists in the situation affected by your patch. Roderick > The current wglShareLists() will fail if the destination context has ever > been made current. This causes a crash in Homeworld 2, unless pbuffers are > disabled. This patch fixes the crash by deleting and recreating the > underlying OpenGL context, unless it is still current in some thread. > > Improved patch by: Moving the deletion of the old context into the > wine_tsx11_lock where it belongs; tracking whether a WGL context is current in > some thread so we don't deselect it out from under the app; adding an > explanatory comment; a more professional change entry ;) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

3 4