| Alessandro Ghizzardi |
Portabilità - Dubbio
Ciao a tutti,
Stavo per installare il framework su una macchina linux che abbiamo qui in ufficio per fare qualche prova... Purtroppo ho avuto altri problemi e credo che dovrò lasciare a metà l'installazione e riprenderla nel week end :( Una domanda che mi è venuta in mente è:possibile installare il framework su una macchina non x86? qualcuno di voi ci ha mai provato? Grazie Alessandro |
| Marco Barzaghi |
Re: Portabilità - Dubbio
intendi MONO giusto?
HTH M.rkino |
| Alessandro Ghizzardi |
Re: Portabilità - Dubbio
No, intendo se sia possibile sviluppare un framework in tecnologia che non sia x86, cioè che non sia quella dei pentium, 486 o 386. Me lo chiedo perchè so che gli assembly hanno un'istruzione per "scavalcare" il loader del sistema operativo e che questa istruzione è scritta per x86. Quindi, se io faccio un framework per una macchina non x86, il mio assembly compilato da visual studio comunque non funzionerà, anche se fa solo una writeline("hello world"), giusto?
A meno che non abbia installato XP o 2003 server per macchine non x86 (francamente, non so neanche se esistano :)) che da quanto so ignorano questa istruzione.... Insomma, era solo pura curiosità... :) bye alex |
| Ste Dev |
Re: Portabilità - Dubbio
Scusa la mia ignoranza...quando esco dalla piattaforma Windows mi perdo...
A cosa serve Mono ? |
| Marco Barzaghi |
Re: Portabilità - Dubbio
beh nel caso di Windows qndo isnalli i framework il loader viene sostituito... prima un exe passa dal nuovo loader kapisce se è managed o unmaneged e il resto è qlloo ke accade (credo ke il raffaele qst te lo può spiegare meglio). il framework installato su 386 e 486... qsto non me lo sono mai kiesto, se non sbaglio l requisito è w2k... non so se su nt4 va... qndi se hai un 386/486 con una w2k dovrebbe andare ;p
x qnto riguarda mono funziona kome qndo lanci una calsse java... esempio se compilo il mio pippo.exe e poi lo porto kosì kom'è semza rikompilarlo su una linux kon mono faccio "mono pippo.exe"... cioè devo espicitare ki è il loader dell'applicazione. ciao M.rkirno |
| Alessandro Ghizzardi |
Re: Portabilità - Dubbio
Beh il loader che io sappia _non_ viene sostituito... semplicemente viene creato un rimando ad un metodo di una libreria presente in system (MSCor qualcosa.dll). Il loader va a vedere questa libreria e gli passa il comando, e questa si occupa di caricare il CLR e dargli in pasto l'assembly. Se poi non è così illuminatemi :)
Per quanto riguarda mono, allora si non avevo pensato che richiamando tutto come una "normale" virtual machine il problema dell'istruzione x86 viene scavalcato! ma se io installo NT4 su macchina non x86?? su NT4 il framework funziona, ma cosa succede? si incarta?? o da errore? bye alex |
| Raffaele Rialdi |
Re: Portabilità - Dubbio
Non mi risulta che esista una versione del framework (ms ufficiale) per cpu diverse da Intel (compact framework a parte). Qualcuno ha visto il download del framework per Itanium (IA64)?
Quando installi un prodotto su NT4 (cpu alfa), devi averlo in versione alfa. Idem vale per il framework .net. Una volta che hai il framework sul pc, il codice .net è sempre e solo IL e quindi non ha alcuna necessità di essere ricompilato per quella cpu. Il 'trucco' non è la classica virtual machine ma il jit (just in time compiler) che esegue una post-compilazione. Il codice è già compilato in IL ma il jit esegue una conversione delle istruzioni IL in quelle del processore che è installato sul pc (386, P3, P4, ...). Questa conversione finale è (parole di Jeffrey Richter) quasi una sostituzione in una look-up table e quindi molto rapida. Dai sorgenti di rotor puoi verificare che è veramente così. Questa soluzione ha vantaggi/svantaggi: * Il codice è sempre compilato nella migliore versione del processore su cui gira (il codice c++ di solito è compilato per 80386 o 80486 al massimo e quindi molto meno performante). * Il codice diventa portabile al massimo, tanto da poter girare su cpu diverse perchè il lavoraccio se lo sbriga il jit. * Il primo avvio del codice è più oneroso perchè richiede la post-compilazione del jit. Problema ovviabile con il tool ngen ma soluzione sconsigliata. Io ho provato rotor per FreeBSD (che gira sempre su macchine x86) e fatto girare lo stesso codice binario sia su Windows che su Linux. Sapevo che funzionava ma vederlo con i propri occhi è tutta un'altra cosa ;-) Raffaele |
| Marco Barzaghi |
Re: Portabilità - Dubbio
ciao raffa, confidavamo in un tuo intervento :D
>Sapevo che funzionava ma vederlo con i propri occhi è tutta un'altra cosa ;-) si confermo... io provato compilare da VS e portato su una RedHat :D M.rkino :D |
| Alessandro Ghizzardi |
Re: Portabilità - Dubbio
Grazie, ero al corrente di tutto questo.
Il dubbio che ho è perchè (sempre parole di richter) nell'header di un assembly viene messa un'istruzione x86 (non mi ricordo, qualcosa tipo JMP _exeMain o simile) che chiama il relativo metodo nella MScorqualcosa (MScorEE mi pare ma non sono sicuro.. la prossima volta cerco sul libro :)) e da li parte il tutto... ed io mi chiedevo perchè un'istruzione specifica per x86. Vero, come dici te ora come ora non esistono versioni del framework per CPU alpha o itanium (anche se questo mi preoccupa meno, perchè tanto su itanium si installeranno solo windows XP e windows 2003 server, che hanno effettivamente il loader modificato e saltano questa istruzione x86), ma se un giorno o l'altro usciranno? un eseguibile scritto ora non funzionerà? o non ho capito nulla io? ciao alessandro |
| Lawrence Oluyede |
Re: Portabilità - Dubbio
> Vero, come dici te ora come ora non esistono versioni del framework per CPU alpha o itanium (anche se questo
> mi preoccupa meno, perchè tanto su itanium si installeranno solo windows XP e windows 2003 server, che hanno > effettivamente il loader modificato e saltano questa istruzione x86), ma se un giorno o l'altro usciranno? un > eseguibile scritto ora non funzionerà? o non ho capito nulla io? Alla conferenza su Rotor Peter Drayton disse che erano abbastanza indietro sullo sviluppo di IA64 ma erano decisamente a buon punto su Athlon64 :) Ad ogni modo il giorno in cui avremo un'architettura a 64 bit (come quella di A64) e un framework a 64 bit gli exe a 32 bit in teoria dovrebbero funzionare sull'x86-64. Al contrario sull'IA64, che ha un'architettura decisamente differente, il codice per x86 sarà eseguito in emulazione (Intel stessa dice che avrà le prestazioni di un PII) e quindi fatico ad immaginare l'esecuzione di un PE "sporcato" da .NET cosi com'è ora sul mio buon vecchio PC x86. |
| Raffaele Rialdi |
Re: Portabilità - Dubbio
Tu intendi una versione del framework per windows ma su cpu != x86?
In quel caso non credo che MS farebbe tanta fatica a cambiare il loader anche a Win2k. Si tratta solo di controllare se .text contiene il jmp e se idata ha un riferimento a mscoree.dll (si, ho riletto il capitolo). Anche le win32 sono anche loro un layer (csrss.exe) che poi chiamano le loro sorelline che iniziano per Zw. Il Loader di xp e w2k3 usa LoadLibrary e Create Process. Queste poi chiamano le rispettive ZwLoadLibrary e ZwCreateProcess. Quindi non sarebbe poi un disastro patchare il loader per questo proposito anche se ritengo che sugli OS con versione < XP, MS non migrerà più nulla. Non ti convince? Raffaele |
| Alessandro Ghizzardi |
Re: Portabilità - Dubbio
> quindi fatico ad immaginare l'esecuzione di un PE "sporcato" da .NET cosi com'è ora sul mio > buon vecchio PC x86. Umm, perchè? credo che semplicemente i sistemi operativi a 64 bit (almeno quelli microsoft) saranno scritti apposta per mantenere questa compatibilità: se l'IL è comune, non vedo particolari problemi a far compilare al JIT per 64 bit invece che per 32 (oddio, qualche problema si, ma non insormontabile credo).... |
| Lawrence Oluyede |
Re: Portabilità - Dubbio
> Umm, perchè? credo che semplicemente i sistemi operativi a 64 bit (almeno quelli microsoft) saranno scritti apposta per > mantenere questa compatibilità: Si ma credo che il problema sia HW non tanto SW >se l'IL è comune, non vedo particolari problemi a far compilare al JIT per 64 bit invece > che per 32 (oddio, qualche problema si, ma non insormontabile credo).... Boh stiamo a vedere :) |
| Marco Barzaghi |
Re: Portabilità - Dubbio
ciao ste,
è un implementazione open source del framework per SO anche non windows. http://www.go-mono.com ciao M.rkino |
| Ste Dev |
Re: Portabilità - Dubbio
on 19. Jun 2003 14:19 Marco Barzaghi wrote:
> ciao ste, > è un implementazione open source del framework per SO anche non windows. > http://www.go-mono.com > > ciao M.rkino Vale per Linux ? Ovviamente rimangono escluse le WindowsForm ? |
| Lawrence Oluyede |
Re: Portabilità - Dubbio
> Vale per Linux ?
E' stata pensata inzialmente per Linux ma gira anche su Windows su x86 e ne esiste anche un'implementazion per PowerPC > Ovviamente rimangono escluse le WindowsForm ? Grazie ad un hack (si tratta di emulazione tramite Wine) anche le WinForms girano abbastanza bene |
| Ste Dev |
Re: Portabilità - Dubbio
Se volessi provare l'ebrezza di vedere girare un'applicazione mediante questo Mono, cosa devo fare ? Tieni conto che parto da zero con un PC con a bordo Windows XP e Visual Studio.NET.
Se hai tempo indicami tutti gli step che devo seguire, di sta cosa non so nulla !!!!!! Grazie 1000 PS hai visto che ho macinato una tip ???? |
| Lawrence Oluyede |
Re: Portabilità - Dubbio
on 19. Jun 2003 15:01 Ste Dev wrote:
> Se volessi provare l'ebrezza di vedere girare un'applicazione mediante questo Mono, cosa devo fare ? Sinceramente su Windows non saprei :) Non ho mai provato ma credo che ti basti provare ad eseguire un exe con il suo loader... Su linux beh a me bastava fare "apt-get install mono" ed ero già pronto :P >Tieni > conto che parto da zero con un PC con a bordo Windows XP e Visual Studio.NET. > Se hai tempo indicami tutti gli step che devo seguire, di sta cosa non so nulla !!!!!! Beh... o installi Linux per provare o installi quella Win e fai qualche prova... non saprei :( > PS hai visto che ho macinato una tip ???? Ah ah ormai non le conto nemmeno più :) |
| Alessandro Ghizzardi |
Re: Portabilità - Dubbio
> Non ti convince? Si mi convince (anche io sono andato a rileggermi il capitolo :)) e sono daccordo sul fatto che MS non patchera nulla per NT4... quindi effettivamente il problema non si pone... Il mio era più un dubbio etico che altro, sul perchè mettere un'istruzione x86 invece di patchare direttamente il loader... ma probabilmente hanno avuto dei problemi di performance/stabilità nelle prove ed hanno dovuto risolvere in questo modo :) Grazie per gli spunti cmq, ora metto in piedi un frarmework per NT4 alpha e dopo vado a fare il whiner in MS :p ciao Alessandro |