Canonical to bundle CodeWeavers CrossOver?

In a official post on the Ubuntu Forums, user Matthew (a official Canonical employee?) asks users to complete a survey with the applications they would like to see in the upcoming versions of Ubuntu.

Among the applications one can find: Spotify, Pandora, Hulu, Skype, WoW, Picasa, Adobe Photoshop, Apple iTunes, CodeWeavers and a couple more applications.

I'm wondering if Canonical has plans to bundle CodeWeavers CrossOver with forthcoming releases? Most of the applications CodeWeavers already supports and the one or two apps they don't officially support will already run as Unsupported apps in CrossOver now. The only change would be for CodeWeavers to officially support the apps in a upcoming release.

So ask people what Apps/Games they would like to see running on Ubuntu then ask if they would also use Codeweavers..... I suppose if enough people say YES to the CodeWeavers question we just might see a bundle between the two companies.

Here is is the post, and link to the survey :

Please help the Canonical and Ubuntu leadership
We are trying to gather preferences for the apps that users would like to see in upcoming version of Ubuntu. While we all believe in the power of open source applications we are also very keen that users should get to choose the software they want to use. There are some great apps that aren't yet available to Ubuntu users and Canonical would like to know the priority that users would like to see them. This list is indicative not definitive and we would love to also read your suggestions in the free text box.

They are also requesting that anyone who has comments please do so here.

Note: there has been some confusion that I would like to clear up--this is not about applications to be included by default, but merely things that we may attempt to make more easily available for Ubuntu users to install for themselves from official repositories.

ReactOS Arwinss to use more Wine code

All,
Today I would like to officially announce the (sub)project I was working on for the last half a year, and make a call to developers to participate.

ReactOS has been around for about 11 years, and it's been growing each year since then. The demand for an open source Windows-compatible operating system is huge: geek, servers, netbooks, accounting, point of sales, CAD... The list could go on and on.

Time goes by, new versions of Windows operating systems are being released. ReactOS usability still has not reached any significant value. Not to say ReactOS didn't even officially enter the Beta stage. Separately, there are many achievements: audio support appeared, bootloader is able to boot real Windows, some Windows binary drivers could be loaded and work in ReactOS, networking is being improved every day, the kernel is being actively worked on too. But all of that does not really matter for the end user. For a user it's important that a web-browser loads websites, instant messenger client connects and works, [Microsoft/Open] Office shows documents, email client gets new messages.

This bare usability is what's still missing, and if it continues to be like this, I am afraid our project won't be of much use in another 10 years. Certainly, I became very concerned and started analyzing situation. Being opensource project without major commercial sponsors, there are certain limitations as to what could be done to improve the situation, so mainly it's a matter of picking right priorities and properly managing (motivating) existing human resources.

The part of ReactOS which plays major role in compatibility and usability is Win32 subsystem. Right now, it's a huge monster which requires a lot more human resources than we have now. It's very hard and time consuming to reach even Windows 2000 level of compatibility with current amount of participating developers, and high entry level.

I came up with something which could solve this problem: Arwinss. To better explain what it is, I made a special presentation (URL to slides in PDF format is in the end of this email). Please imagine myself talking through it as I didn't perform/record it.

Now, after you read through the presentation, I would like to make a proposal to all developers (even newcomers, who never worked on ReactOS before). Let's make an Arwinss week, or Arwinss month. Every developer could definitely find a few hours during a week to hack Arwinss. Entry level is rather low, there are some basic docs about Arwinss in the wiki, and I am happy to consult about details.

If I could make this new subsystem out of nothing (out of Wine and ReactOS) almost alone (Kamil and Smiley help is very valued and appreciated!) within a few months, imagine what we could do all together?

With the best regards,
Aleksey Bragin.

The presentation: (links to further information are in the presentation too)
http://www.reactos.org/media/docs/2010/arwinss.pdf
http://www.reactos.org/wiki/Arwinss
http://www.reactos.org/wiki/Arwinss_technical

Briefly, what was done:

• gdi32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL.
• user32.dll - source code is nearly unmodified from Wine, but compiled in ReactOS tree, into a real PE DLL.
• What about Wineserver, you would ask? SERVER_START_REQ and related macros are rewritten to perform a syscall to win32k.sys (more about win32k.sys below). Server protocol is the same, but of course many requests aren't need.
• winex11.drv - this is the one if you want X Server to be your interface. This is unchanged Wine source code, again compiled inside a ReactOS source tree into a PE DLL
• winent.drv - an alternative user/gdi driver, which mostly forwards all calls into a kernel mode graphics engine located in win32k.sys (which is compatible with Windows video drivers, so all acceleration could be used).
• win32k.sys - kernelmode counterpart of the new Win32 subsystem, contains graphics engine, user server which is based on a small part of platform-independent Wineserver source code adapted to kernelmode, and a simple window manager which calculates visible regions for windows and manages window showing/hiding.

Macs And Windows

As a confirmed Mac-head, I have always bemoaned the fact that there has not, until recently, been enough interest shown in making applications usable for the Mac. Well, that has changed for several reasons. First, the Mac is now using the Intel chip, which is the same as in PC's. This means virtual Windows software is much easier and faster running on Macs. Second, Apple has the benefit of "cool," what with iPods, iPhones, and all sorts of other neat products, like their wafer-thin and light MacBook Air, so more people are buying them. Finally, the sheer power of the latest Mac's and their own native Boot Camp allows virtual Windows to run on the machines with little drop off in performance.

Even better is not having to purchase Windows in the first place. Wine, which stands for Wine Is Not an Emulator, was first designed for Linux. As the the web site says, "Rather than acting as a full emulator, Wine implements a compatibility layer, providing alternative implementations of the DLLs that Windows programs call, and processes to substitute for the Windows NT kernel." However it works, if you are good at programming, you can implement Wine for free. However, a company called Codeweavers is compiling a database of Windows programs that will run under the Mac Wine interface, so that Mac owners can use their computers at work without switching. As a Codeweaver advocate, I try to get my chosen Windows programs to run under CrossOver, the Wine program from Codeweavers. So far I am batting about .500, which is not too bad. It is great when a program to which you were denied due to your computer choice suddenly works.

Putty for Mac

$15.00

Wine Is a Long Shot at Solving the Windows Apps on Linux Problem

The open-source Wine project is less a solution and more a workaround when it comes to the issue of running Windows applications on Linux.

After devoting my last couple of columns to the topic of choosing an alternate OS (in particular, Linux) without giving up your Windows apps, I didn't plan on extending the discussion further—that is, until a lively reader exchange prompted me to turn that pair of columns into a trio.

If we're to discuss Windows applications on Linux and other Unix-like operating systems, how can we forget about Wine, the open-source project devoted to building a sort of shim between the APIs that Windows applications require and the equivalents of those interfaces on a Linux machine?

I've been keeping tabs on Wine for as long as I've been following Linux, and my exclusion of Wine was less about having forgotten about it than about having set it aside—at best as a “maybe someday” solution and at worst as an altogether lost cause. For a time, I hoped that Wine would be the answer to the Linux apps chicken-and-egg problem. However, things never quite worked out that way.

First off, many (it's probably safe to say most) Windows apps don't run under Wine at all. For instance, neither of the two Windows-bound applications that I miss the most as a Linux user—iTunes and the VMware vSphere client—works under Wine. In the case of iTunes, Wine lacks USB support, so there's no way to use it to communicate with my iPod Touch. The vSphere client relies on Version 3 of Microsoft's .NET framework, which Wine does not

What's more, even when it is possible to get your Windows apps running on Wine, various tweaks are often required to get there. For instance, while getting reacquainted with Wine to write this column, I found that the Windows apps I tried to run appeared on my desktop with jagged-looking fonts. I managed to enable font anti-aliasing to address the issue, but only after fiddling around in the registry of my Wine installation.

Once you've gotten an application running, the next set of system updates you apply—whether to your Linux machine, to the Windows app in question or to Wine itself—could well sour your installation, requiring still more tweaking and forum searching.

For certain popular applications, you can save yourself some of this hassle by purchasing a Wine distribution such as Codeweavers CrossOver product as a way of outsourcing some of that tweaking and searching work. But if you need support from your application's vendor, I imagine you'll have a tough time finding Wine in any supported configurations matrix.

For all these reasons, I can't see Wine serving as a reliable option for addressing the Windows-apps-on-Linux problem. Rather, it's a workaround, something to keep in mind and try if you're in a pinch, but not something to count on.

Now, if, as the reader I discussed this with suggested, all the big Linux vendors got together and invested in Wine, I don't doubt that they could improve the project a great deal.

According to the project's bug tracker, some work toward USB support is under way, and versions of the .NET Framework earlier than the one I need for the vSphere client are reported to work.

However, these vendors have reacted toward Wine with unambiguous ambivalence for going on 10 years now. Considering how slow the projects and companies that drive Linux have been to seize on and integrate the largely Linux-powered apps of the Web into first-class citizens of their desktop distributions, it's tough to imagine them working hard to enlarge the application base for Windows.