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