Re: svchost: Added base implementation of svchost (1/27)
Roy Shea wrote: +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR= @srcdir@ +VPATH = @srcdir@ +MODULE= svchost.exe +APPMODE = -municode +IMPORTS = advapi32 kernel32 ole32 I can't see any reason why svchost needs to import ole32. -- Rob Shearman
Re: Removing Windows and Solaris from the Downloads page
On Saturday 17 November 2007 12:04:36 Maarten Lankhorst wrote: Roderick Colenbrander schreef: They should get updated. In case of Solaris there are some bugs which prevent it from running I think. In case of Windows someone needs to update the package. It is very useful to use some of the wine dlls (wined3d for instance) or tests on Windows. 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. That sounds promising. I should be able to tweak the winetest.exe build infrastructure so it also build DLLs and executables without too much trouble. Having a target that skips attempting to build DLLs that will never work would help. Cheers, Paul.
Re: gdi32: Add stub for RemoveFontMemResourceEx
Klaus Layer [EMAIL PROTECTED] wrote: Nokia PC Suite installation crashes due to missing function RemoveFontMemResourceEx. This patch adds function RemoveFontMemResourceEx which just calls WineEngRemoveFontMemResourceEx as stub You forgot to create WineEngRemoveFontMemResourceEx implementation for a case when HAVE_FREETYPE is not defined. -- Dmitry.
Re: bits: Added framework for testing the BackgroundCopyJob interface (25/27)
On Fr, 2007-11-16 at 16:21 -0800, Roy Shea wrote:
+/* Generic test setup */
+static BOOL setup(void)
unused code
+/* Generic test cleanup */
+static void teardown(void)
unused code
+START_TEST(job)
+{
+CoInitialize(NULL);
+CoUninitialize();
+}
Do you want to call setup() and teardown() here?
--
By by ... Detlef
Re: bits: INF and resource file for qmgr registration (8/27)
On Fr, 2007-11-16 at 16:16 -0800, Roy Shea wrote: dlls/qmgr/qmgr.inf | 32 dlls/qmgr/rsrc.rc | 21 + 2 files changed, 53 insertions(+), 0 deletions(-) The change for Makefile.in to add rsrc.rc is missing here. (found in the next patch) -- By by ... Detlef
Re: Valgrind results for Nov 12 13
Dan Kegel wrote: Oh, he'd undoubtedly prefer ignoring to memsetting. I believe the official answer is to teach valgrind which fields are important for which server request. Granted, it a lot more work, but it's the only way we will actually catch errors :-) Shachar
Re: advapi32/service.c -- remove untriggerable check
Gerald == Gerald Pfeifer [EMAIL PROTECTED] writes: Gerald n is of type DWORD which is unsigned, so n 0 always will Gerald evaluate to false. Gerald Gerald Gerald ChangeLog: Remove untriggerable check. Gerald Index: dlls/advapi32/service.c Gerald === Gerald RCS file: /home/wine/wine/dlls/advapi32/service.c,v retrieving Gerald revision 1.160 diff -u -3 -p -r1.160 service.c --- Gerald dlls/advapi32/service.c 15 Oct 2007 16:29:59 - 1.160 +++ Gerald dlls/advapi32/service.c 18 Nov 2007 06:01:28 - @@ -2107,9 Gerald +2107,6 @@ QueryServiceConfigW( SC_HANDLE hService, n -= Gerald sizeof(WCHAR); } Gerald - if( n 0 ) - ERR(Buffer overflow!\n); - TRACE(Image path = Gerald %s\n, debugstr_w(lpServiceConfig-lpBinaryPathName) ); Gerald TRACE(Group = %s\n, Gerald debugstr_w(lpServiceConfig-lpLoadOrderGroup) ); Gerald TRACE(Dependencies = %s\n, Gerald debugstr_w(lpServiceConfig-lpDependencies) ); Is dropping the check the right answer? Shouldn't the check test for high values like 0xff00 and report a possible problem? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
re: advapi32/service.c -- remove untriggerable check
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. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: gdi32: Add stub for RemoveFontMemResourceEx
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
Wine and LD_PRELOAD
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 ? Thanks in advance, Lionel Tricon
Re: advapi32/service.c -- remove untriggerable check
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
Re: Wine and LD_PRELOAD
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. signature.asc Description: This is a digitally signed message part.
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
On Sunday 18 November 2007 20:38:34 [EMAIL PROTECTED] 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
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
On Sunday 18 November 2007 22:14:17 [EMAIL PROTECTED] 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
Re: Removing Windows and Solaris from the Downloads page
On Nov 17, 2007 6:04 AM, Maarten Lankhorst [EMAIL PROTECTED] 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
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
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 [EMAIL PROTECTED] Gesendet: 18.11.07 21:45:34 An: wine-devel@winehq.org Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW On Sunday 18 November 2007 20:38:34 [EMAIL PROTECTED] 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
Re: Wine and LD_PRELOAD
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
Re: Removing Windows and Solaris from the Downloads page
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
Re: msi: Install Entire Feature
On 11/18/07, Daniel Sim [EMAIL PROTECTED] wrote:
Install entire feature enabled and implemented.
What is this patch for? Is this to fix a bug?
+/* FIXME: Why 0x1000? */
Don't add random comments about things you don't understand in the code.
+msi_seltree_install_entire_feature(HWND hwnd, HTREEITEM hItem,
MSIPACKAGE *package, UINT r) {
Please use the style of the rest of the file (bracket below function).
+for (
+child = TreeView_GetChild (hwnd, hItem);
+child;
+child = TreeView_GetNextSibling (hwnd, child) )
Style changed again...and that's just ugly.
+msi_seltree_install_entire_feature (hwnd, child, package, r);
Why are you doing this recursively?
--
James Hawkins
Re: Removing Windows and Solaris from the Downloads page
Hi, On Nov 18, 2007 8:03 PM, Juan Lang [EMAIL PROTECTED] wrote: 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. I understand that, I'm just not being very pragmatic today. 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. The headers are not an issue because we use the Wine headers and import libraries for the dlls. The only place there is a problem is with wine/programs and the regression tests. They use the native import libraries. I don't really understand Alexandre's reasoning on this as myself and Dmitry have both sent patches in to correct this issue and his answer has always been that we should fix mingw w32api. Wine always tends to break when cross-compiling because of this. If we always defaulted to using the Wine headers and Import libs there never would be a problem in that regards. /rant off. I understand the reasoning behind it breaking and just needed to vent about it because sometimes going back over old problems, presents new solutions. Thanks -- 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
Re: Wine and LD_PRELOAD
On Nov 19, 2007 12:48 AM, Lionel Tricon [EMAIL PROTECTED] wrote: 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. LD_PRELOAD will just affect the wine loader, I don't think wineserver is affected. Try this instead: wineserver -k export LD_PRELOAD=... wine ... Also, IIRC, wine already looks for libraries in ../lib/wine relative to the directory which contains the wine executable. If I'm right, then there is no need to deprefix it further with LD_PRELOAD hacks. Damjan
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
On Sun, Nov 18, 2007 at 10:14:17PM +0100, [EMAIL PROTECTED] wrote: 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 :) It is not yet committed to the mainline repository. Once it is it will show up in wine-snapshot of the openSUSE buildservice of this day. Ciao, Marcus
Re: recent cedega contributions to wine
Am Montag, 19. November 2007 08:13:49 schrieb EA Durbin: http://www.cedega.com./devreports/ The latest Cedega dev report states it plans to include wine's msi implementation back into it's code base and they have been contributing back to wine. TransGaming's developers have been contributing some changes back to Wine as well, including in several networking and debugging libraries. Just out of curiousity, which patches are these? A wine-patches archive search finds these: http://article.gmane.org/gmane.comp.emulators.wine.patches/32979 http://article.gmane.org/gmane.comp.emulators.wine.patches/32981 http://article.gmane.org/gmane.comp.emulators.wine.patches/32982 http://article.gmane.org/gmane.comp.emulators.wine.patches/39016 http://article.gmane.org/gmane.comp.emulators.wine.patches/39017 http://article.gmane.org/gmane.comp.emulators.wine.patches/33632 http://article.gmane.org/gmane.comp.emulators.wine.patches/33633 signature.asc Description: This is a digitally signed message part.
