Hab gestern gelesen das Apple ab 1. Mai sämtliche NICHT UB Apps rausschmeißt! Ist das ein Zeichen dafür das bis zum 1. Mai Apple ihren ganzen App-Portfolio umgestellt hat? Also Produktion Suite und den ganzen Kram! Sonst müssten Sie ja ihre eigenen Apps aus kicken *grins

vor allem verstehe ich Microsoft gar nicht. Was gibt bei Office viel umzustellen?

Hat Steve auf der Keynote nicht gesagt, es sei beim compilieren nur ein Häkchen zu setzten dann läuft es auf beiden Plattformen? Wo ist bitte jetzt das große Problem von Microsoft und Adobe?

das geht eben nur wenn man auf xcode compiliert hat .... und das hat adobe definitv nicht bis jetzt.

Thunderson

Assemblercode? Binäre Daten?

Zwei Dinge die mir spontan einfallen. Haboptimierter Assemblercode muss erst von pcc/altivec auf x86/sse portiert werden, auch wenn im Fall von Adobe sicher x86/sse Versionen für Windows existieren, ist das "object-format" doch ein anderes und so muss auch der window/x86/sse-Assemblercode geändert werden. Bei M$ ist es wohl so, dass Mac-Office eh eine eigenständige Codebasis hat.

Ein anderes Problem ist die Endianness binärer Daten. Je nachdem wie sie abgespeichert wurden, muss mal die eine Prozessorplattform bytes swappen mal die andere, aber eine muss immer und nie beide. ppc ist nämlich big-Endian und x86 little-Endian.

Bis dann

R"udiger

PS: Endianess beschreibt die Reihenfolge in der die Bytes eines mehrbytigen Wertes (16bit, 32bit 64 bit integer, und floats) abgelegt werden.

Wenn Adobe schon solche Probleme hat, dann wird MS Office ja der reinste Horror werden! So wie das jetzt schon läuft muss man das wohl so richtig von der ersten Zeile an neu schreiben.

ist 1200 viel? Ich vermute mal das sind kein 10% der für apple verfügbaren Applikationen.

rgoetz
PowerPC beherrscht beide Endian-Varianten.

Leute, so einfach wie Herr Jobs das auf der Bühne verkauft ist es nicht. Je mehr Code auf PPC und Altivec optimiert wurde und womöglich aus Codewarrior stammt, desto problematischer ist der Intel-Code.

Die Firmen die jahrelang schlampigen Crossplattformcode vertickt haben, sind nun die Ersten, weil sie auch vorher schon wenig Energie in den Mac gesteckt haben (Hallo Maxon!) und werden von euch auch noch bejubelt weil sie so fit sind.

Alle anderen, wie Adobe, sind dagegen faule Nichtskönner. Die Wahrheit ist manchmal anders als es erscheint. Adobe will halt keine halben Sachen machen.

yenz
OS X kennt über 20.000 native Programme. Da ist 1200 wirklich nicht viel. Zumal die großen wichtigen Kernprogramme fast gänzlich fehlen.

sb War es nicht so, dass der G5 pseudo-little-endian nicht mehr unterstützt, weswegen die Umsetzung von VirtualPC auf G5 so schwer war?

Fen

Ja das stimmt so. Der G5 kann das nicht.

Das Problem mit der Endianness gäbe es nicht, wenn man bei Zeiten auf Cocoa umgestiegen wäre. Und die hatten mindestens 5 Jahre Zeit dafür.

chris
Warum sollte es das Problem in Cocoa nicht geben?

sb,

Fast richtig. Zum einen ist AFAIR der Mode für gemischte Endiasness beim G% zumindest problematisch oder nicht vorhanden.

Zum anderen laufen PPC-Macs im BigEndian-Mode. D.h. de facto hatte Source-Code für OSX-Programme bisher Endianess-swapping,w o Intel-Macs es nicht mehr brauchen und es fehlte da wo Intel-Macs es nun brauchen. Das aber im gewachsenem Sourcecode alles zu finden kann dauern.

Bis dann

R"udiger

Weil für gewöhnlich Cocoa das handelt. - Außer bei selbstimplementierten Netzwerkzugriffen oder Dateizugriffen.

chris

Um es vorweg zu sagen, ich habe keine Erfahrung als programmierer mit Objective-C/Cocoa. Ich arbeite mit c/C++ unter Linux.

Aber wie kann Cocoa wissen, wie meine Daten strukturiert sind, wie siehr das Äquivalent zu etwas wie

fwrite(&data,sizeof(int),1000,fp);

oder

fwrite(&data,sizeof(XY),100,fp);

(XY sei eine vorher definierte Klasse.)

aus?

Bis dann

R"udiger

rgoetz:

Das kann es natürlich nicht, wenn Du ihm nicht die Sicherung überlässt. - Beispielsweise mal so: [NSKeyedArchiver archiveRootObject:myObjs toFile:filePath]; Aber man kann natürlich weiterhin manuell jedwede Art von Zeug direkt auf die Platte schreiben, und das am besten noch ohne Strukturinformationen.

Aber das ist ja eigentlich nicht die Sache im Fall von Photoshop, daher schrieb ich noch "Außer bei selbstimplementierten Netzwerk- oder Dateizugriffen." und ergänzen würde ich es noch um Hardwaretreiber.

Hallo,

Wie speichert das [NSKeyedArchiver archiveRootObject:myObjs toFile:filePath]; die Sachen auf der Platte, als xml oder binär.

Wenn xml, da wäre mir das zu langsam, da es geparst werden muss. Fwrite/fread benutze ich ja vor allem, dann wenn große Datenmengen schnell rein sollen, oder der Aufwand es in ASCII umzusetzten zu gross ist. In letzterem Fall würde mich ein Umsetztung in mit Cocoa weniger stören).

BTW: Ein Problem von Cocoa war/ist das es nur mit Objective-C oder Java geht/ging. Ein ordentliches C++-API wäre wirklich nicht schlecht. Oder gibt es inzwischen eine C++-Cocoa?

Bis dann

R"udiger

rgoetz:

Je länger ich drüber nachdenke stellt sich mir viel mehr die Frage: Kannst Du mir sagen, an welcher Stelle ist Deiner Meinung nach überhaupt die Endianess maßgeblich für die Verzögerung von Photoshop verantwortlich?

rgoetz:

Das ist nicht neu, dafür gibt Objective-C++ das dir den Zugriff auf Cocoa von C++ ermöglicht, und zwar schon seit 10.1.

NSKeyedArchiver speichert binär. - Es gibt aber auch noch andere Möglichkeiten: [NSDictionary writeToFile:filePath atomically:TRUE] Und du kannst auch - z.B. für Prefs - irgendwie sowas wie binäres XML speichern. - Weiss jetzt aber spontan nicht wie.

Hallo,

Ich weiss ja nicht, wie der Sourcecode von Adboe aussieht

Gibt es einen gemeinsamen für Windows und MacOS oder nicht.

Wenn Mac-only:

Dann wird aus einem (z.B. bei Einlesen eines ppm-Bildes mit slpha-kanal, / k.A. ob Photoshop ppm unterstützt, ist aber ein schön simples Grafikformat)

fwrite(&picture,sizeof(int),width*height,fp);

Der int speichert nun alle vier Farbkanäle. Bei Intel muss ich nun entweder swappen, oder die RGB-Werte stehen in der anderen Reihenfolge im int, d.h. ich brauche entweder ein

#ifdef INTEL
swapEndianess(&picture);
#endif

oder

#ifdef PPC
swapEndianess(&picture);
#endif

wenn der swap bei ppc bisher nötig war
oder

#ifdef PPC
r = picture[x][y] & 0x000000FF;
g = picture[x][y] & 0x0000FF00;
b = picture[x][y] & 0x00FF0000;
a = picture[x][y] & 0xFF000000;
#else
r = picture[x][y] & 0xFF000000;
g = picture[x][y] & 0x00FF0000;
b = picture[x][y] & 0x0000FF00;
a = picture[x][y] & 0x000000FF;
#endif

Die ganze endif Teile fehlen und müssen an passender Stelle hinzugefügt werden. oder nimmt irgendwelche anderen 32bit integer in einem binären Datenformat auf der Platte (jpegs, photoshop-files, keine Ahnung was noch so geschrieben und gelesen wird).

Das ist alles im Prinzip simpel. Nur man muss eben alle betroffenen Stellen finden und darf keine übersehen. Gut dran ist wer sowas von vornherein abstrahiert hat.

Bis dann

R"udiger

rgoetz:

"Gibt es einen gemeinsamen für Windows und MacOS oder nicht."

Das soll ein gemeinsamer Source sein.


"Gut dran ist wer sowas von vornherein abstrahiert hat."

Wegen des gemeinsamen Source und vor allem der Austauschbarkeit der Dateien, kann man davon ausgehen.

Hallo,


Sorry, das ich erst jetzt antworte. War zwischenzeitlich nicht in der Nähe eines Rechners.

Wenn dem so ist, wie due schreibst, sollte die Endianess nur im plattformspezifisch handoptimierten Teil Probleme machen.

Die Frage von Thundeson war ja wo das Problem der genannten Firmen liegen könnte. Und die von mir genannten Bereich gehören potenziell sicher dazu. Und M$ hat m.W. beim Office keine gemeinsame Codebasis. Ergo ist die Endianess potenziell ein Problem.

Bis dann

R"udiger

es waere ja ok wenn adobe und MS ende 2006 als ziel angeben, aber mitte 2007 oder spaeter ist der hammer... sind denen die bestandskunden und switcher egal??? oder wollen die jungs einfach nicht lernen???

my 2 cents

=-O=-O