In the first few years of Linux, many people asked whether it would be possible to run MS Windows under Linux. They were tired of rebooting over and over to run applications such as word processors that are available under Windows, but not under Linux.
Since Windows (in some incarnation) runs under SCO, iRTX, QNX, and SVR4 of various flavors, why couldn't it run under Linux as well? The immediate answer was that all the other OS's that run Windows 3.1 have access to some Windows source code, and are working under “non-disclosure agreements” from Microsoft, and that Windows, as it comes out-of-the-box, takes over the entire machine. It is possible to run Windows 3.0 in “real mode”, where it doesn't take over the machine, but very few applications will run in that mode.
Others pointed out that most of the other implementations crash just as often as Windows itself does, and that Linux is a 32-bit operating system, while Windows is a 16-bit system, and that standard Windows binaries are 16-bit binaries.
Some people suggested rewriting Windows for Linux and X11, and then laughed at their own joke.
Attention turned to the DOS emulator that became widely useable about a year and a half after Linux's debut. Many were excited when, with some rather ugly hacks, the DOS emulator was able to run Windows 3.0 in “real mode”, at least for a few developers who knew what they were doing. It became apparent that there are very few useful Windows applications which still run in real mode, that it would be very difficult to get Windows to run in standard mode under Linux, and that if Windows could be made to run under Linux, it would make the system unstable.
A year ago or so (in June 1993), Bob Amstadt started writing the beginnings of Wine. He started by writing the code necessary to load Windows binaries into memory (Windows binaries are not in a format Linux understands, and need to be “fixed up” when they are run) and some code for Linux to allow modifying some of the memory management structures (the LDT) in such a way that Windows binaries could run.
He set up a structure for rewriting the rest of Windows, and a few programmers joined him in writing these functions. A year later, over 35% of the functions have been written, and many small applications run, more or less. These include the standard Windows applets Solitaire and Winmine, as well as a commercial security system application. Each week, more programs are added to the success list.
Wine translates the Windows API (Application Programming Interface, how Windows applications call Windows) into equivalent functionality available through the standard Unix and X interfaces. When a Windows program creates a window, Wine converts that into a call to create a window through the standard Xlib library. When DOS interrupts are called, for example to read a file, Wine translates them into Unix system calls.
Wine also implements other API's that are available for Windows. For instance, the WinSock API is becoming the standard way of accessing TCP/IP networking under Windows, and Wine provides the functionality of WinSock, mapping it to the standard Unix socket calls.
Wine should run applications at approximately the same speed as Windows, because the application code is running on the native CPU-Wine does not emulate a 386 or 486 processor. Because Wine itself is a 32-bit application, it has a chance to be faster than MS Windows in some areas. Windows, by contrast, runs in 16-bit mode and has to do a lot of “segment arithmetic” that is not necessary in 32-bit mode.
Wine loads Windows binaries; it also loads the closely related DLLs (dynamically linked libraries) which most applications require. Wine itself uses a DLL called sysres.dll, in which are stored all the bitmaps for the standard buttons on the title bar.
OS/2 2.x was marketed as “A better Windows than Windows”, and in some ways this was true. OS/2 provides “Crash Protection”, whereby one misbehaving Windows application cannot crash another application. Windows, on the other hand, does not adequately protect applications from each other. With Wine, each program is run as a separate process, which utilizes the protection already provided by the Unix process model, where each process is separate.
Not only will you not crash your computer, you will not crash X either. X is designed to be robust, and to check the data that is passed to it by applications, so that random bad data will not cause the X server to crash.
There are additional benefits beyond “crash protection” to running each Window binary as a separate process. One is that each program has more resources. Instead of all the Windows programs running at the same time having to share GDI heap (a memory resource), each program has access to its own entire heap.
Under Windows, when an application is busy and changes the cursor to the dreaded hourglass, the user has to wait to use all the programs currently running on the computer. With Wine, when one application is busy, the user can let that application be busy while switching to another application and getting some work done.
In Unix, filesystems are “multithreaded”, which means that multiple processes may be reading and writing files simultaneously. DOS does not allow this, so Wine, by using the Unix functionality for reading and writing files, allows much faster and smoother access to files, both on the hard drive and on floppies. The user can back up to any medium and work at the same time, just as you would expect under Unix.
Running MS Windows programs on remote computers that are also running MS Windows is not easy or fun. It requires that special remote-access programs be running on both computers, and none of the many remote access programs is compatible with any of the other programs, because they all use closed, proprietary protocols. Furthermore, they usually require that the remote user be the sole user of the machine.
X, by contrast, is designed to run remotely, and to run on multi-user systems. Because Wine translates Windows calls into X calls, Wine allows the same easy remote access that X does. It is just as simple (although a little slower) for a user in Moscow to run the Windows application on your computer as it is for you, if you are on the Internet, and so is she, and you give her an account on your machine.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide