Re: Re: [PHP3] Configuring php with apache on win98

> Did I read this right, THERE IS NO WAY to run PHP as a module for Apache > on the windows platform? Even if I compile the binaries myself? I believe that is correct... I'm really not an expert, and there's probably some hacker somewhere who will contradict me... Or is this tied to that gnarly "Threads" thing that Windows sucks at, and so just can't be fixed until somebody fixes that "Threads" thing for Apache like they did for IIS? Also, take heart: One of the goals of the PHP4 re-write was to abstract the various SAPI functions (the ones that let PHP be a Module of Apache/IIS/AOL/NES/fhttpd/Omin/Xitami/whatever) so that instead of having to write a whole new code-base for each server, only a page or two of code needs to be customized to fit in to any given server. So, in theory, the PHP team should be able to crank out Module-ness for each Web-Server in a relatively short time. > I'd like to get the Apache/PHP combo as close to the same as I have on my unix > box so I don't have to change too much code between the two. If I have to run it > as CGI only on windows, does that mean I have to call the path to the cgi > EVERYTIME I bust in and out of php? No, no, no. The CGI is called by Apache on each *page* hit, automatically. Well, not *automatically*, but you set it in httpd.conf and forget it. You don't have to change your source code at all. (Well, okay, there are a few technicalities/exceptions). Nobody on the PHP team would accept having to drastically alter your code just to move from Un*x to Windows or Module/CGI compiles. That's just not acceptable. Only Microsoft would try to pull a stunt like that and expect people to work with it. :-) In other words: In the Module setup, Apache has PHP "builtin" and calls a "function" that *is* PHP, which loads/parses/executes your script. In the CGI setup, Apache fires up php as a stand-alone program, which loads/parses/exectues your script. In either case, PHP does its thing, and returns your HTML to Apache which just spits it back at the browser. It's really just a question of how PHP gets started by Apache, not what PHP does with your source once it's going. And *certainly* not what your source code has to do to work. :-) The exceptions to this "100% compatibility" are: o The virtual() function works only on Module, not CGI. You can usually do anything you woulda done with virutal() by using exec() instead. o You cannot issue the HTTP Authentication headers *from* *PHP* in CGI mode. You'll have to authenticate using some external solution, such as htpasswd files or mod_auth_mysql or mod_auth_pgsql or mod_auth_etc. You also don't get the $HTTP_AUTH_USER or whatever that variable is. Actually, I think you get it, but it's always blank, and you can't use that variable name for GET/POST/COOKIE cuz PHP over-writes it on every page. (The over-writing part is true in any case.) o Some performance loss: This is generally over-blown by CGI-bashers, since a decent machine with enough RAM to hold httpd binaries and PHP binary and whatever other processes are constantly running means that the PHP binary will be in the cache. Thus the dreaded "penalty" of running a new PHP for each page hit is drastically reduced. Of course, if you're short on RAM or have a lot of junk running and chewing your RAM up, well, it's going to be noticably slower. That's not to say the Module isn't inherently faster than CGI, just that it's not usually the huge difference it is often made out to be. o I think there's one other exception, and I can never remember all four at once. Whatever it is, it's never been important enough to bug me :-) YMMV. So unless you're using one of the exceptions above, you'll never notice the difference. Well, Windows is gonna crash a lot, but you knew that. :-) PHP3 doesn't make Windows any less stable than it already is though. I'm not sure we can make the same statement about PHP4. Yet.