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

Re: [1/4] user32/tests: Test size and minmax of WS_THICKFRAME child.
by Austin English 16 Nov '08

16 Nov '08

On Sun, Nov 16, 2008 at 10:52 AM, Florian Köberle <florian(a)fkoeberle.de> wrote: > Patch to fix bug 15188. > > This work is based on: > http://www.winehq.org/pipermail/wine-patches/2008-October/062460.html > > In this new patch series I calculate size like this: > > const int outer = 2; > int resizeBorder = GetSystemMetrics(SM_CXFRAME) - > GetSystemMetrics(SM_CXDLGFRAME); > int size = 2*(outer + resizeBorder); > > I took this formular from dlls/user32/nonclient.c: > ------------------ > adjust = 0; > if ((exStyle & WS_EX_DLGMODALFRAME) || > (style & (WS_THICKFRAME|WS_DLGFRAME))) adjust = 2; /* outer */ > } > if (style & WS_THICKFRAME) > adjust += ( GetSystemMetrics (SM_CXFRAME) > - GetSystemMetrics (SM_CXDLGFRAME)); /* The resize > border */ > ------------------ > > While writing this test I also tried some other styles and compared the > behavior between > CreateWindowEx and AdjustWindowRectEx. It didn't look like they have > much in common, that is why I didn't wrote the test against > AdjustWindowRectEx. > > Best regards, > Florian > > > > > From 762f49e2192b6d8477826c6535ef1ba0e1fd9d9b Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Florian=20K=C3=B6berle?= <florian(a)fkoeberle.de> Looks like you've botched the encoding somehow... > + test_thick_child_size(hwndMain); // causes test_capture_2() to fail Don't use C++ style comments, use C (/* comment */) instead. -- -Austin

2 1

Re: tools/fnt2bdf: fix a few compiler warnings (1/10)
by Michael Stefaniuc 16 Nov '08

16 Nov '08

Austin English wrote: > This series of patches fixes most of the new warnings generated in gcc > 4.3.2. There's one issue left, but I'm not quite sure what should be > done on that one. > diff --git a/tools/fnt2bdf.c b/tools/fnt2bdf.c > index 1a14d6c..3c3134b 100644 > --- a/tools/fnt2bdf.c > +++ b/tools/fnt2bdf.c > @@ -595,14 +595,14 @@ int main(int argc, char **argv) > > if( !(lpfont = (unsigned char*) realloc( lpfont, length )) ) > { >- fprintf(stderr, errorMemory ); >+ fprintf(stderr, "%s", errorMemory ); Ugly. You could just use fputs instead. But if you know that the passed in strings are safe aka no format specifiers in them you can leave the code as is as the compiler warning is bogus. > exit(1); > } bye michael

3 3

Re: [PATCH 1/7] msi: Add more tests for the CompLocator part of the AppSearch action.
by Paul Vriens 16 Nov '08

16 Nov '08

James Hawkins wrote: > --- > dlls/msi/tests/package.c | 526 +++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 421 insertions(+), 105 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, I was looking at why on Win9x there were some registry entries left behind with the package tests. It had to do with creating the UserData keys (which doesn't exist at all on win9x/winme btw.) within test_complocator (by calling set_component_path) and trying to delete them with a W-function (that isn't present on win9x/winme by default). I did some further testing on several platforms and it turns out the test_complocator succeeds even without creating those registry keys in the first place (tested on Win98, W2K3 and Wine). The attached 'patch' just excludes the registry entry creation/deletion. Am I completely missing something or can this registry creation/deleted be removed from that test? -- Cheers, Paul. diff --git a/dlls/msi/tests/package.c b/dlls/msi/tests/package.c index 47ffa35..3c128f0 100644 --- a/dlls/msi/tests/package.c +++ b/dlls/msi/tests/package.c @@ -7906,6 +7906,7 @@ static void test_complocator(void) CreateDirectoryA("olorotitan", NULL); CreateDirectoryA("pantydraco", NULL); +#if 0 set_component_path("abelisaurus", MSIINSTALLCONTEXT_MACHINE, "{E3619EED-305A-418C-B9C7-F7D7377F0934}", NULL, FALSE); set_component_path("bactrosaurus", MSIINSTALLCONTEXT_MACHINE, @@ -7922,6 +7923,7 @@ static void test_complocator(void) "{8B1034B7-BD5E-41ac-B52C-0105D3DFD74D}", NULL, FALSE); set_component_path("neosodon", MSIINSTALLCONTEXT_MACHINE, "{0B499649-197A-48EF-93D2-AF1C17ED6E90}", NULL, FALSE); +#endif r = MsiDoAction(hpkg, "AppSearch"); ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r); @@ -8039,6 +8041,7 @@ static void test_complocator(void) RemoveDirectoryA("neosodon"); RemoveDirectoryA("olorotitan"); RemoveDirectoryA("pantydraco"); +#if 0 delete_component_path("{E3619EED-305A-418C-B9C7-F7D7377F0934}", MSIINSTALLCONTEXT_MACHINE, NULL); delete_component_path("{D56B688D-542F-42Ef-90FD-B6DA76EE8119}", @@ -8055,6 +8058,7 @@ static void test_complocator(void) MSIINSTALLCONTEXT_MACHINE, NULL); delete_component_path("{0B499649-197A-48EF-93D2-AF1C17ED6E90}", MSIINSTALLCONTEXT_MACHINE, NULL); +#endif DeleteFileA(msifile); }

1 0

uninitialized reference in wineconsole in call to WriteConsoleInput?
by Dan Kegel 16 Nov '08

16 Nov '08

One more of the 100 valgrind warnings; this one is in kernel32/tests/console.c (but really in wineconsole). It's code Eric wrote six years ago, and the fix might be as straightforward as using memcpy(&ir, 0, sizeof(ir)) in WCUSER_GenerateMouseInputRecord(). Is there a better fix? Short form: SyscallParam wine_server_call WriteConsoleInputW WCUSER_GenerateMouseInputRecord WCUSER_Proc call_window_proc WINPROC_call_window DispatchMessageW WCUSER_MainLoop WinMain main Long form: <kind>SyscallParam</kind> <what>Syscall param writev(vector[...]) points to uninitialised byte(s)</what> <stack> <frame> <obj>dlls/ntdll/ntdll.dll.so</obj> <fn>wine_server_call</fn> <dir>dlls/ntdll</dir> <file>server.c</file> <line>248</line> </frame> <frame> <obj>dlls/kernel32/kernel32.dll.so</obj> <fn>WriteConsoleInputW</fn> <dir>dlls/kernel32/../../include/wine</dir> <file>server.h</file> <line>61</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_GenerateMouseInputRecord</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1087</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_Proc</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1186</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>call_window_proc</fn> <dir>dlls/user32</dir> <file>winproc.c</file> <line>458</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>WINPROC_call_window</fn> <dir>dlls/user32</dir> <file>winproc.c</file> <line>2212</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>DispatchMessageW</fn> <dir>dlls/user32</dir> <file>message.c</file> <line>3108</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_MainLoop</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1378</line> </frame> <origin> <what>Uninitialised value was created by a stack allocation</what> <stack> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_GenerateMouseInputRecord</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1066</line> </frame> </stack> </origin>

2 1

Re: Race in thread shutdown in imm32?
by Ge van Geldorp 15 Nov '08

15 Nov '08

> From: "Rob Shearman" <robertshearman(a)gmail.com> > > I believe that Windows terminates all threads on process > exit It does, see http://blogs.msdn.com/oldnewthing/archive/2007/05/03/2383346.aspx

1 0

Re: OLEAUT32: implement OleLoadPictureFile(Ex) and add tests
by Detlef Riekenberg 14 Nov '08

14 Nov '08

On Mi, 2008-11-12 at 23:40 -0800, Jeremy Drake wrote: I have no Idea about that area, but the unicode API is not implemented on win9x (GetTempFileNameW, CreateFileW, DeleteFileW) > if(!pOleLoadPictureFile || !pOleLoadPictureFileEx) Are there systems in the Wild that have OleLoadPictureFile, but are missing OleLoadPictureFile? In that case, you should use 2 seperate tests. > skip("Skipping OleLoadPictureFile tests\n"); Think, what you would see in the log before your text: "filename.c:__LINE__: Tests skipped:" "Skipping" is redundant and "tests" also. The usual way would be: skip("OleLoadPictureFile not found\n"); When you want to make sure, that we never skip in Wine here, then use win_skip instead. -- By by ... Detlef

1 1

Re: gdiplus: fix GdipFlattenPath for already-flat paths and add a test
by Vincent Povirk 14 Nov '08

14 Nov '08

Please ignore this patch. It has a line removed that shouldn't be. Vincent Povirk On Fri, Nov 14, 2008 at 5:07 PM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > >

1 0

RFC: Wine Icons
by Joel Holdsworth 14 Nov '08

14 Nov '08

Hi All, I notice that some of Wine's icons have been changed in recent releases. In principle I think updating the icons is a great idea, but right now I gotta say that icons in Wine are a real disaster. Take a look here: http://www.airwebreathe.org.uk/icons.png This is a screenshot of the shell folder select dialog. Out of those icons My Documents looks the least broken - with it's wannabe 98/ME/2000 styling. Desktop, "/", My Computer and Trash look like they've been taken from large icons which have shrunk - badly, and with a broken alpha channel. And the new golden Folder icons look completely out of place - they bear no resemblance to anything else, they've been scaled down poorly, they don't look like Windows icons, and they don't fit in with the Gnome desktop (and I can't imagine they'd look good in KDE or on Mac either). I'd really like for Wine to start using icons from the Tango project, or similar. The purpose of Tango was to create a set of icons that are clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely that's exactly what we want? Note that ReactOS is using Tango, and it seems to be working out pretty well for them! Any comments on that? Best Regards Joel Holdsworth

3 4

Re: RFC: Wine Icons
by Branan Riley 14 Nov '08

14 Nov '08

On Fri, Nov 14, 2008 at 9:43 AM, Branan Riley <branan(a)gmail.com> wrote: > On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth > <joel(a)airwebreathe.org.uk> wrote: >> Hi All, >> >> I notice that some of Wine's icons have been changed in recent releases. >> In principle I think updating the icons is a great idea, but right now I >> gotta say that icons in Wine are a real disaster. >> >> Take a look here: http://www.airwebreathe.org.uk/icons.png >> >> This is a screenshot of the shell folder select dialog. Out of those >> icons My Documents looks the least broken - with it's wannabe 98/ME/2000 >> styling. Desktop, "/", My Computer and Trash look like they've been >> taken from large icons which have shrunk - badly, and with a broken >> alpha channel. And the new golden Folder icons look completely out of >> place - they bear no resemblance to anything else, they've been scaled >> down poorly, they don't look like Windows icons, and they don't fit in >> with the Gnome desktop (and I can't imagine they'd look good in KDE or >> on Mac either). >> >> I'd really like for Wine to start using icons from the Tango project, or >> similar. The purpose of Tango was to create a set of icons that are >> clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely >> that's exactly what we want? >> >> Note that ReactOS is using Tango, and it seems to be working out pretty >> well for them! >> >> Any comments on that? >> >> Best Regards >> Joel Holdsworth > > The problem with hardcoding Tango is that it won't necessarily match > the user's desktop. > > On Linux and FreeBSD, I'd suggest finding a way to detect the current > icon theme (perhaps determine which desktop environment is running, > then read the config file for that desktop?) and use the > freedesktop.org icon names and the XDG_DATA_DIRS variable to locate > the icons. This wouldn't work on KDE3 (which doesn't use the > freedesktop spec). In that case I would say fall back to the hicolor > icons. > > On Mac, you should use the native mac icons, but that might not work > to do Obj-C issues (I know nothing about mac programming, so maybe > there's a way to get native icons without Obj-C?). > > This way, when theming is implemented, the icons and the theme will > both match the user's desktop environment. It's more complicated than > just implementing Tango, but visually it makes more sense. > > Branan Thinking about this a bit more, it would require a tool to generate the .DLL with the icons we want from the freedesktop spec, in order to maintain compatibility with Windows on how system icons are handled. This could be done once when the prefix is created, with an option in winecfg to re-build the icon DLL.

2 1

Re: Revert "quartz: Reaching a renderer in the filtergraph is not an error."
by Lei Zhang 14 Nov '08

14 Nov '08

On Fri, Nov 14, 2008 at 1:54 PM, Maarten Lankhorst <maarten(a)codeweavers.com> wrote: > This is plain wrong, input pin and output pin are supposed to be connected > to each other, not the input pin being connected to a renderer pin and NOT > reaching output pin > --- > > From 0f91e8a67c88d1ec0871c772679871249fd7625f Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <maarten(a)codeweavers.com> > Date: Fri, 14 Nov 2008 22:50:34 +0100 > Subject: [PATCH] Revert "quartz: Reaching a renderer in the filtergraph is > not an error." > > This reverts commit 62a0bd65d2fe9febd6928ff5912e84a34f76a97f. > --- > dlls/quartz/filtergraph.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index b249724..c53771e 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -1042,8 +1042,9 @@ static HRESULT WINAPI > FilterGraph2_Connect(IFilterGraph2 *iface, IPin *ppinOut, > if (SUCCEEDED(hr)) { > unsigned int i; > if (nb == 0) { > - TRACE("Reached a renderer\n"); > - break; > + IPin_Disconnect(ppinfilter); > + IPin_Disconnect(ppinOut); > + goto error; > } > TRACE("pins to consider: %d\n", nb); > for(i = 0; i < nb; i++) > -- > 1.5.6.5 > > > > > Correct, I got this one wrong. Please revert my patch and apply Maarten's patch to fix infinite recursion.

1 0