wine-devel November 2008

wine-devel@winehq.org

110 participants
239 discussions

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

DIB Engine
by Massimo Del Fedele 16 Nov '08

16 Nov '08

I recently had a chat with Dan Kegel about the way to contribute and start hacking on a DIB engine. I grabbed Huw Davies and Jesse Allen's repositories and started looking at them. As it'll be an hard (and long) work, I'd like to know some opinions on how to proceed and propose an idea on how to have it introduced in mainstream without breaking stuff. The idea is, for now, JUST an idea and I still don't know if it'll be possible, but I guess yes. So, I was thinking on : 1) Try to join best stuffs of both repos of Huw and Jesse. 2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) : missing DIBENGINE env var or DIBENGINE=NONE New dib engine will not be used, back to X11DRV DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest using new dib engine code DIBENGINE=FULL use just dib engine code and shows FIXMEs for unimplemented stuffs The first would allow to insert dib engine in main stream without breaking anything, the last would allow to see what's more important to implement. The middle one (FORWARD) would allow to check if something breaks during the transition, and use the developed parts. 3) Stop and wait till it's put on mainstream, so more people could contribute. The doubt is if it'll be possible the mixed approach, forwarding unimplemented stuffs to X11, but I think so. Is it an acceptable way to proceed ? Ciao Max

4 11

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

← Newer
1
...
11
12
13
14
15
16
17
...
24
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2008