The Desktop War
Linux users can run not only native Linux programs but also many DOS, SVR3 Unix, SVR4 Unix, and Macintosh programs by using emulation programs. It is very clear that this makes Linux a more universally useful system. There are emulators for lots of older computers as well, including Apple ][, Commodore 64, and others, which are useful to some people, and certainly fun for people who like games they used to play on their old computers. What has been missing from this list so far has been real support for MS Windows programs. This is a pity, since there are more applications for MS Windows than any other computing platform on the planet. Not only are there many applications, but they are well-known, and people know how to use them.
Some people have decided that MS Windows has won the desktop war, and there will be no competition for the foreseeable future. I think that assumption is a little premature, for two reasons. The first is that despite the fact that MS Windows has more applications, many of them are not particularly high quality. The second, and far more important reason, is that even if you concede the API war to Microsoft, doesn't mean that Microsoft has won the war for the desktop. That is, even if all the applications out there were written only for MS Windows, MS Windows wouldn't be your only choice for an “operating system”—it's possible to emulate MS Windows. It's even possible to do a better job of it than Microsoft.
It's also important not to loose perspective; there are applications that Linux already runs, without any MS Windows emulation, and Linux is already a wild success in many important areas.
Most Linux users are aware that for about two and a half years, a team of programmers has been steadily working on a project called Wine, which is essentially a near-clone of MS Windows designed to run under the X Window System. For a long time, Wine could run only simple programs like Windows Solitaire, and when some onlookers waited for a whole month after Solitaire worked, and found that Microsoft Word still didn't work under Wine, they decided that Wine was dead and proclaimed their amazing deduction to all readers of the Linux Usenet newsgroups—though they neglected to include their skewed logic—which caused some other readers to believe them.
The Wine developers plodded carefully along, undeterred, and Wine has slowly matured, and is now approaching general usefulness. While each new release of Wine is still “for developers only”, some “real” MS Windows-based applications are starting to work. That doesn't mean that they are useful yet—there is no support yet for printing from Wine, for instance—but it does mean that the Wine developers are still making steady progress.
Some Linux users have heard that a new company called Willows (www.willows.com) is developing a commercial programming library called TWIN, which was just released as BETA software a few weeks ago. It allows developers to write applications for MS Windows and then turn them into native applications (which maintain the MS Windows look and feel) on Unix and Linux systems, and in the future (according to Willows), Macintosh and OS/2 systems.
While TWIN is explicitly not being sold as an MS Windows emulator—“...we do not currently provide [or] support pure emulation capability for “off the shelf” products (such as MS WORD and EXCEL) as a stand-alone capability.''—they do provide the ability to run MS Windows-based binary programs that developers need, including both DLLs and EXEs. Their FAQ states: “I am currently running Microsoft Office Applications, Word, Excel and Project. These are the best ways for us to verify the library...”
Now that Willows' TWIN has been released, it is appropriate to compare it to Wine. The most important difference is that Willows says that TWIN is intended only as a developer's tool, and that the binary capabilities are intended to help developers. By contrast, Wine is intended primarily to become a tool for end-users to run their normal MS Windows applications, and the developer's library which comes with it is almost a by-product (which doesn't mean that it is low-quality or useless). Wine runs only on Intel platforms, whereas TWIN has “binary emulation” and can run on other platforms as well. TWIN can use standard MS Windows printer drivers, whereas printing support is still missing from Wine. TWIN is commercial software, and Wine is freeware. TWIN is more complete.
Willows is also participating in an effort to make an ISO standard, non-proprietary version of the MS Windows programming API. The Application Programming Interface for Windows, or APIW, is a publicly available standard that will not only help Willows, Sun, and other companies that wish to clone the MS Windows programming interface, but will also help the Wine project in two ways:
By providing more documentation on how the MS Windows programming interface works (Microsoft has not been helpful on this point, and has refused to take part in the APIW specification process), the Wine programmers will need less trial-and-error to determine doubtful points, making their job easier, and
By helping standardize how MS Windows applications work, APIW has the potential to make it easier for Wine to support more applications.
No stone is being left un-turned in the effort to provide MS Windows-based applications to Linux users. The team of programmers that works on the Linux DOS box, DOSEMU, has been able to run MS Windows 3.1 in the DOSEMU DOS box under Linux. This is not particularly stable, and kernel patches are required, but for people who need to run MS Windows-based applications right now, don't want to re-boot to do so, and have sufficient technical understanding, it is an option.
- Give new life to old phones and tablets with these tips!
- Readers' Choice Awards--Nominate Your Apps & Gadgets Now!
- Memory Ordering in Modern Microprocessors, Part I
- Tech Tip: Really Simple HTTP Server with Python
- [<Megashare>] Watch Mrs Brown's Boys Movie Online Full Movie HD 2014
- RSS Feeds
- diff -u: What's New in Kernel Development
- Security Hardening with Ansible
- Returning Values from Bash Functions