What's the oldest MS VC version Parrot should built with?
Ron Blaschke
ron at rblasch.org
Fri Dec 19 21:05:42 UTC 2008
Vadim Konovalov wrote:
> 在 Friday 19 December 2008 11:42:15,Ron Blaschke 写道:
>
>> I've probably just been lucky, but I've never had any issue because of
>> using different CRTs. If you or anyone else have, please share your
>> experience, I really would like to hear them!
>
> Again, Jan's explanation:
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-03/msg00725.html
>
> With different CRT you'll get unneeded bloat, and new CRT could not yet be
> installed on target OS, so in newer VC you need to provide user with
> instructions how to install CRT for VC9.
>
> WinXP+SP3 do have lates VC runtime, while pure WinXP could not!
AFAIK, the recommended way is to have the installer use the CRT merge
module, or distribute the vcredist with the installer and have it invoke
vcredist. This will install the CRT into WinSxS, and I think it'll make
it subject to Windows Update as well. There's no need to make the user
install the CRT themselves.
Regarding the bloat, I don't know the actual difference, but I'd only
optimize it based on numbers. Executables are memory mapped into the
processes, and paged only once if unchanged. The CRT's private data may
be the dominant factor for more than one process, and I doubt it
qualifies as bloat, unless I'm wrong. ;-)
>>> But there is another point: one of the widely used compilers on Win32 is
>>> GCC in "no-cygwin" mode, which is ordinary GCC in cygwin but it will
>>> create binaries dependant on VC6 CRT, AFAIK.
>>>
>>> It would be a pity to lose a possibility to create binary on the same
>>> CRT.
>> MinGW and Cygwin are supported, and if they use the standard (VC6) CRT
>> that's fine. I'm not discouraging the use of the library, just the use
>> of a decade old, no longer maintained compiler. Actually, if the CRT is
>> of prime importance, I strongly second Jerry's suggestion of using MinGW.
>
> the point I've raised is not choosing between GCC(mingv) and VC9, but rather
> why it could be desireable to not drop VC6 support, provided that there will
> be VC9 support anyway.
I don't think there will be huge efforts to break VC6, just that people
may not consider it when making changes. If things break (it's quite
possible they don't) and a fix that someone provides doesn't completely
mess things up, I don't see any reason not to include it. It may be
best just to see how things go, and discuss this when an actual issue
arises.
But that's just my opinion, I'm not in a position to make a call.
Ron
More information about the parrot-dev
mailing list