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
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!"
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?
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....
Off the top of your head, what side effects do you alreadyanticipate, 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
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:
Off the top of your head, what side effects do you alreadyanticipate, 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
Best regards,
Marcus
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
- 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
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
- 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
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
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
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
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
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?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 windowsNuno
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.
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:
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.
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.
-----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:
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.
Best regards,
Marcus
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...)
-----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?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 windowsNuno
--
Best regards,
Marcus
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