Subject: Re: [SWIPL] Announce: SWI-Prolog 4.0.8/XPCE 5.1.8

From: Jan Wielemaker <[email-masked]>
Date: Fri, 6 Jul 2001 16:09:26 +0200

Paul,

I'm not an expert ...

> re: Cygwin (about which I don't know enough yet...)
> 
> Is it like this:
> 
> You are now maintaining a SWI-Prolog port to the Cygwin pseudo-platform?

Officially I'm not maintaining anything :-) In practice I maintain
SWI-Prolog for platforms we use or have enough users complaining if
something goes wrong (enough normally means >0 for POSIX based plaforms
as it is supposed to be portable to these).

My aim is to base building on POSIX on the GNU libtool suite, which
should improve portability a *lot*. *The* windows binary remains based
on its own separate makefiles using nmake and MSVC.

> And actually there are two variants of this platform: Cygwin-via-POSIX
> and Cygwin-direct-to-Win32?

Cygwin consists of a POSIX runtime library and a port of the GNU
toolchain.  The Cygwin version of gcc (the C-compiler of the suite)
can generate code for use with the POSIX runtime or native Win32 code.

> And each port could, in principle & practice, be offered in a binary-only
> version, but would require that the target machine at least has the
> Cygwin runtime library?

I think that is correct.

> And furthermore, each could perhaps be offered as a binary distribution
> with a suitable Cygwin runtime library bundled in?

Also true, though you should check the Cygwin licence conditions. I
think you'll be fine, but I normally work in academic setting which
make these issues a bit more relaxed (GPL is no problem at all for
us).

> And that if you want to support fork() and exec() on Win32, and hence
> socket-based servers etc, this is currently the only way? (necessary
> and sufficient...)

Yes. Forking works fine, but is a bit slow (technically speaking, modern
Unix split the process using copy-on-write, while Cygwin couldn't get it
any better then making a real copy, so if your server is big the fork
gets real slow).

> But if Win32 SWI-Prolog users want to develop foreign libraries using
> MS VC++, they won't be able to use the Cygwin-via-POSIX variant, but
> should be OK with the Cygwin-direct-to-Win32 flavour?

The latter is surely ok. The former might (and likely will) work if you
make MSVC not use msvcrt*.dll and compile for single-threading.  The
first restriction is documented with Cygwin. I'm not sure on the second.

> Or have I got this all wrong?!

As you see, close.  All standard compiled packages work under Cygwin, 
though XPCE's port is incomplete and hardly tested.  Biggest problem
is that is doesn't listen to the gui while waiting for the console,
so you have to start your own dispatch-loop.

	Cheers --- Jan