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.

Run Kindle for PC in Linux with WINE

Reader Gene told us that Kindle for PC is "more important than people realize." That's because the desktop app runs almost seamlessly in Linux with one WINE tweak, making Kindle a great little laptop or netbook reading option.
To install Kindle for PC on your Linux system, make sure you've got WINE installed. Most major distributions (Ubuntu, Fedora, openSUSE) offer WINE in one of their repositories, or have versions custom-made for them.
With WINE installed, download the Kindle for PC installer, then double-click on the .exe file you downloaded. WINE will pick it up and install it in its virtual C:/ drive. The one issue you'll encounter is that Kindle will automatically start up and ask you for your username and password, even though you can't see the fields; you can quit the app and fix that, or just type in your username, hit Tab, then your password, and then quit.

Head to your system's menu and then to the WINE folder, and hit "Configure WINE"—if you don't see it, just run winecfg from a terminal or Alt+F2 prompt. In the "Applications" tab, hit "Add Application," then navigate to Kindle for PC in your virtual Windows drive, which is at C:\Program Files\Amazon\Kindle for PC\KindleForPC.exe by default. Hit OK, select KindleForPC.exe back in the Wine configuration window, and change the "Windows Version" drop-down at the bottom to Windows 98. Head back to your WINE menu, run Kindle for PC, and now all your controls and buttons should be showing up correctly.

You can now send books and sample chapters from Amazon's Kindle store to your PC. If you've already installed Kindle for PC in a Windows machine and tied it to your account, be sure to send your Kindle items to your Linux-based reader (which was "Kindle for PC 2" in my case).

Putty for Mac

$15.00