Winelib - Any port in a storm.

Winelib

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.

Contents

  1. Winelib
  2. Introduction
    1. Why
    2. Where
    3. How
    4. What
  3. Applications
    1. Todo
      1. CD-DA X-Tractor
      2. CDex
      3. DXSDK's Examples
      4. Easy Code
      5. Gimp
      6. OpenOffice
      7. Ultimate++
      8. VirtualDub
    2. In progress
      1. ATL & MFC
      2. Mozilla
      3. TeXnicCenter
      4. WinAMP
    3. Works
      1. AbiWord
      2. CoolPlayer
      3. GNU Winboard
      4. WinVi
    4. Done
      1. Petzold's Examples
      2. PuTTY
      3. Visual MinGW
    5. Abandoned
      1. Dev-C++
  4. Winelib Fixes
    1. Todo
    2. Done

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

  • Update the Winelib User's Guide to the latest porting process

  • Fixing header and library problems in the process.

Where

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 winemaker documentation 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 add it.

Applications

Legend:

  • TODO: the project is waiting in the queue for someone to pick it up, and run with it

  • IN PROGRESS: someone has started porting the application to Winelib

  • WORKS: the application compiles, links, and runs as a Winelib application

  • DONE: the Winelib platform has been included in the official application build system

  • ABANDONED: the application has been deem unsuitable for porting using Winelib

Todo

CD-DA X-Tractor

CDex

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).

DXSDK's Examples

Suggested by Robert Reif.

Easy Code

Suggested by KevinNelson

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.

OpenOffice

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.

Ultimate++

It seems to have a MinGW build system since Nov 2004.

VirtualDub

Suggested by Nerijus Baliunas since it is often requested.

In progress

ATL & MFC

This is a very common request. And due to its widespread usage, a very important project as well.

  • worker: Ronald MALLET

  • status: IN PROGRESS: MFC successfully compiles

  • updated: Dec 17, 2002

From Ronald, on what it took to compile MFC:

  • 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

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 203303.

TeXnicCenter

Suggested by Matthias Jahn: It is a tex-shell like kde's "kile".

WinAMP

Suggested by Brian Vincent: Looks like Nullsoft has released the Winamp 3 code as open source.

Works

AbiWord

To build under Winelib, simply do:

  • make ABI_OPT_WINELIB=1

CoolPlayer

Suggested by Henrik Uggla.

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.

GNU Winboard

Suggested by Erwin Wolff.

Interesting and simple chess game because it depends on email and network (TCP/IP) code to function.

WinVi

Beside the 32-Bit winelib port it is the first application ported to 64-Bit winelib and still runs.

Done

Petzold's Examples

Suggested by John Kopplin.

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:

  1. 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.

  2. 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:

Enjoy!

PuTTY

A most loved Windows tool.

Visual MinGW

Rational provided by Steven Edwards:

[...] 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.

Abandoned

Dev-C++

Andrew Lynch writes: Visual-Mingw sounds almost identical to DevEx found at http://sourceforge.net/projects/wingtk and http://www.bloodshed.net. I am using their wGLADE tool for cygwin/GTK+ development presently and it works great under Win98.

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.

Winelib Fixes

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:

Todo

Configuration

Submit patch to autoconf to recognize Wine as a platform.

  • worker: none

  • status: TODO: not started

  • updated: Nov 28, 2002

Done

Compilation
Write a small wrapper that makes gcc on Linux behave like mingw.
Resources

Make wrc compatible with windres at command line level.

Linking

Write wrapper script that takes care of generating .spec files, etc. 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.

  • worker: Dimitrie O. Paun

  • status: DONE: first cut submitted for review, patch committed.

  • updated: Dec 16, 2002
Running
Arrange so that a regular Unix executable is generated.

Improve the wineapploader so it can be used directly by the step above.

CategoryToDo CategoryDevelopment CategoryToDo

Winelib (last edited 2012-09-11 09:21:43 by KevinNelson)