ch63.htm

linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E

is stored as GDI.24. GDI is the name of the MS-Windows graphics library, and 24 is

the position in that DLL where <TT>Ellipse</TT> starts. Wine does not need to do

any instruction emulation, because both Linux and MS-Windows use the i386 instruction

set. When an MS-Windows primitive function is called, Wine intercepts that call and

passes it to a matching library routine.

<CENTER>

<H4><A NAME="Heading18<FONT COLOR="#000077">The Wine Library</FONT></H4>

</CENTER>

<P>Wine converts the MS-Windows API to the matching X or UNIX API calls. A call to

the MS-Windows <TT>Ellipse</TT> function to draw an ellipse in a window has the following

format:</P>

<PRE><FONT COLOR="#0066FF">Ellipse (hdc, xLeft, yTop, xRight, yBottom);

</FONT></PRE>

<P>The definitions of <TT>xLeft</TT>, <TT>yTop</TT>, <TT>xRight</TT>, and <TT>yBottom</TT>

are a bounding box for an ellipse, as shown in Figure 63.2.</P>

<P>The same ellipse is drawn under the X API <TT>XDrawArc</TT> function:</P>

<PRE><FONT COLOR="#0066FF">XDrawArc(display, d, gc, x, y, width, height, angle1, angle2);

</FONT></PRE>

<P>The definitions of <TT>x</TT>, <TT>y</TT>, <TT>width</TT>, <TT>height</TT>, <TT>angle1</TT>,

and <TT>angle2</TT> are shown in Figure 63.3.

<H6></H6>

<P><A NAME="Heading19<A HREF="../art/63/60lnx02.jpg"><FONT COLOR="#000077">FIGURE

63.2.</FONT></A> <I>MS-Windows <TT>Ellipse</TT> coordinates.<BR>

</I><BR>

<A NAME="Heading20<A HREF="../art/63/60lnx03.jpg"><FONT COLOR="#000077">FIGURE

63.3.</FONT></A><FONT COLOR="#000077"><I> ,</I></FONT><TT><I>XDrawArc</I></TT><I>

coordinates. </I><BR>

<BR>

Wine needs to do a little math to convert the coordinates from an <TT>Ellipse</TT>

call to that of an <TT>XDrawArc</TT> call. Other parameters of the <TT>XDrawArc</TT>

call are a bit easier to map. The d refers to a drawable area, which is typically

a handle to a window. Under MS-Windows, this is contained in the <TT>hdc</TT> structure.

The gc is a graphics context and is analogous in functionality to the hdc under MS-Windows.

As X is capable of displaying on different machines over a network, the display parameter

describes which display to use. The display parameter remains constant over the life

of a Wine session. The last thing Wine has to consider is that an MS-Windows <TT>Ellipse</TT>

call can also specify a filled ellipse. Wine checks the <TT>hdc</TT>, and possibly

uses <TT>XFillArc</TT> instead.</P>

<P>There are nearly 300 graphics primitives available under MS-Windows that need

to undergo similar translations. While this might seem to be a bit of work, the graphics

conversions are among the simpler things to emulate under MS-Windows.

<CENTER>

<H3><A NAME="Heading21<FONT COLOR="#000077">Where Does Wine End and MS-Windows

Begin?</FONT></H3>

</CENTER>

<P>As Wine currently requires parts of MS-Windows to operate, it is a bit confusing

to know where Wine ends and MS-Windows begins. Wine currently provides API calls

for the following parts of a typical MS-Windows installation: 

<TABLE BORDER="0">

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>commdlg</TT></TD>

		<TD ALIGN="LEFT">Common Windows Dialogs</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>gdi</TT></TD>

		<TD ALIGN="LEFT">Graphics Device Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>kernel</TT></TD>

		<TD ALIGN="LEFT">Kernel Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>keyboard</TT></TD>

		<TD ALIGN="LEFT">Keyboard Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>mmsystem</TT></TD>

		<TD ALIGN="LEFT">Multimedia System Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>mouse</TT></TD>

		<TD ALIGN="LEFT">Mouse Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>shell</TT></TD>

		<TD ALIGN="LEFT">Windows 3.1 Shell API Library</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>sound</TT></TD>

		<TD ALIGN="LEFT">Windows sound system</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>toolhelp</TT></TD>

		<TD ALIGN="LEFT">Debugging and tools helper calls</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>user</TT></TD>

		<TD ALIGN="LEFT">Microsoft Windows User Interface</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>win87em</TT></TD>

		<TD ALIGN="LEFT">Coprocessor/Emulator Library</TD>

	</TR>

	<TR ALIGN="LEFT" rowspan="1">

		<TD ALIGN="LEFT"><TT>winsock</TT></TD>

		<TD ALIGN="LEFT">Windows Socket interface (TCP/IP)</TD>

	</TR>

</TABLE>

Wine requires access to some parts of MS-Windows to use features that are not implemented

by Wine. One example is the MS-Windows dynamic link library <TT>OLECLI</TT>, which

implements the OLE client. The Wine team has made significant headway in reducing

the number of files needed. The Wine project charter includes removing any dependency

on MS-Windows files. This includes utilities and file organizations to install MS-Windows

applications.</P>

<P>Some of the simplest MS-Windows applications run today under Wine without need

of any MS-Windows code or access to any MS-Windows directories. <TT>WINMINE.EXE</TT>

and <TT>SOL.EXE</TT> are examples of such applications. Although no suggested directory

organization exists to support this, a quick example of doing this is the following:



<DL>

	<DD><B>1.</B> Copy <TT>winmine.exe</TT> and <TT>win.ini</TT> to a Linux directory

	such as <TT>/users/windows</TT>.<BR>

	<B><BR>

	2.</B> Change the Windows path options in <TT>wine.conf</TT>, such as to <TT>/users/windows</TT>.<BR>

	<B><BR>

	3.</B> Dismount your MS-DOS partition.<BR>

	<B><BR>

	4.</B> Run Wine.

</DL>



<CENTER>

<H3><A NAME="Heading22<FONT COLOR="#000077">The Limitations of Wine</FONT></H3>

</CENTER>

<P>Only a few MS-Windows software packages run correctly under Wine. Luckily, it

is possible to estimate how likely a program is to run correctly without actually

running it. Unfortunately, there are some classes of applications that are unlikely

to ever run under Wine.

<CENTER>

<H4><A NAME="Heading23<FONT COLOR="#000077">Software That Works</FONT></H4>

</CENTER>

<P>Recent versions of Wine support a good number of the MS-Windows applets and games

included with the stock MS-Windows 3.1. There are considerable variations between

each release of Wine. Changes that help some applications often break others. But

here are just a few of the accessories and games that work well under Wine:



<UL>

	<LI><TT>calc.exe</TT>

	<P>

	<LI><TT>clock.exe</TT>

	<P>

	<LI><TT>cruel.exe</TT>

	<P>

	<LI><TT>golf.exe</TT>

	<P>

	<LI><TT>notepad.exe</TT>

	<P>

	<LI><TT>pipe.exe</TT>

	<P>

	<LI><TT>pegged.exe</TT>

	<P>

	<LI><TT>reversi.exe</TT>

	<P>

	<LI><TT>winmine.exe</TT>

</UL>



<CENTER>

<H4><A NAME="Heading24<FONT COLOR="#000077">Using winestat to Analyze Windows

Programs</FONT></H4>

</CENTER>

<P>Part of Wine is the <TT>winestat</TT> utility. This is actually the same program

as Wine, but instead of running an MS-Windows executable, <TT>winestat</TT> simply

attempts to load a Windows executable and reports on how successful the load was.

In loading an executable, <TT>winestat</TT> also loads any DLLs necessary, and reports

if any are missing. <TT>winestat</TT> looks for Windows API calls that are used by

either the executable or any DLL, and verifies their existence. A sample <TT>winestat</TT>

run on the MS-Windows Paintbrush applet <TT>pbrush</TT> yields the following:</P>

<PRE><FONT COLOR="#0066FF">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 60 (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 %)

</FONT></PRE>

<P><TT>winestat</TT> calls out by number and module the individual functions 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 <TT>if1632</TT> directory for the given module

name's spec file. A sample <TT>kernel.spec</TT> file is as follows:</P>

<PRE><FONT COLOR="#0066FF">#1 FATALEXIT

#2 EXITKERNEL

3   pascal GetVersion() GetVersion()

...

...

...

#54 pascal16 GETINSTANCEDATA

</FONT></PRE>

<P>Any line in a <TT>.spec</TT> file that starts with a <TT>#</TT> is considered

a comment, not an implemented function. In this example, both 1 and 54 are commented,

with the respective names of <TT>FATALEXIT</TT>, and <TT>GETINSTANCEDATA</TT>. <TT>FATALEXIT</TT>

is used for debugging MS-Windows programs under error conditions and is not important

for most MS-Windows users. <TT>GETINSTANCEDATA</TT> copies configuration data from

a previous instance of an application. If you are running only one instance of an

application, this does not apply.</P>

<P>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.</P>

<P>MS-Windows applications to which <TT>winestat</TT> 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:

<TT>wine -desktop 800</TT>x<TT>600 </TT>filename. Normal methods of killing a Windows

process from your window manager should work.



<DL>

	<DT></DT>

</DL>





<DL>

	<DD>

<HR>

<A NAME="Heading25<FONT COLOR="#000077"><B>TIP: </B></FONT>When all else fails

	trying 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 into a virtual console and use <TT>ps -ax | grep wine</TT>

	to find your Wine sessions. Use <TT>kill -15 </TT>pid where pid is the process id

	returned by <TT>ps</TT> 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 down the Alt and Ctrl keys, and press F1 through F8 until you

	find it. 

<HR>



</DL>



<CENTER>

<H4><A NAME="Heading26<FONT COLOR="#000077">One Major Piece That Is Missing

from Wine</FONT></H4>

</CENTER>

<P>Perhaps the most obvious omission from Wine is the lack of a printer interface.

As 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 <TT>GhostScript</TT> are already capable of converting PostScript

to other printer types, such as HP laser and inkjet printers.

<CENTER>

<H4><A NAME="Heading27<FONT COLOR="#000077">Software Unlikely to Ever Work</FONT></H4>

</CENTER>

<P>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 <TT>winsock</TT> DLL, which uses the TCP/IP inherent in the Linux

kernel.

<CENTER>

<H3><A NAME="Heading28<FONT COLOR="#000077">The History of Wine</FONT></H3>

</CENTER>

<P>The first parts of Wine were made available in July 1993. The first versions had

problems running the MS-Windows Solitaire game, and were quite limited. Notably missing

was support for menus. Since then a huge number of changes have been made by many

dedicated people. Following are just a few of the notable milestones:



<UL>

	<LI>Dec 1993 Communications port support

	<P>

	<LI>Feb 1994 Winsock interface added

	<H1></H1>

	<LI>May 1994 <TT>clock.exe</TT> working, <TT>backingstore</TT> optimizations added

	<P>

	<LI>Aug 1994 Win 32 resource loading support started

	<P>

	<LI>Oct 1994 <TT>commdlg.dll</TT> support started

	<P>

	<LI>Nov 1994 Multiple language support added

	<P>

	<LI>Jul 1995 ipc, DDE, shared memory support

</UL>











</td>
</tr>
</table>
<!-- begin footer information -->


</body></html>