October 2010 - Wine-Devel - list.winehq.org

Re: loader: On Mac, reserve the process's original thread for the frameworks.
by Ken Thomases Oct. 28, 2010

Oct. 28, 2010

On Oct 27, 2010, at 5:36 PM, Ken Thomases wrote: > > The frameworks expect the original thread to run its run loop, so input > sources (like distributed notifications) get processed. For example, > Core Audio on Snow Leopard doesn't track changes in the default ouput > device, such as when headphones are plugged in, without this. > --- > libs/wine/Makefile.in | 2 +- > libs/wine/loader.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 115 insertions(+), 1 deletions(-) > > > <0001-loader-On-Mac-reserve-the-process-s-original-thread-.patch> Hold off on this one. I've encountered a strange issue after sending it (that I didn't encounter in earlier testing). err:process:start_wineboot failed to start wineboot, err 1359 Apparently, there's a failure of an execve() system call in a child process. It's getting EFAULT. Artificially avoiding the very top of the available address space for the secondary thread stack works around the problem. Either the fork() alters the address space (perhaps as a consequence of eliminating all but one thread when creating the child from the parent), or execve() is sensitive to the specific layout. Perhaps it needs to use the very top of the address space, but won't if it thinks that's where the thread's stack is. Or something. -Ken

2 1

Re: About the Gallium Direct3D 10/11 work
by abraham vargas moreno Oct. 28, 2010

Oct. 28, 2010

galllund3 how long it takes to have dx 10 and 11 and ubuntu natively, all the world want to have a minimum release date for this wonderful work they are dealing with the DX.

1 0

Re: [PATCH 3/3] kernel32/tests: Add a test for opening short paths of differing case.
by Vitaliy Margolen Oct. 27, 2010

Oct. 27, 2010

On 10/27/2010 07:46 PM, Charles Davis wrote: > + sprintf(buf,"%s\\%s\\%s",tmpdir,dirname,filename); Could you please put some spaces after each coma everywhere in your patch? Please use snprintf(). > + GetShortPathNameA(buf,shortbuf,MAX_PATH); Use sizeof(buf) instead of MAX_PATH to guarantee that's what it means. > + hndl = CreateFileA(shortbuf,GENERIC_READ|GENERIC_WRITE,0,NULL,OPEN_EXISTING,0,NULL); > + ok(hndl!=INVALID_HANDLE_VALUE,"CreateFileA failed\n"); It's nice to know LastError and the full filename if it fails. > + for(i=0;i<MAX_PATH&& shortbuf[i];i++) You getting past the filename size in the buffer. > + shortbuf[i]=(rand() % 2) ? tolower(shortbuf[i]) : toupper(shortbuf[i]); Please don't use any sort of random stuff in tests. They should always be the same every time on every platform. > + /* Now try it on mixed case short names */ What's the point of the test anyway? You know that Wine already handles all files as case-insensitive. Short file name isn't any different. Vitaliy.

2 2

Re: [PATCH 1/3] configure: Check for the getattrlist() function and the <sys/attr.h> header (resend).
by Vitaliy Margolen Oct. 27, 2010

Oct. 27, 2010

On 10/27/2010 07:46 PM, Charles Davis wrote: > --- a/configure > +++ b/configure Please exclude changes to configure from your patches. AJ regenerates it himself. > @@ -1866,6 +1867,7 @@ AC_CHECK_FUNCS(\ > ftruncate \ > futimes \ > futimesat \ > + getattrlist \ > getdirentries \ > getopt_long \ > getpagesize \ Incorrect indentation - should be a tab, not 4 spaces. Vitaliy.

1 0

Re: [PATCH 3/3] kernel32/tests: Add a test for opening short paths of differing case.
by testbot＠testbot.winehq.org Oct. 27, 2010

Oct. 27, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6562 Your paranoid android. === WINEBUILD (build) === Failure running script in VM: Exceeded timeout limit of 300 sec

2 1

RE: [1/3] mscoree: Add tests for LoadLibraryShim.
by Vincent Povirk Oct. 27, 2010

Oct. 27, 2010

Well, in practice, it's a detail that I don't expect to be very important, so it's probably not worth the trouble. Mostly I just want to elminiate the call fusion makes back into mscoree, since it is so blatantly wrong and causes the change I really want to break the tests. We could probably even get away with a hard-coded path, since our ngen.exe doesn't work anyway, and that's essentially what we're doing now given the semi-stub status of GetCORVersion. If/when we need to use the CLR version in fusion for something other than finding the precompiled assembly cache, this may become more important, but even then I don't think we'll need multiple simultaneous instances to work properly. We'll just need to know the correct version to use when only one instance is loaded. Multiple simultaneous runtimes is a case I'm thinking about and trying to account for, but I don't expect to ever see it used. If you prefer, I can add a test for fusion instead that compares the version we get out of GetCachePath(ASM_CACHE_ZAP) to the one we pass to LoadLibraryShim, in cases where more than one runtime is installed, assuming only one instance will be loaded at once. I can fix that without any changes to the loader, but it will mean adding a wine-specific export to fusion. OR mscoree could lie about which .NET versions are installed when Mono isn't available, until there's a real need to load Mono. -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Wednesday, October 27, 2010 2:15 PM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: [1/3] mscoree: Add tests for LoadLibraryShim. "Vincent Povirk" <vincent(a)codeweavers.com> writes: > There is another minor problem highlighted by this test, which is that > I can make up any path and end up with a loaded dll, as long as > there's a builtin dll filename at the end. That's a feature, the idea is that builtin dlls are independent from the actual dll files. That's also why asking for the path name of a builtin doesn't make sense. This could conceivably be changed now that we have the fake dlls mechanism, but it would be a pretty fundamental redesign. -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: [1/3] mscoree: Add tests for LoadLibraryShim.
by Vincent Povirk Oct. 27, 2010

Oct. 27, 2010

Well, I don't think we can do it properly without having multiple instances of a builtin dll. I believe that native fusion.dll is different for each .NET version, and it probably has the version number baked in. If we can't have multiple instances of a builtin dll, I still believe testing the path is the best way to determine which version was given to LoadLibraryShim, if that's possible. If testing the path is not possible, we can have LoadLibraryShim use a wine-specific exported function to inform fusion.dll of the version, but this approach won't work if someone loads fusion.dll directly from a .NET system directory. There is another minor problem highlighted by this test, which is that I can make up any path and end up with a loaded dll, as long as there's a builtin dll filename at the end. -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Wednesday, October 27, 2010 1:31 PM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: [1/3] mscoree: Add tests for LoadLibraryShim. "Vincent Povirk" <vincent(a)codeweavers.com> writes: > This is needed so that fusion.dll can find out which .NET version it's > expected to use without loading mscoree.dll. Native has the capability > of loading multiple .NET versions in a single process, so the current > approach is unworkable. Testing the filename doesn't seem much more workable, you can't load multiple instances of a builtin dll anyway. How are you planning to handle this? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/3] mscoree: Add tests for LoadLibraryShim.
by Alexandre Julliard Oct. 27, 2010

Oct. 27, 2010

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > This is needed so that fusion.dll can find out which .NET version it's > expected to use without loading mscoree.dll. Native has the capability > of loading multiple .NET versions in a single process, so the current > approach is unworkable. Testing the filename doesn't seem much more workable, you can't load multiple instances of a builtin dll anyway. How are you planning to handle this? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 4)
by Alexandre Julliard Oct. 27, 2010

Oct. 27, 2010

Charles Davis <cdavis(a)mymail.mines.edu> writes: > If the volume is indeed case insensitive, we skip searching through the > whole directory ourselves, and just stat() each portion of the path. You still have extra stat() calls in the fast path, as well as some unnecessary changes. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [3/3] mscoree: Implement LoadLibraryShim.
by testbot＠testbot.winehq.org Oct. 27, 2010

Oct. 27, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6541 Your paranoid android. === W2K3R2SESP2 (32 bit mscoree) === mscoree.c:176: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === WVISTAADM (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W2K8SE (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W7PRO (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (64 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL"

1 0