Windows porting

[Robin Rowe]

> Judging from what I heard of the discussion, from where I was at the end
> of the table, it sounded like one person repeatedly trying to advocate
> such ports, and others surrounding him replying with non-technical
> personal opinions of an OS-advocacy nature -- tantamount to a troller /
> trollee session.  If there was any substantial discussion of porting
> issues, I missed it.

I tried to have a substantial discussion of Windows porting issues, but that
wasn't feasible with one person vocally opposed to the very idea of porting
open source to Windows, who didn't want Windows users becoming accustomed to
Linux applications running on Windows, didn't want to welcome Windows
programmers to open source, and was against attempting to bring Windows
programmers and users into Linux via the route of open source. Perhaps I was
surrounded by Windows.die.die.die advocates as you suggest, but it didn't
seem so to me. One or two people did seem to have an extreme opinion, but I
found that interesting.

I did mention the key points to porting C++ GUI apps to Windows, but that
would have been easy to miss from the other end of the table.

1. Don't use fork(). Use threads instead.
2. Use a portable GUI library, such as GTK+ or Qt -- not Xlib or Xt.
3. There is no unistd.h. However, when Windows implemented Berkeley sockets
a lot of functionality found in unistd.h was needed. Look in winsock.h,
stdlib.h, stdio.h, and io.h. You have to search.
4. If you support Win9x and not just WinNT/2k/XP there are extra gotchas
because some Windows NT API calls in Win9x don't actually do anything or are
incompletely implemented. For instance, named pipes don't work in Win9x even
though the calls are there. (No, the VC++ docs don't warn you that named
pipes won't work in Win9x.)

It is cleaner to anticipate a Windows port, rather than kludge one later.
Designing a program often involves choosing between three different
approaches to any particular task. Some will work in Windows with little or
no trouble. Others will not. Porting from Linux to Windows tends to be
fairly easy because Windows is POSIX compatible. The reverse, a Windows to
Linux port may be harder. Of the several design options available in any
Windows program, typically there will be just one little mentioned API set
that is UNIX compatible. Microsoft uses Windows-only APIs to tie programmers
to their OS.

Motion picture studios such as DreamWorks now design their code to build on
Linux, Irix, and Windows. They report that building and testing on multiple
platforms helps them eliminate obscure bugs and requires little extra effort
provided there was prior planning.

My article in this month's Linux Journal is about porting the GTK+ Linux
application Gothello (Othello) to Windows. It wasn't very hard.

Cheers,

Robin