Why PHP SAPI (php5_apache.dll) built with VC9 won't work with Apache built with VC6

Question

As announced by http://windows.php.net/ , PHP SAPI (php5_apache.dll) compiled with VC9 won't work with Apache compiled with VC6.

For Apache SAPIs (php5_apache2_2.dll), be sure that you use a Visual Studio C++ 9 version of Apache. We recommend the Apache builds as provided by ApacheLounge. For any other SAPI (CLI, FastCGI via mod_fcgi, FastCGI with IIS or other FastCGI capable server), everything works as before. Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we now provide.

But, a DLL built with any version of VC(vc11, vc9, vc6), even Borland C++, should be able to be loaded and executed by any version of binaries (DLL or EXE) with no problem.

Why PHP SAPI (php5_apache.dll), as a DLL, compiled with VC9 won't work with Apache compiled with VC6?

Answer 1

But, a DLL built with any version of VC(vc11, vc9, vc6), even Borland C++, should be able to be loaded and executed by any version of binaries (DLL or EXE) with no problem.

Loaded yes (for example, using the LoadLibrary API call), that should work. Now whether you can call the exported functions and have them work properly, that is a different story.

If the exported functions accept or return types that are not the generic Windows types (ie DWORD, LONG, BOOL, etc. and pointers to those types), then all bets are off. This is especially the case if the type is a class or struct that can either have different internals between versions, or uses dynamic memory allocation.

If the Apache authors deem it is necessary to now match versions of the DLL with a certain compiler, they wouldn't announce this without doing the research. More than likely, they discovered that it really is a necessity due to a change in the internals of the parameter and/or return types used by the DLL and application.