RE: NSAPI snaps build

Hi Pierre again,

I again checked all the header files for NSAPI and was a little bit
confused, because time_t in VC6 was 32 bits and is per default 64bit in VC9.
Because additionally to struct stat, the nsapi header files use time_t and
the server compiled in VC6 uses time_t as 32bit, I was wondering why it
worked correctly.

After some looking into config.w32 and looking into the VC9 build log, I
noticed that PHP defines _USE_32BIT_TIME_T for VC9. Can you keep somewhere a
note, that this is also needed for NSAPI to work. If you change it to 64bit,
the NSAPI code will crash on 32bit platforms.

After these checks I am now sure, that the NSAPI module works correct with
VC9. I scanned the whole nsapi.h file for symbols/structs and checked for
definitions that are different in VC6 and VC9. So time_t and struct stat are
the only problematic ones, but with 32bit time_t both structs/types look
exactly equal.

Maybe I can add a test in NSAPI-SAPI that checks at compile time the correct
time_t, something like the ZTS check currently in NSAPI:

#if defined(PHP_WIN32) && versionof_msvc>=9 && !defined(_USE_32BIT_TIME_T)
# error "NSAPI needs time_t in 32bit"
#endif

How would you write down this additional check to the VC version, which
compiler variable uses this? By the way 64bit on windows is currently not
supported by Sun (if you plan to enable 64bit windows builds). I want to
include this for safety if somebody in the future wants to enable 64 bit
time_t for the windows builds etc. How does apache handle this? Is Apache
also using 32bit time_t in VC9 builds?

-----
Uwe Schindler
[email protected] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

> -----Original Message-----
> From: Uwe Schindler [mailto:[email protected]]
> Sent: Saturday, January 03, 2009 1:43 PM
> To: 'Pierre Joye'; 'Uwe Schindler'
> Cc: [email protected]
> Subject: RE: NSAPI snaps build
> 
> Hi Pierre,
> 
> > Something was wrong with the -latest link, they were referring only to
> > the TS versions for the buildconf and configure links. It is fixed
> > now. Is it where you see the NSAPI being enabled?
> 
> That was exactly my problem. I only clicked on the href to the log file
> and
> the wrong one was displayed. Now everything is OK.
> > > I will then test tomorrow, as soon as there is again a new VC9
> snapshot.
> > >
> > > FYI: The latest SJSWS 7.0U4 is still linked against VC6, but according
> > to my
> > > previous mails, it should work because VC6 and VC9 CRTs can coexist as
> > long
> > > as no resources are shared between both CRTs. NSAPI has a private API,
> > the
> > > only shared structs between VC6 and VC9 would be: "struct stat", which
> > is
> > > hopefully identical. All other resources used as parameters to
> functions
> > are
> > > simple handles or private structs. No malloc or other CRT resources
> are
> > > shared/used.
> >
> > No handle either? But if you can test (if not already done) them and
> > confirm that we can use them safely with our VC9 builds, then I will
> > simply add them back.
> 
> I tested SJSWS 7.0u4 in Windows XP locally installed. The server starts
> correctly with VC6 and VC9. A phpinfo() page is displayed without
> problems,
> the NSAPI-specific dynamic linking of the undocumented webserver API for
> the
> virtual() call is working, and the only problematic "struct stat" symbol
> sharing is working correctly. This was checked with getlastmod() PHP
> function, that uses the stat cache of the webserver (which returns the
> pointer to a struct stat from VC6).
> 
> To enable it, you must install a shared msvcr90 (using the MS installer).
> Copying somewhere is too complicated (as the webserver runs in another
> directory as PHP and so the msvcr90.dll is not found on startup/module
> load.
> 
> So no problems with NSAPI, it is compatible with the sun webserver
> (version
> 7.0 using VC6 and msvcrt). It again shows, that it is possible, that two
> CRTs can be parallel in one process as long as no incompatible resources
> are
> shared between both.
> 
> A test with a real windows server is not needed, as the VC6/VC9 problem
> does
> not have to do anything with the OS kernel.
> 
> So please enable NSAPI again for both VC6 and VC9 thread-safe and mark it
> as
> officially supported by me :)
> 
> Uwe