Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
Motto: The journey of a thousand miles starts with a single step.
Introduction
Theoretically, any Win32 app should be compilable out of the box under Wine.
This, of course, is not the case. We have incompatible headers, and a bunch
of other problems described in
Winelib User's Guide.
A good way to fix these is to try to compile applications for which we
have the source under Winelib.
Why
But what do we hope to achieve? Well, the purpose of this project is four-fold:
Document our experience on porting these applications to Winelib
Improve Winelib based on the above such that the porting process becomes very simple
There are many such apps around, and a lot of them are hosted at
SourceForge. There are over
10,000 apps
listed as running under Windows OS, and over
7,000
of them are listed as running under the Win32 environment.
All of the above have publicly available source code, and
most are decent candidates for this project.
Obviously, we cannot start porting all these applications. We have to pick a
few important ones, and work with those.
How
Compiling apps under Winelib should theoretically involve only makefile changes.
In practice, you will encounter header problems, and the likes -- for these it is
much better (and faster) to submit a patch, rather than document them. So for the
remainder of the section, let's assume the Wine headers are good enough for the
application in question.
We are now faced with adapting the build process to Wine's needs. As things
stand today, we have to make another assumption: you aim at compiling the application
using the GNU toolchain (gmake, gcc, ld, etc.). In theory, it should be possible to
accomplish this with other tools, but at this point this is a rather unexplored
territory. That being said, we now distinguish two large application classes:
Non-GNU tools build process
For these, winemaker does a decent job of generating a build system.
I will not cover this type of applications here, for the time being.
Please refer to the winemakerdocumentation
for more information.
GNU tools based build process
Fortunately, most OSS applications have a build system based around the
MinGW tool chain. Sometimes they have
alternative build systems for the Borland and/or Microsoft tools, but more
often than not they have to support the MinGW tools out of necessity.
What
If you know of applications that should be listed here, please send your suggestions
to Dimi. Currently, we have:
Suggested by Steven Edwards:
I have just compleated a full install of OO 1.1 under WINE. No outsite
packages are required to install and configure OpenOffice for Win32
under Wine. There are a few minor bugs with some of the strings in
menus but I would rate it at 99%. If anyone is interested in a good
hobby project a Winelib port of this would be nice to see.
Suggested by Stuart Rowan:
cdex is a great ripper tool used by many to make mp3s and oggs under windows. [...]
If this could be ported to winelib that would be super then I can enjoy it on linux (finally).
It took some work, but we've done it. The good news is that
all (but 3) examples compile just fine. This has been accomplished
while making absolutely no changes to the original source, and
very few (and obvious) changes to the GNU Makefiles.
This is very good news, as it shows we can have a common build
system between Wine and Windows. The only samples that don't
work just yet are those from Chap21 which build DLLs, and DLL
creation is yet not supported by winegcc. I hope this will change
in the near future.
The problems that needed fixing were very simple, and quite
obvious. They fall into 2 categories:
The samples expect to link with the msvcrt, not the
Unix libc, so we had to pass the -mno-cygwin flag
to the compiler/linker. Under mingw this is the default
behaviour. This change is actually beneficial for
the Windows port as well, as it will allow the samples
to be build using Cygwin's gcc also. As such, it
should be considered a portability fix, rather than
a Wine specific fix.
The filenames used mixed case (not matching the actual
name on disk), and some includes use backslash (\),
instead of forward slash (/). This problem is typical
and simple to address in a portable manner if you
can modify the source. As we wanted to not touch
the examples in any way, we had to find another way
around it. Luckily, Unix accepts virtually any char
in a filename (except / of course), as well as links.
So we just created the appropriate symbolic links
where necessary, or just renamed the file if it made
more sense.
All these renames / symlinks creation was collected in a nice
little installation script. So, without further delay, here
are the instructions on how to try the sample under Wine:
(place the Petzold CD in the CDROM drive)
mount /mnt/cdrom
mkdir petzold
cd petzold
cp -r /mnt/cdrom/* .
wget http://www.computersciencelab.com/Petzold.zip
unzip -a Petzold.zip
bash Wine/install.sh
make
Update: (from Vincent) Ok, so I got it running under Winelib.
I'm listening to /usr/share/redhat-credits.ogg (only thing I could find quickly on my
computer :). It's so good to listen to something through it :P
I'll try to get it all under small bits for both projects.
Mozilla
One of the largest free software projects that we can support with Winelib.
Having this one compile, and run under Winelib would be a real tour de force.
Update: Mozilla currently requires MS tools to build on Win32.
To be ported to Wine, Mozilla must first be ported over to MinGW. There is an
ongoing effort to do so that is tracked in bug
134113.
[...] WINE might gain more of a market share if there was an easy way for
people that are writing Windows apps on Windows if they had an IDE for GCC
that was cross-platform. [...] the idea is to run Visual-Mingw under WINElib
and be able to just recompile your Win32 app that was built with Visual-Mingw
and the w32api package plus reduce some of the redundancy Wine,
Mingw and ReactOS have by finding areas where we are not in sync.
Update: This project cannot be ported using Winelib,
as it is written in Pascal/Delphi.
It should be possible to port it to Linux using Kylix relatively easily.
ATL & MFC
This is a very common request. And due to its widespread usage,
a very important project as well.
I had to uncomment PSH_WIZARD97 in /wine/prsht.h (fixed by Francois)
The packing pragmas looks handled by gcc-3.2.1, so we may remove all modifications made by winemaker
I had to force winnt.h to use nameless struct and unions (fixed by Dimi)
I added #define EDEADLOCK EDEADLK in /wine/msvcrt/errno.h (fixed by Francois)
I linked _alloca() to alloca() function (fixed by Alexandre)
There was a conflict on HKEY type between afxres.h and wine/windef.h
Some little others syntax issues like: __try __expect, asm {}, unsigned short(x), (LPCTSTR)CString
Gimp
This one's a very strange case. The Gimp is a native
Linux application built around the GTK+ toolkit.
It became a native Windows application by porting over the entire GTK+ toolkit, and
other supporting libraries. It would thus be quite interesting to see how it can be
ported back to Linux, via Winelib.
As explained in the introduction, the primary motivation for this effort is to discover,
and fix Winelib shortcomings. These are the fixes that have been
suggested and discussed
thus far:
Configuration
Submit patch to autoconf to recognize Wine as a platform. [TODO]
worker: none
status: not started
updated: Nov 28, 2002
Compilation
Write a small wrapper that makes gcc on Linux behave like mingw. [DONE]
Write wrapper script that takes care of generating .spec files, etc. [DONE]
From Alexandre: Yes, I think we want a wrapper like dllwrap to do all that. I'm not
sure a script would be enough, we may want a full-fledged C program.
The idea would be that you do something like:
winewrap *.o *.res -o foo -lwhatever
and it builds the .spec.c, compiles it, links everything into
foo.exe.so, and builds a foo executable (which may be a wrapper script
or a real ELF binary). This also (mostly) solves the "Running" issues:
you still have a .exe.so file, but you don't really need to worry
about it. You simply run "foo" and everything works.
