November 2005 - Wine-devel - list.winehq.org

What would most aid WINE development?
by Susheel Daswani 19 Nov '05

19 Nov '05

Hello WINE Development community, My name is Susheel Daswani. I am a second-year law student at Berkeley School of Law. I am also a software engineer - I used to develop the LimeWire open source Gnutella p2p application. Nice to meet everyone. For my 'Antitrust & IP' course this semester I am writing a brief about why I think the remedy in the Microsoft antitrust case was inadequate. My main recommendation is that the 'applications barrier to entry' phenomenon (users like OSes with lot of applications, developers like OSes that users like) need not aid Windows' dominance. This is of course familiar thinking to the WINE community - if a *nix (or any other OS) could effortlessly run every Windows application, then we wouldn't have a monopolist over in Redmond, or at least we'd have some fervent competition in the personal desktop OS space. So my question for the WINE developers is "What materials from Microsoft would most aid the development of WINE"? The Windows API is of course public, so my guess is that isn't a huge bar to creating WINE. So what are the bars? Is it simply the scope of the project? Is there information that MS could divulge that would greatly aid the WINE effort? Would open sourcing part of Windows help? I plan to use your answers for no other purpose than educating my professor on what, alas, *could* have been done to help restore competition to the personal desktop OS market. Thanks very much! Susheel Daswani http://www.susheeldaswani.com sdaswani(a)boalthall.berkeley.edu

6 6

Re: make builtin dlls visible for applications?
by Juan Lang 19 Nov '05

19 Nov '05

> 2) place dummy files for all builtin dlls in c:\windows\system32 I believe this is the correct approach. I know of at least one InstallShield installer (that uses MSI) that searches for IE by looking for the file shdocvw.dll and checking its version. Presumably we'd like our users to have the option of installing programs using all builtin DLLs, even with silly checks like this. Eric once mentioned he had some hacky program that parsed PE headers that we might be able to coerce into creating such dummy DLLs. What we're looking for (besides him posting the code) is a volunteer to work on it. > hmm I guess you would get into trouble if you use WINEDLLOVERRIDE. > Wouldn't LoadLibrary try to load those dummy files? Someone proposed a hack where the loader would know that these DLLs are dummies based on a wine-specific flag in the header. --Juan __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

5 4

Quick q about bug posting
by Dustin Navea 19 Nov '05

19 Nov '05

Just wondering, I'm going through all of the different apps that I have to see what sorts of problems I am running into, and in several of them, the programs run fine, but there are some graphic glitches (nothing major).. Should I report those here, to bugzilla, or both? They all see to be trivial to fix, and could be a plus to have listed as like gold or platinum (if there is a platinum designation). These are all _apps_.. not games.. So like I said, here, bugzilla or both? Dustin

1 0

Using Windows .DLLs in Linux C++ code - possible?
by Jim Morash 19 Nov '05

19 Nov '05

Is it possible, via Wine, to link against a Windows DLL in a C++ program compiled under Linux? My specific situation: I would like to interface a piece of hardware over a serial port. The manufacturer refuses to provide a serial comms specification for the device "because it's proprietary", but they will happily provide a Windows DLL that can be used to control the device. Any chance of using it under Linux? thanks --Jim Morash

3 2

Re: [winecfg] add sound driver test
by Steven Edwards 18 Nov '05

18 Nov '05

Hi, On 11/13/05, Robert Reif <reif(a)earthlink.net> wrote: > Changelog: > - add a simple sound driver test > > Download the test wave file from: This is 3 megs. Could we not use a higher level studd and use winemp3 to docode a mp3 that can be embedded in a resource script? I wrote a patch a few months back alot like the one you submitted but I decided to trash the idea when I saw how large and how much of a pain it would be to deal with a *.wav test. Thanks Steven

5 5

make builtin dlls visible for applications?
by Peter Beutner 18 Nov '05

18 Nov '05

Hi There is yet another issue preventing SeriousSam from working. It fails to load opengl32.dll because before loading the dll it makes sure it can find it via SearchPath().The problem is that SearchPath doesn't know about the builtin dlls provided by wine, so it fails to find them and SeriousSam won't start. I can think of several ways to work around that, but i don't really like any of them. Maybe somebody else can throw in some comments or even has a better idea: possible solutions: 1) let SearchPath search for builtin dlls, and if found make it pretend the file exists in the c:\windows\system32\. This will cause all sorts of trouble if the application want to do anything else with the file beside trying to load it.(think of somebody browsing around with a Filemanager trying to copy/move/rename those files) 2) place dummy files for all builtin dlls in c:\windows\system32 (or symlinks pointing to corresponding *.dll.so files) hmm I guess you would get into trouble if you use WINEDLLOVERRIDE. Wouldn't LoadLibrary try to load those dummy files? 3) just put it under the category "application-specific hack", and put instructions somewhere(appdb,..) what to do to get it working. ie:"touch ~/.wine/drive_c/windows/system32/opengl32.dll", would do it in this case. 4) combination from 1) and 3), solve it like in 1) but make it a per-application configuration setting similar to dll overrides. Comments? Better ideas? Peter

2 1

Re: What would most aid WINE development?
by Juan Lang 18 Nov '05

18 Nov '05

> The Windows API is of course public, so my guess is that isn't > a huge bar to creating WINE. Unfortunately, you guess incorrectly. While the API may legally be public (the interface can't be protected, as far as we know,) it isn't always documented. MS uses undocumented APIs very, very frequently in its own products, and I don't just mean in its applications: parts of its API depend on other, hidden parts of its API. Even the parts that are documented are not documented completely. For example, many APIs take 32-bit flags parameters, some of whose meanings are documented. But the behavior for all possible values is not well-specified, nor are the return values. I continue this thread next: > Is it simply the scope of the project? This is a large part of the problem. It's difficult to appreciate just how large it is. (There was a presentation about this once, maybe by David Korn, but I've lost track of it.) We can only learn the behavior through experimentation, and so do application developers. The application developers depend on undocumented behaviors, so we have to replicate them, including bugs. The problem is, there are many more of application developers (and Windows developers) than there are of us. Also part of the problem, though I don't think it comes close to scale as far as its impact, is that our architectures are different. For example, the code obfuscation tools (securom, safedisk et al) depend on device drivers being loaded by ntoskrnl.exe. This is related to the hidden assumpmtions problem I described already, but sometimes we have to implement a large amount of silliness that we didn't anticipate having to do, or reimplement stuff that was already working for some apps. ReactOS can potentially avoid some of these issues, since they're copying much more of Windows's architecture. > Would open sourcing part of Windows help? Only if it were done in a way that didn't encumber our ability to develop WINE. --Juan __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

3 2

RESENT: [msvcrt] I64 and ll support
by Raphael 17 Nov '05

17 Nov '05

On Wednesday 09 November 2005 02:15, Raphael wrote: > Hi, > > Changelog: > - add I64 modifier support on msvcrt *printf functions > - correct ll modifier support on msvcrt *printf functions > - correct tests > > this should correct bug 3759 and 2075 (and many others) > > Now for libc who don't support %ll modifiers (which one?) > Jesse Allen provide the patch (see bug 2075 content) > > Regards, > Raphael better patch than previous: now Jesse can put his code into #else / #endif :) Changelog: - add configure check to detect support of %ll modifier on libc printf - add I64 modifier support on msvcrt *printf functions - add I32 modifier support on msvcrt *printf functions - correct ll and LL modifier support on msvcrt *printf functions - some FIXMEs on unsupported cases - correct tests Regards, Raphael

2 3

program name clashes
by Daniel 17 Nov '05

17 Nov '05

Hi, a problem which just popped up in the newsgroup: Imagine a program called start.exe (or notepad.exe or regedit.exe, etc.). Invoking 'wine start.exe' will not run this program, but the start.exe that comes with wine. The only workaround is to do WINEDLLOVERRIDES="start.exe=n" wine start.exe. This neither logical nor intuitive, instead it is rather silly. At least 'wine ./start.exe' should actually run the program intended, not some obscure program the average user has never heard about. regards, Daniel

1 0

Drop the PFD_GENERIC_ACCELERATED flag?
by Peter Beutner 17 Nov '05

17 Nov '05

At the moment wine always set the PFD_GENERIC_ACCELERATED flag in X11DRV_DescribePixelFormat. SeriousSam uses this flag to determine if the pixelformat is hardware accelerated. If the flag is set it is interpreted as _no_ hardware acceleration available. Unfortunately MSDN isn't really clear about what that flag really means: it describes it as: "The pixel format is supported by a device driver that accelerates the generic implementation." After reading [1] I think it should be like that instead: If PFD_GENERIC_ACCELERATED is set the pixelformat is partially accelerated by the device driver and some parts are just software fallbacks. If PFD_GENERIC_FORMAT is set everything is done in software. And only if none of both is set it is fully accelerated in hardware. Is there anything similiar in GLX(full vs. partial accelerated) so we could set that flag according to that? Or, if not, can we just drop it? Imo it's better always off than always on. Thanks Peter [1] http://www.microsoft.com/msj/archive/S2085.aspx

4 8