William A. Rowe, Jr. wrote:
> Issac Goldstand wrote:
>> -0.5
>>
>> I would actually like to see builds prepared against MSVCRT80, which is
>> available in the Vista SDK's bundled free compiler, rather than having
>> users need to download the SDK + VS Express Edition + configure the one
>> to find
Issac Goldstand wrote:
-0.5
I would actually like to see builds prepared against MSVCRT80, which is
available in the Vista SDK's bundled free compiler, rather than having
users need to download the SDK + VS Express Edition + configure the one
to find and work with the other (a royal pain). As l
-0.5
I would actually like to see builds prepared against MSVCRT80, which is
available in the Vista SDK's bundled free compiler, rather than having
users need to download the SDK + VS Express Edition + configure the one
to find and work with the other (a royal pain). As long as the latest
SDKs ar
On Fri, 28 Dec 2007, Randy Kobes wrote:
> On Fri, 28 Dec 2007, Jan Dubois wrote:
> > Therefore I'm genuinely interested to learn where the problems are
> > if you build say Apache with VS2008, Perl with VC6 and e.g. mod_perl
> > with VC7. I would expect this to work just fine if we ignore the
> >
Jan Dubois wrote:
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
The obvious question is; what are your include libraries for that
module? The modern compiler's? (e.g. studio 200X?) The SDK's? Or
continue to build with VC 6?
That Platform SDK headers (in case the module uses APIs that were
i
On Fri, 28 Dec 2007, Jan Dubois wrote:
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
[ ... ]
My instinct, with 2008 adding the new SDK features for apr such as
multicast group filtering, and the continued availability of a 2008
'express'/'lite' free version, is to take httpd 2.4 (3.0?) bina
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Jan Dubois wrote:
>> I still haven't seen a compelling argument why someone wants to move
>> away from using MSVCRT.dll (and then continue switching CRTs then
>> every other year).
>
> The obvious question is; what are your include libraries for th
Jan Dubois wrote:
The initial switch away from MSVCRT.dll was due to a conflict inside
Microsoft between the Windows and the VC++ teams: MSVCRT.dll has become
so important to the operation of Windows itself that the compiler team
was no longer allowed to update it; ownership had been transferred
On Fri, 28 Dec 2007, William A. Rowe, Jr. wrote:
> Studio 2008, true to form, proves that MS is incapable of keeping
> around a stdc library any longer than one product cycle. Yes, our long
> awaited (not) MSVCR90 is here.
You can expect a new runtime library version for each compiler release
from
