Porting Windows Applications to Linux

If you have an existing win32 application, one way to port it is to use the WINE libraries. WINE encludes a windows emulator and also a Win32 compatible library. The problem with running applications under wine is that it doesn't support many of the undocumented functions in the Win32 API. Like other microsoft APIs, it is fairly useless as documented; to do anything useful you need access to inside information. However, if you are porting an application, you know what the API functions you need should do and since Wine is open-source, you can add the desired functionality to wine to support your application and contribute that back to the wine project. Corel used this approach and found that it took them about a week to port a major application program to Linux.

If you are writing a new C or C++ GUI application, consider writing it around the GTK+ toolkit. This toolkit runs on Linux and other un*x systems, and has been ported to windows 95/NT.

You should be aware of the Cygwin library which attempts to provide ANSI and POSIX standards compatabile functions in the proprietary windows environment. This library has been used to port many standard unix development tools to the windows environment.

Programs written in Java, Perl, and Python are likely to be fairly portable between different operating systems since these languages are normally distributed with a standard environment which usually includes GUI functions.

A good way to improve the portability of application programs is to encapsulate system specific functions in your own functions which can later be modified to work with other system APIs. These functions should be based around a calling convention which makes sense from your application's point of view instead of from the existing API's perspective. That way, when you port your program you don't find yourself having to contort your data to the form required by the first systems API and then contort it back to conform to the second systems API which might want the data in a form which resembles the original form.

Networking. The WinSock API is basically a butchered subset of the standard berkely sockets interface found on un*x systems. On unix systems, you use the same read() and write() system calls to read data from or write data to a network connection or an ordinary file.

To print from your application, simply output postscript piped to another program (preferably allowing the user to specify the name of the program). To read from a scanner under linux, you will need to use the SANE API.

If you are writing a printer driver, be aware that a ghostscript driver is the ONLY driver you need to write to make your device run on every 32 bit and 64 bit operating system and even some 16 bit operating systems. Ghostscript has been ported to windows 95 and can work with the proprietary printing system. Ghostscript effectively makes any printer handle the postscript language (as well as PDF). One driver can be compiled on Linux, FreeBSD, NetBSD, OpenBSD, Hurd, Solaris, SunOS, AIX, SCO, Windows 95, Windows NT, MacOS, OS/2, BeOS, Atari, Amiga and many others.

If you are writing a scanner driver, the SANE standard is far superior to TWAIN. TWAIN is horribly system specific and just broken. SANE has been ported to many unix operating systems and can reasonably be ported to Windows, MacOS, and others. TWAIN supports GUI applications only and is tied to a particular operating system since the dialog box is painted by the driver. SANE can potentially work on any operating system which supports dynamically loaded shared libraries and works with GUI, text mode, remote network SANE clients, CGI programs, and automated applications. A SANE driver exports a hardware description to the application and lets it draw a dialog box, parse command line parameters, or otherwise set these values or let the user do so. A TWAIN to SANE driver can easily be written which would allow any TWAIN aware application to be SANE aware so you would only need SANE drivers. The reverse cannot really be done because of TWAIN's limitations. Doing at least a partial SANE port to windows and contributing it back to the SANE project and writing a SANE driver makes much more sense than writing a TWAIN driver.

Process creation. My libchild package has not been ported to windows (at least at the time of this writing) but I think it presents an API to the application which can be more cleanly implemented on both un*x and windows. Also, look at the spawn family of calls in the cygwin library.

In several sections, I suggest giving something back to the community. This is the ethical thing to do since you are benifiting from the existing code base and it can generate favorable publicity.