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

> >> And in windows (which is different to UNIX), it is possible to have
> more
> >> than one CRT in one single process (because linking in windows is *not*
> only
> >> dependent on the symbol name, it uses symbol name *AND* dll name for
> >> linking).
> >
> > With the risk to repeat myself: mixing CRT is a bad idea. Whether it
> > works with SWS or not is not really relevant as all the stack has to
> > work (all libs, all deps, etc.). I still think that moving away from
> > VC6 is the way to go and I'm happy to see than Sun is considering VC9
> > :)
> 
> In this case, Une is 100% correct.

Thanks! :-)

> If you are not free()ing what had
> been malloc()ed for you by the other msvcrt consumer, if you are not
> registering clib callbacks with atexit() and family, if you are not
> using FILE* or fd's created in one msvcrt within the other, you
> *should* be 100% safe.

And this is exactly the case for NSAPI. The webserver consumes and frees his
resources, it is using *his* CRT alone (see my other mail with an exact
explanation).

> An example of this is the mod_aspdotnet library which used a much more
> modern blend of msvcrXX and ole/coruntime within an older httpd/msvcrt.
> Never a flaw due to the discrepancy, because httpd objects are managed
> and reclaimed by httpd, while mod_aspdotnet only used httpd's abstractions
> in an opaque manner and handled the destruction of it's own resources.

Another example:
Windows API does not link to any CRT, so no problems. But there are other
public Windows APIs, that use DLLs, that are itself linked to VC6's msvcrt.
The best example is MSIE. There are thousands of programs using the MSIE
shdocvw/mshtml-API. As soon as you link to these DLLs, you also link to
msvcrt.dll. And a lot of these thousands of programs are compiled with VC9.
Even example programs from Microsoft's VC9. So where is the problem? All
these programs link to both CRTs - no problem. The important part:

In windows, the CRT is only a small part of what the CRT is for linux
programs. In Linux, every call to kernel functions like stat() is exported
by the CRT. In windows, all programs directly link to kernel32.dll,
user32.dll, advapi.dll,... All these libraries are part of Windows API and
are not related to any CRT. They are part of the operating system and his
win32 API. This is really different to Linux or BSD (and this make windows
and win32 cool in my opinion). This is missing in linux: A library that just
exports symbols from the kernel, without any other logic.

The CRT part of msvcrt, msvcr90 and so on is just a thin wrapper, exporting
some functions, that are not directly part of the windows API, but needed
for some POSIX compliance. This include things like malloc, FILE* etc.

There are windows programs that do not use any CRT at all (because they do
not use malloc). Examples are Delphi (pascal) programs. Delphi has his own
small stub, called SYSTEM Unit, that supplies malloc and so on. The rest is
pure Win32 API.

In "Windows speek" a good API (that is windows conform) does not use symbols
from CRTs, only symbols from Windows API. And APIs like NSAPI or Sybase CT
or ODBC are designed this way. This is why you can use an ODBC driver in any
application regardless if the driver itself uses whatever CRT it likes (or
none at all).

Uwe