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

RFC - device notifications idea
by Damjan Jovanovic 02 Jun '06

02 Jun '06

I was disappointed to see that "dynamic drive configuration" (http://www.winehq.org/?issue=313#Dynamic%20Drive%20Configuration) amounts to a few HAL functions in wine's explorer. Windows has been using device notifications for at least 11 years now (since Windows 95), and neither wine nor ReactOS have even begun this feature. I would be interested in implementing it by using dbus/HAL in wineserver, and translating HAL device notifications into equivalent WM_DEVICECHANGE messages which then get broadcast to all windows. Is any work being done in this area? If not, would this work? Are long-running functions requiring I/O (hal_device_get_property_...()) allowed in wineserver (which seems to be event-driven)? Any other comments? Thank you Damjan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Wine VM86 exception handling bug?
by Andrey Turkin 02 Jun '06

02 Jun '06

Hi all! I think i found a bug in VM86 exception handling (must be regression, i guess). Short Wine function flow: On privileged instruction __wine_enter_vm86 saves vm86 registers in CONTEXT and starts raise_segv_exception. raise_segv_exception routes exception to the INSTR_EmulateInstruction and then to winedos I/O emulator, then tries to use NtSetContextThread(GetCurrentThread(), CONTEXT). NtSetContextThread obviously fails because of VM86 segment values in CONTEXT. My opinion is that NtSetContextThread call is wrong; __wine_enter_vm86 would restore vm86 registers correctly. I think i know what is the problem; however, I lack experience to fix it myself :) I need help; any hints would be appreciated.

1 0

re: test case for MSI problem in America's Army installer
by Dan Kegel 02 Jun '06

02 Jun '06

Mike M. wrote: >>> [America's Army install crashes, see >>> http://bugs.winehq.org/show_bug.cgi?id=5139 ] >> >> This is as close as I will be able to come to including a test case, as >> this is how I obtained my results. > > If you want me to fix the problem, please submit a regression test to > wine-patches with a todo_wine{} around the code that doesn't work. If that's too hard for EA (he admits he's not a C hacker), maybe I can focus some energy on it... - Dan

1 0

Re: winspool: [3/3] Add GetPrintProcessorDirectoryA
by Alexandre Julliard 02 Jun '06

02 Jun '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > + if (ret) { > + needed = WideCharToMultiByte( CP_ACP, 0, InfoW, -1, (LPSTR)Info, cbBuf, NULL, NULL); > + if (pcbNeeded) *pcbNeeded = needed; > + ret = (needed > cbBuf) ? FALSE : TRUE; This check is wrong, WideCharToMultiByte will return 0 if the buffer is too small. -- Alexandre Julliard julliard(a)winehq.org

2 1

intermediate fontconfig 2.3.94 problems
by Marcus Meissner 02 Jun '06

02 Jun '06

Hi, SUSE Linux 10.1 contains fontconfig 2.3.94, which changed the FcPatternGetString() function from return path names to return only the filenames. We received this bugreport: https://bugzilla.novell.com/show_bug.cgi?id=179457 However, Bernd Rosenkraenzer reported this problem already and the change was reverted for fontconfig 2.3.95. Its just that it might be broken only in SL 10.1 (perhaps fixed with online update, still in discussion). So this is just a heads-up, if more bugreports should appear. Ciao, Marcus

1 0

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)
by Alexandre Julliard 02 Jun '06

02 Jun '06

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

2 2

Test Case
by EA Durbin 02 Jun '06

02 Jun '06

This is as close as I will be able to come to including a test case, as this is how I obtained my results. Here is my code, and the resulting logs. Here are some patches I used, just a quick hack of the existing wine code, to run a query and iterate through the results. As you'll see in the enclosed results, this query is returning the results of Sequence < 8 even though the query called for Sequence >= 8. trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 2 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 1 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 3 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 5 trace:msi:msiobj_release 0x7efcad60 trace:msi:msiobj_release object 0x7efcad60 destroyed trace:msi:MSI_ViewFetch 0x7efda640 0x7fb8f9f8 trace:msi:ITERATE_QueryTest File Sequence: 4 f8 And when I queried the Media Table WHERE LastSequence >= 20, it returns LastSequence < 20, trace:msi:ACTION_InstallFiles DEBUGGING SELECT * FROM Media WHERE LastSequence >= 20 trace:msi:MSI_ViewExecute 0x7efde0f0 (nil) trace:msi:MSI_ViewFetch 0x7efde0f0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest Last Sequence: 6 trace:msi:ITERATE_QueryTest Disk Id: 1 trace:msi:ITERATE_QueryTest CAB: L"Disk1.cab" trace:msi:msiobj_release 0x7efe0900 trace:msi:msiobj_release object 0x7efe0900 destroyed trace:msi:MSI_ViewFetch 0x7efde0f0 0x7fb8f9f8 trace:msi:ITERATE_QueryTest Last Sequence: 14 trace:msi:ITERATE_QueryTest Disk Id: 2 hence its broken. And this query is the same, regardless of the platform WHERE VALUE >= test condition, is WHERE value is Greater than or equal test condition, on any SQL implementation, MSI, mysql, postgre, ORACLE, etc. etc., wine's implementation is broken.

2 1

MSI
by EA Durbin 02 Jun '06

02 Jun '06

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

1 0

MSI Query tests
by EA Durbin 02 Jun '06

02 Jun '06

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.

2 3

Lineage 2 crash
by Andres de Barbara 02 Jun '06

02 Jun '06

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.

1 0