Adobe Photoshop CS4 a 64bit solo per Windows

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/softwar...ows_24878.html

Adobe Photoshop CS4 offrirà inizialmente il supporto alle architetture a 64bit solo per sistemi operativi Microsoft Windows

Click sul link per visualizzare la notizia.

[zephyr83]

Prima dei programmi ci vorrebbero i driver e "stupidi" plugin come adobe flash!! Il limite più grosso per il passaggio ai 64 bit mi sembra proprio questo!!!! Cosa aspettano a fare una versione a 64 bit di sto flash del cavolo???? Mortacci loro!!!!

[jo.li.]

Questo è solo un problema degli sviluppatori che in pratica devono riconvertire le loro linee di codice per le API Cocoa che sono anche a 64bit, questo perché di OS X c'è solo una versione che supporta sia i 32 che i 64 bit dei moderni processori, e perché le applicazioni del S.O. della Apple possono contenere codice Fat binary cioè 32/64 bit così come sia PowerPC che per processori X86. Questa versatilità è evidente anche pensando al fatto che l'iPhone adotta sempre OS X con le stesse API Cocoa che girano su un'altra differente architettura HardWare basata su processore ARM.

[sesshoumaru]

Era ora che li obbligassero a scrivere in Cocoa.

Carbon è un framework vecchio, mi stupisco che apple lo tenga ancora in piedi, non capisco perchè Adobe lo usi ancora.

[Criceto]

Adobe, purtroppo, aveva scelto per lo sviluppo di Photoshop Carbon e, quindi, ora deve correre ai ripari cercando di recuperare il tempo perduto

Diciamo che Adobe non ci ha mai proprio pensato a portare le sue applicazioni su Cocoa. Anzi Carbon è nato proprio dal rifiuto delle grosse software house come Adobe e M$ a voler portare le proprie applicazioni sulle API di derivazione NeXT (Cocoa). La prima versione beta di quello che sarebbe diventato OS X, infatti, non includeva le API Carbon. Sono state aggiunte proprio per facilitare il porting di Photoshop e compagnia sul nuovo OS.

Ancora a distanza di 7 anni dall'uscita di OS X nè Adobe nè M$ (ma questo mi sorprende meno) si sono rassegnate a scrivere le loro applicazioni con le nuove API, e purtroppo si vede. Sono quindi contento che Apple abbia scelto di rimuovere il supporto dei 64 bit su Carbon così da dare una motivazione in più ad Adobe ad aggiornare davvero le sue applicazioni.

[jo.li.]

La Apple è stata costretta a diciamo "ammodernare" le vecchie API del Mac OS Classico poi divenute Carbon, perché non solo questo avrebbe facilitato il passaggio delle applicazioni ad OS X ma anche perché allora nel 1997 la situazione della Apple non era certamente quella di adesso e in molti ne avevano pronosticato il fallimento.

Quindi era impensabile che dei programmi così grossi venissero riscritti in un nuovo linguaggio e con nuove API, vista la situazione finanziaria e commerciale.

E' chiaro che adesso lo scenario è completamente diverso e che la Apple spinge perché vorrebbe che tutte gli sviluppatori usassero Cocoa per molte valide ragioni a mio modesto parere.

[idt_winchip]

Effettivamente c'è da considerare che la stessa apple ha ancora il finder e itunes scritti con cocoa e non sono applicazionucce messe così..il finder è il nucleo del sistema!
Posso capire su mac os 10.1..ma qui siamo al 10.5 e la situazione è sempre questa.
Io credo che il problema fondamentale sia passare dal C/C++ di carbon a obiective C di cocoa. Fare il porting di un grande progetto non è assolutamente cosa da poco.
Speriamo che in questo modo porteranno finalmente tutto in cocoa!

[DTM]

Era ora...in ambito professionale erano ANNI che aspettavo questa notizia. Finalmente è ufficiale

[LNdemon]

Originariamente inviato da idt_winchip

Effettivamente c'è da considerare che la stessa apple ha ancora il finder e itunes scritti con cocoa e non sono applicazionucce messe così..il finder è il nucleo del sistema!
Posso capire su mac os 10.1..ma qui siamo al 10.5 e la situazione è sempre questa.
Io credo che il problema fondamentale sia passare dal C/C++ di carbon a obiective C di cocoa. Fare il porting di un grande progetto non è assolutamente cosa da poco.
Speriamo che in questo modo porteranno finalmente tutto in cocoa!

Beh, in realtà in Finder era in carbon fin dalla 10.4 poi è stato riscritto in cocoa quando si è passati allo stile itunes-like sulla 10.5 ( Leopard ).
Cocoa ( Objective C ) è davvero semplice da usare quando si è capito il meccanismo, mentre Carbon è molto piu difficile da gestire. Penso sia questo uno dei particolari che li distingue. Anche se, sinceramente, ancora non capisco perchè apple abbia adottato questo stile di programmazione per il suo framework di punta

[MiKeLezZ]

Ne varrà ancora la pena sviluppare per Mac OS ?

[frikes]

era ora! un software del genere risultava castrato per via della "minima" quantità di ram utilizzabile.

a questo indirizzo http://punto-informatico.it/p.aspx?i=2244707
viene detto che è ufficialmente utilizzabile con Win vista 64bit "sebbene dovrebbe girare - eventualmente con qualche problema minore - anche su Windows XP x64. "



sul blog di john nack viene annunciata anche la versione di Lightroom a 64bit
http://blogs.adobe.com/jnack/2008/04...hop_lr_64.html

[sesshoumaru]

Originariamente inviato da MiKeLezZ

Ne varrà ancora la pena sviluppare per Mac OS ?

Per Adobe decisamente si, fa da sempre grandi vendite nel mondo mac.

[jo.li.]

Originariamente inviato da LNdemon

Beh, in realtà in Finder era in carbon fin dalla 10.4 poi è stato riscritto in cocoa quando si è passati allo stile itunes-like sulla 10.5 ( Leopard ).
Cocoa ( Objective C ) è davvero semplice da usare quando si è capito il meccanismo, mentre Carbon è molto piu difficile da gestire. Penso sia questo uno dei particolari che li distingue. Anche se, sinceramente, ancora non capisco perchè apple abbia adottato questo stile di programmazione per il suo framework di punta

Il Finder è ancora una applicazione Carbon così come iTunes e molte altre.

L' Objective-c così come il C++ sono linguaggi di derivazione C orientati verso la cosiddetta programmazione ad oggetti, nati su per giù nello stesso periodo, solo che il secondo ha avuto più fortuna, ma questo non vuol dire che il primo sia peggiore dell'altro, anzi secondo me è vero il contrario.

[Ravered]

con la 10.6.x non ci sarà più il problema del supporto dei G4 a 32bit, quindi a quel punto Adobe potrà rilasciare la sua suite per Mac solo a 64 bit.

[Criceto]

Originariamente inviato da Ravered

con la 10.6.x non ci sarà più il problema del supporto dei G4 a 32bit, quindi a quel punto Adobe potrà rilasciare la sua suite per Mac solo a 64 bit.

Perchè dovrebbe? Non sempre i 64 bit sono meglio.
E poi la prima generazione di MacIntel montava i CoreDuo che erano a 32 bit.

[jo.li.]

Originariamente inviato da Ravered

con la 10.6.x non ci sarà più il problema del supporto dei G4 a 32bit, quindi a quel punto Adobe potrà rilasciare la sua suite per Mac solo a 64 bit.

Ma che c'entra? Ripeto OS X esiste in un Unica versione che supporta sia i 32 bit che i 64 bit.

Per esempio, la Adobe ha già rilasciato una beta del suo programma Lightroom per Mac che è anche a 64 bit perché scritta fin dall'inizio con le API Cocoa.

Questo vuol dire che se io la lancio su un Mac che ha un processore a 32 bit questa andrà a 32 bit mentre se la lancerò su un Mac con processore a 64 bit questa andrà a 64 bit.

[^TiGeRShArK^]

Originariamente inviato da idt_winchip

Io credo che il problema fondamentale sia passare dal C/C++ di carbon a obiective C di cocoa. Fare il porting di un grande progetto non è assolutamente cosa da poco.
Speriamo che in questo modo porteranno finalmente tutto in cocoa!

Lo penso pure io.
Per il poco che ho visto di codice cocoa, con tutto che il c++ mi fa schifo, l'objective c ha una sintassi che definire orrida è anche un complimento.
non avevo ancora mai usato un linguaggio che per chiamare un metodo (e quindi inviare un messaggio ad un oggetto) ti obbliga a scrivere oscenità del genere:

NSCountedSet *cset = [[NSCountedSet alloc] initWithArray:args];

al posto dell'n volte + leggibile (con n grande a piacere):

NSCountedSet *cset = new NSCountedSet.initWithArray(args);

in C++
o di

cset = NSCountedSet.new.initWithArray args

del ruby.
Per fortuna che esiste anche un wrapper che utilizza ruby per cocoa al posto dell'objective c...
però ovviamente dovevano fare qualcosa per rompere le palle..
In ruby ogni chiamata all'ultimo metodo deve terminare con un odiosissimo underscore _.
E il bello è che in teoria sarebbe anche possibile non metterlo dato che sono permesse entrambe le sintassi..
Ma guarda caso di default su mac os x è disabilitata la sintassi senza underscore

[^TiGeRShArK^]

Originariamente inviato da jo.li.

Il Finder è ancora una applicazione Carbon così come iTunes e molte altre.

L' Objective-c così come il C++ sono linguaggi di derivazione C orientati verso la cosiddetta programmazione ad oggetti, nati su per giù nello stesso periodo, solo che il secondo ha avuto più fortuna, ma questo non vuol dire che il primo sia peggiore dell'altro, anzi secondo me è vero il contrario.

il secondo ha una sintassi da far vomitare.
Basta avere un minimo di esperienza nella scrittura di codice in progetti medio-grandi per capire che mentre una sequenza di fai(questo).quindi(quello); è molto leggibile prova a districarti in [[fai :questo] quindi :quello]; e qui ancora stiamo invocando solo due metodi con un parametro....
Sinceramente mi sembra molto + error-prone l'approccio di objective-c dato che servono parentesi quadre concatenate e innestate tra di loro.

[^TiGeRShArK^]

Originariamente inviato da Criceto

Perchè dovrebbe? Non sempre i 64 bit sono meglio.
E poi la prima generazione di MacIntel montava i CoreDuo che erano a 32 bit.

Nel caso dell'architettura x86 si.
I 64 bit, correttamente implementati nel processore, sono meglio in qualunque caso.

[jo.li.]

Originariamente inviato da ^TiGeRShArK^

il secondo ha una sintassi da far vomitare.
Basta avere un minimo di esperienza nella scrittura di codice in progetti medio-grandi per capire che mentre una sequenza di fai(questo).quindi(quello); è molto leggibile prova a districarti in [[fai :questo] quindi :quello]; e qui ancora stiamo invocando solo due metodi con un parametro....
Sinceramente mi sembra molto + error-prone l'approccio di objective-c dato che servono parentesi quadre concatenate e innestate tra di loro.

E' tutta una questione di esperienza, io ho una maggiore pratica con l'objective-c e pochissima con il C++.