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

Re: wine.inf: Remove obsolete and duplicate entries.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 02:08 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Dear reviewers, > > Vitaliy Margolen wrote in the discussion of bug #20693: >> Those entries shouldn't be in the wine.inf in the first place >> (as Alexandre already said). If anything they should be removed >>from there to lessen the confusion. > > Here is a patch to remove those entries. Note that > I'm not familiar enough with the printing system or MS-Windows' > expected vital entries to judge whether the entries should be present > as default fallbacks on systems compiled without cups, > or which have no printer, > or because some apps on MS-Windows crash if they are not present > even when there's no printer > or whatever reason. I just trust your word. > > All I can see is that these entries about [HKLM\HARDWARE] do not make > it into system.reg on my Linux machine even though they are present in > wine.inf, I suppose because the dynamic device detection code > (hal/dbus) removes them (with no printer nor cups-dev installed). > > Regards, > Jörg Höhle > Hi Jörg, This was already (partly) done in commit d19e2ada9ce2d52d8b09e984fe5b12803bf6d4ca. -- Cheers, Paul.

1 0

Re: mciavi: Simplify play loop.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 01:51 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > in the future, MCIAVI will hopefully be able to drive the loop > with either audio or video turned on or off individually > (setaudio/setvideo off), like native (e.g. mciavi can play > the audio tracks only). > Here's a first step towards unification. > > Regards, > Jörg Höhle > Tabs and space mixtures here as well. -- Cheers, Paul.

1 0

Re: mciqtz32: Fix open/close omissions.
by Paul Vriens 30 Nov '09

30 Nov '09

On 11/30/2009 01:47 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Regards, > Jörg Höhle > Hi Jörg, You're mixing tabs and spaces here. -- Cheers, Paul.

1 0

Re: [1/3] WineD3D: Infrastructure to render swapchains to a FBO
by Henri Verbeet 30 Nov '09

30 Nov '09

2009/11/30 Stefan Dösinger <stefan(a)codeweavers.com>: > I think this will break color_fill_fbo(). My general feeling is that I'm seeing to much variants of "if (swapchain->render_to_fbo)". Also, I think this patch has parts that can be separated like e.g. the surface_init_sysmem() bit. Out of curiosity, what would the performance impact be of always rendering to FBO?

2 2

Re: gdi32 : Correction of bug 20850 Write buffer overflow in WidenPath()
by Dan Kegel 30 Nov '09

30 Nov '09

On Sat, Nov 28, 2009 at 5:04 PM, Laurent Vromman <laurent(a)vromman.org> wrote: > - pStrokes = HeapAlloc(GetProcessHeap(), 0, numStrokes * > sizeof(GdiPath*)); > - pStrokes[0] = HeapAlloc(GetProcessHeap(), 0, sizeof(GdiPath)); > - PATH_InitGdiPath(pStrokes[0]); > - pStrokes[0]->pFlags = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(INT)); > - pStrokes[0]->pPoints = HeapAlloc(GetProcessHeap(), 0, > pPath->numEntriesUsed * sizeof(POINT)); > - pStrokes[0]->numEntriesUsed = 0; > + pStrokes = NULL; ... Wait, wouldn't it be simpler to keep the initial alloc, as in the attachment? - Dan

3 4

RFC: EM_FORMATRANGE Patch for Wine-1.1.33
by James McKenzie 30 Nov '09

30 Nov '09

All: Time to beat on this patch again and make it better. I've also attached it to bug 6254. Please make comments constructive. I would like to get assistance where to break this down so that it will be 'easier to swallow' pieces as this is one huge patch that AJ has rejected before. James McKenzie

1 0

windows shutdown process
by Vincent Povirk 29 Nov '09

29 Nov '09

In order to find the correct fix for bug 18753, I've been examining the shutdown process on Windows. I have written a program that logs the messages sent to it, and I've run it on Windows 7. What I found was that a shutdown produces the following sequence of events: * We get a 0x3b message. DefWindowProc sends a WM_QUERYENDSESSION message. We return 1, allowing the session to end. * We get another 0x3b message, which leads to a WM_ENDSESSION. * Nothing else happens, but for some reason the program exits. I added a trace after the message loop returns to see if the program gets a WM_QUIT. It doesn't. Apparently, my test program was killed. I tried changing the window proc so that it loops infinitely when it gets WM_ENDSESSION. Windows 7 sees this as "blocking shutdown". (Naturally, it responds the same way if I return 0 from WM_QUERYENDSESSION.) This leads me to believe that Windows 7, when shutting down, immediately kills any process that returns from a WM_ENDSESSION message. Does that seem sane? I've posted my test program (source code and .exe file) at http://madewokherd.nfshost.com/msgtest.zip, and I'd like to hear if other Windows versions behave the same way Windows 7 does. -- Vincent Povirk

2 2

Re: kernel32.dll: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)
by Rob Shearman 29 Nov '09

29 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > --- ./dlls/kernel32/locale.c.orig 2009-11-02 05:45:10.000000000 +0200 > +++ ./dlls/kernel32/locale.c 2009-11-26 19:35:39.000000000 +0200 > @@ -3017,7 +3017,7 @@ > RtlInitUnicodeString( &keyName, szKeyName ); > InitializeObjectAttributes(&attr, &keyName, 0, hRootKey, NULL); > > - if (NtOpenKey( &hkey, KEY_ALL_ACCESS, &attr ) != STATUS_SUCCESS) > + if (NtOpenKey( &hkey, MAXIMUM_ALLOWED, &attr ) != STATUS_SUCCESS) > hkey = 0; > > return hkey; This is ugly. The function should be changed to allow the required access rights to be specified. -- Rob Shearman

1 0

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible
by Rob Shearman 29 Nov '09

29 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > @@ -376,7 +376,7 @@ > InitializeCriticalSection(&(*db)->cs); > > err = RegCreateKeyExW(HKEY_LOCAL_MACHINE, SZ_SERVICES_KEY, 0, NULL, > - REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, > + REG_OPTION_NON_VOLATILE, MAXIMUM_ALLOWED, NULL, > &(*db)->root_key, NULL); > if (err != ERROR_SUCCESS) > HeapFree(GetProcessHeap(), 0, *db); I'm not happy with this change because the code was written with the assumption that data it will always have permission to write data back to keys under root_key. The return value from save_service_config isn't always checked and thus this could lead to silent data loss. In any event, the use of MAXIMUM_ALLOWED should not be encouraged where at all possible [1] and instead the code should try the most permissions it needs and fall back to less as appropriate. > @@ -417,7 +417,7 @@ > break; > > WINE_TRACE("Loading service %s\n", wine_dbgstr_w(szName)); > - err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ | KEY_WRITE, &hServiceKey); > + err = RegOpenKeyExW(db->root_key, szName, 0, KEY_READ, &hServiceKey); > if (err == ERROR_SUCCESS) > { > err = load_service_config(hServiceKey, entry); This change is fine since hServiceKey is only every used with operations that require KEY_READ at the most. -- Rob Shearman [1] http://blogs.msdn.com/larryosterman/archive/2004/09/14/229658.aspx

1 0

Re: advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible
by Rob Shearman 29 Nov '09

29 Nov '09

2009/11/27 Paul Chitescu <paulc(a)voip.null.ro>: > Changelog: > advapi32.dll: Reduce Registry access to MAXIMUM_ALLOWED wherever possible > > Makes read operation succeed on read/only Registry keys. Needs tests to show that this behaviour matches that on Windows. You should be able to achieve this by setting an appropriate security descriptor on the registry key before calling the function you are changing. However, the change to get_special_root_hkey looks fine to me. The rest of your patch isn't easy to review because you haven't generated the diff with the "-p" option. -- Rob Shearman

1 0