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

Re: msi patch submission - cond.y
by Mike McCormack June 5, 2006

June 5, 2006

EA Durbin wrote: > fixed various SQL errors in COND_GetOperator() and compare_int() IMO, both of your patches are incorrect. I'm waiting for your test case. Mike

3 2

To <space> or <tab> or not :-)
by Molle Bestefich June 5, 2006

June 5, 2006

> isn't it rather insane to require specific editor settings > just to be able to *view* the code? It's a necessity for some editors. The TAB setting can be embedded in ASCII files, there are various magic comments that will cause vim and emacs to switch to a readable tabs setting. What is insane is 8 characters per tab. IMHXP 2 characters is too little to quickly make out the indentation. 3 and 4 are both fine choices. 4 wastes slightly more horizontal space, so I prefer 3. 8 is just nuts, it was probably written by someone who hates tabs and wants to use it as an argument to convince everybody to convert to spaces. Using spaces in place of tabs is bad, because you have to press <backspace> and <space> so much the more, wasting your time and tearing your fingers. And there's a higher risk of misaligning something - you have to pay more attention, which again is a waste of your time. You loose fine-grained control when you use tabs instead of spaces, but fine-grained control also means a jungle of bizarre rules about when-and-where-to-do-fine-grained-indenting, so it never pays off, rather it always ends up ruining the indentation anyway. By far the easiest solution is to just use tabs, and just indent codelines that span more than a screenful (7x chars or what not) with an extra tab.

3 3

Re: rpcrt4: Introduce a new function, safe_multiply, which will raise an exception if a multiply overflows a 4-byte integer.
by Alexandre Julliard June 5, 2006

June 5, 2006

Robert Shearman <rob(a)codeweavers.com> writes: > + unsigned char overflow; > +#if defined(__i386__) && defined (__GNUC__) > + __asm__( > + "mull %3\n\t" > + "seto %%cl" > + : "=a" (ret), "=c" (overflow) /* outputs: eax, cl */ > + : "%a" (a), "rm" (b) /* inputs: eax, any register or memory > + * address (params are interchangable) */ > + : "edx" /* edx clobbered */); > +#else > + ret = a * b; > + overflow = (b && (ret / b != a)); > +#endif That asm seems really overkill. Something like: ULONGLONG ret = (ULONGLONG)a * b; if (ret > 0xffffffff) will generate pretty much the same code with a recent gcc, and it's a lot more readable. BTW could you please add a sequence number in the subject line for your patches? It makes things a lot easier for me when the mails arrive out of order. Thanks. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: userenv: Add a stub implementation of userenv.dll
by Detlef Riekenberg June 5, 2006

June 5, 2006

Am Montag, den 05.06.2006, 14:01 +0900 schrieb Mike McCormack: > +++ b/dlls/userenv/userenv_main.c > +typedef struct _PROFILEINFOA { ... > +} PROFILEINFOA, *LPPROFILEINFOA; For mingw, this is in "include/userenv.h" -- By By ... ... Detlef

2 2

Light reading about .net framework 1.1 installer
by Dan Kegel June 5, 2006

June 5, 2006

I just ran across an nice description of what the .net framework 1.1 installer uses during its execution: http://blogs.msdn.com/astebner/archive/2004/08/02/205936.aspx That's going to be a bit of a challenge. - Dan

1 0

re: Added initial version of Wine OleView
by Dan Kegel June 4, 2006

June 4, 2006

Hi Piotr! Say, does it *do* anything useful yet? Might be worth waiting until it does before submitting it. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

Ecco Pro hangs when accessing "2nd level" dialogs
by Don Dwiggins June 4, 2006

June 4, 2006

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

2 1

Re: FW: RE: My 1.0 wish list
by EA Durbin June 4, 2006

June 4, 2006

>From: Hans Leidekker <hans(a)it.vu.nl> >To: wine-devel(a)winehq.org >CC: "EA Durbin" <ead1234(a)hotmail.com> >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 4 Jun 2006 09:49:47 +0200 > >On Sunday 04 June 2006 09:08, EA Durbin wrote: > > > I wrote a quick test in wine/dlls/msi/tests/db.c to add a 2nd row to the > >Could you share it? > > > database that was being created, then I inserted the `id` of 8 into it >and > > then I ran the query SELECT * FROM phone where `id` > 6, and it returned > > the correct results with `id` of 8. But in the actual wine installer >code a > >Is the table in db.c comparable? Does it have the same fields and types? >Also, you're using > in your select but the failing select statement has >= >which may make a difference. > > -Hans It shouldnt matter whether its >= or >, they both return the wrong results in the actual msi installer and the right results in db.c. I have enclosed my tests, I tested these against the America's Army database installer and I have double checked the actual contents of the msi file in ORCA. I've packaged up some tests and included them with this email. Here are some queries that have returned the wrong results SELECT * FROM `Media` WHERE `LastSequence` > 15 SELECT * FROM `File` WHERE `Sequence` > 10 SELECT * FROM `Media` WHERE `LastSequence` >= 15 SELECT * FROM `File` WHERE `Sequence` >= 10

3 7

DAZ Studio
by Andrew Neil Ramage June 4, 2006

June 4, 2006

After running winecfg and setting winver for DAZStudio.exe to XP, I get the following. andrew(a)apollo:~/Download/Windows> wine /home/andrew/.wine/drive_c/Program\ Files/DAZ/Studio/DAZStudio.exe fixme:imm:ImmReleaseContext (0x10020, 0x403cde30): stub fixme:imm:ImmReleaseContext (0xa00a2, 0x403cde30): stub fixme:imm:ImmReleaseContext (0x200aa, 0x403cde30): stub fixme:uniscribe:ScriptItemize L"DAZ|Studio can search for directories that\2028may contain content from other programs\2028that DAZ|Studio can read. Please indicate\2028which drives you want DAZ|Studio to search.\2028NOTE: On large drives or network drives\2028this operation can take several minutes.\4291",249,255,(nil),(nil),0x415ae8a4,0x415af0b0: semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptShape (0xac0, 0x4232a600, 0x4291db70, 10, 10, 0x4232d1ac): semi-stub fixme:uniscribe:ScriptPlace (0xac0, 0x4232a600, 0x4232ba40, L"'$=_6WXGLR", 10, 0x4232cea8, 0x4232d1ac, 0x4232bd2c): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db84, 1, 1, 0x4232d1d4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba54, L"\0003", 1, 0x4232cebc, 0x4232d1d4, 0x4232bd54): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db86, 3, 3, 0x4232d1fc): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba56, L"FDQ", 3, 0x4232cebe, 0x4232d1fc, 0x4232bd58): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8c, 1, 1, 0x4232d224): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5c, L"\0003", 1, 0x4232cec4, 0x4232d224, 0x4232bd64): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db8e, 6, 6, 0x4232d24c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba5e, L"VHDUFK", 6, 0x4232cec6, 0x4232d24c, 0x4232bd68): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9a, 1, 1, 0x4232d274): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6a, L"\0003", 1, 0x4232ced2, 0x4232d274, 0x4232bd80): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291db9c, 3, 3, 0x4232d29c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba6c, L"IRU", 3, 0x4232ced4, 0x4232d29c, 0x4232bd84): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba2, 1, 1, 0x4232d2c4): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba72, L"\0003", 1, 0x4232ceda, 0x4232d2c4, 0x4232bd90): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dba4, 11, 11, 0x4232d2ec): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba74, L"GLUHFWRULHV", 11, 0x4232cedc, 0x4232d2ec, 0x4232bd94): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbba, 1, 1, 0x4232d314): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8a, L"\0003", 1, 0x4232cef2, 0x4232d314, 0x4232bdc0): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbbc, 4, 4, 0x4232d33c): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba8c, L"WKDW", 4, 0x4232cef4, 0x4232d33c, 0x4232bdc4): semi-stub fixme:uniscribe:ScriptShape ((nil), 0x4232a600, 0x4291dbc4, 1, 1, 0x4232d364): semi-stub fixme:uniscribe:ScriptPlace ((nil), 0x4232a600, 0x4232ba94, L"", 1, 0x4232cefc, 0x4232d364, 0x4232bdd4): semi-stub fixme:win:SetWindowTextA setting text "EAX=00006078 EBX=42A6810C ECX=415AF1D8 EDX=403DFDE0 ESI=4232BA94\nEDI=403DF9D8 EBP=415AF15C ESP=415AF144 EIP=42A66FF5 FLG=00210246\nCS=0073 DS=007B SS=007B ES=007B FS=1007 GS=0033" of other process window (nil) should not use SendMessage -- Andrew When the dragons grow too mighty To slay with pen or sword I grow weary of the battle And the storm I walk toward Madrigal by Rush (A Farewell to Kings, 1974) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

4 4

Shell integration idea
by Mikołaj Zalewski June 4, 2006

June 4, 2006

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

5 8

Re: mapi32: Write-strings warnings fix
by Peter Oberndorfer June 4, 2006

June 4, 2006

On Saturday 03 June 2006 16:33, Andrew Talbot wrote: > Changelog: > mapi32: Write-strings warnings fix. > > diff -urN a/dlls/mapi32/sendmail.c b/dlls/mapi32/sendmail.c > --- a/dlls/mapi32/sendmail.c 2006-05-23 17:24:40.000000000 +0100 > +++ b/dlls/mapi32/sendmail.c 2006-06-03 14:44:21.000000000 +0100 > @@ -113,8 +113,8 @@ > } > if (message->nFileCount) FIXME("Ignoring attachments\n"); > > - subject = message->lpszSubject ? message->lpszSubject : ""; > - body = message->lpszNoteText ? message->lpszNoteText : ""; > + subject = message->lpszSubject ? message->lpszSubject : NULL; > + body = message->lpszNoteText ? message->lpszNoteText : NULL; I think this is wrong, as it makes the whole "? :" construct unnecessary. (for non NULL it evaluates to "message->lpszNoteText" and for NULL it becomes NULL; > > TRACE( "Subject: %s\n", debugstr_a(subject) ); > TRACE( "Body: %s\n", debugstr_a(body) ); > > > Greetings Peter

3 12

Re: FW: RE: My 1.0 wish list
by EA Durbin June 4, 2006

June 4, 2006

That can't be used for a test case, for a test case I, or most likely someone elsewho has the ability and the time has to write code under dlls/msi/tests/db.c and make a program in windows to re-illustrate this bug. >From: "Jason Green" <jave27(a)gmail.com> >To: "EA Durbin" <ead1234(a)hotmail.com> >CC: mike(a)codeweavers.com, dank(a)kegel.com, wine-devel(a)winehq.org >Subject: Re: FW: RE: My 1.0 wish list >Date: Sat, 3 Jun 2006 12:02:15 -0400 > >On 6/3/06, EA Durbin <ead1234(a)hotmail.com> wrote: >> >>This problem in MSI spans a multitude of bugs. >> >>ATI demo(Rendering With Natural Light ) - bug # 4712? >> > >I noticed yesterday that just about every ATI Demo had similar >installer problems. Just try a few from here if you need some quick >test cases: > >http://www.ati.com/developer/demos.html > >Thanks, and good luck!

2 3

Re: FW: RE: My 1.0 wish list
by EA Durbin June 3, 2006

June 3, 2006

I have compiled a list of applications that are affected by the bug in which the query in ready_media_for_file() in MSI returns the wrong results, it returns LastSequence less than the file->Sequence being passed. Here is a detailed analysis of the multiple types of errors this bugs causes. Common debug outputs of this bug are: Error #1: err:msi:ACTION_InstallFiles compressed file wasn't extracted This error is usually caused by the results of the query returning a LastSequence number of Less than that of the working install media and the installer is trying to extract the file from the wrong install medium. Error #2: err:msi:extract_cabinet_file FDICopy failed err:msi:ACTION_InstallFiles Unable to ready media There is a zero in LastSequence Value of the Media table and the query in ready_media_for_file() returns it. For some reason the msi file has a zero in the LastSequence but its really a dummy cabinet file and doesn't exist. The file sequence being passed for the first file is most likely 1, and the query of >= 1 is returning 0 falsely causing this error. This problem in MSI spans a multitude of bugs. America's Army - bug #5139 J2SE - bug # 4280 Half Life 2 - bug # 5004, 4533 Dawn of War Demo - bug # 3749 E-Sword 6.5 - bug # 4251 Rush for Berlin demo - bug #5187 ATI demo(Rendering With Natural Light ) - bug # 4712? There are probably other bugs resulting from this, but the log doesn't detail it well enough, alot of them just have the debug dump at the end and not the pertainent msi err lines. I only included applications where it was obvious from the log, or I tested personally. >From: Mike McCormack <mike(a)codeweavers.com> >To: EA Durbin <ead1234(a)hotmail.com> >Subject: Re: FW: RE: My 1.0 wish list >Date: Sun, 04 Jun 2006 00:30:41 +0900 > > >You can send me as many mails as you like, but I'm not doing anything until >there's a test case showing the problem. > >Mike I wrote a test showing the results of the query in the wine installer and included the source code and resulting logs which clearly displays the problem. That's the best I can do. I'm not up to snuff on my C programming, nor am I familiary with how the official test case for wine is supposed to be layed out. If someone else wants to work on it then thats fine, but I layed out the problem, and debugged it, and I've proven this with code and resulting logs. This problem affects a multitude of applications in wine. If your not willing to work on it then either someone else can, or it can remain broken.

5 4

My 1.0 wish list
by Dan Kegel June 3, 2006

June 3, 2006

... is now at http://wiki.winehq.org/DanKegel I'm willing to focus some effort on these tasks, too, so it's not just pie-in-the-sky wishing.

3 6

Alsa sound vs OSS with wine and riven
by Stephen Clark June 3, 2006

June 3, 2006

Hello, I have been working to get "Riven" the sequel to Myst to work with the latest wine from cvs on the latest FC5. It works and the sound is almost perfect with OSS, but is totally screwed up when I use ALSA, I don't know whether this is a WINE or Linux issue, so I am cross posting to both lists. Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)

1 0

Re: Added initial version of Wine OleView
by Vitaliy Margolen June 3, 2006

June 3, 2006

Saturday, June 3, 2006, 11:36:45 AM, Piotr Caban wrote: Please change FSF's address to the new one. Vitaliy Margolen

1 0

ntdll: a simple implementation of cross-process NtAllocateVirtualMemory
by tkho＠ucla.edu June 3, 2006

June 3, 2006

Hello, I ran across the need to do memory allocations across processes and came upon Alexander Yaworsky's patch at http://www.winehq.org/pipermail/wine-devel/2004-September/029953.html and took a different approach. Instead of waiting for the target process to check a fd, I changed the implementation to use ptrace to interrupt the target process and execute code in kernel32 that does an mmap/munmap. This is a simple implementation that does not do a full-on call to Nt(Allocate|Free)VirtualMemory inside the target process, mainly because the locks taken in the allocation management code would cause deadlocks. I've done informal testing to make sure the code doesn't crash Wine by running applications alongside this memory-churner: http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.exe http://www.seas.ucla.edu/~kho/wine/alloc_test/alloc_test.cpp One thought that has recently crossed my mind: Building off his framework and putting much of the code in the server may not have been a great idea, since the only real need for the server is to get the unix pid of the thread. Is this a step in the right direction? Comments appreciated! Thomas Kho --- Index: dlls/kernel/kernel32.spec =================================================================== RCS file: /home/wine/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.174 diff -u -r1.174 kernel32.spec --- dlls/kernel/kernel32.spec 27 May 2006 11:36:56 -0000 1.174 +++ dlls/kernel/kernel32.spec 2 Jun 2006 05:43:15 -0000 @@ -1239,3 +1239,8 @@ # Init code @ cdecl __wine_kernel_init() + +# Remote memory allocation +# kernel32 is mapped to the same place in every process +@ cdecl wine_remote_NtAllocateVirtualMemory(ptr long long) +@ cdecl wine_remote_NtFreeVirtualMemory(ptr long) Index: dlls/kernel/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/virtual.c,v retrieving revision 1.18 diff -u -r1.18 virtual.c --- dlls/kernel/virtual.c 23 May 2006 12:48:03 -0000 1.18 +++ dlls/kernel/virtual.c 2 Jun 2006 05:43:15 -0000 @@ -42,6 +42,7 @@ #include "wine/exception.h" #include "excpt.h" #include "wine/debug.h" +#include "wine/library.h" #include "kernel_private.h" @@ -778,3 +779,77 @@ __ENDTRY return FALSE; } + +/*********************************************************************** + * wine_remote_NtAllocateVirtualMemory (KERNEL32.@) + * + * Reentrant function that allocates memory + * + * PARAMS + * base [I] Desired base address + * size [I] Number of bytes to allocate + * prot [I] Memory protection flags + * + * RETURNS + * Success: %eax contains base address of allocated region of pages. + * Failure: %eax is NULL. + */ +void wine_remote_NtAllocateVirtualMemory( LPVOID base, DWORD size, DWORD prot ) +{ + char *mem; + size += sizeof(int *); + mem = wine_anon_mmap(base, size, prot, 0); + /*printf("mmap base=0x%08x size=%d prot=%d, allocated at 0x%x\n", + base, size, prot, mem);*/ + *(int *) mem = size; + + mem += sizeof(int); + /* return base address of allocated memory in eax */ + asm("movl %0, %%eax" + : + :"r"(mem) + :"%eax"); + asm("int3"); /* execution doesn't continue past here */ + return; +} + +/*********************************************************************** + * wine_remote_NtFreeVirtualMemory (KERNEL32.@) + * + * Reentrant function that frees mmap'd memory + * + * PARAMS + * base [I] Desired base address + * size [I] Number of bytes to free + * + * RETURNS + * Success: %eax contains size of unmapped region + * Failure: %eax is 0. + */ +void wine_remote_NtFreeVirtualMemory( LPVOID base, DWORD size ) +{ + int result; + if (size == 0) + { + base = (char *) base - sizeof(int *); + size = *(int *) base; + result = munmap(base, size); + } + else /* FIXME unsafe for invalid base */ + result = 1; + + /*printf("munmap base=0x%08x size=%d, result: %d (%s)\n", + base, size, result, result == 0 ? "success" : "failure");*/ + + if (result == 0) /* munmap success */ + result = size; + else + result = 0; + /* return munmap return value in eax */ + asm("movl %0, %%eax" + : + :"r"(result) + :"%eax"); + asm("int3"); /* execution doesn't continue past here */ + return; +} Index: dlls/ntdll/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v retrieving revision 1.90 diff -u -r1.90 virtual.c --- dlls/ntdll/virtual.c 23 May 2006 12:48:22 -0000 1.90 +++ dlls/ntdll/virtual.c 2 Jun 2006 05:43:16 -0000 @@ -144,6 +144,36 @@ /*********************************************************************** + * remote_op + * + */ +NTSTATUS remote_op( HANDLE process, int opcode, + void* params, int params_size, + void* result, int* result_size ) +{ + NTSTATUS status, remote_status = 0; + + SERVER_START_REQ( remote_operation ) + { + req->handle = process; + req->code = opcode; + if (params) wine_server_add_data( req, params, params_size ); + wine_server_set_reply( req, result, *result_size ); + if (!(status = wine_server_call( req ))) + { + remote_status = reply->status; + if (result) + *result_size = wine_server_reply_size( reply ); + TRACE("result_size=%d\n", *result_size); + } + } + SERVER_END_REQ; + + return status ? status : remote_status; +} + + +/*********************************************************************** * VIRTUAL_GetProtStr */ static const char *VIRTUAL_GetProtStr( BYTE prot ) @@ -1250,8 +1280,8 @@ * NtAllocateVirtualMemory (NTDLL.@) * ZwAllocateVirtualMemory (NTDLL.@) */ -NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, ULONG zero_bits, - SIZE_T *size_ptr, ULONG type, ULONG protect ) +NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, + ULONG zero_bits, SIZE_T *size_ptr, ULONG type, ULONG protect ) { void *base; BYTE vprot; @@ -1265,8 +1295,48 @@ if (!is_current_process( process )) { - ERR("Unsupported on other process\n"); - return STATUS_ACCESS_DENIED; + struct remote_op_params_vm_alloc alloc_params; + struct remote_op_result_vm_alloc alloc_result; + int result_size = sizeof(alloc_result); + typedef void (*allocator_type)(LPVOID base, DWORD size, DWORD prot); + static allocator_type allocator = NULL; + + if (!allocator) + { + HMODULE hkernel32; + UNICODE_STRING module; + ANSI_STRING function; + WCHAR kernel32W[] = {'k','e','r','n','e','l','3','2', + '.','d','l','l',0}; + RtlInitUnicodeString(&module, kernel32W); + RtlInitAnsiString(&function, "wine_remote_NtAllocateVirtualMemory"); + if (LdrGetDllHandle(0, 0, &module, &hkernel32) == STATUS_SUCCESS) + LdrGetProcedureAddress(hkernel32, &function, 0, + (void**)&allocator); + else + return STATUS_DLL_NOT_FOUND; + printf("using allocator in kernel32 at 0x%08x\n", + (unsigned) allocator); + } + + alloc_params.addr = *ret; + alloc_params.zerobits = zero_bits; + alloc_params.size = size; + alloc_params.type = type; + alloc_params.protect = VIRTUAL_GetProt( protect ); + alloc_params.allocator = allocator; + status = remote_op( process, REMOTE_OP_VM_ALLOC, + &alloc_params, sizeof(alloc_params), + &alloc_result, &result_size ); + if (!status) + { + *ret = alloc_result.addr; + *size_ptr = alloc_result.size; + } + printf("NtAllocateVirtualMemory status=0x%08x ptr=0x%08x size=%d\n", + (unsigned) status, (unsigned) alloc_result.addr, + alloc_result.size); + return status; } /* Round parameters to a page boundary */ @@ -1372,8 +1442,42 @@ if (!is_current_process( process )) { - ERR("Unsupported on other process\n"); - return STATUS_ACCESS_DENIED; + struct remote_op_params_vm_free free_params; + struct remote_op_result_vm_free free_result; + int result_size = sizeof(free_result); + typedef void (*deallocator_type)(LPVOID base, DWORD size); + static deallocator_type deallocator = NULL; + + if (!deallocator) { + HMODULE hkernel32; + UNICODE_STRING module; + ANSI_STRING function; + WCHAR kernel32W[] = {'k','e','r','n','e','l','3','2', + '.','d','l','l',0}; + RtlInitUnicodeString(&module, kernel32W); + RtlInitAnsiString(&function, "wine_remote_NtFreeVirtualMemory"); + + if (LdrGetDllHandle(0, 0, &module, &hkernel32) == STATUS_SUCCESS) + LdrGetProcedureAddress(hkernel32, &function, 0, + (void**)&deallocator); + else + return STATUS_DLL_NOT_FOUND; + printf("using deallocator in kernel32 at 0x%08x\n", + (unsigned) deallocator); + } + + free_params.addr = *addr_ptr; + free_params.size = size; + free_params.type = type; + free_params.deallocator = deallocator; + status = remote_op( process, REMOTE_OP_VM_FREE, + &free_params, sizeof(free_params), + &free_result, &result_size ); + if (!status) + *size_ptr = free_result.size; + printf("NtFreeVirtualMemory status=0x%08x size=%d\n", + (unsigned) status, (unsigned) free_result.size); + return status; } /* Fix the parameters */ Index: include/winternl.h =================================================================== RCS file: /home/wine/wine/include/winternl.h,v retrieving revision 1.181 diff -u -r1.181 winternl.h --- include/winternl.h 27 May 2006 11:37:02 -0000 1.181 +++ include/winternl.h 2 Jun 2006 05:43:17 -0000 @@ -2242,7 +2242,8 @@ extern NTSTATUS wine_nt_to_unix_file_name( const UNICODE_STRING *nameW, ANSI_STRING *unix_name_ret, UINT disposition, BOOLEAN check_case ); extern NTSTATUS wine_unix_to_nt_file_name( const ANSI_STRING *name, UNICODE_STRING *nt ); - +extern void wine_remote_NtAllocateVirtualMemory( LPVOID base, DWORD size, DWORD prot ); +extern void wine_remote_NtFreeVirtualMemory( LPVOID base, DWORD size ); /*********************************************************************** * Inline functions Index: include/wine/server_protocol.h =================================================================== RCS file: /home/wine/wine/include/wine/server_protocol.h,v retrieving revision 1.198 diff -u -r1.198 server_protocol.h --- include/wine/server_protocol.h 27 May 2006 11:37:01 -0000 1.198 +++ include/wine/server_protocol.h 2 Jun 2006 05:43:18 -0000 @@ -3727,6 +3727,132 @@ }; + +struct remote_operation_request +{ + struct request_header __header; + obj_handle_t handle; + int code; + /* VARARG(data,bytes); */ +}; +struct remote_operation_reply +{ + struct reply_header __header; + unsigned int status; + /* VARARG(data,bytes); */ +}; +enum remote_op_code +{ + REMOTE_OP_NEW_THREAD, + REMOTE_OP_VM_ALLOC, + REMOTE_OP_VM_FREE, + REMOTE_OP_VM_PROTECT, + REMOTE_OP_VM_QUERY, + REMOTE_OP_VM_MAP, + REMOTE_OP_VM_UNMAP, + REMOTE_OP_VM_FLUSH +}; + +struct remote_op_params_new_thread +{ + int suspend; + void *stack_addr; + unsigned int stack_reserve; + unsigned int stack_commit; + void *start; + void *param; +}; +struct remote_op_result_new_thread +{ + obj_handle_t handle; + thread_id_t tid; +}; + +struct remote_op_params_vm_alloc +{ + void *addr; + unsigned long zerobits; + unsigned long size; + unsigned long type; + unsigned long protect; + void *allocator; +}; +struct remote_op_result_vm_alloc +{ + void *addr; + unsigned long size; +}; + +struct remote_op_params_vm_free +{ + void *addr; + unsigned long size; + unsigned long type; + void *deallocator; +}; +struct remote_op_result_vm_free +{ + unsigned long size; +}; + +struct remote_op_params_vm_protect +{ + void *addr; + unsigned long size; + unsigned long new_prot; +}; +struct remote_op_result_vm_protect +{ + void *base; + unsigned long size; + unsigned long old_prot; +}; + +struct remote_op_params_vm_query +{ + void *addr; + int info_class; +}; + +struct remote_op_params_vm_map +{ + void *addr; + unsigned long zero_bits; + unsigned long commit_size; + unsigned long offset_low; + long offset_high; + unsigned long size; + int inherit; + unsigned long alloc_type; + unsigned long protect; +}; +struct remote_op_result_vm_map +{ + void *base; + unsigned long size; +}; + +struct remote_op_params_vm_flush +{ + void *addr; + unsigned long size; + unsigned long unknown; +}; +struct remote_op_result_vm_flush +{ + void *base; + unsigned long size; +}; + + +struct remote_op_request +{ + enum remote_op_code op_code; + thread_id_t originator; + int params_size; +}; + + enum request { REQ_new_process, @@ -3942,6 +4068,7 @@ REQ_create_symlink, REQ_open_symlink, REQ_query_symlink, + REQ_remote_operation, REQ_NB_REQUESTS }; @@ -4162,6 +4289,7 @@ struct create_symlink_request create_symlink_request; struct open_symlink_request open_symlink_request; struct query_symlink_request query_symlink_request; + struct remote_operation_request remote_operation_request; }; union generic_reply { @@ -4380,8 +4508,9 @@ struct create_symlink_reply create_symlink_reply; struct open_symlink_reply open_symlink_reply; struct query_symlink_reply query_symlink_reply; + struct remote_operation_reply remote_operation_reply; }; -#define SERVER_PROTOCOL_VERSION 234 +#define SERVER_PROTOCOL_VERSION 238 #endif /* __WINE_WINE_SERVER_PROTOCOL_H */ Index: server/process.c =================================================================== RCS file: /home/wine/wine/server/process.c,v retrieving revision 1.167 diff -u -r1.167 process.c --- server/process.c 23 May 2006 12:49:34 -0000 1.167 +++ server/process.c 2 Jun 2006 05:43:18 -0000 @@ -22,12 +22,15 @@ #include "wine/port.h" #include <assert.h> +#include <errno.h> #include <limits.h> +#include <linux/user.h> #include <signal.h> #include <string.h> #include <stdarg.h> #include <stdio.h> #include <stdlib.h> +#include <sys/ptrace.h> #include <sys/time.h> #ifdef HAVE_SYS_SOCKET_H # include <sys/socket.h> @@ -36,6 +39,7 @@ #ifdef HAVE_POLL_H #include <poll.h> #endif +#include <sys/wait.h> #include "ntstatus.h" #define WIN32_NO_STATUS @@ -1081,3 +1085,209 @@ release_object( process ); } } + +/* Accept parameters for remote operation and start it */ +DECL_HANDLER(remote_operation) +{ + int access; + struct process *process; + struct thread *thread; + + /* define required access rights */ + switch( req->code ) + { + case REMOTE_OP_NEW_THREAD: + access = PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION + | PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE; + break; + case REMOTE_OP_VM_ALLOC: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_FREE: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_PROTECT: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_QUERY: access = PROCESS_QUERY_INFORMATION; break; + case REMOTE_OP_VM_MAP: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_UNMAP: access = PROCESS_VM_OPERATION; break; + case REMOTE_OP_VM_FLUSH: access = PROCESS_VM_OPERATION; break; /* FIXME: is access right? */ + default: + set_error( STATUS_INVALID_PARAMETER ); + return; + } + + switch( req->code ) + { + case REMOTE_OP_NEW_THREAD: + break; + case REMOTE_OP_VM_ALLOC: + { +#if defined(linux) && defined(__i386__) + int pid; + struct user_regs_struct oldregs, regs; + struct remote_op_params_vm_alloc *params; + struct remote_op_result_vm_alloc result; + + params = (struct remote_op_params_vm_alloc *) get_req_data(); + + /* get process object */ + if (!(process = get_process_from_handle( req->handle, access ))) + return; + + thread = get_process_first_thread(process); + pid = thread->unix_pid; + release_object(process); + + /*printf("attaching to process with pid %d\n", pid);*/ + if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) + goto errorbeforeattach; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto error; + + memcpy(&oldregs, &regs, sizeof(struct user_regs_struct)); + + regs.eip = (int) params->allocator; + + /* cdecl */ + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-4, params->protect) == -1) + goto error; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-8, params->size) == -1) + goto error; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-12, params->addr) == -1) + goto error; + regs.esp -= 16; + + /* prevent the kernel from restarting the system call. + * see i386_linux_write_pc() in gdb/i386-linux-tdep.c of gdb */ + regs.orig_eax = -1; + + if (ptrace(PTRACE_SETREGS, pid, NULL, &regs) == -1) + goto error; + if (ptrace(PTRACE_CONT, pid, NULL, NULL) == -1) + goto error; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto error; + + /* eax has pointer to allocated memory */ + /*printf("mem allocated in target process at 0x%08x\n", + (unsigned) regs.eax);*/ + if (ptrace(PTRACE_SETREGS, pid, NULL, &oldregs) == -1) + goto error; + if (ptrace(PTRACE_DETACH, pid, NULL, NULL) == -1) + goto error; + + reply->status = regs.eax ? STATUS_SUCCESS + : STATUS_INVALID_PARAMETER; + result.addr = (void *) regs.eax; + result.size = params->size; + + assert(sizeof(result) <= get_reply_max_size()); + set_reply_data(&result, sizeof(result)); + + break; + +error: + printf("error!\n"); + ptrace(PTRACE_DETACH, pid, NULL, NULL); + set_error( STATUS_INVALID_PARAMETER ); + break; + +errorbeforeattach: + printf("error before attach!\n"); + set_error( STATUS_INVALID_PARAMETER ); + break; +#else + set_error( STATUS_NOT_IMPLEMENTED ); +#endif + } + case REMOTE_OP_VM_FREE: + { +#if defined(linux) && defined(__i386__) + int pid; + struct user_regs_struct oldregs, regs; + struct remote_op_params_vm_free *params; + struct remote_op_result_vm_free result; + + params = (struct remote_op_params_vm_free *) get_req_data(); + + /* get process object */ + if (!(process = get_process_from_handle( req->handle, access ))) + return; + + thread = get_process_first_thread(process); + pid = thread->unix_pid; + release_object(process); + + /*printf("attaching to process with pid %d\n", pid);*/ + if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) + goto freeerrorbeforeattach; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto freeerror; + memcpy(&oldregs, &regs, sizeof(struct user_regs_struct)); + + regs.eip = (int) params->deallocator; + + /* cdecl */ + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-4, params->size) == -1) + goto freeerror; + if (ptrace(PTRACE_POKEDATA, pid, regs.esp-8, params->addr) == -1) + goto freeerror; + regs.esp -= 12; + + /* prevent the kernel from restarting the system call. + * see i386_linux_write_pc() in gdb/i386-linux-tdep.c of gdb */ + regs.orig_eax = -1; + + if (ptrace(PTRACE_SETREGS, pid, NULL, &regs) == -1) + goto freeerror; + if (ptrace(PTRACE_CONT, pid, NULL, NULL) == -1) + goto freeerror; + + wait(NULL); + if (ptrace(PTRACE_GETREGS, pid, NULL, &regs) == -1) + goto freeerror; + + /* eax has return value */ + /*printf("munmap'd in target process, result=0x%08x\n", + (unsigned) regs.eax);*/ + if (ptrace(PTRACE_SETREGS, pid, NULL, &oldregs) == -1) + goto freeerror; + if (ptrace(PTRACE_DETACH, pid, NULL, NULL) == -1) + goto freeerror; + + reply->status = regs.eax ? STATUS_SUCCESS + : STATUS_INVALID_PARAMETER; + result.size = regs.eax; + + assert(sizeof(result) <= get_reply_max_size()); + set_reply_data(&result, sizeof(result)); + + break; + +freeerror: + printf("error!\n"); + ptrace(PTRACE_DETACH, pid, NULL, NULL); + set_error( STATUS_INVALID_PARAMETER ); + break; + +freeerrorbeforeattach: + printf("error before attach!\n"); + set_error( STATUS_INVALID_PARAMETER ); + break; +#else + set_error( STATUS_NOT_IMPLEMENTED ); +#endif + } + case REMOTE_OP_VM_PROTECT: + case REMOTE_OP_VM_QUERY: + case REMOTE_OP_VM_MAP: + case REMOTE_OP_VM_UNMAP: + case REMOTE_OP_VM_FLUSH: + break; + default: + set_error( STATUS_INVALID_PARAMETER ); + return; + } +} Index: server/protocol.def =================================================================== RCS file: /home/wine/wine/server/protocol.def,v retrieving revision 1.198 diff -u -r1.198 protocol.def --- server/protocol.def 27 May 2006 11:37:01 -0000 1.198 +++ server/protocol.def 2 Jun 2006 05:43:18 -0000 @@ -2615,3 +2615,124 @@ @REPLY VARARG(target_name,unicode_str); /* target name */ @END + + +/* Accept parameters for remote operation and start it */ +(a)REQ(remote_operation) + obj_handle_t handle; /* process handle */ + int code; /* operation code (see below) */ + VARARG(data,bytes); /* operation parameters (see below) */ +(a)REPLY + unsigned int status; /* operation status */ + VARARG(data,bytes); /* operation result data (see below) */ +(a)END +enum remote_op_code +{ + REMOTE_OP_NEW_THREAD, + REMOTE_OP_VM_ALLOC, + REMOTE_OP_VM_FREE, + REMOTE_OP_VM_PROTECT, + REMOTE_OP_VM_QUERY, + REMOTE_OP_VM_MAP, + REMOTE_OP_VM_UNMAP, + REMOTE_OP_VM_FLUSH +}; + +struct remote_op_params_new_thread +{ + int suspend; + void *stack_addr; + unsigned int stack_reserve; + unsigned int stack_commit; + void *start; + void *param; +}; +struct remote_op_result_new_thread +{ + obj_handle_t handle; + thread_id_t tid; +}; + +struct remote_op_params_vm_alloc +{ + void *addr; + unsigned long zerobits; + unsigned long size; + unsigned long type; + unsigned long protect; + void *allocator; +}; +struct remote_op_result_vm_alloc +{ + void *addr; + unsigned long size; +}; + +struct remote_op_params_vm_free +{ + void *addr; + unsigned long size; + unsigned long type; + void *deallocator; +}; +struct remote_op_result_vm_free +{ + unsigned long size; +}; + +struct remote_op_params_vm_protect +{ + void *addr; + unsigned long size; + unsigned long new_prot; +}; +struct remote_op_result_vm_protect +{ + void *base; + unsigned long size; + unsigned long old_prot; +}; + +struct remote_op_params_vm_query +{ + void *addr; + int info_class; +}; + +struct remote_op_params_vm_map +{ + void *addr; + unsigned long zero_bits; + unsigned long commit_size; + unsigned long offset_low; + long offset_high; + unsigned long size; + int inherit; + unsigned long alloc_type; + unsigned long protect; +}; +struct remote_op_result_vm_map +{ + void *base; + unsigned long size; +}; + +struct remote_op_params_vm_flush +{ + void *addr; + unsigned long size; + unsigned long unknown; +}; +struct remote_op_result_vm_flush +{ + void *base; + unsigned long size; +}; + +/* structure for marshalling remote operation requests */ +struct remote_op_request +{ + enum remote_op_code op_code; + thread_id_t originator; + int params_size; +}; Index: server/request.h =================================================================== RCS file: /home/wine/wine/server/request.h,v retrieving revision 1.132 diff -u -r1.132 request.h --- server/request.h 23 May 2006 12:49:34 -0000 1.132 +++ server/request.h 2 Jun 2006 05:43:18 -0000 @@ -323,6 +323,7 @@ DECL_HANDLER(create_symlink); DECL_HANDLER(open_symlink); DECL_HANDLER(query_symlink); +DECL_HANDLER(remote_operation); #ifdef WANT_REQUEST_HANDLERS @@ -542,6 +543,7 @@ (req_handler)req_create_symlink, (req_handler)req_open_symlink, (req_handler)req_query_symlink, + (req_handler)req_remote_operation, }; #endif /* WANT_REQUEST_HANDLERS */ Index: server/trace.c =================================================================== RCS file: /home/wine/wine/server/trace.c,v retrieving revision 1.310 diff -u -r1.310 trace.c --- server/trace.c 27 May 2006 11:37:01 -0000 1.310 +++ server/trace.c 2 Jun 2006 05:43:19 -0000 @@ -3263,6 +3263,21 @@ dump_varargs_unicode_str( cur_size ); } +static void dump_remote_operation_request( const struct remote_operation_request *req ) +{ + fprintf( stderr, " handle=%p,", req->handle ); + fprintf( stderr, " code=%d,", req->code ); + fprintf( stderr, " data=" ); + dump_varargs_bytes( cur_size ); +} + +static void dump_remote_operation_reply( const struct remote_operation_reply *req ) +{ + fprintf( stderr, " status=%08x,", req->status ); + fprintf( stderr, " data=" ); + dump_varargs_bytes( cur_size ); +} + static const dump_func req_dumpers[REQ_NB_REQUESTS] = { (dump_func)dump_new_process_request, (dump_func)dump_get_new_process_info_request, @@ -3477,6 +3492,7 @@ (dump_func)dump_create_symlink_request, (dump_func)dump_open_symlink_request, (dump_func)dump_query_symlink_request, + (dump_func)dump_remote_operation_request, }; static const dump_func reply_dumpers[REQ_NB_REQUESTS] = { @@ -3693,6 +3709,7 @@ (dump_func)dump_create_symlink_reply, (dump_func)dump_open_symlink_reply, (dump_func)dump_query_symlink_reply, + (dump_func)dump_remote_operation_reply, }; static const char * const req_names[REQ_NB_REQUESTS] = { @@ -3909,6 +3926,7 @@ "create_symlink", "open_symlink", "query_symlink", + "remote_operation", }; static const struct

6 15

re: MSI query tests
by Dan Kegel June 3, 2006

June 3, 2006

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

3 5

Re: Added initial version of Wine OleView
by James Hawkins June 3, 2006

June 3, 2006

On 6/3/06, Piotr Caban <piotr.caban(a)gmail.com> wrote: > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA The address has changed, and we recently did a sweep of the code base changing to the new address, so we'd like to keep the old address out. * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA +/* BINRES toolbar.bmp */ +IDB_TOOLBAR BITMAP DISCARDABLE toolbar.bmp +/* { +'42 4d 36 12 00 00 00 00 00 00 36 00 00 00 28 00' +'00 00 60 00 00 00 10 00 00 00 01 00 18 00 00 00' +'00 00 00 12 00 00 12 0b 00 00 12 0b 00 00 00 00' The patch is quite large by Wine's standards. You could reduce the size by taking out the bitmap for now and sending that separately; otherwise, it looks good and keep up the good work! -- James Hawkins

1 0

Re: Built-in iexplore
by Jonathan Ernst June 3, 2006

June 3, 2006

Le vendredi 02 juin 2006 à 13:42 -0700, Brandon a écrit : > Daniel Skorka wrote: > > Oleksii Krykun <krikun(a)academy.kiev.ua.nospam> wrote: > > > $ wine iexplore > > > fixme:shdocvw:IEWinMain "" 1 > > > fixme:ole:CoResumeClassObjects stub > > > Could not load Mozilla. HTML rendering will be disabled. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Where is aq problem? > > > > Guess. > > I get the same thing even though I have mozilla installed. I'm using > wine in 64-bit linux, though, so that probably has something to do with > it. You don't need mozilla, but the Mozilla activex control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though (so I'm CCing wine-devel and Jacek to see if something has to be changed in nsembed.c). Best regards. Jonathan Ernst

1 0

Re: Re: Re: Wine 1.0 Tasks
by fenix＠club-internet.fr June 3, 2006

June 3, 2006

----Message d'origine---- >Date: Fri, 2 Jun 2006 21:27:53 +0200 >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: Dan Kegel <dank(a)kegel.com> >Copie à: wine-devel(a)winehq.org, >Sujet: Re: Re: Wine 1.0 Tasks > >On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: >> On 5/30/06, Scott Ritchie <scott(a)open-vote.org> wrote: >> > > It might be, but the heavy hitters I know of who have taken a look at >> > > it in detail have concluded that an X change really is needed.] >> > >> > Is this really a problem? Another version of X is due out in about 4 >> > months (probably the earliest we could possibly see Wine 1.0), so why >> > can't we just help write an X extension to tackle the bug? >> >> Not really a problem. It'll just take some time to trickle out to the world. >> We may also have to get Nvidia and ATI on board so they can implement >> the extension in their drivers. > >And for it to be taken, I guess we would need to not only write the >extension, but a 'reference implementation' (I would guess in DRI / Mesa) >and get it approved by the FD.o people. > >But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X >window would be the easiest idea to investigate (because it would not only >fixes this issue but also the mutiple windows with multiple pixel formats >problem that the former 'extension' solution does not). > i thought the same idea. But investigation modifications in x11drv to permit wine x pixmaps access for wined3d/opengl will fix many problems (but not hthe multiple pixel formats) Anyway we must move some code of wined3d and opengl32 (GLX code, etc...) to x11drv as it permit : - to handle this problems without hacks (ie many ExtEscape) - to help macos-X to port wined3d and opengl (all specific cost must be on x11drv/qwartwdrv) > Lionel (in 'not even time to read wine-devel' mode :-) ) > Well, at least i take time for it :) (and reviewing the flood of d3d patches) Waiting for you for coding :p Regards, Raphael

1 0

Re: How are we doing?
by Juan Lang June 3, 2006

June 3, 2006

> Especially the code that is responded to as , I know it's a mess to > look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

Quartz driver
by Emmanuel Maillard June 2, 2006

June 2, 2006

Hi all, Quartz driver is up to date on Darwine CVS. 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. Cheers Emmanuel

3 2

Re: Re: Wine 1.0 Tasks
by fenix＠club-internet.fr June 2, 2006

June 2, 2006

Hi, >> (Note the #3902 should be renamed as 'DIB Engine rewrite' > >Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 :) >> and i don't think is mandatory for 1.0) > >Probably right. Let's create the next milestone after 1.0, say 1.1, and start >retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; >some bugs they retarget early, some just before the release.) > >> But i think we must fix users most hated bugs as: >> - dsound deadlocks/craps >> - openGL problems (multi contexts, fb/visual configs) >> - lotus problems > >The OpenGL child window bug, >http://bugs.winehq.org/show_bug.cgi?id=2398 >probably won't be fixed for 1.0 because it requires >an X server change. No it must be doable without X changes (But X additions as GLX_EXT_texture_from_pixmap will help a lot). Only problem is to find time to fix it (as lionel, i have no time for now). Anyway i having a simple and downloadable application to reproduce this problem (not lightwave) must help. The only parts who really needs X change are for: - glShareList: sharing fb/visual config between exitings GLX contexts - dinput mouse management >I'm not sure lotus notes problems should block 1.0, as IBM has a native >Linux client now, but if someone wants to fix them (especially the ones >in usp10.dll netapi32.dll, that would be great. agree :) >> Note: it will be interesting to add user votes to wine-bugs (ala kde) to >> better see user needs. > >There are already user votes in bugzilla, that should suffice. >- Dan Oups i never seen it :) Regards, Raphael

9 11

Re: Missing LeaveCriticalSection on error paths (found by Smatch).
by Michael Stefaniuc June 2, 2006

June 2, 2006

Michael Stefaniuc wrote: > can somebody more familiar with this code confirm that on the error > paths the CriticalSection should be released? I'm not sure about it as > the function is supposed to keep the lock held when exiting without > error; there is a d3ddevice_unlock_update() function that releases the > lock. Asked Lionel Ulmer on irc and the patch is correct. But according to Stefan Dösinger that code will be replaced by his code "in the next couple of days". bye michael > --- > > dlls/ddraw/device_opengl.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > dd0b9b20d26984ae408c1a7727323a08d44e0d95 > diff --git a/dlls/ddraw/device_opengl.c b/dlls/ddraw/device_opengl.c > index d19996e..4c663a6 100644 > --- a/dlls/ddraw/device_opengl.c > +++ b/dlls/ddraw/device_opengl.c > @@ -3775,10 +3775,12 @@ static void d3ddevice_lock_update(IDirec > buffer_color = GL_BGRA; > } else { > ERR(" unsupported pixel format at device locking.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > } else { > ERR(" unsupported pixel format at device locking - alpha on frame buffer.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > > > > ------------------------------------------------------------------------ > > -- 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

1 0

Re: test case for MSI problem in America's Army installer
by Dan Kegel June 2, 2006

June 2, 2006

I think you can just compile and run it with visual C++ as a standalone app, with the right commandline options to the compiler. Let's see: try the instructions here: http://www.winehq.com/hypermail/wine-devel/2005/05/0865.html You can also build with the wine build system and then run the executable with a single commandline option giving the name of the test to run. Better ask on wine-devel, I have to run. On 6/2/06, EA Durbin <ead1234(a)hotmail.com> wrote: > How does one use the test application in the msi/tests folder? > > I know you run it with wine, but without looking through all of the code in > the application to determine this could you maybe advise me what it expects > for arguments, or how to work with it? > > Do you pass it an misdatabase, and a DB argument, or how does this utility > work? > > I don't usually hack in C, but im somewhat capable. I could write a mean > Hello World Application back in college. My day usually consists of parsing > data with PERL, but that doesn't mean I can't pick up C again. > > I'd appreciate it if you focused some energy on it, but I would also like to > know how it works so I can contribute in the future. > > > >From: "Dan Kegel" <dank(a)kegel.com> > >To: wine-devel <wine-devel(a)winehq.org> > >Subject: re: test case for MSI problem in America's Army installer > >Date: Fri, 2 Jun 2006 07:06:30 -0700 > > > >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 > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

winedbg: newbie question (sorry...)
by Molle Bestefich June 2, 2006

June 2, 2006

Hello Carsten Niehaus (cniehaus(a)gmx.de) over on wine-users gets a page fault when he tries to print with this app: http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip He's posted a backtrace: > fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in printer list so trying to find default > wine: Unhandled page fault on write access to 0x0000002e at address 0x7f6a2540 (thread 0009), starting debugger... > Backtrace: > =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) > 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) [snip!] > 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) I'm slightly cli-debugger-clueless, so could one of you guys please tell me how to convert this: PRINTDLG_WMCommandA+0x619 into a proper line number reference to the source file?

2 1

RFC - wine-macos mailing list
by Jeremy White June 2, 2006

June 2, 2006

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

11 11

Re: comctl32: Fix loading string from resources (take 2)
by Dmitry Timoshkov June 2, 2006

June 2, 2006

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > 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. It would be appropriate to provide a test case showing correct LoadString behaviour and fix LoadString in Wine if it confirms the statement above since Wine clearly returns the size of the string resource if the passed buffer is NULL. -- Dmitry.

1 0

Wine 1.0 tasks: installers
by Dan Kegel June 2, 2006

June 2, 2006

James Hawkins and I think we should come up with a list of installers that need to run before we release Wine 1.0. Looking at http://www.winehq.org/pipermail/wine-devel/2006-March/045634.html and http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_des… I made a list biased towards freely downloadable apps, programming tools, things Munich wants, stuff that has been passionately discussed of late (e.g. America's Army), educational apps, and anything that smacks of long-unfinished business. Here's what I ended up with: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Some of those might already be fixed, hopefull we can just close out a couple. And a couple might be too hard for 1.0 (.net, say), it's ok to defer them to 1.1 later if we have to. Ideally we'd also have cxtest scripts for all of these installers, so Codeweavers can use them to validate new releases. How's that sound? - Dan

2 2

RFC - device notifications idea
by Damjan Jovanovic June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 2, 2006

June 2, 2006

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 June 1, 2006

June 1, 2006

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 June 1, 2006

June 1, 2006

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 June 1, 2006

June 1, 2006

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

MSI SQL
by EA Durbin June 1, 2006

June 1, 2006

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.

1 0

Re: winspool/tests: Use 0xdeadbeef as magic Value
by Jeff Latimer June 1, 2006

June 1, 2006

A minor spelling mistake, deaddeef instread of deadbeef. Jeff Detlef Riekenberg wrote: >I was using 0x00dead00 before, but Dmitry suggested 0xdeadbeef, as this > > > >-#define MAGIC_DEAD 0x00dead00 >+#define MAGIC_DEAD 0xdeaddeef > >

2 1

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom
by Mike Hearn June 1, 2006

June 1, 2006

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

4 4

wine problems on a 64bit system
by Pavel Troller June 1, 2006

June 1, 2006

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 ? With regards, Pavel Troller

6 14

Text input box with scrollbar
by Augusto Arcoverde da Rocha June 1, 2006

June 1, 2006

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. Thanks, Augusto Arcoverde da Rocha

3 2

Re: winspool/tests: [1/3] Tests for GetPrintProcessorDirectory
by Alexandre Julliard June 1, 2006

June 1, 2006

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

2 2

Winecfg add CoreAudio to audio drivers list
by Emmanuel Maillard June 1, 2006

June 1, 2006

Changelog : Winecfg add CoreAudio to audio drivers list thanks Emmanuel

1 0

Re: Re: How are we doing?
by fenix＠club-internet.fr June 1, 2006

June 1, 2006

----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

4 3

Wine 1.0 Tasks
by Dan Kegel June 1, 2006

June 1, 2006

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… 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 -- Wine for Windows ISVs: http://kegel.com/wine/isv

8 14

Re: comctl32: Fix loading string from resources
by Alexandre Julliard June 1, 2006

June 1, 2006

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

2 1

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom
by Francois Gouget June 1, 2006

June 1, 2006

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.

1 0

Re: svrapi: add stub implementation
by Robert Shearman June 1, 2006

June 1, 2006

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? -- Rob Shearman

2 1