January 2009 - Wine-Devel - list.winehq.org

Re: First complete test run passing on a Windows platform

by Zachary Goldberg

2009/1/29 Dan Kegel <dank(a)kegel.com>: > Wow, that's awesome! A day seven years in the making... > 2009: the test suite passes for somebody besides Alexandre on Wine: > http://www.winehq.org/wwn/355#Test%20Suite%20Passes! We'll have a new link to WWN 356 for Test Suite Passes v2 : Windows Style :) Congrats to the whole team! Now we need to get patchwatcher back up again and working on windows to ensure this behavior doesn't go away! -Zach

Jan. 30, 2009

Re: report on obscure issues: running out of file handles with python under wine

by Vitaliy Margolen

Luke Kenneth Casson Leighton wrote: > also note it's file descriptors not file handles There are no such thing as "handle" in *NIX world. The only thing matter is a file descriptor. But it's for files, directories, devices, etc. Wine takes care of all the handles internally (one of the main tasks for wineserver). Wineserver has a really big handle limit: #define MAX_HANDLE_ENTRIES 0x00ffffff I really doubt you overrunning that. And you would see messages in the terminal if Wine can't allocate anymore FDs. Vitaliy.

Jan. 30, 2009

Re: Wined3d being used with VirtualBox D3D

by Jaime Rave

This bug is related to that http://bugs.winehq.org/show_bug.cgi?id=17190 2009/1/29 Zachary Goldberg <zgold(a)bluesata.com> > All, > > An interesting piece from Phoronix about new VirtualBox Direct3D > support; which apparently uses WineD3D in the backend. I haven't > noticed anything in particular but has Sun been filing bugs / sending > patches? > > http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA > > --Zach > > >

Jan. 30, 2009

Wined3d being used with VirtualBox D3D

by Zachary Goldberg

All, An interesting piece from Phoronix about new VirtualBox Direct3D support; which apparently uses WineD3D in the backend. I haven't noticed anything in particular but has Sun been filing bugs / sending patches? http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA --Zach

Jan. 30, 2009

Re: dinput: Move gain support from effect to device

by Vitaliy Margolen

Vincent Pelletier wrote: > Hi. > > Windows supports setting force feedback effect gain at 2 levels: > - device > - effect > There is support for the former on Linux, but not for the latter. > > > + DWORD ff_gain; > }; ... > + This->ff_gain = max(0, (int) pd->dwData); First why do you typecase DWORD to (int) to assign to DWORD? Second DWORD will always be > 0. If you want to check it against limit then just check it being <= 10000 otherwise return error. > + if (This->joyfd != -1) { You should be checking This->base.acquired instead of fd. > + event.value = This->ff_gain * 0xFFFF / 10000; You should use MulDiv instead because this can be optimized out by compiler into something that won't be as accurate. Vitaliy.

Jan. 30, 2009

re: First complete test run passing on a Windows platform

by Dan Kegel

Wow, that's awesome! A day seven years in the making... 2002: the C test suite is started: http://source.winehq.org/git/wine.git/?a=commit;h=caa03388bcccc64f444f9b4ef… 2003: winetest committed: http://www.winehq.org/wwn/199#Winetest%20Integrated%20&%20Future%20Steps 2004: server to build winetest and parse winetest results set up http://www.winehq.org/wwn/216#A%20Distributed%20Test%20Environment 2009: the test suite passes for somebody besides Alexandre on Wine: http://www.winehq.org/wwn/355#Test%20Suite%20Passes! Anyone have a graph of test suite size vs. time?

Jan. 29, 2009

Re: A proposal for increased security in wine - respecting previously expressed needs

by Rob Shearman

2009/1/29 Alex Villacís Lasso <a_villacis(a)palosanto.com>: > Guillaume SH escribió: >> Hi wine community, >> >> I took some time for reflexion following the thread "A step in the wrong >> direction, in an ocean of steps in the right direction" and to the >> explanations some of you kindly exposed to me. >> >> As a follow-up I am making a proposal. >> >> A - The proposal >> >> A1 - The core proposal >> >> All function callable from outside wine should implement, as the first >> task they perform(1), a sanity parameter check. This check >> hasn't to be systematic, only really used parameters should be checked >> and only checks assuring those parameters can be safely used >> the way they are in the function implementation (or in a function >> called by it). Other check are superfluous and must be discarded. >> >> So to decline the proposal operationally, I will take an example(2) : >> >> BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED >> lpOverlapped, [...]) >> >> if ( lpOverlapped == NULL ) >> { >> #Call the function ExitWineCleanlyAndAdvertiseUser >> } >> >> >> This call being justified by the statement, following some lines later : >> status = lpOverlapped->Internal; >> >> >> The function ExitWineCleanlyAndAdvertiseUser being something like that : >> >> <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters to >> be determined> >> >> #1 - Advertise user outputting a message, for example : "The >> application you used present a defect. Using it directly expose you to some >> security issue and indirectly expose others users to some other >> security issue." >> >> #2 - Cleanly release all still allocated resources >> >> #3 - Cleanly exit wine >> >> >> A2 - offering flexibility >> >> As I have understood that wine community is willing to be able to run >> all applications written for a Windows platform, >> even those relying on the worse behaviours of windows, I will propose >> too to add a registry key for the purpose of enabling / disabling >> wine "safe" mode. >> In this case it would make sense that "safe" mode is the default, with >> possibility to fall-back to "unsafe" mode when needed. >> >> B - Advantages / Drawbacks to the proposal >> >> Drawback of this solution I can think of are : >> 1 - It is contrary to the current consensus >> 2 - It implies a lot of work (even if this can be done bit by bit over a >> long period time, direction is what matters here) >> 3 - Detailed implementation of what I presented may very well not be as >> simple as I imagine, or even impossible >> 4 - Maybe all the reasons have not been expressed in the previous >> thread, thus not considered here >> 5 - It can go against the interest of the author of those apps relying >> on Windows's bad behaviors (large firms for example) >> 6 - It doesn't cover all security issue in wine and it doesn't cover at >> all security issue in the calling app >> 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I >> don't know how to evaluate) >> >> Advantage of this solution I can think of are : >> 1 - Top-notch level of service to user : I can be informed when I use an >> unsafe software ! >> 2 - Encouragement to software industry : I must provide some clean and >> safe software or wine can judge me "unsafe" (=promoting "best-practices") >> 3 - Wine is better from it, so people will have a better opinion of wine >> 4 - Goal reached by wine are far beyond "Windows behaviours on free-OS >> platform" >> 5 - Wine is safer so more people will want to use it and to promote its >> usage >> >> >> I think I will go no further than this proposal, so I leave the rest to you, >> from simply ignoring it to demonstrate me than I'm wrong or applying a >> variation, >> Guillaume >> >> (1) TRACE, variable declaration or other task may come before though >> (2) Please don't argue about the coding style, I am not a technical expert >> (unlike you) and it would be off-topic >> >> > I think I remember a discussion about a particular bug in which some > version of an installer (InstallShield?) refused to work correctly > because the wine version of one API call was checking a pointer > parameter against NULL and returning an error code instead of crashing. > If I recall correctly, it turned out that the installer *expected* the > crash, and depended on the fault handler executing some code for its > correct operation. So the NULL check was removed, the API now crashes > with the invalid pointer (exactly like native) and that installer now > works correctly. Maybe somebody who was involved in the actual fix can > dig up a pointer to the relevant thread. http://www.winehq.org/pipermail/wine-devel/2006-July/049830.html http://bugs.winehq.org/show_bug.cgi?id=5384 -- Rob Shearman

Jan. 29, 2009

Quick and dirty testcases for MS-DOS API?

by Dan Kegel

Looking at http://bugs.winehq.org/show_bug.cgi?id=17181 I get a feeling that we really need some testcases to verify we conform to the 16 bit MS-DOS API. Yeah, even though 16 bit is on the way out, there's still some use for a few win16 programs, and they use MS-DOS for file I/O. We could merge in http://win16test.googlecode.com, but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty (unless you're on Ark Linux, see http://www.openwatcom.org/index.php/Installing_Open_Watcom_on_Linux ) And the Linux build had problems building DOS apps last time I tried anyway. But "apt-get install nasm" works great, so let's use it to run just a few crucial testcases, in particular, the one that keeps DOS apps from recursively deleting directories. What I'm thinking is to add a configure check for nasm. If it's present, and the target is 32 bit Intel, dlls/winedos/tests would use it to assemble a few simple assembly testcases. The test cases would be run from a normal test case (so no deep integration), and only when running on a machine capable of running 16 bit code. I'll probably have an include file for routines to print PASS and FAIL, but otherwise it'll be very, very bare bones. 'Course, I have no idea when I'll have time to do this, but I imagine it won't be too complicated. It wouldn't bother me at all if somebody beat me to it. - Dan

Jan. 29, 2009

First complete test run passing on a Windows platform

by Reece Dunn

Hi, The Wine tests are now passing on a Windows XP machine (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group…) Two of the other four only have 2 or 3 failures. The 2003 group has 3 machines with 1 failure each (urlmon:protocol on one, user32:menu on the others). Congratulations to everyone involved fixing the tests! - Reece

Jan. 29, 2009

Re: [1/3] d3dxof: Make parsing more permissive about semicolon and comma in objects

by Christian Costa

Hi Paul, I'm just sending a patch to fix that. Thanks for spotting. Bye, Christian Paul Vriens a écrit : > > Christian Costa wrote: >> >> >> ------------------------------------------------------------------------ >> >> > Hi Christian, > > + if ((token != TOKEN_SEMICOLON) && (token != TOKEN_COMMA)) > { > /* Allow comma instead of semicolon in some specific cases */ > if (!((token == TOKEN_COMMA) && ((i+1) < pt->nb_members) && > (pt->members[i].type == pt->members[i+1].type) > > This introduced a DEADCODE warning in Coverity. The code changed was > in d3dxof.c but was moved in a later patch to parsing.c. > > Could you have a look? >

Jan. 29, 2009