Re: [Caml-list] Some comments on recent discussions

[Adrien <camaradetux@gmail.com>]

On 14/12/2011, David Allsopp <dra-news@metastack.com> wrote:
> Gerd Stolpmann wrote:
>> Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
>> > On 14.12.2011 04:52, Gerd Stolpmann wrote:
>> >
>> > > I don't think you will be able to convince everybody - at this point
>> > > the issue becomes political in some sense: Do we want to give up our
>> > > Unix habits just to support an OS we (often enough) do not like, and
>> > > would only cover to get more love from the world?
>> > >
>> > > There could be an alternative: The "busybox approach". We could
>> > > develop a toolkit that covers all the Unix commands we need for the
>> > > existing build scripts. It would include easy things like cp, mv
>> > > etc., but also a classic "make" (medium difficulty, note that it
>> > > could reuse the godi_make code), and especially a POSIX shell. The
>> > > latter is a bit of work, but not too much. I'd guess the overall
>> > > effort takes not more than
>> > > 1-2 weeks if done by somebody how knows the semantics of the tools
>> > > very well.
>> > >
>> > > There are a number of advantages over Cygwin:
>> > >  - No danger of running into licensing problems
>> > >  - The Unix compatibility is only maintained for commands, but not on
>> > >    the system call level (eaiser to use, less surprises, fewer
>> > > deps,...)
>> > >  - It would only be a small download, and easy to integrate into
>> > >    installers
>> >
>> > Note that to a degree, OMake already provides the ability to do
>> > Unix-style things under Windows.
>>
>> I know, and this makes me quite optimistic that it is not that hard to
>> develop standalone executables for the frequently used Unix utilities.
>
> Any particular reason why the GnuWin32 project doesn't already fulfil this
> requirement (http://gnuwin32.sourceforge.net/)?

It's not maintained well and it's often quite dirty.

This is from the main page, "News" section:
> 7 June 2009: LibPng-1.2.37: library and tools for PNG images: new release

I'm stealing the following from slackware's changelog, starting mid-2010:

> Upgraded to libpng-1.2.44 and libpng-1.4.3.
> This fixes out-of-bounds memory write bugs that could lead to crashes
> or the execution of arbitrary code, and a memory leak bug which could
> lead to application crashes.
> For more information, see:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2249

> Upgraded to libpng-1.2.46 and libpng-1.4.8.
> Fixed uninitialized memory read in png_format_buffer()
> (Bug report by Frank Busse, related to CVE-2004-0421).
> For more information, see:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0421

As you can see, gnuwin32's libpng is more than outdated.


Maybe we could reuse it and provide our own updated packages?
Unfortunately, the foundations are quite bad since they rely on libgw32c:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

If you look at this page, you'll see that it provides a fork() function!
Except that the body of the function is as follows:
> int __fork () {
>   __set_errno (ENOSYS);
>   return -1;
> }

This is a typical example and many functions are not available. Think about
it: making Windows a UNIX. That's not a trivial task and the only complete
solution is cygwin. You can't have both a unix and no additional dependency
(cygwin or interix/sua). And you don't want to do that anyway because
Windows is not UNIX: typical issues are paths and their encoding:

  http://permalink.gmane.org/gmane.comp.windows.gnu.user/1197
  (I'm being told that Windows paths are not UTF-16 but UCB; I'm unable to
   explain more unfortunately)

Hopefully, you don't need to make applications and libraries believe they're
on a unix: most of the time, there is a windows port. For some things like
build systems (makefiles, autotools, or perl-based ones or...), it's more
difficult but you can quite simply cross-compile.

GnuWin32 and libgw32c are not completely worthless however: they can be used
for small systems (to bootstrap something bigger for instance).

Regards,
Adrien Nader