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

re: winedos: Support reading from VGA register 0x3ba
by Dan Kegel 08 Jul '08

08 Jul '08

> Title says it all. Not *quite* all. Inquiring minds always want to know what app it will help and/or bugzilla entry it will fix. Codeweavers folks often don't mention that for business reasons, but if you're at liberty to mention it, it's always nice to include that in patch descriptions.

2 1

Re: [PATCH 2/2] user32: Set SWP_NOSIZE for windows with SWP_NOREDRAW.
by Alexandre Julliard 08 Jul '08

08 Jul '08

"Lei Zhang" <thestig(a)google.com> writes: > @@ -1808,6 +1808,10 @@ static BOOL fixup_flags( WINDOWPOS *winpos ) > if ((wndPtr->rectWindow.right - wndPtr->rectWindow.left == winpos->cx) && > (wndPtr->rectWindow.bottom - wndPtr->rectWindow.top == winpos->cy)) > winpos->flags |= SWP_NOSIZE; /* Already the right size */ > + else if (((winpos->flags & (SWP_NOZORDER|SWP_NOREDRAW|SWP_FRAMECHANGED|SWP_NOACTIVATE)) == SWP_NOREDRAW) && > + (wndPtr->rectWindow.right - wndPtr->rectWindow.left == origSize.x) && > + (wndPtr->rectWindow.bottom - wndPtr->rectWindow.top == origSize.y)) > + winpos->flags |= SWP_NOSIZE; /* Already the right size */ It makes no sense to compare the window rect against the original size since the window rect hasn't been changed yet, it will always match. Also I fail to see why this would have anything to do with SWP_NOREDRAW. I think you are on the wrong track with this bug. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winedos: Support reading from VGA register 0x3ba
by Michael Karcher 08 Jul '08

08 Jul '08

Am Sonntag, den 06.07.2008, 13:45 -0700 schrieb Jon Griffiths: > Title says it all. > + case 0x3ba: > + /* CRT status register (read only) > + * This register is read repeatedly to signal whether a hercules/ > + * monochrome adapter is present, which is signalled by bit 7 > + * changing within 0x8000 reads. The other bits then describe the > + * type of monochrome adapter present. > + */ > + return 0; /* VGA compatible */ That patch seems wrong. As a VGA is able to coexist with a monochrome adapter, it does not respond to reading 0x3ba at all. And ISA is TTL compatible, i.e. open inputs read as one, so reads without responder return 0xFF. Regards, Michael Karcher

2 1

Re: bug 14360: dosmem forgot MAP_FIXED
by Alexandre Julliard 08 Jul '08

08 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > Attached is the patch for http://bugs.winehq.org/show_bug.cgi?id=14360 > dosmem forgot MAP_FIXED No, it's not forgotten, that's the way it's supposed to work. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: gdiplus: Add a test to show that bitmap fonts aren't used for fontfamilies.
by Adam Petaccia 08 Jul '08

08 Jul '08

On Tue, 2008-07-08 at 13:20 +0100, Huw Davies wrote: > --- > dlls/gdiplus/tests/font.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) On my Windows system I can't find MSSansSerif, only Microsoft Sans Serif. I'm not sure if that's a valid test to prove that point.

2 1

Re: bug 14362: RtlDestroyHeap forgot to notify_free on allocated blocks
by Alexandre Julliard 08 Jul '08

08 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > +static void subheap_notify_free_all(SUBHEAP const *const subheap) > +{ > + char const *ptr = (char const *)subheap->base + subheap->headerSize; > + > + //DPRINTF("subheap_notify_free_all heap @%p, arena=%p\n", subheap, ptr); Please clean up that sort of thing before submitting. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bug 14359: clear new reserved slots in new argv[]
by Alexandre Julliard 08 Jul '08

08 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > Attached is the patch for http://bugs.winehq.org/show_bug.cgi?id=14359 > clear new reserved slots in new argv[] I don't see any case where the reserved slots wouldn't be initialized. Please provide more details. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: quartz: Fix deadlock with transform filter, try 2
by Michael Karcher 08 Jul '08

08 Jul '08

Am Montag, den 07.07.2008, 18:22 -0700 schrieb Maarten Lankhorst: > Reworks the code so that the lock is taking in the called procedures now. > + InputPin *pin = (InputPin *)pTransformFilter->ppPins[0]; > + > + EnterCriticalSection(&pTransformFilter->csFilter); > + if (pTransformFilter->state == State_Stopped) > + { > + LeaveCriticalSection(&pTransformFilter->csFilter); > + return VFW_E_WRONG_STATE; > + } I have to admit that I don't know anything about quartz. Are you sure you may access pTransformFilter->ppPins[0] before taking the lock? Regards, Michael Karcher

2 1

Re: [RESEND]MSI:ACTION_AppSearchReg() should return backslash terminated paths - Solves bug 13838
by James Hawkins 08 Jul '08

08 Jul '08

On Mon, Jul 7, 2008 at 10:04 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > I'll repost that one... I'd like some feedback if it looks wrong. > This isn't going to be committed without a test. > To maintain consistence between global MSI path properties (as > CommonAppDataFolder) which are returned with a trailing backslash, and > local MSI path properties (as LOCALAPPDATAFOLDER) which by now where > returned without the trailing backslash. Properties in MSI are just that...properties. Folders loaded from the Folder table just happen to be stored as properties. The AppSearch action looks for a path (in this case) and sets a user-defined property to the path of the directory. You're making a connection between these two completely separated sets of functionality that doesn't exist. > This solves autocad's installer bug 13838. > Ok, we've had tons of patches submitted, some committed, that fix one app and break tons of other apps. This is exactly why this has to be backed up by a test. I'll review your patch for you anyway: @@ -368,6 +368,17 @@ static UINT ACTION_AppSearchReg(MSIPACKAGE *package, LPWSTR *appValue, MSISIGNAT switch (type & 0x0f) { case msidbLocatorTypeDirectory: + /* directories should be returned with a trailing backslash + so check for it and append if necessary */ Leave the comment out. + if((LPWSTR)value[sz-1] != L'\\') + { Two things wrong. That first part is casting the result of value[sz-1], which is a BYTE (integer), to LPWSTR (pointer). Second, you can't use L in Wine. + *appValue = (LPWSTR)value; + value = msi_alloc(sz+1); You forgot to check if you're out of memory. + lstrcpyW((LPWSTR)value, *appValue); + lstrcatW(value, L"\\"); Again, can't use L in Wine. + msi_free(*appValue); + *appValue = NULL; + } rc = ACTION_SearchDirectory(package, sig, (LPWSTR)value, 0, appValue); break; case msidbLocatorTypeFileName: Now let's look at the whole thing: *appValue = (LPWSTR)value; value = msi_alloc(sz+1); lstrcpyW((LPWSTR)value, *appValue); lstrcatW(value, L"\\"); msi_free(*appValue); *appValue = NULL; You're using *appValue as a temporary pointer, which is ugly. msi_realloc is your friend. Check out the warnings you get when you compile this, which is the first sign that something is wrong: appsearch.c: In function 'ACTION_AppSearchReg': appsearch.c:373: warning: cast to pointer from integer of different size appsearch.c:373: warning: comparison between pointer and integer appsearch.c:378: warning: passing argument 1 of 'lstrcatW' from incompatible pointer type appsearch.c:378: warning: passing argument 2 of 'lstrcatW' from incompatible pointer type Taking one more step back: @@ -368,6 +368,17 @@ static UINT ACTION_AppSearchReg(MSIPACKAGE *package, LPWSTR *appValue, MSISIGNAT switch (type & 0x0f) { case msidbLocatorTypeDirectory: + /* directories should be returned with a trailing backslash + so check for it and append if necessary */ So this 'fix' is only for ACTION_AppSearchReg. What about all the other AppSearch functionalities that also search for a directory? Those will remain unfixed. Also, why are you making it the responsibility of AppSearchReg to add the backslash? You're assuming that ACTION_SearchDirectory never changes the value sent in and only copies it straight back if it finds the path. That's a bad assumption. Plus, if you fix this at the lowest level, you get a fix for all the AppSearch functionalities for free. -- James Hawkins

5 7

Re: bug 14357: undefined edge padding in bitmaps annoys valgrind
by Alexandre Julliard 08 Jul '08

08 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > Attached is the patch for http://bugs.winehq.org/show_bug.cgi?id=14357 > undefined edge padding in bitmaps annoys valgrind Please stop filing bugs for your patches. Just submit the patches with a proper changelog entry and explanations, instead of a pointer to bugzilla. -- Alexandre Julliard julliard(a)winehq.org

1 0