# VS 2005 Support for 5.3? - Thread: https://externals.io/message/32540 - Original archive: https://news-web.php.net/php.internals/32540 - Started by Pierre on 2007-10-02T11:34:46+00:00 - Messages: 17 - 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 --- ## #32540 — Pierre — 2007-10-02T11:34:46+00:00 URL: https://externals.io/message/32540#32540 Hi, One important thing we forgot to discuss is to drop VS6 support fin 5.3 and finally move to VS2005. It has a couple of side effects but it is a one time job and should make our life easier on windows from 5.3 and up. Comments? Cheers, --Pierre --- ## #32546 — Richard Quadling — 2007-10-02T13:40:57+00:00 URL: https://externals.io/message/32540#32546 · In reply to: #32540 > Hi, > > One important thing we forgot to discuss is to drop VS6 support fin > 5.3 and finally move to VS2005. > > It has a couple of side effects but it is a one time job and should > make our life easier on windows from 5.3 and up. > > Comments? > > Cheers, > --Pierre Would making the windows compiler MS VC++ Express Edition be a "better" solution? That way you have what is considered a "free" MS compiler. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #32547 — Daniel Brown — 2007-10-02T13:50:17+00:00 URL: https://externals.io/message/32540#32547 · In reply to: #32546 > > > […] Pierre, Off the top of your head, what side effects do you already anticipate, specifically? Also, I think Rich makes a good point about the "free" Microsoft VS2005 Express Edition, but I don't know how much more of a pain it would be to target that, or if it would cause long-term issues or detriment to the progress. -- Daniel P. Brown [office] (570-) 587-7080 Ext. 272 [mobile] (570-) 766-8107 Give a man a fish, he'll eat for a day. Then you'll find out he was allergic and is hospitalized. See? No good deed goes unpunished.... --- ## #32551 — Rob Richards — 2007-10-02T14:20:23+00:00 URL: https://externals.io/message/32540#32551 · In reply to: #32540 Hi Pierre, Going forward this might be a good idea, but there needs to be a good amount of testing. I have ran into an issue recently running apps built with VS 2005 using dynamically linked libraries built with older versions due to different runtime linking, which did make me think of this specific issue. Seeing that there are a crap load of third part dlls, things will need some extensive testing. The issue I saw was due to the fact that the application (built with 2005) created a FILE * using fopen. This was passed to a dll, which called fwrite (built with an older version). `fwrite()` was called within msvcrt8, while fopen was called within msvcrt causing a crash due to the use of different runtimes. Of course the FILE * probably should have been obtained from the dll (API permitting), but there is a good potential for similar issues with the number of libraries around and the fact that they can no longer rely on always being called from msvcrt like they could in the old days. Rob Pierre wrote: > Hi, > > One important thing we forgot to discuss is to drop VS6 support fin > 5.3 and finally move to VS2005. > > It has a couple of side effects but it is a one time job and should > make our life easier on windows from 5.3 and up. > > Comments? > > Cheers, > --Pierre --- ## #32554 — Stanislav Malyshev — 2007-10-02T16:25:04+00:00 URL: https://externals.io/message/32540#32554 · In reply to: #32540 > One important thing we forgot to discuss is to drop VS6 support fin > 5.3 and finally move to VS2005. As far as I know, non-CL builds are not supported at all right now, and for CL builds it works with both - is there anything should be done for VS2005? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #32555 — Stanislav Malyshev — 2007-10-02T16:26:47+00:00 URL: https://externals.io/message/32540#32555 · In reply to: #32547 > Off the top of your head, what side effects do you already > anticipate, specifically? Also, I think Rich makes a good point about > the "free" Microsoft VS2005 Express Edition, but I don't know how much > more of a pain it would be to target that, or if it would cause > long-term issues or detriment to the progress. IIRC there might also be some runtime issues since VS2005 links with some shared libs which may not be installed on older systems, so we need to verify this... -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #32556 — Andi Gutmans — 2007-10-02T16:58:05+00:00 URL: https://externals.io/message/32540#32556 · In reply to: #32551 I definitely think it's worth another go. VS 2005 binaries are significantly faster than VC 6 (at least last time I checked). We can also help out a bit with issues as we've tackled some of them already. Andi > -----Original Message----- > From: Rob Richards [mailto:rrichards@ctindustries.net] > Sent: Tuesday, October 02, 2007 7:20 AM > To: Pierre > Cc: PHP Internals List; Frank M. Kromann; Edin Kadribasic; Dmitry > Stogov > Subject: [PHP-DEV] Re: VS 2005 Support for 5.3? > > Hi Pierre, > > Going forward this might be a good idea, but there needs to be a good > amount of testing. > I have ran into an issue recently running apps built with VS 2005 using > dynamically linked libraries built with older versions due to different > runtime linking, which did make me think of this specific issue. > Seeing > that there are a crap load of third part dlls, things will need some > extensive testing. > > The issue I saw was due to the fact that the application (built with > 2005) created a FILE * using fopen. This was passed to a dll, which > called fwrite (built with an older version). `fwrite()` was called within > msvcrt8, while fopen was called within msvcrt causing a crash due to > the > use of different runtimes. > > Of course the FILE * probably should have been obtained from the dll > (API permitting), but there is a good potential for similar issues with > the number of libraries around and the fact that they can no longer > rely > on always being called from msvcrt like they could in the old days. > > Rob > > Pierre wrote: > > […] --- ## #32595 — Marcus Boerger — 2007-10-03T15:06:53+00:00 URL: https://externals.io/message/32540#32595 · In reply to: #32555 Hello Stanislav, right, we could however change to vs2003 or supply the dependend dlls. marcus Tuesday, October 2, 2007, 6:26:47 PM, you wrote: > > […] > IIRC there might also be some runtime issues since VS2005 links with > some shared libs which may not be installed on older systems, so we need > to verify this... > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com Best regards, Marcus --- ## #32596 — Marcus Boerger — 2007-10-03T15:07:56+00:00 URL: https://externals.io/message/32540#32596 · In reply to: #32540 Hello Pierre, dropping all vc6 build files seems like a good idea to me. If possible i'd like to have vs2002 and vs2003 work as well. And vs2007 is at the door already. marcus Tuesday, October 2, 2007, 1:34:46 PM, you wrote: > Hi, > One important thing we forgot to discuss is to drop VS6 support fin > 5.3 and finally move to VS2005. > It has a couple of side effects but it is a one time job and should > make our life easier on windows from 5.3 and up. > Comments? > Cheers, > --Pierre Best regards, Marcus --- ## #32605 — Pierre — 2007-10-03T16:48:17+00:00 URL: https://externals.io/message/32540#32605 · In reply to: #32596 > Hello Pierre, > > dropping all vc6 build files seems like a good idea to me. Only Stan (or Dmitry?) was given them some love lately but the rest of us use the jscript based build system :). So yes, we can remove them as well. > If possible i'd > like to have vs2002 and vs2003 work as well. And vs2007 is at the door > already. I already use 2k3 to compile my binaries or to develop, it works pretty well. The 2k5 brings more change and require a couple of important changes in our build (like the manifest support or what other describe in this thread). I never tried with the test versions of 2k7, however what I heard is that being ready for 2k5 will make us ready for 2k7 as well. Cheers, --Pierre --- ## #32619 — Nuno Lopes — 2007-10-03T21:34:33+00:00 URL: https://externals.io/message/32540#32619 · In reply to: #32605 > I already use 2k3 to compile my binaries or to develop, it works > pretty well. The 2k5 brings more change and require a couple of > important changes in our build (like the manifest support or what > other describe in this thread). Uhm I use VS 2005 to build PHP (vanila) for quite some time and it works pretty well. I even use some of Edin's compiled libraries. Disclaimer: I don't use those binaries in production. I only use them to debug PHP bugs on windows Nuno --- ## #32624 — Andi Gutmans — 2007-10-03T23:14:45+00:00 URL: https://externals.io/message/32540#32624 · In reply to: #32619 Although it may work for you with your applications unless all of your 3rd party libs are compiled with VS 2005 there's a fair chance that you'll have issues when data structures are passed between PHP which is compiled against one CRT lib to DLLs which were compiled with older versions (different size of structures, etc...) > -----Original Message----- > From: Nuno Lopes [mailto:nlopess@php.net] > Sent: Wednesday, October 03, 2007 2:35 PM > To: Pierre; Marcus Boerger > Cc: PHP Internals List; Rob Richards; Frank M. Kromann; Edin > Kadribasic; Dmitry Stogov > Subject: Re: [PHP-DEV] VS 2005 Support for 5.3? > > > […] > > Uhm I use VS 2005 to build PHP (vanila) for quite some time and it > works > pretty well. I even use some of Edin's compiled libraries. > Disclaimer: I don't use those binaries in production. I only use them > to > debug PHP bugs on windows > > Nuno --- ## #32625 — William A. Rowe — 2007-10-03T23:44:35+00:00 URL: https://externals.io/message/32540#32625 · In reply to: #32624 Andi Gutmans wrote: > Although it may work for you with your applications unless all of your > 3rd party libs are compiled with VS 2005 there's a fair chance that > you'll have issues when data structures are passed between PHP which is > compiled against one CRT lib to DLLs which were compiled with older > versions (different size of structures, etc...) Or more to the point, localized resources that actually exist in one CRT which aren't visible to the other CRT. Faux-posix I/O that MS implements is a really good example of this. If you are building to Apache httpd binaries /as shipped by the ASF/, you will want to ship these in VC6 for the lifespan of httpd 2.0/2.2. As the corner turns over to httpd 2.4 sometime soon, there's a good chance that VS2005 will be picked up at that point (and stay there for it's lifetime). I doubt ASF will pick up VS2008 quickly, given the number of clib issues that occur in each iteration of the libraries. One trouble is that AS still ships Perl built on VC6 runtime, Python on the VS2003 runtime, etc etc. Until everyone can land on VS2005 at the same approximate time, it's a game of cat and mouse. [We won't go into the lack of wisdom of MS shipping yet-another-clib for each of their compiler versions.] If you just clean up the .pdb's to the point that they import cleanly, you can really keep everyone happy, today and tomorrow. When you ditch the .pdb's, it's no longer possible to export .mak build files at all for use outside of the studio-world. --- ## #32627 — Andi Gutmans — 2007-10-04T03:43:55+00:00 URL: https://externals.io/message/32540#32627 · In reply to: #32625 Another option which isn't always ideal is to use FastCGI and de-couple Apache and PHP. > -----Original Message----- > From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net] > Sent: Wednesday, October 03, 2007 4:45 PM > To: Andi Gutmans > Cc: Nuno Lopes; Pierre; Marcus Boerger; PHP Internals List; Rob > Richards; Frank M. Kromann; Edin Kadribasic; Dmitry Stogov > Subject: Re: [PHP-DEV] VS 2005 Support for 5.3? > > Andi Gutmans wrote: > > […] > your > > […] > is > > […] > > Or more to the point, localized resources that actually exist in one > CRT > which aren't visible to the other CRT. Faux-posix I/O that MS > implements > is a really good example of this. > > If you are building to Apache httpd binaries /as shipped by the ASF/, > you > will want to ship these in VC6 for the lifespan of httpd 2.0/2.2. As > the > corner turns over to httpd 2.4 sometime soon, there's a good chance > that > VS2005 will be picked up at that point (and stay there for it's > lifetime). > I doubt ASF will pick up VS2008 quickly, given the number of clib > issues > that occur in each iteration of the libraries. > > One trouble is that AS still ships Perl built on VC6 runtime, Python on > the VS2003 runtime, etc etc. Until everyone can land on VS2005 at the > same approximate time, it's a game of cat and mouse. > > [We won't go into the lack of wisdom of MS shipping yet-another-clib > for each of their compiler versions.] > > If you just clean up the .pdb's to the point that they import cleanly, > you can really keep everyone happy, today and tomorrow. When you ditch > the .pdb's, it's no longer possible to export .mak build files at all > for use outside of the studio-world. --- ## #32677 — Marcus Boerger — 2007-10-06T18:13:21+00:00 URL: https://externals.io/message/32540#32677 · In reply to: #32627 Hello Andi, as far as I heard from from MS that is the much better way anyhow. marcus Thursday, October 4, 2007, 5:43:55 AM, you wrote: > Another option which isn't always ideal is to use FastCGI and de-couple Apache and PHP. > > […] Best regards, Marcus --- ## #32678 — Marcus Boerger — 2007-10-06T18:13:33+00:00 URL: https://externals.io/message/32540#32678 · In reply to: #32624 Hello Andi, most struct sizes do not matter in the windows API (becasue it takes care of that). The problem actually lies in the POSIX stuff and the modified stuff as well as the new *_r() and *_l() and what not functions that do not exist in the older functions. A thing that hurts first is the memory allocation. Basically this boils down to that you have to bind statically and may not share any malloc block to get freed in the other code. Between VC6, 2002, 2003, 2005 I had various attempts of getting cross build libs/binaries work and never had real success (and don't ask why I tried it). marcus Thursday, October 4, 2007, 1:14:45 AM, you wrote: > Although it may work for you with your applications unless all of your > 3rd party libs are compiled with VS 2005 there's a fair chance that > you'll have issues when data structures are passed between PHP which is > compiled against one CRT lib to DLLs which were compiled with older > versions (different size of structures, etc...) > > […] Best regards, Marcus --- ## #32686 — William A. Rowe — 2007-10-06T22:05:05+00:00 URL: https://externals.io/message/32540#32686 · In reply to: #32678 Marcus Boerger wrote: > Hello Andi, > > most struct sizes do not matter in the windows API (becasue it takes care > of that). The problem actually lies in the POSIX stuff and the modified > stuff as well as the new *_r() and *_l() and what not functions that do not > exist in the older functions. A thing that hurts first is the memory > allocation. Basically this boils down to that you have to bind statically > and may not share any malloc block to get freed in the other code. Between > VC6, 2002, 2003, 2005 I had various attempts of getting cross build > libs/binaries work and never had real success (and don't ask why I tried it). It works very well for modules which are well-partitioned. E.g. if the same module frees all of it's own memory (as httpd will do through APR for all apr allocations) life is happy. When you pass results that the callee is intended to free() when they are finished with the data, things will explode. For example, mod_aspdotnet always needed to be compiled in a C++.NET managed app, and was susceptible to this sort of issue running on a VC6 build of the httpd library; but it never had a problem because it did all of the httpd-oriented allocations from apr_palloc calls. What will trip us all up is the fact that we all tightly bind to openssl in particular. That's a mess all it's own if compiled to a different CRT. Bill