Fog Creek Software
Discussion Board




Using Wine to 'port' desktop software to Linux.

Recently Macromedia announced that they are going to make their Flash MX software compatible with Wine, so that it can be ran under Linux. If they see considerable interest, they are going to produce a native port.
In one of your articles you mentioned that porting to another platform can be justified only if the costs of porting are lower then the expected revenue from the additional clients. While I would not necessarily agree with that, I am trying to look at the problem of porting CityDesk to another platform from your point of view. I would assume that you have researched wine as an option, which would let you ‘kind of port’ (be able to run, if we want to be correct) CityDesk to Linux.
So, do you know how easy would it be to make CityDesk work in Wine? How much easier is it than producing a native port? What issues can be expected (compatibility of 3rd party libraries and VB runtime, different versions of Wine, licensing restrictions)?

Alexander Chalucov (www.alexlechuck.com)
Friday, March 05, 2004

I have not actually investigated porting CityDesk to Linux using Wine. Honestly, there is so little money in the business of desktop Linux software I just can't see how it would be worth doing. The people who run Linux desktops are the least likely people to pay for commerical desktop software.

That said, the two biggest obstacles I can see are the Jet library and the Internet Explorer control. I don't know if those are provided by Wine, but if they aren't this would be a showstopper as we rely extensively on them.

Joel Spolsky
Fog Creek Software
Friday, March 05, 2004

In theory, if everything was already there, you wouldn't need to port it at all. It would just run. WINE is an ABI compatibility layer, not an API library.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, March 05, 2004

In that case, how exactly is Macromedia making Flash MX play nicely under WINE?

Christopher Charabaruk
Friday, March 05, 2004

In theory it should be exactly as windows. However I assume that in practice it has features that are implemented slightly incompatibly. Wine might have bugs. Also Wine might be missing bugs in Windows on which your app (or libraries you use) rely on. Also, Wine might behave slightly differently from windows although according to specs (as far as such thing applies t Windows) but this might reveal hidden bugs in your app. Having in mind all the above cases, your app must use the lowest common denominator of the bugs in windows and wine.
By the way, what kind of version of windows does Wine pretend to be? NT-based or 95-based? There are differences in the implementation of APIs between these two branches of Windows ...

Alexander Chalucov (www.alexlechuck.com)
Friday, March 05, 2004

My best guess is that they're working around holes in WINE that they need to exploit.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, March 05, 2004

Wine essentially has 2 parts (logically).

The runtime stuff that handles dynamically loading DLLs and all that stuff.

The DLLs themselves which are clean-room reverse engineered from the API docs.

If you have a legal copy of windows, you can copy the DLLs accross to your wine installation and things run much better.

Koz
Friday, March 05, 2004

It's kind of a catch-22.  I have never paid for software to run on Linux, but I have paid for commercial software, and I'm not completely opposed to buying software for Linux.  The reason is that commercial software for Linux is really bad.  And if I have the choice between getting "something really bad for free with source", or "something really bad binary-only for money", I'll take "free with source" every time.

For example, I bought Adobe Photoshop.  When I'm on Linux, I use Gimp, simply because it's the best there is, but it's not as good as Photoshop (as of 2.0-pre3).  If Adobe announced tomorrow that they were shipping Photoshop 8 for Linux, that would be neat, but I probably wouldn't buy it.  Their free Acrobat Reader for Linux is horrible, and if they can't get Acrobat Reader to work well, I have no faith they'd make Photoshop for Linux suck less than Gimp.

(Now, if Adobe came out with Photoshop 8 for Linux, that acted as much like a native Linux app as Photoshop for {Mac,Windows} behaves like a {Mac,Windows} app, I'd buy it.  The odds of that happening are pretty much zero.)

Can you make money selling Linux software?  I don't know.  But I also think nobody's given it a fair test yet.  The presense of free pretty-good software means you have to do better than pretty-good to sell something on Linux.

KH
Friday, March 05, 2004

Just my 2 cents here - Borland seems to be devoting a lot of effort to create dev tools for Linux.  Between Kylix (the Linux version of Delphi) and C++ Builder, they have about the only commercially supported RAD tools I'm aware of for Linux.  They also have C# Builder for the .Net crowd.

Borland had some serious problems for a while (InPrise, anyone?), but I think they are somewhat back on track.  They are probably the largest non-MS shop in town for dev tools anymore - most of the rest (Watcom, Symantec to name a few) are gone.  Metrowerks is supposedly decent, and have quite the range of tools.

Anyway, I guess that my point is that not everyone thinks that creating commercial apps for Linux is useless...but I'm not very aware of commercial apps that aren't dev tools, so I'm guessing that either nobody has come up with one yet or all those tools are used purely internally by the companies that buy them.

BTW, I believe Wine has the option of either running a compiled Windows app (emulating Windows) or can serve as a set of libraries to create a native Linux app that is source level identical to the Windows app.

Aaron F Stanton
Friday, March 05, 2004

As another aside, if someone were contemplating porting code to Linux, I'd suggest taking a serious look at Mainsoft's Visual MainWin product.  http://www.mainsoft.com/products/mainwin.html
I don't work for them, by the way.

Aaron F Stanton
Friday, March 05, 2004

Uhh.. Do you know what MainWin costs?  Its only feasible for very high end applications, ones that sell for thousands per seat.

Ken McKinney
Saturday, March 06, 2004

A product like CityDesk is aimed at the group of users that pretty much doesn't exist on Linux, because they already use Windows or Mac OS X and see no point switching.

On the other hand, there is a small (but growing) group of developers and administrators who work with Linux and are ready to pay for software that makes their jobs easier.

When devGuide.net ships its first product, we'll do it on the Windows platform, then evaluate demand for Mac OS X and Linux, and then decide whether it makes business sense for us to port our application to these platforms.

One of the obstacles to porting commercial apps to Linux is the fear of GPL. People think that everything you build with GCC will be automatically infected with GPL. I think there is a lot of misunderstanding in that area and the Linux community needs to educate developers what is OK and what is not.

Jacek Artymiak
Saturday, March 06, 2004

Well, Acrobat Reader for Windows pretty much sucks too so I'm not sure that is really a good indicator of how their Photoshop port would operate.

There are so many problems with the concept of desktop software for Linux it isn't even funny.  One often overlooked problem (by Linux users, not by businesses) is the support nightmare.  Microsoft does a pretty fair job of keeping Windows both backward and forward compatible, but since nobody "owns" Linux,  nobody is in a position to do the same on that side.  Thus your desktop application that runs great on kernel 2.2 might not run at all on kernel 2.6.  Or the application that runs perfectly on a particular version of Red Hat may not function at all on another distro, or even a different version of Red Hat (see: the libc split of a few years ago). 

As a company you are pretty much forced to peg your application to a very specific Linux release if you don't want to open a huge can of worms on the support side;  and then when you do this, they post a message about it on Slashdot and the vocal Linux users just bash the hell out of you.... 

Yeah sounds like a great market to get into.

Mr. Fancypants
Saturday, March 06, 2004

This is exactly what happened to Borland Kylix, by the way. The current version of Kylix will not run on any modern distribution anymore. Borland has announced that they will not do any updates in 2004. Nothing is announced for 2005 either. It doesn't seem too profitable to me.

Frederik Slijkerman
Saturday, March 06, 2004

Actually, I was unaware that MainWin cost so much.  It's one of those situations where they don't prominently post the cost.

Also, I somehow missed that Kylix is apparently being ditched.  Annoying, but not completely out of line for Borland.  They dumped C++ for OS/2 long before IBM had messed up as badly as they did.

The Linux community indeed does not seem to much care about backwards binary compatibility.  After all, when you have the source code, why not just recompile?

Aaron F Stanton
Saturday, March 06, 2004

"WINE is an ABI compatibility layer, not an API library."

It's both. You can use it for both source code level and binary compatability. It's just that no companies are really bothering to port desktop software to Linux, so mostly it's only used for binary compatability.

The Kylix GUI (the app itslef, not the apps it produces) was ported using WINE. That's really the last major success story of it though (and that's several years ago).

Sum Dum Gai
Saturday, March 06, 2004

>>>
There are so many problems with the concept of desktop software for Linux it isn't even funny.  One often overlooked problem (by Linux users, not by businesses) is the support nightmare.  Microsoft does a pretty fair job of keeping Windows both backward and forward compatible, but since nobody "owns" Linux,  nobody is in a position to do the same on that side.  Thus your desktop application that runs great on kernel 2.2 might not run at all on kernel 2.6.  Or the application that runs perfectly on a particular version of Red Hat may not function at all on another distro, or even a different version of Red Hat (see: the libc split of a few years ago). 
>>>

So I should be able apps from Windows 95 correctly on Windows XP? Don't think so. Installing Winamp for different users is a mess, for just one example. Many games do not work anymore (e.g. Tie-Fighter 95, and others). I cannot even open documents correctly between Office97 and XP... Anyway, to stop the flaming and going on: one acronym for you: LSB. The Linux Standards Base was created to address these specific issues. The main problem you could have is a discrepancy between the compiler used in your app and the one used in the particular distribution (I'm mostly talking about versions of GCC here). If commercial apps want consistency, they should try to stick with and enforce the LSB.
Lastly, the libc split of a few years ago was a few years ago. I haven't heard of big app-breakings since.

>>>
As a company you are pretty much forced to peg your application to a very specific Linux release if you don't want to open a huge can of worms on the support side;  and then when you do this, they post a message about it on Slashdot and the vocal Linux users just bash the hell out of you....
>>>

So tell me, how do you think every open source Linux project manages to catch up? Mind you, not every one of them has the amount of developers the "stars" have (the linux kernel, apache, openoffice, the BSDs...)

Adriano Varoli Piazza
Saturday, March 06, 2004

I think your argument is pretty flimsy.  Virtually every example of broken apps between different versions of Windows is due to bugs in the applications that just happen to not have been tripped in older version of Windows.  If you stick to proper use of documented interfaces it just isn't an issue like it is on Linux.

The beauty part is I don't even have to bother debating you.  The lack of commercial shrinkwrap support for Linux speaks for itself.

Mr. Fancypants
Saturday, March 06, 2004

gcc isn't the problem, the libraries are.  Not all of them are available under the LGPL.

Simon Lucy
Saturday, March 06, 2004

What happens in the games world is suggestive of the desktop.  id Software released their Quake III Arena game for Windows, Mac and Linux, simultaneously if I recall.

The Linux version was a financial disaster -- I don't think it was even remotely worth it.

Another company by the name of Loki Games was working with Windows developers to convert games to Linux.  This company went bankrupt after failing to deliver on most of their projects.  I don't know if they were using WINE or what-not.

So it's been given a fair try in the games world, and no one made money.

Actually not a gamer
Saturday, March 06, 2004

>>>So it's been given a fair try in the games world, and no one made money.
>>>


They failed when almost nobody outside a server or a university was running Linux, didn't they? Though I accept that the market might not be ready right now either (linux usage is around 5% of the total, i believe, but still used more for servers and the like than for desktops), things are much different from what they were, and improving steadily. Perhaps next year...

Adriano Varoli Piazza
Saturday, March 06, 2004

>>>I think your argument is pretty flimsy.  Virtually every example of broken apps between different versions of Windows is due to bugs in the applications that just happen to not have been tripped in older version of Windows.  If you stick to proper use of documented interfaces it just isn't an issue like it is on Linux.
>>>

Tell me, how will that be affected by XP's SP2? Not flaming, but it's a good case of "backwards compat. broken". For a good cause, too. It was about time.

Adriano Varoli Piazza
Saturday, March 06, 2004

Acrobat for Windows may suck, but I don't recall it sucking anywhere near as much as on Linux.  On Linux, on top of crashing and being hard to use, it uses every remaining processor cycle, even when doing nothing.  You basically have to open Acrobat, read what you came to read, and then close it, so you can use other apps again.  It's that bad.

I'm not even sure it matters if it's no real inidcation that Photoshop would be that bad -- users (like me) think it does.

If you won't support your software when I upgrade my Linux system (say, from libc5 to libc6), well, I'm probably justified in not buying your software.  When Apple released Mac OS X, look how many Quark users switched to InDesign, because Quark took years to release an OS X version of Quark.  There's nothing special about Linux here.  If you aren't going to support your software 6 months from now, people aren't going to buy it.  Quake3, despite not selling well, runs pretty well on pretty much every recent Linux system; it's not impossible.

Finally, if you're afraid that on slashdot "users just bash the hell out of you", then don't get into any computer-related business.

KH
Saturday, March 06, 2004

I have paid for Opera for Linux (and windows).  I know others that have paid.  It's very hard to see how big the market is, but there is a market there.  Maybe in a few more years :)  After all, I just read the other day that Linux on the desktop has surpassed Mac.

saberworks
Saturday, March 06, 2004

" Uhh.. Do you know what MainWin costs?  Its only feasible for very high end applications, ones that sell for thousands per seat. "

To the contrary, it is not the initial cost of their porting tools that is the show stopper, but the terms of the distribution royalties. They have some extremely high minimum payments which can only be profitable if you ship thousands of copies so that the cost per copy goes to some reasonable number. If you have an app which sells for thousands of $ per seat, you won't be shipping enough copies to cover the costs.

The only other competitor comparable to MainWin is Bristol Wind/U which also has high toolkit costs but very reasonable distribution royalties. However, they don't seem to have updated their releases in about 3 years. It almost seems as though they have abandoned the market.

old_timer_at_home
Saturday, March 06, 2004

"What happens in the games world is suggestive of the desktop.  id Software released their Quake III Arena game for Windows, Mac and Linux, simultaneously if I recall."

However, the Linux version:

a) Wasn't available in all the stores where the Windows version was.
b) In the stores that did stock it, came in significantly later (at least here in Australia)
c) Cost about $40 more, as it only came in the "special" edition.

Hardly a fair comparison.

I agree that releasing games for Linux is probably not going to make you much money, but I don't think the quake 3 release really proved much. id were going to release Linux binaries no matter what, so people just bought the windows version.

That said, if you write your game well, porting should be fairly easy, and the amount of goodwill and publicity you generate from a Linux release may be worthwhile even if the sales aren't huge.

Sum Dum Gai
Sunday, March 07, 2004

And don't use Loki as an example of what happens to Linux Gaming (though I agree, it wasn't ready then). Loki died because the CEO was skimming money off the top, not putting any back into the company, and doing crazy things, such as not paying the developers for months of labor. I don't remember all the specifics, but you can google for it probably. The big thing to remember is that their demise was not due to a bad market for Linux games, but for corporate misdoings.

Ziktar
Sunday, March 07, 2004

"That said, if you write your game well, porting should be fairly easy, and the amount of goodwill and publicity you generate from a Linux release may be worthwhile even if the sales aren't huge. "

Why is goodwill and appreciation enough to warrant losing money? I don't care how much I like a company I can't buy their software if they go into bankruptcy.

Justo
Sunday, March 07, 2004

"Why is goodwill and appreciation enough to warrant losing money? I don't care how much I like a company I can't buy their software if they go into bankruptcy."

I highly doubt id lost money on quake 3 Linux. They were going to port the backend code to Linux anyway, because they needed it to run on that OS as a server. That basically leaves the UI and graphics. The graphics are open GL, and so are easily ported. Input isn't much code in your typical game, so I doubt it took that long to port.

I recall Carmack saying in his .plan file that getting the code to run on the mac only took a day, so I'd think the Linux port would be on the same order of effort.

They did sell several thousand copies of the game (initial run was 40K I think?), so even if only a few percent of those were to people who wouldn't have bought the windows version, it's still a win.

Finally, consider these words of John Carmack, about quake 2:

"Linux
I consider linux the second most important platform after win32 for id.
>From a biz standpoint it would be ludicrous to place it even on par with mac or os/2, but for our types of games that are designed to be hacked, linux has a big plus: the highest hacker to user ratio of any os. I don't personally develop on linux, because I do my unixy things with NEXTSTEP, but I have a lot of technical respect for it."

In other words, the 3rd party mods are a driver for sales of their games, and so it makes sense to get as many tinkerers as possible interested in their games. Hence, Linux is a good target platform for them.

If a game isn't designed with third party content in mind, this might not be so important. It's interesting to note that the three really big name games with first party Linux ports (the quake series, the unreal tournament series and neverwinter nights) all have big mod communities around them. I think if you want to be in this part of the games market, porting to Linux might make financial sense.

Sum Dum Gai
Sunday, March 07, 2004

Selling shrinkwrap desktop software is very hard on both Linux and Windows; try it and you'll see what I mean. Plus the two platforms are more different than you would think at a first glance so direct ports of software (in both directions) tends to suck badly.

Fancypants: The problem with Linux incompatible libraries is very much like the problem the Windows DLLs. The latter has stabilized since WinXP but that's very recent in history. The easiest solution is to link statically; your users hardly care about a couple of megabytes larger binaries and your software will run unmodified for a long time.

Jonas B.
Monday, March 08, 2004

I beg to differ on the subject of Acrobat Reader for Linux sucking more than on Windows.  Granted PDF is a crappy format and page based is sucky to navigate, but I do find Acrobat better than Xpdf and any other PDF reader I've used on Linux and (apart from 1 feature) it runs better and faster on Linux than Windows.  I find it slow on Windows and badly integrated with IE - maybe I'm more used to UNIX apps being poorly integrated :-) . That 1 feature that's better on Windows is mouse wheel scrolling which doesn't seem to have reached Acrobat for Linux yet.

John
Tuesday, March 09, 2004

I've run apps compiled for libc4 (many many versions of Redhat ago) on kernel 2.4. I'd try it now on Kernel 2.6 but I don't have the application around anymore.

There are cases when people do stuff that breaks (for example, RealPlayer used to open the sound device in a weird way), but the kernel maintains compatibility with even very old software. You just need to make sure you have the correct versions of the library and you will be fine.

The stuff that tends to be grossly incompatible is things like kernel patches (see Nvidia), and stuff that has some fairly unpleasant ties to external code. Also, the C++ ABI changing every compiler release didn't help, but that merely makes life harder, not impossible

Andrew Shuttlewood
Tuesday, March 09, 2004

We've been using Qt to develop simultaneously for Windows and Linux, and the experience has been positive so far. It is certainly a lot better than I remember MainWin to be (to be fair, I tried MainWin a long time ago). Not very expensive either, and you get complete source code. I'm not sure how good the ActiveX etc. support is - we do not use databases nor ActiveX nor a web browser. The GUI support seems pretty good, with some oddities on Linux. Child process control and communication also has some issues. Overall, though, I have no hesitation recommending Qt.

Arnab Bhaduri
Monday, March 15, 2004

*  Recent Topics

*  Fog Creek Home