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

[Sylvain Beucler]

On Sun, Aug 26, 2007 at 01:28:35PM +0200, Bruno Haible wrote:
> 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
> Latin).

Oops I meant free-as-in-free-beer.  I meant that's the only version I
have under the hand and it was valuable in the first steps of porting
the code to g++ (the code was pretty fragile and it was interesting to
know whether the latest changes made it misbehave only under MinGW, or
better test how to translate a weird construct that g++ was not
accepting and produced only a warning in vc++).

I can't redistribute binaries from that version _at all_ anyway,
there's even a splash message box that says so when launching the
resulting .exe (and there even was a plug-in out there to remove that
message box but that's illegal and besides the point ;)).


> > 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.

Thanks.

In my particular case, I'm porting a program that is not actively
developped iself, yet surrounded by a community of people who tend to
use VC++ for utilities. I don't think they are sympathetic enough to
free software to accept a "just adapt to my ways" answer, so in order
to be more progressive about it, I was wondering about making the
project compile with VC++ for a little longer (as libsdl does somehow)
- mingw requires command line knowledge for ./configure and is several
times slower.

But indeed it sounds better to drop VC++ altogether.  I shall use
mingw as the Woe portability layer, and put more effort in supporting
Code::Blocks for convivial compilation.

-- 
Sylvain