Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a Guruman [quote=Guruman] [quote=Mak73 ha scritto]Ok, direi che il quadro è abbastanza chiaro. Ma le librerie iexemul e libnix risultano quindi sempre necessarie o solo in fase di compilazione?[/quote] ixemul e' una libreria dinamica (ixemul.library) dunque si linka dinamicamente, cosi' gli eseguibili sono piu' piccoli. [quote]Tali librerie allora non non sono ancora abbastanza complete in quanto cmq i porting di fatto non si vedono, o sbaglio? A parte cio, vista la situazione, gli sviluppatori AOS4/MOS per rendere più facili i porting da ambienti posix dovrebbero quindi potenziare le librerie citate? [/quote] Il problema e' leggermente piu' complesso. Di fatto ixemul aggiunge ad AmigaOS e a MorphOS la compatibilita' POSIX. O meglio, implementa oltre 1000 funzioni, tutte quelle che fanno la POSIX compliance, tranne UNA. Si tratta di fork() , che e' quella chiamata che genera un processo figlio (child) in un'applicazione multithread. Purtroppo la gran parte delle applicazioni grosse sfruttano il multithreading, e dunque non possono essere semplicemente ricompilate linkando ixemul. La funzione fork() non puo' essere aggiunta in maniera banale, per la struttura di AmigaOS/MorphOS, e dunque o si cambia profondamente tale struttura (perdendo non solo la compatibilita' col passato, ma anche quelli che potrebbero essere le caratteristiche distintive di AmigaOS...), oppure i programmi devono essere modificati pesantemente e in maniera non banale per ricompilarli. O si usano altre librerie come pthreads, in aggiunta. Del resto che la POSIX compliance sia piuttosto alta lo si vede dal numero di port di programmi SDL o dai GeekGadgets (inclusi ad esempio nell'SDK di MorphOS). Pero'... c'e' un pero'. Anche AmigaOS o MorphOS fossero 100% POSIX compliant, i port non arriverebbero molto piu' velocemente. Gli esempi che ho fatto sopra (SDL, GeekGadgets) esistono perche' non usano toolkit grafici particolari - SDL usa SDL appunto, e i GeekGadgets sono per lo piu' privi di GUI. Le GUI sono realizzate con GTK, o Pango, come diceva Raistlin. Dunque bisogna portare anche questi toolkit. Ma qui non basta ricompilare. Bisogna reimplementare ad una ad una ciascuna delle centinaia di chiamate alle funzioni grafiche dell'OS che compongono un toolkit grafico. Oppure come stanno facendo quelli del wrapper GTK-MUI, rimapparle sul toolkit grafico gia' esistente (MUI, apppunto). Ma e' un gran lavoro, perche' le funzioni delle librerie grafiche non sono le stesse, hanno nomi e sintassi diverse, e cosi' pure i toolkit, di solito hanno funzioni analoghe, ma mai uguali. Negli anni `90, quando c'erano molti programmatori validi, forse un simile lavoro sarebbe stato eseguito in tempi ragionevoli, oggi ci vogliono anni, e non e' detto che gli autori non perdano la passione nel frattempo. Altrimenti ci si deve accontentare dei programmi senza MUI. Programmi come Blender e Pixel sono stati portati su MOS perche' il primo usa OpenGL per la GUI e il secondo SDL. Sputnik, invece e' basato su GET+Webcore, ma l'autore ha cambiato A MANO tutte le chiamate a GTK in chiamate a MUI. Cio' e' possibile perche' un browser, per quanto complicato, usa solo un sottoinsieme di tutte le chiamate a un toolkit grafico. Ma per realizzare altri port, dovrebbe rifare il lavoro. Del resto, per portare GTK impiegherebbe molto piu' tempo, e la beta di Sputnik staremmo ancora sognandola. E oltre al toolkit grafico ci sono altre dipendenze (in genere minori e piu' facilmente risolvibili) da tenere in considerazione. Una volta sistemato GTK si dovrebbe pensare anche a quelle prima di avere Firefox e OpenOffice. Ma dubito che vedremo GTK in tempi brevi... [quote]In un altro topic, si diceva che anche Apple con il passaggio a MacOSX ha dovuto affrontare il problema della compatibilità con il vecchio software, essendo MecOSX basato appunto su kernel UNIX diversamente dalle versioni precedenti dell'OS. Come ha risolto Apple il problema di retrocompatibilità?[/quote] Come ha detto Raistlin, i programmi di MacOS 9, 8 e 7 girano all'interno di una sandbox, una scatola trasparente per la retrocompatibilita' all'interno di MacOS X. Doppio click sull'icona di uno di quei programmi, e parte la sandbox. L'utente non se ne accorge. MorphOS applica un concetto simile: sopra il kernel Quark gira la QBOX, all'interno della quale gira l'ABOX. l'ABOX e' compatibile con AmigaOS, la QBOX ha memoria protetta, resource tracking e altre cose. Il "problema" e' che al momento nella QBOX non gira nient'altro se non la ABOX. E popolare la QBOX sarebbe un grosso lavoro per un gruppo ristretto di programmatori, senza contare che prima bisogna decidere cosa farne: al momento invece l'interesse di tutti e' verso l'ABOX, perche' son tutti programmatori "amighisti"... Saluti, Andrea [/quote] formattazione A sinistra Giustificata Nessuna

24 Gennaio 2007 Postato da: Mak73 Porting su AOS4 e MOS

Prendo spunto da un'altro topic per aprire questo. Per AmigaOS, ma anche per MOS, vedo che i porting di software di vario genere, ma di una certa 'caratura' tipo Firefox, OpenOffice, per citarne due, stentano. Quali sono i motivi per cui certi progetti non partono? Ci sono ostacoli/mancanze in questi OS per cui effetuare certi porting diventa una cosa complicata? Mi chiedo questo perchè vedo che altri OS come SkyOS o BeOS, che non è che siano diffusissimi, hanno invece la loro versione di Firefox .

Commenti: 12  Aggiungi  - Leggi

Blue-troll! Post inviati: 596	Commento Guruman 27 Gennaio 2007    17:48:37
	Mak73 ha scritto Ok, direi che il quadro è abbastanza chiaro. Ma le librerie iexemul e libnix risultano quindi sempre necessarie o solo in fase di compilazione? ixemul e' una libreria dinamica (ixemul.library) dunque si linka dinamicamente, cosi' gli eseguibili sono piu' piccoli. Citazione Tali librerie allora non non sono ancora abbastanza complete in quanto cmq i porting di fatto non si vedono, o sbaglio? A parte cio, vista la situazione, gli sviluppatori AOS4/MOS per rendere più facili i porting da ambienti posix dovrebbero quindi potenziare le librerie citate? Il problema e' leggermente piu' complesso. Di fatto ixemul aggiunge ad AmigaOS e a MorphOS la compatibilita' POSIX. O meglio, implementa oltre 1000 funzioni, tutte quelle che fanno la POSIX compliance, tranne UNA. Si tratta di fork() , che e' quella chiamata che genera un processo figlio (child) in un'applicazione multithread. Purtroppo la gran parte delle applicazioni grosse sfruttano il multithreading, e dunque non possono essere semplicemente ricompilate linkando ixemul. La funzione fork() non puo' essere aggiunta in maniera banale, per la struttura di AmigaOS/MorphOS, e dunque o si cambia profondamente tale struttura (perdendo non solo la compatibilita' col passato, ma anche quelli che potrebbero essere le caratteristiche distintive di AmigaOS...), oppure i programmi devono essere modificati pesantemente e in maniera non banale per ricompilarli. O si usano altre librerie come pthreads, in aggiunta. Del resto che la POSIX compliance sia piuttosto alta lo si vede dal numero di port di programmi SDL o dai GeekGadgets (inclusi ad esempio nell'SDK di MorphOS). Pero'... c'e' un pero'. Anche AmigaOS o MorphOS fossero 100% POSIX compliant, i port non arriverebbero molto piu' velocemente. Gli esempi che ho fatto sopra (SDL, GeekGadgets) esistono perche' non usano toolkit grafici particolari - SDL usa SDL appunto, e i GeekGadgets sono per lo piu' privi di GUI. Le GUI sono realizzate con GTK, o Pango, come diceva Raistlin. Dunque bisogna portare anche questi toolkit. Ma qui non basta ricompilare. Bisogna reimplementare ad una ad una ciascuna delle centinaia di chiamate alle funzioni grafiche dell'OS che compongono un toolkit grafico. Oppure come stanno facendo quelli del wrapper GTK-MUI, rimapparle sul toolkit grafico gia' esistente (MUI, apppunto). Ma e' un gran lavoro, perche' le funzioni delle librerie grafiche non sono le stesse, hanno nomi e sintassi diverse, e cosi' pure i toolkit, di solito hanno funzioni analoghe, ma mai uguali. Negli anni `90, quando c'erano molti programmatori validi, forse un simile lavoro sarebbe stato eseguito in tempi ragionevoli, oggi ci vogliono anni, e non e' detto che gli autori non perdano la passione nel frattempo. Altrimenti ci si deve accontentare dei programmi senza MUI. Programmi come Blender e Pixel sono stati portati su MOS perche' il primo usa OpenGL per la GUI e il secondo SDL. Sputnik, invece e' basato su GET+Webcore, ma l'autore ha cambiato A MANO tutte le chiamate a GTK in chiamate a MUI. Cio' e' possibile perche' un browser, per quanto complicato, usa solo un sottoinsieme di tutte le chiamate a un toolkit grafico. Ma per realizzare altri port, dovrebbe rifare il lavoro. Del resto, per portare GTK impiegherebbe molto piu' tempo, e la beta di Sputnik staremmo ancora sognandola. E oltre al toolkit grafico ci sono altre dipendenze (in genere minori e piu' facilmente risolvibili) da tenere in considerazione. Una volta sistemato GTK si dovrebbe pensare anche a quelle prima di avere Firefox e OpenOffice. Ma dubito che vedremo GTK in tempi brevi... Citazione In un altro topic, si diceva che anche Apple con il passaggio a MacOSX ha dovuto affrontare il problema della compatibilità con il vecchio software, essendo MecOSX basato appunto su kernel UNIX diversamente dalle versioni precedenti dell'OS. Come ha risolto Apple il problema di retrocompatibilità? Come ha detto Raistlin, i programmi di MacOS 9, 8 e 7 girano all'interno di una sandbox, una scatola trasparente per la retrocompatibilita' all'interno di MacOS X. Doppio click sull'icona di uno di quei programmi, e parte la sandbox. L'utente non se ne accorge. MorphOS applica un concetto simile: sopra il kernel Quark gira la QBOX, all'interno della quale gira l'ABOX. l'ABOX e' compatibile con AmigaOS, la QBOX ha memoria protetta, resource tracking e altre cose. Il "problema" e' che al momento nella QBOX non gira nient'altro se non la ABOX. E popolare la QBOX sarebbe un grosso lavoro per un gruppo ristretto di programmatori, senza contare che prima bisogna decidere cosa farne: al momento invece l'interesse di tutti e' verso l'ABOX, perche' son tutti programmatori "amighisti"... Saluti, Andrea