Slashdot Mirror
Ask About Running Windows Software in Linux
There have been recent reports about programs from Israel, Canada, and The Philippines that let you run Windows software in Linux. Are they really new? Can they succeed? Is this whole effort worth the time and trouble going into it? CodeWeavers CEO and Wine maven Jeremy White ought to know, since he's been working to bring Windows software to Linux users for many years -- with quite a bit of success. We'll forward 10 - 12 of the highest moderated questions posted here to Jeremy, and run his answers as soon as we get them back.
We've heard that Project David could be a CrossOver Office rip-off. To what extent is David a fraud and what are your options to combat those who would misrepresent themselves using your products for VC or even illegal/infringing sales revenue?
The dangers of knowledge trigger emotional distress in human beings.
What is the timeline to get true windows program compatability in the open source operating systems?
Evolution or ID?
How do features and bugfixes get priority/take precedence in WINE? Is that likely to change?
tasks(723) drafts(105) languages(484) examples(29106)
Why dedicate time (and presumably money) to continue the lock-in Microsoft Office and similar apps have in the workplace, rather than dedicating that time to make existing F/OSS software better, thereby removing the lock?
To what extent do you believe Windows binary compatibility on Linux could stifle development of native Linux solutions that compete with those Windows applications?
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
What are the biggest challenges in getting generic Windows software to run? So far, WINE has appeared to be mostly focused on games. While it's great that my son's Blue's Clues game runs just as well as on Windows (Thank You!), getting applications like Video Players installed tends to be difficult if not impossible.
Javascript + Nintendo DSi = DSiCade
Do you receive any help or tips from developers at Microsoft? I don't mean illegal access to source code or anything, but maybe discussions on how duplicate certain methods to increase compatability and stability in WINE?
I understand that most of the work of Wine was in porting the Windows APIs. Have there been a lot of surprises outside of API porting that you've encountered along the way?
Of the various API libraries, are there any you thought would be particularly easy or difficult to port, that ended up surprising you?
I imagine at least some of the APIs worked somewhat contrary to their documented (or undocumented?) nature; in those cases have you chosen to go with the Windows implementation details in order to maintain compatibility?
Which API have you disliked working with the most?
I am disrespectful to dirt! Can you see that I am serious?!
If you could reimplement the Windows API yourself, keeping it in recognizable form but making improvements, what would you do differently? What are your favorite and least favorite things about it?
What I'm listening to now on Pandora...
Isn't trying to be compatible with MS what killed OS/2?
If people can code for windows and run elsewhere, why code for unix/linux natively?
Artists against online scams http://www.aa419.org/
If the EU really does pass the software patent law under consideration and the U.S. adopts that treaty that Bush is pushing, won't MS just be able to sue any compatibility products out of business?
-All that is gold does not glitter - Tolkien
www.ra
What types of applications are currently being focused on to get working under emulation? Do you target specific applications, or catagories of applications?
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
The WINE web site goes a long way towards making the case for the API solution. Obviously, the VM solution seems to be easier to accomplish, would a hybrid solution give us a better result?
A lot of people I know are put off by the way applications running in WINE look on their *nix desktop. Are there plans to integrate WINE with a native linux GUI toolkit for a more streamlined user experience?
It's been coming for a long time, any idea as to when it will get here and what are the criteria for achieving that mystical 1.0 milestone!
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
What have been the biggest obstacles encountered so far?
...and what has been more difficult:
Poking the WinAPI and figuring out how and what it does?
or
Microsoft breaking what you do figure out?
has microsoft actually been as much of a hinderance as us Slashdot readers would expect them to be?
One would think with lots of API documentation available that a near perfect compatibility layer should have been feasible by now. This has not happened and many people (myself included) don't really understand why.
What hurdles stand between Wine/Codeweavers and a near-flawless Windows compatibility layer?
It seems like most of the effort so far has been to get office productivity software (ie. Microsoft Office) to work on Linux. However, there is a market for low cost home computers that Linix could help to fill if the educational software that kids use (such as the Reader Rabbit series) could run on Linux. Why is this potential market being ignored?
Do you have any funny stories about making this sort of thing work? Ever discover embarrasing or silly stuff about a developer? Seems like your line of work would lend itself to those sort of things.
"Derp de derp."
I had the dubious honor of testing a Windows app that was ported to Solaris a few years back, using a Win32 translation library (not WinE, forget the name of the library). Not only was it 5-7 times larger than the equivalent U*ix app, it was 7-10 times slower.
So I'm wondering what provisions are being made to maintain performance levels in the libraries themselves. Simply mapping Win32 API's to U*ix API's and providing some compatibility stuff won't cut it if my Win32 apps run on U*ix system like poorly written recursive shell scripts.
...and you run and you run and you can't stop what's been done...
If your project enables Windows software to become fully compatable with Linux, do you see companies choosing to only produce a Windows variant?
Will full compatability force Microsoft to release Linux variants of its software?
Will full compatability neccesarily mean people changing their OS to Linux?
Indeed, do you feel full compatability ever be possible?
correct me if I am wrong, but doesnt the whole windows emulation thing come down to whether or not you can utilize the drivers, namely the video drivers... if you could run PC games JUST AS WELL on a Linux box then a Windows box... i think it would boost Linux sales into the roof... what do you think?
Have you found any attempts to break WINE? Programs that in your opinion had code put in just to make it difficult for WINE to run?
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
In the event that you succeed in porting the Windows API to Linux, have you thought of adding a few... extensions of your own? And, if so, what would those be?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Is the current focus on a broad compatibility or making specific (but large userbase) applications work?
Where should the focus be?
Will your efforts be a success when Crossover and/or WINE have equal compatibility with WIN32 applications as does Windows (i.e. not very good except for MS products), or will you have to be better than MS at making applications work?
"As God is my witness, I thought turkeys could fly." A. Carlson
Will .NET cause a convergence of binary programs to this one standard?
.NET CIL be the end of cross-platform binary incompatibility?
Could forcing the huge catalogue of traditionally Microsoft-only software to
You've probably noticed that people's noses get bigger as they get older. That's because old people are huge liars.
Do you ever get disheartened when Microsoft announces a new API, as that means you've suddenly got a whole load of new code to replicate? DirectX would seem to be a prime example of this. How do you see .Net/Mono in relation to Wine? Do you think they will ever become the prime method of running Windows applications under *nix?
What options/alternatives do you see Linux gamers having with regards to DirectX emulation for popular Windows games that don't have Linux equivalents? Do you see better support for DirectX API in the near or distant future?
Reader Rabbit and his ilk are the only reason we still have a Windows computer in the house (but never on the net!). That won't last forever: either our kids will outgrow that, or Wine will get good enough. Our youngest is 1, so they have about 17 years to liberate our family from Windows, or it's too late.
See what I've been reading.
I know of many projects (like TransGaming's WineX) that are commercial and made for the idea of running windows games on Linux. My quesions are this do you feel that this is the correct way to get a developers to slowly switch over to Linux, or do you belive that it would make more sense to make complier and library that is more 'friendly' for game development? Also, what do you feel is the largest factor that slows the production of games for linux?
Are you guys working on a deal with any of the tax software publishers to ensure their software runs under Wine each year?
If not, would you consider it?
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Programs running under wine however simply look just like windows programs making them a bit "alien" on unix desktops. Do you think it would be a good idea that programs running under wine look and feel more like native programs?
At the present moment, TransGaming Technologies, which implements their own version of Wine (WineX) seems to be both the poster-child for what's good and bad about running Windows applications (games specifically) on Linux.
Of all the games they list for compatibility, only 8 games score a "5" for useability (meaning: no glitches, no 'minor irrirations'). That's 8 out of a virtual gazillion.
While some trumpet this as a promising turn in the tide towards Linux gaming (as opposed to waiting for native ports), many feel that it's trading the virtues of one OS in order to subsidize another.
What is Jeremy's opinion on TransGaming's approach to 'Windows apps on Linux' in light of this?
(and thanks!)
This wasn't just plain terrible, this was fancy terrible. This was terrible with raisins in it. - Dorothy Parker
It seems to me that there are two good approaches to running Windows and Linux programs on the same box without switching between operating systems. One is to use Wine under Linux and the other is to use Cygwin under Windows. What are the advantages of each approach?
I like my beverages with warning labels!
It'd seem to me that the biggest problem with Wine and its derivatives is that they're constantly chasing a moving target.
Since MSFT is, to some degree, held hostage by a need to ensure compatibility back to Win 98 (or perhaps, Win2k), why not create an independent standard for ISVs industry wide? Freeze a Win32 API set that meets the needs of most ISVs, call it something like OpenWin32, and get the word out that if writing to this API will ensure that software works on BOTH Windows and Wine-like constructs.
Creating such a thing would be expensive - there'd have to be developer tools and compatibility suites created - but it'd not only help crack MSFT's lock on the industry, but it'd be a potential revenue source for Crossover (who better to create such resources?), and help popularize Windows software on non-Win platforms.
My likely misinformed $.02
Jonathan
Many, if not most FOSS apps are developed as a way to scratch an "itch" for a developer; a task or problem that isn't solved by current software. The Wine project's itch could logically be construed as the inability to run a Windows program on Linux. What was the app that you couldn't live without; the proverbial straw that broke the camel's back?
I'm a wine user, windows user, and linux user. It seems that games under wine work slower then the same app under windows.
I would have thought that because the linux filesystem is faster then fat32 (the fs I'm using under windows) it would be faster in that respect. In other respect it should be equal.
Where are the current bottlenecks and will it ever be close enough to a windows platform that a wine'd application will run as fast as windows, and without any noticable differences?
(BTW, I'm not complaining, the wine crew have done a fantasic job thus far!)
I hear a lot of talk about binary compatibility with Windows, but not so much about source-code-level compatibility. What sort of efforts, if any, are being made toward letting people trivially recompile existing Windows programs to run natively under Linux/X? Have any commercial software vendors considered taking this approach?
Once WINE gets to a point where it can run most all Windows applications and is usable to the average Windows user, do you believe that it will cause more users to migrate to Linux? Why or why not?
I have had some extensive use of both wine and VMWare, and to be perfectly honest have found wine to be lacking. I realise that, being free software, wine has certain economic & ( dare I say it ) "ideological" advantages, but for most of the programs for which I actually need windows compatibility, I find that it simply doesn't ( yet ) cut the mustard. Also, it seems that the approach you've taken for wine of mapping libraries to their linux equivalents rather than doing actual emulation produces a vast number of compatibility issues that need to be resolved, and keeps the advancement of the wine project very slow. Could you tell me what technical advantages wine will ultimately bring once its reached full compatibility with windows, as compared to a solution like vmware.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
One of the biggest setbacks I see in companies desires to embrace Linux is legacy applications. This has risen to be such a problem that Microsoft XP has 'compatibility mode' functionality to run these antiquated applications. Granted they probably should have gotton rid of that old cobol program years ago, but they use it today and they call it critical. If Linux can run their proprietary software, then they'll do it. But if not, then they'll have to keep their Windoze computers around. How is Linux going to compensate for this? I could understand if it was only a few programs... I'd hire some programmers, but try taking on like 20 to 30 thousand apps?
My question: I can see that security holes that come from Windows OS code shouldn't effect the CrossOver Office Win98-like implementation of the APIs. Security holes that come from the MS application's code may or may not be present in that environment, but how do I know? What types of MS security updates apply to my CrossOver environment, and which don't? Are any of the security houses (like e-Eye) testing for vulnerabilities in the Linux/CrossOver (or Linux/WINE) space?
As to those who ask "WHY?": I run Office 2000 and IE under Crossover Office on Mandreake 9.2.1 because many functions at work require the MS apps. Our test report is generated by a template and macros under Word 2000 that do not run under OpenOffice. Several secure web sites I have to access are not supported for any browser except IE. I can't change these things, but I have the freedom to not run Win2K for my desktop OS. So Crossover Office is a great solution for me.
Any technology distinguishable from magic is insufficiently advanced. - Geek's corollary to Clarke's law
Hi Jeremy. One of the advantages I don't see Wine exploiting is that Wine doesn't have any financial need to constantly force users to the latest and greatest version of Windows. Microsoft of course is happy to deprecate features, change APIs, and so on. Why doesn't Wine offer different codebases as different "versions" of Windows are needed?
I've seen some of this -- as I setup Wine, I can select what kind of Windows widgets I want to use (95 or 98). But I've also seen some apps work for a while and then stop working as the codebase is updated. If I were able to say "run my BG2 game as Win 98" and "run my Office XP as Win XP" and so on, I could end up with a Windows that is more powerful and more capable than Windows itself. And possibly more stable too, if I can match my software to the version of Windows that ran it best.
My Greasemonkey scripts for Digg &
What kind of percentage coverage of the complete Windows API do you currently have? Do you check? Are you actively trying to increase the coverage as an explicit goal?
I think Wine really needs a standerized unix deployment methodology. As of right now, Wine is "self contained". By that I mean, you usually install it in one place for one peice of software.
/usr/lib/win32, which contains win32 dlls. Software such as mplayer and friends can install their DLLs here, and reuse each others.
/usr/share/java containing .jar files, and Mono having a central place to put them, etc.
.Deb building) system into there current Windows build system.
We need a standard distro supported Wine layout, such as
Similar to Java
Doing this would reinforce the fact that Wine is just one more Unix subsystem, like Java, Mono, Perl, Python, and all the others. Commericial Windows developers, who want to distribute there software for Linux, can integrate such a package layout (RPM building,
I sort of envision this creating an easier division of logic for WineX and Crossover as well. It means the common components of each could be shared. WineHQ could provide the linker, loader, and base framework, as they do, and other projects like WineX, could just provide implementations of Microsoft DLLs, such as DirectX, etc. Intead of what they are doing now (complete forks).
Hmm. Food for thought.
A lot of us assume that older applications/games (those written for Win95/98) are easier for Wine to facilitate than newer ones (those for 2000/XP/.NET). Is this indeed true?
If so, how long do you think it will be before Wine has matured to the point that we finally catch up with Win95? That is to say, I can install Wine and be confident that 99% of the windows apps targetted for Win95 will just work with no fuss? Same question for Win98?
Would you consider working for Microsoft if they offered you a job.
Think like a man of action, act like a man of thought.
Why run Windows in Linux, when you can :((( ) serviced by WinXP...
run Linux in Windows.
http://www.colinux.org
I like it very much.
I can work in X session in Linux while playing
pinball and have my modem (strange Toshiba software modem, closed source
Works great!
Microsoft is, obviously, pushing .NET as hard as it can, making every effort to deploy it as widely as possible.
.NET" i.e. partially in Win32, partially in .NET ? Is there going to be lots of thunking between Wine and Mono, or is the Wine team going to attempt to get Microsoft's CIL interpreter and other tools running on Linux?
What is the Wine project's strategy for enabling compatibility with applications that are not "pure
Furthermore, what are the pros and cons of each approach?
Tired of FB/Google censorship? Visit UNCENSORED!
if linux keeps trying to run windows programs, it will always be lagging a little behind windows (the programs were written for windows). even if software comes out that lets you run windows programs in linux, microsoft will just react by making a new os that is even more convoluted and harder to emulate. what needs to happen is adding capabilities to linux that windows doesn't have. so people will think, hmm can't do this in windows, guess i'll use linux. i guess some can argue linux has stabilty and windows doesn't, but if you install windows2000 it's pretty stable out of the box, the instability in windows is caused by installing lots of programs.
Is there any talk with Rational, Segue, or another automated test tools vendor about recording/playback automated test using WINE as a target platform?
Windows vendors want delivery targets - not "date releases" of runtime platforms. I work in Software QA... you tell me you want the app certified on Windows XP SP1, Windows NT4 SP6a, and Windows 2000... I'll do it. Same with Windows 98, ME, and 95.
But you start talking about Linux, and then I have to ask which base distribution and which release of Wine.
The only way to know your application works in Linux + WINE is lots and lots of grueling, manual test effort.
Multiply this by the number of Linux distributions, versions, and that Wine is often distributed by "date releases" not "versions", and it is impossible to support.
The same can be said about Microsoft's systems... wierd things that crash on 98 but work on XP... BUT there are automated test tools. Record, edit, cleanup and you have an automated test library that can be run against every 32-bit Intel version of Windows.
There's no such support for WINE, and there's no developer incentive into manually auditing such a liquid platform.*
*(And that's not an insult.. I happen to think most of the innovation is happening on Linux, but my job's hard enough without putting extra hours testing a platform that won't make or break sales. Without real SQA certification tools, any sensible Technical Support manager won't touch WINE either.)
Do you expect WINE and Mono to move closer together or merge into one project when the next Windows OS ships with .NET as an integral part?
Because I have to use various Windows software in order to makea living, what I find myself doing is using SSH+XForwarding into my Linux machines, thus mooting the argument.
With Wine or VMWare or whatever, I take a pretty huge performance hit and have no guarantees that anything will actually work. By pulling my Linux apps onto my Windows desktop via X-Forwarding, I end up with a VERY powerful desktop where EVERYTHING works. I thus have ZERO use for any Windows binaries mucking up my Linux machines.
If efforts are made to maintain compatibility for older versions of Windows in WINE, is there a possibility that, in a few years, Linux will be more compatible with Windows95 and Windows98 than the latest versions of the Windows OS?
How has the switch to LGPL affected contributions to the project, both positively and negatively? When the switch happened, there was a lot of noise from groups like Transgaming who needed to license proprietary technology from third parties, and the formation of the ReWind project. Has there been a noticable effect on contributions to WINE from outside groups as result of the licensing change?
- Stealth Dave
Evil is as eval("does");
Xen allows a computer to run both Windows and Linux at the same time(similar to VM on mainframes. It has turned out to be quite a bit harder than we anticipated early on to get Wine running well than originally anticipated due to the host of undocumented features Microsoft uses. Xen on the other hand appears to have the blessing of Microsoft(at least for the time being). I suspect that Xen will be out first-and will mean that folks that have a machine with Windows already on it will be able to continue using Windows-with badly needed adult supervision. If properly handled, the net effect would be the same:
You'd be able to run windows programs from Linux and Linux programs from Windows(both running on the same machine). IMHO getting the installation really down right will be important here--but I think that Xen really does have the potential to get a much bigger chunk of existing windows users also running Xen.
I have a bosses that are old mainframe hacker-they really liked Xen when it was explained to them. I suspect this will catch on.
What about essential professional apps that aren't office productivity related? I'll use Architecture as an example, since I am most familiar with it. But I'm sure there are many other professional level applications that could serve equally well in this context.
Apparently it's going to be a good while before any of the standard CAD programs are ported to Linux. I know that CGI shops use custom programs for rendering and modeling on vast farms of Linux machines, so Linux must be up to the challenge.
Architects and engineers have to be able to send files around to collaborators at other firms, who must then be able to manipulate the original files (add plumbing systems to buildings, etc.) So compatibility with the software being run on Windows systems(and to a lesser extent Macs) is essential. Furthermore, in my experience the learning curve to gain proficiency in one of the major design tools is particularly steep relative to other programs, so re-training reasonably highly-paid users is an expesive proposition, which makes being able to run well-known, industry- standard programs is even more important.
Is there a critical mass of users needed to encourage the consideration of particular software by those of you writing emulators? Is there even awareness of the potential market for such products? (These are users who regularly spend $2,000 - $5,000 per seat for the priviledge of running specific programs, if that helps the financial end of the argument. They'll pay for software.) Do the intense video requirements of these programs just make them more difficult to run in emulation? Do firms like Autodesk and Graphisoft (who are particularly paranoid about piracy, due to the "high-margin/low-volume" nature of the market for professional CAD software) go out of their way to discourage interoperability? Is there something I'm missing?
Is there any value in Windows-apps-on-Linux solutions which force you to own a copy of Windows anyway?
Well, most people seem to see the main point of Win32-on-Linux as being a way to migrate step by step to a 100% Linux solution.
In that scenario, the person who wants to use the software already owns a Windows license, so there's no extra cost involved. If the Win32 layer, by requiring Windows libraries, can be more compatible than one which doesn't, then for such users the one which relies on Windows libraries is more useful.
That doesn't cover everyone's situation, sure, but it is a case where the concept is potentially valuable.
What are your opinions on the .Net platform, Microsoft's push of C#, and all these combined together that are in practice creating a new API for Windows Longhorn called WinFX? What will Wine and Codeweavers do when the new API replaces win32?
Also, as Wine is an implmentation of win32 API for x86, what will wine do now that Intel and AMD are both replacing this instruction set with the new AMD64? Is wine only going to rely on AMD64's ability to run x86 programs nativly? Or are there any plans to port wine to other platforms, namely AMD64 and IA-64?
--