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