You mixed up .dlls from sever releases. Not a bug.

Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0


- Davey

I too also experienced this error in the php/php-cli dists.  I also must note that the internal socket support throws a starnge error in the newer snaps as well.

~ Andrew

Zeev, you touched that stuff on 18th of August..

edink hit it on the head - it's not a bug, you're mixing binaries from different builds.
In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist.  If there are missing symbols - the build would fail.

The only situation where you can get missing symbols is if you mix different successfully-built binaries.

Then there is something else at play here.

I keep my PHP installs in seperate folders like this:

c:\php4\
c:\php5\

I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: 

"This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem."

I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this)

- Davey

OK, it seems that it finds my ZDE php4ts.dll in c:\program files\zend\bin is the one its finding (note that it didn't find the one in c:\program files\zend\bin)

It errors with: 

"The procedure entry point zend_uv could not be located in the dynamic link library php4ts.dll" - presumably because that php4ts.dll is from 4.2.2 (IIRC).

If I then restore my c:\php4\php4ts.dll is seems to find that one instead because the error goes back to the original one reported. 

Could this be %PATH% related? Or is PHP5 looking for php4ts.dll differently to PHP4? Note that PHP4 *also* finds the ZDE one (and errors with the same error) if c:\php4\php4ts.dll is not there.

Something is going on here.

- Davey

Note that this *only* happens with the CLI for me. So is there some difference in how this binary detects php4ts.dll to how the cgi one does?

- Davey

Worked this one out...

The reason is that the cgi binary has the php4ts.dll for PHP5 in its PWD, and when it requests the dll, thats where windows looks first and tells it that its there.
The CLI binary does NOT have a php4ts.dll for PHP5 in its PWD, so windows traverses the %PATH%, where it finds the PHP4 php4ts.dll and tells the binary thats where it was found.

Solution: Put a copy of php4ts.dll in c:\php5\cli if you need to run PHP5 and PHP4 simultaneously (testing), otherwise put c:\php5 in your path(note that when running the PHP4 binaries, they will find the PHP5 php4ts.dll, the problem is reversed).

- Davey