October 2010 - Wine-Devel - list.winehq.org

Re: (resend)[2/10]winegstreamer: add gstreamer splitter filter

by Vitaliy Margolen

On 10/25/2010 07:45 AM, Aric Stewart wrote: > --- > + ERR("++++++++++++++++ perform byte seek ------------------\n"); > + if (1 || This->initial) { > + ERR("Relinked\n"); > + FIXME("Seeking %i %i\n", format, GST_FORMAT_BYTES); > + FIXME("using \"%s\"\n", name); Some debug leftovers? > + AM_MEDIA_TYPE amt = { }; > .. > + ZeroMemory(&amt, sizeof(amt)); This is redundant. > sizeof(piOutput.achName) / sizeof(*piOutput.achName) The more common construct in Wine is sizeof(array)/sizeof(array[0]). IMHO it's better to stick with one Also could you please put an empty line in each function after variable declarations? Your patches look inconsistent. Vitaliy.

Oct. 25, 2010

Re: explorer: Create a standalone tray window wrapper if the driver doesn't provide native implementation. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch makes sure that "Shell_TrayWnd" window doesn't have a caption > since some apps depend on it being empty. The bug #20129 lists one of such > applications. It does FindWindow("Shell_TrayWnd", "") and expects that it > returns a valid tray window handle. This looks ugly when moving the window. The real systray should most likely be kept off-screen. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2010

Re: [PATCH 3/3] [Server]: fix access rights for console creation (#24792)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > server/console.c | 15 +++++++++++++-- > 1 files changed, 13 insertions(+), 2 deletions(-) It's not correct: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so console.c && touch console.ok console.c:789: Test failed: Shouldn't succeed console.c:790: Test failed: GetLastError: expecting 6 got 0 make: *** [console.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2010

Re: [PATCH] wininet: added one missing buffersize check in URLCache_CopyEntry (Coverity)

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > CID 831, indirectly spotted by Coverity, one missing > check for (*lpdwBufferSize >= dwRequiredSize) added. It doesn't work: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so urlcache.c && touch urlcache.ok urlcache.c:219: Test failed: RetrieveUrlCacheEntryFile failed with error 122 wine: Unhandled page fault on read access to 0x00000000 at address 0x6820cb08 (thread 0028), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2010

Re: [PATCH 1/3] [Kernel32]: don't force winedbg startup when no AeDebug key is present (#24524)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > - cmdline = HeapAlloc(GetProcessHeap(), 0, 80); > - snprintf(cmdline, 80, "winedbg --auto %ld %ld", /* as in tools/wine.inf */ > - (long)GetCurrentProcessId(), (long)HandleToLong(hEvent)); > + /* no AeDebug key present, just kill the program */ > + return FALSE; This means you don't get a backtrace if there's a crash before the initial registry creation is complete. I don't think that's a good idea. -- Alexandre Julliard julliard(a)winehq.org

Oct. 25, 2010

Re: [PATCH 2/3] [Msvcrt]: put in place the full scheme for paramter validation (the _s family of functions)

by Piotr Caban

Hi, Only debugging version of the dll is passing data to invalid_paramter_handler. I guess it's why we shouldn't do it. There already is a test for it in msvcr90 (see strtoi64 tests). Because it was not strict enough it will not show it very well. Currently it will not show that it was expecting invalid_parameter_handler to be invoked (but will fail checking errno that should not be changed). Of course this behavior may vary between msvcrXX dlls, I have tested it only with msvcr90 and msvcrt on Windows XP. Cheers, Piotr

Oct. 24, 2010

Re: [3/4] ddraw: fix DDSCAPS_3DDEVICE surfaces always setting DDSCAPS_VISIBLE

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6460 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Oct. 24, 2010

Re: [2/4] ddraw/tests: test some more caps combinations

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6459 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by James McKenzie

On 10/24/10 8:50 AM, Vitaliy Margolen wrote: > On 10/24/2010 12:32 AM, Marcus Meissner wrote: >> Actually I would like to know if its just more than the >> dlls/shell32/pidl.c >> problem... > Or just grep for '\[1\]' in include directory. Lots and lots of > declarations in all different places. > Stoopid question time. Is there a better method of declaring these than making them 2 char arrays? Can we 'assume' a maximum length and set them to that to prevent possible buffer overflows or is this something that we have to accept and work with? I understand that we want to keep the memory footprint for Wine as low as possible but we also don't want to introduce possible exploits in the process. James McKenzie

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Marcus Meissner

On Sun, Oct 24, 2010 at 09:50:42AM -0600, Vitaliy Margolen wrote: > On 10/24/2010 12:32 AM, Marcus Meissner wrote: > >Actually I would like to know if its just more than the dlls/shell32/pidl.c > >problem... > If you take a look at winternl.h you'll see number of structures > there look like: > typedef struct _foo { > ULONG length; > WCHAR buffer[1]; > } foo, *pfoo; > > Or just grep for '\[1\]' in include directory. Lots and lots of > declarations in all different places. As I already wrote, this works. Here is a sample code which shows the problem dlls/shell32/pidl.c has: $ cat xx1.c #include <string.h> #include <stdlib.h> struct foo { int x; char y[1]; }; union bar { struct foo fo; long y; float fl; }; struct berk { int t; union bar b; }; int main(int argc, char **argv) { struct berk *x1; struct foo *x2; x1 = malloc (sizeof(struct berk) + 5); x2 = malloc (sizeof(struct foo) + 5); strcpy(x1->b.fo.y, "hallo"); strcpy(x2->y, "hallo"); } $ gcc -O2 -Wall -D_FORTIFY_SOURCE=2 -g xx1.c -o xx1 xx1.c: In function ‘main’: xx1.c:28:1: warning: control reaches end of non-void function In file included from /usr/include/string.h:640:0, from xx1.c:1: In function ‘strcpy’, inlined from ‘main’ at xx1.c:26:8: /usr/include/bits/string3.h:107:3: warning: call to __builtin___strcpy_chk will always overflow destination buffer Only the "strcpy(x1->b.fo.y, "hallo");" with the nested struct is warned about, while the second strcpy works fine. It is just nested structs it does not like at this time. Ciao, Marcus

Oct. 24, 2010

Re: Test for window messages of a property sheet with custom dialog proc (bug 12104)

by Vitaliy Margolen

On 10/24/2010 05:20 AM, Bernhard Übelacker wrote: > If I got it right, tests which would fail in wine are prefixed with todo_wine? > > I want to ask if this patch looks right for inclusion and if the > location (dlls/comctl32/tests/) is right? > + /* disabled because todo_wine would fail because some messages arrive correct in wine No, it doesn't look right. If you testing for missing messages, then you should test all messages as done in some other places. See dlls/comctl32/tests/msg.h and where it's used. Vitaliy.

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Vitaliy Margolen

On 10/24/2010 12:32 AM, Marcus Meissner wrote: > Actually I would like to know if its just more than the dlls/shell32/pidl.c > problem... If you take a look at winternl.h you'll see number of structures there look like: typedef struct _foo { ULONG length; WCHAR buffer[1]; } foo, *pfoo; Or just grep for '\[1\]' in include directory. Lots and lots of declarations in all different places. Vitaliy.

Oct. 24, 2010

Re: Re : missing tests in test.winehq.org

by Paul Vriens

On 10/24/2010 01:51 PM, paulo lesgaz wrote: > but nothing at > http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_… > for instance. (And to list, I should remember to hit the correct button). That's because there are no failures/skips for ddraw:drawmodes on that platform. What did you expect to see? -- Cheers, Paul.

Oct. 24, 2010

Re: Re : missing tests in test.winehq.org

by André Hentschel

Am 24.10.2010 13:51, schrieb paulo lesgaz: > but nothing at > http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_… > for instance. > > A+ > > David > > ------------------------------------------------------------------------ > *De :* Paul Vriens <paul.vriens.wine(a)gmail.com> > *À :* paulo lesgaz <jeremielapuree(a)yahoo.fr> > *Cc :* wine-devel(a)winehq.org > *Envoyé le :* Dim 24 octobre 2010, 11h 43min 24s > *Objet :* Re: missing tests in test.winehq.org > > On 10/24/2010 09:23 AM, paulo lesgaz wrote: >> Hello, >> >> looking at http://test.winehq.org, i remarked that the file >> ddraw/tests/ddrawmodes does not exist and so it is never tested. > > What about: > > http://test.winehq.org/data/tests/ddraw:ddrawmodes.html > > or am I missing something? > > -- > Cheers, > > Paul. When one OS type has nothing to report for a test, then it is not listed. -- Best Regards, André Hentschel

Oct. 24, 2010

Re : missing tests in test.winehq.org

by paulo lesgaz

but nothing at http://test.winehq.org/data/8c5718ec9d0613be7208e1ceaecac0e7434c4cf5/index_… for instance. A+ David ________________________________ De : Paul Vriens <paul.vriens.wine(a)gmail.com> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Dim 24 octobre 2010, 11h 43min 24s Objet : Re: missing tests in test.winehq.org On 10/24/2010 09:23 AM, paulo lesgaz wrote: > Hello, > > looking at http://test.winehq.org, i remarked that the file > ddraw/tests/ddrawmodes does not exist and so it is never tested. What about: http://test.winehq.org/data/tests/ddraw:ddrawmodes.html or am I missing something? -- Cheers, Paul.

Oct. 24, 2010

Test for window messages of a property sheet with custom dialog proc (bug 12104)

by Bernhard Übelacker

Hello, the attached patch consists of a test case for following bug: http://bugs.winehq.org/show_bug.cgi?id=12104 This test shows how cygwin's setup checks if a WM_SIZE message was received (by the custom window proc). In wine only the property page gets such a message - not the sheet. If I got it right, tests which would fail in wine are prefixed with todo_wine? I want to ask if this patch looks right for inclusion and if the location (dlls/comctl32/tests/) is right? Kind regards, Bernhard

Oct. 24, 2010

Re: missing tests in test.winehq.org

by Paul Vriens

On 10/24/2010 09:23 AM, paulo lesgaz wrote: > Hello, > > looking at http://test.winehq.org, i remarked that the file > ddraw/tests/ddrawmodes does not exist and so it is never tested. What about: http://test.winehq.org/data/tests/ddraw:ddrawmodes.html or am I missing something? -- Cheers, Paul.

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Alexandre Julliard

Kees Cook <kees(a)ubuntu.com> writes: > It seems to me that disabling FORTIFY_SOURCE is a mistake. It offers > a great many protections, and virtually every distribution has very > intentionally turned on this compiler flag by default. Given Wine's > size[1], I would argue the benefits[2] outweigh the hassle of rearranging > the structures and accessors to not trick the compiler into allocating > memory beyond the end of the structure for incoming strings. > > It has found, at least in other projects, a lot of potential problems, > and better yet, has repeatedly turned exploitable vulnerabilities into > simple denial of services. So far in Wine, all it has done is repeatedly turn perfectly valid code into denial of service. Actually, even if Fortify worked correctly, the benefits would most likely be small, given that we make little use of the standard libc functions. Though given the trouble we've had so far, I shudder to think what would happen if we used libc functions all over the place. Fortify is a nice idea in theory, and I'd certainly encourage developers to enable it to see if it catches anything useful. But at this point it's not reliable enough to be forced upon end users. -- Alexandre Julliard julliard(a)winehq.org

Oct. 24, 2010

Re: new

by Michael Sgier

Yes I've tried that a good while ago without result. So I wonder how to proceed now. Thanks --- On Sat, 10/23/10, Ricardo Filipe <ricardojdfilipe(a)gmail.com> wrote: From: Ricardo Filipe <ricardojdfilipe(a)gmail.com> Subject: Re: new To: "Michael Sgier" <scrat_is_here(a)yahoo.com> Cc: wine-devel(a)winehq.org Date: Saturday, October 23, 2010, 10:14 PM 2010/10/23 Michael Sgier <scrat_is_here(a)yahoo.com> HiI'm new to this but know that MS Flight Simulator would one need little tweak to run flight school etc. (already worked once) So I've downloaded git and would be thankful for hints on how to proceed and find those bugs in FS9. I also would prefer using Eclipse/Linux, but anyway thanks for help.Many thanksMichael hi michael! if it has already worked before you need to do some regression testing to see when the new error was introduced. http://wiki.winehq.org/RegressionTesting as far as using eclipse or whatever that's your choice. use what you feel confortable with to compile and test code. have fun :)

Oct. 24, 2010

missing tests in test.winehq.org

by paulo lesgaz

Hello, looking at http://test.winehq.org, i remarked that the file ddraw/tests/ddrawmodes does not exist and so it is never tested. Does anyone have an explanation for this fact? A+ David

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Marcus Meissner

On Sun, Oct 24, 2010 at 03:44:35PM +0900, Dmitry Timoshkov wrote: > Marcus Meissner <marcus(a)jet.franken.de> wrote: > > > Actually I would like to know if its just more than the dlls/shell32/pidl.c > > problem... > > It's the problem with any storage declared as something[1], there are plenty > of them in win32, and that's perfectly valid code. Actually FORTIFY knows those constructs in standalone structs and handles them correctly. It is only if they are embedded within another struct or unions when it has problems. Ciao, Marcus

Oct. 24, 2010

Re: ddraw: Add tests for the foreground window set by SetCooperativeLevel

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6448 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Dmitry Timoshkov

Marcus Meissner <marcus(a)jet.franken.de> wrote: > Actually I would like to know if its just more than the dlls/shell32/pidl.c > problem... It's the problem with any storage declared as something[1], there are plenty of them in win32, and that's perfectly valid code. > (And of course also the stupid warn_unused_results warning spam, which we > disabled already.) It's also infamous "longjmp causes uninitialized stack frame": http://bugs.winehq.org/show_bug.cgi?id=21405 -- Dmitry.

Oct. 24, 2010

Re: disabling FORTIFY_SOURCE

by Marcus Meissner

On Sat, Oct 23, 2010 at 11:54:27PM +0000, Dan Kegel wrote: > Hi Kees, > sure, supporting Fortify in Wine would be great, but it's not > clear how long it will take to fix Wine so it works with Fortify. > > Which would you prefer: > 1) have Wine broken for an unknown and possibly long time > or > 2) have Wine working, but without Fortify, until the bugs are fixed > ? Actually I would like to know if its just more than the dlls/shell32/pidl.c problem... (And of course also the stupid warn_unused_results warning spam, which we disabled already.) Ciao, Marcus

Oct. 24, 2010

Between IGF Demo is Unresponsive (Steam Client and Wine 1.3.2)

by Singapore Citizen Mr. Teo En Ming 张恩鸣

Dear All, When I click on the Play button for Between IGF Demo in Steam client, a window pops up and hangs there. Nothing is displayed in the popped up window. It just hangs there. Anybody know what happens? Please refer to screenshot. [1] http://imgur.com/3Mky4.png [2] http://i55.tinypic.com/dxz6nq.png [3] http://img218.imageshack.us/img218/4595/aa3steamclientwine132.png [4] http://img2.uploadhouse.com/fileuploads/6751/67514722a40f9a6544b45081e58dd0… Please assist in troubleshooting the problem. Thank you very much for your kind assistance. -- Yours sincerely, Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 Dip(Mechatronics) BEng(Hons)(Mechanical Engineering) Singapore Identity Card No.: S78*6*2*H Location: Bedok Reservoir Road, Singapore ZIP: 470103 Mobile Phone (Starhub Pre-paid): +65-8369-2618 Windows Live Messenger: teoenming-at-hotmail.com My Youtube videos: http://www.youtube.com/user/enmingteo Alma Maters: [1] Singapore Polytechnic (Graduated 1998) [2] National University of Singapore (Graduated 2006) My Open Letter (Plea for Medical Help/Assistance) to World Leaders (Updated 28 August 2010):- http://lists.mcs.anl.gov/pipermail/mpich-discuss/2010-August/007811.html http://mythtv.org/pipermail/mythtv-users/2010-August/295952.html http://archives.gentoo.org/gentoo-user/msg_f6a341d9623fda17880159b137c07335… Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #1: http://i54.tinypic.com/2415z7t.jpg Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #2: http://img842.imageshack.us/img842/7534/enmingteodscf2511.jpg

Oct. 24, 2010

Alien Swarm Does Not Launch (Steam Client and Wine 1.3.2)

by Singapore Citizen Mr. Teo En Ming 张恩鸣

Dear All, When I try to click the Play button for Alien Swarm in the Steam client, the game does not launch at all. Do you know what happens? Please assist in troubleshooting the problem. Thank you very much for your kind assistance. -- Yours sincerely, Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 Dip(Mechatronics) BEng(Hons)(Mechanical Engineering) Singapore Identity Card No.: S78*6*2*H Location: Bedok Reservoir Road, Singapore ZIP: 470103 Mobile Phone (Starhub Pre-paid): +65-8369-2618 Windows Live Messenger: teoenming-at-hotmail.com My Youtube videos: http://www.youtube.com/user/enmingteo Alma Maters: [1] Singapore Polytechnic (Graduated 1998) [2] National University of Singapore (Graduated 2006) My Open Letter (Plea for Medical Help/Assistance) to World Leaders (Updated 28 August 2010):- http://lists.mcs.anl.gov/pipermail/mpich-discuss/2010-August/007811.html http://mythtv.org/pipermail/mythtv-users/2010-August/295952.html http://archives.gentoo.org/gentoo-user/msg_f6a341d9623fda17880159b137c07335… Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #1: http://i54.tinypic.com/2415z7t.jpg Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #2: http://img842.imageshack.us/img842/7534/enmingteodscf2511.jpg

Oct. 23, 2010

America's Army 3 (AA3Game.exe) Crashes with Steam Client and Wine 1.3.2

by Singapore Citizen Mr. Teo En Ming 张恩鸣

Dear All, Please refer to attached screenshot of America's Army 3 Program Error. [1] http://imgur.com/3Mky4.png [2] http://i55.tinypic.com/dxz6nq.png [3] http://img218.imageshack.us/img218/4595/aa3steamclientwine132.png [4] http://img2.uploadhouse.com/fileuploads/6751/67514722a40f9a6544b45081e58dd0… Please assist in troubleshooting the problem. I have set the Default Settings in Application Settings in winecfg to "Windows 7". Thank you very much for your kind assistance. -- Yours sincerely, Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 Dip(Mechatronics) BEng(Hons)(Mechanical Engineering) Singapore Identity Card No.: S78*6*2*H Location: Bedok Reservoir Road, Singapore ZIP: 470103 Mobile Phone (Starhub Pre-paid): +65-8369-2618 Windows Live Messenger: teoenming-at-hotmail.com My Youtube videos: http://www.youtube.com/user/enmingteo Alma Maters: [1] Singapore Polytechnic (Graduated 1998) [2] National University of Singapore (Graduated 2006) My Open Letter (Plea for Medical Help/Assistance) to World Leaders (Updated 28 August 2010):- http://lists.mcs.anl.gov/pipermail/mpich-discuss/2010-August/007811.html http://mythtv.org/pipermail/mythtv-users/2010-August/295952.html http://archives.gentoo.org/gentoo-user/msg_f6a341d9623fda17880159b137c07335… Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #1: http://i54.tinypic.com/2415z7t.jpg Photo of Singapore Citizen Mr. Teo En Ming (Zhang Enming) 张恩鸣 #2: http://img842.imageshack.us/img842/7534/enmingteodscf2511.jpg

Oct. 23, 2010

re: disabling FORTIFY_SOURCE

by Dan Kegel

Hi Kees, sure, supporting Fortify in Wine would be great, but it's not clear how long it will take to fix Wine so it works with Fortify. Which would you prefer: 1) have Wine broken for an unknown and possibly long time or 2) have Wine working, but without Fortify, until the bugs are fixed ?

Oct. 23, 2010

Re: new

by Ricardo Filipe

2010/10/23 Michael Sgier <scrat_is_here(a)yahoo.com> > Hi > > I'm new to this but know that MS Flight Simulator would one need little > tweak to run flight school etc. (already worked once) > > So I've downloaded git and would be thankful for hints on how to proceed > and find those bugs in FS9. I also would prefer using Eclipse/Linux, but > anyway thanks for help. > > Many thanks > > Michael > > > hi michael! if it has already worked before you need to do some regression testing to see when the new error was introduced. http://wiki.winehq.org/RegressionTesting <http://wiki.winehq.org/RegressionTesting>as far as using eclipse or whatever that's your choice. use what you feel confortable with to compile and test code. have fun :)

Oct. 23, 2010

Re: [PATCH 7/7] configure: disable fortify the right way

by Marcus Meissner

On Sat, Oct 23, 2010 at 09:08:06AM -0600, Charles Davis wrote: > On 10/23/10 3:39 AM, Alexandre Julliard wrote: > > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > >> Hi, > >> > >> $EXTRACFLAGS is used before $CFLAGS, so the previous try would not work. > >> > >> Also just -U the define. > > > > Won't this break if the default is set through a header? Do all distros > > do this only through CFLAGS? > Nope. Mac OS sets it in <_types.h>: > > #ifndef _FORTIFY_SOURCE > # if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && > ((__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0) < 1050) > # define _FORTIFY_SOURCE 0 > # else > # define _FORTIFY_SOURCE 2 /* on by default */ > # endif > #endif Then I would suggest adding to CFLAGS: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 Otherwise for CFLAGS="..." ./configure you get redefinition warnings for every file. Ciao, Marcus

Oct. 23, 2010

disabling FORTIFY_SOURCE

by Kees Cook

Hi, It seems to me that disabling FORTIFY_SOURCE is a mistake. It offers a great many protections, and virtually every distribution has very intentionally turned on this compiler flag by default. Given Wine's size[1], I would argue the benefits[2] outweigh the hassle of rearranging the structures and accessors to not trick the compiler into allocating memory beyond the end of the structure for incoming strings. It has found, at least in other projects, a lot of potential problems, and better yet, has repeatedly turned exploitable vulnerabilities into simple denial of services. I realize it's a bit of a pain to work with given how you're building some of the structures, but I'd like to ask that it not be globally disabled. Thanks, -Kees [1] $ find . -type f -name '*.[ch]' | xargs wc -l | grep total 2678911 total [2] Some details at https://wiki.ubuntu.com/CompilerFlags#-D_FORTIFY_SOURCE=2 but at least the following... Compile time: - static buffer length checks - missed return values - open() checks for missing mode when used with O_CREAT Run time: - dynamic buffer length checks - dynamic format string safety check - dynamic format position safety checks Functions with buffer length (or other) checks: asprintf confstr dprintf fgets fgetws fprintf fread fwprintf getcwd getdomainname getgroups gethostname getlogin_r gets getwd longjmp mbsnrtowcs mbsrtowcs mbstowcs memcpy memmove mempcpy memset pread64 pread printf ptsname_r read readlinkat readlink realpath recv recvfrom snprintf sprintf stpcpy stpncpy strcat strcpy strncat strncpy swprintf syslog ttyname_r vasprintf vdprintf vfprintf vfwprintf vprintf vsnprintf vsprintf vswprintf vsyslog vwprintf wcpcpy wcpncpy wcrtomb wcscat wcscpy wcsncat wcsncpy wcsnrtombs wcsrtombs wcstombs wctomb wmemcpy wmemmove wmempcpy wmemset wprintf -- Kees Cook Ubuntu Security Team

Oct. 23, 2010

Re: [PATCH 7/7] configure: disable fortify the right way

by Charles Davis

On 10/23/10 3:39 AM, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > >> Hi, >> >> $EXTRACFLAGS is used before $CFLAGS, so the previous try would not work. >> >> Also just -U the define. > > Won't this break if the default is set through a header? Do all distros > do this only through CFLAGS? Nope. Mac OS sets it in <_types.h>: #ifndef _FORTIFY_SOURCE # if defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && ((__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__-0) < 1050) # define _FORTIFY_SOURCE 0 # else # define _FORTIFY_SOURCE 2 /* on by default */ # endif #endif Chip

Oct. 23, 2010

Font config in Desktop Integration broken when switching locales

by cheer_xiao

---------- Forwarded message ---------- From: cheer_xiao <xiaqqaix(a)gmail.com> Date: Fri, Oct 22, 2010 at 5:06 PM Subject: Font config in Desktop Integration broken when switching locales To: wine-users(a)winehq.org As a translator, It is frequent for me to switch between locales (en_US.utf8 and zh_CN.utf8 for me), but the font configurations in winecfg/'Desktop Integration' gets broken under certain circumstances. To demonstrate, I run winecfg with LANG=zh_CN.utf8, and set the 'Menu Text' (菜单文字) font to 'WenQuanYi Zen Hei Sharp' (文泉驿点阵正黑) 10pt (shot00.png). It turns out fine (shot01.png), but with LANG=en_US.utf8 the menu text font is a mess (shot02.png). The configuration under zh_CN.utf8 fails to work under en_US.utf8. However, if I run winecfg with LANG=en_US.utf8, and redo the setting (shot10.png, shot11.png), the configuration works under both locales (shot12.png, shot13.png). The configuration made under en_US.utf8 is more "portable". An interesting phonomenum is that in shot10.png, the font configuration seems to have been "reset", ie. it is the font on the top of the list, with the minimum size. This also happens when you configure the font (menu text font here) for the very first time so it must be some kind of default value. The configuration under zh_CN.utf8 was not recognized by winecfg under en_US.utf8, thus falling back to the default. However, during font rendering such fallbacks are not functioning properly (the fallback itself shouldn't be happening though), resulting in the boxes in shot02.png. I guess this issue is due to a bug of how winecfg saves the font configurations and/or how these configurations are used during font rendering. Could anyone explain and/or fix this? I have been looking up the registry but the configurations appear to be stored somewhere else. BTW: Another problem is also observed. Every time I run wine programs (like winecfg, notepad) with LANG=zh_CN.utf8 I get lots of: fixme:msvcrt:_setmbcp trail bytes data not available for DBCS codepage 0 - assuming all bytes I run Wine compiled from the git repo (just a day or two ago) on Ubuntu 10.10. Default locale is en_US.utf8.

Oct. 23, 2010

Re: [PATCH 7/7] configure: disable fortify the right way

by Marcus Meissner

On Sat, Oct 23, 2010 at 11:39:45AM +0200, Alexandre Julliard wrote: > Marcus Meissner <marcus(a)jet.franken.de> writes: > > > Hi, > > > > $EXTRACFLAGS is used before $CFLAGS, so the previous try would not work. > > > > Also just -U the define. > > Won't this break if the default is set through a header? Do all distros > do this only through CFLAGS? Hmm. openSUSE/SUSE sets it via RPM_OPT_FLAGS -> CFLAGS. Unsure about Redhat. Ciao, Marcus

Oct. 23, 2010

Re: [PATCH 7/7] configure: disable fortify the right way

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Hi, > > $EXTRACFLAGS is used before $CFLAGS, so the previous try would not work. > > Also just -U the define. Won't this break if the default is set through a header? Do all distros do this only through CFLAGS? -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2010

new

by Michael Sgier

HiI'm new to this but know that MS Flight Simulator would one need little tweak to run flight school etc. (already worked once)So I've downloaded git and would be thankful for hints on how to proceed and find those bugs in FS9. I also would prefer using Eclipse/Linux, but anyway thanks for help.Many thanksMichael

Oct. 23, 2010

Re: winegstreamer error with 'make install'

by Paul Vriens

On 10/22/2010 09:37 PM, Reece Dunn wrote: > On 22 October 2010 20:07, Paul Vriens<paul.vriens.wine(a)gmail.com> wrote: >> Hi, >> >> Current Git (Fedora 13) gives me: >> >> /usr/bin/install -c winegstreamer.so >> /usr/local/lib64/wine/winegstreamer.so >> /usr/bin/install: cannot stat `winegstreamer.so': No such file or directory >> >> There is a winegstreamer.dll.so in this directory. >> >> Anyone? > > The '.dll' part is missing in the `install` command. > > - Reece (Now to list as well) Sure, but why? Am I the only one? -- Cheers, Paul.

Oct. 22, 2010

Re: winegstreamer error with 'make install'

by Reece Dunn

On 22 October 2010 20:07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Current Git (Fedora 13) gives me: > > /usr/bin/install -c winegstreamer.so > /usr/local/lib64/wine/winegstreamer.so > /usr/bin/install: cannot stat `winegstreamer.so': No such file or directory > > There is a winegstreamer.dll.so in this directory. > > Anyone? The '.dll' part is missing in the `install` command. - Reece

Oct. 22, 2010

winegstreamer error with 'make install'

by Paul Vriens

Hi, Current Git (Fedora 13) gives me: /usr/bin/install -c winegstreamer.so /usr/local/lib64/wine/winegstreamer.so /usr/bin/install: cannot stat `winegstreamer.so': No such file or directory There is a winegstreamer.dll.so in this directory. Anyone? -- Cheers, Paul.

Oct. 22, 2010

Re: explorer: Create a standalone tray window wrapper if the driver doesn't provide native implementation. Take 2.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6432 Your paranoid android. === W7PROX64 (64 bit win) === win.c:2684: Test failed: GetActiveWindow() = 0000000000000000 win.c:2684: Test failed: GetFocus() = 0000000000000000 win.c:2710: Test failed: GetActiveWindow() = 0000000000000000 win.c:2710: Test failed: GetFocus() = 0000000000000000 win.c:2769: Test failed: GetActiveWindow() = 0000000000000000 win.c:2769: Test failed: GetFocus() = 0000000000000000

Oct. 22, 2010

Re: [3/3] msxml3: implement domdoc schema validation

by Nikolay Sivov

On 10/22/2010 01:27, Adam Martinson wrote: > --- > dlls/msxml3/domdoc.c | 127 > ++++++++++++++++++++++++++++++++------------ > dlls/msxml3/tests/domdoc.c | 4 +- > 2 files changed, 94 insertions(+), 37 deletions(-) > + TRACE("doc not well-formed, returning error 0xC00CE223\n"); > if (err) > - *err = create_parseError(0, NULL, NULL, NULL, 0, 0, 0); > + *err = create_parseError(0xC00CE223, NULL, NULL, NULL, 0, 0, 0); You should add corresponding error code defines for that. This one is E_XML_NOTWF.

Oct. 22, 2010

Re: [1/3] msxml3: libxml2 error/warning callback functions

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > +#define LIBXML2_OUTPUT_CALLBACK void __WINE_PRINTF_ATTR(2,3) > +#define LIBXML2_OUTPUT_CALLBACK_BODY(caller, dbcl, msg) \ > + do { \ > + va_list ap; \ > + char* buf; \ > + int len; \ > + va_start(ap, msg); \ > + len = vsnprintf(NULL, 0, msg, ap); \ > + buf = heap_alloc(len+1); \ > + vsnprintf(buf, len+1, msg, ap); \ > + va_end(ap); \ > + wine_dbg_log(__WINE_DBCL##dbcl, __wine_dbch___default, #caller, buf); \ > + heap_free(buf); \ > + } while (0) > + > +#define LIBXML2_XMLERROR_CALLBACK void > +#define LIBXML2_XMLERROR_CALLBACK_BODY(caller, err) \ > + do { \ > + enum __wine_debug_class dbcl = __WINE_DBCL_ERR; \ > + switch (err->level) \ > + { \ > + case XML_ERR_NONE: \ > + dbcl = __WINE_DBCL_TRACE; \ > + break; \ > + case XML_ERR_WARNING: \ > + dbcl = __WINE_DBCL_WARN; \ > + break; \ > + default: \ > + break; \ > + } \ > + wine_dbg_log(dbcl, __wine_dbch___default, #caller, err->message); \ > + } while (0) That's ugly, please write the code explicitly instead of using macros, it's not that much code. -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2010

Fwd: Invitation: Apply to be a Mentoring Organization for GCI

by Dan Kegel

This looks interesting... ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Mon, Oct 18, 2010 at 3:10 PM Subject: Invitation: Apply to be a Mentoring Organization for GCI To: Google Summer of Code Mentors List <google-summer-of-code-mentors-list(a)googlegroups.com> Hi everyone, Starting today we are accepting applications from organizations who have participated in a previous Google Summer of Code (you!) to get involved with our contest for 13-18 year olds, Google Code-in [0]. If you haven’t read up about Google Code-in, you can check out our announcement [1] to this list from a couple weeks ago or read our blog post [2] about the contest. If your org has decided it would like to apply to participate in the contest, you can fill out the application [3] on Melange now. The deadline for applications is 29 October at 23:00 UTC. Also, if you want to look over the rules for the contest before applying to participate they can be found on the organization application [3] at the bottom. They will also be posted on the Google Code-in website [0] in the next couple days in other languages. We hope your org will consider participating. [0] - http://code.google.com/gci [1] - http://groups.google.com/group/google-summer-of-code-mentors-list/msg/0985e… [2] - http://google-opensource.blogspot.com/2010/10/google-code-in-schools-out-co… [3] - http://socghop.appspot.com/gci/org_app/take/gci_program/google/gci2010/orga… Cheers, Carol -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en.

Oct. 22, 2010

Re: explorer: Create a standalone tray window wrapper if the driver doesn't provide native implementation.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch makes sure that "Shell_TrayWnd" window doesn't have a caption > since some apps depend on it being empty. The bug #20129 lists one of such > applications. It does FindWindow("Shell_TrayWnd", "") and expects that it > returns a valid tray window handle. It can't work the way you are doing it, FindWindow won't find a child window. -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2010

Re: (resend) [PATCH] mscms: Handle bitmap formats BM_xRGBQUADS in from_bmformat( BMFORMAT format ) which is used by TranslateBitmapBits

by Hans Leidekker

On Thu, 2010-10-21 at 17:52 +0200, Tomasz Michno wrote: Please mark your patches with something like (try X) and comment on the changes you made in the same e-mail. Use (resend) when you resend a patch without making any changes. > +/* defines copied from lcms.h: > + */ > +#define INTENT_PERCEPTUAL 0 > +#define INTENT_RELATIVE_COLORIMETRIC 1 > +#define INTENT_SATURATION 2 > +#define INTENT_ABSOLUTE_COLORIMETRIC 3 These should be added to icm.h. I'll send a patch. > + ret=pTranslateBitmapBits(transform, (void*)bitmapBits, > + ok( ret, "BGR: TranslateBitmapBits() succeeded (%d)\n", There's no need to cast to void *. The sense of that error message is wrong. It's displayed when the condition evaluates to false, so it should be 'failed'. And it happens to fail on Windows: transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87)

Oct. 22, 2010

Re: ddraw [patch 2/2 | RESEND]: SETFOCUSWINDOW lives independently of other flags

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6427 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Oct. 22, 2010

Re: ddraw [patch 2/2]: SETFOCUSWINDOW lives independently of other flags

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6424 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Oct. 21, 2010

Re: (resend) [PATCH] mscms: Handle bitmap formats BM_xRGBQUADS in from_bmformat( BMFORMAT format ) which is used by Translat

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6423 Your paranoid android. === W98SE (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2KPROSP4 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === WXPPROSP3 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2K3R2SESP2 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === WVISTAADM (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W2K8SE (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PRO (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PROX64 (32 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87) === W7PROX64 (64 bit transform) === transform.c:127: Test failed: RGB: TranslateBitmapBits() succeeded (87) transform.c:137: Test failed: BGR: TranslateBitmapBits() succeeded (87) transform.c:142: Test failed: GRAY: TranslateBitmapBits() succeeded (87) transform.c:155: Test failed: xRGB/1: TranslateBitmapBits() succeeded (87) transform.c:167: Test failed: xRGB/2: TranslateBitmapBits() succeeded (87)

Oct. 21, 2010

Re: ddraw [patch 1/2]: Remove a useless else

by Henri Verbeet

On 21 October 2010 22:28, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Trailing spaces.

Oct. 21, 2010

Re: Reflection interfaces

by Rico Schüller

Am 19.10.2010 12:25, schrieb Henri Verbeet: > 2010/10/18 Rico Schüller<kgbricola(a)web.de>: > >> What's the preferred way to implement the different interfaces? >> >> 1. Implement a parser which parses the shader (RDEF, STAT), and implement 4 >> independent interfaces (each in its own dll). Only reuse the parser. >> 2. Like 1, but all 4 implementations have there own parser, which leads to a >> lot of duplicated code. But it is the most flexible way. It could easily >> parse all possible shader blobs (theoretically they could differ from >> version to version, I have no test for that, yet). >> 3. Forward all interfaces to d3dcompiler_43.dll and this will contain all >> interfaces and the parser. This way the codebase is the smallest possible >> one, but it will offer all interfaces, which isn't what native does. Also >> all further interfaces would go to d3dcompiler_43.dll. This could get >> tricky. >> >> > I'm not sure. The problem with 3 is that it will prevent using the > native d3dcompiler to work around e.g. the missing HLSL compiler > because it doesn't implement ID3D10ShaderReflection etc. Perhaps we > don't care in the long term, but at least in the short term that would > be a problem. Option 1 would require d3dcompiler to have some private > interface or entry point, and you'd still have the same problem as > with option 3. Option 2 leads to duplicated code. > > There may be an option 4 though, which would be to implement the older > interfaces on top of ID3D11ShaderReflection. I.e., you'd use the > information you get from the ID3D11ShaderReflection interface to > construct constant buffers and variables for the other interfaces, > instead of parsing the shader bytecode yourself. It would need some > investigation to determine how feasible this option is. > > Yeah option 4 sounds very well. The problem I see with that is if there is a newer interface that adds a new interface function where the values couldn't be quarried by an older one. (I'm not sure if this would happen.) Then we would have to move the code to the newest function. I guess that older functions/variable will be always there in newer interfaces. But if it is really a showstopper we could move from option 4 to option 3 if that would really be required. So we start with option 4 and implement the ID3D11ShaderReflection interface in d3dcompiler_43. Any other opinions? Cheers Rico

Oct. 21, 2010