# Differences in VC6 and VC9 Windows builds and MSSQL Driver. - Thread: https://externals.io/message/42414 - Original archive: https://news-web.php.net/php.internals/42414 - Started by Richard Quadling on 2008-12-31T10:11:53+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #42414 — Richard Quadling — 2008-12-31T10:11:53+00:00 URL: https://externals.io/message/42414#42414 Hi. With regard to http://bugs.php.net/bug.php?id=46971, how much effort is needed (if any) to document that some functionality is not going to be available in all windows builds? [DOC] Or, When will VC6 be dropped? [CORE and DOC] Admittedly, it is only an issue for Microsoft SQL Server (mssql and pdo_mssql) and for Sybase_ct. With Microsoft having their own PHP extension for talking to MSSQL (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - though documented to only support SQL 2005 and 2008, not 7 or 2000), could this become the standard alternative for php_mssql.dll (though not PDO as the MS extension is procedural only, leaving ODBC as the route for older versions? -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #42415 — Richard Quadling — 2008-12-31T10:38:30+00:00 URL: https://externals.io/message/42414#42415 · In reply to: #42414 2008/12/31 Richard Quadling : > With Microsoft having their own PHP extension for talking to MSSQL > (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - > though documented to only support SQL 2005 and 2008, not 7 or 2000), > could this become the standard alternative for php_mssql.dll (though > not PDO as the MS extension is procedural only, leaving ODBC as the > route for older versions? http://www.codeplex.com/SQL2K5PHP is another link for this extension. Regards, Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #42416 — Uwe Schindler — 2008-12-31T10:57:25+00:00 URL: https://externals.io/message/42414#42416 · In reply to: #42414 Hi Richard, I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly map into servers may have problems if using the wrong CRT. Until now, I had no time to build up a Windows "Sun Java System Webserver" and test it with both CRTs. The code compiles fine on the snaps box, but I am not sure, if the DLL loads into the server. To the snaps build: The NSAPI module tests for "#define ZTS" and does therefore not compile without thread safety. Why do the windows non-ts builds on snaps.php compile? Is ZTS on windows always defined (it looks like so in the makefile). How to test on windows, if thread safety is available? But better would be to disable thread-unsafe builds for the NSAPI SAPI from the beginning. Uwe ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Richard Quadling [mailto:rquadling@googlemail.com] > Sent: Wednesday, December 31, 2008 11:12 AM > To: PHP Documentation ML; PHP Developers Mailing List > Subject: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL > Driver. > > Hi. > > With regard to http://bugs.php.net/bug.php?id=46971, how much effort > is needed (if any) to document that some functionality is not going to > be available in all windows builds? [DOC] > > Or, > > When will VC6 be dropped? [CORE and DOC] > > > > Admittedly, it is only an issue for Microsoft SQL Server (mssql and > pdo_mssql) and for Sybase_ct. > > With Microsoft having their own PHP extension for talking to MSSQL > (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - > though documented to only support SQL 2005 and 2008, not 7 or 2000), > could this become the standard alternative for php_mssql.dll (though > not PDO as the MS extension is procedural only, leaving ODBC as the > route for older versions? > > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" --- ## #42417 — Pierre Joye — 2008-12-31T11:02:17+00:00 URL: https://externals.io/message/42414#42417 · In reply to: #42414 hi Richard, On Wed, Dec 31, 2008 at 11:11 AM, Richard Quadling wrote: > Hi. > > With regard to http://bugs.php.net/bug.php?id=46971, Can you repost (and subscribe to the list if you did not subscribe yet) to the right list please (Windows Internals list)? Thanks, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #42449 — William A. Rowe — 2009-01-02T16:01:23+00:00 URL: https://externals.io/message/42414#42449 · In reply to: #42416 Uwe Schindler wrote: > > I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly > map into servers may have problems if using the wrong CRT. Until now, I had > no time to build up a Windows "Sun Java System Webserver" and test it with > both CRTs. The code compiles fine on the snaps box, but I am not sure, if > the DLL loads into the server. Precisely. Note that httpd 2.4 (.next) will not be compiled with VC6, but may continue to use msvcrt.dll - if I successfully validate a proper method (which might rely on some sdk/wdk includes) for continuing to use this lowest common denominator crt with sources compiled on modern compilers, I'll be sure to send this feedback in. 99% certain that the classic method is simply wrong (link32 msvcrt.lib /ignore:msvcrXX.lib) since the correct clib headers corresponding to msvcrt are required to avoid abi issues. --- ## #42450 — Pierre Joye — 2009-01-02T16:17:32+00:00 URL: https://externals.io/message/42414#42450 · In reply to: #42449 hi William, On Fri, Jan 2, 2009 at 5:01 PM, William A. Rowe, Jr. wrote: > Uwe Schindler wrote: > > […] > > Precisely. Note that httpd 2.4 (.next) will not be compiled with VC6, but > may continue to use msvcrt.dll - if I successfully validate a proper method > (which might rely on some sdk/wdk includes) for continuing to use this > lowest common denominator crt with sources compiled on modern compilers, > I'll be sure to send this feedback in. 99% certain that the classic method > is simply wrong (link32 msvcrt.lib /ignore:msvcrXX.lib) since the correct > clib headers corresponding to msvcrt are required to avoid abi issues. I'm not sure it is worth the effort. What would be the gains besides not having to distribute the 9.0 CRT (which is a non issue for the installers and a one time install for the other)? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #42483 — Lukas Kahwe Smith — 2009-01-05T14:36:02+00:00 URL: https://externals.io/message/42414#42483 · In reply to: #42414 > With Microsoft having their own PHP extension for talking to MSSQL > (http://www.microsoft.com/sqlserver/2005/en/us/PHP-Driver.aspx - > though documented to only support SQL 2005 and 2008, not 7 or 2000), > could this become the standard alternative for php_mssql.dll (though > not PDO as the MS extension is procedural only, leaving ODBC as the > route for older versions? I do not see us adding a new RDBMS specific extension that only works on one OS (that is not even our main target OS in practice for deployment) for an RDBMS that is also quite a niche solution for PHP. Actually the only RDBMS where I am willing to currently consider a new non PDO extension sqlite. As such I do not think we should consider bundling this extension, let alone have it replace the php_mssql.dll. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #42484 — Lukas Kahwe Smith — 2009-01-05T14:43:54+00:00 URL: https://externals.io/message/42414#42484 · In reply to: #42483 > target OS in practice for deployment) for an RDBMS that is also > quite a niche solution for PHP. Actually the only RDBMS where I am > willing to currently consider a new non PDO extension sqlite. Just to make it clear what I was talking about here (there is an "is" missing in front of sqlite): http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite3/ And sqlite3 is already in 5.3 .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #42485 — Richard Quadling — 2009-01-05T14:52:36+00:00 URL: https://externals.io/message/42414#42485 · In reply to: #42483 2009/1/5 Lukas Kahwe Smith : > > > > > […] > > > I do not see us adding a new RDBMS specific extension that only works on one > OS (that is not even our main target OS in practice for deployment) for an > RDBMS that is also quite a niche solution for PHP. Actually the only RDBMS > where I am willing to currently consider a new non PDO extension sqlite. > > As such I do not think we should consider bundling this extension, let alone > have it replace the php_mssql.dll. Even though it will most likely be the case that php_mssql.dll will not be available for later versions of PHP/CRT/etc. Or, are you saying that PHP support for MSSQL is via ODBC only (I don't know if php_pdo_mssql uses ntwdblib.dll like php_mssql and as such suffers in the same way). > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #42486 — Lukas Kahwe Smith — 2009-01-05T15:00:35+00:00 URL: https://externals.io/message/42414#42486 · In reply to: #42485 > 2009/1/5 Lukas Kahwe Smith : > > […] > > Even though it will most likely be the case that php_mssql.dll will > not be available for later versions of PHP/CRT/etc. > > Or, are you saying that PHP support for MSSQL is via ODBC only (I > don't know if php_pdo_mssql uses ntwdblib.dll like php_mssql and as > such suffers in the same way). What I am saying is that ext/mssql should be kept alive as long as we keep the other "native" RDBMS ext around. Even if its not possible to keep it alive for this long for whatever reason, users should be directed at PDO. regards, Lukas Kahwe Smith mls@pooteeweet.org