November 2007 - Wine-Devel - list.winehq.org

Re: Removing Windows and Solaris from the Downloads page

by Juan Lang

Hi Steven, > The problem is not in the makefiles, a lot of the problem is that we > are not clear on which dlls would be of use for testing in windows. I > had to go through hoops to get wininet buildable on Windows because it > uses unix sockets on Wine rather than winsock. There was quite a > performance issue when running under Wine with winsock that did not > show up when using Unix sockets and I felt, and still do that hacking > around the problem rather than finding where the bottleneck was, is > not the right answer. The problem with using winsock rather than UNIX sockets is in the I/O between a client process and the wineserver. The extra overhead it imposes is really unavoidable, AFAICT. We're doing a context switch to a separate process that a UNIX socket call (or a winsock call on Windows) does not require. While we could speed up such I/O in certain cases with hacks like the shared memory wineserver, or with a wineserver kernel module, doing so is very error prone, and we'd lose a lot of time chasing down errors that's better spent improving our implementation of Windows dlls. It may not be the "right" thing to do in a purely abstract sense, but it's clearly the right thing given our resources and our priorities. If wineserver performance is ever the thing preventing a large number of apps from working correctly, we might invest more time in it. Switching wininet to winsock might make sense then, but not before. > Mingw/MSVC and friends will always be second class citzen to Wine on Unix. It's true, for several reasons: 1. We don't use MSVC to develop Wine (nor should we) so we don't catch errors there as quickly. 2. MinGW's headers aren't in synch with ours, so building with it is for the very patient. I'm happy someone does it, but we can't all do it without losing a lot of time. 3. We don't use MinGW in compile Wine, nor, again, should we. --Juan

Nov. 19, 2007

Re: Removing Windows and Solaris from the Downloads page

by Steven Edwards

On Nov 17, 2007 6:04 AM, Maarten Lankhorst <maarten(a)codeweavers.com> wrote: > The question is what dlls should we include? Something like the d3d > dll's would be useful, and a lot of other dll's (mshtml, shdocvw, etc) > probably too. Unfortunately wine won't build on mingw properly,if you > try a 'make' in mingw, it will bomb out on building in dll's. If someone > wants to maintain windows dll's, the makefiles should be adjusted so > that it will build properly, and skip the dll's wine can't emulate in > windows. Such as ntdll, kernel32, advapi, to name a few, probably all > dll's with wineserver calls and perhaps a few more. And all of the dlls that make unix functional calls that don't exist on windows. I seem to recall us having a discussion about a certain WinMM patch... The problem is not in the makefiles, a lot of the problem is that we are not clear on which dlls would be of use for testing in windows. I had to go through hoops to get wininet buildable on Windows because it uses unix sockets on Wine rather than winsock. There was quite a performance issue when running under Wine with winsock that did not show up when using Unix sockets and I felt, and still do that hacking around the problem rather than finding where the bottleneck was, is not the right answer. That was my point in the winmm patch we discussed also, if there is a bottleneck in wineserver or somewhere, hacking around window portability for performance gain seems to just be hiding the problems. I don't have a solution that will always work mind you, I am just venting. Mingw/MSVC and friends will always be second class citzen to Wine on Unix. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Nov. 18, 2007

Re: Wine and LD_PRELOAD

by Lionel Tricon

On Sunday 18 November 2007 20:14:41 Stefan Dösinger wrote: > I think wine dlopen()s many libraries instead of linking dynamically to > them. This makes the build environment more independent of the runtime > environment, and we can provide binary builds with all features enabled, > and they will still run if the user's system does not have all the libs. Hi Stefan, Thanks for your reply. > We had an issue like that with libGL.so a long time back, and it was fixed > by changing some parameter to dlopen. Does anyone remember what that was, > and if this can be done for the other libraries too? > > Lionel, can you provide us with a list of libraries where LD_PRELOAD does > not work correctly? This should help to track down the bad ldopen calls. In fact, we overload a lot of common system call from the standard libc. We have slightly modified the fackechroot library and we need to trap almost all system calls linked to the filesystem. To give you an idea, all the following system calls are reimplemented so that we can put the software into a jail (in most of them, we only change the local path before calling the real one). As far as i understand the problem (and with the help of strace), it appears that the wine application ignore the LD_PRELOAD env var (LD_PRELOAD instructs the loader to load additional libraries into a program). I suppose that wine use its own internal mechanisme which is not compatible with the LD_PRELOAD one. So, if you have some ideas ... __lxstat __lxstat64 __open __open64 __opendir2 __xmknod __lxstat __lxstat64 __open __open64 __opendir2 __xmknod __xstat __xstat64 _xftw _xftw64 access acct canonicalize_file_name chdir chmod chown chroot creat creat64 dlmopen dlopen euidaccess execl __xstat __xstat64 _xftw _xftw64 access acct canonicalize_file_name chdir chmod chown chroot creat creat64 dlmopen dlopen euidaccess execve execvp fopen fopen64 freopen freopen64 fts_open ftw ftw64 get_current_dir_name getcwd getwd getxattr glob glob64 glob_pattern_p lchmod lchown lgetxattr link listxattr llistxattr lremovexattr lsetxattr lstat lstat64 lutimes mkdir mkdtemp mknod mkfifo mkstemp mkstemp64 mktemp nftw nftw64 open open64 opendir pathconf readlink realpath remove removexattr rename revoke rmdir scandir scandir64 setxattr stat stat64 symlink tempnam tmpnam truncate truncate64 unlink utime utimes

Nov. 18, 2007

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW

by Hans Leidekker

On Sunday 18 November 2007 22:14:17 devzero(a)web.de wrote: > latest version i tried here is > > wine-0.9.49-11.3.i586.rpm > wine-snapshot-0.9.49.20071118-11.1.i586.rpm > > but same error. > maybe that`s not recent enough ? > > do i need to enable special option or add some files ? You can either download, patch and compile wine yourself or wait for Wine 0.9.50 to be released, which should happen within one to two weeks. -Hans

Nov. 18, 2007

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW

by devzero＠web.de

Hello Hans, thanks for that info. latest version i tried here is wine-0.9.49-11.3.i586.rpm wine-snapshot-0.9.49.20071118-11.1.i586.rpm but same error. maybe that`s not recent enough ? do i need to enable special option or add some files ? sorry, i`m quite new to wine and maybe i should read deeper into the docs instead of posting :) regards roland > -----Ursprüngliche Nachricht----- > Von: "Hans Leidekker" <hans(a)it.vu.nl> > Gesendet: 18.11.07 21:45:34 > An: wine-devel(a)winehq.org > Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW > > On Sunday 18 November 2007 20:38:34 devzero(a)web.de wrote: > > > i`m new to wine. > > I tried windirstat under wine-0.9.44-15 and crossover-office 6.2.0-1 under opensuse10.3 - but it doesn`t work. > > > > i`m getting > > wine: Call from 0x7b8447d0 to unimplemented function KERNEL32.dll.FindFirstVolumeW, aborting > > wine: Unimplemented function KERNEL32.dll.FindFirstVolumeW called at address 0x7b8447d0 (thread 0019), starting debugger... > > Unhandled exception: unimplemented function KERNEL32.dll.FindFirstVolumeW called in 32-bit code (0x7b844852). > > I submitted a stub implementation for this function which makes > windirstat start up fine here. > > -Hans > ______________________________________________________________________________ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134

Nov. 18, 2007

Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW

by Hans Leidekker

On Sunday 18 November 2007 20:38:34 devzero(a)web.de wrote: > i`m new to wine. > I tried windirstat under wine-0.9.44-15 and crossover-office 6.2.0-1 under opensuse10.3 - but it doesn`t work. > > i`m getting > wine: Call from 0x7b8447d0 to unimplemented function KERNEL32.dll.FindFirstVolumeW, aborting > wine: Unimplemented function KERNEL32.dll.FindFirstVolumeW called at address 0x7b8447d0 (thread 0019), starting debugger... > Unhandled exception: unimplemented function KERNEL32.dll.FindFirstVolumeW called in 32-bit code (0x7b844852). I submitted a stub implementation for this function which makes windirstat start up fine here. -Hans

Nov. 18, 2007

Unimplemented function KERNEL32.dll.FindFirstVolumeW

by devzero＠web.de

Hello ! i`m new to wine. I tried windirstat under wine-0.9.44-15 and crossover-office 6.2.0-1 under opensuse10.3 - but it doesn`t work. i`m getting wine: Call from 0x7b8447d0 to unimplemented function KERNEL32.dll.FindFirstVolumeW, aborting wine: Unimplemented function KERNEL32.dll.FindFirstVolumeW called at address 0x7b8447d0 (thread 0019), starting debugger... Unhandled exception: unimplemented function KERNEL32.dll.FindFirstVolumeW called in 32-bit code (0x7b844852). does somebody know when this function will be available ? is this a rarely used function? http://msdn2.microsoft.com/en-us/library/aa364425.aspx tells "Retrieves the name of a volume on a computer. FindFirstVolume is used to begin scanning the volumes of a computer." regards roland _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

Nov. 18, 2007

Re: advapi32/service.c -- remove untriggerable check

by Robert Shearman

Dan Kegel wrote: > Uwe wrote: > >> Gerald Pfeifer writes: >> >> >>> n is of type DWORD which is unsigned, so n < 0 always will >>> evaluate to false. >>> >> Is dropping the check the right answer? Shouldn't the check test for high >> values like > 0xff00 and report a possible problem? >> > > Indeed. > IMHO we don't need patches like this, and Gerald > is not thinking hard enough. Simplistic just-remove-the-warning > patches are a Bad Thing, and we Don't Want To Encourage Them. > Please stop. Arguably, the check shouldn't be there anyway. Either the code always calculates the buffer size required correctly or it doesn't. As Gerald has pointed out, the extra check doesn't actually trigger so it is useless and makes people have a false sense of security in the code. I'm not a big fan of turning on obscure warnings in gcc, but it has uncovered some real bugs and Gerald has argued before that uncovering real bugs is easier when there are less harmless warnings to sift through. Obviously, if the code becomes less readable through this process or it introduces bugs then this is not desirable, but that isn't the case with this patch. -- Rob Shearman

Nov. 18, 2007

Re: Wine and LD_PRELOAD

by Stefan Dösinger

Am Sonntag, 18. November 2007 17:13:20 schrieb Lionel Tricon: > Hi wine list, > > I am currently working for the next generation of the klik project (1 > application = 1 file) and we actualy face some troubles with picasa which > is running under linux thanks to wine. > > It seems that wine deal badly with the LD_PRELOAD feature which is one of > the main composant we use to virtualize and execute the application (with > fuse for the underlying filesystem). > > Is there a way to force wine to go through LD_PRELOAD (to overload some > system calls) ? or this limitation is driven by the architecture ? I think wine dlopen()s many libraries instead of linking dynamically to them. This makes the build environment more independent of the runtime environment, and we can provide binary builds with all features enabled, and they will still run if the user's system does not have all the libs. We had an issue like that with libGL.so a long time back, and it was fixed by changing some parameter to dlopen. Does anyone remember what that was, and if this can be done for the other libraries too? Lionel, can you provide us with a list of libraries where LD_PRELOAD does not work correctly? This should help to track down the bad ldopen calls.

Nov. 18, 2007

Re: gdi32: Add stub for RemoveFontMemResourceEx

by Klaus Layer

Am Sonntag, 18. November 2007 14:15:23 schrieb Dmitry Timoshkov: > You forgot to create WineEngRemoveFontMemResourceEx implementation for > a case when HAVE_FREETYPE is not defined. > > -- > Dmitry. > Dimitry, thanks for reviewing the patch. I just resent the patch together with the missing implementation. Best regards, Klaus

Nov. 18, 2007