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.
Why not just give up on life and never attempt to improve anything, right?
Like Word Perfect? Shoulda realized you were a troll. I'm sorry I bit on that crap.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Agreed. And you missed one argument: Sometimes there is no FS/OS version. I had to translate a Quark document to text at work. I run FreeBSD (yes,yes, FBSD is dead, yada yada...). Anyway, there was no way to translate Quark to anything else that would run on *BSD or Linux. One script which was horribly broken, that's it. In the end, I ahd a coworker with an MS desktop download the demo version of Quark to convert the files. Yet one more reason windows emulation is not a bad idea.
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
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.
Unfortunately, a lot of titles use the old WinG API's (for cartoon animation) which to the best of my knowledge are not supported under WINE.
There are various games which run considerably better under WineX than under native Windows on some peoples machines. The nVidia 3d drivers are excellent. I won't comment on the ATi ones. And the DRI ones are just laughable.
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.
Speak for yourself. Some of "us" Slashdot readers don't expect Microsoft to stand in the way of WINE at all. After all, they couldn't stop DR-DOS or PC DOS or Pro DOS. And they didn't stand in the way of VirtualPC or VMWare.
As for breaking WINE -- well, Microsoft would be hard pressed to change their APIs in such a way that would break WINE, but that wouldn't break third party applications. The last thing Microsoft wants to do is to further annoy third part devs who have enough trouble with service packs already.
Incidentally, poking the WinAPI shouldn't be that big a deal considering how much work us third party Windows developers have already done to catalogue it. It is a popular Slashdot myth that nobody knows how Windows works. In reality, it's more the Linux/BSD situation that you think. There are a FEW developers who know how EVERYTHING in Windows works and (more importantly) what doesn't. But almost everybody knows a couple of API tricks. By this point, the whole API has been traversed and documented -- check out sites like allapi.net or dotnet247 for decent free info on the APIs and their side effects, and sites like SysInternals for tools to uncover the "secret world" of your Windows kernel. Process Explorer alone is a godsend...it's like a really handy GUI front end to grep, ps, and kill on Linux/UN*X with the ability to remove file, process and registry handles without (necessarily) crashing the program that opened them.
Hey freaks: now you're ju
www.transgaming.com
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)
>What sort of efforts, if any, are being made toward letting people trivially recompile existing Windows programs to run natively under Linux/X?
:)
WineLib.
Thanks for playing
Tell them to grow up.
Why? Because unless you are prepared to write better (and unencumbered) documentation for each API, no one is going to bother to read it. After all, why should they when DevStudio offers all the help they need just by pressing F1?
And even if they did read it, it still wouldn't do much good since most software is written against ATL or MFC, or in a language that doesn't even hit Win32 directly. Not to mention that WINE would still have to support the 'broken' Win32 API anyway in order to run the tens of thousands of apps that already work out there.
In short this is a waste of time. A better approach would be to produce some porting tools to help people move their Win32 apps and build them natively using Linux using the WINE lib. That means scripts to turn nmake files into gmake files, wrappers for cl.exe, open source versions of libraries such as MFC & ATL. These libs alone are the biggest impediment to moving source code over at this time. It would non trivial to replicate to be sure, but necessary for a lot of code to move across. Even half implementations that did the more common classes (CString, CWnd, CWindow, CComObject, CDialog, CComPtr, CComBSTR etc.) would be very useful for a lot of projects.
The questions are still valid. I don't think the poster was looking to stir up a lynch mob, but to ask what his opinions are regarding folks who do such things and what should be done to curtail such activities.
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
Perhaps the story contributer could clarify why he thinks Ignalum is claiming MSWindows runtime compatability?
"values of beta will give rise to dom!"
That doesn't mean its a ripoff.
Care to explain why not?
Same directory/file names? References given the same names as well? Known bugs reproduced *exactly*? Sheesh, you're sounding more like the CEO trying desperately to defend his innocence, even though it's plainly obvious that the applications are one and the same.
Get a clue.
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.
You MUST be kidding about Remote Desktop. It often (between my XP Home desktop at home and my PX Pro desk at work, or from that work desktop to my Win2K and Win2K3 servers) stops working, crashes on the client desktop. X is *much* faster than Remote Desktop, but it doesn't do sound. And X is native - Remote Desktop is a MS hack onto their video system - try playing a game (even Spider) on it. *shudder*. VNC isn't any better, but still..
Define sqrt(x) as something really evil like (x / rand()), and bury it deep in a shared include somewhere.
I'd be surprised if this makes the interview given that CrossOver 3 is OUT TOMORROW and yes Microsoft Money does start and appears to be usable. We only got Money starting at the last minute though, so it might still be rather buggy - why not download the demo when available and find out?
Hate to burst your bubble but the newer versions of windows don't use FAT32 filesystem. They use NTFS.
Creative Demolition