[Mono-list] Latest mono for Cygwin

Dick Porter dick@ximian.com
Thu, 31 Jan 2002 10:03:49 +0000

On Thu, Jan 31, 2002 at 09:33:35AM +0000, Dan Lewis wrote:
> At the moment the build system appears to have two Win32 targets, denoted by
> the
> defines PLATFORM_WIN32 and PLATFORM_WIN32_NATIVE. The first is meant for Cygwin
> (Unix-style API, linking to the cywin1.dll emulation layer), the second for
> MinGW.
> Now IMHO, I think the PLATFORM_WIN32 target (Cygwin) should be scrapped, or at
> least put on the back burner - and PLATFORM_WIN32_NATIVE (MinGW) should be the
> Windows default. The reason being is that Dick Porter's io-layer, which is sort
> of like a mini-Cygwin in reverse, would be mapping the Windows API to the Unix
> API, and then Cygwin would be mapping the Unix API back to Windows. This is
> crazy enough, but you'd also have to actively maintain the code for Cygwin,
> which is already missing a few screws. (Unfortunately it's difficult to use
> both
> cygwin1.dll and the MS runtime libraries together, because certain things
> collide
> - eg the sockets namespace).

Actually, on cygwin the io-layer is bypassed. Cygwin has its own wrapper
for the native w32 calls (in the w32api package).  Mono has been known to
build under cygwin (we try and keep it working, though none of the runtime
developers builds it on windows very often), but the mingw "support" in
configure.in and io-layer is really just good intention.

> To fully support the native target, we need to do a few things. Where Unix
> libraries are used, a Windows alternative needs to be provided. There's an
> example of this in rawbuffer.c, which uses mmap() under Unix and file mapping
> under Windows. Thankfully there are only a few places where this needs to be
> done (the class globber in monowrapper uses the Unix regex library, for
> instance).

The monowrapper library is being deprecated in favour of the io-layer library.

> Secondly, a Windows target for corlib needs to be built. There's some code to
> do
> this in the class library, but I can't seem to get it to compile. (I could run
> hello world using the Linux library, but the loader throws up loads of warnings
> when it trys to link internal methods to libc and libm instead of MSVCRT.)

The separation between windows and posix builds (the System.PAL namespace)
is also being deprecated in favour of the io-layer library.  At the moment,
sorting out class/corlib/Windows/Windows.cs to match Linux.cs shouldn't be
too difficult - all the internal calls should be exactly the same.

- Dick