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.
I think I can answer this one at least in part and I doubt it will make the list. So, allow me.
The largest part of the educational multimedia market uses software built with either Macromedia Director or Authorware or some other very high level authoring system as opposed to C++. This is because typically these applications are heavy on realtively simple mulitmedia interactions and light on intensive computing that requires stramlined code.
For the most part, these systems do already work quite flawlessly under Wine. I've developed a few of these type apps and I used to go to the Marcomedia corporate newsgroups and harrangue then to come out with a GNU/Linux run-time so educational authors could create native GNU/Linux apps in addition to Windows and Mac. But then Wine came out and I discovered that not only did my own apps, but several dozen other Macromedia based apps I tried all worked under Wine. Not only that, the authoring environment itself works under Wine. And that was at least four years ago. Probably more like six.
Since then, I've assisted a number of teachers who simply assumed that their apps wouldn't work under Wine to make them work. In every case what I have found is that Wine already did work, but the real problem was the teacher in question didn't understand how Wine worked and how to setup the fake_Windows directory. So, it's not really a Wine problem as much as a lack of familiarity with the Linux filesystem among those people who would be responsible for making the switch, ie teachers.
I don't know the Reader Rabbit series per se, but I do know that the average public school in California and Colorado where I have had direct experience in such things has purchased a copy of Macromedia Authorware for just about every single staff and the janitors too in hopes that they would take a crack at putting some multimedia lessons together and very very few of them have. However, there are a number of existing and many many bankrupt companies that devoted themselves to producing these type of titles and since they all use similar run-times which use only a limited subset of the Windows API that was supported in Wine a long time ago, the chances are your app quite likely might already work.
Direct3D games probably never will be as fast on Linux as they are on Windoze. It simply because the native API on Linux is OpenGL, and every call has to be "translated" from D3D to OpenGL. 3D Sound and other arcane features still have issues under Linux, but straight OpenGL + Stereo Sound should perform as well as it does on Windows.
The filesystem has about nothing to do with game performance, as any game with a chance to run fluently has to keep most of its data cached in RAM.
Are you using Wine, or WineX?
:-)
Just the latest WINE build.
Any tricks you'd like to share to get it working?
When I first tried running it, the window border showed up in fullscreen. This prevented input from being handled correctly. The problem seemed to have cleared up after the next reboot. No idea why. *shrug*
It was actually a rather funny story. You see, I had installed WINE because Sun suggests it for running programs that the Java Desktop System does not yet have support for. I then left JDS running while I went to work. A few hours later, my wife calls and asks how to get Blue's Clues running on JDS (despite a previous offer for her to reboot into Windows at any time). I thought about it a moment and had her double-click on the CD. She found the EXE file and ran it. To my complete shock and surprise, it ran! (Albeit with the previously described issue.)
Later that night I came home, rebooted to JDS, and tried Blue's Clues again. That time it worked without any problems. Pretty simple, actually.
Just remember to associate EXE files with the WINE executable, and you should be fine.
Javascript + Nintendo DSi = DSiCade
Yes, with respect to the filesystem, wine is probably faster. But for games, this is not the most significant thing.
Most windows games use DirectX for graphics. DirectX is an API, i.e. a set of standard commands programs use. Most graphics cards provide a DirectX driver, so DirectX calls usually exploit the capabilities graphics card as much as possible.
Wine emulates DirectX through OpenGL, which is a different API. This makes for bottlenecks in several ways:
Firstly, the DirectX calls have to be 'translated' into OpenGL ones. That takes some time.
Secondly, there is the OpenGL driver.
OpenGL is unfortunately not as well supported as DirectX by card makers. This means that the capabilities of the card may not be as well exploited, and that some things that could've been done in hardware are performed more slowly in software.
The second bottleneck is the bigger of the two, and there isn't much the Wine team can do about it, except hope that the card makers get better at supporting OpenGL. Nvidia is known for some pretty good work.
The first bottleneck is more directly related to Wine, but that overhead is the smaller of the two.
I'm not certain if you should expect Wine to ever run at the speed of windows, even if it is not impossible. But after all, you are adding another layer between your program and the OS.
But as processors get faster, and games continue to utilize as much of it as possible, you could expect this second bottleneck to get less and less significant, since its size is relatively constant.
(The amount of computation increases faster than the number of system calls)
Perhaps the story contributer could clarify why he thinks Ignalum is claiming MSWindows runtime compatability?
"values of beta will give rise to dom!"
What does Windzoze really lack? Try a fork(), proper pipes, a proper shell (or several), multiple virtual terminals, a protocol like X which can be sent across a network tolerably well, the ability to at least read foreign file systems, a way of shutting down not involving a START button, journalling filesystems, a choice of window manager,............
You have to be joking!! Of all the things you asked for, you could have asked for things windows doesn't do well
Anyway, thats not the point there are a lot of things wrong with windows, you just need to (install XP/2003) educate yourself so you don't sound like an idiot and name a bunch of things that are accually better on Windows.