Giovanni Premuda wrote:

> Pierre Joye wrote:
>
>> VC6, 7, 8 and 9 CRTs are not compatible with each other. It is not
>> recommended (read: don't do it) to mix them at runtime. For example,
>> when memory areas are allocated by a CRT and freed by another may end
>> to crashes.
>
> fbclient.dll and gds32.dll certainly do not depend on the CRT version of
> the application, they dont' even depend on the application using a C
> Runtime Library.
> What you are describing are problems that happen only with dll's that do
> share memory with some ugly hack.

Thanks Giovanni
Since I don't use M$ I did/do not understand what the 'problem' was/is.
Certainly anything that makes the client incompatible with Delphi and other
interfaces would not be acceptable and I do know that there are not currently
any restrictions on WHERE the client is used. But I do stand to be corrected -
which is why I'm asking the question.

Pierre - PLEASE explain what you think the problem is here. And bear in mind
that many of us are still running W2k based systems which will not be replaced
in the next ten years since newer versions of windows - in some cases - will
not even run on the hardware! Heck I still have customers with W98SE powered
display controllers which are now talking to new FB2 databases. You just
update the client! No doubt at some point Microsoft will screw things up so
much that we can't continue down that path - which is why many of my customers
have now accepted Linux powered servers when W2k machines need replacing!
While the SERVER is subject to the restrictions you are probably concerned
about, the client interface is specifically designed not to be? So we do not
have to worry about getting older systems to talk to new servers?

It's this backwards compatibility that has been one of the major strengths of
Firebird and transparent interoperability with Interbase was not a problem in
the past, but is now becoming a concern simply because of the differences now
being introduced. However many of the 'improvements' have not made changes to
the API directly, but to the information passed through it, which is why there
is simply not an urgent need to CHANGE anything IN php_interbase only to make
minor changes to the implementation. ALL of the bugs in php_interbase over the
last couple of years have been due to changes in the PHP code not to changes
in the Firebird/Interbase client! And that is also the reason that there has
been no pressing need to implement the switch already planned IN php_interbase
to split off php_firebird.

In my apparently flawed way of thinking, all that needs to happen in PHP5.3 is
that php_interbase is compiled to be compatible with the rest of PHP - the
same as happens with the Linux builds? The client side does not change. In the
same way that the windows builds of Firebird are released - I do not have to
concern myself with which version of a compiler that is done with! I simply
test the results on my existing systems. OK new builds of Firebird will not
run on W98 - but the client does!

Have I now explained things any better? The heated debate inside FIREBIRD is
to introduce a new client API and that WILL require a complete rewrite of the
interfaces, but at present we simply pass SQL queries to the server and get a
result set back. It's the complexity of the SQL that has expanded over time,
not how we pass the messages so no one is clamering for some missing feature
to be added to php_interbase?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php