Are you 100% sure you have really updated PHP and that you
don't have duplicate php4ts.dll's in your system?
And that the one you have is for PHP 4.3.2?
 
And FYI: earlier extensions might not work with current php.

Yes, I am 100% sure. Meanwhile I verified that an absolute path spec does work. It is _really_ strange: curiously I tried go_pear.php and I encounter the named problem. When executing other scripts this is not the case.
There is another strange thing about go_pear.php: it thinks I am using cgi while I am using php4apache. 
I tried go_pear with a PHP 4.4-dev and it worked (with some minor gliches) !?!?
I will investigate further. It seems it could be a pear issue.

(IMHO the reason for this trouble is that relative extension dir spec is based upon cwd whereas it should be based upon the folder php resides in).
Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.
Obviously with absolute path spec this call finds the extensions and everything is fine. Still don't know why 
e.g. a PHP4.4-dev (feb03 approx) works with relative specs?

I've no idea what PHP 4.4-dev is..last release is 4.3.2..
Reclassified as pear bug.

<Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.>

It tries to detect the current SAPI. Why do you use a pif do launch php? Then I do not know what is related with PEAR if php launched with a pif does not find some dlls. Comments?

btw, have you think about moving to real OS? like something newer than win98se? win2K?

pierre

Can't see any bug here..

Before we start flaming (_real_ OS, ...) I would like to turn your attention to the first sentence of my message.
I will happily be settling with calling it a feature request:
Please base relative path specs for extension dir on the
folder the executable resides in (and re-think the decision
of packing php-cli into another folder, btw. what's the rationale behind that?).
There are bulks of user comments and recommendations to put all the dlls into WINSYS folder which is a _very_ bad startegy when it comes to upgrading. And it is caused by 
this feature.
IMHO program extensions do by all means belong to the program and not to the data (in the sense that for PHP
scripts are data).
Second: (Just curious) I use Apache with mod_php. How do you get any relevant information on this config out of calling PHP.EXE?
Last: Using a PIF to start PHP comes from 2 points: I use the pif to customize the command window and to set the current folder so PHP starts in a defined environment.
I don't believe anything discussed around this issue has
anything to do with the _flavor_ of WIN (98SE is not the only one I use - it just happens to be the one on the machine I first loaded PHP 4.3.2 on)

fine, let's make this a feature request. 

The manual installation instructions have been updated to _don't_ advise to copy the files to the windows dir.