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?
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?
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
Is there any value in Windows-apps-on-Linux solutions which force you to own a copy of Windows anyway?
Gerv
http://www.gerv.net
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?!
How easy is it for you to sleep at night knowing your job is dependant on Linux succeeding, yet MS software staying popular? You are living in a paradox of a job!
(This is supposed to be a joke, not to insult the guys)
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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...
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?
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...
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.
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?
How scary is Longhorn for WINE / CO? What problems does it introduce, if any?
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 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
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 &
Would you consider working for Microsoft if they offered you a job.
Think like a man of action, act like a man of thought.
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!
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?