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.

dio li fa e poi li accoppia..

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

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.

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.

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

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

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.

bello, sembra il ritorno di Odin per OS/2 (http://odin.netlabs.org/) :)
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"... :mbe:
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

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

vmware è di emulazione, giusto?

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.

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

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

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!

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

è 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 :D
Insomma secondo me FinDuZ ci ha azzeccato. La virtualizzazione è una strada molto più promettente.
imho, resta una tecnica complementare, non sostitutiva ;)
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

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.
:confused:
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... ;)

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!

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.

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 :p)

Secondo me, la mela dovrebbe rendere disponibile Mac OS X per funzionare sui "normali" computer per diffonderne l'uso. Difficoltà tecniche non dovrebbero più essercene. Secondo me con questa manovra stanno solo diffondendo ulteriormente il SO microzozz. Forse sbaglio... Voi cosa ne pensate?
:)

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. queste difficoltà non pregiudicano la riuscita del progetto, altrimenti Wine e ReactOS non esisterebbero. sono difficoltà che si superano con un team sufficientemente numeroso, e non sono illimitate

Secondo me, la mela dovrebbe rendere disponibile Mac OS X per funzionare sui "normali" computer per diffonderne l'uso. Difficoltà tecniche non dovrebbero più essercene. Secondo me con questa manovra stanno solo diffondendo ulteriormente il SO microzozz. Forse sbaglio... Voi cosa ne pensate?
:) MacOSX su Intel esiste già :Prrr:

a programa avviato tu avrai una situazione semplicissima
Direi che dipende dalla complessità della protezione. Non sono un esperto cracker ma direi che le protezioni odierne non si limitano a scompattare tutto il programma in memoria all'avvio, ma scompattano pezzi di programma solo se e quando servono. Inoltre alcune monitorizzano anche il pc per controllare che non ci sia nessun programma "spione". Una situzione non semplice come sembrerebbe.

queste difficoltà non pregiudicano la riuscita del progetto, altrimenti Wine e ReactOS non esisterebbero.
E' vero ma Wine non si scontrerà mai con il problema dei binari criptati perchè deve limitarsi a rendere disponibile l'API giusta quando serve. Qui invece parliamo di tradurre l'intero codice a programma fermo o appena avviato. Cosa difficile se non puoi neanche leggerlo inmodo completo :P

Originariamente inviato da: sleeping
Secondo me, la mela dovrebbe rendere disponibile Mac OS X per funzionare sui "normali" computer per diffonderne l'uso. Difficoltà tecniche non dovrebbero più essercene. Secondo me con questa manovra stanno solo diffondendo ulteriormente il SO microzozz. Forse sbaglio... Voi cosa ne pensate?

avranno fatto i loro calcoli e visto che non gli conveniva. Se non sbaglio tempo fa ci hanno pure provato, prima che ritornasse steve jobs.

se riesco a giocarci tutto bene altrimenti sarà un bluff (non so come si scrive cavoli).

E' vero ma Wine non si scontrerà mai con il problema dei binari criptati perchè deve limitarsi a rendere disponibile l'API giusta quando serve. Qui invece parliamo di tradurre l'intero codice a programma fermo o appena avviato. Cosa difficile se non puoi neanche leggerlo inmodo completo :P il punto è precisamente che non stiamo parlando di questo... stiamo parlando di una conversione di formato, qualunque sia il contenuto della sezione .text

se Alky ricompilasse il codice non servirebbe LibAlky


Direi che dipende dalla complessità della protezione. Non sono un esperto cracker ma direi che le protezioni odierne non si limitano a scompattare tutto il programma in memoria all'avvio, ma scompattano pezzi di programma solo se e quando servono. Inoltre alcune monitorizzano anche il pc per controllare che non ci sia nessun programma "spione". Una situzione non semplice come sembrerebbe. nessuno ti vieta di usare OpenProcess e ReadProcessMemory, e se le usi il processo target non ha nessun modo di accorgersene; l'unica sarebbe installare un driver per patchare al volo kernel32.dll ed intercettare le chiamate a quelle due funzioni a livello globale: a parte che non giocherei mai a un gioco nel cui team c'è stato chi ha avuto la bella idea di mettere in atto una boiata simile, per OpenProcess dire che sarebbe una cosa ridicola è un eufemismo, per quell'altra Alky sarebbe costretto alla resa ma siccome nessun cracker debugga in usermode quel programma non sarebbe fatto per impedire il cracking, ma specificamente per impedire la traduzione da parte di Alky e conseguenti vantaggi commerciali (diffusione su Mac)

Io preferisco senza dubbio la virtualizzazione al dual boot, utilizzare i programmi win senza abbandonare mac os è senza dubbio una figata... però mi sa che per giocare non si potrà cmq fare a meno del dual boot... poi va be se uno ha un macbook o un mini fa schifo per giocare anche con win e quindi il dual boot neanche se lo fa...

scusate...sapete se esiste già un software per la virtualizzazione fisica tra linux e windows?
nel mio core duo è attivabile un'opzione da bios ma servirebbe un programma di boot che permetta di far girare contemporaneamente i due sistemi e di switchare da uno all'altro in real time. grazie ciao.

Sleeping ha scritto:

Secondo me, la mela dovrebbe rendere disponibile Mac OS X per funzionare sui "normali" computer per diffonderne l'uso. Difficoltà tecniche non dovrebbero più essercene. Secondo me con questa manovra stanno solo diffondendo ulteriormente il SO microzozz. Forse sbaglio... Voi cosa ne pensate?


Possibile che sotto ogni news apple arrivi questo commento?
La Apple fa computer! Dai quali trae il maggior guadagno, dovrebbe vendere 10 volte tanto MacOSX per fare quello che dici tu. Inoltre MacOSX è ottimizzato per HW mac non per tutti i pc x86....

Avvelenato ha scritto:

avranno fatto i loro calcoli e visto che non gli conveniva. Se non sbaglio tempo fa ci hanno pure provato, prima che ritornasse steve jobs.


non è esatto, hanno concesso licenze per costruire macchine cloni dei mac sui quali era installato macOS. E proprio questa concorrenza HW ha messo in difficoltà apple.

Ciauz!

Avvelenato ha scritto:


non è esatto, hanno concesso licenze per costruire macchine cloni dei mac sui quali era installato macOS. E proprio questa concorrenza HW ha messo in difficoltà apple.

Ciauz!
a quanto mi risulta stai sbagliando :| Apple non ha mai concesso in licenza il suo os

a quanto mi risulta stai sbagliando :| Apple non ha mai concesso in licenza il suo os

Non sbaglia. Io avevo 2 Cloni Motorola StarMax anni fà.
Avevano le stesse caratteristiche dei PowerMac 4400, addirittura la piastra madre era "made by Apple".

I cloni sono stati una delle prime cose segate da Jobs al suo ritorno.

In particolare Apple era andata in difficoltà perchè la PowerComputing (una delle marche che produceva cloni) stava per immettere sul mercato il primo Mac-Clone con processore "G3", molto più veloce dei modelli top di Apple basati su PPC 604.

Possibile che sotto ogni news apple arrivi questo commento?
La Apple fa computer! Dai quali trae il maggior guadagno, dovrebbe vendere 10 volte tanto MacOSX per fare quello che dici tu. Inoltre MacOSX è ottimizzato per HW mac non per tutti i pc x86....

Il motivo principale è senz'altro questo, ma la Apple si guarda bene dal farlo anche per un altro motivo: vendere osx per x86 generico comporterebbe, oltre che ridurre il margine di guadagno vendendo il so ma non il pc, anche di rischiare vendite 'castrate' del software (l'OS per intenderci), dati gli alti tassi di pirateria odierni.

In ogni caso, pensatela pure come volete (fattori estetici, moda, bla bla bla...), ma il mio prossimo portatile sarà un macbookpro con piattaforma Santa Rosa e dualboot gentoo-osx :P
Ovviamente se dovessero sentirsi nuovamente voci riguardo a plastiche che si scoloriscono, dissipatori "incollati" con la pasta termica et similia la cara apple il suo macbookpro se lo terrà :D

Un motivo in più per non sviluppare software nativo per Mac OS X/Linux. Grazie! :rolleyes:

Un motivo in più per non sviluppare software nativo per Mac OS X/Linux. Grazie! :rolleyes:
il punto non è quello, il punto è nel rendere possibile eseguire su piattaforme diverse da quella su cui sono nati, programmi che non verrebbero portati comunque (esempio banale: i giochi di qualche tempo fa, che per chi non li ha mai giocati forse potrebbero essere altrettanto divertenti che appena usciti) ;)
perdi di vista un fattore tanto semplice quanto importante: mentre wine è un tool che l' utente finale deve necessariamente avere sul proprio sistema e di cui necessariamente deve imparare l' uso (se non altro per sapere cosa digitare nella riga di comando per avviare MSOffice ),
Alky (più precisamente, il traduttore "Alkynator") è uno strumento la cui utilità potrebbe essere paradossalmente maggiore per i produttori di SW che per gli utenti finali, che potrebbero avere, di un prodotto SW nativo per Windows già pronto o in fase di sviluppo, una build nativa per Linux in tempi brevi e senza i costi di analisi/progettazione/coding aggiuntivi che si hanno quando un programma è pianificato a monte per essere multipiattaforma
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.
Se mi dici che stare dietro alla MS e reimplementare una a una tutte le funzioni delle varie versioni di MFC, dei common controls, del dotnet framework, ecc ecc ecc, da qui all' eternità, è un lavoro infinito, ti dò ragione, e infatti anche reactos e wine mi risulta stiano procedendo a passi graduali
prima però, mi riferivo più che altro alle caratteristiche del formato binario Portable Executable nei confronti dei loro omologhi nell' Executable Linkable Format e in Mach-O: le specifiche di questo formato, AFAIK ampiamente documentato, e che comunque 71104 conosce di gran lunga meglio di me, saranno per forza di cose in numero "finito" e anzi saranno con ogni probabilità rigorosamente formalizzate e vincolate
altrimenti l' application loader del sistema operativo non potrebbe funzionare in modo generale con degli eseguibili che nella stragrande maggioranza dei casi assicurano la compatibilità con tutti gli OS win32 da Win9x a XP senza ricompilazione
E cosa succede se dopo aver reso compatibile un'applicazione uscirà la versione nuova ? Tutto daccapo :P
Si ridà la nuova versione "in pasto" ad Alky, questo sì... Ma la nuova versione di un programma per Windows, si spera che sia "compatibile con Windows" come prima : nel senso, di restare nell' ambito delle librerie comunemente disponibili sulle versioni di Windows e non esulare da, ad es. , richiedere la MFC71.dll in loco di MFC60.dll o gdiplus.dll in loco di gdi.dll, per implementare le nuove funzioni
ma le funzioni e le classi contenute nelle librerie di sistema di Win finora prodotte, non si possono dire infinite
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.
Se la EULA di un programma o di un gioco mi impone di usarlo solo su Windows, e io volessi usare quel programma su un OS diverso, violerei la licenza a priori
Ma se non vi fossero restrizioni di questo tipo e se quell' applicazione mi è necessaria e se ne posseggo una licenza d' uso in primis, dovrei essere libero di usare delle tecniche che mi permettano di farlo quantomeno "girare" sull' OS di mia scelta, a mio rischio e percolo... soprattutto perchè messe in pratica da un tool automatizzato che mi produrrebbe un nuovo eseguibile equivalente al precedente, senza darmi informazioni mirate al reverse engineering o a capire i segreti del programma

Un motivo in più per non sviluppare software nativo per Mac OS X/Linux. Grazie! :rolleyes: infatti, nessuno svilupperà più su Mac, però tutti i programmi potranno girare lo stesso

edit - merged with prev. post :O

scusate...sapete se esiste gi[]un software per la virtualizzazione fisica tra linux e windows?
nel mio core duo []attivabile un'opzione da bios ma servirebbe un programma di boot che permetta di far girare contemporaneamente i due sistemi e di switchare da uno all'altro in real time. grazie ciao.

Il software Parallels in questione non []solo per mac , ma fa le stesse cose anche su windows e linux, cambia solo la versione e forse il prezzo, vai a vedere sul sito di parallels.