From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBFATH1c013929 for ; Thu, 15 Dec 2011 11:29:17 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBANzK6U5KfVM2kGdsb2JhbABEqyQIIgEBAQEJCQ0HFAQhgXIBAQEDARICLAEbFAkBAwELBgULAwouIgERAQUBDgENBhMaAQeHWAiaeAqLZYJrhHBAiHECBQuLfASNPYc5jXU9g3k X-IronPort-AV: E=Sophos;i="4.71,356,1320620400"; d="scan'208";a="123468008" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Dec 2011 11:29:11 +0100 Received: by eekc50 with SMTP id c50so2499216eek.27 for ; Thu, 15 Dec 2011 02:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WsB2lxgxqxkF1e4yd68nLL5NIHPXgkLKxfxhWg+dmvY=; b=mILSGe3htamFIVE9972OMGzOuEHtlVNKETQf1qFpIuBLg77NCt6nMyjWDw+jXn6Pfv 6V65zyj7aDGJbvG/segV6q2G7sJF4dzebBm7xiYOu3JaTeRsiPLD/51KIizSAkXWbw4U GNfGIj/MI8xqfxCiCi0d3FMMyUkVg/znEMXoQ= MIME-Version: 1.0 Received: by 10.14.99.78 with SMTP id w54mr1134483eef.33.1323944950967; Thu, 15 Dec 2011 02:29:10 -0800 (PST) Received: by 10.213.10.148 with HTTP; Thu, 15 Dec 2011 02:29:10 -0800 (PST) In-Reply-To: References: <4EDE33A0.6070004@gmail.com> <1323760512.9833.9.camel@samsung> <4EE711FB.5020602@frisch.fr> <4EE83C26.7090108@frisch.fr> <1323867161.7750.27.camel@samsung> <4EE8DC93.1000806@metaprl.org> <1323884194.7750.58.camel@samsung> Date: Thu, 15 Dec 2011 11:29:10 +0100 Message-ID: From: Adrien To: David Allsopp Cc: Gerd Stolpmann , Aleksey Nogin , "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Some comments on recent discussions On 14/12/2011, David Allsopp 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