Re: Problems with ~/.wine/dosdevices symlinks on samba servers
2009/6/22 Dan Kegel : > On Sun, Jun 21, 2009 at 7:25 PM, Dan Kegel wrote: >> According to >> http://groups.google.com/group/Google-Labs-Picasa-for-Linux/browse_thread/thread/9b0c746965d34f73 >> a user is having trouble because the symlinks in ~/.wine/dosdevices >> don't work when on a Samba share. >> >> It's unfortunate at this late date to realize that one >> of the key choices Wine made isn't compatible >> with the cifs/samba combination... but I guess >> nobody expected home directories to be served >> with that network filesystem. >> >> If this turns out to be a real problem, what are our options? >> The first thing that comes to mind is to notice >> the problem and fall back to underscore instead of colon somehow... > > FWIW, he also posted it to > http://groups.google.com/group/linux.samba/browse_thread/thread/a00c04cccf1a40fb# > > > In my opinion CIFS is unsuitable for such Unixy things as home directories. Is the problem just the : in the filename (in which case it's expected behaviour on Windowsy filesystems) or the fact that a symlink is being used?
XI2 DirectInput/RawInput/WH_*_LL hooks
I've been thinking about the XI2 a fair bit since the last time we discussed it on the mailing list, and a few things have come to mind, which I think need sanity checking before I explore any harder. I'm assuming we want one X11 connection turning XI2 events into WH_*_LL events, RawInput events, and DirectInput events, simply because WH_*_LL events are actually sent out by wineserver to all processes, so we only want one of those per XI2 event. This leads me to retaining the current WH_*_LL-based implementation of DI, but with cursor management and control (ie all the stuff Exclusive mode brings to the table) handling via a graphics driver hook or similar. However, the mechanism for feeding the XI2 events to the wineserver as WH_*_LL events is a little tricky. XI2 events need their own thread and hence X connection, as we cannot rely on a WinMain loop hitting X11DRV_MsgWaitForMultipleObjectsEx in a timely manner, or in fact all. The three possibilities I see are: *) Most recent foreground application catches XI2 events in its own spawned thread. Need to elect a replacement on process exit. Easiest to co-ordinate with non-XI2 hook-feeding code. *) Wineserver gains an X11 connection, for XI2 use only. This is generally bad, only here for completeness. *) A new process (ala services.exe) which grabs XI2 events from X11 via its own connection and feeds them to the wineserver. I'm inclined to think the latter one is the best option of the three, and it requires simply that the winex11.drv detect XI2 presence and if found, it disable its own WH_*_LL feeding code and spawn the XI2 process if it is not already running. It avoids the complicated coordination dance you would need for the first option to avoid losing messages. Mind you, I've been thinking this away from the codebase, so it's mostly mindwork right now. But unless I get any better suggestions or criticism, I'll prolly knock up a sample implementation of the third option next time I play with this, and see if I can get the DI keyboard interface implemented. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpAeuS6hjBS1.pgp Description: PGP signature
Re: Problems with ~/.wine/dosdevices symlinks on samba servers
On Sun, Jun 21, 2009 at 7:25 PM, Dan Kegel wrote: > According to > http://groups.google.com/group/Google-Labs-Picasa-for-Linux/browse_thread/thread/9b0c746965d34f73 > a user is having trouble because the symlinks in ~/.wine/dosdevices > don't work when on a Samba share. > > It's unfortunate at this late date to realize that one > of the key choices Wine made isn't compatible > with the cifs/samba combination... but I guess > nobody expected home directories to be served > with that network filesystem. > > If this turns out to be a real problem, what are our options? > The first thing that comes to mind is to notice > the problem and fall back to underscore instead of colon somehow... FWIW, he also posted it to http://groups.google.com/group/linux.samba/browse_thread/thread/a00c04cccf1a40fb#
Problems with ~/.wine/dosdevices symlinks on samba servers
According to http://groups.google.com/group/Google-Labs-Picasa-for-Linux/browse_thread/thread/9b0c746965d34f73 a user is having trouble because the symlinks in ~/.wine/dosdevices don't work when on a Samba share. It's unfortunate at this late date to realize that one of the key choices Wine made isn't compatible with the cifs/samba combination... but I guess nobody expected home directories to be served with that network filesystem. If this turns out to be a real problem, what are our options? The first thing that comes to mind is to notice the problem and fall back to underscore instead of colon somehow...
Re: Test patch
On Sat, Jun 20, 2009 at 9:37 PM, Joshua Reisenauer wrote: > I am sending this test patch to see if I used the correct formatting. I > would like feedback on what the wine dev community likes and doesn't like in > patches. For example do you prefer .txt or .patch? .txt please, much easier to read in browser. Please avoid tabs. Many of the changes you made aren't needed, aren't appropriate. E.g., 'etc.' is right, 'etc...' is not (unless that's a British thing I don't know about). Some of the places you capitalized aren't needed. The 'patch file' listed in the README should be deleted, since it's no longer provided. -- -Austin
Re: Wine translation statistics sources
The results for Wone 1.0.x ( http://pf128.krakow.sdi.tpnet.pl/wine-transl/ ) won't open (tryied several times yesterday and today) The correct URL is http://www.mikolaj.zalewski.pl/wine-transl/1.0.x/ . This can be fixed in config.php (I've forgotten to update the example config in the sources). Of course, this can be also moved to WineHQ (by creating a new tree with the same PHP scripts, but with different config and data) to have everything in one place. Mikołaj
Re: msi: add dummy thread just to initialize an MTA; fixes bug 18070
On Sunday 21 June 2009 07:39:39 pm Dan Kegel wrote: > I'm more worried about thread shutdown. > It seems wrong to just hope that the thread finishes terminating > before DllMain returns and the system calls FreeLibrary, > but as oldnewthing explains, you can't wait for a thread to > terminate inside DllMain. I don't see a way to it cleanly in DllMain. You could ignore thread shutdown and let the system clean it up at process exit, but then you'd leak threads when an app keeps loading and unloading the dll. However, it might work if you start the dummy thread right before running the first custom action and take it down after the last one has finished, e.g. in ACTION_FinishCustomActions. > What would the elegant solution be? Running the custom action in a separate process. > > Another blog explains that inheritance of an existing MTA is just a > > side effect of starting the custom action in a different process, one > > that happens to have initialized an MTA already. > > Sorry, I'm feeling dense. Which other blog, and what's interesting about > that? Sorry, I should have looked it up: http://blogs.msdn.com/astebner/archive/2005/02/07/368917.aspx The interesting bit is in the comments. -Hans
Re: Strange issue with recv in Launchpad Enhanced
On Sun, Jun 21, 2009 at 10:23 AM, Erich Hoover wrote:
> On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic wrote:
>
>> ...
>>
> Maybe the memory is writable but not readable, and
>> WSARecvFrom()/recv() is reading it while memcpy() is not?
>>
>
>> Maybe the memory is from a DIB section which Wine lazily mprotects and
>> the kernel isn't raising SIGSEGV for the protection to be reapplied?
>> Does simply zero-filling buf before calling WSARecvFrom() help?
>>
>
> The memory should be a buffer from the calling application that it is using
> temporarily to store update data before saving it to the hard-disk. Yes,
> oddly enough zero-filling the buffer before calling WSARecvFrom() also fixes
> the problem.
>
> So, where exactly should I be looking to find the real problem? As far as
> I can tell the memory for the buffer is being allocated immediate prior to
> the call and the request is for read/write access:
> 0009:Call KERNEL32.VirtualAlloc(01b85000,0004,1000,0004)
> ret=79e74a2b
> 0009:Ret KERNEL32.VirtualAlloc() retval=01b85000 ret=79e74a2b
> 0009:Call ws2_32.recv(0380,01ba4fc1,000178d0,) ret=0036a287
> ...
>
After looking over the documentation for VirtualAlloc, it appears that Wine
should be zeroing the returned memory if MEM_COMMIT is specified. Making
this change (rather than playing around in the socket code) also fixes the
problem (see attached patch). Do you think this step occurs if write access
isn't specified?
Erich Hoover
ehoo...@mines.edu
diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c
index 33918ca..be7ed24 100644
--- a/dlls/ntdll/virtual.c
+++ b/dlls/ntdll/virtual.c
@@ -1754,6 +1754,10 @@ NTSTATUS WINAPI NtAllocateVirtualMemory( HANDLE process, PVOID *ret, ULONG zero_
if (status == STATUS_SUCCESS)
{
+ /* A successful commit operation must zero the allocated memory */
+ if (type & MEM_COMMIT)
+ memset(base, 0, size);
+
*ret = base;
*size_ptr = size;
}
Re: msi: add dummy thread just to initialize an MTA; fixes bug 18070
On Sun, Jun 21, 2009 at 8:13 AM, Hans Leidekker wrote: > It appears that calling CreateThread in DLL_PROCESS_ATTACH can cause > deadlocks: > > http://blogs.msdn.com/mgrier/archive/2005/06/21/431378.aspx There seems to be a better explanation of the deadlock issues at http://blogs.msdn.com/oldnewthing/archive/2007/09/04/4731478.aspx I'm perfectly willing to believe that one should not create threads or wait for them to finish in DllMain, out of an abundance of caution, but I don't see how this particular case could deadlock. I'm more worried about thread shutdown. It seems wrong to just hope that the thread finishes terminating before DllMain returns and the system calls FreeLibrary, but as oldnewthing explains, you can't wait for a thread to terminate inside DllMain. > It might work if you move it to somewhere near ACTION_CallDllFunction, > and wait for the thread to start up, but this remains a hack of course. What would the elegant solution be? > Another blog explains that inheritance of an existing MTA is just a > side effect of starting the custom action in a different process, one > that happens to have initialized an MTA already. Sorry, I'm feeling dense. Which other blog, and what's interesting about that? - Dan
Re: Strange issue with recv in Launchpad Enhanced
On Sun, Jun 21, 2009 at 1:36 AM, Damjan Jovanovic wrote: > On Sun, Jun 21, 2009 at 1:06 AM, Erich Hoover wrote: > > I'm trying to track down an issue with Launchpad Enhanced were it fails > to > > download its updates (Bug #17443). It appears that the issue stems from > > recv being called with a buffer from a different process, so as a result > the > > call fails. I put together a hack that gets around the problem > > (http://bugs.winehq.org/show_bug.cgi?id=17443#c2), but I'm having > difficulty > > figuring out exactly why this is happening in the first place. Does > anyone > > know if this is a known difference between Windows and Linux or if there > is > > something else strange going on? > > If recv() fails with EFAULT, why doesn't the memcpy() in your patch > raise SIGSEGV instead? > While I realize now that I didn't exactly state this, that's why I thought the issue I was encountering was strange. > Maybe the memory is writable but not readable, and > WSARecvFrom()/recv() is reading it while memcpy() is not? > > Maybe the memory is from a DIB section which Wine lazily mprotects and > the kernel isn't raising SIGSEGV for the protection to be reapplied? > Does simply zero-filling buf before calling WSARecvFrom() help? > The memory should be a buffer from the calling application that it is using temporarily to store update data before saving it to the hard-disk. Yes, oddly enough zero-filling the buffer before calling WSARecvFrom() also fixes the problem. So, where exactly should I be looking to find the real problem? As far as I can tell the memory for the buffer is being allocated immediate prior to the call and the request is for read/write access: 0009:Call KERNEL32.VirtualAlloc(01b85000,0004,1000,0004) ret=79e74a2b 0009:Ret KERNEL32.VirtualAlloc() retval=01b85000 ret=79e74a2b 0009:Call ws2_32.recv(0380,01ba4fc1,000178d0,) ret=0036a287 ... Erich Hoover ehoo...@mines.edu
Re: msi: add dummy thread just to initialize an MTA; fixes bug 18070
Hi Dan, > +/* Dummy thread just to initialize an MTA for the benefit of custom action > DLLs */ > +static HANDLE dummy_thread_event = NULL; > +static HANDLE dummy_thread_handle = NULL; > + > +DWORD WINAPI dummy_thread_proc(void *arg) It appears that calling CreateThread in DLL_PROCESS_ATTACH can cause deadlocks: http://blogs.msdn.com/mgrier/archive/2005/06/21/431378.aspx It might work if you move it to somewhere near ACTION_CallDllFunction, and wait for the thread to start up, but this remains a hack of course. Another blog explains that inheritance of an existing MTA is just a side effect of starting the custom action in a different process, one that happens to have initialized an MTA already. -Hans
disabled mail on bouncing bugzilla accounts
Thanks to Jeff Zaroyko, who went through the bounce mail, I just disabled sending bug mail to a few bugzilla accounts. Anyone who is affected by this and has fixed his mail reception can ask an bugzilla admin to enable it again (e.g. by mailing me directly). Jan
Re: Wine translation statistics sources
Alexandre Julliard schrieb: Mikołaj Zalewski writes: It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). It's now online at http://source.winehq.org/transl/ and will be updated every time there's a git push. Please let me know if you find any problems. The source is also available now in the tools.git repository. Nice! I will have a look at the style and the clock-resource bug.
Crash in the mlang test
Hi Ge The mlang tests where reordered and now it crashed on on your Win98 machine with mlang.dll "4.72.3110.0". http://test.winehq.org/data/675e6e93b1d2b4555d05e311764510abf763d21d/98_gvg-w98/mlang:mlang.html Please send me the results for the test with: set WINETEST_REPORT_SUCCESS=1 Thanks -- By by ... Detlef
Re: Wine translation statistics sources
On Mo, 2009-06-08 at 23:24 +0200, Michael Stefaniuc wrote: > >> And we of course need something to cope with the change to the clock > >> resource files as mentioned by Michael Stefaniuc. > >> > > Or we should change our clock resources to fit in the rest of wine? > You mean reverting Alexandre's patch? Doubt it. > > Alexandre and I talked on irc about that. The --verify-translation > functionality needs to move out wrc and into a separate tool that parses > the .res files or the binary. When using the *.rc files, we could add --import and --export for *.po -- By by ... Detlef
Re: W-related helper functions for our tests
On Fr, 2009-06-19 at 12:44 +0200, Paul Vriens wrote: > I was wondering if it would make sense to introduce several helper > functions that could be used by all our tests. > > The main ones needed are the ones to cope with Win9x missing several > W-functions. > > Another one used quite often in the tests is something like wine_dbgstr_w. > > Yet another one compares a W with an A-string. > > Ideas, remarks, suggestions? +1 debugstr_w is used often. With lstrcpyW, the results can be stored in UNICODE without loosing informations (CP_ACP) / without stumble over unsupported Codepages (CP_UTF8) -- By by ... Detlef
Re: Wine translation statistics sources
On Sa, 2009-06-20 at 19:19 +0200, Alexandre Julliard wrote: > Mikołaj Zalewski writes: > > > It's online again. Having it on WineHQ would probably give a better > > uptime > > It's now online at http://source.winehq.org/transl/ and will be updated > every time there's a git push. Please let me know if you find any > problems. T Thanks! The results for Wone 1.0.x ( http://pf128.krakow.sdi.tpnet.pl/wine-transl/ ) won't open (tryied several times yesterday and today) Is is possible to host a copy of the results on winehq.org ( http://source.winehq.org/transl-1.0/ ) to remove the load and bandwidth from Mikołaj's server or remove the Link to the Results from winehq.org? -- By by ... Detlef
Re: Strange issue with recv in Launchpad Enhanced
On Sun, Jun 21, 2009 at 1:06 AM, Erich Hoover wrote: > I'm trying to track down an issue with Launchpad Enhanced were it fails to > download its updates (Bug #17443). It appears that the issue stems from > recv being called with a buffer from a different process, so as a result the > call fails. I put together a hack that gets around the problem > (http://bugs.winehq.org/show_bug.cgi?id=17443#c2), but I'm having difficulty > figuring out exactly why this is happening in the first place. Does anyone > know if this is a known difference between Windows and Linux or if there is > something else strange going on? If recv() fails with EFAULT, why doesn't the memcpy() in your patch raise SIGSEGV instead? Maybe the memory is writable but not readable, and WSARecvFrom()/recv() is reading it while memcpy() is not? Maybe the memory is from a DIB section which Wine lazily mprotects and the kernel isn't raising SIGSEGV for the protection to be reapplied? Does simply zero-filling buf before calling WSARecvFrom() help? > Erich Hoover > ehoo...@mines.edu > > > > Damjan Jovanovic
