MSVC and ActiveState

With the release of the MSVC cmdline tools, I started wondering what this might do to ActiveState, and ActivePerl in specific. Here's a few thoughts I had, in no particular order:

Immediately, it does nothing, because every module with XS now needs to be tested against the new cmdline tools, and probably modified. (q.v. 346164)
ActivePerl is more than just Perl - it's also an ActiveX extension and has support for ASP. Could those be supported outside ActivePerl? Would they?
Does this have an impact outside of Perl, such as Python and Ruby? Lisp, even?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Comment on MSVC and ActiveState

Replies are listed 'Best First'.
Re: MSVC and ActiveState by diotalevi (Canon) on Apr 19, 2004 at 14:36 UTC
I'm not going to attempt to test any of my XS code against the newly available compiler until there is a version of perl that I can get running without having to fiddle with (like Corion did). I'll test against the version that Just Works and test gladly!	[reply]
Re: MSVC and ActiveState by Jouke (Curate) on Apr 21, 2004 at 12:36 UTC
I don't think this will have any effect on ActiveState's strategy at all. Jan Dubois (Sr. at ActiveState) posted this on P5P regarding this subject: You could get VC++ for free for a couple of years already; it is part of the .NET Framework redistributable. The new (and indeed very cool) thing is that now the code optimizer is included in the free version too. There is one thing I don't like about VC++ 7.0 and later: it no longer uses the C runtime library that is part of the OS: msvcrt.dll. Instead it now bundles a versioned library with each compiler release. We have already seen msvcr70.dll and msvcr71.dll. So if you compile modules with different compiler versions, you end up loading multiple runtimes into your process. And if you want to wrap your Perl program with PAR, PerlApp or Perl2Exe, then you'll have to ship all these runtime libraries as well whereas you know that you already have msvcrt.dll on each potential deployment system. This is one of the major reasons we decided to stick with VC++ 6.0 for ActivePerl in the past, and I don't see us changing that anytime soon. I personally don't quite understand what you mean by 'what it might do to Activestate'. I'd think you mean by this that the only reason that Activestate exists is that they have the possibility to distribute a binary Perl. That's not what they make a living of. They have tools, like Komodo and the Perl Dev Kit. The ActivePerl distribution is free, so there isn't much of a difference now that MS releases their MSVC commandline stuff for free... Jouke Visser Speaking at the 2004 O'Reilly Open Source Convention about pVoice	[reply]