Slashdot Mirror

Not that this really hurts your argument (as setting up wine is not a newb-friendly task), but windows solitaire and oregon trail both run on linux under wine. I play lots of classic games with wine, check it out.

While listening to the wineconf presentations I heard one guy talking about a scheme using goto statements.

Hmmm.. A package that would allow Linux to run Win32 binaries? So, something that's not an emulator, but translates application's system calls from Win32 libraries to Linux libraries? I've even got a great recursive acronym for it! WINE is Not an Emulator!

Then there are the class libraries, which have sprawled to a massive scale, and in comparison make implementing the JVM look easy. Look at Wine, which still isn't an alternative for Win32 (only selected applications are supported), after years and years of work. Or Mono, which cannot and probably never will run arbitrary .Net apps.

Read http://winehq.org/?issue=272

We were at the conf.

-sedwards

You need this: http://www.winehq.org/

...although I don't want to do anything illegal. So I hack on wine http://www.winehq.org/ instead.

The problem is simply that binary compatibility is hard.

Hell, if you run WINE you can run Windows applications from about 10 years ago on your Linux system, while you can't even say that for native Linux applications, Wine included.

There's no point talking "Linux desktop" with this problem still around... it's simply more economical for people to buy Windows knowing they'll still be able to use it with all new applications 5 years from now.

Even if every member of RH Engineering (~100 people a few years ago, more now) had worked on the distro, so what? Debian has nearly 1000 developers!

Even though the Inkscape package is a version old, I think it's still very valuable to have. I know that I can install Inkscape and it will work. I don't think that the few extra features that are developed in six months time are worth sacrificing stability and reliability.

One thing I've seen Debian supporters say more and more often lately is that it's OK that Debian Stable is old, because when you're working you need stability. Fine. But the "stable" in Debian stable does not refer to the software. It refers to the behaviour of apt. There are lots of bugs in old versions of Mozilla etc shipping in Woody which were fixed in later versions.

All distributions do is take free software and put it together in a package that works.

No, this is what Debian does. Other distributions like Fedora or Xandros take free software, integrate it, improve it, and produce an installable operating system out of it. Yes a lot of this work involves packaging, but other parts involve writing new software, working on things upstream. Distributions are useful because they are a grounding point at which you can tie together all the loose ends that otherwise might not be connected by upstream projects. It lets you take a look at the Big Picture and work on new things relative to that.

When there are problems with a program, you go to the distro first. They figure out what's wrong, and either fix it or notify upstream if that's where the problem is.

No, no they don't. I know this is what is supposed to happen, but it doesn't. Instead end users who can't tell the difference between broken software and broken packages report it upstream.

In this utopian vision where everybody uses free software, where everybody uses Debian, where nobody reports bugs to upstream etc, this ideal might stand a chance of working. But we don't live in anything even resembling an approximation of this world. Instead of trying to control everything and constantly having the details slip through your fingers, it's better to provide the land on which others can build their houses and let the free market take care of the rest.

Then you may be interested to know that World of Warcraft works quite well in Wine.

Then you may be interested to know that World of Warcraft works quite well in Wine.

That's the whole purpose of Wine, to provide an open implementation of the entire Win32 API for *nix, so that unmodified Win32 binaries can run on *nix without emulation.

goto wine, if you still having problems I'm sure you can find someone who will fix them for a few dollars.

What do you do when you have problems with you car? or anything else for that matter.

http://bugs.winehq.org/show_bug.cgi?id=2685 I tried the following a few months ago then submitted the bug: wine termsrv.exe It failed because the termsrv program is Win2KServer or WinXPserver. Wine doesn't supply those Windows Version types to the program so the Windows termsrv program refuses to run. I was trying to run Wine using termsrv.exe because it would get around the various slow display emulations and bugs that mapping windows display actions into X commands run into. Then I could have all my windows programs on a linux server providing RDP without needing reverse engineered display mappings. Also, if it had worked, one could run it off of LOCALHOST giving flawless display in X. Maybe I need to debug the Win2KServer to see what the code is and hardcode it into a version of wine. That said I just took the easy course and run wine as an X-task from the server and deal with the failures and crashes.

You know, "Wine Is Not An Emulator" WINE? Copy over a few of the files off an old Windows 98 CD + some fonts 'n' libraries and you can be playing "World of Warcraft", "Half-Life 2", "GTA: San Andreas", or whatever else you'd like. And if that fails, just get Cedega for $5. They're for linux, but they work just as well on a Mac. I know, I've tried.

Just use the real Wine or, if you want to pay money, CrossOver.

Proxomitron also runs under wine just fine. http://appdb.winehq.org/appview.php?appId=39

Well, almost completed, anyway. If you look at the , you will see they aren't quite there.

However, massive amounts of work have been done over the last six months, and I think the next six months will bring some very exciting things for the Wine community.

2.2. Does Wine emulate a full computer?

No, as the name says, Wine Is Not a (CPU) Emulator. Wine just provides the Windows API. This means that you will need an x86-compatible processor to run an x86 Windows application, for instance from Intel or AMD. The advantage is that, unlike solutions that rely on CPU emulation, Wine runs applications at full speed. Sometimes a program run under Wine will be slower than when run on a copy of Microsoft Windows, but this is more due to the fact that Microsoft has heavily optimized parts of their code, whereas mostly Wine is not well optimized (yet). Occasionally, an app may run faster under Wine than on Windows. Most apps run at roughly the same speed.

So no, it's not an emulator in the strict sense, it's merely an alternative implementation of the windows api. For more info, look here

To my knowledge WINE is an emulator for windows, so that windows programs may be run without purchasing windows.

On the flipside, I wonder if this means that WINE has moved from the part where MS ignored them and will begin laughing at them. :) I also wonder how much code from the WINE project (and probably DOSBox) made it into Windows XP for backwards compatibility? ;P I think DOSBox does a much better job of running old DOS games on XP than XP does.

You have to figure that MS bought Connectix for their virtualization technology so that they could actually dump backwards compatibility from the core OS and just use limited virtualization for better backward compatibility. At the same time by dumping all that cruft from the core OS, they can make the OS something more advanced. XP was a pretty big leap from Win2K in that direction (dropping support for CPUs below P II for example). I would have to guess that Longhorn is going to be an even bigger jump which is why it's taking so long.

Or what, did you really think we could run apps like Office and iTunes without such a basic sync primitive?

The easiest way to port Win32 GUIs is using Wine. Also, if one was going down this route one might also question the logic of going to the trouble of porting the file/mmap/synchronisation functions away from Win32.

Then it's all done, we'll party with hookers and coke while some guy from Sun complains loadly about daniels removing xeyes from the so called 'modular' tree...

Classic games, huh?
Well, I happen to have just the links for you.

Doomsday: A windows and linux improved doom port
http://www.doomsdayhq.com/

ScummVM: An LucasArts games emulator. Plays almost all games: Indiana Jones, Day of the Tentacle, Sam & Max...
http://www.scummvm.org/

DOSbox: An DOS emulator. Good for classic games.
http://dosbox.sourceforge.net/

With Wine, you can also play lots of classic windows games. Take a look at wine's application database to find your game.
http://appdb.winehq.org/

I have submitted entries into the DB for various other viruses that have happily found their way into my inbox, but they haven't accepted anything other than Sircam. This is a shame because Sircam is very out of date. We now have a whole bunch of much nicer, better viruses. I hope that this article will correct this problem with the app db. They need to fix this policy. Just because some of us use Linux doesn't mean we should be excluded from receiving whatever benefits these small applications may have to offer.

Note that when I do run viruses, I make sure that things are set up so that they can't possibly get out to anyone else' computer. This is pretty easy because I don't use Outlook so the viruses have no way to spread. But I am careful because I don't want to spread these things or otherwise be a "bad netizen". Wine is the perfect way to explore the features and benefits of these little applications without causing harm to myself or others.

If you want to see what physics are already available for PC and which could easily be implemented with considerably less CPU power than the next generation of consoles is likely to have, you absolutely must have a look at Meqon whose demos incidentally run really rather well under Wine.

Cheers & God bless
Sam "SammyTheSnake" Penny

Perhaps not too off base, as Alexadre and Linus seem to be in good communication. If you look at the WINE newsletter for the last week in December, not only is Linus shown as posting to their mailing lists, Linus is shown as having the greatest number of posts (18).

Myth 1: "Wine is slow because it is an emulator"

Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor.

They're working on support for Microsoft Installer. Until then, have you tried installing it on a winbox and then copying it over, or is it anal about registry entries, or are you boycotting Windows entirely?

Does the client work under ABI translation on Linux or *BSD on x86?

Photoshop 6 and 7 are both listed as "silver" applications on Codeweaver's compatibility database for CrossOver Office, which means they are very usable with a few bugs keeping them from running perfectly. If you want better support for those versions and support for CS and Elements, be sure to place a vote in the compatibility database. If it's worth some money to you, make a pledge. Pledges pay for development time, basically. The apps that get the most votes and pledges will be supported fastest. Looks like right now Photoshop CS is at the bottom of their list of the Top 25 Pledged Apps with $819.50.

Oh, and CrossOver Office is based on WINE, and all the bug fixes that Codeweavers find will eventually work their way back into the WINE source, so supporting Codeweavers is generally a good thing for Linux and the whole Open Source community.

ObDisc: Not associated with Codeweavers in any way, but I've used CrossOver Office and found it to be good software.

As for your original question, I would recommend using any light weight window manager. openbox, blackbox, etc. You could move from gnome or kde to one of these when you are going to play a game. Also, I recomend you to buy an nvidia card. The ati drivers suck badly. I play 3 games on my machine (when running linux) Doom 3, UT 2004, and Enemy territory.

I forgot to tell you, that you might want to check this links:
Wine Application DB"
Frank's Corner
To see how to install several windows games in linux.

Wine is not an emulator

Actually, Wine stands for "WINdows Emulator". Someone dishonestly changed it to "not an emulator" later, but even the Wine webpage reveals that is untrue.

Meaning that wine does not add any "extra" layers on top of the os

That's precisely false. Wine absolutely adds extra layers on top of the OS; including the wineserver for example.

1. Just want to know how much longer until I can get a fully working win32 binary release so I can drop explorer.exe but keep my win32 apps (such as virtual dub).

I don't know what Windows has to do with KDE, though Virtual Dub works fine under Wine. Also, if you need .Net (CLR) support, the folks working on the Gnome project are integrating Mono.

The last time I checked, people didn't think in Windows API.

I didn't say "Windows API". I said "Windows ABI", application binary interface, meaning "if you put this disc in this computer, this app will appear on this display." Even four-year-olds who haven't learned to read and write can still put a disc in a Windows machine and predictably see SpongeBob EncephaloPants. This ABI changes from OS to OS; if you put a Windows CD in a Linux box, you probably won't get the same result without translation software installed on the machine.

People become confused and lock up because the start button changes from gray in Windows 98 to green by default in Windows XP, or because the start menu is shaped differently. How can one explain this?

Moderators be patient, as we're getting to the underlying problem behind both switching orthographies and switching operating systems by operating in a space potentially more familiar to Slashdot readers.

...so that I could actually view a trailer on my computer every once in a while. Why, oh why, must the movie industry be in bed with Apple to such a degree that there actually is not even one trailer available in a non-quicktime format?

I have found the Win98/ME version of Apple's QT player to work fine under Wine. If you run Linux on x86, you might find this useful.

I just bought the Suunto X9. The device itself is perfect and it comes with serial docking station. The provided software called "TrekManager" is only available for Windows and I had no luck to get it working with Wine, so I asked Suunto to give me some informations about the communication protocol. The answer:

Of course you are free to write your own software at your own risk but we can't unfortunately give you the information you requested as it isn't made public.

I don't wanna force other companies to produce MacOSX/Linux software. Its a decision, that should be respected, but they should make it possible for Open Source developers to write their own software. Suunto makes Hardware and thats all - the software is itself is just an add-on.

Now I have to find a windows box, install the software, connect the GPS watch and sniff the serial line to figure out the communication protocl. Sooner or later I'll (or someone else) find out how it works and then we can publish the informations.

If I could run it 100% Windows Free I would, but the University I'm due to transfer to next year insists on everyone running Windows 98SE/ME/2000/XP, Office2000 or XP, and SPSS. Aside from SPSS I'd be totally fine being Windows Free but so far I have found no way to either run SPSS in Linux (neither Codeweavers nor the regular WINE project can do it at this point) but there are SPSS workalikes that are Linux native. Hopefully by the time I have to deal with stats I'll be able to convince my math prof to let me use either RProject or PSPP instead. I am so ready to ditch Windows once and for all.

and get wine-ing

If you want a 32bit Wine (most people want that as they want to be able to run Win32 apps), you need to tell it (actually tell your build toolchain) to issue a 32bit binary rather than the default 64bit.

To do so, follow the instructions given here, and you should be set.

According to TFA, this is a pre-compiler/translator, not an emulator. i.e. The entire program is recompiled for another platform using only the binary data as the source. This is theoretically possible and has been attempted many times, but such compilers often trip over levels of indirection that programmers add.

Well, Photoshop will work under WINE. Haven't tested Dreamweaver myself, yet, though.

A kernel is not an OS - not just the MacOS X GUI is proprietary but also the API implementations, which vastly outweigh the size of Darwin. Litmus test: can you run MacOS X GUI apps (and nearly all are) on a plain old Darwin build? No? Thought not.

2) their open source OS is still building on BOTH Power PC and Intel platforms.

So what? "Building" does not equal "installs easily", "has drivers", "optimized for" etc etc

3) a version of Microsoft Office (like it or not, this is a huge advantage that the Mac has over other Open Source OS's)

Not really. Office for Mac is good, but it's not the software that people have already paid for, trained on, scripted and written arcane spreadsheet/OLE hybrid apps for.

Why rebuy all your copies of Office at huge expensive (Office for Mac costs more than MS Office does) when you can run the real thing on an open source OS via Windows emulation?

This release also contains UNIX System 5 Release 4 (SVR4) standard components such as the SVR4 Print Subsystem.

The specific implementation that is supposedly owned by SCO, or a compatible implementation made by IBM itself ?

A small, but significant difference :). After all, Wine implements the Windows API (poorly, but still...), but it's not copyrighted or in any way owned by Microsoft.

Wait until they see how they can run most of their Windows software under GNU/Linux using Wine.

Cool. I wonder how far along reactos, an effort to clone NT4 is with this :-) Incidentally this is a very cool project and they've completed about 70% of the kernel and most of the userspace is taken from the Wine Project.

Btw... You wanted to wait on mutexes with Linux... Well you can! Kernels >= 2.5.7 have the sys_futex call that wakes up everyone waiting on the value of a certain address to change.

BTW... if you really wanted to show off some really basic VMS features Linux does not (yet) have then how about NT-APCs (Asynchronous System Traps as they're called in VMS) which is code in userspace of the process that initiated the IO that is called when that IO operation has completed. I doubt a lot of apps use them, however.

There are probably a zillion facilities one OS has that another lacks. Take IBM MVS / OS/390 /zOS jobs for example. A job in IBM's mainframe OS is a sequence of processes that run in sequence and parallel and the OS takes care of synchronizing them, connect them to the resources (datasets, network resources, etc.) they need and make sure that they run in the correct sequence and wait up on each other.

However there is one thing where the Linux-kernel is ahead and that's where it counts: It's a free highly featured enterprise-ready opensource production quality kernel under constant public review. No kernel-feature can make up for that

Now to get ahead of Microsoft in userspace, yes... I could even live with the OSS community adopting Microsoft DCOM. We already did in a way with Mozilla XPCOM.

It turns out a few files have slipped in with licenses other than the MIT/X licenses. My appendix links to a detailed license analysis (I didn't do the analysis, kudos to the person who did!). But there aren't many such files, and it wouldn't take much to fix them. It's likely that some weren't even intentional, and contacting the authors would be all that's needed in some cases.

I very much doubt that they'd move to the GPL. This is a project shared between GPL'ed operating systems, *BSDs, proprietary X vendors, and proprietary OS vendors; a GPL move would break that. I guess it's conceivable they'll later move parts to the LGPL, particularly easily separable parts (like a sound server). Mesa was originally LGPL, for example. And the commercial environment has changed since X was started; some projects like Wine have decided to switch from MIT/X/BSD-like licenses to the LGPL, because they believed that too many commercial companies would take but not give back otherwise (rendering the project unable to continue). So you could argue that the changed environment might encourage them to use a different license to keep the project more viable. But I suspect that won't happen, at least in the short term. Most people seem to be interested in keeping the "status quo" MIT/X license, and more interested in rearchitecting and adding new features. I don't speak from special authority, just as someone who occasionally follows the discussions.

It works through the wonders of the beautiful projects Wine and libfst. So, basically all your favourite plugs are compatible.

Though this technology is still quite young, your milage will vary (it works better than expected though). Eventually all plugs will work!

Are you running wine?

Only instances I can find.