RE: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.

> Because the MS paradigm is nonsense - we will always be a family of
> interoperable moving pieces; and we should expect some 2005 compiled
> modules, some 2008 compiled modules and some 2010 (VC.next) compiled
> modules, none of which share a crt.  That, of course, is utterly
> bullshit.  With PHP, perl, python and lua compiled in, we are in four
> different crt's at once (if one used ActiveState).
> 
> OpenSSL project compiles to msvcrt from the modern compilers.  Until
> Microsoft can grok the concept of modular development coming from
> multiple parties (who don't share a single 'corporate direction' in
> terms of the tools to use when and where), I'm afraid practically
> speaking we can't follow the "wisdom" of the studio/c++ team.
> I've broached this issue to them at Redmond, but I'm afraid all we
> got were puzzled looks (you need to do what?!?  No company uses four
> flavors of Visual Studio in the same finished binary.)

This is another very famous incident with multiple CRT:
Until Java 5, Sun compiled its JVM with VC6 and the standard CRT msvcrt.dll
that is shipped with every windows version. A lot of programs (best example
was Eclipse) use a stub EXE file, loading jvm.dll after looking up the last
recent JVM from registry. This is often used to ship CD-ROM with Java
programs. Bad practise is to bundle a very old JVM, so the better solution
is for the EXE file to detect the last recent one on the target computer and
use it. If no JRE installed, a JRE installer is launched. Very simple and
very nice to do. On success, the EXE stub loads jvm.dll from the
installation path of the JRE (from registry). With Java 6, Sun breaked this,
because they used a newer CRT when compiling jvm.dll. The problem was that
programs, that dynamically load the jvm.dll now get DLL not found
exceptions, because msvcrXXX.dll was not in search path of the linking
program (e.g. in Eclipse Dir, on CD-ROM). Sun has solved this problem
partially in newer Java versions, but it shows the problem, this problem
affects thousands of programs and CD-ROMs (including one of our
developments)

But on the other hand it shows: The stub program was often linked with VC6
and msvcrt.dll. But it was able to load the jvm.dll using another CRT, as
long as the other's CRT DLL is in search path. Problems only occur, if
between the VC6 DLL and VC9 DLL data is exchanged that relies on different
header files. In case of the JVM, the public API is not CRT dependent. So in
my opinion, for Sun web servers, the CRT used by PHP is irrelevant for the
web server itself, because the linked symbols are NSAPI-private only. And
the JVM problem shows, that it is possible for one process to load different
CRTs in parallel. There are only problems, when symbols like FILE* from the
CRT etc. are used and exchanged between the two modules (which is the case
with Apache Webserver I think), simple example: DLL (a) exports a function
with signature dosomething(FILE* param) and DLL (b) wants to use it. Because
CRT is different and the header files are different, FILE may look different
=> crash.

In my opinion, the best is to avoid this conflict and link with VC6 header
files and CRT (like OpenSSL does).

Uwe