Fun With Wine
taviso writes "Ever wondered what would happen if you could compile and run cygwin under wine ? What about compiling wine under cygwin ? well these guys have, and are planning to nest the two environments as many times as possible to see if wine can take the strain, and not without good reason: 'Having such virtualization environments run within each other is an important milestone in the lives of these projects, it is a remarkable technical feat that requires a great deal of maturity'. "
Microsoft can snap it any time. All they need to do, is to change thier APIs and making them incompatible.
Uhh... perhaps you've been living under a rock for the last two years? They did change all of their APIs to make WINE obsolete. Here are the new ones: http://www.microsoft.com/net/
Slashdot is jumping the shark. I'm just driving the boat.
To break Wine, they need to break backwards compatibility. Their existing MASSIVE market of users and companies that use old programs on new Windows will prevent them from ever doing this like you say.
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
But I still cannot run MS Office or Internet Explorer
What are you talking about? Of course you can
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
from cygwin.com:
.dll.
Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts:
# A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality.
# A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel.
Basically it lets you compile unix programs on windows and run them with the cygwin
Blessed are the pessimists, for they have made backups.
I had the same problem, sometime I would manage to get something running, mostly not.
Now the standard (unstable) debian install comes with winesetup, which sets up a nice working wine installation (works a bit better of you have windows installed)
Try to install winesetup (a contribution from codeweavers)...
MS Office and IE both run fine in Wine. IE of course only runs if you have an existing Windows install. And all the games I care about (like Warcraft III and Max Payne :P) work fine in WineX
Ok, here you go: http://appdb.winehq.com/ just what you want
Actually the WineHQ site is being redesigned at the moment (I'm not a major contributor but am on the lists).
The best tip for using wine is simply - buy it. WineHQ wine hasn't had much effort put into end user usability, it's much like the raw Linux kernel, it needs wrapping up with lots of utilities and quite a few "hack patches" for it to do everything the users demand. I have 2 installations of Wine on my machine, CrossOver and Wine CVS. Guess which works better.
Often, a few little things can make a program work better if it doesn't work properly with a standard CodeWeavers install. For instance: WinZip works fine until you open a zip with a message in it. Why? Because it's missing a RichEdit control (wine has no replacement for it yet). You could fiddle with config files and make it use a native riched40.dll, but an easier way is to google for it, find allerasoft.com and download it from there. Run the RichEdit update .exe in Wine, and now you have the control and WinZip works perfectly.
The Apps DB is the best place to look for tips like this, each app that is known about in the database has a score and a comments section for users to swap tips.
"By the way, a lot of people think that the Windows API is too much of a moving target for WINE to catch up. As a Windows developer, let me say, this is rubbish. Almost every Windows app out there is tested on Win 95 to make sure it runs decently on the entire 32 bit Windows product line. If WINE could ever catch up to Win 95, they would be almost completely done. The target hasn't moved anywhere since August, 1995." -- Joel Spolsky
To make this clear, here are links for running MS Word, MS Excel, and MS IE under Wine without paying any money to Codeweavers or any other company. You do pay with your time, though.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
http://www.frankscorner.org/wine/ is an incredible resource. Check it for info on how to run all of those hard-to-make-work programs. He even shows how to get WineX working for free :-)
yes and no, wine provides low-level binary compatibility, not hardware emulation, so its only for OSes running on x86 chips.
winelib, however, is aiming for cross-platform compatability, so its possible you can compile windows software and link it with winelib for use on osx.
ex$$
The first one is that Wine is hard to make work. Well, it's like Linux you know, if you go get a release from WineHQ it's like getting Debian or Gentoo, great for power users but it requires quite a lot of effort to make it work well. It's all there though, you can sit down and beat WineHQ releases into running Office or IE. It just takes effort and skill.
For the rest of us, companies like CodeWeavers are for Wine what RedHat is for Linux. They add bits, integrate it nicely, give you support. As a concrete example of what they add, they have a nice app (officesetup) which presents you with a list of apps that are installed a la "Add/Remove programs". If you use this program to install an app as opposed to running the setup.exe directly, icons will be added to your menus and desktop, and file associations will be automatically setup for you. Wine doesn't have this (yet).
Another thing is that WineHQ has no code for automatically performing a "reboot". Stuff like IE needs some actions to be performed when you reboot the machine (the RunOnce sections). WineHQ releases don't have any code for this, so you'd have to manually read the registry entries and files and do it yourself, hence the fact that most people fail.
WineHQ will get this code. One of the targets for Wine 1.0 is that it's easy to use. For now though, you need to buy CrossOver Office for the best overall Wine experience. It's unfortunate that you have to buy a separate product for games, but that's one of the perils of BSD licensing, it allows forks like that (fyi wine is now lgpl).
Another myth is that wine can never catch up with Microsoft. That actually isn't true, if anything we're moving as fast as, if not faster than Microsoft right now. There are a few large projects left and then Wine basically has a mostly complete implementation of the Windows APIs. Such projects include a richedit control (effectively a mini word processor), RPC (being worked on now), DirectX (an lgpl implementation, parts are available but d3d is only like 10% done), a WinHelp app and so on. After that, it's pure bugfixing all the way.
So what are Microsoft doing? Well they're working on .NET of course, the Windows APIs are horrible and .NET is a way of making them easier to use. But we have that covered as well with Mono, in fact for System.Windows.Forms Mono is using the Wine controls library. Mono is moving at an astonishing pace, it has lots of volunteers working on it. But it needs more developers as always (wine that is), and one problem is that getting Wine working well enough to hack on it is hard. Catch 22 in a way. Don't be put off though. Wine is cool, and remarkably advanced.
Hmm, odd. Make sure Wine is set to be emulating Windows 98 not 95
But things like this typically follow a scale:
1) does it work period? (i.e. can cygwin run under wine - 1 nesting)
2) does it work in the small-number case (i.e. 2-5 nestings, or thereabout)
3) does it work in the extreme case? (i.e. 10^(2-5) nestings) - which means that most inefficiency bugs are flushed out and the design scales well
Just about every system can fit into one of these categories - but only the most robust fit into #3. Example: Linux threading. Right now it passes 1 (you can multithread), passes 2 (having a number of threads/process under ~100 doesn't really change performance), but fails 3 (the 2.5 kernel developers are working on that one right now - but ~10,000 kernel threads will bring the system to its knees).
A witty [sig] proves nothing. --Voltaire
As you can see from those screenshots, I've had success getting PS 6.0 to work from within Codeweaver's "Crossover Office". It starts & runs without issue. I also tried a few different filters, and they worked.
However, every time I attempted to modify the default user colors, it crashed without hesitation.
YMMV.
+Chiron+
The LINE Project also falls into this ubercool camp. (Is Sourceforge down? Here's the cached version). It allows you to run staticly (statically?) linked Linux applications under Windows/Cygwin - including advanced X11 applications. I've tried it and it actually works surprisingly well. The problem is that LINE emulator is not actively maintained any longer and it broke with the recent Cygwin DLL and/or the upgrade to the recent GCC 3.2.x compiler for Cygwin. When I get a chance I'm going to take a look at it to see if there's an easy fix. If anyone here has a clue as to what the problem might be, please reply to this post. thanks.
You can sue all you want, but it doesn't mean that are right or that you will win.
Apple sued, but they lost., because Apple was not the inventor or the GUI interface. They borrowed the GUI idea from the Smalltalk project which was created by Xerox and PARC.
"Can of worms? The can is open... the worms are everywhere."
Ehm, Crossover developers actually support the license switch to LGPL.. it's Transgaming folks that have problems with it and encourage dual-licensing, because some of their changes involve propietary bits that cannot be revealed.
Nothing stopping anyone from putting a propietary pay-only interface on top of an LGPL product.
Michel
Fedora Project Contribut
If you read the fucking page, it says "Hit Enter when prompted for a password."
It's hard to be religious when certain people are never incinerated by bolts of lightning.
It used to be. When Wine began, it was basically a loader for the libraries that came with Windows to handle the Windows API calls. Now, Wine handles those Windows API calls itself so having a Windows partition around is not necessary.
That said, if you can't install a program under Wine does not mean that the program itself is incompatable with Wine. Having Windows around to install a program for Wine to use later can be useful.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
> And Mozilla isn't slow.
Mozilla isn't slow, but it has a higher memory footprint than some
other browsers (Opera, for example) and a higher _apparent_ memory
footprint than IE, from the user's perspective (because the parts
of IE that are loaded at bootup time won't be considered as parts
of IE by most users). This means that on systems with marginal
amounts of RAM, Mozilla is more likely to push you over the edge of
your memory into swap, which of course is _noticeably_ slower. This
is the phenomenon most often meant when people say Mozilla is slow.
In my case, I've got 512MB of RAM, and after the OS (Linux) and GUI
(XFree/Gnome) take their hits the five apps I use most (Emacs, Gnus,
Mozilla, Gimp, and gnome-terminal) are welcome to most of the rest.
Once a day or so when I fire up something else large (OpenOffice,
for example) too, I dip into swap space, but most of the time that's
not a problem. But I'm a power user, and I specifically maxed out
the RAM on my system so that I could have [counts] fourteen windows
open at once (at the moment, 3 Emacsen, the 4 basic Gimp windows
(no actual images just now), one Mozilla (9 tabs), and 6 instances
of gnome-terminal (in 4 different terminal classes) for various
things (one for a MySQL client, two looking at directories where
I'm doing two different projects, one tailing a log (related to one
of the projects), and two sshed into another system). That's not
normal user stuff; most people _don't_ go out and spend extra money
on extra RAM, because they _don't_ need to have 14 windows open at
once. So for them, if the computer is anything like as old as mine
(January 1998 originally, though I haven't had 512MB of RAM that
long), Mozilla is indeed going to be "slow".
This is however not a _performance_ issue (from the programmer's
standpoint), but a footprint issue, and it will be fading in
importance, as new computers are coming with more hefty amounts of
RAM these days. (128MB is _way_ more than Mozilla needs, and
that's the least a normal system comes with these days.) Yes,
apps will continue to grab more of that, but since most users
only really run one app at a time... so app developers don't
have to _stop_ the growth in the amount of RAM they use, as long
as the keep it substantially _slower_ than the growth in the amount
of RAM that new computers have. By Netscape 8 timeframe nobody's
going to _care_ that it uses 48MB of RAM or more. The people who
_do_ run multiple apps at once (such as myself) can pick up a
little extra RAM; it's cheap these days. By the time Netscape 9
comes out, it can probably get away with using 64MB or more, since
three-year-old off-the-shelf systems (being sold today) will have
128 to work with en total, and new systems will be selling with
more like 512 or more. (Of course that number is guesstimated.)
Code optimization from the compiler doesn't really matter; it's
keeping it from swapping that will save your day in terms of
apparent performance. The difference between well-optimized code
and poorly-optimized code, in terms of CPU time, is subliminal;
most people need benchmarks to even determine whether there _is_
a difference. But if you run out of physical RAM and start using
swap space, the user can measure the delay with something no more
precise than an analog watch.
Cut that out, or I will ship you to Norilsk in a box.