June 2006 - Wine-Devel - list.winehq.org

Ecco Pro hangs when accessing "2nd level" dialogs

by Don Dwiggins

I'm a heavy user of Ecco Pro on Windows, and am trying to port myself as completely as possible to Linux (Ubuntu currently). Wine does a good job of supporting most of Ecco's features, but there are a couple of places (unfortunately important ones) where it hangs up tight. I've just submitted Bug #5335 about this problem. I'm a long-time programmer with good (if rusty) knowledge of C/C++ and Unix, just getting up to speed on Linux. I'm at the point where I might be willing to tackle this myself, if the learning curve isn't too steep. I'm posting this to ask for guidance on the best way to proceed. At least, if there's a good way to get more information on the hangup, I'm definitely willing to add to the bug report. Thanks for any good words, -- Don Dwiggins don(a)dondwiggins.net "The truth will make you free, but first it will make you miserable" -- Tom DeMarco

June 1, 2006

MSI

by EA Durbin

My first analysis was incorrect, its not the compound statement that is broken, but the existing implementation of the WHERE statement in MSI SQL is broken. I've ran several tests to confirm this. I don't know how this can be replicated in windows, as the problem lies within the existing implementation of wine MSI SQL, the WHERE clause is returning the wrong values. SELECT * FROM TABLE WHERE Tablevalue >= testvalue should return greater than or equal to, regardless of what platform you run that query on, and it returns the wrong value in wines msi implementation. Further down in where.txt, which is the result of the WHERE query I saw the QUERY WHERE LastSequence > 1, was returning a 0 at disk 22, which is wrong. The ORDER BY QUERY works fine. The WHERE STATEMENT in the existing wine code is broken. I've ran several other tests, on multiple tables to verify this. My code I used for testing is included below if you would like to have a look at it. I queried the File table WHERE Sequence >= 8, and in the retuned values the SQL statement returned Sequences 1 to 7, which are less than 8, so the SQL statement isn't functioning properly. Example 1. I changed the sql statement in my installer to read the following at ready_media_for_file. SELECT * FROM Media WHERE LastSequence > %i , and it returns the 1st DiskId, with a LastSequence of 6, even after the LastSequence exceeds 6. The WHERE STATEMENT is broken in msi SQL. The installation of the first 6 .dlls works nicely, they are in my C: folder. trace:msi:ACTION_InstallFiles file paths L"C:\\windows\\temp\\FL_mfc71_dll_1_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" to L"C:\\mfc71.dll" trace:msi:ACTION_InstallFiles Pass 2: L"_a8c1851f3c994e35b6e28a65f4793745" trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Media` WHERE `LastSequence` >=7" 0x7fb8f794 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:MSI_ParseSQL Parse returned 0 trace:msi:ready_media_for_file LastSequence 6 trace:msi:ready_media_for_file Source is CAB L"Disk1.cab" Example 2: - query from the File table, also returns the wrong values I also tried querying another table to ensure it is the WHERE statement and not a table specific problem. here is the result of the SELECT * FROM File WHERE Sequence >= 8 Though this query doesn't return in sequential order like from the Media table, I did find numbers lower than 8 in the results trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `File` WHERE `Sequence` >= 8" 0x7fb8fa38 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 7 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 2 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 1 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 3 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 5 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 4 From: "EA Durbin" <ead1234(a)hotmail.com> To: dank(a)kegel.com CC: wine-devel(a)winehq.org Subject: Re: MSI query tests Date: Thu, 01 Jun 2006 21:51:20 -0500 1. The conformance test suite must run on Windows. This is necessary to provide a reasonable way to verify its accuracy. Furthermore the tests must pass successfully on all Windows platforms (tests not relevant to a given platform should be skipped). I don't know how I would run this on windows. I edited the wine code itself and queried tables in the MSI database to troubleshoot the behavior of the installer code. Then i retrieved the pertainent values from the results, as in the case of the file table i retrieved the sequence value being returned by the query http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/… Here is the code i used to iterate queries MSIQUERY * view; static const WCHAR ExecSeqQuery[] = {'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', '`','F','i','l','e','`',' ','W','H','E','R','E',' ','`','S','e','q','u','e','n','c','e','`',' ','>','=',' ','8',0}; rc = MSI_DatabaseOpenViewW( package->db, ExecSeqQuery, &view ); if ( rc != ERROR_SUCCESS ) return ERROR_SUCCESS; TRACE( "DEBUGGING SELECT * FROM File WHERE Sequence >= 8 \n" ); rc = MSI_IterateRecords( view, NULL, ITERATE_QueryTest, package ); return rc; static UINT ITERATE_QueryTest( MSIRECORD *row, LPVOID param ) { MSIPACKAGE *package = (MSIPACKAGE*)param; int fileSequence; fileSequence = MSI_RecordGetInteger( row, 8 ); TRACE( "File Sequence: %i \n", fileSequence ); return ERROR_SUCCESS; } and the Media table i returned the DiskId, cabinet, and LastSequence values from the results http://msdn.microsoft.com/library/en-us/msi/setup/media_table.asp?frame=true static UINT ITERATE_QueryTest( MSIRECORD *row, LPVOID param ) { MSIPACKAGE *package = (MSIPACKAGE*)param; int lastSequence, DiskId; LPWSTR cab; lastSequence = MSI_RecordGetInteger( row, 2 ); DiskId = MSI_RecordGetInteger( row, 1); cab = MSI_RecordGetString( row, 4) TRACE( " Last Sequence: %u \n", lastSequence ); TRACE( " CAB %s \n", debugstr_w( cab ) ); TRACE( " Disk ID %u \n", DiskId ); return ERROR_SUCCESS; } From: "Dan Kegel" <dank(a)kegel.com> To: "EA Durbin" <ead1234(a)hotmail.com> CC: wine-devel(a)winehq.org Subject: Re: MSI query tests Date: Thu, 1 Jun 2006 19:34:12 -0700 On 6/1/06, EA Durbin <ead1234(a)hotmail.com> wrote: >Great. Can you package up the tests as Wine conformance tests? I'm new to wine, how do I accomplish this? http://winehq.org/site/docs/winedev-guide/testing has an introduction to the subject. - Dan # From: Mike McCormack <mike(a)codeweavers.com> To: EA Durbin <ead1234(a)hotmail.com> CC: wine-devel(a)winehq.org Subject: Re: MSI Query tests Date: Fri, 02 Jun 2006 12:19:59 +0900 EA Durbin wrote: SELECT * FROM `Media` WHERE `LastSequence` > 1 that it returns the SQL statement correctly. Then in orderby.txt i query SELECT * FROM `Media` ORDER BY `LastSequence` and it returns the results as expected. Then in compoundsql.txt I query SELECT * FROM `Media` WHERE `LastSequence` > 1 ORDER BY `LastSequence`, which is just as the statement appears in InstallFiles(). In this query it ignores the WHERE CLAUSE and uses what is to the far right , the ORDER BY LastSequence statement, which first grabs the LastSequence of 0. Thanks for the analysis. Do you think you could add a test case to dlls/msi/tests/db.c that shows the correct behaviour of the above query on Windows for me? If you can do that, I'll have a go at fixing it... Mike

June 1, 2006

Re: MSI Query tests

by Mike McCormack

EA Durbin wrote: > SELECT * FROM `Media` WHERE `LastSequence` > 1 that it returns the SQL > statement correctly. > > Then in orderby.txt i query > SELECT * FROM `Media` ORDER BY `LastSequence` and it returns the results > as expected. > > Then in compoundsql.txt I query SELECT * FROM `Media` WHERE > `LastSequence` > 1 ORDER BY `LastSequence`, which is just as the > statement appears in InstallFiles(). > > In this query it ignores the WHERE CLAUSE and uses what is to the far > right , the ORDER BY LastSequence statement, which first grabs the > LastSequence of 0. Thanks for the analysis. Do you think you could add a test case to dlls/msi/tests/db.c that shows the correct behaviour of the above query on Windows for me? If you can do that, I'll have a go at fixing it... Mike

June 1, 2006

Re: MSI query tests

by Dan Kegel

On 6/1/06, EA Durbin <ead1234(a)hotmail.com> wrote: >> 1. The conformance test suite must run on Windows. This is necessary to >> provide a reasonable way to verify its accuracy. Furthermore the tests must >> pass successfully on all Windows platforms (tests not relevant to a given >> platform should be skipped). > > I don't know how I would run this on windows. I edited the wine code itself > and queried tables in the MSI database to troubleshoot the behavior of the > installer code. Then i retrieved the pertainent values from the results, as > in the case of the file table i retrieved the sequence value being returned > by the query You'll have to figure out a way to tickle the problem with a plain old Windows program written in C, I'm afraid. That's essentially what our conformance tests are. You can do it if you put your mind to it, I bet, but along the way you'll acquire an advanced degree in MSI-ology :-) - Dan

June 1, 2006

Lineage 2 crash

by Andres de Barbara

Hi. I triying to run this game in my linux box but it crash. runing : WINEDEBUG=+d3d,+ddraw,warn+all,+seh,+d3d_draw,trace+d3d_shader,trace+d3d_draw,trace+opengl winedbg l2.exe this is the backtrace First chance exception: page fault on read access to 0x6814d0c8 in 32-bit code (0x7e6f6dab). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7e6f6dab ESP:7fb956cc EBP:7fb95784 EFLAGS:00210202( - 00 - -RI1) EAX:6814d0c8 EBX:7e74cdcc ECX:7fdfdf38 EDX:681e002c ESI:7fdfdf38 EDI:681e002c Stack dump: 0x7fb956cc: 00000000 00000000 00000000 000000ff 0x7fb956dc: 7fb95714 b7f034f4 00000036 7ff8aa06 0x7fb956ec: 00000002 7ffdf0e8 00000036 7fb9579c 0x7fb956fc: 7ffdf0e8 7ffdece0 0000000e 7ffd5524 0x7fb9570c: 00000028 7e73fed7 7fb95744 7ff8aa9b 0x7fb9571c: 7e73fed7 7fb9579c 7e74d6c1 7e73ec3b Backtrace: =>1 0x7e6f6dab drawStridedSlow+0xdb(glPrimType=0x4, idxData=0x70d63b50, idxSize=0x2, minIndex=0x908, startIdx=0x0) [/home/adebarbara/wine/wine- 0.9.14~winehq1~ubuntu~6.06/dlls/wined3d/drawprim.c:1344] in wined3d (0x7e6f6dab) 2 0x7e6f79d5 drawPrimitiveDrawStrided+0x471(iface=0x70d00020, useVertexShaderFunction=0x0, usePixelShaderFunction=0x0, useHW=0x0, dataLocations=0x7fdfdf38, numberOfvertices=0x50f3, numberOfIndicies=0x8820, glPrimType=0x4, idxData=0x70d63b50, idxSize=0x2, minIndex=0x908, StartIdx=0x0) [/home/adebarbara/wine/wine- 0.9.14~winehq1~ubuntu~6.06/dlls/wined3d/drawprim.c:1914] in wined3d (0x7e6f79d5) 3 0x7e6fa8bb drawPrimitive+0x587(iface=0x70d00020, PrimitiveType=0x4, NumPrimitives=0x2d60, StartVertexIndex=0x0, numberOfVertices=0x50f3, StartIdx=0x0, idxSize=0x2, idxData=0x70d63b50, minIndex=0x908, DrawPrimStrideData=0x0) [/home/adebarbara/wine/wine- 0.9.14~winehq1~ubuntu~6.06/dlls/wined3d/drawprim.c:2164] in wined3d (0x7e6fa8bb) 4 0x7e6e1c0b IWineD3DDeviceImpl_DrawIndexedPrimitive+0x98(iface=0x70d00020, PrimitiveType=0x4, baseVIndex=0x0, minIndex=0x908, NumVertices=0x50f3, startIndex=0x0, primCount=0x2d60) [/home/adebarbara/wine/wine- 0.9.14~winehq1~ubuntu~6.06/dlls/wined3d/device.c:5609] in wined3d (0x7e6e1c0b) 5 0x7f185490 IDirect3DDevice8Impl_DrawIndexedPrimitive+0x88 in d3d8 (0x7f185490) 6 0x7ca79075 in d3ddrv (+0x19075) (0x7ca79075) 7 0x783210f5 in engine (+0x3410f5) (0x783210f5) 8 0x7828dc59 in engine (+0x2adc59) (0x7828dc59) 9 0x78260b92 in engine (+0x280b92) (0x78260b92) 10 0x7826345a in engine (+0x28345a) (0x7826345a) 11 0x781aebe6 in engine (+0x1cebe6) (0x781aebe6) 12 0x111049d4 in windrv (+0x49d4) (0x111049d4) 13 0x1110238e in windrv (+0x238e) (0x1110238e) 14 0x781b5fee in engine (+0x1d5fee) (0x781b5fee) 15 0x1090cb24 in l2 (+0xcb24) (0x1090cb24) 16 0x1090d9c2 in l2 (+0xd9c2) (0x1090d9c2) 17 0x10912611 in l2 (+0x12611) (0x10912611) 18 0x10919507 in l2 (+0x19507) (0x10919507) 19 0x7fc4b7cf in kernel32 (+0x4b7cf) (0x7fc4b7cf) 20 0xb7f222e3 wine_switch_to_stack+0x17 in libwine.so.1 (0xb7f222e3) 0x7e6f6dab drawStridedSlow+0xdb [/home/adebarbara/wine/wine- 0.9.14~winehq1~ubuntu~6.06/dlls/wined3d/drawprim.c:1344] in wined3d: flds 0x0(%eax) 1344 nx = ptrToCoords[0]; I attach the log. Could someone help me with this? Thack you in advance.

June 1, 2006

Re: MSI query tests

by EA Durbin

1. The conformance test suite must run on Windows. This is necessary to provide a reasonable way to verify its accuracy. Furthermore the tests must pass successfully on all Windows platforms (tests not relevant to a given platform should be skipped). I don't know how I would run this on windows. I edited the wine code itself and queried tables in the MSI database to troubleshoot the behavior of the installer code. Then i retrieved the pertainent values from the results, as in the case of the file table i retrieved the sequence value being returned by the query http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/… MSIQUERY * view; static const WCHAR ExecSeqQuery[] = {'S','E','L','E','C','T',' ','*',' ','F','R','O','M',' ', '`','F','i','l','e','`',' ','W','H','E','R','E',' ','`','S','e','q','u','e','n','c','e','`',' ','>','=',' ','8',0}; rc = MSI_DatabaseOpenViewW( package->db, ExecSeqQuery, &view ); if ( rc != ERROR_SUCCESS ) return ERROR_SUCCESS; TRACE( "DEBUGGING SELECT * FROM File WHERE Sequence >= 8 \n" ); rc = MSI_IterateRecords( view, NULL, ITERATE_QueryTest, package ); return rc; static UINT ITERATE_QueryTest( MSIRECORD *row, LPVOID param ) { MSIPACKAGE *package = (MSIPACKAGE*)param; int fileSequence; fileSequence = MSI_RecordGetInteger( row, 8 ); TRACE( "File Sequence: %i \n", fileSequence ); return ERROR_SUCCESS; } and the Media table i returned the DiskId, cabinet, and LastSequence values from the results http://msdn.microsoft.com/library/en-us/msi/setup/media_table.asp?frame=true static UINT ITERATE_QueryTest( MSIRECORD *row, LPVOID param ) { MSIPACKAGE *package = (MSIPACKAGE*)param; int lastSequence, DiskId; LPWSTR cab; lastSequence = MSI_RecordGetInteger( row, 2 ); DiskId = MSI_RecordGetInteger( row, 1); cab = MSI_RecordGetString( row, 4) TRACE( " Last Sequence: %u \n", lastSequence ); TRACE( " CAB %s \n", debugstr_w( cab ) ); TRACE( " Disk ID %u \n", DiskId ); return ERROR_SUCCESS; } >From: "Dan Kegel" <dank(a)kegel.com> >To: "EA Durbin" <ead1234(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: MSI query tests >Date: Thu, 1 Jun 2006 19:34:12 -0700 > >On 6/1/06, EA Durbin <ead1234(a)hotmail.com> wrote: >> >> >Great. Can you package up the tests as Wine conformance tests? >> >>I'm new to wine, how do I accomplish this? > >http://winehq.org/site/docs/winedev-guide/testing >has an introduction to the subject. >- Dan #

June 1, 2006

Re: MSI query tests

by Dan Kegel

On 6/1/06, EA Durbin <ead1234(a)hotmail.com> wrote: > > >Great. Can you package up the tests as Wine conformance tests? > > I'm new to wine, how do I accomplish this? http://winehq.org/site/docs/winedev-guide/testing has an introduction to the subject. - Dan

June 1, 2006

re: MSI query tests

by EA Durbin

>Great. Can you package up the tests as Wine conformance tests? I'm new to wine, how do I accomplish this? >From: "Dan Kegel" <dank(a)kegel.com> >To: ead1234(a)hotmail.com >CC: wine-devel <wine-devel(a)winehq.org> >Subject: re: MSI query tests >Date: Thu, 1 Jun 2006 19:14:08 -0700 > >EA Durbin wrote: >>I've written some tests to debug the MSI Installer in wine, in which I >>have >>tested various SQL statements against the America's Army installer >>database >>and iterated through the queries. > >Great. Can you package up the tests as Wine conformance tests? >That would be very useful; it might even provide the nudge >needed for an MSI expert to fix the problem. >- Dan > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv

June 1, 2006

MSI SQL

by EA Durbin

I changed the sql statement in my installer to read the following. SELECT * FROM Media WHERE LastSequence > %i , and it returns the 1st DiskId, with a LastSequence of 6, even after the LastSequence exceeds 6. The WHERE STATEMENT is broken in msi SQL. The installation of the first 6 .dlls works nicely, they are in my C: folder. trace:msi:ACTION_InstallFiles file paths L"C:\\windows\\temp\\FL_mfc71_dll_1_____X86.3643236F_FC70_11D3_A536_0090278A1BB8" to L"C:\\mfc71.dll" trace:msi:ACTION_InstallFiles Pass 2: L"_a8c1851f3c994e35b6e28a65f4793745" trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `Media` WHERE `LastSequence` >=7" 0x7fb8f794 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:msiobj_addref 0x7fd53fd8 trace:msi:MSI_ParseSQL Parse returned 0 trace:msi:ready_media_for_file LastSequence 6 trace:msi:ready_media_for_file Source is CAB L"Disk1.cab" I also tried querying another table to ensure it is the WHERE statement and not a table specific problem. here is the result of the SELECT * FROM File WHERE Sequence >= 8 Though this query doesn't return in sequential order like from the Media table, I did find numbers lower than 8 in the results trace:msi:MSI_DatabaseOpenViewW L"SELECT * FROM `File` WHERE `Sequence` >= 8" 0x7fb8fa38 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 7 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 2 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 1 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 3 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 5 trace:msi:msiobj_release 0x7efded70 trace:msi:msiobj_release object 0x7efded70 destroyed trace:msi:MSI_ViewFetch 0x7efdbca0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 4 Looks like the WHERE statement is broken in SQL.

June 1, 2006

re: MSI query tests

by Dan Kegel

EA Durbin wrote: > I've written some tests to debug the MSI Installer in wine, in which I have > tested various SQL statements against the America's Army installer database > and iterated through the queries. Great. Can you package up the tests as Wine conformance tests? That would be very useful; it might even provide the nudge needed for an MSI expert to fix the problem. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

June 1, 2006

Re: [Darwine] RFC - wine-macos mailing list

by Raphael

On Friday 02 June 2006 00:12, Mark F. Murphy wrote: > At 5:05 PM -0500 6/1/06, Jeremy White wrote: > >Some Mac folks have told me privately that having a Mac specific mailing > >list on www.winehq.org would make it more inviting to them. > >Perhaps that is reason alone to make the change. > > > >What do others think? > > +1 +1 too Anyway i prefer people interested on having wined3d/opengl working over AGL (ie porting GLX code) on wine-devel list (or better in wine-d3d list) :) Regards, Raphael

June 1, 2006

RE: MSI Query tests

by EA Durbin

or not, LastSequence of 0, is being returned in DiskId of 22 further down in the text. which is not greater than 1, I guess the WHERE statement is broken, as its returning a 0, when the query is SELECT * FROM `Media` where `LastSequence` > 1. >From: "EA Durbin" <ead1234(a)hotmail.com> >To: mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: RE: MSI Query tests >Date: Thu, 01 Jun 2006 19:22:31 -0500 > > >I've found a simple solution to this, not a fix for the SQL bug, but a fix >for InstallFiles(). > >If you notice in where.txt, Im selecting * from media WHERE LastSequence > >1. The default sort order for the results is by the table key of DiskId, >which follows that of LastSequence. > >Simply dropping the ORDER BY statement from the query in InstallFiles() >causes it to return the results in order by table key of DiskId, using the >WHERE statement where LastSequence > file->Sequence, so it never returns >the LastSequence of 0, thus fixing the InstallFiles() bug. > >>From: "EA Durbin" <ead1234(a)hotmail.com> >>To: mike(a)codeweavers.com >>CC: wine-devel(a)winehq.org >>Subject: MSI Query tests >>Date: Thu, 01 Jun 2006 19:07:53 -0500 >> >>I've written some tests to debug the MSI Installer in wine, in which I >>have tested various SQL statements against the America's Army installer >>database and iterated through the queries. Here are the results. >> >>It appears that in my attachment, where.txt, which is a standard where sql >>statement, >>SELECT * FROM `Media` WHERE `LastSequence` > 1 that it returns the SQL >>statement correctly. >> >>Then in orderby.txt i query >>SELECT * FROM `Media` ORDER BY `LastSequence` and it returns the results >>as expected. >> >>Then in compoundsql.txt I query SELECT * FROM `Media` WHERE `LastSequence` >> > 1 ORDER BY `LastSequence`, which is just as the statement appears in >>InstallFiles(). >> >>In this query it ignores the WHERE CLAUSE and uses what is to the far >>right , the ORDER BY LastSequence statement, which first grabs the >>LastSequence of 0. >> >>In conclusion, the actual problem in InstallFiles() is the inability to >>handle the compound SQL statement with a WHERE and an ORDER BY together. >> >>Unfortunately I don't understand wine's SQL underpinnings enough to where >>I can implement a solution. I've looked it over and it appears somewhat >>cryptic, so I will need some help. >> > > >><< compoundsql.txt >> > > >><< where.txt >> > > >><< orderby.txt >> > > >> > > > >

June 1, 2006

RE: MSI Query tests

by EA Durbin

I've found a simple solution to this, not a fix for the SQL bug, but a fix for InstallFiles(). If you notice in where.txt, Im selecting * from media WHERE LastSequence > 1. The default sort order for the results is by the table key of DiskId, which follows that of LastSequence. Simply dropping the ORDER BY statement from the query in InstallFiles() causes it to return the results in order by table key of DiskId, using the WHERE statement where LastSequence > file->Sequence, so it never returns the LastSequence of 0, thus fixing the InstallFiles() bug. >From: "EA Durbin" <ead1234(a)hotmail.com> >To: mike(a)codeweavers.com >CC: wine-devel(a)winehq.org >Subject: MSI Query tests >Date: Thu, 01 Jun 2006 19:07:53 -0500 > >I've written some tests to debug the MSI Installer in wine, in which I have >tested various SQL statements against the America's Army installer database >and iterated through the queries. Here are the results. > >It appears that in my attachment, where.txt, which is a standard where sql >statement, >SELECT * FROM `Media` WHERE `LastSequence` > 1 that it returns the SQL >statement correctly. > >Then in orderby.txt i query >SELECT * FROM `Media` ORDER BY `LastSequence` and it returns the results as >expected. > >Then in compoundsql.txt I query SELECT * FROM `Media` WHERE `LastSequence` > > 1 ORDER BY `LastSequence`, which is just as the statement appears in >InstallFiles(). > >In this query it ignores the WHERE CLAUSE and uses what is to the far right >, the ORDER BY LastSequence statement, which first grabs the LastSequence >of 0. > >In conclusion, the actual problem in InstallFiles() is the inability to >handle the compound SQL statement with a WHERE and an ORDER BY together. > >Unfortunately I don't understand wine's SQL underpinnings enough to where I >can implement a solution. I've looked it over and it appears somewhat >cryptic, so I will need some help. > ><< compoundsql.txt >> ><< where.txt >> ><< orderby.txt >> >

June 1, 2006

Re: [Darwine] RFC - wine-macos mailing list

by Sylvain OBEGI

Jim White wrote: > Brian Vincent wrote: > >> HOWEVER... >> >> I say create wine-macos but remove darwine-devel - keeping it would be >> too confusing. User-level stuff can go to wine-macos and devel stuff >> can go to wine-devel. > > What? And make the millions of PowerPC Mac owners cry? I don't think > so. Come on, millions of PowerPC owners crying over the loss of a dev list dealing with something they never had? Get real! Nobody cares! I've been on this list for 6 months, and I was following the website before that. The truth is, I don't think I've ever seen any actual improvement specific to PPC. If there is ever a x86->ppc translator included in (dar)wine, it will be done once the os x port is fully integrated into mainline (so no dev os x-specific list needed anymore) by an adventurous, (very) competent developer, so it will probably happen off the list anyway, leaving all the darwine-devel traffic for.. err, threads about merging lists? OS X for PPC is a dead-end. It's much cheaper to buy a new x86 machine than code what's needed to perhaps get wine to work on it. As I said, maybe someone will do it for the technical challenge, but in any case, the list won't be of much use. I personally prefer a separate list because wine-devel is too much traffic for me, as a user, but as the os x platform is getting closer to the Linux/x86 platform, and as the share of Wine users under OS X will rise probably very quickly, it doesn't make sense anymore to have a separate list (except maybe for the translator trick, but as there's no common effort to that, it's pointless). > WineHQ has nothing to do with running Darwine (an > OpenDarwin.org/SourceForge.net project). Seems more like an ego problem than a technical point. > If you wanna join darwine-devel and suggest we close it, feel free. > > Jim White Just my humble opinion anyway, please feel free to disregard it. -- Sylvain OBEGI

June 1, 2006

MSI Query tests

by EA Durbin

I've written some tests to debug the MSI Installer in wine, in which I have tested various SQL statements against the America's Army installer database and iterated through the queries. Here are the results. It appears that in my attachment, where.txt, which is a standard where sql statement, SELECT * FROM `Media` WHERE `LastSequence` > 1 that it returns the SQL statement correctly. Then in orderby.txt i query SELECT * FROM `Media` ORDER BY `LastSequence` and it returns the results as expected. Then in compoundsql.txt I query SELECT * FROM `Media` WHERE `LastSequence` > 1 ORDER BY `LastSequence`, which is just as the statement appears in InstallFiles(). In this query it ignores the WHERE CLAUSE and uses what is to the far right , the ORDER BY LastSequence statement, which first grabs the LastSequence of 0. In conclusion, the actual problem in InstallFiles() is the inability to handle the compound SQL statement with a WHERE and an ORDER BY together. Unfortunately I don't understand wine's SQL underpinnings enough to where I can implement a solution. I've looked it over and it appears somewhat cryptic, so I will need some help.

June 1, 2006

Re: RFC - wine-macos mailing list

by Jim White

Brian Vincent wrote: > HOWEVER... > > I say create wine-macos but remove darwine-devel - keeping it would be > too confusing. User-level stuff can go to wine-macos and devel stuff > can go to wine-devel. What? And make the millions of PowerPC Mac owners cry? I don't think so. WineHQ has nothing to do with running Darwine (an OpenDarwin.org/SourceForge.net project). If you wanna join darwine-devel and suggest we close it, feel free. Jim White

June 1, 2006

Re: How are we doing?

by EA Durbin

Speaking from the viewpoint of a new wine developer, the major hurdle, in my view, to contributing to wine is the lack of comments in the code, and the lack of whitespace. Wine is complicated enough, and the lack of comments in the code makes it more difficult. When trying to trace existing code to see how things work, there are very few comments to go off of. This hinders things, especially when trying to understand things that don't have any documentation written for them. Parts of wine might have one or two comments spread throughout the page, if you don't count the copywright info at the top of the page.

June 1, 2006

Re: RFC - wine-macos mailing list

by Brian Vincent

On 6/1/06, Jeremy White <jwhite(a)codeweavers.com> wrote: > Specifically, should we create a 'wine-macos' mailing list? I think the biggest concern here is that we've fragmented things before and we know we suck at maintaining multiple lists/forums for the same thing. Examples - wine-users & c.e.m.wine newsgroup (now fixed), third-party web forums & wine-users, wine-license stagnated for years before we removed it, etc. HOWEVER... I say create wine-macos but remove darwine-devel - keeping it would be too confusing. User-level stuff can go to wine-macos and devel stuff can go to wine-devel. </$.02> -Brian

June 1, 2006

Re: RFC - wine-macos mailing list

by Kai Blin

* Jeremy White <jwhite(a)codeweavers.com> [01/06/06, 17:05:31]: > Hi Folks, > > I'd like to pull one thread out of a previous discussion > and ask for comments on it specifically; I think other issues > in the thread detracted from what I think is a useful discussion. > > Specifically, should we create a 'wine-macos' mailing list? > > I think the idea would be that it would be a mailing list > for Mac users and developers to worry about Mac specific issues. > The benefit is that it would be more inviting to Mac users > and it would allow Mac folks to hone in on Mac specific topics. While I don't mind a seperate macos list, I'd prefer to see development going on on wine-devel. > The goal is still that Mac Wine developers would come join us > on wine-devel and #winehackers, so it would likely end up > primarily as a user forum. I guess the downside is that it > could be confusing, and you can argue that we > haven't created any platform specific lists prior to this. I would appreciate if we could get this working. I think MacOS development is interesting, I'd like to see some discussions here. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Quit worrying about your health. It'll go away. -- Robert Orben

June 1, 2006

Re: winspool/tests: Use 0xdeadbeef as magic Value

by Detlef Riekenberg

Am Montag, den 29.05.2006, 21:28 +1000 schrieb Jeff Latimer: > A minor spelling mistake, deaddeef instread of deadbeef. Thanks for validating my Patch. And updated Check is already in the Tree :-) -- By By ... ... Detlef

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Mike Hearn

On 6/1/06, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > What about the device node symlink? It's needed for the games alot and > it's the number one thing I get asked for help for now. We don't have > an easy way to detect it, although HAL should be able fix it. Right well that's us being borked somewhere ... Alexandre has said on IRC that we shouldn't actually need the x:: symlink anymore :)

June 1, 2006

Re: wine problems on a 64bit system

by Mike Hearn

On 6/1/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > Yes, I'm afraid we'll have to do that by default, there are too many > broken binaries out there. I think we've only seen a couple of such reports so far .... given that the exec bit was never enforced before now it wouldn't be surprising if there are lots of buggy apps out there but we don't seem to be seeing them yet. Perhaps for NX capable systems it could be an appdefault? The security enhancement it gives would be nice to have at least as an option for power users (yeah yeah I know, another pref ...) thanks -mike

June 1, 2006

Re: [Darwine] RFC - wine-macos mailing list

by Mark F. Murphy

At 5:05 PM -0500 6/1/06, Jeremy White wrote: >Some Mac folks have told me privately that having a Mac specific mailing >list on www.winehq.org would make it more inviting to them. >Perhaps that is reason alone to make the change. > >What do others think? +1 mark -- --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development <mailto:markm(a)tyrell.com> Tyrell Software Corp <http://www.tyrell.com> ---------------------------------------------------------------------------

June 1, 2006

RFC - wine-macos mailing list

by Jeremy White

Hi Folks, I'd like to pull one thread out of a previous discussion and ask for comments on it specifically; I think other issues in the thread detracted from what I think is a useful discussion. Specifically, should we create a 'wine-macos' mailing list? I think the idea would be that it would be a mailing list for Mac users and developers to worry about Mac specific issues. The benefit is that it would be more inviting to Mac users and it would allow Mac folks to hone in on Mac specific topics. The goal is still that Mac Wine developers would come join us on wine-devel and #winehackers, so it would likely end up primarily as a user forum. I guess the downside is that it could be confusing, and you can argue that we haven't created any platform specific lists prior to this. My driving concern is that I think we need to welcome the Mac community to the Wine Project and do all that we can to enable the Mac developers and users to use mainstream Wine resources. I don't think anyone wants www.winehq.org to be perceived as a 'Linux only' environment. (Although I do see that www.winehq.org doesn't list Mac OS X...hmmm). Some Mac folks have told me privately that having a Mac specific mailing list on www.winehq.org would make it more inviting to them. Perhaps that is reason alone to make the change. What do others think? Cheers, Jeremy

June 1, 2006

Re: How are we doing?

by Molle Bestefich

Tony Lambregts wrote: > The Application Queue is not being processed in a timely fashion. > > For myself I am busy with my day job, working on upgrading bugzilla, and > burnt out/frustrated trying to keep up with Application submitions (I am > too soft hearted to reject some submittions that probably should be > rejected). Keeping up with the Application Queue is a tough job (for me > at least, at this time) and at this point just reviewing some of the > submittions makes my head hurt. Once I get some free time, I'd like to get acquainted with the AppDB code and help out in the PHP department, specifically making it easier for maintainers to do stuff without having to go through the moderation queue. Too bad that the queues are filling up, unfortunately I don't have the time or energy to help with that right now. I think the system needs a shift towards less stuff ending up there in the first place, right?

June 1, 2006

Re: How are we doing?

by Molle Bestefich

KGJ <WOLFProductions(a)gmx.de> wrote: > The AppDB is a great idea, but why is it so poorly integrated in the > main page? The same question goes to the Bugtracker and the Wiki where > the situation is even worse. On most web pages you have a navigation bar > which remains the same as long as you are on the same page. But if you > enter the AppDB or the Bugtracker you have the feeling that you are on > an entirely new page which only have a link back to the main page and a > similar design. If you enter one of the wiki pages the situation is even > worse because it does not even have a link to the main page in the > navigation bar. Is this a design decision or is it just the lack of time > which prevents IMHO proper integration? There's so many pages, I think it's utopia to create a common menu for all of them. But perhaps the menu could have an integrated navigation bar added. Example. On the main page: +====== | WineHQ | > Wiki | > AppDB | > Issue Tracker After clicking "Wiki": +====== | WineHQ | > Wiki | > Categories | > All pages | > Recent changes Sort of a menu + navigation bar + automatic-folder-of-unused-menu-items-thingy...

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Jesse Allen

On 6/1/06, Mike Hearn <mike(a)plan99.net> wrote: > The location CD drives are mounted changes between systems, this patch is > essentially specific to yours. Wine already supports HAL, which should > solve this in a more correct manner (though we have reports it doesn't > work for some games!), so how comes that's not enough? > > thanks -mike > What about the device node symlink? It's needed for the games alot and it's the number one thing I get asked for help for now. We don't have an easy way to detect it, although HAL should be able fix it. Jesse

June 1, 2006

Re: How are we doing?

by Marcus Meissner

On Thu, Jun 01, 2006 at 03:21:52PM -0400, Vijay Kiran Kamuju wrote: > Any status on what projects have been approved and > who is going to work on which project for this years SoC. They are listed here: http://code.google.com/soc/wine/about.html Ciao, Marcus

June 1, 2006

Re: How are we doing?

by Tony Lambregts

On 6/1/06, KGJ <WOLFProductions(a)gmx.de> wrote: > Hi, > > The AppDB is a great idea, but why is it so poorly integrated in the > main page? The same question goes to the Bugtracker and the Wiki where > the situation is even worse. On most web pages you have a navigation bar > which remains the same as long as you are on the same page. But if you > enter the AppDB or the Bugtracker you have the feeling that you are on > an entirely new page which only have a link back to the main page and a > similar design. If you enter one of the wiki pages the situation is even > worse because it does not even have a link to the main page in the > navigation bar. Is this a design decision or is it just the lack of time > which prevents IMHO proper integration? I have to agree here that this sucks. I have been looking at doing something about this for a while. I have looked at making patches that woud fix up Wine HQ, AppDB and Bugzilla but I am lost with changing the wiki. The change I propose would add links for the four sites that we have to each site. IE: Wine HQ menu Main Site Home AppDB Home Bugzilla Home Wiki Home. I am still working on the upgrade to 2.20 for bugzilla and I think I am close to having it finished but I do not want to have a repeat of the last upgrade, so I am a little gun shy. Once that is in I can make it a priority to get those changes in. Also as I have said I have a lot of problems changing the wiki. Maybe Dimi could give me some pointers. (please). -- Tony Lambregts

June 1, 2006

Shell integration idea

by Mikołaj Zalewski

As a SoC project I'll try to improve the integration of wine with the Unix shells. My first step will be to implement the freedesktop.org Trash. I've written some code that doesn't add any new features but shows how I want to add it. I'd like to know if this is a good design? The main idea is not to hard-code one implementation of things like the Trash into shell32 - not everything is standardized by the freedesktop and even if it would this might not work on other systems like MacOS X. We should allow for many implementations. The correct one is loaded depending on a registry settings (so that a winecfg entry can be added). My implementation uses COM objects as it's standard dlls provides support for such tasks. Currently there is one interface (IWineShellIntegration) that acts as a factory for specialized objects. That could also be implemented using COM Aggregation - when we do that we could use QueryInterface instead of GetIntegrationObejct. Some COM objects can run in the address space of the calling process - e.g. the trash can be implemented like that. For others it would be a waist of resources (e.g. there is no need for every process to watch is the file associations have changed) - it's enough to load them only once. The explorer seems to be a good candidate to create such objects. In the attached patch there is one specialized interface - the IWineTrash. The SHELL_DeleteFile[AW] is patched to use it - it shows a different icon if the file can be trashed (these are not the correct icons as wine's shell32 uses a message box instead of a special dialog) and calls the trash method then. Currently there is only one built-in trash that can't trash anything. (note that SHELL_DeleteFile is called in the folders that are decendents of My Computer. If choose delete on a file that is a decendent of the '/', it will be deleted without a warning). Mikolaj Zalewski

June 1, 2006

Re: How are we doing?

by KGJ

Hi, Tony Lambregts wrote: > In the interm I believe the AppDB has helped a lot. I think that the > work that we have put into it has paid off fairly well to a point. So > far we have added: > > - Applications Maintantainers that can modify application entries on > an App by App basis. > > - Notification emails so that people (Administrators, Maintainers and > Monitors) kept up to date on changes to applications. > > - Bug links to track bugs affecting an application. > > - Test results to track how well an application runs on a Wine > version. and help spot regressions > > - Lots of small improvements. > > Lots of thanks to Chris Morgan and Johnathan Ernst and everyone else > that submited patches to get it to its current state. > > However there are a number of things that are needed still. > > - We need a general search page. > > - It would be nice to have the ability for people to have classes of > rights so that they can add/change/delete certain fields IE: > "Application Description" without having to become a maintainer or > administrator. > > There is a todo list here as well. http://wiki.winehq.org/AppdbInfo > > If anyone has experience with PHP or wants to gain some, there is a > real need for your help. > > > - A newsgroup set up that works the same as bugs so that anyone can > see the notifications generated by the AppDB. > > I asked Jeremy Newman for this before but I don't think that I > explained the need for it very well. (trying again) The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration? Another thing I'd like to be changed is the "Paid Support" Link. Now it leads you direct to the codeweavers homepage. Well I'd not expect such a behaviour from a menu link. I would propose it to change it so that it opens a new window with the codeweavers page (ok I know that some people don't like that) or to make a new page under "Paid support" which contains the link to codeweavers (and perhaps others, if existent) I'm a PHP and C/C++ coder and I thought about working on the todo list but I don't like the idea of starting to work on something which won't satisfy me in the end. I don't even care what you think about me or my ideas. There are other projects which needs to be worked on, too. Don't get me wrong, wine is a super project and I use it daily to run my favorite instant messenger, but I think the climate is a bit cold for my taste. I thought a while whether to send the email here or to /dev/null, but I thought I should inform you what I don't like ;) Greetings KGJ

June 1, 2006

Re: How are we doing?

by Matt Finnicum

I will be working on riched20 for SoC - Initially I'll be working on some unimplemented messages and styles, and then I'll be working on some of the missing COM interfaces. Details are at http://wiki.winehq.org/MatthewFinnicum --Matt On 6/1/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Any status on what projects have been approved and > who is going to work on which project for this years SoC.

June 1, 2006

Re: How are we doing?

by Vijay Kiran Kamuju

Any status on what projects have been approved and who is going to work on which project for this years SoC. --- Vijay On 6/1/06, Kai Blin <blin(a)gmx.net> wrote: > * Detlef Riekenberg <wine.dev(a)web.de> [01/06/06, 01:15:28]: > > > Big Patches went into the tree: > > > > Juan Lang: crypt32: Implement CryptBinaryToStringA and > > CryptStringToBinaryA. > > > > When I saw the big Patch, i wanted to ask to split this in seperate > > Patches: > > 1x Header-Changes > > 2x Testcase (2 tested Functions -> 2 Patches) > > 2x Implementation ( 2 Functions) > > However, the Big patch was already in the Tree: > > http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html > > > > My only Idea is: "special Patch": SoC > > The only connection with SoC this patch has is that it's using the > base64 encoder/decoder I wrote for Summer of Code 2005. > > Besides, it took me unitl about november to finally get my SoC patches > with major functionality in, so SoC students certainly don't have any > bonus. > > Cheers, > Kai > > -- > Kai Blin, (blin at gmx dot net) > Quit worrying about your health. It'll go away. > -- Robert Orben > > >

June 1, 2006

Re: How are we doing?

by Kai Blin

* Detlef Riekenberg <wine.dev(a)web.de> [01/06/06, 01:15:28]: > Big Patches went into the tree: > > Juan Lang: crypt32: Implement CryptBinaryToStringA and > CryptStringToBinaryA. > > When I saw the big Patch, i wanted to ask to split this in seperate > Patches: > 1x Header-Changes > 2x Testcase (2 tested Functions -> 2 Patches) > 2x Implementation ( 2 Functions) > However, the Big patch was already in the Tree: > http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html > > My only Idea is: "special Patch": SoC The only connection with SoC this patch has is that it's using the base64 encoder/decoder I wrote for Summer of Code 2005. Besides, it took me unitl about november to finally get my SoC patches with major functionality in, so SoC students certainly don't have any bonus. Cheers, Kai -- Kai Blin, (blin at gmx dot net) Quit worrying about your health. It'll go away. -- Robert Orben

June 1, 2006

Re: Text input box with scrollbar

by Detlef Riekenberg

Am Dienstag, den 30.05.2006, 11:06 -0300 schrieb Augusto Arcoverde da Rocha: > Hi all, > > Where I can find the inputbox drawing code? > > Some of these box appear with scrollbar when testing Action Request > System application under Wine, but not under MS Windows. Might be: dlls/user/edit.c (edit control), or dlls/riched20/* (rich edit control v2.0 and v3.0) (riched32 and msftedit are only wrapper for riched20) "DEVELOPERS-HINTS" is your friend :-) -- By By ... ... Detlef

June 1, 2006

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > I want to be nice to make it easy for them to reuse our tests. > They got an SoC-Project for the Spooler, so the lifetime for this > test will be about half a Year up to the maximum of a Year. Nobody will ever fix it, since it silently handles both cases. > I can document in the wiki or in the Source the location for such Code, > that is not needed for Wine any longer but temporary still in Wine to > allow ReactOS to reuse our Code more effective. The tests are supposed to reflect the Windows behavior, not the Wine or Reactos behavior. Unless Windows returns ERROR_CALL_NOT_IMPLEMENTED here, it's not correct for Wine to do it, and that's what the test should express by using a todo_wine. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory

by Detlef Riekenberg

Am Donnerstag, den 01.06.2006, 11:15 +0200 schrieb Alexandre Julliard: > Detlef Riekenberg <wine.dev(a)web.de> writes: > > > + SetLastError(0xdeadbeef); > > + res = GetPrintProcessorDirectoryA(NULL, NULL, 1, NULL, 0, &cbBuf); > > + if(!res && ( (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) || > > + (GetLastError() == 0xdeadbeef) )) { > > + trace("Not implemented yet\n"); > > + return; > > + } > > Unless there really is a Windows version that fails here, this test is > wrong. Things that are not implemented yet in Wine should be marked > with todo_wine, not ignored. Our current stub is just a FIXME, followed by "return 0". The missing "SetLastError()" is detected by "GetLastError() == 0xdeadbeef" I see no reason to run the rest of the tests for our stub or add a "SetLastError(ERROR_CALL_NOT_IMPLEMENTED)", that needs to be removed by the next Patch. ReactOS has SetLastError(ERROR_CALL_NOT_IMPLEMENTED) in every stub. I want to be nice to make it easy for them to reuse our tests. They got an SoC-Project for the Spooler, so the lifetime for this test will be about half a Year up to the maximum of a Year. I can document in the wiki or in the Source the location for such Code, that is not needed for Wine any longer but temporary still in Wine to allow ReactOS to reuse our Code more effective. -- By By ... ... Detlef

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: > As a hack you can change the code so every range of memory that is mapped > is mapped executable. Yes, I'm afraid we'll have to do that by default, there are too many broken binaries out there. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Alexandre Julliard

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> writes: > So the HAL thing doesn't work for everyone, and this works for a lot > of people. When you see /media/cdrom, you can be sure it's a cd-rom > drive. So why not use it? Because HAL is supposed to work (assuming you have the proper libraries), and if it doesn't work this should be investigated and fixed. And once it's fixed, the drives created manually are going to interfere with it. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: How are we doing?

by Detlef Riekenberg

Am Donnerstag, den 01.06.2006, 11:45 +0200 schrieb Alexandre Julliard: > > During the Time, things changed and I get confused more and more times > > about "special Developers" and "other Developers", as well as "special > > Patches" and "other Patches". > > (It's also Possible, that i did not see the big differences before). > > There's no such thing as special developer vs. other developer, it's > more like a linear scale based on trust: Just a different wording for the same thing. :-) It's the Only way, how it can work. Not only here for accepting Patches, but everywhere for everything in the World. > the more I trust a developer > the easiest it is for him to get his patches committed. The only way > to earn trust points is by submitting consistently good patches. IMHO, modify trust points according the recent coding Area from a Developer can improve the quality of the committed Patches a little bit. To pick up my last Message, Stefan does a great Job for ddraw/dx. The trust for him is so high, that he was hired by Codeweavers. The quoted Patch was IMHO an unusual Coding-Area for him, because it was his first Patch for the regression tests. Another Example is the Testcase for GetPrinter by Dmitry Timoshkov (14. April). I'm working on winspool about a Year now and the Patch from Dmitry was the first one from him in the Area of winspool and winspool/tests for that time. The first view was enough for me to know, that this Test will produce a lot of failures and was never tested on any win9x-system, but is was already in the tree. I asked Markus for renaming sane.gs to winesane.ds and gphoto.gs to winegphoto.ds as well as wine-devel, Emmanuel Millard, Robert Reif and Ken Thomases to use dlls/winmm/winecoreaudio.drv as a starting point for dlls/wineaudio.drv. Both Patches where resend a day after my questions, but without any changes in this area (Over 100k of code). During my re-reading of the winecoreaudio-Patch yesterday, I missed the Part for winecfg/audio.c to extend sAudioDrivers with "coreaudio", but Robert has already send a message about this topic. > That doesn't mean you can't get stuff in if you aren't trusted, but it > means it will require extra scrutiny, which is why it's very important > at the beginning to send small patches that are easy to review. Once > you have earned enough trust you can get away with being a bit more > sloppy (but not too much, or you'll lose trust points again ;-) Another statement that we can use for the wine-dev-guide. Thanks -- By By ... ... Detlef

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Vincent Povirk

On 6/1/06, Mike Hearn <mike(a)plan99.net> wrote: > The location CD drives are mounted changes between systems, this patch is > essentially specific to yours. Wine already supports HAL, which should > solve this in a more correct manner (though we have reports it doesn't > work for some games!), so how comes that's not enough? > > thanks -mike I think /media/cdrom is actually some sort of standard. A google search led me to http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT I don't know where this standard gets any authority, but most modern linux distros I've seen do have a /media/cdrom directory. If there is a /media/cdrom, one can assume that it is the cd-rom drive (whichever has a cd in it) without relying on HAL at all. A quick test shows that wine 0.9.14, with a clean .wine directory, can install worms: armageddon but not run it (it couldn't find the cd, probably because wine didn't find it). Simply /media/cdrom as d: and using autodetection is enough to make it work. So the HAL thing doesn't work for everyone, and this works for a lot of people. When you see /media/cdrom, you can be sure it's a cd-rom drive. So why not use it? -- Vincent Povirk

June 1, 2006

Winecfg add CoreAudio to audio drivers list

by Emmanuel Maillard

Changelog : Winecfg add CoreAudio to audio drivers list thanks Emmanuel

June 1, 2006

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

by Juris Smotrovs

Alexandre Julliard wrote: >>@@ -1435,9 +1435,19 @@ >> "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", >> context, expected->message, expected->lParam, actual->lParam); >> } >>- ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), >>- "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", >>- context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); >>+ if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) >>+ { >>+ todo_wine { >>+ failcount ++; >>+ ok_( file, line) (FALSE, >>+ "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", >>+ context, expected->message, expected->lParam, actual->lParam); >>+ } >>+ } >>+ else >>+ ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), >>+ "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", >>+ context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); > > The problem is that this will cause tests that currently succeed to be > turned back into todos. It would be better to do the changes in a way > that doesn't break existing tests. Not exactly. If a test currently succeeds (todo == FALSE), then the else branch will execute, and the else branch is exactly as before the patch. So nothing will change for successful tests. Anyway, if you are wary about changes affecting all tests, I will prepare another patch, simply disabling the particular (todo == TRUE) test causing the problem, with a FIXME comment. This test is unsuccessful both before and after the patch, simply because of currently not checking for todo flag at defwinproc mismatch, it gets reported as test failing the whole msg suite. The defwinproc mismatch itself appears because, after solving the WM_SIZE issue, this message -- correctly -- is sent, so the actual message queue shifts relative to the expected message queue, and -- due to some messages still missing -- three expected defwinproc messages coincide with three actual non-defwinproc messages which are expected later-on. Thus this failure is actually not about messages sent from incorrect place, but simply about missing messages which is a very typical failure among the todo tests. Cheers, Juris Smotrovs >

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Mike Hearn

The location CD drives are mounted changes between systems, this patch is essentially specific to yours. Wine already supports HAL, which should solve this in a more correct manner (though we have reports it doesn't work for some games!), so how comes that's not enough? thanks -mike

June 1, 2006

Re: wine problems on a 64bit system

by Mike Hearn

On Wed, 31 May 2006 07:26:37 +0200, Pavel Troller wrote: > The machines are running very similar kernels. Both are hardened with > exec-shield, but even disabling it on a 64bit by > 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with > exec-shield enabled (and doesn't print the no-exec message). As a hack you can change the code so every range of memory that is mapped is mapped executable. thanks -mike

June 1, 2006

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

by Alexandre Julliard

Juris Smotrovs <juris.smotrovs(a)sets.lv> writes: > @@ -1435,9 +1435,19 @@ > "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > context, expected->message, expected->lParam, actual->lParam); > } > - ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), > - "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", > - context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); > + if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) > + { > + todo_wine { > + failcount ++; > + ok_( file, line) (FALSE, > + "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > + context, expected->message, expected->lParam, actual->lParam); > + } > + } > + else > + ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), > + "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", > + context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); The problem is that this will cause tests that currently succeed to be turned back into todos. It would be better to do the changes in a way that doesn't break existing tests. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Pavel Troller <patrol(a)sinus.cz> writes: > This page really is NOT executable. So, why the workaround has been activated > just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it > also should be ? Why this new page has not been worked-around ? Because the app exception handler ignores the exception instead of propagating it. That's broken IMO, but it would certainly be possible to unprotect a larger range on the first fault. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Christoph Frick

On Thu, Jun 01, 2006 at 02:59:30PM +0200, Pavel Troller wrote: > root(a)co:/proc/28433# cat maps |grep 6d4 > 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll i run this game (il2+fb+ace+pf) on a opteron system quite well. i found the folling things helpfull - it might shed some more light on the whole thing: a) i have to run this game using win2k (or up - guess nt4 might also work) - it wont work using win98 b) when i configure EnableHardwareShaders=1 (?) in the conf.ini then the game crashes sooner or later (depending on the Water=XXX setting (3 is sooner, 2 is later)) with OutOfMemory exceptions in java. the game takes up to 3 gb ram virtual and a few 100mb resistant acording to "top". the box has 2gb real but i am not sure if i put 1gb or 2gb swap on - so it might actually really use "all my ram". i found it also quite amusing, that 3gb where used - where i guessed windows can only do 2gb per process without further handling (urban legend?). once i disable the hardware shaders the water looks dull within the game but serves my hours of fun without a problem -- cu

June 1, 2006

Re: wine problems on a 64bit system

by Pavel Troller

> > > It looks that the first exception is the No-exec, then there is one more lonely > > one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation > > of the looping one - this one repeats in the log at the same address forever. > > Sounds like the whole code section is non-executable. Check where this > section comes from using +module and/or winedump. > Hi Alexandre! By making +seh,+module dump and then grepping for 6d4, I've found the following interesting excerpts: At first: trace:module:load_native_dll Trying native dll L"Z:\\home\\tv\\il2sturmovikfb\\bin\\hotspot\\jvm.dll" trace:module:map_image mapped PE file at 0x6d420000-0x6d4ef000 trace:module:map_image mapping section .text at 0x6d421000 off 1000 size 94000 virt 93dd0 flags 60000020 trace:module:map_image mapping section .rdata at 0x6d4b5000 off 95000 size 9000 virt 8ca7 flags 40000040 trace:module:map_image mapping section .data at 0x6d4be000 off 9e000 size 11000 virt 24638 flags c0000040 trace:module:map_image mapping section .reloc at 0x6d4e3000 off af000 size c000 virt bf20 flags 42000040 It looks, from this one, that 0x6d4dxxxx belongs to .data section of jvm.dll. And next: trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cf0 ecx=7fe02cf0 edx=00000003 esi=7fe02cf0 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 We already know this one. It's the first attempt to access this address range. Workaround has been tried to activate. And now: trace:module:MODULE_InitDLL (0x6d420000 L"jvm.dll",THREAD_ATTACH,(nil)) - CALL trace:module:MODULE_InitDLL (0x6d420000,THREAD_ATTACH,(nil)) - RETURN 1 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 Now we see another access to this area. According to /proc/<pid>/maps: root(a)co:/proc/28433# cat maps |grep 6d4 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d421000-6d4b5000 r-xp 00001000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4b5000-6d4be000 r--p 00095000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4be000-6d4cf000 rw-p 0009e000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4cf000-6d4d0000 rw-p 6d4cf000 00:00 0 6d4d0000-6d4d1000 rwxp 6d4d0000 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 6d4e3000-6d4ef000 r--p 000af000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll This page really is NOT executable. So, why the workaround has been activated just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it also should be ? Why this new page has not been worked-around ? With regards, Pavel Troller

June 1, 2006

Re: How are we doing?

by Mike Hearn

On 6/1/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > It's possible to see on wiki the "trust points" positions ? :) > > And on each WWN, see the variations (seems the famous kde buzz) :) > > The commit logs contain the time of the change and the time of the > commit, so you could use that to build a top-10 of the developers with > the best patch-to-commit times ;-) Heh :) Bear in mind that it depends a lot on the patch and what kind of work you're doing. Getting some clearly correct typo fixes in for an obscure DLL is going to be a lot easier even for 'untrusted' developers than, say, implementing SetThreadPriority which touches the core of Wine in a sensitive area and is somewhat controversial. There's no special privilege for CW employees or SoC students, though we appreciate it may look that way at first glance. I'm a CW employee on and off (more off than on lately due to university) and I get patches rejected all the time <chuckle> :) thanks -mike

June 1, 2006

Re: Wine 1.0 Tasks

by Wesley Parish

Oh, FWLIW, I have suggested to Jason Matusow, the current Microsoft Standards maven, that the time has come (portentious voice ;) to submit the MS Win32 API to the standardization process, since Wine is now in Beta, there are more than one OS supporting the Win32 API as the standard API, and besides, Microsoft has muddied the waters considerably with its confused defintion of Vista vis-a-vis the DotNET project. Inspired heckling, even if I do say so myself! ;) FWLIW! ;) Wesley Parish On Tue, 30 May 2006 16:01, Dan Kegel wrote: > If you look at http://bugs.winehq.org/ you'll see a link on the left hand > side called "1.0 Tasks", which lists the 1.0 bugs being tracked in > bugzilla. Here's the URL it links to > http://bugs.winehq.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_s >tatus=REOPENED&product=Wine&target_milestone=1.0.0 > > I suspect a few of these are stale, and a bunch others are missing, > but I like the idea of using bugzilla to track our progress to 1.0. > > What other bugs should be fixed before 1.0? Let's nominate > a few bugs to add to the 1.0 task list, discuss them a bit, and see > what Alexandre thinks. > > For instance: > I'd like one goal of 1.0 to be "make Windows developers take Wine > seriously." To achieve that, I think 1.0 has to support at least some > Microsoft development tools well, including their IDEs and debuggers. It's > probably unreasonable to require 1.0 to support .NET, so maybe supporting > the last pre-.NET versions of Visual C++ (6.2?) and Visual Basic (6.0?) > would be a good goal. And I don't think it's that unreasonable anymore; > Wine is pretty close to being able to do that. What do y'all think? > - Dan -- Clinersterton beademung, with all of love - RIP James Blish ------------- Mau ki ana, he aha te mea nui? You ask, "What is the most important thing?" Maku ki ana, he tangata, he tangata, he tangata. I reply, "It is people, it is people, it is people."

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Pavel Troller <patrol(a)sinus.cz> writes: > It looks that the first exception is the No-exec, then there is one more lonely > one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation > of the looping one - this one repeats in the log at the same address forever. Sounds like the whole code section is non-executable. Check where this section comes from using +module and/or winedump. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: How are we doing?

by Michael Stefaniuc

Alexandre Julliard wrote: > fenix(a)club-internet.fr writes: > > >>It's possible to see on wiki the "trust points" positions ? :) >>And on each WWN, see the variations (seems the famous kde buzz) :) > > > The commit logs contain the time of the change and the time of the > commit, so you could use that to build a top-10 of the developers with > the best patch-to-commit times ;-) Wont work quite well as the time of the change can be way older than the time the developer submitted his patch. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

June 1, 2006

Re: wine problems on a 64bit system

by Marcus Meissner

On Thu, Jun 01, 2006 at 01:42:37PM +0200, Pavel Troller wrote: > > Pavel Troller <patrol(a)sinus.cz> writes: > > > > > But now I'm unsure, maybe we are on a false track. I just examined +relay > > > output again and I've found that immediately after the No-exec message the > > > program seems to continue normally. The problem (exception loop in msvcrt) > > > occurs many thousands lines later. I'm attaching preceding cca 1500 lines > > > of the log. > > > > It sounds like the no-exec workaround worked fine, and that you have > > some other problem. What does a +seh trace look like? > > > Hi Alexandre! > +seh shows the following: > > trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 > trace:seh:raise_exception info[0]=00000008 > trace:seh:raise_exception info[1]=6d4d08b0 > trace:seh:raise_exception eax=00000001 ebx=7fe02cd8 ecx=7fe02cd8 edx=00000003 esi=7fe02cd8 edi=6d4e0e90 > trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 > trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 > trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub > trace:seh:_except_handler3 filter = 0x401e62 > trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) > trace:seh:_except_handler3 filter returned CONTINUE_SEARCH > trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch > trace:seh:call_stack_handlers handler at 0x401f00 returned 1 > trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 > fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around > trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 > trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef > trace:seh:raise_exception info[0]=00000008 > trace:seh:raise_exception info[1]=6d4db3ef > trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef > trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 > trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 > trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub > trace:seh:_except_handler3 filter = 0x6d469332 > trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION > trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 > trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b > trace:seh:raise_exception info[0]=00000008 > trace:seh:raise_exception info[1]=6d4d5d7b > trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef > trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 > trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 > trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub > trace:seh:_except_handler3 filter = 0x6d469332 > trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION > trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 > > It looks that the first exception is the No-exec, then there is one more lonely > one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation > of the looping one - this one repeats in the log at the same address forever. Please check the audit log whether a SELINUX audit event happened. (/var/log/audit/audit.log I think.) Ciao, Marcus

June 1, 2006

Re: How are we doing?

by Alexandre Julliard

fenix(a)club-internet.fr writes: > It's possible to see on wiki the "trust points" positions ? :) > And on each WWN, see the variations (seems the famous kde buzz) :) The commit logs contain the time of the change and the time of the commit, so you could use that to build a top-10 of the developers with the best patch-to-commit times ;-) -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Pavel Troller

> Pavel Troller <patrol(a)sinus.cz> writes: > > > But now I'm unsure, maybe we are on a false track. I just examined +relay > > output again and I've found that immediately after the No-exec message the > > program seems to continue normally. The problem (exception loop in msvcrt) > > occurs many thousands lines later. I'm attaching preceding cca 1500 lines > > of the log. > > It sounds like the no-exec workaround worked fine, and that you have > some other problem. What does a +seh trace look like? > Hi Alexandre! +seh shows the following: trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cd8 ecx=7fe02cd8 edx=00000003 esi=7fe02cd8 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever. With regards, Pavel Troller

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Pavel Troller <patrol(a)sinus.cz> writes: > But now I'm unsure, maybe we are on a false track. I just examined +relay > output again and I've found that immediately after the No-exec message the > program seems to continue normally. The problem (exception loop in msvcrt) > occurs many thousands lines later. I'm attaching preceding cca 1500 lines > of the log. It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like? -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Pavel Troller

Hi Alexandre, many thanks that you are also looking at this problem. > It may be that your kernel doesn't allow writable memory to be made > executable, in which case we can't do anything about it. Or maybe the > workaround is simply broken... It may also be possible to make that > section executable some other way, you'll need to investigate what > that memory address corresponds to in the app. Running the app, it shows tv(a)co:~/il2sturmovikfb$ wine il2fb.exe fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around Looking at /proc/<pid>/maps, it shows root(a)co:/proc/14647# cat maps |grep 6d4d 6d4cf000-6d4d0000 rw-p 6d4cf000 00:00 0 6d4d0000-6d4d1000 rwxp 6d4d0000 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 It looks that this page IS writable as well as executable. However, there is nothing more about it, no indication of which part of the app it corresponds to. Just a global data/BSS section ? BTW the problem happens very early during startup, even before an Xserver is accessed, so trying it from the text console (without $DISPLAY defined) gives exactly the same results as from Xterm. But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log. With regards, Pavel Troller

June 1, 2006

Re: comctl32: Fix loading string from resources

by Ferenc Wagner

Alexandre Julliard <julliard(a)winehq.org> writes: > Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > >> LoadString() cannot be used to measure the length of a string resource. >> It will not return the length of the string if no buffer is provided, >> instead it will return 0! This patch fixes the broken property sheet code. > > Since you are going to the trouble of loading it all by hand, you > should allocate and fill the buffer right away, instead of returning > only the length and letting LoadString do the whole thing once again. > > Also a test case for LoadString demonstrating that the current > behavior is wrong would be a good idea. At first sight it's a simple matter of extending the resource test (user dll) by adding {0, 0} to the test variable. At second sight creation of a new test is needed, as the current one tests LoadStringA only... Anyway, you can use that as a template. -- Feri.

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Pavel Troller <patrol(a)sinus.cz> writes: > Hi! > As some of you know, I'm experimenting with my new 64bit systems. I've found > that there are problems running a lot of applications, which normally run on > a 32bit system. > A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, > with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. > On a 64bit system, it just prints > fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around > but the workaround seems to be unefficient, because nothing more happens. > With a +relay, it shows that the program is looping, executing > 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 > 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 > and nothing more, ad infinitum. > The machines are running very similar kernels. Both are hardened with > exec-shield, but even disabling it on a 64bit by > 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with > exec-shield enabled (and doesn't print the no-exec message). > Are there chances to fix this issue ? Or is it a system problem ? It may be that your kernel doesn't allow writable memory to be made executable, in which case we can't do anything about it. Or maybe the workaround is simply broken... It may also be possible to make that section executable some other way, you'll need to investigate what that memory address corresponds to in the app. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: Re: How are we doing?

by fenix＠club-internet.fr

----Message d'origine---- >De: Alexandre Julliard <julliard(a)winehq.org> >A: Detlef Riekenberg <wine.dev(a)web.de> >Date: Thu, 01 Jun 2006 11:45:10 +0200 >Copie à: wine-devel(a)winehq.com, Mike Hearn <mike(a)plan99.net> >Sujet: Re: How are we doing? > >Detlef Riekenberg <wine.dev(a)web.de> writes: > >> During the Time, things changed and I get confused more and more times >> about "special Developers" and "other Developers", as well as "special >> Patches" and "other Patches". >> (It's also Possible, that i did not see the big differences before). > >There's no such thing as special developer vs. other developer, it's >more like a linear scale based on trust: the more I trust a developer >the easiest it is for him to get his patches committed. The only way >to earn trust points is by submitting consistently good patches. > >That doesn't mean you can't get stuff in if you aren't trusted, but it >means it will require extra scrutiny, which is why it's very important >at the beginning to send small patches that are easy to review. Once >you have earned enough trust you can get away with being a bit more >sloppy (but not too much, or you'll lose trust points again ;-) It's possible to see on wiki the "trust points" positions ? :) And on each WWN, see the variations (seems the famous kde buzz) :) Anyway, adding an explaining page on wiki for "how to begin as wine developper" may help a lot Regards, Raphael

June 1, 2006

Re: comctl32: Fix loading string from resources

by Alexandre Julliard

Thomas Weidenmueller <wine-patches(a)reactsoft.com> writes: > LoadString() cannot be used to measure the length of a string resource. > It will not return the length of the string if no buffer is provided, > instead it will return 0! This patch fixes the broken property sheet code. Since you are going to the trouble of loading it all by hand, you should allocate and fill the buffer right away, instead of returning only the length and letting LoadString do the whole thing once again. Also a test case for LoadString demonstrating that the current behavior is wrong would be a good idea. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: How are we doing?

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > During the Time, things changed and I get confused more and more times > about "special Developers" and "other Developers", as well as "special > Patches" and "other Patches". > (It's also Possible, that i did not see the big differences before). There's no such thing as special developer vs. other developer, it's more like a linear scale based on trust: the more I trust a developer the easiest it is for him to get his patches committed. The only way to earn trust points is by submitting consistently good patches. That doesn't mean you can't get stuff in if you aren't trusted, but it means it will require extra scrutiny, which is why it's very important at the beginning to send small patches that are easy to review. Once you have earned enough trust you can get away with being a bit more sloppy (but not too much, or you'll lose trust points again ;-) -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > + SetLastError(0xdeadbeef); > + res = GetPrintProcessorDirectoryA(NULL, NULL, 1, NULL, 0, &cbBuf); > + if(!res && ( (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) || > + (GetLastError() == 0xdeadbeef) )) { > + trace("Not implemented yet\n"); > + return; > + } Unless there really is a Windows version that fails here, this test is wrong. Things that are not implemented yet in Wine should be marked with todo_wine, not ignored. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Francois Gouget

On Thu, 1 Jun 2006, Mike McCormack wrote: > + ln -s /media/cdrom "$WINEPREFIX/dosdevices/m:" Wouldn't it be better to create it as the d: drive? That's usually where CD-ROM drives end up on Windows... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

June 1, 2006

Re: svrapi: add stub implementation

by Vitaly Lipatov

On Wednesday 31 May 2006 17:36, Robert Shearman wrote: > Vitaly Lipatov wrote: > >svrapi.dll is exist on Win9X OS and used in some programs. > > What programs? Is it still used even with the winver set to > win2k? Some accounting program called BEST in Russia. No it used only with winver set to win95/win98, but we may not use win2k winver now. P.S. I will review svrapi patch according to notes about getuname from Alexandre and you. -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

June 1, 2006

Re: Quartz driver

by Steven Edwards

Hi, On 5/31/06, Emmanuel Maillard <mahanuu(a)opendarwin.org> wrote: > Winemine is playable on both PPC and x86 but it look fine only on > PPC, x86 driver suffer strange rendering bugs. > > See wiki for building the driver : http://wiki.opendarwin.org/ > index.php/Darwine:quartzdrv > I will update wiki soon with issues and todo for Quartz driver. Very nice. This is much further along than I expected. Your work is really amazing. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 1, 2006