wine-devel March 2010

wine-devel@winehq.org

102 participants
263 discussions

Re: (try 3) wineaudiofile.acm: Initial commit
by Alexandre Julliard 16 Mar '10

16 Mar '10

Aric Stewart <aric(a)codeweavers.com> writes: > Supported mp3 decoding on OSX Leopard systems. > Expandable to Tiger and other formats fairly easily. It looks like almost all of that code is duplicated from winemp3, so there doesn't seem to be much reason to make it a separate dll. -- Alexandre Julliard julliard(a)winehq.org

1 0

asserts in wine
by Reece Dunn 16 Mar '10

16 Mar '10

Hi, After seeing Gerald Pfeifer's patch, I decided to see how many asserts were used in wine. $ find . -type f -iname *.c -exec grep -H assert '{}' \; > assert1.log This returns 2313 matching lines, some of which are including <assert.h>. $ cat assert1.log | sed -e 's/:.*//' | sort | uniq -c | sort -n > assert2.log This shows that there are 454 files that make use of assert, of which 166 files only reference assert once. $ cat assert2.log | grep " 1 " | sed -e 's/ *1 //' | xargs grep -H "#include <assert.h>" > assert3.log This shows that 151 files pull in assert.h but don't reference it in the c file, so could be removed. NOTE: The results are out by a few files as some of the results just have assert in a comment (such as dlls/wined3d/arb_program_shader.c). ----- As a general principle, assert in: 1/ tests should be changed to an ok and possibly a skip -- otherwise, the test results are reported as a crash, making it harder to find out where the problem is. 2/ dlls should be changed to a SetLastError or failure return code (depending on the API) -- otherwise, the program triggering this will be killed with no information as to what happened. 3/ tools should print an error message indicating the problem (failed to allocate memory, could not open file, ...) preferably with as much information as possible (file does not exist, user does not have privileges to open/write to file, ...) -- this is to make it easier to see what the problem is and correct it. 4/ server -- not sure here, but this should ideally return an error code to the caller (APIs?) so it can be handled by that API/program. 5/ programs should display an error to the user (e.g. MessageBox) indicating the nature of the problem (file does not exist, ...) in a way that is understandable by the user and (if possible) recover from the error, or otherwise inform the user that the application cannot recover (e.g. out of memory). - Reece

3 2

Re: [PATCH 01/10] ntdll: Fixup imports after CREATE_PROCESS_DEBUG_EVENT.
by Alexandre Julliard 16 Mar '10

16 Mar '10

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c > index 1723f18..fbdda00 100644 > --- a/dlls/ntdll/loader.c > +++ b/dlls/ntdll/loader.c > @@ -2533,10 +2533,14 @@ PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule) > */ > static NTSTATUS attach_process_dlls( void *wm ) > { > + LPCWSTR load_path; > NTSTATUS status; > > pthread_sigmask( SIG_UNBLOCK, &server_block_set, NULL ); > > + load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer; > + if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) return status; > + > RtlEnterCriticalSection( &loader_section ); > if ((status = process_attach( wm, (LPVOID)1 )) != STATUS_SUCCESS) > { > @@ -2622,7 +2626,6 @@ void WINAPI LdrInitializeThunk( void *kernel_start, ULONG_PTR unknown2, > static const WCHAR globalflagW[] = {'G','l','o','b','a','l','F','l','a','g',0}; > NTSTATUS status; > WINE_MODREF *wm; > - LPCWSTR load_path; > PEB *peb = NtCurrentTeb()->Peb; > IMAGE_NT_HEADERS *nt = RtlImageNtHeader( peb->ImageBaseAddress ); > > @@ -2652,8 +2655,6 @@ void WINAPI LdrInitializeThunk( void *kernel_start, ULONG_PTR unknown2, > if ((status = server_init_process_done()) != STATUS_SUCCESS) goto error; > > actctx_init(); > - load_path = NtCurrentTeb()->Peb->ProcessParameters->DllPath.Buffer; > - if ((status = fixup_imports( wm, load_path )) != STATUS_SUCCESS) goto error; > if ((status = alloc_process_tls()) != STATUS_SUCCESS) goto error; > if ((status = alloc_thread_tls()) != STATUS_SUCCESS) goto error; > heap_set_debug_flags( GetProcessHeap() ); You can't change the order of operations, for instance tls setup has to be done after import fixup. Also I expect this will break Safedisc code injection, you should add tests for the non-debugged case too. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH 1/3] kernel32/tests: Add test for 'all processors' flag on Vista and newer.
by Joerg-Cyril.Hoehle＠t-systems.com 16 Mar '10

16 Mar '10

Hi, Erich Hoover wrote: >so if we're not testing >the version we wouldn't know that it got removed. This is a very valid point. For instance, I'm currently writing a test that will read ok(1234123123==mhdr.dwOffset || broken(0==mhdr.dwOffset/*w9x,nt*/) ...) i.e. w2k+xp+Vista+7 differ from w95+98+me+nt. The Wine testsuite will not warn should MS-Windows ever revert back to w9x+nt behaviour. I've been fixing multimedia bugs in Wine, some of which were present for almost 10 years now. My point is: right *now* I'm closely looking at the exact behaviour under existing versions of MS-Windows (and having Wine mimick "modern" w2k/xp behaviour), yet the broken() mechanism prevents the tests from noticing when that behaviour will change next time. Patches these days make Wine implement the now "modern" behaviour, but remember modern is relative and tests with broken() will fail to report any future change... Until, perhaps again in ten years, somebody will look closely at the results, perhaps triggered by a bug report. Why wait for a bug report? Somehow, I feel that not noticing changes in behaviour is a waste of the test automation resources. broken() shadows broken (not valid any more) assumptions. Every now and then I wish there were a switch to disable broken() entirely and see what test.winehq reports for the various OS. E.g. $WINETEST_STRICT=1 => have broken() always yield 0/false. The goal to reach becomes WINETEST_STRICT=1 => no test failures on the system Wine purports to mimick (currently XP(?)). (Seems like a good idea, expect a patch soon ;) Regards, Jörg Höhle Well, at least the above example of broken() is much stricter than ok(!rc||broken(rc/*w9x*/)) == anything goes What does such a test tell except impose Wine's rc?

4 5

Re: [PATCH] cmd: removed %CD% test.
by Paul Vriens 16 Mar '10

16 Mar '10

On 03/16/2010 10:53 AM, Yann Droneaud wrote: > %CD% seems not supported on Windows NT 4. > > The patch which introduce this test was based on MSDN documentation > and only tested on Windows XP Hi Yann, Winetestbot (https://winetestbot.geldorp.nl/index.pl) provides you with several Windows flavors for testing purposes. -- Cheers, Paul.

1 0

Re: [PATCH] cmd: added some expansion tests. (try 2)
by Paul Vriens 16 Mar '10

16 Mar '10

On 03/09/2010 01:15 PM, Yann Droneaud wrote: > diff --git a/programs/cmd/tests/test_builtins.cmd b/programs/cmd/tests/test_builtins.cmd > index ed2b75b..e346ffa 100644 > --- a/programs/cmd/tests/test_builtins.cmd > +++ b/programs/cmd/tests/test_builtins.cmd > @@ -23,6 +23,21 @@ cd dummydir > echo %~dp0 > cd .. > rmdir dummydir > +echo %CD% Hi Yann, This one doesn't work on NT4: http://test.winehq.org/data/tests/cmd.exe:batch.html Could you have a look ? -- Cheers, Paul.

2 1

Re: [PATCH] [WineDbg]: allow to specify which format to be used for integers in backtraces
by Dmitry Timoshkov 16 Mar '10

16 Mar '10

Eric Pouech <eric.pouech(a)orange.fr> wrote: > Gdb uses decimal notation by default for integers, so do we. GDB can use anything their developers think appropriate, my patch to use hex was intended to match Wine's relay traces and win32 header constants. This patch will make finding matches impossible again. -- Dmitry.

1 0

Re: wined3d: Fix ATI2N pitch and offset calculations
by Stefan Dösinger 16 Mar '10

16 Mar '10

Am 16.03.2010 um 01:36 schrieb REalm: > Fix ATI2N calculations to match Windows. > Not sure if this is the right way, but it's better than previous old try. > Might also be possible making ATI2N non compressed surface? Or some special flag? > This also fixes bug 21519: Mass Effect 2 crashes after start. > - {WINED3DFMT_ATI2N, 4, 4, 16}, > + {WINED3DFMT_ATI2N, 1, 1, 1}, This way is OK IMO, it's certainly better than adding a special flag for just this surface. What we may think about is migrating all surfaces to the block notation and using blocksize 1x1, bpp bytes per block for uncompressed surfaces. That's beyond the scope of this patch though.

1 0

re: .net 3.5sp1 status check, blocking GFWL
by Dan Kegel 16 Mar '10

16 Mar '10

The appdb for another game, Fallout 3, http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322 suggests "1) Download msasn1.dll from e.g. here 2) Override msasn1.dll in Wine Configuration. How to Override DLL 3) Download gfwlivesetupmin.exe from e.g. here 4) Install gfwlivesetupmin.exe but without .NET Framework 5) Only set xlive to native in Wine Configuration." The playonlinux script for that game, http://www.playonlinux.com/repository/?script=402 shows that the way to do 4) is wine gfwlivesetupmin.exe /nodotnet Does that help? I guess winetricks should add a gfwl verb that does that, but we would need a better source for msasn1.dll. There might be a usable one inside http://download.microsoft.com/download/d/b/4/db49275f-7741-47cc-b8d5-42a312… can somebody try it? And then, as http://wiki.winehq.org/msasn1 suggests, we ought to implement msasn1 in wine. - Dan

3 3

Re: [9/9] shell32/shellview: Don't crash on ::DragLeave called without droptraget
by Paul Vriens 15 Mar '10

15 Mar '10

On 03/13/2010 10:10 PM, Nikolay Sivov wrote: > That causes a crash in Office 2k3 Save As menu at least, while trying to drapdrop something. > Hi Nikolay, These new tests (don't know which ones of the patchset) introduce test failures on Vista+: http://test.winehq.org/data/tests/shell32:shlview.html Could you have a look? -- Cheers, Paul.

1 0

← Newer
1
...
14
15
16
17
18
19
20
...
27
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 March 2010