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

Re: 1.0 idea - ntdll - add a messagebox for missing dlls

by Steven Edwards

On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards <winehacker(a)gmail.com> wrote: > On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel <dank(a)kegel.com> wrote: > > 2. You never clear that environment variable... what happens > > when an app just tests for the existence of a DLL by > > trying to load it? We don't want to print an error then. > > (That's why I originally suggested clearing the env var > > after the app finished loading. That's still broken -- it > > won't catch errors in helper exes -- but it's better than nothing.) > > I assume you mean if the application is just checking manually for the > dll via GetModuleHandle or LoadLibrary? I'll write a test case for > this to see if it causes a problem. My assumption was that the failure > case for that was at a higher level but I'll check with a test case. I > don't think we need to clear the variable....what I mean is I wonder > if there is a way to set the variable to be inherited by all child > processes launched by start.exe.so in unix mode. I'll look in to this > as well. I assumed the code path must be different so I wrote a test app that tried to do a GetProcAddress or LoadLibrary on a non-existent dll and was right, It did not throw the messagebox. So that just leaves the issue of do we want to clear the environment for the child process. My thinking is no, because I assume most applications that invoke other applications via CreateProcess inherit the environment of the parent just like apps started from start.exe.CreateProcess do. It would not really make since for a vendor to have an application foo.exe that calls bar.exe to be randomly setting and unsetting variables in the package so I assume then we want the verbose variable to remain resident for all child processes started by start.exe in case foo.exe calls bar.exe which is linked to a missing dll so the user will get a warning rather than just failing silently. Unless you can point me to a case otherwise I think that it is correct behavior. IMHO if we can extend this patch a bit to return more information via the message box such as the name of the missing dll and also address the case of dlls that are there but with missing exports, then this should go in before the freeze so we have time to shake it down. If worse comes to worse we can revert it. I think the behavior as it stands with this patch is better than a user clicking on a menu or *.exe from KDE/GNOME and nothing happening at all. Thanks Steven -- 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

April 29, 2008

Re: 3/2 WineD3D: add D3DPRASTERCAPS_MULTISAMPLE_TOGGLE support

by Stefan Dösinger

Am Montag, 28. April 2008 22:08:28 schrieb Roderick Colenbrander: > Hi, > > Add a missing d3d9 capability. For now add it behind a dxVersion check. We > should get rid of those after Wine 1.0 but right now there is no filtering > code in d3d8, so don't risk any regressions now. IMHO adding a caps filter to dx8 is less risky than adding multisampling support, so I don't see a reason not to do that and avoid the dxVersion check

April 28, 2008

Re: Mixed-mode assembly support in Mono

by Kornél Pál

> From: Dan Kegel >> I have recently committed required changes to Mono SVN repository as >> r102052. >> Now Mono has mixed-mode assembly support on Windows. > > Wow, congratulations! When will a windows installer be available > for a version of mono with your changes included? It would make > testing much easier. Unfortunately installers are only built for releases. But you can install the latest version and just build and replace mono.exe, mono.dll, and mscorlib.dll (1.0 and 2.0) from SVN trunk. If you need I can send a compiled version to the list. > We'll have a look, thanks. Do you happen to know of any > real-world apps that would benefit? To be honest I don't really know how many real world Windows applications use .NET because thay apper to have .NET components without any notification. Kornél

April 28, 2008

Re: widl: Add a framework for automated testing of IDL files that should succeed or fail to be parsed.

by Dan Hipschman

On Mon, Apr 28, 2008 at 08:37:26PM +0100, Robert Shearman wrote: > > This should aid in testing more-obscure parts of the parser that aren't > necessarily valid when using RPC (and hence don't make sense being put > in dlls/rpcrt4/tests/server.idl). Obviously this is a good idea. I tried doing something similar a while ago, but it didn't get accepted on the first try and I never asked why, so I'll ask why now. See here: http://winehq.org/pipermail/wine-patches/2006-September/030438.html It has some benefits over the approach you're proposing so it's worth bringing up. One is that it can run the tests against MIDL, so we know the tests themselves are correct (ok, MIDL has been known to do things differently than the spec, but we may want to copy MIDL's behaviour anyway, and in any case it's easier to automatically validate the tests on MIDL than to do so by hand or by inspection). Another is versatility in what it can test. Since the tests are shell scripts, not only can it test the success/failure of a parse, but it can check that all the correct files were created, and it can perform further tests on the output (e.g., if we have an import in the IDL file, we can grep the output to make sure a #include was generated for the import). It already supports "todo"s, and the test scripts look similar to the usual Wine tests written in C. On the other hand your method has some advantages over mine. You already provide a "make test" framework, and including the expected result of the compilation in the IDL file is cleaner. Alexandre may very well disagree with what I see as valid points (like testing on MIDL), but these are my suggestions anyway. Hope they're useful.

April 28, 2008

re: Mixed-mode assembly support in Mono

by Dan Kegel

Kornel wrote: > I have recently committed required changes to Mono SVN repository as r102052. > Now Mono has mixed-mode assembly support on Windows. Wow, congratulations! When will a windows installer be available for a version of mono with your changes included? It would make testing much easier. > These is no full MSVCRT support because that heavily depends > on the unmanaged API of .NET Framework but programs compiled using > Microsoft Visual C++ and not using MSVCRT should > be supported. Even exporting functions in managed DLLs is supported > that is supported by ildasm.exe and ilasm.exe as well. > > When the process is created using mono.exe there are some > limitations for executable assemblies but with a custom mscoree.dll > Mono has full support to create processes from managed executables. > > The attached mscoree.c is the source code for a custom mscoree.dll > that uses Mono for creating processes from executables. > I think that you should incorporate this into your mscoree.dll. We'll have a look, thanks. Do you happen to know of any real-world apps that would benefit? - Dan

April 28, 2008

Bad recommended package lists

by Francois Gouget

http://wiki.winehq.org/Recommended_Packages The Wiki's Recommended Packages list contains a lot of incorrect recommendations. I have already cleaned up the Debian section, but there seems to be a lot of copy/paste that spread the bad information to the RPM distros. So we'd need volunteers for pruning and updating these lists for Fedora and RHEL / WBEL. Here's a list of the suspicious or downright bad package recommendations I spotted: * audiofile-devel This is a library for accessing audio files. Wine does not use it. Maybe it was confused with AudioIO (which is not used on Linux anyway). * e2fsprogs-devel Why would Wine need ext2fs tools? * expat-devel We use libxml2, not expat. * glib2-devel That's not the glibc. That's a Gnome library which Wine never used. * isdn4k-utils-devel Maybe this is for libcapi20? * krb5-devel As far as I know we don't use Kerberos in Wine (or it's experimental code that is not enabled in the mainline). * libao-devel Wine does not use libao. Instead it has backends for most of the audio systems out there, although there's always a new kid on the block that's missing. * libmng-devel That's for MNG files, the moving version of PNG files. But what we use is libpng, not libmng. * libusb-devel Wine did use libusb at one point but now it's using libhal. * libogg-devel * libvorbis-devel We don't use those. * libxml, libxml-devel We use libxml2, not the deprecated libxml1. Now, maybe some distributions use 'libxml-devel' as the package name for libxml2 but this should be clarified, especially since libxml2-devel is mentionned too. * qt-devel That's QT, the toolkit used by KDE. Wine has never used it. * libXxf86dga-devel As far as I can tell we don't use libXxf86dga anymore. * opencdk-devel, libgpg-error-devel, libgcrypt-devel These are all related to GPG. We have nothing to do with GPG so we don't need them. * libXft-devel Wine uses FreeType and fontconfig but not libXft as far as I know. * gnutls-devel I believe we used GNU TLS at some point but now we use OpenSSL. * cyrus-sasl-devel Cyrus SASL also has to do with cryptography but as far as I can tell we never used it. * libieee1284-devel For parallel port access. Not used as far as I can tell. * libXmu-devel Contains 'miscellaneous utility convenience functions for X libraries to use'. I don't think Wine uses it. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

April 28, 2008

Mixed-mode assembly support in Mono

by Kornél Pál

Hi, I have recently committed required changes to Mono SVN repository as r102052. Now Mono has mixed-mode assembly support on Windows. These is no full MSVCRT support because that heavily depends on the unmanaged API of .NET Framework but programs compiled using Microsoft Visual C++ and not using MSVCRT should be supported. Even exporting functions in managed DLLs is supported that is supported by ildasm.exe and ilasm.exe as well. When the process is created using mono.exe there are some limitations for executable assemblies but with a custom mscoree.dll Mono has full support to create processes from managed executables. The attached mscoree.c is the source code for a custom mscoree.dll that uses Mono for creating processes from executables. I think that you should incorporate this into your mscoree.dll. Also note that you should only provide not implemented stubs in your mscoree.dll and implement missing functionality in Mono's coree.c if required. mscoree.c and http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metadata/coree.c contains some comments about managed module support in ntdll.dll and msvcrt.dll of XP and later. If someone volunteers this could be implemented in Wine as well. Kornél

April 28, 2008

Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: >> That's actually easy to implement, but the problem is that there is >> no free space in the Graphics tab of winecfg to add a preview control. >> That needs some redesigning work, I'll see how that could be done. > > All would be well if "Screen Resolution" had its own tab, perhaps. Alexandre suggested to get rid of all the text comments on that page, I'll go that route. -- Dmitry.

April 28, 2008

Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.

by Dan Kegel

Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > That's actually easy to implement, but the problem is that there is > no free space in the Graphics tab of winecfg to add a preview control. > That needs some redesigning work, I'll see how that could be done. All would be well if "Screen Resolution" had its own tab, perhaps.

April 28, 2008

Re: ws2_32: Use WSAWaitForMultipleEvents instead ofWaitForSingleObject

by Dmitry Timoshkov

"Kai Blin" <kai.blin(a)gmail.com> wrote: > > > - HANDLE hEvent = INVALID_HANDLE_VALUE; > > > + WSAEVENT event_array[1]; > > > > Is that change only to avoid passing &hEvent to WSAWaitForMultipleEvents? > > Nope. WSAWaitForMultipleEvents expects an array of WSAEVENTs. So this seemed > like the cleaner approach to do this. That's exactly what I pointed out above. In C both ways is an equivalent. -- Dmitry.

April 28, 2008