[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Visual C++ (was: PATH_MAX with mingw)

From: Bruno Haible
Subject: Re: Visual C++ (was: PATH_MAX with mingw)
Date: Sun, 26 Aug 2007 13:28:35 +0200
User-agent: KMail/1.5.4

Sylvain Beucler wrote:
> PATH_MAX is however not defined under the visual c++ 6 / free version
> that I'm using for the port. ...

Ahem, you call that "free"?
  - As far as I remember, Microsoft did not give the permission to
    redistribute the copies, and they have meanwhile removed it from their
    own website. They now offer Visual C++ 2005 [1] for download, but its
    compiled programs rely on a DLL library that is not part of older
    Windows distributions.
  - The EULA says that one may only redistribute binaries compiled with
    Visual Studio if they "only operate in conjunction with Microsoft Windows
    platforms". So, one has to take measures that such binaries cannot be
    used with Linux+Wine.
You call that "free"?? It's rather a poisoned present ("Danaum munus" in

> So supporting MAX_PATH is essentially supporting visual c++ more
> precisely (I'm not sure that's what I want). It depends on whether
> gnulib's portability goal extends to supporting unmodified W32API. Is
> that the case?

Compiling GNU programs with Visual C++ was something that a few people did
in the past, but that is not seriously done anymore nowadays, for the
following reasons:

  - You have the choice among
    (a) restricting yourself to an outdated compiler (Visual C++ 6),
    (b) have users of older Windows systems not be able to execute your
        program because they don't have msvcrt7.
    (c) ship msvcrt7 together with the binaries of your program, which AFAICT
        violates the GPL of your program.

  - Either you write all Makefiles by hand for 'nmake', or you let the
    developer install a Unix 'sh' and 'make' - preferrably through mingw.
    But once the developer has installed mingw, there is no point any more
    using the Microsoft compiler.

  - The MSVCRT does not support readdir. Many packages rely on readdir in
    one form or the other.

  - configure files expect to call the compiler with Unix conventions, like
    -o and -c flags. This requires a wrapper script around MSVC. There are
    such wrapper scripts, but none of them is a de-facto standard.

  - libtool does not support this configuration, although patches to that
    effect were submitted already more than two years ago.

So, my conclusion is that for GNU projects, we can consider Visual C++ as dead.


[1] http://msdn2.microsoft.com/de-de/express/aa975050.aspx

reply via email to

[Prev in Thread] Current Thread [Next in Thread]