Windows e Mac OS X sempre più vicini

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/apple/17729.html

Boot Camp, ambienti di virtualizzazione di terze parti e addirittura un progetto opensource per convertire eseguibili Windows in binari per OS X. I due sistemi operativi non sono mai stati così vicini

Click sul link per visualizzare la notizia.

[Pinko7]

dio li fa e poi li accoppia..

[Aryan]

Finalmente si muove qualcosa nell'ambito della virtualizzazione HW e non più quella del SO come succede con vmware...

[FinDuZ]

Spiragli interessanti .. tutti a vantaggio del MAC


L' approccio di Alky di tradurre il codice mi sembra che difficilmente possa arrivare a coprire applicazioni complesse ... che sono poi quelle che maggiormente servono.

[Automator]

lo sto usando da un po', e devo dire che va veramente molto bene.

peccato solo non sia supportata l'accelerazione video per il 3d.

[gropiuz73]

questo Alky per linux potrebbe risultare interessante... in teoria perlomeno... mi sembra improbabile ottenere in questo modo del codice molto efficiente... chi vivrà vedrà!

[Kayne]

a prescindere dai che risultati riusciranno ad ottenere, Alky è veramente un progetto interessante

[stefanotv]

x Aryan

sempre di virtualizzazione tramite un layer software si tratta,
vmware esx ti permette da tempo di assegnare una determinata cpu, un quantitativo di ram, disco fisico, storage esterni, controller scsi ed ethernet ad un determinato s.o.....
il problema era che fin'ora l'hardware per fare queste virtualizzazioni era solo quello dell'ambito server, ora che anche una comune workstation puo' avere piu' core, piu' ethernet... le cose stanno cambiando.

[jappilas]

bello, sembra il ritorno di Odin per OS/2

Originariamente inviato da FinDuZ

L' approccio di Alky di tradurre il codice mi sembra che difficilmente possa arrivare a coprire applicazioni complesse ... che sono poi quelle che maggiormente servono.

non capisco cosa intendi con "applicazioni complesse"...
il fatto che un' applicazione, come magari quelle professionali, sia più "corposa" di un' altra, non la rende necessariamente più "complessa", da un punto di vista "binario" (certo, la complessità sarà inerentemente maggiore per chi la progetta e sviluppa e per chi la usa)
ma per il sistema operativo una volta compilata apparirà sempre come un BLOB (binary large object) con un entry point, dei simboli importati, delle chiamate a funzioni di libreria eccetera: un' applicazione più consistente avrà più che altro dipendenze più numerose in termini di DLL di appoggio richieste per girare quindi il processo di conversione sarà "più lungo" piuttosto che che "più difficile"
per cui la probabilità di successo nella conversione non dovrebbe dipendere dalla "dimensione" dei dati sorgente, fintantoche il programma di traduzione tra formati binari supporta tutte le caratteristiche dei formati sorgente e destinazione ed è in grado di rimapparle, e fintantoche sono disponibili degli omologhi funzionali per le dipendenze che un' applicazione si può aspettare soddisfatte nell' OS per cui è stata compilata
quindi il problema è, una volta accertato che il convertitore, di suo, funzioni in modo generale e stabile, rendere sufficeintemente completa, funzionale e stabile, la "libAlky"... che poi è un problema analogo a quello che si è affrontato con l' environment di Wine in effetti

[Kappaloris]

Qual'è la differenza tra is SW di virtualizzazione e quelli di emulazione?

vmware è di emulazione, giusto?

[magilvia]

Jappilas è vero che non dipende strettamente dalle dimensioni del binario ma devi ammettere che più è lungo il codice più è probabile trovare una chiamata ad una libreria che ancora non è disponibile oppure trovare l'utilizzo di una feature non documentata e quindi non traducibile.
Inoltre c'è un aspetto che avete trascurato: molti binari sono criptati, palliativo per proteggerli dalla pirateria e quindi non saranno in alcun modo traducibili. e consideriamo che questa è una tendenza in aumento.
Insomma secondo me FinDuZ ci ha azzeccato. La virtualizzazione è una strada molto più promettente.

[Rubberick]

bene dai... dove nn arrivano gli accordi ci pensano utenti e progetti interessanti...

[karplus]

I mac costano di più solitamente, se uno li compra per poi farci girare win ha buttato i soldi imho... se bisogna usare win per tutti i programmi specifici e mac per posta/internet ecc tanto vale installare win e linux su un pc normale che costa molto meno

[NoLimit]

Non vorrei dire una cazzate, ma è simile a Wine; cioè si usa il sistema Mac con librerie Windows per poter eseguire il software. A questo punto non è virtualizzazione, ma semplicemente un substrato software che si interfaccia con l'applicazione e traduce per il SO ospitante.
WINE!

[*sasha ITALIA*]

ottima cosa per colroo che devono usare app windows che sotto mac non arriverano probabilmente mai...

senza contare che in poco tempo potremmo vedere Autocad.dmg, WMP.dmg (questo serve eccome sotto mac) ecc ecc

[jappilas]

Originariamente inviato da magilvia

è vero che non dipende strettamente dalle dimensioni del binario ma devi ammettere che più è lungo il codice più è probabile trovare una chiamata ad una libreria che ancora non è disponibile oppure trovare l'utilizzo di una feature non documentata e quindi non traducibile.

ma allora mi dai ragione: il problema non è nel traduttore in sè quanto nell' assicurare un' adeguata "copertura" delle funzioni di libreria, e nell' assicurare che quelle implementate, almeno funzionino in modo corretto
che come problema, non è in rapporto causale, con caratteristiche dell' applicazione win32 da supportare, ma più con la documentazione delle funzioni da reimplementare e dalla bravura di chi ci lavora su

Inoltre c'è un aspetto che avete trascurato: molti binari sono criptati, palliativo per proteggerli dalla pirateria e quindi non saranno in alcun modo traducibili. e consideriamo che questa è una tendenza in aumento.

ci sono anche molti binari compattati con UPX per risparmiare il 50% dello spazio su disco... però il processore non può eseguire codice nè criptato nè compresso , quindi saranno sempre composti da una sezione binaria in corrispondenza dell' entry point che descripta o scompatta il resto e mappa in memoria il codice binario effettivamente eseguito
tracciare l' esecuzione e le chiamate di funzioni sarà più difficile, ma non del tutto impossibile, esistono tecniche per farlo (che se non ricordo male partono eseguendo passo a passo il programma target in una sandbox )
inoltre se fosse criptato al punto da non rendere disponibili i simboli importati, dubito che già l' OS potrebbe caricarlo

Insomma secondo me FinDuZ ci ha azzeccato. La virtualizzazione è una strada molto più promettente.

imho, resta una tecnica complementare, non sostitutiva

Originariamente inviato da NoLimit

Non vorrei dire una cazzate, ma è simile a Wine; cioè si usa il sistema Mac con librerie Windows per poter eseguire il software. A questo punto non è virtualizzazione, ma semplicemente un substrato software che si interfaccia con l'applicazione e traduce per il SO ospitante.
WINE!

non proprio
WINE reimplementa le librerie fondamentali dello userland Win32, come PE DLL, e un proprio loader che carica gli eseguibili PE come dati grezzi, li alloca e li mette in esecuzione come fosse una sorta di "managed code"
(infatti per avviare un prog Win sotto Linux con Wine mi pare si debba digitare wine <nomeProgramma.exe> in una shell e resti in memoria un programma che faccia da "application server" per le chiamate di sistema Win32)
questo, oltre a reimplementare la userland tradurrebbe eseguibili e librerie nel formato binario nativo di MacOSX, che è Mach-O

[Aryan]

Originariamente inviato da stefanotv

x Aryan

sempre di virtualizzazione tramite un layer software si tratta,
vmware esx ti permette da tempo di assegnare una determinata cpu, un quantitativo di ram, disco fisico, storage esterni, controller scsi ed ethernet ad un determinato s.o.....
il problema era che fin'ora l'hardware per fare queste virtualizzazioni era solo quello dell'ambito server, ora che anche una comune workstation puo' avere piu' core, piu' ethernet... le cose stanno cambiando.

Anche con VMWare workstation posso fare quello che dici, solo che quest'ultimo ha bisogno di un SO che ci giri sotto, mentre ESX ne ha uno proprietario che succhia meno risorse e cmq è più potente rispetto al workstation.

Per virtualizzazioni HW(quella che hanno i Pentium D e AMD AM2) intendo quella in cui diversi SO possono accedere a basso livello all'hardware...

[cagnaluia]

Originariamente inviato da karplus

I mac costano di più solitamente, se uno li compra per poi farci girare win ha buttato i soldi imho...

esattamente imho...

tanti li comprano perchè piacciono esteticamente... (a livello portatili).

e possono permettersi di pagare quel dippiù.. per un pò di esclusività, che diciamocela.. ancora apple ha!

[magilvia]

ma allora mi dai ragione: il problema non è nel traduttore in sè quanto nell' assicurare un' adeguata "copertura" delle funzioni di libreria, e nell' assicurare che quelle implementate, almeno funzionino in modo corretto

No, è che la vedi in modo in diverso. Tu parti dal presupposto che sia possibile "terminare il lavoro" con una lista completa di fatures. Infatti scrivi:

fintantoche il programma di traduzione tra formati binari supporta tutte le caratteristiche dei formati sorgente e destinazione

Io invece penso che si concentreranno prima di tutto sulle funzioni principali, poi procederanno applicazione per applicazione a verificare dove sono i problemi e a correggerli. Ma ad ogni nuova applicazione scopriranno che ci sono problemi e cose nuove da implementare, e più sono grandi le applicazioni più problemi trovarenno.
E cosa succede se dopo aver reso compatibile un'applicazione uscirà la versione nuova ? Tutto daccapo :P
Insomma un lavoro senza fine.

ci sono anche molti binari compattati con UPX per risparmiare il 50% dello spazio su disco... però il processore non può eseguire codice nè criptato nè compresso , quindi saranno sempre composti da una sezione binaria in corrispondenza dell' entry point che descripta o scompatta il resto e mappa in memoria il codice binario effettivamente eseguito
tracciare l' esecuzione e le chiamate di funzioni sarà più difficile, ma non del tutto impossibile, esistono tecniche per farlo
inoltre se fosse criptato al punto da non rendere disponibili i simboli importati, dubito che già l' OS potrebbe caricarlo

Sono daccordo ma le tecniche di cui parli sconfinano nel reverse engineering. Ciò significa che a meno di permessi speciali rilasciati dalle case produttrici, per legge non potranno nemmeno provarci.

[71104]

Originariamente inviato da magilvia

Sono daccordo ma le tecniche di cui parli sconfinano nel reverse engineering. Ciò significa che a meno di permessi speciali rilasciati dalle case produttrici, per legge non potranno nemmeno provarci.

a programa avviato tu avrai una situazione semplicissima, ovvero una serie di moduli PE mappati in memoria virtuale ai loro base addresses o ad altri multipli di 0x10000 nel caso i loro base addresses predefiniti siano occupati; un traduttore ipotetico deve soltanto chiamare OpenProcess e ReadProcessMemory per leggere il particolare modulo PE situato al base address predefinito dell'eseguibile da cui è stato creato il processo; dopodiché deve adattare i dati di importazione alla sua "LibAlky" e convertirlo di formato. nessuna di queste operazioni è illegale, sono tutte operazioni ben documentate grazie a Matt Pietrek che spiega molte cose in merito; il reverse è ben altra cosa, e anche se fosse un programma non è in grado di effettuare dirty room reverse (che è l'unica sua forma illegale). il reverse engineering illegale non può essere effettuato da una macchina, ma necessariamente da un essere umano (almeno finchè sofisticati software di AI non saranno adattati allo scopo )