| Previous | Table of Contents | Next |
Part of Wine is the winestat utility. This is actually the same program as Wine, but instead of running an MS-Windows executable, winestat simply attempts to load a Windows executable and reports on how successful the load was. In loading an executable, winestat also loads any DLLs necessary and reports if any are missing. winestat looks for Windows API calls that are used by either the executable or any DLL and verifies their existence. A sample winestat run on the MS-Windows Paintbrush applet pbrush yields the following:
KERNEL.1 not implemented KERNEL.54 not implemented KERNEL.113 not implemented KERNEL.114 not implemented KERNEL.121 not implemented KERNEL.154 not implemented KERNEL.178 not implemented KERNEL.207 not implemented KERNEL: 52 of 66 (86.7 %) USER: 150 of 150 (100.0 %) GDI.151 not implemented GDI.307 not implemented GDI.366 not implemented GDI.439 not implemented GDI: 80 of 84 (95.2 %) SHELL: 9 of 9 (100.0 %) KEYBOARD: 2 of 2 (100.0 %) TOTAL: 293 of 305 winapi functions implemented (96.1 %)
winestat calls out the individual functions by number and module that are not implemented by Wine. If you are curious as to the function name, rather than number, look at the Wine sources in the if1632 directory for the given module name’s spec file. A sample kernel.spec file is as follows:
#1 FATALEXIT #2 EXITKERNEL 3 pascal GetVersion() GetVersion() … … … #54 pascal16 GETINSTANCEDATA
Any line in a .spec file that starts with a # is considered a comment, not an implemented function. In this example, both 1 and 54 are commented, with the respective names of FATALEXIT and GETINSTANCEDATA. FATALEXIT is used for debugging MS-Windows programs under error conditions and is not important for most MS-Windows users. GETINSTANCEDATA copies configuration data from a previous instance of an application. If you are running only one instance of an application, this does not apply.
The final percentage shows which MS-Windows API calls are implemented. This is often a good measure of how much of an application could work under Wine. Unfortunately, if a single, unimplemented API call is needed to initialize your MS-Windows application, anything less than 100 percent is not good enough.
MS-Windows applications to which winestat gives an overall implementation rating over 95 percent are worth a try. Unlike DOSemu, Wine is not as prone to leaving Linux in an unusable state. However, it is not always a trivial matter to kill an errant Wine session. The easiest thing to do is to start Wine with a separate desktop: wine -desktop 800×660 filename. Normal methods of killing a Windows process from your window manager should work.
Tip:
When all else fails to stop an errant Wine session, switch to a free virtual console and kill the errant Wine process. For example, Alt+Ctrl and F2 would switch to virtual console number 2. You can log in to a virtual console and use ps -ax | grep wine to find your Wine sessions. Use kill -15 pid where pid is the process id returned by ps to stop the process.You can return to your X session by switching to the virtual console that is running X. If you don’t know what console number that is, hold the Alt and Ctrl keys, and press F1 through F8 until you find it.
Perhaps the most obvious omission from Wine is the lack of a printer interface. Because this is a complex process, work on a printer interface is little more than a few ideas. It would be a huge task to support all of the types of printers supported under MS-Windows. Wine will likely implement only a PostScript driver. Existing Linux utilities such as GhostScript are already capable of converting PostScript to other types of printer types, such as HP laser and inkjet printers.
The 32-bit Windows API (win32) is mostly unsupported. This is the executable image format for Windows NT and Windows 95, and is known as PE (portable executable). Wine currently supports the loading of resource files, such as fonts, that are in PE format, but is unable to handle executables or DLLs.
The Wine project has no plans to support Windows Virtual Device Drivers (VDDs). VDDs use a different image format, called LE for linear executable, that the Wine loader is unable to handle. Because VDDs do things like direct hardware manipulation, coexistence of a VDD with Linux device drivers would be a tough problem indeed. One of the uses of VDDs in commercial MS-Windows is for TCP/IP stacks. Wine supports TCP/IP through the winsock DLL, which uses the TCP/IP inherent in the Linux kernel.
In this chapter you’ve seen how to set up and use the Wine Windows Emulator to run Windows applications. Wine is not the only way to accomplish this task; there are several other Windows emulators and binary interfaces available (such as WABI). However, Wine is one of the oldest (at least as far as Linux is concerned) and has a good user base to support it.
From here you can explore related chapters:
| Previous | Table of Contents | Next |