Win32 Port

[Tom Tromey]

>>>>> "Jon" == Jon Beniston <jon@sentinelware.freeserve.co.uk> writes:

Jon> I'm interested in (doing) a Win32 port, I've read through the
Jon> mailing list but there seems to be no mention of one. Is this
Jon> something that is likely to be feasible assuming a CygWin
Jon> environment? What's going to cause the most problems, threads?
Jon> Encouragement and hints welcomed!

I'd be really interested in seeing a Windows port.

Actually, there is room for two "Windows" ports: a native port and a
Cygwin port.  I have a preference for seeing the former first, since I
think it would be the best way to go.

There are some documents on the web page describing the porting
process.  You must port the file layer, the GC, signals, and threads.
There is also some as-yet-undocumented porting: java.net, processes,
and properties.

This sounds like a lot, and it is.  But some of it is easy.  The GC is
probably already done.  The file and thread layers are probably fairly
simple to map onto Windows calls.  Processes were set updesigned to be
fairly easy to port (you just have to write a Windows version of
ConcreteProcess).

I don't know what, if anything, is involved in porting java.net.  It
might be hard or it might be easy.

You'll still need a Unixy environment in which to build things.  That
is, you need sh and friends to run configure and make.  But the goal
(at first) should be not to rely on Cygwin at runtime (unless this is
what you really want to do, like I said I'd prefer a native port).


There is some configury work involved, too, but it should be easy (at
least at first).  Ultimately we want to support Windows cross builds
(so I can build a Windows libgcj from my Linux box), but you probably
don't have to worry about that.


I've been thinking for some time now that we need a better portability
infrastructure in those cases where entire files depend on the OS
"flavor" (Windows, Unix, various embedded things).  For instance, the
file handling layer could somehow be segregated into its own files and
automatically renamed at configure time -- much as they are now; I'm
just picturing something a bit more structured.  Or maybe I'm just
picturing documentation and consistency.  My thoughts on this aren't
any more clear than that, so make of it what you will.  This is
different from the ordinary autoconf-style of using macros.  When
doing a port to a completely different OS family, you'd end up with
#if hell.


Don't be discouraged!  I'd be happy to check in even partial ports.
For instance, if you port the thread layer, I could just check that
in.  That way we are at least inching closer to the goal of making it
work on WIndows.

Finally, be aware of copyright assignment issues.  Before I can check
in major work (> 10 lines of code) I need legal stuff filled out for
Cygnus.  Instructions are on the web page.

Tom