Files to lib/System/Win32

From: Reid Spencer <reid@x10sys.com>
Date: Mon, 13 Sep 2004 21:07:16 -0700

Henrik,

The patches you submitted will not work (at all) for the Win32 platform
because they (still) use Unix system calls. Win32 doesn't have mkdtemp,
fork, execve, etc. Furthermore in Path.cpp forward slashes are still
used. These need to be changed to back slashes.

Specifically I've searched my win32 source for function calls of mkdtemp, fork and execve and they are exclude from compilation due to the MinGW configure didn't find it worth to flag HAVE_BACKTRACE and HAVE_SYS_WAIT.

I've specifically left the unix code untouched for HAVE_BACKTRACE and HAVE_SYS_WAIT inclusions, because if some one or me came across and felt it was worth rewriting, then the semantic implementation could be read, instead of one has to dig it out of some other sources.

So, I'm not familiar with mingw platform. Since you've stated they
compile on your mingw platform, I'm assuming mingw is some kind of Unix
clone like cygwin.

It's not another unix clone but it is POSIX.1 compatible at source code level. You can make truely win32 executables with it. The shell of MSYS support bash shell scripts :slight_smile: and that makes porting easy at the moment :slight_smile:

That raises for me the issue of whether we really
want to support *another* Unix interface on Windows. We are already
supporting cygwin and Interix.

It's up to you guys ...

So, would you consider using cygwin or Interix instead of mingw? If not,

as told lately, the Interix port is somewhat stalled on my local system. I'm still considering what I should do.

then I will place your patches into a lib/System/MingW directory and you
can provide the implementation there. If you want to go that way you'll

Still depends on you guys...

need to make some corrections to your patches. The main one is that
you've replicated the generic Unix code into the Path.cpp file. Instead
of doing that, I would prefer it if you #included it so we don't have
duplicate Unix code all over the place.

I've modified the unix code to be posix and win32 compatible. I considered an inclusion, but found out, that I had to make some modifications to some functions. I'll reconsider the inclusion of generic unix code, if I should move along with this port, too.

But, if you don't feel it's true win32 code, feel free to move it into a seperate folder.

Henrik