Slashdot Mirror

I hear your frustration. You'd like Wine to work really well, and you are impatient with the current rate of progress. But implementing Win16/win32/win64 is a shitwad of work, so no matter how fast we go, you'll probably always be impatient. And so will I.

The best way to look at the current experimental DIB engine implementation is as a prototype. If apps work well enough with it, it'll be easier to commit the resources to do a production-quality one.

If patches are rejected, it means there's something wrong with them; good, persistant developers who listen to the feedback and submit small, incremental patches can get them accepted. It's true that it can be frustrating at times, but that's not unique to Wine; gcc and the linux kernel are also frustrating for new contributors. And don't even get me started about gibc :-)

http://www.englishbreakfastnetwork.org/krazy looks great, but a lot of its checks are for C++ specific issues, which Wine doesn't have because it's based on C. Wine is well aware of the benefits of automated testing and code analysis. We do have an automated build and test system, see http://test.winehq.org/ and we're slowly working on getting all the tests green. And we pay attention to Coverity's scans of our source tree. (We also have a patchwatcher, but it's out of action right now because I'm lame.)

If you want to go help raise funds from governmens stuck on win32, please do! I tried to make a little pitch for this at the end of my CeBIT talk last week, see http://kegel.com/cebit But it's hard to get their attention. First, they aren't impressed unless it can run all their apps, and second, the ones that are really serious about getting away from Windows tend to focus on native applications anyway.

So: the grapes really aren't that sour. Dive in and help - and be patient and persistent.

Working on it!

(Status: doesn't actually, er, compile as yet. And even if it did, the program launcher wouldn't work. But more people to at least solve the inability to compile would be most welcome. Current block: Cygwin's header files are on crack.)

Looks like wine already started

Wine since 1.1.14 is able of running IE7. You'll need a whole lot of hacks to make it work. Better just grab the latest PlayOnLinux as it has a script that will automate everything for you. I personally tested it, it works but crashes randomly and generally sluggish. Pretty much as it is in Windows.
http://appdb.winehq.org/objectManager.php?sClass=version&iId=4195

try looking here .

From the Wine homepage (http://www.winehq.org/history):

In March of 2002 a poll was conducted among both the free and commercial developers of Wine to see if there was interest in moving to a different license. Most developers did not want their code to be appropriated by a commercial entity and there were concerns that might happen. After much debate they chose the Lesser General Public License and on March 9th, 2002 the Wine source code became bound to those terms.

At this point, obviously Transgaming was no longer allowed to use new versions of Wine in a closed source product. But there is not necessarily personal hostility between the developers. I guess if Transgaming reconsider and make their product Open Source (preferably LGPL) too, Wine and Gedega could be merged again.

Clean, clear code is the best documentation.

Why write everything twice? The text version always falls out of date anyway.

http://source.winehq.org/ is the best Win32 documentation I know (providing what you are after has been implemented).

It's worth noting that the Windows x86 binary runs fine under Wine, and that's how I first played the game before buying it and running it on a Mac. A native Linux release is great news though.

Maybe YOU can't:

http://appdb.winehq.org/objectManager.php?sClass=version&iId=3498

Others have been quite successful.

The historical archives would be quite one-sided documenting only the neat and legal aspects, without including the surrounging context thrills of the game technology, including fumbling with config.sys, autoexec.bat, system.ini, winecfg, video drivers, directx, opengl, drm cracking, keygens, patched binares, virtual-to-real money scams, cheats, hacks, etc.

Hooray for the Application Database!

Really? No problems with those particular tasks? video problems due to Vista's design are well-known, as well as numerous other performance problems such as file copying while listening to music.

And what is RA3? Red Alert 3? If you're wanting to run a program designed for WINDOWS you need Wine installed first. Linux isn't Windows, which is apparently very hard for lots of people (like you) to understand. After that, you just pop the disc in, and install. You might consider playing a better programmed game, though... even under Windows, the entire C&C series network code and performance sucks balls.

but as for my computer, uh, let me know when i can play simcity 4 on it.

Sadly, I don't own the game so I can't verify, but a current version of WINE might be worth a shot. Judging by the reports you should expect at least some slight graphical glitching.

you mean this simcity 4?

Apparently you need a partial crack to run it, but that's true with many games on Linux because they usually have Windows specific CD/DVD protection that needs to be disabled (usually a no-CD file from some place like GameCopyWorld which removes or spoofs the protection checks). You can read about the legality of it there, but most people think it's legal to manually disable protection since you can legally do anything you want to your own copy.

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

Unless the status of "Garbage" means something other than what I think it means, there is no rejoicing yet.

--

And don't tell me to download Inkscape. I HAVE Inkscape. I USE Inkscape. I LIKE Inkscape. But it does not do some of the things that Illustrator does that I need to do.

Really, I don't care which is more efficient at booting or copying, if Ubuntu cannot run the software I want all of its performance benefits are lost

Rejoice!

I think you meant to link to: http://forum.winehq.org/viewtopic.php?t=3375

The list should be titled, "Apps That Wine Officially Supports." And it doesn't look good to have that list be so small.

No. That is a list of apps that officially support Wine.

The list you're looking for is located at http://appdb.winehq.org/

Furthermore, Wine is not an emulator. It implements Windows-specific API's so that that program can be run under Linux - x86 Linux. If the programmers are writing good code, it should run unmodified on Wine. Writing a program that implements an established API is not that hard. The problem is, software never works as intended, and programmers invariably make use of undefined behavior in the Windows API. The challenge of Wine is emulating this behavior. However, it is not a Windows emulator. It translates Windows API calls into Linux API calls.

Hell yeah! Join me in a game of Day of Defeat: Source. It should be pretty easy for me to chase you, since you'll be getting about only about 17 FPS.

Most software either has equivalents in the open-source world, or DOES work. What's your problem with that? It's not like the Windows API is something new.

As for games, why not check here?

One small Wine sub-project: contacting developers whose apps work perfectly under Wine and asking them to list Wine as a supported platform. Starting slow but getting there.

If you have Linux and Wine and buy games like the latest Price of Persia that have zero copy protection then there is nothing to fear ;)

It also comes with a torrent client that you can use to download the DRM-stripped games from http://thepiratebay.org/ that you can browse with the Firefox browser. You can also use that nifty browser to browse http://appdb.winehq.org/ catalog to see what games you should download for your Linux system ;).

WoW is rated Gold on WINE's app database. I suppose that counts for something...
http://appdb.winehq.org/

The program loader doesn't presently work, but I'm working on Wine for Windows! First step: get it to actually compile ...

I will say that although I have not had the joy of opening Office 2000 files with OO.o 3.0, I do recall there being some serious issues between powerpoint slides.

I've heard that about prior versions of OO.o, but I don't know if the same is true of 3.x. I have had problems with some older Word documents not showing some images when opened in OO.o, including 3.0. If your main concern is viewing or converting old files, why not keep Office 2000 around? What's the point of getting rid of it completely?

Just use OpenOffice.org to create all new or revised files, as they can be opened universally, in part because free ODF plug-ins and converters are everywhere. If you have an older file that needs a revision, convert it to an older or more consistent format (Office '95 and '97 formats work for me most of the time), and then open the converted file in OO.o, without losing any formatting or data. A variety of external or command-line format converters also exist, which are useful for batch converting legacy files.

I have several old copies of Office 2000 and 2003 floating around the office, mainly to convert between old file types ad-hoc. Microsoft also offers read-only Office document viewers and converters of their Office line, for free:

http://office.microsoft.com/en-us/downloads/HA010449811033.aspx

I think most of these tools, and some versions of the full MS Office Suites, also work on other OS platforms via WINE.

http://appdb.winehq.org/appview.php?appId=31
http://www.codeweavers.com/products/differences/

I regrettably give you the option of getting Novell's OO.o distribution (here) in which you can install an extension for OpenXML.

Why the regret? Novell maintains a good package of OpenOffice installers and extensions. There are also Open Source ODF and OpenXML converters:

http://sourceforge.net/projects/odf-converter

And OpenXML support comes with OpenOffice.org 3+ "out of the box":

http://blog.mypapit.net/2008/04/openofficeorg-30-supports-microsoft-openxml-docx.html

Going forward, the ability to convert almost every legacy document format that ever existed, to an International Standard like ODF, makes most file format differences a non-issue.

Not everyone has caught up with current standards, so we make it company policy to use ODF formats internally, but we convert files down to Office '97 or PDF when sharing them with external contacts. Everyone with any Office suite from the last 10 years can open our converted files without installations or issues.

WINE works for Steam stuff very well, though.

Nope. Probably have bought it if it worked better.

Linux users aren't out of the running completely. Silverlight runs on Wine. No idea if it runs on IE6 or if you have to use IEs4Linux to get IE7 on there.

We're working on a solution!

Wine is already a better "Windows" than Vista. I can't see Windows 7 being more backwards-compatible.

I'm downloading the beta right now. I want to see if I can compile Wine under Cygwin or Mingw on it, after all ...

Hey, perhaps Bill will get the bailout he asked for so American businesses can afford to buy it.

Bill: "It's all because people aren't confident to spend their money. In fact, they didn't start buying Vista in 2007 because they were expecting this even then. A subsidy to buy good, honest American computer operating systems is essential to the health of the economy, or my part of it anyway."

It's nice, and all, that you found a few games marked as "Gold" -- strange, however, that you decided not to mention any of the games I specifically named.

I didn't realise I had to however ok..

Age of Empires 3 - Gold rating
D&D Online - Platinum rating

I think I'll stick to the information I've received from the CGA club on campus

Blind leading the blind. Good luck with that.

It's nice, and all, that you found a few games marked as "Gold" -- strange, however, that you decided not to mention any of the games I specifically named.

I didn't realise I had to however ok..

Age of Empires 3 - Gold rating
D&D Online - Platinum rating

I think I'll stick to the information I've received from the CGA club on campus

Blind leading the blind. Good luck with that.

And yet, bug 6971 is still outstanding. It's the second highest voted bug on their bugzilla, and it's been open since 2006. They call it a "normal" severity bug, yet it clearly meets the definition for a "major" severity bug. That is: "Major loss of functionality for a wide range of applications." Just about every Unreal engine game is unplayable because of this bug. It was supposed to be fixed for 1.0, but it keeps getting deferred. I don't see why this isn't a higher priority for them. It obviously affects a lot of users, just look at all the duplicate bug reports for this one!

Which versions? Is there a tutorial on that?

Here you go.

Which versions? Is there a tutorial on that?

Here you go.

...why? Wine runs them decently (there are some bugs as you can read there. Nothing that couldn't be fixed with a bit more developer resources) well as it is. If those aren't good enough, there is always Cedega...

...why? Wine runs them decently (there are some bugs as you can read there. Nothing that couldn't be fixed with a bit more developer resources) well as it is. If those aren't good enough, there is always Cedega...

I assume you mean things like shared dlls.

And IPC. FYI, There is nothing inherently dangerous about sharing DLLs, that memory is either read-only or Copy-on-write. There is much less likely to be a bug in something as simple as shared memory handling code than a VM.

access to users documents, Direct X, OpenGL, screenshots (GIMP)

access to users documents: VMs don't give access to user documents or systemwide screenshots by default. This would lose much of the security of running a VM. Direct X, OpenGL: VMware includes experimental support for Direct3D video acceleration. This feature is not fully functional. Virtual box only supports OpenGL. As far as I know VirtualPC doesn't support either.

And it would STILL be more compatible than what we currently get passed off as "backward compatibility"

Really? Because even Wine offers much better support for gaming than any VM I have come across (which is all I use Vista for). I haven't had any trouble with backwards compatibility with Vista, except with device drivers, and the VMs aren't going to have much use for those. And I have continually hit bugs and limitations with every VM I have come across.

Which sounds more security to you?

Well, myself I'd pick an effective way of sandboxing applications without the overhead of a VM, and then sandbox everything whether it is 64bit or not.

Either you didn't read the entire post, you chose to ignore the part that explains why we would be better off memory wise,...

Maybe because the closest thing is an argument was

Literally at worst your XP application would require 3 gigs of ram. Now consider that you now have an OS that cleanly could access up to 16 exabytes of RAM, the memory limitation would be far worse on the 32 bit native than it would be on the clean 64-bit system running virtual machines as they could load more programs, and each program could have more memory than if it ran native on a 32-bit machine.

None of which explains how running 5 3gig VMs could be more memory efficient than running 32bit code directly on a 64bit kernel allocating only and exactly the memory it needs. And 5*3gig of memory is not all that cheap. Have you considered that it may be you who fails to understand? In any case, this thread has become more confrontational than interesting, and have little interest in spending more time on it.

Because as everybody knows Codeweavers fully supports FreeBSD 7.x, wait, you say that it's very early stages and doesn't actually run on any of the recent versions?

Although CodeWeavers doesn't officially support FeeeBSD, we are unofficially relatively active on the FreeBSD front. See bug 16023 for instance.

Interestingly, based on the wine-patches.tar.gz posted on Bordeaux's page, they don't use my work, which means they don't work on recent FreeBSD either (or the binaries they distribute don't match the source they publish which would be contrary to the LGPL).

Working on it!

I think that will suck unless you can kick Linux off the video hardware completely and let the guest Windows OS drive it directly.

Why? The video card doesn't care anymore than the CPU cares that Windows is running in a VM.

How do you think games work on Windows and Mac? Do you think the OS suspends itself while a game is running? How do you think running a game in windowed mode works?

Consider a DirectX game on Windows. It calls into a DirectX interface. The code it calls is provided by the graphics driver. It writes a few values into memory mapped registers on the card and returns. Like I said it is a very thin veneer over the hardware, only a few hundred instructions. The card goes to work. Any virtualisation, even trapping the port accesses and then letting them go ahead, will slow this down because adding a few hundred more instructions in such a performance sensitive spot is disasterous. This is the reason fullscreen Dos boxes in NT used to kick the OS off the card for performance. Basically the virtualisation layer, thin as it was crippled performance.

Any sort of virtualisation of DirectX will be painfully slow, and trying to emulate it on top of a OpenGL driver just seems doomed to bad performance.

Yet somehow it works for Wine, Cedega, and pretty much any port of a DirectX game to Mac OS X and Linux.

Yeah right. This is a much thicker virtualisation layer, for example it would need to translate DirectX shader language into OpenGL shader language, translate all the DX calls into equivalent OGL ones and so on.

And sure enough

http://appdb.winehq.org/objectManager.php?sClass=version&iId=13809
Linux: 2461 points (Vista: 4490 points)

Woohoo, I can run my games at half speed, low quality (No DX10/SM3) and have them crash or render badly occasionally. Given that modern games on an oldish system are a bit sluggish even in Windows, why would I want to do that?

So has anyone tried it yet? I was going to this weekend, but I got caught up in all sorts of pre-holiday preparations. I'll have plenty of time over the New Year to check it out though.

There's a whole pile of games that Wine won't play because of one measly little mouse bug. It will be great to finally have Aliens vs Predator working.

What are you talking about? VMWare does no such thing, there is no connection between vmware and wine whatsoever.

He's probably thinking of Parallels:

http://en.wikipedia.org/wiki/Parallels_Desktop_for_Mac#Wine_controversy
http://wiki.winehq.org/Parallels

OK, then anything listed as "Platinum" qualifies. Assuming they've been accurately classified by the people using them, anyway.

The page linked to is a directory of applications, and their level of compatibility. The appdb is not a binary "compatible"/"not compatible" list like I guess you want, and it also acts as a wish list.

You can find what you seem to be looking for here, though: http://appdb.winehq.org/objectManager.php?sClass=application&sTitle=Browse+Applications&iappVersion-ratingOp0=5&sappVersion-ratingData0=Platinum&sOrderBy=appName&bAscending=true

The page linked to from the summary is NOT a compatibility list, but a compatibility REQUEST list!

Photoshop CS3

Looking at the AppDB page, I'd suggest trying it on some distro other than Ubuntu. Although CS2 works better if that would be sufficient.

- Office 2007

I need those specific apps because those are the formats my peers and clients use.

Well, you can open .docx files as of OOo 3.0. Or maybe you could talk them into using Sun's ODF Plugin (It's a long shot, but I thought I'd throw that out there.)

- MSIE 6/7

IE6 runs, sure, but leaks memory like there's no tomorrow, so I have to kill -9 it after a few minutes lest I face a swap-spiral of doom.

IEsforLinux? Although it seems a little dead...

Eh, I don't see anything impressive about having a popularity contest either. More interesting is the list of applications that are actually supported, e.g. the productivity applications that work without any flaws.

I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.

* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential

Eh, I don't see anything impressive about having a popularity contest either. More interesting is the list of applications that are actually supported, e.g. the productivity applications that work without any flaws.

I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.

* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential

Eh, I don't see anything impressive about having a popularity contest either. More interesting is the list of applications that are actually supported, e.g. the productivity applications that work without any flaws.

I don't know what you mean by "Relax on APIs". However WineLibs makes porting applications to Linux much easier. Wine is Not an Emulator, it is a reimplementation of the Win32 libraries. This means that it need not be slower, and even though Wine is not fully optimized it is already faster than Windows XP in some areas. If your app doesn't just instantly work in Wine then you have found a bug in Wine*, you just have to fix or workaround that bug. Otherwise you'd have to change every part of your program.

* or you have found a buffer overrun that just happens not to be detected by Windows. Congratulations. Also tweaking the GUI a bit would help so it would fit in better, but not strictly speaking essential

http://wiki.winehq.org/Wine64 http://wiki.winehq.org/WineOn64bit

http://wiki.winehq.org/Wine64 http://wiki.winehq.org/WineOn64bit