Parliamo di WINE: ho scoperto un'architettura alternativa (per la gioia di mjordan)

[71104]

in pratica da quel poco che conosco di WINE e che ho potuto intuire leggendo alcune cose sul loro sito nonché su uno dei progetti che essi proponevano per la Summer of Code di Google, WINE in realtà avrebbe ben diritto di essere chiamato "emulatore", contrariamente a quanto vorrebbe comunicare il suo nome che è una sigla ricorsiva per "Wine Is Not an Emulator", in quanto questo software altro non fa che tradurre le chiamate Win32 in chiamate Unix (*emula* chiamate Unix).
l'architettura alternativa che esso potrebbe invece avere, che gli toglierebbe ogni aspetto di un emulatore, e che gli permetterebbe di essere molto più veloce di com'è attualmente, e probabilmente anche assai più veloce anche dello stesso Windows (in qualsiasi situazione), consiste in un vero e proprio kernel a parte che gira alternativamente a quello di Linux comunicando direttamente con i drivers delle varie periferiche.
infatti, mentre normalmente come si è già detto WINE traduce una chiamata User Mode Win32 in una chiamata (sempre User Mode suppongo) Unix, passando quindi per il kernel principale del sistema operativo (il che costituisce una inutile stratificazione e conseguente rallentamento), per essere più veloce potrebbe semplicemente (per modo di dire ) implementare esso stesso una versione del kernel di Windows che si basi però sui drivers di Linux: in tal modo le chiamate Win32 verrebbero direttamente tradotte in gestione dei drivers, con al limite l'intermediazione di processi di sistema che conformino questa implementazione al modello microkernel, o meglio ancora all'ibrido tra microkernel e modello monolitico (monolitico dove si necessiti di particolare performance, microkernel altrove).
naturalmente questi sono argomento che ho già trattato in un altro thread che molti di voi avranno letto, ma che (come delineato dal pessimo mjordan) risultavano fortemente OT; ho pertanto deciso di riportarli sinteticamente in questo nuovo thread

[VICIUS]

Originariamente inviato da 71104

in pratica da quel poco che conosco di WINE e che ho potuto intuire leggendo alcune cose sul loro sito nonché su uno dei progetti che essi proponevano per la Summer of Code di Google, WINE in realtà avrebbe ben diritto di essere chiamato "emulatore", contrariamente a quanto vorrebbe comunicare il suo nome che è una sigla ricorsiva per "Wine Is Not an Emulator", in quanto questo software altro non fa che tradurre le chiamate Win32 in chiamate Unix

Questo quando possibile. Se una tecnologia non è disponibile viene implementata da zero. Vedi DirectX, COM e compagnia bella.

Originariamente inviato da 71104

(*emula* chiamate Unix).

E' windows che viene "emulato" quindi avresti dovuto scrivere "*emula* chiamate windows".

Originariamente inviato da 71104

l'architettura alternativa che esso potrebbe invece avere, che gli toglierebbe ogni aspetto di un emulatore, e che gli permetterebbe di essere molto più veloce di com'è attualmente, e probabilmente anche assai più veloce anche dello stesso Windows (in qualsiasi situazione), consiste in un vero e proprio kernel a parte che gira alternativamente a quello di Linux comunicando direttamente con i drivers delle varie periferiche.

Ma i due kernel separati come farebbero a gestire l'accesso contemporaneo alla memoria, i registri, interrupt, dma, ... ? Alla fine è come far girare due SO diversi su una singola macchina nello stesso istante. Con l'hardware di ora è irrealizzabile. Probabilmente con l'introduzione di Pacifica da parte di Amd e Vanderpool di Intel sara possibile fare una cosa simile ma a questo bastera usare semplicemente Windows.

ciao

[mayor]

che io sappia il vero problema di wine è che nn supporta tutte le api di windows e quindi nn tutti i programmi funzionano
quindi penso che sarebbe + utile risolvere questo problema a mio parere la velocità è secondaria! poi come si fa ad usare il kernel di windows microsoft ha donato i sorgenti???

[mayor]

che io sappia il vero problema di wine è che nn supporta tutte le api di windows e quindi nn tutti i programmi funzionano
quindi penso che sarebbe + utile risolvere questo problema a mio parere la velocità è secondaria! poi come si fa ad usare il kernel di windows? microsoft ha donato i sorgenti???

[71104]

Originariamente inviato da mayor

che io sappia il vero problema di wine è che nn supporta tutte le api di windows e quindi nn tutti i programmi funzionano
quindi penso che sarebbe + utile risolvere questo problema a mio parere la velocità è secondaria! poi come si fa ad usare il kernel di windows? microsoft ha donato i sorgenti???

be', infatti la mia non vuole essere una proposta al team di sviluppo di WINE, che come dici tu giustamente ha già altri grilli per la testa (chiamali grilli ce li voglio a implementare COM, OLE, ActiveX e tutto quello che ne deriva, come ad esempio DirectX... ); voleva piuttosto essere una temporanea disquisizione tecnica (nonché una certa critica al nome di cui si fregia il progetto! ) che ha trovato un piccolo spazio di OT in un altro thread, ma mjordan ha voluto a tutti i costi che la spostassi in un luogo in cui si fosse trovata più IT: potevo mai non accontentarlo, quel "QI=300 su 200"?
aggiungo anche che devi aver frainteso alcuni miei passi: premettendo che in realtà qualche anno fa la Microsoft ha dovuto rilasciare un bel 200 mega di documentazione del codice del suo bel kernel (sempre le solite questioni di monopolio, cause, politica, ecc., roba di cui non mi interesso molto a dir la verità), la mia ipotesi non tocca minimamente l'idea di usare il kernel di Windows per realizzare un ipotetico WOL: al contrario, se così fosse (ipotesi per assurdo, visto che applicare il kernel di Windows ai drivers di Linux secondo me è semplicemente impossibile...) il risultato sarebbe una cosa pessima e peggiore sia di WINE che di Windows
la mia idea era di realizzare un kernel ex novo.

[71104]

Originariamente inviato da VICIUS

Questo quando possibile. Se una tecnologia non è disponibile viene implementata da zero. Vedi DirectX, COM e compagnia bella.

l'asso nella manica di Microsoft, l'unico motivo percui (grazie al cielo...) i desktop sono ancora al 90% Windows

E' windows che viene "emulato" quindi avresti dovuto scrivere "*emula* chiamate windows".

be', alla fine entrambi i significati valgono, no? dipende dal punto di vista: ad una applicazione Win32 vengono emulate le chiamate Win32, nel sistema operativo Linux vengono emulate le corrispettive chiamate Unix.
ma alla fine questa è solo retorica, il concetto l'abbiamo oramai ben presente entrambi.

Ma i due kernel separati come farebbero a gestire l'accesso contemporaneo alla memoria, i registri, interrupt, dma, ... ?

esattamente come farebbero due processi diversi, no? mettila così: il kernel è di Linux, ma ci sta anche una applicazione molto grossa che si chiama WINE che ha bisogno di comunicare direttamente coi drivers; questa applicazione tra l'altro permette all'utente di avviare programmi PE.

[71104]

esattamente come farebbero due processi diversi, no? mettila così: il kernel è di Linux, ma ci sta anche una applicazione molto grossa che si chiama WINE che ha bisogno di comunicare direttamente coi drivers; questa applicazione tra l'altro permette all'utente di avviare programmi PE.

credo che questa mia ultima affermazione abbia creato qualche confusione nell'altro thread dove inizialmente si discuteva di questa cosa.
quando ho scritto "applicazione" molti avranno pensato "quindi User Mode"; in realtà il termine giusto sarebbe stato "software": se voglio implementare un "kernel alternativo" naturalmente devo lavorare non solo in User Mode, ma anche e soprattutto in Kernel Mode.

[mjordan]

Io ti do le mie motivazioni. Innanzitutto stai continuamente usando il mio nick per infangarmi con aggettivi che se permetti non accetto (usando addirittura il mio nick come tittolo di un thread, cosa da vili). Secondo tu stai proponendo un'architettura di un qualcosa che dovrebbe essere un software, tu invece vuoi metterlo nel kernel. Il fatto di mettere applicativi nel kernel non e' una cosa nuova, lo stesso linux implementa nel kernel un Web server che viene utilizzato come assistente di APACHE. Nulla ti vieta di farlo, cio' non toglie che e' diverso dal concetto iniziale he hai esposto "usare i driver scavalcando il kernel" e a questo punto l'infattibilita' mi sembra palesemente ovvia. Se per te invece ovvio non e', ti ho gia' chiesto come un software possa usare i soli driver senza passare per il kernel. Pero' ne devi dare dimostrazione pratica. Hai definito un WINE un emulatore di chiamate Unix. WINE in realta' e' solo un'implementazione delle WIN32 API e per farlo implementa le chiamate Windows in chiamate Linux (non traduce come hai detto, ecco perche' WINE NON e' un emulatore, di conseguenza hai pure sbagliato il concetto di fondo). Quindi visto che hai tanto da spalare merda su di me, a questo punto chiedo una dimostrazione pratica della fattibilita' della cosa. Basta teorie. Passiamo adesso in che modo vorresti scavalcare un kernel. Della teoria abbiamo ascoltato. Ora io cerco di darti ragione e suppongo che cio' sia possibile. Vorrei capire come fai. Grazie.

[cerbert]

Ah, per inciso 71104... quanto scritto qui:
http://www.hwupgrade.it/forum/showth...tpost&t=955307

Vale ovunque.

[DanieleC88]

71104: WINE è un'implementazione libera delle API di Windows. Basta. Non è un emulatore. Infatti con WINE (per essere precisi, con winelib) puoi compilare sorgenti scritti per Windows e renderli binari ELF nativi di Linux che si ricollegano a WINE. Insomma, non è un emulatore. Che esista poi il file /usr/lib/wine/wine.bin che fa anche da interprete, è un'altro discorso. Secondo me hai semplicemente sbagliato modo di vedere la cosa e ti sei intestardito su una discussione inutile, permettimelo.
Dai, fate pace, che non è il caso di scontrarsi per un tema del genere.

E poi: hai idea del fatto che WINE cerca di essere disponibile su vari sistemi operativi? Alcune beta vanno anche su Solaris e su particolari architetture, se non ricordo male. Fare quello che tu dici comporta la totale e indissolubile dipendenza da Linux. Creare un strato del kernel che faccia da layer di emulazione di Windows è una cosa tanto a basso livello che dovrebbe essere riscritta totalmente per funzionare anche su altri sistemi operativi. Hai presente l'assembly? Ti sei mai chiesto perché è poco portabile?

[mjordan]

Originariamente inviato da DanieleC88

71104: WINE è un'implementazione libera delle API di Windows. Basta. Non è un emulatore. Infatti con WINE (per essere precisi, con winelib) puoi compilare sorgenti scritti per Windows e renderli binari ELF nativi di Linux che si ricollegano a WINE. Insomma, non è un emulatore. Che esista poi il file /usr/lib/wine/wine.bin che fa anche da interprete, è un'altro discorso. Secondo me hai semplicemente sbagliato modo di vedere la cosa e ti sei intestardito su una discussione inutile, permettimelo.
Dai, fate pace, che non è il caso di scontrarsi per un tema del genere.

E poi: hai idea del fatto che WINE cerca di essere disponibile su vari sistemi operativi? Alcune beta vanno anche su Solaris e su particolari architetture, se non ricordo male. Fare quello che tu dici comporta la totale e indissolubile dipendenza da Linux. Creare un strato del kernel che faccia da layer di emulazione di Windows è una cosa tanto a basso livello che dovrebbe essere riscritta totalmente per funzionare anche su altri sistemi operativi. Hai presente l'assembly? Ti sei mai chiesto perché è poco portabile?

Vedo che si comincia a ragionare Senza contare il fatto che un programma per Unix che "interpreta chiamate Unix" e' a dir poco senza senso

[DanieleC88]

Originariamente inviato da mjordan

Vedo che si comincia a ragionare

Be', è normale: io conosco poco WINE, lo ammetto, ma credo che lui lo conosca anche peggio di me, quindi mi sentivo in dovere di fare chiarezza. Anche perché, purtroppo, è stata proprio l'incomprensione tra voi due alla base dello scontro. Mi dispiace che la discussione sia degenerata, perché siete entrambi degli ottimi programmatori e non siete per niente stupidi.
Come ho già detto, non mi sembra il caso di fare la guerra per così poco.

[VegetaSSJ5]

Originariamente inviato da 71104

l'unico motivo percui (grazie al cielo...) i desktop sono ancora al 90% Windows

questo vallo a dire in un'altro forum!

[71104]

Originariamente inviato da VegetaSSJ5

questo vallo a dire in un'altro forum!

ti fa schifo Windows?

[VegetaSSJ5]

Originariamente inviato da 71104

ti fa schifo Windows?

no windows non mi fa schifo, infatti lo sto utilizzando in questo momento.

cmq la mia era una battuta...

[71104]

Originariamente inviato da VegetaSSJ5

no windows non mi fa schifo, infatti lo sto utilizzando in questo momento.

cmq la mia era una battuta...

LOL, temevi un altro flame, eh? asd

[VegetaSSJ5]

Originariamente inviato da 71104

LOL, temevi un altro flame, eh? asd

esatto! ma me ne tengo alla larga!

[lupixslacky]

Originariamente inviato da DanieleC88

71104: WINE è un'implementazione libera delle API di Windows. Basta. Non è un emulatore. Infatti con WINE (per essere precisi, con winelib) puoi compilare sorgenti scritti per Windows e renderli binari ELF nativi di Linux che si ricollegano a WINE. Insomma, non è un emulatore.

Meno male che qualcuno e' arrivato a capirlo...Io mi chiedo come mai ci sono cosi' tanti utonti winzows che passano a linux perche' e 'figo.Ma perche'al posto di dire certe eresie non disinstallate linux e passate a windows che vi trovate meglio?
Per me non ha senso Wine,visto che esistono i corrispettivi software per linux.
Peccato che alcuni se non si trovano la schermata di installazione con il pulsante avati non sono contanti..
Spero che non me ne vogliate....
Ciao