Slashdot Mirror

Wine isn't an emulator. http://www.winehq.org/site/myths

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

where most = some

CS3 - no

GoogleTalk - no

CodeWarrior - no
.NET Framework - no

Visual Studio - no

Visual Studio .NET - no

I'm sure there are disks that are even beyond Disk Doctor, but I've had good luck rescuing 4 different disks that wouldn't even play on a computer (a Mac with iTunes in my case).

Having said that, importing to iTunes using the error correcting features of your CDROM would be my first recommendation. (Turn on error correction in the iTunes options (Advanced > Importing)....fyi, I think iTunes works in WINE/CrossOver, so use it that way if you don't have another good option for error correction and you're on Linux.) If it works and the errors are fixed, I'd still make sure you rip to a lossless format and burn a fresh hardcopy.

The Disk Doctor would be my second choice since it actually alters the disk. Having said that, I've had 100% success on the 4 attempts where I've used it to recover a CD. FYI, DD actually abrades the play-surface of the disk, so it will look aweful when it's done doing its thing. I guess to a laser it looks "good" though - at least better than a scratch. Again, I would rip to a lossless format and burn a new hardcopy if this works.

Hope you have good luck with it!
-Matt

get a Linux one and format c:

What's a 'c:'?

The Windows file system has up to twenty-six predefined mount points, named A: through Z:. The LSB file system used by GNU/Linux, on the other hand, has mount points named like folders in a single root: /mnt/cdrom. On a PC running GNU/Linux, the Wine subsystem translates between Windows and LSB mount points.

Unfortunately, the editor for it has 4 Garbages... I downloaded the editor in Windows last night so I could tinker with it in my free time.

Gets a Gold and a Platinum ratings. TF2 is a big-name app that the wine community really works on supporting. Took me 30 seconds to google "TF2 wine" and look at the results. Try it sometime ;)

When they really mean it video games will work well with wine.

According to the wine project the problem with osx is that apples X implementation is badly broken.
http://wiki.winehq.org/FAQ#head-4b564e8db73f20159168f50c44828fb684f21aaf

>when will a project similar to WINE come out for OSX?

You mean something like WINE?
http://www.winehq.org/
-Wine provides both a development toolkit for porting Windows source code to Unix -as well as a program loader, allowing many unmodified Windows programs to run on -x86-based Unixes, including Linux, FreeBSD, Mac OS X, and Solaris.

If I see a version number of 2.00, I can ASSume that there are significant changes from 1.X. Also, as an "ohoh" version, it's more likely to have bugs than 2.1.

Though there are exceptions, like Wine 1.0. If you were new to the Linux world you might have thought it was some fresh project, not one that had been in development for 15 years (current release 1.1.1)

Are there really any (non game) apps by anyone other than Microsoft that won't work on Linux or don't have any equivalent method in Linux?

Quicken is either Gold or Garbage under WINE, I can't tell which.

If you've already got 10 years of data including investment accounts, etc. then converting to another application is incredibly painful, if it's even possible. You can't get all your data extracted & converted perfectly.

So the answer to your question is...yes.

As I do not have network connection configured in Windows, no chance to try it now. Waiting for better release or at least wine-compatible version.

#1 Base Windows 7.0 on the Singularity OS project.

#2 Work with the WINE team to get 100% of the Vista and XP API calls supported under WINE, and port WINE to Singularity OS aka Windows 7.0 for legacy support.

#3 Profit.

Microsoft make sure to make royalty checks made out to Orion Blastar via Paypal to my email address for this idea. :)

Yeah but once WINE has 100% of the Vista and XP API calls support, why would we need Windows 7?

#1 Base Windows 7.0 on the Singularity OS project.

#2 Work with the WINE team to get 100% of the Vista and XP API calls supported under WINE, and port WINE to Singularity OS aka Windows 7.0 for legacy support.

#3 Profit.

Microsoft make sure to make royalty checks made out to Orion Blastar via Paypal to my email address for this idea. :)

Wine was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) do you still see the need for Wine?

Well, besides the purely practical reasons like: Wine is cheaper than paying for a VM application (some are free) plus a Windows license (never free), provides better performance (or should), is better integrated with your Linux environment, etc.

So besides these purely practical reasons, Wine is very important for the big picture: with Windows being on >90% of the computers, our society depends on Windows. Take away Windows and lots of things stop working (from travel agencies to airports and administration) until you can find a replacement. But there is no replacement because no other system is capable of running Windows applications. Wine is the only Windows replacement (ReactOS uses Wine), it is the only alternative supplier of a system that can run Windows applications. Thus, independently of practical aspects, Wine has a very high strategic importance for our society as a whole.

For more details, see Why Wine is so important.

The problem with OpenGL performance in WINE is that it runs on X11 (which is FUBAR too for some reasons, at least the one from Apple) and doesn't use the native Quartz driver.

It is in the works though (for more see the Quartz Driver page in the official WINE wiki. It isn't included yet in the official version of WINE, but you can find a guide on the page how to install it.

A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.

A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.

A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.

A few years ago Lionel and I wrote some debugging tutorials and docs. If you're curious try reading the developer cheatsheet, and tutorials on debugging Reason 3, PE Explorer, and Wild Metal Country.

Wine is just an API computability layer, whilst DOSbox is an actual emulator which emulates the actual CPU.

If you want to see how cross-architecture Wine is it can run on PPC Macs using Qemu: http://wiki.winehq.org/MacOSX/QemuWork

My one question is when or if Wine will include some means to configure the amount of RAM and HD sizes that are reported to running application, including Windows itself, given that legacy Windows versions can't handle more than 512 MB of reported system RAM. Pulling some memory modules or crippling the host OS don't seem to be very practical solutions to what I consider to be the one reason why I can't use Wine at the moment.

Yeah, you can use traces to show when it's trying to access a particular DLL.

You should probably stop by the forum with app-specific questions, devs there will suggest how to give enough info for a usable bug report.

Yeah, you can use traces to show when it's trying to access a particular DLL.

You should probably stop by the forum with app-specific questions, devs there will suggest how to give enough info for a usable bug report.

File more and clearer bugs and they'll have more to work with!

Per the FAQ, it'll leave Wine as the best way to run twenty years of Windows crapware. It's about the apps, not the platform.

You know, the official Wine page lists OS X specifically as a supported platform. If you want to get the dependencies (expat, freetype, fontforge, iconv, and so on) together for Wine you can build it yourself on OS X. Also, projects like MacPorts make it easy to build all kinds of free software. Personally, I like to just download a prebuilt binary of Darwine.

What were you saying about being available to OS X users?

Wine seems to making large improvements on ease of use in Linux desktops, especially with the simple installation afforded by package managers. However, installation of Wine on Mac OS X remains complicated.

Are there any efforts underway to simplify the use and installation of Wine on Mac OS X?

That's because Linux will most probably NEVER:

-Let me run my old PC games
-Let me run current PC games (without great hassle)
-Let me run applications specific to my line of work (3d studio max, maya, premiere, photoshop, and various game engines)

Actually, dosbox works in linux, and plays any of the old DOS games. Wine is a fantastic emulator...I was surprised the first time I ran Age of Empires on the tux.

Now that nVidia and ATI are beginning to actually support linux, some game companies are showing interest. First it's emulation, in a year or so we'll see native support...

It'll happen, we just need to get more people on it to increase actual demand.

You're right about MS domination of the market. Anyone I talk to has no concept of a world without Windows. I try to share the light as much as possible, but, for some reason, the dark is what makes people feel all warm and cozy.

I used to think wine was a useless project. Why would you want to run Windows programs when you have Linux. Now I see the wisdom of the wine developers.

Office works,You can run Everquest I and II in wine just fine. http://appdb.winehq.org/objectManager.php?sClass=version&iId=358

I think the turning point for me was when I installed the Windows version of Firefox so that I could run the .ica client for citrix on a diskless LTSP client. It worked. Flawlessly the first time. No install scripts, configuration tweaking or whatever. Run the installer and it works. The diskless client boots in seconds and If I can run Firefox and .ica client to remote desktop to a citrix server and access both my Outlook and my local files; if I can run Office natively and access my Exchange server, WTH do I need Windows for? Really, what? All of the clients work the same way -- install the app on my account and I can access the app from any of 50 clients.

I also used to be a big detractor of the server-centric thin client architecture. I was wrong. Have another look. Apparently the server-centric world is not dead yet.

I used to think wine was a useless project. Why would you want to run Windows programs when you have Linux. Now I see the wisdom of the wine developers.

Office works,You can run Everquest I and II in wine just fine. http://appdb.winehq.org/objectManager.php?sClass=version&iId=358

I think the turning point for me was when I installed the Windows version of Firefox so that I could run the .ica client for citrix on a diskless LTSP client. It worked. Flawlessly the first time. No install scripts, configuration tweaking or whatever. Run the installer and it works. The diskless client boots in seconds and If I can run Firefox and .ica client to remote desktop to a citrix server and access both my Outlook and my local files; if I can run Office natively and access my Exchange server, WTH do I need Windows for? Really, what? All of the clients work the same way -- install the app on my account and I can access the app from any of 50 clients.

I also used to be a big detractor of the server-centric thin client architecture. I was wrong. Have another look. Apparently the server-centric world is not dead yet.

Plus, Vista has such a stunningly _high_ appcompat rating percentage that Wine would "NEVER" be able to come even distantly close to this extraordinary amount of compatibility with Windows applications...

Now please let me go die in peace from my lethal sarcasm overdose...

From what I understand, you can do all of that stuff with VirtualBox (virtual machine), DOSBox (x86 emulator w/ DOS) and Wine (cross-platform implementation of the Windows API).

DOSBox takes care of basically every vintage game I've ever played and even though VirtualBox needs Windows installed in the virtual machine, it has a 'seamless' mode that allows you to have the Windows apps running 'outside' of the virtual machine. That's a sucky explanation and it'd be easier to explain if I had a pencil and paper.

Wine recently reached version 1.0 and, as I believe a sibling post pointed out, it should be able to run Photoshop perfectly well. The open source Windows project you mentioned, ReactOS, shares some of its code with Wine (which is how the two projects have managed to make some great advances in certain areas), so there's a nice little tie-in.

ReactOS is currently at about version 0.3.5, so we'll probably have to wait a while for a fully stable version to come out. The day it does will be a good day. A very good day.

Sure sounds like Wine's Win32 reimplementation to me. It tricks the games into thinking they are running on Windows.

If you look at faq

http://www.winehq.org/site/myths#slow

But as to the "it must emulate x86 instructions to run a Win32 application on x86 Linux" theory as someone once put it, "only an idiot would think that".

Mind you there is a flaw to Wine. Consider a DirectX game running on Windows. DirectX is thin veneer over the driver which is probably a thin veneer over the hardware. NVidia and ATI know that the biggest market for fast graphics cards in PCs is DirectX games on Windows. It makes sense to optimize their hardware for this - ideally the hardware should implement DirectX functions more or less directly. Abstraction layers cost time, and they want to get the best 3dMark200x score, not be 3D API independent.

Now run the same game on Wine. Wine needs to map DirectX to OpenGL. And at best call into the NVidia or ATI OpenGL accelerated binary driver. But if the hardware is basically implementing DirectX directly, the driver needs to map OpenGL back into DirectX before it can pass stuff to it. Note the worst case, where the users use the open source driver is worse than this, because that doesn't know enough about the hardware to accelerate things optimally.

ATI are planning to drop support for accelerated OpenGL on Windows as of Vista. Which makes you wonder how well future ATI hardware will support OpenGL

http://www.geekzone.co.nz/forums.asp?ForumId=46&TopicId=11123

I read that NVidia don't support accelerated OpenGL on Linux. So if you have a game running on Wine 3D won't be accelerated at all.

And Microsoft will obviously do everything it can to kill accelerated OpenGL partly because it makes things like Wine pointless.

"The Linux update system you are talking about is similar to Windows Update and Windows Update does not require "login/pass" to work.

Companies/Organisations typically use SMS and similar sort of update software in order to:
1) update THEIR own (custom, 3rd party) software, and
2) to have more control over it (less bandwidth used, updates only happen on known dates).

So in this case Linux wouldn't work so well either, they'd to do the same thing which could have similar problems username/password incorrect, repository pointed to out of date address etc."

two things with linux, a typical linux repository will have all the software you need, if not, the source is open, and you can contribute code to the community to implement features you need, so a repository is nothing like windows update, it's more like have a 50 DVD set of every software package imaginable, but you only download and install the ones you need.

if for whatever reason company deploying linux wants to use proprietary software, all they need to do is build their own repository, have a private key, and do exactly what winehq has done http://www.winehq.org/site/download-deb

only instead of posting the key on a webserver, the sysadmins manually install the key on every pc, or however you want to roll your own repository. Windows Update can't compare, to what a good repository system can do, and here you don't need a login/pass just a generic repository key, and all the code can be closed source even!

the best thing is that by rolling your own repository, you can mix n match open source with closed source, and create dependencies on existing Free open source software to cut your deployment time over a completely proprietary system.

Unfortunately Age of Conan does not yet work with Wine (at least not that I know of). According to winehq it's still garbage and there is an active thread over at ubuntuforums with people having no luck.

The Wine website has your answer.

It is actually listed under "Fun Projects" as "Almost Compiles" and "In Progress" (even though not updated for six years)
http://www.winehq.org/site/fun_projects#virtualization

because someone will surely remove your fingers for typing that question on /. instead of checking somewhere more appropriate...

Seems that, with some work, some other people got OfficeXP working a few years ago, I doubt its regressed since then since OfficeXP was on their 1.0 goals list if I recall correctly.

http://www.winehq.org/pipermail/wine-users/2006-February/020480.html

The use for 'binary emulator' in that statement is incorrect. As the grand parent post states, Wine Is Not an Emulator, which is where it gets its name from. Appearently they person who has added/editted the Synaptic package isn't really aware of what WINE really is. I have to fully agree with the parent post, as even though the text you posted is mostly correct, it is still wrong in at least one obvious way that makes many people still think 'emulator'.

Please read #1 on:

http://www.winehq.org/site/myths

And for anyone who still believes WINE is an emulator, please read #10 from the above URL. If you still don't believe it or don't understand #10, then call it what ever you want cause it doesn't matter to you anyway.

Do you post testing data and bugs? If you don't - well, thats the only way for them to really find out what doesn't work. That's all handled at http://appdb.winehq.org/

I've done some stuff before, and the issues actually got the attention they needed.

I find it a little disappointing that they couldn't fix bug #6971. That's a vast quantity of games that are unplayable because they won't warp the mouse from one side of the screen to another when it hits the edge. They won't even mark it as a high severity bug, even though it meets the qualifications (makes many applications unusable), it's one of the most duplicated bugs, and it's one of the most highly voted bugs.

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

OK, I'll bite, straight from the Synaptic package manager (and I think it's a pretty good explanation):

Microsoft Windows Compatibility Layer (Binary Emulator and Library)
Wine is a compatibility layer for running Windows applications on Linux.
Applications are run at full speed without the need of cpu emulation. Wine
does not require Microsoft Windows, however it can use native system dll
files in place of its own if they are available.

This package includes a program loader for running unmodified Windows executables
as well as the Wine project's free version of the Windows API for running programs
ported from Windows.

  Homepage: http://www.winehq.org/