<chapter id="porting"> <title>Porting Wine to new Platforms</title> <para>Porting Wine to different (UNIX-based) operating systems...</para> <sect1 id="wine-porting"> <title>Porting</title> <para> written by ??? </para> <para> (Extracted from <filename>wine/documentation/how-to-port</filename>) </para> <sect2> <title>What is this?</title> <para> This note is a short description of: </para> <itemizedlist> <listitem> <para>How to port Wine to your favourite operating system</para> </listitem> <listitem> <para>Why you probably shouldn't use <symbol>#ifdef MyOS</symbol></para> </listitem> <listitem> <para>What to do instead.</para> </listitem> </itemizedlist> <para> This document does not say a thing about how to port Wine to non-386 operating systems, though. You would need a CPU emulator. Let's get Wine into a better shape on 386 first, OK? </para> </sect2> <sect2> <title>Why <symbol>#ifdef MyOS</symbol> is probably a mistake.</title> <para> Operating systems change. Maybe yours doesn't have the <filename>foo.h</filename> header, but maybe a future version will have it. If you want to <symbol>#include <foo.h></symbol>, it doesn't matter what operating system you are using; it only matters whether <filename>foo.h</filename> is there. </para> <para> Furthermore, operating systems change names or "fork" into several ones. An <symbol>#ifdef MyOs</symbol> will break over time. </para> <para> If you use the feature of <command>autoconf</command> -- the Gnu auto-configuration utility -- wisely, you will help future porters automatically because your changes will test for <emphasis>features</emphasis>, not names of operating systems. A feature can be many things: </para> <itemizedlist> <listitem> <para>existance of a header file</para> </listitem> <listitem> <para>existance of a library function</para> </listitem> <listitem> <para>existance of libraries</para> </listitem> <listitem> <para>bugs in header files, library functions, the compiler, ...</para> </listitem> <listitem> <para>(you name it)</para> </listitem> </itemizedlist> <para> You will need Gnu Autoconf, which you can get from your friendly Gnu mirror. This program takes Wine's <filename>configure.in</filename> file and produces a <filename>configure</filename> shell script that users use to configure Wine to their system. </para> <para> There <emphasis>are</emphasis> exceptions to the "avoid <symbol>#ifdef MyOS</symbol>" rule. Wine, for example, needs the internals of the signal stack -- that cannot easily be described in terms of features. </para> <para> Let's now turn to specific porting problems and how to solve them. </para> </sect2> <sect2> <title>MyOS doesn't have the <filename>foo.h</filename> header!</title> <para> This first step is to make <command>autoconf</command> check for this header. In <filename>configure.in</filename> you add a segment like this in the section that checks for header files (search for "header files"): </para> <programlisting> AC_CHECK_HEADER(foo.h, AC_DEFINE(HAVE_FOO_H)) </programlisting> <para> If your operating system supports a header file with the same contents but a different name, say <filename>bar.h</filename>, add a check for that also. </para> <para> Now you can change </para> <programlisting> #include <foo.h> </programlisting> <para> to </para> <programlisting> #ifdef HAVE_FOO_H #include <foo.h> #elif defined (HAVE_BAR_H) #include <bar.h> #endif </programlisting> <para> If your system doesn't have a corresponding header file even though it has the library functions being used, you might have to add an <symbol>#else</symbol> section to the conditional. Avoid this if you can. </para> <para> You will also need to add <symbol>#undef HAVE_FOO_H</symbol> (etc.) to <filename>include/config.h.in</filename> </para> <para> Finish up with <command>make configure</command> and <command>./configure</command>. </para> </sect2> <sect2> <title>MyOS doesn't have the <function>bar</function> function!</title> <para> A typical example of this is the <function>memmove</function> function. To solve this problem you would add <function>memmove</function> to the list of functions that <command>autoconf</command> checks for. In <filename>configure.in</filename> you search for <function>AC_CHECK_FUNCS</function> and add <function>memmove</function>. (You will notice that someone already did this for this particular function.) </para> <para> Secondly, you will also need to add <symbol>#undef HAVE_BAR</symbol> to <filename>include/config.h.in</filename> </para> <para> The next step depends on the nature of the missing function. </para> <variablelist> <varlistentry> <term>Case 1:</term> <listitem> <para> It's easy to write a complete implementation of the function. (<function>memmove</function> belongs to this case.) </para> <para> You add your implementation in <filename>misc/port.c</filename> surrounded by <symbol>#ifndef HAVE_MEMMOVE</symbol> and <symbol>#endif</symbol>. </para> <para> You might have to add a prototype for your function. If so, <filename>include/miscemu.h</filename> might be the place. Don't forget to protect that definition by <symbol>#ifndef HAVE_MEMMOVE</symbol> and <symbol>#endif</symbol> also! </para> </listitem> </varlistentry> <varlistentry> <term>Case 2:</term> <listitem> <para> A general implementation is hard, but Wine is only using a special case. </para> <para> An example is the various <function>wait</function> calls used in <function>SIGNAL_child</function> from <filename>loader/signal.c</filename>. Here we have a multi-branch case on features: </para> <programlisting> #ifdef HAVE_THIS ... #elif defined (HAVE_THAT) ... #elif defined (HAVE_SOMETHING_ELSE) ... #endif </programlisting> <para> Note that this is very different from testing on operating systems. If a new version of your operating systems comes out and adds a new function, this code will magically start using it. </para> </listitem> </varlistentry> </variablelist> <para> Finish up with <command>make configure</command> and <command>./configure</command>. </para> </sect2> </sect1> <sect1 id="os2-wine"> <title>Running & Compiling WINE in OS/2</title> <para> Written by &name-robert-pouliot; <email>&email-robert-pouliot;</email>, January 9, 1997 </para> <para> (Extracted from <filename>wine/documentation/wine_os2</filename>) </para> <para> If you want to help the port of WINE to OS/2, send me a message at <email>krynos@clic.net</email> I currently don't want beta testers. It must work before we can test it. </para> <para> Here is what you need to (try to) compile Wine for OS/2: </para> <itemizedlist> <listitem> <para>EMX 0.9c (fix 2)</para> </listitem> <listitem> <para>XFree86 3.2 OS/2 (with development libraries)</para> </listitem> <listitem> <para> <command>bash</command>, gnu <command>make</command>, <command>grep</command>, <command>tar</command>, <command>bison</command>, <command>flex</command> </para> </listitem> <listitem> <para><command>sed</command> (a working copy of)</para> </listitem> <listitem> <para>xpm</para> </listitem> <listitem> <para><command>diff</command> and <command>patch</command> are recommended</para> </listitem> <listitem> <para>Lots of disk space (about 40-50 megs after EMX and XFree installed)</para> </listitem> </itemizedlist> <para> To compile: </para> <screen> <prompt>$ </prompt><userinput>sh</userinput> <prompt>$ </prompt><userinput>tools/make_os2.sh</userinput> <prompt>$ </prompt><userinput>make depend</userinput> <prompt>$ </prompt><userinput>make</userinput> <prompt>$ </prompt><userinput>emxbind wine</userinput> </screen> <para> Currently: </para> <itemizedlist> <listitem> <para><command>configure</command> and <command>make depend</command> work...</para> </listitem> <listitem> <para><command>make</command> compiles (with a modified Linux <filename>mman.h</filename>), but doesn't link.</para> </listitem> <listitem> <para>signal handling is horrible... (if any)</para> </listitem> <listitem> <para>EMX doesn't support <function>mmap</function> (and related), SysV IPC and <function>stafs()</function></para> </listitem> <listitem> <para> XFree86/OS2 3.2 doesn't support <function>XShmQueryExtension()</function> and <function>XShmPixmapFormat()</function> due to the same lack in EMX... </para> </listitem> </itemizedlist> <para> What needs to be redone: </para> <itemizedlist> <listitem> <para>LDT (using <function>DosAllocSeg</function> in <filename>memory/ldt.c</filename>) *</para> </listitem> <listitem> <para>Implement <function>mmap()</function> and SysV IPC in EMX *</para> </listitem> <listitem> <para>File functions, </para> </listitem> <listitem> <para>I/O access (do it!),</para> </listitem> <listitem> <para>Communication (modem),</para> </listitem> <listitem> <para>Interrupt (if int unknown, call current RealMode one...), </para> </listitem> <listitem> <para> Verify that everything is thread safe (how does Win95/NT handle multi-thread?), </para> </listitem> <listitem> <para> Move X functions in some files (and make a wrapper, to use PM instead latter), </para> </listitem> <listitem> <para>Return right CPU type, </para> </listitem> <listitem> <para>Make winsock work</para> </listitem> </itemizedlist> <para> The good things: </para> <itemizedlist> <listitem> <para>OS/2 have DOS interrupts</para> </listitem> <listitem> <para>OS/2 have I/O port access</para> </listitem> <listitem> <para>OS/2 have multi-thread</para> </listitem> <listitem> <para>Merlin have Open32 (to be used later...)</para> </listitem> </itemizedlist> </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables: mode: sgml sgml-parent-document:("wine-doc.sgml" "set" "book" "part" "chapter" "") End: -->