Porting to Windows CE

[Tom Tromey]

>>>>> "Jason" == Jason Swain <jason@parochus.com> writes:

Jason> 1. We need gcc support for WindowsCE (MIPS and ARM). There was
Jason> some work on this but it doesn't seem to be complete.

Jason> 2. We need libgcj ports to Windows CE and Symbian EPOC.

I personally don't know much about CE, and I know nothing about EPOC.

The Windows port in general is still incomplete.  However, it is
making progress.  There are some patches floating around to make it
better; these will be checked in once the copyright assignment
problems have been resolved.  (To those involved: any word on that?)

I think architecture-wise you're probably ok.  I think the MIPS and
ARM ports work fine.  Neither libffi port has been completed, so the
interpreter won't work on these platforms (I don't know if that is
important to you).  I've never done a port of the libffi closure code,
so I couldn't say how long that would take.

If you want thin locks to work (this is a gcc 3.1 thing -- doesn't
appear in 3.0) then some assembly language is required.  I think the
thin locks so far have only been ported to x86, IA-64, and alpha.  I
don't know how hard this is either.

OS-wise, the following things are needed for a port:

* A port of the GC.  Generally speaking this isn't very hard.
  However, whether it is possible depends on some details of your
  thread implementation.  I don't know whether the GC has yet been
  ported to WinCE.

* A port of the libgcj thread layer.  There are some docs on this on
  the web site.  It isn't too hard in theory.

* A port of the libgcj file handling code.  This is usually pretty
  straightforward.  There is code for FileDescriptor and code for
  File.

* The libgcj networking code has never been ported to a non-POSIXy OS.
  If you want that then it might be difficult.  Or maybe there is a
  compatibility layer for your OS that you could use.

* There is some process handling code in libgcj that would need to be
  ported.

* There's some miscellaneous stuff in System and maybe Runtime.
  This is easy.

Some other notes:

* If your OS doesn't have iconv(), then character set support in
  libgcj is very limited.

* For a long time we've wanted to separate the underlying
  FileDescriptor code so it can be different for files and for
  sockets.  I think this is required for the Windows port to work
  correctly.  This still hasn't been done.

Tom