Google Windows Apps Coming To Linux

skaet writes "DesktopLinux.com reports that Google is working together with CodeWeavers to bring their photo editing and sharing program Picasa, formerly only available on Windows, over to Linux. From the article: 'The program is now in a limited beta test. If this program is successful, other Google applications will be following it to the Linux desktop, sources say. The Linux Picasa implementation includes the full feature set of the Windows Picasa 2.x software. It is not, strictly speaking, a port of Picasa to Linux. Instead, Linux Picasa combines Windows Picasa code and Wine technology to run Windows Picasa on Linux. This, however, will be transparent to Linux users, when they download, install, and run the free program on their systems.'"

Comments

Google earth??

[Anonymous Coward]

Google earth on linux please!

IBM nah Google.

[jellomizer]

I think Google by some magic will be able to make Linux for friendly to the desktop far more then all the money that IBM and SUN puts into it. Because it seems that Google may actually do something about it while the other guys just R & D it . The program looks like it may fill in an other knitch that the GIMP may not be able to handle easily. It seems to be a lighter photo editing tool.

Re:IBM nah Google.

[Anonymous Coward]

Right.... because Google sure has a history of producing good client side software... Get a grip people, Google makes the best search engine and a good email interface (IMO it's not even that good but that's another topic). Everything else that they've made has been extremely mediocre at best (Google Video, Google Talk etc.). Saying that they have the ability to make Linux acceptable to the masses more than Sun or IBM, who are two of the worlds biggest open source contributors, is beyond ridiculous.

Then you go on to say, "the other guys just R & D it". Oh please, it'll be years, if ever, before Google can claim that they've produced a fraction of the amount of Open Source code as IBM and Sun. There is no company that the R & D statement would apply to more than Google. IBM and Sun produce a ton of Open Source code, whereas Google produces almost nothing. These aren't even going to be native Linux apps and several of those apps already work in Wine.

I love the words you used as well, "Google by some magic". Sheesh...

Re:IBM nah Google.

[Anonymous Coward]

Er, the work Sun did to add accessibility to Gtk+ is probably 60,000 times more meaningful for desktop linux than having CodeWeavers get Picasa to run with Wine. You might as well say that EA is doing more than IBM and Sun to promote desktop Linux by virtue of having made Battlefield 1942. Sure, they didn't port it to Linux and it runs in Wine. But that's way better than ATK!

Ughhh.....

[segedunum]

Wine. So that means their still Windows applications then?

Re:Ughhh.....

[makomk]

Wine. So that means their still Windows applications then?

Sort of. If they're porting it in the usual way, it'll still use the Windows API but will be a Linux ELF binary. (The actual program binary *might* be a shared object, depending on whether CodeWeavers use the standard wineport tools or some custom-developed toolkit of their own).

Re:Ughhh.....

[gutnor]

Technically maybe but what is important is that for a linux user it looks like a linux application. It will be supported like a Linux application.
It is not a hack you need to do and support yourself in the back of the original developer.

In any cross-platform development you try to limit the difference between different platform source trees, generally you isolate all platform specific functions in a common framework and only port the common framework on different platforms, leaving the rest of code unchanged.
There are plenty of cross-platform frameworks for plenty of use ( from simply using stdio.h to opengl ), in this case they choosed WINE. That is surprising yes, but that does make sense for a project that need to be crossplatform retroactively.

You can see that Google apps are still Windows applications but you can see them as using a cross platform framework developped conjointly by Microsoft on Windows and WINE team on Linux :-)

Yuck

[Anonymous Coward]

Using programs in wine is painful. It's definitely one of those areas where you only do it if you have to, not if you have a choice. Since Picasa is hardly the only such program available for Linux, why bother if it's only going to be half-assed? Who wants to manage a wine installation to run Picasa. Anyone? Do any of you really want this?

The solution to complaints that Google makes no effort to port their software to Linux isn't to get CodeWeavers to make it run when used with winelib. It's to port the software to Linux. Otherwise just tell Linux users to sod off, because that's basically what linking with wine is doing.

Re:Yuck

[raventh1]

First: You have to commend them because they are taking any step to cross-platform.
Second: If any step succeeds, another is likely to be taken.
Third: Other companies will be watching Google, and they may decide it's worth the time to at least start with wine. A foot in the door may lead to a complete port.

Re:Yuck

[lahvak]

It's not going to run "in wine". They are linking it with winelib to make it into a native Linux application without having to completely rewrite it. Winelib provides the interface between Windows API and Linux API. It is similar to porting Unix applications to Windows using Cygwin.

Re:Yuck

[alienw]

There is no difference between Winelib and Wine applications. This is a myth. It's about as much of a difference as linking a program statically versus using dynamic libraries. It's not noticeable from the end-user point of view. A winelib app can have just as many bugs and will be just as fast (or slow) as the wine version.

Re:Yuck

[hey!]

The most stark difference between Cygwin and Wine is that Cygwin is functionally-complete, while Wine is not.

However, if you are a developer using it as a compatability library, presumably you test your applications so they perform the way you intend. If a feature doesn't work right, or it's too slow, then you do it a different way. There's always a different way. Generally your first cut is pretty far from what you'd wish on any implementation of any set of APIs, which is why you test in the first place.

Users trying to run software in which running against WINE are in a completely different position. They're hoping that an app will run well against WINE, even though it has never been tested against it. If it doesn't run well, not having source code they don't have any recourse. Given these unfavorable preconditions, WINE works remarkably well.

The only reason to use WINE as a developer is to port existing Win32 apps to non-Windows platforms. If you are targetting Unix, or intending Unix/Win32 compatibility from the outset, there are better choices.

There is no reason in principle porting your app to Win32 using WINE with a bit of testing can't work, but whether it is practical depends on how much tweaking you need to do to make things work well on both platforms. My guess is that most people looking at this choice don't think it is practical. If getting your Win2000 app to work on WINE as as easy as getting it to work on Windows XP, then I'm sure many more people would be eager to make a Linux offering.

Google has money and is technically innovative. Having a player like this attempt a port of their Win32 app to WINE could be a very interesting development. If they're only going to throw out a half baked version of their closed source Win32 apps, it's hardly important news. But if they contribute back improvements to WINE or create an open source facade that abstracts the differences between the two, it could be very significant.

PPC Linux support? SPARC Linux support?

[CyricZ]

Typically when one says their software support Linux, it means that their program can be compiled (or at least easily ported to) the major non-x86 platforms, including PPC and SPARC.

Wine, however, is only for x86-compatible systems. Will this software from Google only run on x86 Linux systems, and not on PPC Linux and SPARC Linux, amongst other Linux ports?

Re:Wine Source Code Patching

[CyricZ]

Borland used Wine to port their Delphi IDE to Linux a while back. It didn't work out well, and that's part of the reason why Kylix is not longer being developed.

Not a good way to do it, however.

[CyricZ]

But the problem with Wine is one of quality. That's not to suggest that the Wine team hasn't done a great job. They sure have, considering what they have to work with (the Win16 and Win32 APIs). But the past ports of software to Linux via Wine have been terrible. Kylix is one example, and the port of WordPerfect by Corel another. They were slow, buggy, and not very impressive.

Re:Not a good way to do it, however.

[strider44]

They were also a long time ago, at least in terms of computers. Wine has come leaps and bounds especially in terms of stability in just the last year. One of the main ideas behind this however is that Google will know which functions are needed, which lightens the set almost immeasurably. This is a relatively small program compared to WordPerfect so all they need to do is ensure those functions they use are stable, and when they want to port another program along they need to expand the set of functions that they need to be stable to incorperate the functions that program needs and do the maintenance job on that.

They also have the advantage in that they can modify Wine to suit the program and the program to suit Linux should they need it, and advantage that you don't have running Wine on your average computer. They can, for example, rewrite the file loading code to take advantage of the GTK file selecter and grab the files directly from the operating system. They don't *need* to go through the C:\ file system emulation, one of the bigger issues with Wine. They can also probably with small modifications route their audio through GStreamer, cutting out the Wine audio library which is sometimes considered buggy. If a certain section of the program proves buggy, they can simply port that section and do the rest through Wine.

Seriously, I think if a Linux version of Picasso ends up buggy then it's Google's fault, not Wine.

Headline:

[blkros]

Google Throws Linux Users a Bone
An old, marrowless, dried up, bone, with no meat on it, and, yet, there it is.
Basically they're making a Windows app run on Linux, using Wine. Why didn't we think of that?

Re:Wine Source Code Patching

[aug24]

AFAIK, the entire API of wine is provided in the WineLib headers, which means that windows source can be statically compiled against it (assuming all the APIs you want are there which is mostly true now).

Usually however, people don't have the windows source, so the runtime implementations are used and the calls become dynamic. There's the same code behind of course.

There should be a Wine expert along shortly to point out the gross over-simplification in what I've just said ;-)

Justin.

Re:People will moan and bitch about more free stuf

[nogginthenog]

I'm just guessing but presumably they make money when you order prints from Picasa? e.g. Kodak pay them a referral fee?

native

[goarilla]

I wonder why they just dont make a native port?

Re:native

[Yaotzin]

Because they can't be arsed.

Re:native

[moranar]

Because it costs too much money for the potential marketshare gains.

Re:People will moan and bitch about more free stuf

[Professor_UNIX]

Do you really want the majority of Linux software to turn into what they have on Windows and Macs? The vast majority of software on those platforms is binary-only shareware. Everytime some pissant little programmer writes a program to do anything of consequence they slap on a registration requirement and it instantly costs $25-$50 for some stupid little utility. With Linux, on the other hand, the vast majority of software is not only completely free, it's open source! Unless we continue to support open source products and shun the closed proprietary binary-only shareware crap the Windows and Mac users are stuck with the Linux platform will lose one of its main rallying points.

Re:Cool

[JesterXXV]

The combination of your comment and your sig just made my head explode.

Oh goody. Can't wait.

[squoozer]

Why are they bothering? This is going to be greeted with all the enthusiasm of someone breaking wind in a swimming pool. It's great that Google have realized that it has people who want to use it's services that run linux but unless they are going to do the porting job properly I don't think they should do it at all.

Perhaps that's a little harsh but I don't want some clunky Windows app with a ton of Wine libs following it around cluttering up my system. Personally I find digiCam to be as good if not better than Picasa so I think I'll stick with that - certainly on Linux I feel that is the application they are competing against.

Picasa is NOT a photo editing tool.

[rduke15]

Unlike what you seem to think, Picasa is not a photo editing tool.

Rather, it is some sort of photo organizer/viewer. It does have a few (very simple and easy to use) tools to enhance contrast/color etc., but it's purpose is nothing like Photoshop/Gimp/PaintShopPro/etc.

Sorry for not being more clear about what it really is. It's probably because I still wonder myself... Maybe someone who has actually found a use for it can be clearer.

Good for Google.

[spicyed]

It's great that google realizes that programs need to be ported to linux, however hopefully you don't need to use codeweavers software to use it. Or wine even, I don't want to have to install wine myself to use this, it would be nice if Google wrapped winelib in with Picassa. (which they most likely should).

Re:Wine Source Code Patching

[Solder Fumes]

The reason nobody uses winelib is because it's completely pointless. Using DLLs is just as fast and tends to save a lot of space on your hard drive over static linking.

Valid, unless you actually want your application to WORK.

Why do it half assed

[TheSkepticalOptimist]

Honestly, if Google was truely serious about creating a Linux based GOOS then why do a half assed "port" of picasa using Wine. Wine has always resulted in half assed implementations of Windows software, often lacking real performance and often many features disabled. I am surprise Google with all their newly minted billions would not just higher a bunch of Linux Developers and make a native Linux version of Picasa.

And don't fool yourselves, Wine IS an emulator. Anything that has to mediate between native software code and native OS/Hardware code is an emulator. It may not be a hardware emulator (i.e. not translating to machine code the software code wasn't written for), but it is a software emulator translating windows calls to Linux calls. And in any case, emulators are slow.

Re:Why do it half assed

[WhiteWolf666]

Anything that has to mediate between native software code and native OS/Hardware code is an emulator.

Are GTK, QT, and Mono emulators?

Hell, what about XGL and/or Xorg? Or GTK on Win32? What about Cygwin? What about Xen, or VMware, or Java?

What is an emulator, anyways? What's the difference between "native" and "foreign"? How many layers of translation are okay? What if an app relies on libc? That's "translation" between native (assembly) code and the hardware.

Your understanding of these things is very, very limited. Emulation can be really fast (VMware), and in any case, Wine is an implementation of Win32 for Unix based systems. That's all; no more, no less. It's not really all that different from the Linux environment for FreeBSD, or even QT/GTK.

Don't get me wrong, there are speed problems. But these are not design issues, they are implementation issues, and are things that can be solved with programmer time. There is no fundamental design reason why Wine should be slower than Windows; indeed, as long as Linux is faster with the underlying hardware access, Wine can be significantly faster.

Re:People will moan and bitch about more free stuf

[Criterion]

Y'know what? If you don't like shareware, don't use it. Use the free stuff. I like free stuff, you like free stuff, we ALL like free stuff. It's not like it's gonna dry up and blow away, and some competition from closed source apps would be good all around I think. If the free app can't hold up against some "stupid little utility", well then it probably wasn't that good to begin with, and the only reason it was being used was because it was free, and the only game in town. To me, the main rallying point of Linux is that it's not made by MS. I could care less if it was free or open source, really (if that's your thing, more power to ya, I just want my machine to do what I want it to in order to work or play). I've paid for many distros in the past, I forsee that continuing into the future, and I don't have a problem with that because I know the difference between free beer and free speech.

I, for one, would absolutely love to see apps such as AutoCAD and 3DS Max running native on Linux. Give me commercial apps. I'll buy 'em, as would many others. Sorry guys, it's not just a hobby OS anymore, nor is it just for servers. We want workstation apps, not just a word processor, spreadsheet and solitaire. Nor do I want windows app compatability. I want NATIVE apps. While I'm not thrilled about the winlib idea here, it is indeed a step forward.. as long as they keep going forward and the first chance they get to do a re-write (major version change maybe?) do it for full cross compatability. I can see using this to get started down the path of richousness, but not as an end goal. I do NOT want anything like the OS/2 win compatability to happen (which was, IMO the downfall of OS/2).

Wordperfect Office 2000 for Linux anyone?

[caseih]

Remember when Corel "ported" Wordperfect to Linux? They used wine and it was a miserable failure. However Corel's attempt failed where google might succeed as maybe google won't make the same mistakes.

Corel forked wine to add some custom features they needed that head wine didn't have (fonts and printing, for example). This fork proved their undoing. It was never synced back to the head branch and soon died, orphaning their version of wine. Further glibc advances broke wine with every release, effectively preventing corel's wine from running on anything newer than RH 7.

As long as google doesn't do the same thing, we'll probably be okay.

Re:No, port WorldWind instead

[Anonymous Coward]

> why not look at NASA's World Wind and port it to Linux yourself?

There are many possible reasons why.

1) maybe he/she isn't a coder

2) maybe he/she doesn't have time

3) maybe he/she prefers Google Earth

In this Open Source World, are we not allowed to express a wish for developers to do development we'd like to see, without being told "stop being so passive" "do it yourself"? How ridiculous.

They shouldn't waste their time

[panic911]

everybody knows that linux ppl are so pretentious they would never be caught dead running a closed source app (which I'm sure this is going to be). there are alternative photo apps out there that are open source, so why would anyone use this? props to google for extending to the linux crowd, but i think they're wasting their time.

NOT just a Windows port

[vivarin]

I was one of the original developers on Picasa. Two things you might want to know. One: a LOT of Picasa, particularly the main UI code, makes extremely light use of the Win32 apis. Two: If you check the WINE logs in the last while, you'll see a lot of beneficial commits coming from Google employees. Some of these were directly inspired by Picasa, which *does* make use of some of Windows' more obscure APIs that WINE didn't have full support for initially.

Have you ever used Google Talk?

[moultano]

Personally, I think google talk is the nicest IM client I've ever used. Every little thing about it is done right.

Like to know when someone IMed you but don't want timestamps cluttering up your conversations? It will insert subtle timestamps in any long pause in the conversation.

Don't like multiple chat windows cluttering up your screen, but don't want to embarass yourself? Google talk's stackable shadable windows are just the thing.

You get the idea. Every single part of the interface seems like an ingenious compromise between the pros and cons of features that other IM clients have tried.