Slashdot Mirror

You got something there. Do you think that'll run in Wine?

There is no performance hit. It's a myth.

On my Linux box, I run World of Warcraft WIN32 using Cedega, and get native (or better than native) performance. Wine, and hence Cedega, a Wine fork, or NOT emulation. They are binary API compatiblity layers. They are an implementation of WIN32 for Linux.

It's a userspace app that runs WIN32 EXEs. That's all.

There's no emulation. It's wicked fast, and there's minimal overhead. The only "real" overhead is that you're paging code to run more types of binaries than are avaliable on Windows; XP only supports COM and EXE, while Linux (with a WINE-alike) support ELFs, A.OUTs, EXEs, and COMs. More APIs=more memory, and generally more paging.

There are some performance issues with particular titles, but this is not because of "emulation", and an architectural performance limitation. These issues are because of poor implementations of various DirectX/Direct 3D features, which Transgaming is constantly working on.

Furthermore, Cider, which is a rebadged Winelib, does much of the translation work before hand. There's no reason for Cider not to support the latest and greatest; in fact, Transgaming is positioning Cider as something you build into your project during development; when you compile, you can target either Windows or OS X, and Cider should handle all the work for you. Take a look at the Winelib documentation. I'll quote:

Compiling apps under Winelib should theoretically involve only makefile changes. In practice, you will encounter header problems, and the likes -- for these it is much better (and faster) to submit a patch, rather than document them. So for the remainder of the section, let's assume the Wine headers are good enough for the application in question.

So, why doesn't Valve, or Blizzard, or whoever, use Winelib to build games? Because Winelib has limited DirectX capabilities, and because it would require a fair amount of developer interaction with Codeweavers or Wine-dev mailing lists to get problems sorted out. Not to mention that Codeweaver's traditional focus has been on office applications, not gaming.

Enter Cider. Transgaming will offer, for a nominal fee, to deal with all those problems for you. Plus, Transgaming's already done much of the work regarding DirectX; they've currently implemented a substantial portion of SM 2.0, with 3.0 on the horizon. Direct Play, Direct Sound, Direct Input, yadda yadda, all work properly. Dollars to donuts Cider will utilize OpenAL, enabling EAX up to 5.0.

It's silly to think of Winelib, or Cider applications as "non-native". They use the WIN32 API, and they're probably not using QT/GTK2 widgets; but these are most definitely Linux/OS X applications. Heck, 99% of games use their own GUI setup anyways; it's not like your going to be look at MS widgets inside Doom 3.

It's just a different API. As the implementation improves, performance improves. Indeed, in certain regards the Wine (and Transgaming) people have actually surpassed Microsoft, and as such performance is better. For example, Linux's scheduler can perform vastly better than Microsoft's, and games load (and textures pop into place) quite a bit quicker. Comparing two similarly built systems (I have side-by-side desktops with my girlfriend), one on Windows, one on Linux, World of Warcraft loads textures faster, and experiences substantially less texture loading lag, on Linux. When I switch on Cedega's Windows Scheduler implementation, the behavior regresses to be similar to the Windows system.

There's no reason for WINE or Cider to be inferior to native Win32. There are plenty of issues in Win32 that can be "fixed", and run faster; and there are plenty of places that Linux's (and/or OS X) superior performance can be leveraged. It's not an "emulation" architectural issue, it's just a $$/Manpower engineering issue, and the gap has closed significantly. Working directly with developers while they are in the primary phases of development will enable high-quality, high-performance WIN32 applications on Linux/OS X.

Cedega ist available from CVS.

I assume you're talking about this, which hasn't been updated since June, and which barely has any discussion except about internationalization. Or maybe you're talking about ReWind, the BSD-licenced fork of WINE, which is even more lifeless.

Contrast that with WINE, which is actively developed, discussed, and used enough to justify "weekly" news articles.

As a Windows developer, you can always code your game/application to work with wine. http://www.winehq.com/ It seems to work OK for Google http://earth.google.com/earth4.html.

You are right that it works for Google. However, you are wrong about Google Earth.

I'm not picking a fight, but I have a couple of issues with your post. First, I spent over $500US in the last seven months on Linux games. I think this is profitable for someone. When Win95 came out there was a transition. People didn't rush out to buy native Win95 versions of thier DOS games.

There are too many Linux distributions, none of which have a big enough of the Linux market to be considered the de facto standard Linux distribution to develop for and build a customer service department to support.
I bought just about every port that Loki did and I didn't have any problems playing them on on any >= 2.4 kernal version SuSE, RedHat or Ubuntu. Instead of a customer service department, how about a good technical support forum? The Linux Standards Base is your friend.


Finally, once you manage to get things working on a couple distributions, a new release comes out that invalidates your existing application. And in another 6 months another release of Linux is going to come out and invalidate your work again. A developer has a hard time keeping his game working under one distribution from one version to the next. Now multiply that by 10-20 for the most popular Linux platforms each releasing new versions every 6 months.
See above. All my Loki games have worked since SuSE 6.4/RedHat 7.0. As a user space game programmer why should you care about kernal changes. Just code to SDL/OpenGL (Both are backwards compatible).

Game applications are the most strenous and sensitive to the capabilities of the platform. Windows is pretty standard with DirectX. On Linux you don't know what's going to work; the very philosophy of choice with Linux translates to everyone's machine is just different enough in a way that makes developing a game for Linux a real frustration.
Thats nonsense. Code for the lowest good versions of SDL and OpenGL. You will be suprised on how many different distributions of Linux it will run on.

Shipping source code to your customers and expecting them to build it every time they upgrade their machine or switch distributions isn't a solution.
I have purchased over 20 commercial Linux games, none came with source. Are you trolling? You have never purchased/installed a native Linux game yet your an authority on shipping source with a Linux game? I call bullshit.

I buy my Linux games from here: http://www.tuxgames.com/ (No I'm not affilated with the site).
Check out the loki games from here, http://liflg.org/, pay special attention on how the installer works. You can get the installer sources for free from here: http://www.lokigames.com/development/setup.php3

As a Windows developer, you can always code your game/application to work with wine. http://www.winehq.com/ It seems to work OK for Google http://earth.google.com/earth4.html.

Your post does disgrace Interplay, SirTech, MindScape, SSI, Origin and many other great gaming companies from the 80s/90s that did (Intel/Non-Intel CPUs/OSs) cross-platform games.

Enjoy.

I whole-heartedly agree with "gamers who need to suffer Windows." I recently tried a complete switch over to Linux, but was forced to go back because of that single reason. More specifically, it was the Source engine games that took the most performance hit. All games ran (thanks to Cedega) but not nearly as well as on XP. Guild Wars ran acceptably, and Warcraft 3 surpassed expectations. I even got my VPN (Hamachi) to play nice with LAN games.

Gorgeous GUI as well (Gnome).

Almost there, so very, very close!

Go WINE!

Also the mouse delay bug is quite annoying.

Ignorance is strength
Freedom is slavery
War is peace

Stay ignorant and repeat the lies, or learn and make your own oppinion. Your choice.

Package management and dependencies used to be a problem for me, then I learned of debian, games used to be a problem for me and then I learned of winex(cedega), I had a problem with MS office and then I found crossover, I had a problem with outlook and then I found evolution, I had a problem with single sign on and windows transparency over server message block then I found winbind... There are frustrated users, and then there are self educating *nix users.

In reality, the biggest failing is education, not cross compatible software.

There's no such things as FreeDOS nowadays, which was developped to late to be anything useful, specially it's not used by many people (including hardware manufacturer and corporate IT staff) to build bootdisks used to flash and upgrade firmwares and BIOSes(1). Neither is it used by computer manufacturer who signed an agreement with a popular OS company that forbids them to sell a computer without an OS.

Whith such an exemple of another old system, we can be sure that nobody will find whatever use for ReactOS, given the fact that Windows Vista will retain no compatibility with a legacy of win32 APPs and has nothing to do with the NT family which is emulated by ReactOS and Wine. And ReactOS and Wine have stated that they will never, I mean really never try to implement more modern API like Win64 and thus won't be able to run all the huge amount of 64bit apps that are seen everywhere (and of which most aren't open-source anyway and aren't ported to linux either (2) ).

ReactOS is likely to die and go the Linux/BSD way. Netcraft is confirming it in Soviet Russia. In Korea, only old people find usefulness to free and open alternatives that retain compatibility to commercial versions.

Har, har, har.

1 - bootdisks and -CD are specially popular in big places where you need to quickly upgrade BIOSes and Firmware non-interactively just by pluging a disc. The same can't be achieved from windows yet (there are windows-based flasher, but they can't be deployed thru usual network channels as software update)
2 - Windows 64bits is once again a proof of the supperiority of open-source. The first softwares that was the most easily ported to Win64 API were the open-source one, were the developpement is much easier because of source code availability : 7Zip, Blender&Yafray, Mame, FireFox, PuTTY, POV, VirtualDub, and many other. Where as only a couple of commercial games (because they make nice tech demos in booths) were ported, and almost no commercial multimedia package (although multimedia was supposed to benefit the most from the increased memory address space and was hoped to be among the first ported to Win64).

There's no such things as FreeDOS nowadays, which was developped to late to be anything useful, specially it's not used by many people (including hardware manufacturer and corporate IT staff) to build bootdisks used to flash and upgrade firmwares and BIOSes(1). Neither is it used by computer manufacturer who signed an agreement with a popular OS company that forbids them to sell a computer without an OS.

Whith such an exemple of another old system, we can be sure that nobody will find whatever use for ReactOS, given the fact that Windows Vista will retain no compatibility with a legacy of win32 APPs and has nothing to do with the NT family which is emulated by ReactOS and Wine. And ReactOS and Wine have stated that they will never, I mean really never try to implement more modern API like Win64 and thus won't be able to run all the huge amount of 64bit apps that are seen everywhere (and of which most aren't open-source anyway and aren't ported to linux either (2) ).

ReactOS is likely to die and go the Linux/BSD way. Netcraft is confirming it in Soviet Russia. In Korea, only old people find usefulness to free and open alternatives that retain compatibility to commercial versions.

Har, har, har.

1 - bootdisks and -CD are specially popular in big places where you need to quickly upgrade BIOSes and Firmware non-interactively just by pluging a disc. The same can't be achieved from windows yet (there are windows-based flasher, but they can't be deployed thru usual network channels as software update)
2 - Windows 64bits is once again a proof of the supperiority of open-source. The first softwares that was the most easily ported to Win64 API were the open-source one, were the developpement is much easier because of source code availability : 7Zip, Blender&Yafray, Mame, FireFox, PuTTY, POV, VirtualDub, and many other. Where as only a couple of commercial games (because they make nice tech demos in booths) were ported, and almost no commercial multimedia package (although multimedia was supposed to benefit the most from the increased memory address space and was hoped to be among the first ported to Win64).

This comes severely late, in my opinion. The Wine and the CodeWeavers people have put work into running Notes on Linux.

IMHO, it would've been better if IBM had put this investment into Wine so other applications had profited as well. A proper native compilation along with some polishing for the various desktops could've made this "achievement" years earlier. Think Google's Picasa, which was nicely ported to Linux this way, and runs like a charm.

Where to start with you...

First of all, learn to speak English better. From your rant, it seems that not having "fancy graphics" is not a requirement for you, thus making "fancy graphics" appear to contain little importance in your microcosm, which makes me wonder why you'd even bring it up.

Second, have you ever heard of WINE? It also seems you would be a prime candidate for "person who would benefit most from an Apple MacBook which, with its X86 processor and "Boot Camp" can support installation of Windows, Linux, and OSX operating systems simultaneously.

Furthermore, with that absolutely clueless comment you made about Firefox and Outlook, I'd guess that you'd really get a kick out of OSX. Also, have you tried Thunderbird?

I'll stop there for now, before I get carried away.

If it's any consolation, I don't think that you're extremely stupid; I just think you're ignorant.

You can of cource try WINE or VMWare, and you can always keep a dual-boot for games. Though you will have a problem if they are online games. You can also try to set up a firewall based on Linux and connect the Windows machine on that one.

Not to start a flamewar but

You just did. It wouldn't hurt to do a little Google research, as most of the things you say are so untrue that I'd mod you -1 Flamebait/Astroturf if I had the points.

Does it even support winforms yet?

Yes.

.Net 2.0 is coming with VS.net 2005 and Mono has still not caught up with VS.net 2003.

Most of the 1.0 code is complete. 2.0 isn't complete, but what's implemented should work.

But cross platform it is not and its a MS technology just like win32 is, though you can have limited success with wine.

I'd hardly call 4210 applications "limited". Now, I have no clue how many of those work, or work well without tweaking, but between Wine and Cedega, I rarely run into legit apps that don't work. Of course, tools for pirating stuff like Daemon Tools causes problems...

But maybe try it before you knock it? Recent Wines are actually getting pretty damn good. It's amazing how often I'll just download some random free app off the Internet and have it work flawlessly.

More importantly, are you familiar with the history of Linux? Unix was as proprietary an OS as they come, yet they actually published APIs and stuck to them. The GNU people were essentially doing what the WineLib people are doing -- reimplementing the APIs. They weren't shooting for binary compatibility, but they wanted people to be able to take any Unix program and, with a minimum of tweaking, recompile it for the GNU system.

And really, you don't need 100% compatibility. Getting 99% compatibility probably means you get 99% of people able to switch to Linux, which means the 1% stuck on Windows are about as relevant as the 1% currently stuck on DOS.

Mono is even easier, because it was designed to be cross-platform. The actual, official Microsoft .NET code has been ported to Linux, so we know it can be done. And no sane opensource person is afraid of it because it's Microsoft's tech -- if it comes to that, we can always fork it. The fact that it was designed by an evil/incompetent corporation doesn't necessarily mean the tech was a bad idea. Think about it -- how relevant is the original AT&T Unix compared to Linux these days?

Just use Windows. If the server is cracked its the ISP's problem. Not yours if you outsource the server.

I wouldn't count on it. If the server is cracked, the "ISP" (hosting provider, most of them don't sell Internet access) certainly has a problem. But who's going to answer why you went with that provider?

"I cannot think of any other OS that even approaches the maturity of Linux at this point."

IBM might just decide to knock the dust off OS/2. In many ways Linux and Windows and yes even OSX still have not caught up with where it was a decade ago. I don't know of a 64 bit kernel for it or its offspring eCS but it might be hiding in one of the IBM labs in Boca Raton.

Actually the advances in hardware, emulators and virtualizers are making real time simulation of an entire hardware platform API or a specific OS API more practical. I suspect that any posix compliant OS with well written emulators or virtulizers will soon make reduce a specific OS like Windows to application level importance anyway.

I realize that most here are aware of these efforts, but are some urls anyway for the few that are not.

http://www.xensource.com/
http://www.parallels.com/
http://www-03.ibm.com/servers/eserver/about/virtua lization/about/systems.html
http://www.thefreecountry.com/emulators/pc.shtml
http://www.thefreecountry.com/emulators/macintosh. shtml
http://www.winehq.com/

Matthew

Actually, they aren't. Picasa and Earth are the Windows binaries shipped with a Wine binary and config. http://www.winehq.com/pipermail/wine-devel/2006-Ma y/047806.html

You can then literally apply Linux's security modules to individual Win32 applications -- or to individual instances of the same Win32 application -- by running the Win32 app under WINE.

Or run WINE under a different OS (e.g. OpenBSD) or emulator if you want different security tools.

I've done this with/for a number of customers, & integrating the security manageability with a system which has no viruses or spyware to speak of has saved them each endless damage (and endless payments to recover from that damage).

I've also convinced other developers to make their applications portable -- which has instantly increased their productivity and their market, too, sloughing off obsolete dependencies -- and simply stopped running the users under Windows (or anything from MS). This particular tactic earns you much peace & security in one step.

Wine?
Oh doc, I'm confused..

What Apple needs to do is hire the WINE people or Transgaming to get something usable on the Intel Macs and include it free of charge (no Quicktime Pro nag) with the OS. This would be a stop gap solution as Microsoft is planning on destroying everything with Vista anyway but it would at least lower the "Mac's aren't for games" cries.

First though, Apple needs to sit down with ATi, Intel, and likely soon nVidia and get their drivers in better working order. they have the push to be able to do this so there should be no reason not to. Currently, the Intel Macs perform significantly worse under World of Warcraaft under OSX than booting into XP. Yes, this is just one app but it is a driver issue. This needs to change immediately.

Apple also needs to woo the developers (developers! developers!) to OSX. It's not going to happen immediately but if they can prove that there is both a market and a valid gaming system (get rid of crappy GMA-950, fix drivers) then they might have a chance. Developers are already going to have to switch to Vista's new way of doing things, they could also switch to OSX.

So, first step: get the back catalog. Next step: get the developers. Apple has a serious chance here. They better not screw it up.

I think it is just a tad funny that, indeed, the possibility of Linux being more compatable then Windows Vista, almost laughable. Don't believe me, you say? See for yourself: http://www.winehq.com/?issue=310#Vista%20App%20Com patibility What one developer had to say: "Results: Client appcompat % hovering at 40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" [...] He then goes on to say: "Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :)" On a slight offtopic note: Why in the hell did Bill Yates say, "I have too much money :cry:" when the matter of the fact is he is OUTSOURCING all the *#$*#*$)@* jobs of the country? Well, if there is karma, Bill is sure in for one HELL of a ride. ;) Good day, sirs.

Isn't wine an environment that wraps around Win32 executables?

No, Wine is an implementation of the Windows API. When a program calls a Windows API function, the appropriate Wine shared object is called instead of a Windows DLL. This is what the GP meant by his comment about Qt: You could easily implement the Qt API and then substitute your version for the official one so as to have the Qt app load yours at runtime. The wine program itself is a program loader, designed to properly load an execute a binary compiled for Windows.

You can probably find out more here in a more detailed and accurate form :)

From http://picasa.google.com/

System Requirements

Microsoft Internet Explorer 5.0+

Maybe IE isn't such a requirement after all?

A quick look showed that much of Picasa already worked, but key features were missing: the IWebBrowser API, [..] among others. Fortunately, Wine was already halfway to having an implementation of IWebBrowser thanks to Jacek Caban's Summer of Code 2005 project.

It's too bad this isn't linked in the headline.
http://www.winehq.com/pipermail/wine-devel/2006-Ma y/047806.html

This project was an experiment to see how quickly they could get picasa working with wine.

This is what scares me about WINE. Yes, technically it is native, but of course has a much larger memory footprint. Linux may suffer from many buggy, unstable "ported" applications, giving the OS a bad name. If Linux can run both Windows and Linux applications, why write real, better Linux ports? This is what happened to OS/2.

Then you suffer from the same old Catch-22: Linux has few necessary apps. Therefore, few people run it. Few people run Linux, Therefore, why write apps for an OS few people use?

I'm personally looking forward to wine a lot, because it'll (eventually) let me run all my games that are too old for dev support for Linux native binaries, but without a source release to make binaries yourself, plus run new games that the developers shunned Linux with.

BTW, apparently I was wrong: Linux Picasa is just an EXE with some text resource changes. See http://www.winehq.com/pipermail/wine-devel/2006-Ma y/047806.html.

>>They linked the program against winelib. Unlike using "wine picasa.exe",
>>this provides a native Linux binary.

Check that. From http://www.winehq.com/pipermail/wine-devel/2006-Ma y/047806.html it appears that you're incorrect. Picasa for linux is the same EXE as windows with just a simple text resource change.

"It's just as effective, and a heck of a lot easier, to run
the same binary on both Windows and Wine. So that's what the
Picasa team did."

Google has indeed been working on Picasa, and it's finally available for download at http://labs.google.com/ For the curious, here are a few tidbits about how it came to be. When Google wanted to port Picasa to Linux, they faced a problem: the Picasa team was busy working on new projects, and having them also do a native port would have taken a while. As an experiment, Google decided to give Wine a try. A quick look showed that much of Picasa already worked, but key features were missing: the IWebBrowser API, SSL, scanner/camera support, removable media notification (so you can insert a flash drive and have Windows notice it right away), and change notification (so Windows can notify apps when new files are created), among others. Fortunately, Wine was already halfway to having an implementation of IWebBrowser thanks to Jacek Caban's Summer of Code 2005 project. And all that other stuff couldn't be *that* hard, right? :-) So Google engaged Codeweavers to add those features and fix any other bugs. This resulted in tons of improvements to Wine (see the list at code.google.com/wine.html), all of which are now in the public tree at winehq.org. Many people assume that when porting a Windows app to Linux using Wine, the best thing to do is link Winelib into the application to create a native Linux application. Not so! It's just as effective, and a heck of a lot easier, to run the same binary on both Windows and Wine. So that's what the Picasa team did. Picasa for Linux uses slightly different text messages, but the .exe file is identical for both Windows and Linux.

Many people assume that when porting a Windows app to Linux
using Wine, the best thing to do is link Winelib into the
application to create a native Linux application. Not so!
It's just as effective, and a heck of a lot easier, to run
the same binary on both Windows and Wine. So that's what the
Picasa team did. Picasa for Linux uses slightly different
text messages, but the .exe file is identical for both Windows
and Linux.

it's quite interesting
http://www.winehq.com/pipermail/wine-devel/2006-Ma y/047806.html

...would be that copy of the Windows 2k source code that is running around freely on your favorite p2p network !

Humour apart :
ReactOS and Wine would be closest thing to a Linux of Microsoft (namely an opensource implementation of a NT compatible system).
But they aren't done by Microsoft.

Note: I didn't check the ed2k links, I don't know if they are fake or guenuine

With respect to:
'Pro'-software:

Some commercial software delivers functionalities that are not available under Linux. The other way around happens as well, but that does not give so many problems, as the majority must do without them, and you are not expected to have it available. That is only a real problem for quite advanced or professional functionalities, but if it is those you really need, ...

We don't have to "do without them", since there is a wonderful FREE Windows API implementation, that being WINE (Wine Is NOT an Emulator, or as I like to call it, Windows Is Not for Everyone) and the commercial version, Crossover, which I personally use and it works great.

It has out of the box support for many popular M$ software and can be configured to run just about any windows application, even some DOS apps! Granted there are some issues with running some Windows software and can take some tweaking, but to say we must "do without" is simply not true.

You can't make the argument that Linux is easy because it's all point and click...you know launching oo.org, running firefox, checking that email with evolution, etc and then have non point and click instructions to perform other basic tasks like dvd playback.

What are you talking about? Installing xine is as easy as launching the package manager in your distro and selecting the package that is described as 'plays DVDs you n00b'. =)

Don't mistake the CLI way as the only way, although it is the fastest way to do it.

About the naming: I never saw anyone having a problem with winamp, or Nero, although their names don't make sense immediantly.

I don't know about SuSE, but the rest are as easy as two clicks to install, or worst case senario, click add and write in a repository. Still we are talking about Dell preinstalling some distro, so all this 'linux cannot play DVDs' is bullshit. So is all the 'I need to go CLI to install my nvidia drivers'. Dell will ship with an image of linux that does this right out of the box. Last time I checked, windows XP doesn't play DVDs out of the box either. I just tried it yesterday and was searching for my PowerDVD CD all over the place...

Lastly, the lack of games is a problem for gamers. So is lack of some professional software like photoshop. But linux really does have to offer alot to a user that is not in need of niche applications or games.

Of course they're dual-booting windows - how else are employees supposed to play the latest games?

WINE? Cedega? Or how about na-tive?

Windows Vista currently has a rather poor backward-compatibility. (about 40%) It will definitely improve before the final release, but it probably won't get past 70% - 80%.

Here's some details from this week's Wine Weekly News regarding Wine's involvement:
http://www.winehq.com/?issue=310#Software%20Freedo m%20Law%20Center%20Update

Sheesh, I've been running PS and FrameMaker in Linux for ~3 years now. Ever hear of Crossover Office? Yeah, it costs a little bit, but only the price of a couple of pizzas, easy to afford if you can afford $600+ for Photoshop, and if you're really desperate you can just use Wine, upon which Crossover is based, and which is absolutely free (just a little harder to use and configure).

I get really tired about people bemoaning the lack of MS Office and Photoshop when Office XP and Photoshop 6 and 7 have run better (i.e. *faster* and more stably) in Linux than in Windows for several years now.

Yes, if you absolutely must have PSCS, then you're going to suffer a little on the stability front for the moment, and if you're running a print shop (i.e. must have fully color-managed workflow all the way through in-house press) then you'll still need Windows. But I'm a working media professional and honestly MOST of the other pros I know a) are still using older versions of PS (hell, some of them are still using PS4/PS5 on a pre-X Mac) and/or aren't color managed for their part of the process.

I do just fine with GIMP (90% of my graphics/photo work), PS7 (other 10%), and Office XP (100% of my office work) and I do it all in Fedora Core with no usability issues whatsoever.

Emulation is hard. The Wine project has been started 13 years ago, and they still support only a handfull of applications.

I hope you weren't implying that Wine is an emulator because Wine Is Not an Emulator. ;)

Wine 0.9.8 was released today.

If Sun sets up the foundation and lays the groundwork for the licences on the codebase it's very likely they can ensure to be able to use the code in proprietary programs in the future. However, as seen with Wine some projects goes from BSD to LGPL licences to ensure not being ripped of by companies. But as this is Suns codebase to begin with a similiar scenario would be very unlikely.

the OSS community would probably bother to make/improve a .NET clone.

You mean, something like this?
 
.Netters will be hired back to adapt the differences to Linux

If this "difference" is writing code that calls directly out to the Windows API or Windows-only libraries, then yes, .Netters will be hired to "adapt the differences", but not to Linux. Simply to better coding standards, in which if you're going to call something not in the .NET API, you write proper bindings for it, and you use something portable, like OpenGL, instead of something Windows-only, like DirectX.

(because perfect cloning is probably not practical.)

Perfect cloning of the whole OS? Probably not. While there are several attempts, and while the Mono project did attempt to use components from Wine, not everything works, and even if it does, running under Wine sucks compared to a truly native port.

But, they are getting pretty damned close to perfectly cloning this aspect. As I understand it, quite a few applications written for .NET on Windows run unmodified on Mono on Linux, probably even on my AMD64 Linux.

Let me put it this way: It's perfectly possible, and sadly, far too common for a Java applet to be written that only works under Internet Explorer, in Windows. However, in Java, you hardly have to be trying to make something portable -- you almost have to be trying to write bad code to make it IE-only. All my courses so far that have used Java have worked just fine on 32-bit Windows, 64-bit Linux, and my 32-bit PPC Mac (a Powerbook). Even the IDE (Eclipse) was portable, to the point where I'd be able to rsync my workspace across.

Starting with Chapter 6, the "Practical" bit from the books title starts to kick in quite strongly. If its a book with both theoretical and real world information that you want, then the coming chapters are really going to quench your thirst.

Whoa, for a minute there I thought this was a book about WINE.

There are many programs designed to be run on Windows. Developers usually only design for this operating system because it is on such a huge percentage of desktops. These programs cannot run on linux, so people have been working on emulators and/or compatability layors to get them to run on linux. Wine is a program that is used by people to run programs on linux, but is not perfect. With the Windows source code, they should be able to get programs to run much better.

There is also a problem with getting peripherals running under linux. You need drivers to get them working on your OS, but usually the company that made the device will only release drivers for it on windows. There are programs like NdisWrapper for getting certain devices to run on linux, that could also profit from having the windows source code.

These have been the main stinky points for Linux.

ReactOS is an operating designed to be fully compatable with windows drivers and programs. They are currently at version 0.2.9.

On the down side, the lack of crackers having the source code to windows means that it is difficult for them to find vulnerabilities. Even with the code secret, Windows has had a lot of problems with security. It has also developed in an enviroment were the only real security vulnerabilities would be ones that can be found without the source code. The type of people who would be interested in getting through windows's security won't mind downloading the source from some warez site. I hope that it isn't leaked to these kinds of people. Fortunatly, they probably won't release the source code of IE(wich is supposedly part of windows)

Another bad thing is you will most likely be hearing a lot of people making comments about how poorly windows is written.

http://www.winehq.com/

http://www.codeweavers.com/products/cxoffice

upgrade to faster connection, switch to kubuntu (free AND secure), or anything else equally secure.

If you need (unsecure) windows for anything, use vmware player (free), or wine (free), or if you need to play games with 3D acceleration then cedega (nonfree).

Remember about http://www.openoffice.org/ for office work, http://www.gimp.org/ for drawing, http://www.k3b.org/ for burning DVDs... and the list goes on and on.

ps: I've got some karma to burn, so here I'm whoring ;)

Ahem. Check your facts.

From http://www.winehq.com/, "Wine does not require Microsoft Windows, as it is a completely free alternative implementation of the Windows API consisting of 100% non-Microsoft code".

See also the earlier /. thread: "The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue".

"as I doubt the lawschool's testing application runs in Linux"

Sorry to pop in slightly off topic. With the new Wine (post .9) it may be worth 5-10 minutes to download the latest wine and winetools and try her law program with the default wine install. You may be surpised as to how many obscure programs "just work" with wine now (most just need the Arial Font to look right). I know that we hesitated switchng some machines here to Linux because of a few proprietary business apps, but were suprised as to how readily they ran *well* under Linux. Worst case if it doesn't work, then winetools automates the process of downloading/installing additional MS components that may be needed to get a program to work (IE, Windoes installer, etc).

How do you explain how TrollTech makes money with a GPL'd program (Qt and its official frameworks)? Or how CodeWeavers makes money off of CrossOver Office when WINE is Free in both ways? Or how RedHat makes money off of providing a Linux distro + support when there is Fedora Core, their fully Free distro of RedHat?

Old business models die hard, and the new methods are proving to be a success. Even Novell, IBM, Apple, Sun, and others are benefitting financially from Free software.

...when the first thought is "How else are you going to test wine?"

This 'IE' sounds great... does it run on Linux? Do you have the link to the project page?

Run on Linux? yes.

Project page? right here.

IE for UNIX systems was buggy because 1. it was IE and 2. it was just the Windows version recompiled against MainWin, a commercial reimplementation of Win32 that functions in much the same way as Winelib.

I use Wine on my computer a lot, and it seems to work pretty well. I think eventually, more developers will start releasing their products for Linux as well as Windows. For instance, as a mechanical engineer, I use Pro/ENGINEER extensively, and it's out for Linux as well as Windows.

If you do a Windows version you accomodate the vast majority of the desktops on the planet. It is pretty hard to justify increasing the workload very much to cover the remainder. Has anybody tried this application on Wine (http://www.winehq.com/) ?