Miscellaneous Support Page

From Wine-Wiki.org
Jump to: navigation, search


Contents

Wine for ISV (Independant Software Vendors)

The big question is how ready is wine? Software vendors are already making use of wine and they say it is ready.

There are several options provided to allow a company to distribute software on Linux, each of which have a number of factors to weigh.


Wine enables software vendors to get their software working on Linux. Note is that Wine is the results of a community that has a goal of implementing Windows. This Community is an important consideration. There are over a million lines of code in Wine which others in the community have written for many various reasons. This is to your benefit, as no company can buy or take control or even hold you to ransom. As anyone can fix code, and no one is forced to, this means the developers appreciate those who show a willingness to work with the community. With programmers writing up detailed bug reports, submitting test cases, actively participating in the Developer Mailing List, by working in together with the community often very quick progress is seen as they seek solutions that will benefit all software that is used on Windows.

Because the source code for wine is readily available - any programmer who is willing can help develop wine. Some vendors use their own developers or contract with the many Wine developers. Working with the numerous contributers requires an awareness of there being many disparate interests. The leverage of Open Source, is where the combined interests of a wide ranging community of developers benefit each other.


Wine and ISV related Quotes

One ISV wrote [Dec 05]: my partner and I are developing Windows applications. Seeing Wine some months ago fascinated me a lot, so since then I'm spending one or two hours a day trying to bring our applications to work under Wine [...When] submitting a bug, or writing something into the wine-devel list, [...effort is required...](like looking into the Wine sources, close in the problem area, and asking really specific questions to the corresponding 5 or 10 lines of code in the Wine sources. [...]

D. Kegel: [Dec 09 2005] "If you're not ready to invest in a full native port of your Windows app to Linux, you should consider using Wine to do a quick port of your Windows application to Linux. to judge demand for a Linux version of your product." osdl link

J. White of Codeweavers: [Dec 09 2005] Try Wine, if it fails, *ask* how hard it would be to make it work, and then use that in any migration decision. [...] people spend tens or hundreds of thousands of dollars on Windows Terminal Services when a fraction of that money could have gotten them a much nicer solution with Wine. WWN 302


An ISV posted [Jan 06]: We have 50 complex applications written in Microsoft Visual Basic 6.0 [...] We are seriously thinking of porting our applications to Linux under WINE. Is it possible to do so?

U. Bonnes: Porting to other X86 processors or really porting to other nixes, like power PC? In the first case, you can run windows libraries and you don't need the source for those application, in the latter case you need the source for every component in your tool chain.

[...] For this case, porting doesn't buy you too much, and running the application in wine (the "emulator") delivers the same (or even more) functionality to the user. [...] Install a recent wine, perhaps also install winetools and all the Winetools recommended MS downloads [Ed, wine tools has been superseded by Winetricks, wine has implemented so much recently that winetools is now obsolete]. Install all the needed prerequisites for your application (which seem to be big...). Install your application and try to run it... Probably some things will go wrong, try to understand what's going on and if you are at you're wit's end, ask [in the mailing lists]. Also think about the needed licenses for all those downloads. If you want commercial support, there are some offers, e.g codeweavers.

D. Kegel: when porting applications to Linux [...] good bug reports may get a bug fixed for free. [...] A summer intern may be good for an early look. [www.kegel.com/wine/wine-2006-june-talk.pdf]

Bundling your Application with Wine

A developer wrote [May 08 wineusr] I've recently written some graphic application in windows. i've was successfull in running it under Linux using Wine. I had to add gdiplus.dll to the windows/system32 directory.

D. Kegel: Please file a bug for whatever you ran into in gdiplus that made you need the native DLL. Perhaps we can fix it.

Dev: now for my question. Is it legal for me to create a "Bundle" Wine with my application and make it work "native like" under linux - and then sell it?

D. Kegel: Yes. Google does this with Picasa (well, they don't sell it, but that doesn't matter).

Dev: Meaning that the end user will but a software that will install my application while it will run under the Wine platform? my question regards legal issues for Wine but mainly for Microsoft. since i'm using gdiplus.dll, arent i'm obligated to pay something to microsoft?

D. Kegel: A better path would be to bundle gdiplus.dll with your Windows app, and then tell people to run the app with Wine-1.0. You could provide a script that would download Wine 1.0 and install your app in it, say. [...] you have to obey the EULA. For instance, if you use the redistributable from http://www.microsoft.com/downloads/details.aspx?familyid=6A63AB9C-DF12-4D41-933C-BE590FEAA05A you can clearly bundle that gdiplus.dll with your windows app. I am not a lawyer, but: You clearly should not bundle Microsoft's gdiplus.dll with a Linux-only version of your app. It's fine to bundle it with the Windows version of your app, though, to let it run on versions of Windows that don't have that library.

A Wine developer noted that filing separate bugs accompanied with test cases for the dll would help Wine eventually fix the problems with gdiplus.

Developing an Application to run on Wine

Using Wine vs Cross Platform design

oiaohm [2011 Feb] You have two options

  1. do it proper and redesign you code base piece by piece to be cross platform by design.
  2. try to make wine work. Normally works out simpler trying to run inside wine.

Long term 1 ends up better due to different compilers digging out different bugs.

[Ed. While you might want to in the long term look at a redesign, if you need it to work sooner than later, consider that Wine may already run or almost run your software right now.]

Wine vs Winelib

Ed [ It appears winelib is not necessary or recommended unless you are running software on non x86 hardware. It is simpler, more reliable and just plain easier to use Wine.].

Vitamin 2011 Feb: Winelib has a number of issues to work with vitamin; winelib is not a standalone native application. It's still requires Wine to run. And you will need the specific Wine version you used to compile and test your winelib app with. Or you [risk...] regressions and incompatibilities.

[Ed. It is simply better in most cases to improve Wine so that your application runs better in an unmodified Wine]


A Developer asked: do I need to link to a wine-ish library of some kind to allow my app to run in the linux/apple worlds?

Vitamin: No, Wine runs unmodified windows applications. If you find a bug you can try and fix it yourself (in Wine) since you'll know exactly what the problem is. Or at least create a good bug report for the problem.

Developing with Wine in Mind

A Developer wrote Nov 08: how can i best make sure that the programs i design on windows are able to run on wine?

D. Kegel: The main thing is to test on Wine as soon as possible, and file bugs so we can fix any problems you find. Test with Wine *way* before your program is finished, ideally right at the very beginning. In fact, you might consider actually developing on Wine by running your compiler and IDE on Wine, and testing occasionally on real Windows. Also avoid .net, especially .net 3 or higher.

Ed If you are stuck... .Net is a big job that is in progress.. and mono apparently can run on wine for some cases.

As of Dec 09 Wine on the wineuserlist: Wine doesn't support any API newer then XP and possibly some small number of Vista API calls. [Ed Wine is a fast moving target] Wine does not implement every API just because MS decided to create one. Unless you have a real live application that doesn't run on Wine - there are [no real] reasons to implement this function.

Another noted: Anyway, if [an API] isn't yet [Implemented], [you] can stub it. Archived-At: http://permalink.gmane.org/gmane.comp.emulators.wine.user/57179

Gui and threads

I am the developer of program, which must work under Wine and Windows. it has two threads, and these threads use one function to add text to Rich text box. When they try to add texts in parallel, a mixed text appear. So I decided to use critical section. When main thread tries to add text, the text adds perfectly, but when the second thread tries to add text - it hangs my app.

Vitamin dec 10; Don't use crit sections with anything GUI related. It's all serialized via message queues. If something doesn't work when using SendMessage() then you either doing something wrong, or it's a bug in Wine. In first case - check if it works on Windows. And if it does - file bug in bugzilla. Also note that Wine's implementation of RichEdit is still pretty weak and does have significant issues. [..] Can you make a small example program demonstrating the issue?


Hardware Access

A developer wrote: I built a projet that use direct i/o access to $100-$1F0 and $300-$307 i/o address. I use delphi 6 with a driver to enable direct i/o access in winNT,XP etc. and all is ok.

Vitamin [mar 09] Wine does not support this type of drivers. They can not and will not work on Wine. You can not access hardware ports on Linux from user space unless you running this program as root. Or used some other mechanism to allow yourself to access ports. Even if you running program as root, you still have to use ioperm() to enable port access. For more details see for example this HOWTO: http://tldp.org/HOWTO/IO-Port-Programming.html

Another added: The kind of operation you are asking for is not simple to be made work. http://tldp.org/HOWTO/IO-Port-Programming-2.html#ss2.2 Note the warning there about using device port system can be completely exploited by any program giving that ablity. This also applies to Windows raw IO support. Due to using raw hardware access any program doing that can in theory take out the OS. You really need to seriously consider splitting your program in two. Service or a Driver as root and interface as usermode. Things are forbidden from normal users for very good reasons under Linux. You have to consider the security side of what you are doing [..]. No point having you program working on Windows and Linux if it equals running insecure.

Testing for Wine

A developer asked: I was wondering if there's a way to discover if I'm under Windows or Linux just having a function like IsWine() that returns a boolean value. In this way I will be able to fix those small things that don't work and have my application running on both systems.

A. English [feb 09]: We discourage this. The best thing to do would be fix those bugs in wine. Short of that, fix your application in a way that works on both, not hacks for wine/windows depending on the implementation. Depending on hacks for wine is bad practice, as if it's updated in the future, or fixed, your app may break unexpectedly/weirdly. You know the code for your app, so fixing wine is already easier. If you can't fix the bug, file good bug reports (with test cases). [...]

The Problem with testing for Wine

[Ed. Wine development is very, very fast so testing for wine is not the best option. If you cant fix Wine, you might be able to work out how to add a test case to wine's test suite. You could put a bounty on a bug. Also regular testing of wine can also catch new bug that affect you, and by catching them wine can be fixed sooner. This can be automated http://www.cxtest.org/ and with more and more developers doing this, the better for wine]

A developer noted [feb 09 winedevel]: Waiting for Wine to fix it would mean unnecessary waiting and very likely for a problem that is only contained within 1 particular situation.

A. English: Right, but if the bug is fixed in Wine later on, then the app may behave unexpectedly. [Aso many windows machines have similar bugs to Wine] [Ed The problem may just be that Wine is accurately emulating a bug in some versions of Windows]. Windows won't receive that fix either. The proper thing to do would be detect the broken behaviour and work around it, not detect Wine. But if you have a workaround, that should be the default behavior, so your app works the same in Windows and Wine. [..] If you test for the the broken behavior (which can occur on Windows as well), you won't risk breaking Wine in the future, and also fix the app for broken Windows machines.


J. McKenzie: Others have tried [testing for Wine] before and gave up. [The problem is] Wine is a moving target with continual improvements and changes. Microsoft owns the Registry, but how we implement it is up to us and subject to massive changes [so] Anything you do that relies on [how Wine implements the registry] can and will break in the future. [..] The purpose of this project is to emulate the Win32 environment as produced by Microsoft without infringing on Microsoft's patents and trademarks. [..] Because of [this], we don't implement [the registry] the same way as Microsoft. [..and] Anything you find in [Wine's internal implementations] is subject to change at any time.

Thus, you should attempt to find and notify us of anything that does not work in your program when it is run in Wine. [..] Sorry if you feel that we should do things YOUR way, but this is [..] the Wine Project and we don't feel that YOUR way is the correct way. This project is over 16 years old and is continuously evolving. However, [supporting just one program] is not going to change how we do things to [correctly emulate the windows environment]. If your program is Microsoft compliant, [the aim of wine is that] it should run, without any additional changes, on Wine.


One poster pointed to the: Wine[..] set of registry keys http://wiki.winehq.org/UsefulRegistryKeys and asked: Will detecting HKEY_CURRENT_USER\Software\Wine stop working at some point in the future?

Another poster noted: Probably not, but you cannot depend on it, as it's not supported. The developers may choose to rename the registry keys at sometime in the future. Vitamin also commented that nothing is preventing a windows user adding these keys to Windows.

Another Poster posted code but Vitamin reviewed it and said [feb 09]: It's a really bad way to detect Wine by looking at resources. If you really want to have a reliable sure way to detect Wine - look for Wine specific export(s) from that dll. But as mentioned before, make it a user overridable in case Wine gets fixed, or developers want to actually use your app to verify correct functionality.

Another programmer suggested [Jul 09] checking for $WINEPREFIX and use that to detect Wine. [..] Vitamin noted this too would fail and pointed to an alternative: that will fail in the future Wine versions. If you do not know how to check availability of some features, let user choose what platform they are running on.

The alternatives to testing for Wine

Ways to do it (best to worst):

  1. Fix properly in wine.
  2. Adjust app in way that works in windows AND wine, sans hacks.
  3. Package a version of wine with your software
  4. Add an option to enable/disable each Wine hack.
  5. Ask the user if they use wine or windows
  6. Detect wine, hack around it (BAD).


G. van den Berg: It would probably better to bundle a version of Wine with the application (like Picasa), which would prevent this issue... (It would make the detection code unnecessary as well, since you know that the version will always run under Wine). This should not be used as an alternative to reporting bugs though... (Although doing it in parallel might be a nice trade-off)


Sometimes your software nearly works and you need to get the product out of the door and you do not have the time to bundle it with wine but you are willing to accommodate some of the Linux users of your software.. You know why testing for Wine is bad, and there is a better option mentioned by A. English http://permalink.gmane.org/gmane.comp.emulators.wine.user/39838:

Add an option to enable/disable each Wine hack. Utorrent does this. You get your app working in both Windows and Wine, and if/when in the future Wine is fixed, you only have to disable the hack. Quick, easy, cheap, and non-lethal for Wine and Windows. Of course, the developer in me would ask that you file a bug for each problem, and if possible, a small snippet of source code showing the problem.

The proper thing to do would be detect the broken behaviour and work around it, not detect Wine. But if you have a workaround, that should be the default behavior, so your app works the same in Windows and Wine. [..]


If you do have some low level need to access things that are not on Wine, you can use Linux. Thunderbird [wineusr 09} for accessing linux specific files and APIs you don't need to turn your app in a full winelib app. Just use winegcc/wineg++ to build a small winelib library containing the functionality you need and from your windows app it is just a 'win32 plugin dll'. As long as it isn't too fancy it should work on all distributions and won't require a recompile.

Companies which do test for Wine

One company which does test for wine was favourably noted Feb 2009 on the Wine DEvelopment mailing list: LTSpice http://www.linear.com/designtools/software/ltspice.jsp . It was commented in the wine developer list that: Its authors are wine-friendly. This from the online help "LTspice detects whether or not it's running under WINE. If so, it works around a few WINE issues. You can force LTspice to think it's running under WINE with the command line switch �wine. You can force it to think it's not with the command line switch �nowine in case you're interesting in working on WINE issues."

A. English expressed a wish that bugs had been filed, ideally with test cases in wine Bugzilla: A search in bugzilla shows 2 bugs with LTSpice in the name/comments.

D. Kegel noted: Sometimes ISVs just want to get a product out the door. At least they have the runtime option so we can force it on or off, which is nice of them. It would be nice if someone could verify with them that we have bugs filed for everything they had to work around, and maybe [identify ..] the workaround[s] [that ] they applied. [However it was noted that wine will eventually fix these bugs and this may affect how well the software would then work on wine].


How to get a fix

[One Windows developer told off the wine developers for not quickly fixing his problem but was quickly reminded about the culture of Open Source. There is a very wide variety of people from many differing groups, with very differing views - that have a shared interest in Wine.]

Forum name Vitamin [feb 09]: That's not the way Open Source development works. If you want it so bad - code it yourself, or convince someone to do it. Telling them they are an idiot won't help. You can hack all you want a commercial product. But this is not acceptable in the FOSS world. It should be done right or not at all. There were number of cases when detecting Wine and doing something different eventually broke the application on Wine. So this solution is not viewed as acceptable one by the Wine community.

[Ed. If finding the bug in wine is a big task, perhaps try and write a very small program that demonstrates it, you might attach a screen shot showing what should be happening on windows. Writing a test case which shows the bug and file it with a bug report in Wine's Bugzilla appears to be a good idea, or better yet add a test to the wine's automated tests]. Even if you cant provide one of these different test cases, there is an alternative to testing for Wine..

Getting your Application to run on Wine

You may not have developers able to work on Wine, and Aug 09 wine user included a post discussing about how it may not be possible for a company to allow testing with their internal software. The user posted. In my country (Spain) and others lots of organizations have custom closed-source applications developed mainly in Visual Basic. This kind of applications have a complex deployment [..] and use local languages[...] it is not only illegal to publish this applications but they are difficult to test.

[..] There are many work desktops that could use Linux but they depend on one of this custom rare closed-source applications that cost lot of money and have private obscure databases that can't be migrated.

He then asked if there were some area where a user could add the their Windoes API needs rather than a specific program/software/game needs.

A. English pointed to one place where this already occours: http://bugs.winehq.org. [Ed. There are irregular bug entries where an api is requested. Try and make it easy for a developer or bug browser to decide to work on your bug. If you can, write small test cases and attach these to the bug report, or even adding a test case to the wine test framework, can help too. The more public information about the api you can provide the better. ]

Packaging An Application with Wine

Picassa is an example of packaging an application with Wine - perhaps that as a first example.


Jan 09 wineuser post said: I intend to package a few games of mine using Debian packages for easy installation and would like some tips on how to do it properly. I thought of creating packages that depends on wine and to create a wineprefix for each game somewhere in /usr or /var mostly because different games want it's own settings and to control them separately. But this way I don't think updates of wine would be handled well.

A. English: This sounds reasonable. You're best bet would be to test new wine versions (or git), regularly, to be sure to catch regression early.

The user wrote: Another alternative is to include all the wine files in the package - but this seems to be a lot of work.

A. English:Yes, and if they had multiple games, a lot of wasted space/overhead.

The programmer wrote I also would not like to have each user have an own copy of each game/wineprefix in ~, even with symlinks - it's just "feels" wrong... This is the way wine-doors do it I think.

A. English: Well, Wine doesn't yet support multiple users per prefix, so you'd need to do this, or hack around it manually.


A Programmer asked dEC 08 wine user: Is it possible to link in the WINE libs to my application so that I can just have the single executable?

Vitamin: See http://wiki.winehq.org/DeveloperFaq which says "Can I build one large Monolithic application?

No. However, if you don't want Wine as a dependency, you can bundle your private version of Wine into your package (.rpm/.deb). Wine has good support for such a setup via the WINEPREFIX environment variable. This is the way Google Picasa works - they actually use the exact same binary on Windows and Linux, but in the Linux version they bundle a tested version of Wine. "

Is it legal?

Note - this is not legal advice. This is repeating comments on the mailing lists and elsewhere. If you need legal advice ask your lawyer.

A programmer asked feb 09: I'm wondering if it's possible to wrap a program with Wine? Is this legally allowed, is there someone who could provide this service?

A. Austin: Yes. Legally speaking, yes. If you modify Wine, you must provide the source code changes per the LGPL. Codeweavers provides this service as well. Vitamin added: Yes, see Picasa for example.

Applications that support Wine

Curiously Feb09 a wine user suggested: Is there an effort to produce a wine certification? A badge/sticker that can be placed on a product to say "also runs on Linux using wine" Or perhaps, where the OS badges are placed a little tux and glass of wine. Another user wrote: At present I think it's enough to get people to declare that they officially support Wine as a platform. [However none of the wine developers gave their opinion on this, but they already have this official wiki page: http://wiki.winehq.org/AppsThatSupportWine

A Smaller Wine

A Developer wrote: I want support out-of-process COM on a mobile phone platform base on Linux. Wine is perfect,but also is too big and too complex to run on the device. So,I' going to create a project named WCOM with some code(ole32 and rpcrt4) from wine

D. Kegel: Say, how about making Wine configurable, like Embedded XP and Linux are? We already have a configure script. You could add a --tiny configure option to disable everything but the tiniest core needed for embedded devices.

Avoiding a fork might be very good for you business-wise, because it would mean less maintenance work for you. Since Wine is LGPL, you are free to use it in commercial projects as long as you follow the license's requirements. Consult a lawyer for details. See also http://www.softwarefreedom.org/resources/2008/compliance-guide.html for a guide written by lawyers about how to conform to the GPL, LGPL, and related licenses.

BTW, my take on things is: The intent of the LGPL was something like "allow users to fix bugs in the code", so in general you should not static link Wine code directly into your apps, but rather leave Wine as replaceable dynamic shared libraries. You must provide the source for the Wine tree you use. Ideally you'd also provide a way for users to build Wine themselves and flash the device with their own improved versions of wine. But I Am Not A Lawyer.


This was raised again Jan 09 in wineuser mailing list: Does anyone know of a way to compile a LITE wine - like a zinfandel I guess? I just want to be able to use - wine /mypathto/myprogram.exe. such as --disable-dev --without-notepad --without-ie....

[..]There are so many things included that I will never use that basically just take up space. For instance the compile environment,[..] There are other things as well...I don't want/need any of the windows components either.or any of the libraries(/"dll"s) associatied with them. Barring no feasible options at compile time, is there a list of files that are required for just the wine executable. [..] I guess I need to know where the dlls, etc... are that myprograms call when run with wine.

[Ed this is not a task to rush. Tread carefully with this one and use thorough testing]

V. Povirk: You can run make install-lib instead of make install to only include the parts needed to run programs. The corollary is that everything install-lib installs is a necessary component of Wine, including notepad and internet explorer. If you remove any of those things, or configure warns you about missing dependencies, your version of Wine is broken and may fail to run some programs that would otherwise be working. (OK, maybe winemine can go, but everything else is important.)

V. Povirk: You can see what builtin libraries (.so files in lib/wine) are being used when you run a program by running it with WINEDEBUG=+loaddll. This isn't a reliable method to determine what your program needs, as programs (and wine components) are known to load additional libraries at runtime as needed for individual features.

Vitamin: Unless that user developed this program himself/herself there is no way of knowing for sure what a particular program might use. As an example more and more programs use performance counters for accurate timing. Also lots of programs might use printer functionality to process images/text.

A. English: Use --enable-maintainer-mode to find some things you can disable, e.g., debugging symbols. You can also disable some dlls, that are optional. [...] We already do this for some features, e.g., printing/scanning/msxml3/etc. If the user knows they won't need certain features, and they aren't depended on internally in wine, they should be able to disable them. [..]Such a feature would be good though...Patches welcome.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox