Windows e Mac OS X sempre più vicini

[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?

[71104]

Originariamente inviato da magilvia

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

[71104]

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?

MacOSX su Intel esiste già

[magilvia]

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

[avvelenato]

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.

[spannocchiatore]

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

[71104]

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

Originariamente inviato da magilvia

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)

[Laertes]

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...

[tarek]

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.

[manuelmagic]

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....

[manuelmagic]

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!

[The_misterious]

Originariamente inviato da manuelmagic

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

[Criceto]

Originariamente inviato da The_misterious

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.

[darkbasic]

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à

[nico159]

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

[jappilas]

Originariamente inviato da nico159

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

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

Originariamente inviato da magilvia

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

[71104]

Originariamente inviato da nico159

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

infatti, nessuno svilupperà più su Mac, però tutti i programmi potranno girare lo stesso

[jappilas]

edit - merged with prev. post

[Laertes]

Originariamente inviato da tarek

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.