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

Ubuntu starting to support windows autorun.inf on cd-rom insertion!
by Dan Kegel July 4, 2007

July 4, 2007

Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.p… Are we ready for prime time, kids? :-)

5 7

How to make your machine crash when running Wine
by gslink July 3, 2007

July 3, 2007

If you are using the Nvidia drivers posted on the Nvidia web site then you MUST reinstall these drivers whenever you update ANY of the X-server software. If you replace the kernel you will be forced to reinstall the drivers but just replacing the X-server or the open GL code does not do this. Not reinstalling drivers when video code is replaced usually causes problems. It seems like every time RH updates any video code but does not upgrade the kernel at the same time there are complaints that Wine causes machines to crash. This is the reason.

4 3

Re: dsound: Disable property sets if hardware doesn't support it
by Robert Reif July 3, 2007

July 3, 2007

This patch: http://www.winehq.org/pipermail/wine-patches/2007-June/039942.html causes RightMark3DSound.exe (http://audio.rightmark.org/products/rm3ds.shtml) to crash. It appears that the code always expects a property set interface to succeed and crashes on a NULL pointer when it doesn't. Reverting this patch lets the program run.

1 0

Parallels Wine DLLs
by Stefan Dösinger July 3, 2007

July 3, 2007

Hi All! I need your help with testing here: You may have noticed the buzz about Wine DLLs in Parallels Desktop for Mac last weekend. Yesterday Parallels has sent me their modified Wine source, or at least what they claim to be. (http://84.112.174.163/~stefan/WineD3D-0.9.36-Parallels.zip) Can those with a Parallels for Mac license test the rebuilt binaries? The thing is, the modifications in the source does not match the Integration into Windows I have seen in the original Parallels distribution. I don't think thats a malicious attempt to hide something, but rather that they sent us their current development version instead of the Parallels 3.0 version. The new libs do not link dynamically any more against their opengl icd, instead they do lazy linking, which makes compiling the libs easier. Also I think in the old version, the app still talked to microsoft's DLLs, which passed everything through to our dlls. In the source, the apps talk to our dlls, which have an option to pass things through to the original DLLs. I have so far no reason to believe that there are any other changes between the source and the original builds, but I want to be sure. Yes, its technically still a LGPL violation, but IMHO not a huge deal(as compared to not giving the source out at all). Since we can't look into the original shipped DLLs, we'll have to test if the source code works as well as the original DLLs. Steven Edwards has compiled them, and I've uploaded the binaries to http://84.112.174.163/~stefan/parawine.tar.bz2. As a first note, he compiled them using mingw, not using MSVC, so that may cause problems. If I understand the code correctly, installation should work as follows: (Perhaps don't test in a production VM, test in a seperate test VM). Rename the existing C:\windows\system32\d3d8.dll to d3d8.sav, same for d3d8.dll and d3d9.dll and ddrawex.dll and wined3d.dll(no backup needed here). Then put the DLLs from the archive above into C:\windows\system32, perhaps reboot(to be sure) and test your games. I saw that ddraw.dll did not build, so perhaps someone with Microsoft Visual Studio can try to rebuild the DLLs? What to look for? Do the D3D games work at all? Do some games stop to work although they worked before? Do some games work although they didn't work before? Thanks for testing, Stefan PS: I hope there is someone with a Parallels license on this list :-/

3 5

illegal characters in file names
by Lei Zhang July 3, 2007

July 3, 2007

Hi, I noticed a mismatch between the list of illegal characters in file names between Wine and Windows. On Wine the list of characters is: /:<>| and on Windows, it is: \/:*?"<>| Is this intentional or something we should fix? - Lei

6 7

Re: winealsa.drv: Tell the user how big his period size is.
by Maarten Lankhorst July 3, 2007

July 3, 2007

I would rather have that it's only reported in case of period size = 1024 (default dmix) and as a WARN that says 'use 512' instead, since dmix apparantly doesn't always work well with 256 after all on my other pc. Maarten

1 0

Wine and C99 inline incompatibility
by Zephiris July 3, 2007

July 3, 2007

I haven't seen this addressed and couldn't get an answer out of anyone on IRC. GCC defines 'extern inline' very differently from other compilers and C99. inline isn't actually guaranteed to inline (obviously), but 'extern inline' on GCC never defines a global function. References to the function are either inlined, or passed to another global function. In definition blocks that include things like InterlockedExchange, GCC's behavior of extern inline is relied on heavily, specifically that it'll (effectively) never conflict with another definition, and never define a symbol. Specifically, this appears to conflict with, say, when InterlockedExchange is actually defined later in the source file. Even if 'extern inline' is replaced by 'static inline', that's a problem. For that particular case, for instance, I tried to work around by only exporting separate extern declaration if _KERNEL32_ is defined, otherwise define the static inline part, since InterlockedExchange needs to be exported. But not so amusingly, the tools (loader, programs, etc) don't export __WINESRC__, so can't bring in the inlined definitions. I'm not quite sure how the GCC version of thing gets around that, as the extern inline versions aren't exported, and the tools don't depend on -kernel32. There are, of course, a few ways to get around that. Either #if __STDC_VERSION__ >= 199901L has to be used (which would entail all compilers going for specific C99 compliance only apparently), or compiler-specific blocks, or both, but it appears as if either __WINESRC_ needs to be defined for tools/server/etc as well, or they need to depend on kernel32, with no inline blocks defined for these things. There are a few other GCC-isms used that are incompatible with basically everything else, but this appears to be the great big ugly one. If I've missed something, or there's another option, let me know, but it's been nasty trying to work around this one at all, since trying to simply forcibly define __WINESRC__ for the rest would probably doom any patch. And before anyone asks, part of the reason this is coming up is because GCC apparently doesn't produce the most debuggable code on Solaris. But besides that, less explicit dependence on GCC for things where there's no functional difference would be a good thing, no? ^^; [ Reference: http://blogs.sun.com/x86be/entry/gcc_style_asm_inlining_support http://www.greenend.org.uk/rjk/2003/03/inline.html http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Inlin… ]

3 3

[Resubmit]: Added wrapper dll for ct-api(CardTerminal API)
by Christian Eggers July 3, 2007

July 3, 2007

Hello, possibly my previous patch got lost :-) If anything is wrong with the patch, please let me know. regards Christian ------- Weitergeleitete Nachricht / Forwarded message ------- Hello, I've made the suggested changes and prepared a new patch (sorry for the long time of waiting). In the meantime I got some additional feedback from other users of this DLL, hence I added a searchlist for different possible low-level libraries which might be extended in future. regards Christian > On 5/6/07, Christian Eggers <ceggers(a)gmx.de> wrote: > > Hello, > > > > this wrapper dll permits access to chipcard readers which provides a ct-api (CardTerminal > > It looks really good. A couple of quick comments for future patches. > Please use a standard LGPL license header in your patch for the > header, don't use C++ comments and you don't have to add a Changelog > entry. Alexandre's patch tools automatically adds it from your > email/changeset. > > [...] > > I forgot to mention the inclusion of config.h and port.h should come > before other headers in your source. > > Thanks > Steven Der folgende Teil dieser Nachricht enthält einen Anhang im sogenannten Internet MIME Nachrichtenformat. Wenn Sie Pegasus Mail oder ein beliebiges anderes MIME-kompatibles Email-System verwenden, sollte Sie den Anhang mit Ihrem Email-System speichern oder anzeigen können. Anderenfalls fragen Sie Ihren Administrator. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- Datei Information/File information ----------- Datei/File: 0001-Added-wrapper-dll-for-ct-api-CardTerminal-API.txt Datum/Date: 3 Jul 2007, 17:15 Größe/Size: 11150 bytes. Typ/Type: Text

1 0

oleaut32: Constify some variables
by Andrew Talbot July 3, 2007

July 3, 2007

Rob Shearman wrote: >> -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); >> +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); >> static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); >> static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface); >Even if the compiler allows this, it does not make sense. Why would a >constructor not want to modify the object it is constructing? If I'm not mistaken, the input parameter points to the template from which it is copying, rather than the object it is constructing, in this case. -- Andy. [Sorry. I sent this without a subject line, just now.]

1 0

(no subject)
by Andrew Talbot July 3, 2007

July 3, 2007

Rob Shearman wrote: >> -static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc); >> +static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc); >> static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc); >> static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface); >Even if the compiler allows this, it does not make sense. Why would a >constructor not want to modify the object it is constructing? If I'm not mistaken, the input parameter points to the template from which it is copying, rather than the object it is constructing, in this case. -- Andy.

1 0