Compiling PHP4 under Win32

I was not able to compile and link PHP4 from the repository sources under Win32. Only the beta1 works. The main reason seams that the libzend is not included in the repository, and the development version uses new features in libzend which are not correctly set up with the public beta1 archive. In fact the repository contains MSVC projects for php4 or php4ts, which references hardcoded directories in: - "c:\include" (which files should be in that directory ? it seems that this directory is related to "php4/../include" and has something to do with the "bindlib_win32" used in the php4 projects); - "../libzend" (not in the repository, I tried to use the beta1 sources archive which puts it in the "php4/libzend" directory, while the repository version of php4 references "php4/../libzend"). More, the "FlexLexer.h" version included in the beta1 "libzend" project does not work correctly with the current version of its scanner. Where is "libzend" synchronized ? - I could compile "php4/regex" library. - I don't have the "../bindlib_win32" library or project. Where can I get it to work ? - the library "resolv.lib" is also used at link time. Is there a project to build it ? Is it related to the "bindlib_win32" library ? As what I have seen, it seems however that the new architecture of PHP4 is better structured than in PHP3, with much smaller system footprint and an easier module integration (the PHP core is much more little in PHP4 than in PHP3). Note that I have strictly no problem to compile the current PHP3 development version. I've been able for now to compile modules, but after some important changes I would not like to commit without knowning the whole consequences of the changes. So I must suspend any code addition in PHP4. I would have liked to develop another driver for Sybase, which would require much less memory for most requests. In fact the current Sybase modules has many features missing: BLOB's are incorrectly managed, select requests allocate execute completely till the end, storing all results in allocated memory, even if the PHP script only needs the first N rows, it does not handle batches with multiple queries, it cannot bind input parameters for procedure calls, it does not support procedures or batches that return multiple results-sets (a sybase_result_next() function is missing, you cannot call some system procedures like sp_help), it cannot retrieve all messages (procedures that use raiserror and print cannot return more than one line), support for select with computed aggregates on sorted rows is not well suited. With PHP4, I could add support for multiple messages from the server, which would be stored asynchrously during blocking calls, or during query execution or in sybase_result_next(). Another solution would be to support standard Sybase messages between results sets. This would imply that sybase_query() does not fetch rows, but instead stops after query execution or as soon as a sybase server message comes in. Then you can retreive messages in a loop until no more messages are pending, then you get a status saying if a result-set is pending, then you can fetch rows from that result-set until no rows are in the resultset or until you call sybase_result_next() to terminate the current result-set and continue the procedure or batch execution, or until you call sybase_result_free which goes on to terminate the query execution and ignore other pending rows or results-sets. Finally you can optionally test procedure bound output parameters and procedure call return value before calling sybase_result_free() which frees up all Sybase OpenClient ressources instead of waiting for the next query to execute, so that SQL Server won't stay in output pending sleep state for a while. There's only one exception in the design for which the Sybase module documentation is wrong: the affected rows is really accurate for select, but only after you have retrieved all rows. In that case, it will equal the selected rows count, that you can known only after you have fetched all pending rows in a results-set. In the new schema, calling the current function to get the total row count will require, as it's done now, to fetch all pending rows into dynamic memory. But if you don't need this row count, you may eliminate dynamic storage most of the time, and this can speed up very large queries. (this is because queries in procedure cannot be limited by a SET ROWCOUNT statement before the call).