July 2008 - Wine-Devel - list.winehq.org

Re: msi: Partially revert commit 26ae65898685a67f7be29cb94e679e4eb80fc6f5 [RESEND]
by Alexandre Julliard July 17, 2008

July 17, 2008

"James Hawkins" <jhawkins(a)codeweavers.com> writes: > Anything wrong with this patch? While the commit in question is right > in some ways, it's not completely correct and breaks the Office > installers. You should add fixes on top of it instead of reverting then redoing it, that makes a mess of the history, especially in the tests with things moving in and out of todo_wine several times. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: icmp: Forward Icmp* functions to iphlpapi
by Alexandre Julliard July 17, 2008

July 17, 2008

"Juan Lang" <juan.lang(a)gmail.com> writes: > Depends on the iphlpapi patches I just sent. You should do the code move in a single patch so that it's seen as a real move, instead of a copy and then a delete two commits later. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/10] WineD3D: Add extension information to the states
by Ivan Gyurdiev July 17, 2008

July 17, 2008

> Stefan Dösinger wrote: This doesn't look bad on the surface, but I have two concerns: 1. Does not scale to more complex support checks. I suspect you'll have to have to rewrite this as soon as a case comes up that requires more than a single support check to establish support. A function pointer may help here. It would also be interesting to look at similarities and differences with the ffp pipeline replacement - which is essentially the same thing on a much larger scale, where multiple states are replaced rather than a single state. Can these support checks handle the case where an extension would control replacing a group of states ? 2. Not necessarily relating to this patch, but in general I would be wary of trying to replace every if check with a pointer. Splitting on extension support is probably ok. Ivan

3 4

Launching Unix binaries
by Oleh R. Nykyforchyn July 16, 2008

July 16, 2008

After upgrade to Wine 1.1.0 from 0.9.56 I found out that my WinEdt can't launch Unix binaries (xdvi, xterm etc) anymore. A dialog box saying "Cannot execute command ..." appears, but binaries are started anyway. AFAICS it is caused by patch by Dmitry Timoshkov that introduces "winoldap.mod". Now WinExec creates a process and then executes wait_input_idle() that fails for Unix processes that have hProcess == 0. I attach a quick fix that solves the problem for me, but I am not sure that my patch is quite correct and complete. Now we can only check that a Unix process is started successfully, but we don't know what is going on later. Can somebody propose a better solution? --- kernel32/process.c.orig 2008-06-27 17:24:42.000000000 +0300 +++ kernel32/process.c 2008-07-16 10:03:15.000000000 +0300 @@ -1987,8 +1987,8 @@ if (CreateProcessA( NULL, cmdline, NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info )) { - /* Give 30 seconds to the app to come up */ - if (wait_input_idle( info.hProcess, 30000 ) == WAIT_FAILED) + /* Give 30 seconds to the non-Unix app to come up */ + if (info.hProcess && (wait_input_idle( info.hProcess, 30000 ) == WAIT_FAILED)) WARN("WaitForInputIdle failed: Error %d\n", GetLastError() ); ret = 33; /* Close off the handles */ --- kernel32/kernel16.c.orig 2008-07-16 09:59:04.000000000 +0300 +++ kernel32/kernel16.c 2008-07-16 10:04:12.000000000 +0300 @@ -190,6 +190,7 @@ if (CreateProcessA( NULL, cmdline, NULL, NULL, FALSE, 0, NULL, NULL, &startup, &info )) { + if ( info.hProcess ) { /* Give 10 seconds to the app to come up */ if (wait_input_idle( info.hProcess, 10000 ) == WAIT_FAILED) WARN("WaitForInputIdle failed: Error %d\n", GetLastError() ); @@ -199,6 +200,15 @@ GetExitCodeProcess( info.hProcess, &exit_code ); CloseHandle( info.hThread ); CloseHandle( info.hProcess ); + } + else + { + /* Unix binary */ + ReleaseThunkLock( &count ); + exit_code = 33; + CloseHandle( info.hThread ); + CloseHandle( info.hProcess ); + } } else ReleaseThunkLock( &count );

1 0

Re: comctl32: status[1/5]: don't issue a WM_PAINT during a WM_CREATE
by James Hawkins July 16, 2008

July 16, 2008

On Wed, Jul 16, 2008 at 3:02 PM, Mikołaj Zalewski <mikolaj(a)zalewski.pl> wrote: > I haven't noticed such a thing on Windows and it seems strange to run the > WM_PAINT handler before WM_CREATE finishes - it may e.g. break some apps > that subclass this control. > There's only one way to find out for sure. Write a test case. -- James Hawkins

1 0

How long does it take you to compile wine?
by Dan Kegel July 16, 2008

July 16, 2008

Way back five years ago, we all compared notes on how long it took to build Wine on our systems. http://www.winehq.org/site/?issue=149#Compile%20Time%20Comparisons%20/%20Ti… Today I measured it on a new computer (with a spiffy new Intel dual core e7200 processor with 2GB of RAM, http://kegel.com/new-computer-2008.html ). Result: ... it takes me a bit longer today on this machine (11 minutes) to build as it did then on a dual cpu hot rod (8 minutes). I guess Moore's Law isn't quite keeping up with Wine's code growth :-)

12 15

Re: libs/wine/debug: Avoid over-allocating memory in default_dbgstr_wn.
by Michael Karcher July 16, 2008

July 16, 2008

Am Dienstag, den 15.07.2008, 15:55 -0700 schrieb Dan Hipschman: > if (n < 0) n = 0; > size = 12 + min( 300, n * 5 ); > - dst = res = funcs.get_temp_buffer( n * 5 + 7 ); > + dst = res = funcs.get_temp_buffer( size ); This looks like fixing an under-allocation, not over-allocation. The patched code allocates at least 5 bytes more, and never less than 312. Regards, Michael Karcher

2 2

Re: [PATCH] Workarounds for lotro bugs
by Rob Shearman July 16, 2008

July 16, 2008

2008/7/16 Daniel Santos <daniel(a)bytesage.com>: > + if(_lotro_hack_enabled > + && to->sa_family == AF_INET > + && dwBufferCount == 1 > + && _lotro_hack(&get_per_thread_data()->lotro_msgs, > + s, lpBuffers, (struct WS_sockaddr_in*)to)) { > + Sleep(10); > + if(lpNumberOfBytesSent) { > + *lpNumberOfBytesSent = lpBuffers->len; > + } > + return 0; > + } > + Hi Daniel, While I appreciate the effort you've gone to to fix a bug, I don't see any analysis in the bug that suggests this is the only possible solution. It seems to me as though LOTRO is calling WSASendTo in a tight loop and that it isn't such a tight loop on Windows. A +relay log will reveal which calls it is making in that thread. You can then build a similar test program and time how long each call takes on Windows and Wine and see where the difference is (although it probably won't be as simple as that as there will be other threads interacting in LOTRO). At a guess, it might simply be that Windows yields to other threads after making a call to a network function. -- Rob Shearman

2 1

WWN 349
by Kirill K. Smirnov July 16, 2008

July 16, 2008

Hi, Wine main page is not updated - there are no link to WWN 349. Partial patch? -- Kirill

1 0

d3dx9: Add stubs for the ID3DXSprite functions [2/2, try 2]
by tony.wasserka＠freenet.de July 16, 2008

July 16, 2008

The last patch was diff'ed against an old version of dlls/d3dx9_36/Makefile.in. Applies fine now. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0