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 have been the most major hurdles in your projects (both past and present)? How were they handled in the past?
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
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!
will there ever be the possibility to run the famous windows worms and virii in linux?
---
awake and alert!
-Penguin Mints
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?
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."
So at some point Linux will work on and with more old hardware than the newest versions of Windows.
And will be able to use Wine to run crusty old applications better than the newest versions of Windows. (Microsoft's biggest enemy to getting people to use its new products has for many years not been any other company but its own installed base.)
For people outside first world corporate IT departments that transition time when Linux appears more attractive will be sooner. How soon?
How do you expect the transition to desktop Linux to play out?
"Provided by the management for your protection."
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.
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?
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'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?
If Microsoft were to release more source code (legally, not the leaked source from a while back), or if Microsoft approached the Wine team and offered access to portions of the Windows source code, would you accept it? What if it involved an NDA or adding non-GPL portions to Wine?
SmashTech - No smashing of tech involved
Aren't you worried that you'll corrupt Linux with the viral Windows licensing scheme?
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 &
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.
CoLinux (the "Israel" link in the article) is for running Linux under Windows - not the other way around.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
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?
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");
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?
--