Originariamente Scritto da
ceccus
Salve,
NO...mi spiace contraddirti...ma PHP (e neppure ASP o ASPX)(e nessun altro interprete) NON fa chiamate dirette al S.O., ma vengono sempre "mediate" dal chiamante l' interprete stesso... la chiamata al Web Server, nell'esempio fatto, viene fatta per recuperare il SID (Security Identifier) con cui la richiesta deve essere fatta pervenire al sottosistema di autenticazione...Tant'è che il Processo con cui gira IIS (e anche Apache) hanno un proprio SID e PHP e altri interpreti "girano" all' interno di quel processo lì (o almeno ci gira la loro componente Proxy..più avanti vedremo che cosa è la componente Proxy)... quello che dici te sarebbe reale se l' interprete fosse "completamente" esterno...ma non lo è (e non può esserlo...per come funziona Windows)...se te guardi nella configurazione di IIS vedrai che fra le sue ISAPI Extension c'è anche una tale PHP.Dll oltre , naturalmente, al .exe che è l'interprete vero e proprio del PHP Quella Dll è la componente Proxy che si deve re-interfacciare con IIS proprio per i motivi che ti ho spiegato prima e , essendo una dll, condivide gli spazi di indirizzamento del chiamante (in gergo tecnico significa girare "in process")... E questo sistema di reperimento del SID , varia da ambiente ad ambiente... perchè su COM (che è un ambiente oltre che una "filosofia di programmazione") viene risolto in un modo...in ambiente .NET viene risolto in un'altro e le altre chiamate vengono comunque "mediate"...proprio perchè Windows (e anche altri S.O.) sono costruiti "a strati" e a "componenti"...non sono "monolitici".
Esistono , poi, le comunicazioni cosiddette "InterProcess", ovvero fra Processi...quindi fra .exe e .exe ... è il caso , per esempio, se un componente che sta dentro un Package COM+ che vuol richiamare un altro componente che sta in un Package diverso.... i Processi sono 2 DLLHOST.exe diversi e si devono comunque poter scambiare informazioni con , appunto , il meccansimo di "InterProcess Communication"...
Comunque, direi che la cosa si sta facendo mooolto interessante ... e al tempo stesso anche abbastanza incasinata...forse di non immediata comprensione per tutti ... personalmente sono disponibilissimo ad approfondire quello che volete...non vorrei , però, ch etale discussione risultasse di difficile comprensione per la maggioranza degli Utenti....
Ciao !!
si ... ma ... non è necessario passare dal webserver, per intenderci:
come dici tu:
fopen('cicciolina.txt')
verrebbe eseguito in questa senquenza da php:
php -> motore zend -> modulo di php isapi -> interfaccia esposta da IIS appositamente per queste cose -> iis -> sistema operativo
(più o meno)
io dico invece
php -> motore zend -> sistema operativo
la funzione fopen è gestita direttamente dal motore zend di php perché fa parte del subset di funzioni native esposte direttamente da lui, come del resto anche gli streams e altro
Ora ti pongo due domande:
- se fosse come dici tu il modulo di IIS, Apache o qualsiasi altro webserver, dovrebbe ricevere una struttura contenente i puntatori alle funzioni da usare perché al posto di usare open con dei parametri va usato il puntatore alla funzione e passare i parametri per come li vuole lui, ma non sono riuscito a trovare ciò in nessun posto del codice (open era solo per fare un'esempio)
- all'interno del codice sono usate direttamente le chiamate standard ansi (come open, close, read e write e cosi via)
Inoltre quello a cui ti riferisci tu non ha nulla a che fare con questo discorso ... nel senso che ... si, ogni sistema operativo ha un'identificatore di sessione, del processo, del thread, della libreria caricata in memoria e cosi via ... MA ... la libreria, in questo caso il motore zend o il modulo, non ha necessità di passare dal webserver perché è il SO che ha queste informazioni e non il webserver, che comunque può ottenere. Non so se mi sono spiegato :\
E' il SO che ha una bella tabellona con tutte queste informazioni è sa benissimo che il motore di php è caricato da IIS e quindi è legato a quel processo e a quella specifica sessione e quindi quello specifico utente e di conseguenza se va ad eseguire chiamate per accedere ad un file che non ha i permessi su everyone e non ha i permessi sull'utente di IIS ovviamente non lo fa accedere
Salve,
Dimenticavo...in ambiente Windows 32 bit (e a maggior ragione in quello nuovo a 64 bit) è fatto assoluto divieto a qualsivoglia applicazione di andare ad interfacciare
direttamente le risorse di sistema... ma , ogni applicazione che ne fa richiesta si deve "appoggiare" ai servizi offerti dal proprio sottosistema di riferimento ... dove per sottosistema si intende in gergo molto allargato , direttamente il S.O. , ma se la vogliamo dire in modo che più si avvicina alla realtà , sottosistema indica la parte di S.O. a cui di volta in volta l'applicazione richiede i "servigi". Sicuramente, per le applicazioni Web, il primo strato di riferimento è proprio il Server WEB.
Tutto quello che ho scritto , chiaramente, funziona in ambiente Windows...
In Linux ci saranno sicuramente delle differenze...se non altro dovute ad una differente organizzazione del suo Kernel.
Ciao !!
si ma il sotto sistema è il sistema operativo stesso per l'appunto o le funzionalità da lui offerte
---
L'unica struttura passata al momento dell'inizializzazione da parte del webserver è questa
Codice:
static sapi_module_struct isapi_sapi_module = {
"isapi", /* name */
"ISAPI", /* pretty name */
php_isapi_startup, /* startup */
php_module_shutdown_wrapper, /* shutdown */
NULL, /* activate */
NULL, /* deactivate */
sapi_isapi_ub_write, /* unbuffered write */
NULL, /* flush */
NULL, /* get uid */
NULL, /* getenv */
php_error, /* error handler */
sapi_isapi_header_handler, /* header handler */
sapi_isapi_send_headers, /* send headers handler */
NULL, /* send header handler */
sapi_isapi_read_post, /* read POST data */
sapi_isapi_read_cookies, /* read Cookies */
sapi_isapi_register_server_variables, /* register server variables */
NULL, /* Log message */
NULL, /* Get request time */
STANDARD_SAPI_MODULE_PROPERTIES
};
e viene utilizzata qua:
Codice:
sapi_startup(&isapi_sapi_module);
if (isapi_sapi_module.startup) {
isapi_sapi_module.startup(&sapi_module);
}
all'interno della DllMain (che si trova in fondo al file)
sapi_startup esegue alcune operazioni comuni a tutti o quasi i webservers e poi ritorna la palla
l'if, presente subito sotto la chiamata sapi_startup, si occupa di richiamare
php_isapi_startup
ovvero:
Codice:
static int php_isapi_startup(sapi_module_struct *sapi_module)
{
if (php_module_startup(sapi_module, &php_isapi_module, 1)==FAILURE) {
return FAILURE;
} else {
bTerminateThreadsOnError = (zend_bool) INI_INT("isapi.terminate_threads_on_error");
return SUCCESS;
}
}
che richiama php_module_startup che si occupa di inizializzare il tutto e di lavorare poi per come serve
la dll esporta questi simboli:
Codice:
HttpFilterProc
GetFilterVersion
HttpExtensionProc
GetExtensionVersion
e IIS richiama in primis:
- HttpFilterProc, usato solo per gestire correttamente l'autenticazione (almeno cosi a prima vista)
- HttpExtensionProc, usato per gestire l'esecuzione dello script richiesto
Se tu guardi i sorgenti di php, ovvero:
php-5.1.4/sapi/isapi/php5isapi.c
potrai controllare tu stesso tutto quello che ti ho postato qui
e se andiamo a fare le analisi su tutti gli altri moduli ci sarà la stessa situazione 
pensa anche semplicemente ad una cosa ... la compressione in BZip dei file viene eseguita dalla libbz2 (o qualcosa del genere) che è linkata a php e ovviamente fa uso delle sole funzioni standard e basta
e come'è cosi per php lo sarà anche per python, perl, ruby, lua, asp e aspx (anche se magari questi due sono meglio integrati)
comunque se io domani sviluppassi un loader apposito per le librerie isapi sarei in grado di caricare php, asp e aspx senza particolari problemi perché queste solo librerie isapi e le uniche informazioni, a parte alcune strutture interne per l'inizializzazione, sono quelle riguardanti la richiesta eseguita dall'utente
LinkBack URL
About LinkBacks
Rispondi Citando
...ma vedo che non è così e ne sono contento 
Segnalibri