Not that i'm into digital photography in a big way but a number of people recommended me to try Picasa without knowing that i use Ubuntu. Looking at the google pages i discovered that they do a Linux version. I was going to try the windows version on wine before discovering that they had a linux version.
http://picasa.google.com/linux/learn_more.html http://picasa.google.com/linux/faq.html#23
Reading the two links i was interested to read the following sentence. "Wine runs on top of the X Window System and Linux or Unix. But it's not a Windows emulator; instead, it provides a Windows API middleware layer that enables Windows programs to run on Linux without the slowing effects of OS emulation or a virtual machine."
Having tried to learn about wine and virtual machines i've now found a sort of combination. One downloads version 2.7 .deb and then part of it is also running in Wine. This 'middleware layer' is perhaps something new and if anyone knows perhaps they could explain... maybe of interest to photographers amongst us!
thx james
On Sat, 2008-07-12 at 19:54 +0100, James Freer wrote:
Having tried to learn about wine and virtual machines i've now found a sort of combination. One downloads version 2.7 .deb and then part of it is also running in Wine. This 'middleware layer' is perhaps something new and if anyone knows perhaps they could explain... maybe of interest to photographers amongst us!
No Wine is the middleware layer, Google just package a tested version of this with the windows version of Picasa for the Linux version.
Wine isn't an emulator or a virtual machine, it is a reimplementation of the windows API that wraps the Windows executable and translates all the system calls to linux ones, because the core architecture is the same this is possible and a full platform emulation isn't required.
Unfortunately because wine is a result of reverse engineering Windows it will probably never be perfect. What google have done basically is make wine a QA target as if it was another version of Windows itself.
It's not actually a bad solution for code that can not or will not be released OSS. I'd almost prefer running a tested against Wine application than a closed source native one. You can effectively chroot wine away from where it can do any damage and run any untrusted closed source applications safe in the knowledge that really all they can do is contaminate your wine environment which is easily repaired. With a close source installation of a native package you don't really know what it is doing to your system. It also makes one of the key "reasons" for not supporting linux natively a moot point. That being the argument that there are too many changing versions/api's to track. Just target Wine 1.0 instead.
thx james
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Wayne Stallwood wrote:
Wine isn't an emulator or a virtual machine, it is a reimplementation of the windows API that wraps the Windows executable and translates all the system calls to linux ones, because the core architecture is the same this is possible and a full platform emulation isn't required.
This wording implies to me (probably not intentionally) that Wine is still an extra layer compared with Windows and brings performance drawbacks compared with a native environment.
Windows is, from the point of view of an application developer, a set of libraries of standard functions for stuff like drawing windows and managing user input (and network communications, sound, etc). A pretty big library, of-course, but it means that applications that use the Windows API tend to have a standard look and feel, and (in theory anyway) when you go from (say) Windows 3.x to Windows 9.x to XP to Vista the applications keep working (the APIs are still there) but the applications look new, because they use the new window decorations.
In other words, Windows is (as any operating system is) a layer between the hardware and the application. Wine, by implementing the Windows API on Linux and other platforms, means that applications that look for the "draw a window" function that Windows provides will find one that works the same and the application need never know anything is different.
In many cases that is case of mapping Windows functions to the equivalent Linux ones, as surprisingly enough there are functions to draw windows in X as well, they just have different names and parameter lists so a little magic between the two is needed. However there are also other functions that are implemented within Wine (rather than just mapped elsewhere). Whether a Windows application is faster in Windows or Linux therefore depends on which calls it makes, and whether the functions used are written "better" in Wine than in Windows (not uncommon), or if the underlying Linux function being mapped to is written better than its Windows counterpart.
In practise most Windows applications that run under Wine do run slower, albeit often not noticeably, under Wine, but that is a function more of the development that takes place on Wine being focused more on implementing the missing functions than on improving the ones that work, albeit slower. It is quite possible with the way Wine is implemented for it to be faster in some or most (all?) cases than Windows for the same application, but it's not there yet. It is quite feasible, for example, that in time the DirectX equivalents in Wine will allow Windows games to be faster on Linux than under Windows.
I only bother making this point because there is a general "understanding" that Wine is necessarily weaker than Wine, and that does not need to be the case. Not least because should games developers (for example) choose to target it then they have access to the underlying source code to improve on areas that are not working well for their application, something they cannot do with Windows. A Wine-based "Windows" game could be shipped with a complete optimised operating system and I'm sure that the result would be better than trying to run on a typical Windows desktop with all its little applications running in the background (not to mention viruses and spyware slowing the system down). Google ships a suitable version of Wine with Picassa to simplify the installation but I'm sure eny improvements they made to Wine along the way have been fed back for the general use by the rest of us in other Wine-based applications.
On Mon, 2008-07-14 at 10:06 +0100, Mark Rogers wrote:
Wayne Stallwood wrote:
Wine isn't an emulator or a virtual machine, it is a reimplementation of the windows API that wraps the Windows executable and translates all the system calls to linux ones, because the core architecture is the same this is possible and a full platform emulation isn't required.
This wording implies to me (probably not intentionally) that Wine is still an extra layer compared with Windows and brings performance drawbacks compared with a native environment.
It wasn't intentional but in most cases it is true for most aspects of wine. My belief is that in circumstances where wine is faster it is because the underlying Operating System is more efficient or is doing less (no spyware/av scans, norton hogging half the memory etc) and not that the Wine implementation of the Windows API is somehow more efficient. That may not always be true of course and I am not saying that the wine devs couldn't produce faster implementations, just that as you say that is not their priority.
It is quite feasible, for example, that in time the DirectX equivalents in Wine will allow Windows games to be faster on Linux than under Windows.
I have heard that before but I am not sure I understand why. Direct3D implementation for example will presumably have to translate everything to OpenGL because it can't talk to the hardware directly and the linux drivers for say an Nvidia card aren't going to understand DirectX are they ? So ultimately it will have to be another layer surely ? If nothing else that means that the GFX will be more CPU bound than when running on windows or am I missing something ?
I only bother making this point because there is a general "understanding" that Wine is necessarily weaker than Wine, and that does not need to be the case. Not least because should games developers (for example) choose to target it then they have access to the underlying source code to improve on areas that are not working well for their application, something they cannot do with Windows.
Not being a developer I am unsure but how easy is it for people to target wine as a platform rather than windows ? What limitations exist in wine that would somehow degrade the application on Windows ? Is there an automated way of actually having wine as a target at build time that could improve things ?
Asking developers to QA against wine is one thing, asking them to QA against it and then either code around areas where the implementation isn't complete (whilst making sure this doesn't produce bugs when running native on windows) or participate in the reverse engineering of windows to fix the implementation where it falls short seems like almost as much effort on their part as simply designing the code to be more portable from the outset and then building for Linux native.
I am presuming that most implementation holes in Wine are missing stuff rather than stuff behaving differently so would it be possible to make say visual studio target wine and then there be a more than reasonable chance that the application would still run as well on Windows ?
sorry for any naivety there..as I say I am not a developer
Google ships a suitable version of Wine with Picassa to simplify the installation but I'm sure eny improvements they made to Wine along the way have been fed back for the general use by the rest of us in other Wine-based applications.
I think Google say that "most" improvements have been fed back, I am not sure why it is "most" and not all unless the other changes are just to do with the way it is packaged with picassa, I am also not sure what happens when the packaged version is older than a version you already have installed.
Wayne Stallwood wrote:
Not being a developer I am unsure but how easy is it for people to target wine as a platform rather than windows ? What limitations exist in wine that would somehow degrade the application on Windows ? Is there an automated way of actually having wine as a target at build time that could improve things ?
Having done odd bits of Windows development I've found pretty much everything I've written has just worked under Wine without modification so I have no experience of this.
Wine as a build target isn't all that meaningful; the whole point is that Windows as a target should make Wine a viable target too, although I guess you could have different build options that disabled features that didn't work in Wine or that did but were less efficient than the approach used in the Windows build. The result should still run under Windows, though.
In my experience the worst culprits seem to be installers; I have no idea whether the application would work because the installer does weird things that do not run under Wine, so you never get far enough to test the app itself.
Asking developers to QA against wine is one thing, asking them to QA against it and then either code around areas where the implementation isn't complete (whilst making sure this doesn't produce bugs when running native on windows) or participate in the reverse engineering of windows to fix the implementation where it falls short seems like almost as much effort on their part as simply designing the code to be more portable from the outset and then building for Linux native.
Wine devs are generally quite keen, particularly with large/high profile apps, to work with devs - or at least that's the impression I get.
Testing the app, feeding back the results to Wine devs and saying "I have no idea why this doesn't work but I'm the app developer and have access to the code, I can help you work out what is breaking in Wine" is probably a pretty good starting point. After all, if it runs in Windows it pretty much makes Wine the culprit, so the dev doesn't have to risk their pride (do real programmers have that kind of pride?)
I should think that many times when something doesn't work the Wine devs would quickly recognise the symptoms and either suggest a workaround or know where to go looking.
I am presuming that most implementation holes in Wine are missing stuff rather than stuff behaving differently so would it be possible to make say visual studio target wine and then there be a more than reasonable chance that the application would still run as well on Windows ?
Making something like Delphi do that might be more likely (Visual Studio's developers bosses might have something to say about VS targeting Wine...).
I think it's usually pretty easy to tell if it's a missing API call just by running the app through Wine at the commandline and looking at the errors and warnings.
I think Google say that "most" improvements have been fed back, I am not sure why it is "most" and not all unless the other changes are just to do with the way it is packaged with picassa, I am also not sure what happens when the packaged version is older than a version you already have installed.
There's little point passing back changes that have no mainstream use, they'd not be accepted upstream anyway. Whether Google are inclined to "bodge" Wine to make Picassa work I have no idea! But I assume their changes are made available as source under the conditions of the licence so I doubt there's any secrecy.
The packaged version acts just as a local library, AIUI. It certainly has no impact on the version of Wine installed, and coexists with Wine quite happily.