Slashdot Mirror

Someone claims it's working fine http://forum.winehq.org/viewtopic.php?t=9668

No status in WineHQ AppDB yet

http://appdb.winehq.org/objectManager.php?sClass=application&iId=12117

...this probably won't help Wine much. As this post explains http://www.winehq.org/pipermail/wine-devel/2010-September/086885.html : "IIRC, it's been discussed before, and it simply wouldn't work. D3D has too many ties to the Windows API that a non-Windows based implementation wouldn't be appropriate for Wine (try getting an HDC from a D3D resource, or passing an HWND to D3D). Gallium would have to substitute these for X11 resources, or custom resources that tie into X, so wouldn't reflect the Wine's internal state. Additionally, not all drivers will support Gallium (eg. nVidia binaries), so a D3D10->GL path will still be needed."

But what happens when Wine supports DirectX directly? Granted, it's a work in progress.

http://www.winehq.org/site/status/directx

I guess all the people on AppDB having problems are just stupid morons, then?

Windows will always run faster than Wine.

FTFY

Wine is a native client. Wine Is Not an Emulator. Performance is not a priority for Wine, so your point is clear... but your words are misguiding.

For example: http://appdb.winehq.org/objectManager.php?sClass=application&iId=623 and http://appdb.winehq.org/objectManager.php?sClass=version&iId=14305

These are the only reasons I am not a full time Ubuntu user.

I used to game a lot (mostly Unreal Tournament 2004), but not so much any more.

For example: http://appdb.winehq.org/objectManager.php?sClass=application&iId=623 and http://appdb.winehq.org/objectManager.php?sClass=version&iId=14305

These are the only reasons I am not a full time Ubuntu user.

I used to game a lot (mostly Unreal Tournament 2004), but not so much any more.

You call that a ridiculous wine bug? No, this:

http://bugs.winehq.org/show_bug.cgi?id=421

is a ridiculous wine bug.

Well, they could start by just applying patches that fix things and can't really break anything instead of referring to some hypothetically better solution for over a year.
See e.g. http://bugs.winehq.org/show_bug.cgi?id=8854
They still wait on some X extensions that maybe, if we are lucky, will be in some distros in a year... or two... or never.

I was going to place a statement in a similar vein. I hope he didn't have to replicate any work that Wine has already been successful in implementing.

I for one have been awaiting the day when free and non-free software could mix and mingle in a safe environment free from the nasty comments and glares of those who would have us stay separated..

They can - it's called WINE.

Sorry, not available on Windows :-p

Try installing one of the linux distros - they shouldn't be too hard to find. There's even one mentioned in the article summary (oops, my bad, I keep forgetting how many slashdotters don't RTFS, never mind RTFA).

http://wiki.winehq.org/Debunking_Wine_Myths

Then there's what everyone has been waiting for: 'I want to be able to run my x86 Windows applications on any processor architecture I like. That's the most complex one. Again the prerequisite is that Winelib works on this architecture, which will definitely happen someday. Then 'all that is needed' is to integrate an x86 emulator with Wine (and also change Wine's name :-)

But don't let facts stop you from trolling and talking out your ass.

Portal is not only proprietary, but requires a proprietary OS.

Last time I checked, the Source engine ran pretty well under Wine...
Sure enough, according to the AppDB, Portal has gotten a "platinum" rating in the last two entries. (Platinum is the best rating: it means the application works "out of the box", more or less.)
That page suggests setting the DirectX mode to 8.0, so you won't be getting all the eyecandy... But then, you're playing it for a class, not the eyecandy.

Agreed. I also have to add that I've been waiting for a new Age of Empires for ages now. What I saw there is a disappointment: It is made for the idiots that use the web. Why did we let them in anyway? The Web would be better if nearly everyone that uses new how it works -- that way, they'd probably value it.

I sincerely hope this fails on MS. I hope they go bankrupt on that service and go back to what they did well: Trying to innovate. Their best innovation was that of spreading Computer Access throughout the world, and I admire them for that. Other than that they're some crazy-assed monopolist sons-of-bitches. I hope everyone understands that -- and I hope everyone tries to contribute to Wine, so that we can free ourselves from those bastards. I can only point out that it's good they employ people, and I hope that, when this fails, said people continue employed.

You might want to submit your findings to Wine's AppDB instead ( http://appdb.winehq.org/ ). They keep a pretty good database of what works and what doesn't.

Oh ya.. and Windows 7 is a crappy OS that just happens to be less crappy than Vista.

As crappy as it is, it runs those applications that Wine and Darwine don't. Visual C# Express, for example, failed to install on Wine in this test report, and Xcode doesn't compile C#.

The fix for World of Warcraft under WINE made it into 2.6.35, though it is not mentioned in the changelist above. WoW 3.3.5 crashed under recent Linux kernels because it apparently made use of the "icebp" instruction, whatever that is; the kernel stopped sending SIGTRAP for icebp instructions in an earlier 2.6 build for whatever reason.

Diff of fix
Source code of file, showing the icebp fix merged in (search for "icebp")
WINE compat page

Emulation is no longer possible for new consoles. The last console for which a feasible emulator could exist (and in fact does) is probably the Wii.

That's silly. A single core of a 3 GHz i7 is already several times faster than a single core of a 3 GHz Pentium 4.

Emulation of a serial instruction stream cannot be parallelized in software.

This is incorrect. Not only is it incorrect, but almost every x86 chip produced this century will prove you wrong. See speculative execution and out of order execution, for example.

Emulation requires that the emulating machine be several times faster than the emulated machine, because there is effort required in translating the original assembly code to the target processor's code.

Direct emulation of the hardware isn't the only option. You can also reimplement the API(s) provided by the console, for which there need not be any noteworthy processing overhead. This is the approach that Wine uses. Of course, this is generally a more labour intensive approach, but for a static API, far from unattainable.

As an example, most users would try Wine once (at most) and then never want to use it again because it isn't exactly the same as what they are used to.

What in God's name are you *BLABBERING* on about, man? Do you actually know what WINE *IS*???

The *WHOLE PURPOSE* of WINE is to make Linux *MORE COMFORTABLE* to people who like certain games & apps on Windows by letting them run them on Linux.

Where do you get this idea that "most users would try Wine once"? There's a perfectly good WINE Application Database that pretty much tells you the chances of getting your app or game running in the first place, and how to set it up.

Why do you fanbois *CONSTANTLY* make these sweeping statements that have no substance in fact & just glaringly indicate how little you actually *KNOW* about the subject in the first place?

Please... go and be happy with your easy-to-use Apple computers but don't then pretend that being an Apple user makes you some kind of all-knowing computer authority because it clearly does not.

The two main bullet points for windows:

* You are already using WINDOWS programs (e.g. Microsoft Office, ITunes etc) and want to continue using them
* You are familiar with WINDOWS and do not want to learn new programs for email, word processing etc

Wine, anyone? Warning: Wine may not run bloatware crap like iTunes.
If you really can't let go of your bloatware, I recommend VirtualBox.

Really? in my experience nearly all mentions of Wine are along the lines of "hey, it's fairly hit-or-miss but perhaps Wine can help you, give it a try" rather than "use Wine, it can run every Windows app flawlessly!". Hell, even Wine's own website states that it doesn't run everything so where you got the hype from I have no idea.

And in Wine's favor, my experience with them have been that nearly all apps either work out-of-the-box or don't at all. The ones that work-but-require-a-day-of-editing-config-files are more of a rarity that can be safely ignored by normal people since that issue will most likely be fixed by next version anyways. And if you absolutely *need* some specific app right here right now, well, you should've used VirtualBox to begin with.

For example I was trying to move to a Linux desktop at work, to learn more about Linux and its working in our setup. However, being work, I had to be able to get everything done. So I tried Linux AV software and it was crap, couldn't do what I needed to do. I went and asked our Linux head if he'd be willing to help see if Wine could run Sony Vegas. He said sure. After 3 days of fairly intense work and research, he said no, he could find no way to make it run. He was pretty good too, he didn't blow this off he really tried.

The best place to check is the WineHQ application compatibility database. It'd have told your sysadmin in much less than three days that people have gotten it to run but "Installing this was a mission though." and the best anyone's been able to give it a silver rating. The last test report is from almost a year ago though, it'd be very nice if your sysadmin took five minutes to write up a test report to tell others what he found. Anything less than a gold rating should not be used in a production environment, and even then I'd read the notes to see if it's gold because of functionality flaws or installation complications (to get a platinum rating the application must install without special configuration).

One valuable aspect of Wine, particular the major releases like 1.2, is that it provides an API that developers can target to easily create Linux versions of their Windows programs. As nice as it would be if developers would make a fully native port of their application for Linux, it's often more practical to get something that works passably by tweaking an existing program to work with Wine. Sometimes these can even be compiled against Winelib to create an ELF binary.

You think you're joking ...

It's happening. You can actually somewhat use wine on windows. http://wiki.winehq.org/WineOnWindows

>> ubuntu, arguably the most advanced desktop linux, won't play DVDs

Linux won't play DVDs (until you simply install a package) for the same reason Win7 won't play Blu-rays out of the box: Licensing. It has nothing to do with how advanced the OS is.

>> if you are anything more than a flash gamer, linux is out.

No, Linux is only out if you want immediate access to the latest cutting-edge Windows-only game. It's perfectly fine for playing the dozens of games that have native ports (Urban Terror, World of Goo, Nexuiz, Warsow, Second Life, etc.), and many Windows games...

http://www.codeweavers.com/products/cxgames
http://appdb.winehq.org/
http://www.cedega.com/

I played EverQuest and World of Warcraft from it for years.

>> the only way to play netflix on linux is by running it in a windows VM.

Just another great reason to boycott NetFlix. Seriously - who doesn't have on-demand movies assailing them from a half-dozen directions nowadays. I spend most of my time catching up on old series via Linux with XBMC or Boxee.

>> no itunes.

It used to work under Wine, but I don't think anyone cares about it anymore since there are multiple alternatives that works natively with Linux (or any OS with a web browser). I use Amarok every day and don't miss iTunes at all.

That would be http://winehq.org/

Your site is about actual drinkable wine.

Xorg became almost mindless to get configured. Just run xorgconfig, and let it do it's thing. Ok, so it's not well documented, or at least I don't read the documentation.

I was having an argument at one job, where they were very insistent that they *MUST* run a Redhat derivative. I was working on one specific machine, so it wasn't just identical hardware, it was the same machine. I found it I installed various verions of Redhat, Fedora, CentOS, and Slackware. Slackware performed like a champ. The others, not so well. Each had it's own fatal problem. Some couldn't see the network card, and no loadable module would make it work, so I added a second card when running that one. Some couldn't get into X at all, insisting the video card didn't exit. For them, I had made a backup of my xorg.conf, so I could copy it back in. Different problems came up with our own application, which was the purpose of the machine. I put Slackware on, when they were finally desperate for a solution. Slackware picked up all the devices properly, and went into X, just as it was told to.

I'm a strong believer in building kernels specifically for the machine that's in use. I don't want extra drivers. I don't want loadable kernel modules. If the hardware exists, it'll exist. Build it all in, and leave out the fluff. It cuts down the kernel build time dramatically, and improves the performance of the machine. Oh, I didn't mention, building your own kernel may as well have been a moral sin. The guy in charge of the department {sigh} once tried to build a kernel, and it didn't work. Ever since then, customized kernels were against company policy.

Most of my laptops get the dual-boot treatment. If I'm on the road, and must run a Windows app, I can boot into Windows. That's for silly things like cell modems who don't want to activate on anything but Windows, and for the occasional "But it doesn't work under MSIE" complaint, so I can bring it up in Windows and verify that they were stupid.

I've only had one laptop that didn't perform very well under Linux. There was some funky software control for the wireless network card, where the card would be seen, and an IP could be statically set on it, but there was a soft button that enabled the antenna. I didn't find a physical reason for it, so it's something they put in the card.

I know we've come a long way with Linux. There's really no messing around with every driver, trying to get sound, graphic mode video, etc, up. Usually, a generic install will make everything work fine. I remember the "good old days", when once you got Linux installed, you were trying to figure out what drivers would support your hardware

On my current laptop, an Acer Aspire 5532, there's something funky with the touchpad mouse. It doesn't accept clicks on the pad. You have to reach down, and click the physical mouse buttons. That's no show stopper. It's a known bug with these specific touchpads. The damned thing doesn't work very well under Windows either, so I use a wireless USB mouse most of the time. I can't complain much, it was a $350 laptop, and works very nicely.

My home machine dual boots (Slackware64 13.0 and Windows 7 Ultimate). I've had several instances so far where Windows messes up and doesn't want to boot. I can go into Linux and everything is fine. I have to dual boot it though. There's one game, Stargate Resistance (Wine info says it won't work) that I need Windows to play. Even then, it won't play for more than a few minutes on an ATI video card. With a Nvidia card, it plays fine, but there's a bug in the Win7 x64 driver so even Windows will randomly crash. Nice, huh? So, when I want to do something, and keep doing it, I do it under Linux. When I want to play the game, I play under Windows un

According to WineHQ's App Database, Warcraft3: Frozen Throne runs perfectly on Linux.

Where can I get my copy of Duke Nukem Forever?

I downloaded MOO 1 and 2 through GOG. I ran the installer via WINE, then copied the files and ran them with linux dosbox. GOG supports MOO 1 and 2 in windows via dosbox, so I only needed WINE to extract the archive, and then run as I see fit in Linux.

Any DOS game that GOG supports would probably run the same way. I'd check the DOSBOX compatibility table first: http://www.dosbox.com/comp_list.php?letter=a and if you want to check WINE compatibility with your GOG windows only game, you can check it here: http://appdb.winehq.org/

Why not? There's a decent chance it will work under Wine!

Wine still can't run Myst...

Wine support has always been spotty. And it's 2010 now -- Wine support is probably going to continue to be spotty for a long while yet, if not 'forever' in terms of people still wanting to run Win apps on Linux. If Wine works for an app you want, that's terrific and do let people know, but please don't go saying you're "sure" Wine will run somebody's apps. That just causes false hopes that'll be dashed, and then they'll eye-roll for all the other open-source advantages you and others spout after.

ooh, wine on windows + IEs4Linux

No, that is part of the usual Mornington Crescent game. New arguments get invented and the goal post is moved. Max did play according to the rules, tried to satisfy all requests.

The best we have so far is "DIB engine should be integrated into GDI32". This is not a problem, because both Max and AJ share this goal, but if I understand correctly, Max doesn't want to invest the effort (which is a lot) until the current design is validated by inclusion into upstream source.

Asshole! The point is of course that Ben Klein is also no authorative source, because the master has no time to speak his mind. So everyone keeps guessing. What about simple commercial interests or incompetence?

Read the history and read bug 421. There is no way for an inclusion of any DIB engine. When all requirements are satisfied new requirements will be made up.

Hi, i just tested two games with safedisc in wine-1.1.13 and none of these
complained "put the original CD into CD-ROM!" I tested:


* Need for Speed Underground 1 ~ safedisk 2.90.040

* Need for Speed Underground 2 ~ safedisk 3.20.030


So it looks like safedisc support is implemented very well.

Must not have sabotaged it very well if it's working...

Here is a good explanation of why the DIB engine isn't integrated yet:
http://www.winehq.org/pipermail/wine-devel/2009-May/076044.html
In the future, do some research on the topics you complain about.

Note that MSDN is frequently a tissue of lies and only useful for vague guidance rather than as any sort of reliable source - so Wine development these days is mostly test-driven, such that Wine aims to give the same results on the project's tests that it does on Windows. There's even a testbot to automatically run new tests against a pile of VM installations of original Windows.

Wine is also available for Mac OS X.

Well, actually the Wine project management sabotages progress on key projects, e.g. Saferdisc protection and DIB Engine.

Well, actually the Wine project management sabotages progress on key projects, e.g. Saferdisc protection and DIB Engine.

It seems to me that the wine development process does not really scale well but they use also test based development and that seems to speed up the development cycle. Other aspects like the Dib Engine are a governance nightmare of Wine. Though the patch is optional (has to be enabled) they didn't let it in although it supports some applications better and was a release target for 1.2. The Wine project management played Mornington Crescent with contributers for the DIB Engine for almost 10 years. It is a pity that no one ever started to fork Wine and improve project management.

My god, Wine has no use whatsoever

not very well
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5880
http://appdb.winehq.org/objectManager.php?sClass=version&iId=10107

And yes I got the joke :)

not very well
http://appdb.winehq.org/objectManager.php?sClass=application&iId=5880
http://appdb.winehq.org/objectManager.php?sClass=version&iId=10107

And yes I got the joke :)

It's even funnier if you consider the option of running WINE on Windows: http://wiki.winehq.org/WineOnWindows

I know, I was referring to the same line Wine folks have been saying, and the recursive acronym (Wine Is Not an Emulator).

* frowns at emulator tag *

Linux + Wine

I think Vista is pretty ok, in particular when you compare it to the current Wine implementation of the Windows API or the early KDE 4. E.g. the VISTA panel never crashes while it occasionally happens to Plasma.

Do you also develop for linux? with your freedom stance.. I would think you do.. if so how do you explain the packaging requirements for the various distros? do you write only simple command line tools that say "I AM GREAT YOU ARE SUCK DONT BUY CLOSED PRODUCTS" and package them only as source?

Because if you do anything.. on any other platform.. like it or not you are buying in to the quirks and rules of a given system.. Clearly linux should support DirectX right?

There's actually a project seeking to provide exactly that...

To use a non-car analogy, Apple's position on Flash would be like Microsoft declaring that, even if someone took the time to write a compatibility layer to allow Mac apps to run natively on Windows, its use would be forbidden...

I can appreciate the arguments for why Apple's behavior isn't "wrong" - though personally I don't like what they're doing one bit. For this reason I mostly stay out of this discussion. I hate what they're doing, but I don't know that it's wrong. People can do things that are entirely within their rights and it can still be a shitty thing to do, you know?

http://appdb.winehq.org/appview.php?iVersionId=49