Archiv verlassen und diese Seite im Standarddesign anzeigen : Carbon, Cocoa ...
Ist folgendes Verhalten für Carbon-Programme normal?
Auffällig ist auch bei dieser Version die alte Armbanduhr, die kurz vor dem Beachball erscheint. Es handelt sich wohl auch bei CS3 immer noch um ein Carbon-Programm. (Geht das als Universal Binary?)
http://www.hilfdirselbst.ch/foren/Adobe_Illustrator_CS3_-_erste_Eindr%FCcke_P289697.html
Senior Sanchez
2007-05-04, 22:27:40
Ich habe so etwas schon bei anderen Programmen beobachtet (kann dir auf die schnelle aber keins nennen, sry) und ich denke, das könnte wirklich an Carbon liegen.
Ganon
2007-05-04, 22:35:47
Carbon verhindert Universal Binary nicht.
Was Universal Binary verhindert ist CarbonCFM (Code Fragment Manager), was eine kleine OS9-Emulation ist. Davon ist CS3 bereinigt worden.
"Auffällig ist auch bei dieser Version die alte Armbanduhr, die kurz vor dem Beachball erscheint."
was ist damit?
Ganon
2007-05-04, 23:30:31
Na wenn das Programm beschäftigt ist, kommt halt als Mauszeiger eine kleine Armbanduhr. Das kommt nur bei Carbon-Programmen. Bei Cocoa kommt sofort der Beachball Mauszeiger.
Ganon
2007-05-04, 23:34:35
Ich habe so etwas schon bei anderen Programmen beobachtet (kann dir auf die schnelle aber keins nennen, sry)
Weitere Carbon-Programme wären der Finder und iTunes.
IceLord
2007-05-05, 09:12:24
Weitere Carbon-Programme wären der Finder und iTunes.
Wieso sind denn Apple-eigene Programme mit Carbon geschrieben?
Ganon
2007-05-05, 09:31:13
Ich sag mal so... warum nicht? ;)
Na Finder ist Carbon, weil er halt schon immer Carbon war und von OS9 mit übernommen wurde. iTunes eigentlich ebenso. :D
Bei itunes liegt das wohl auch daran, da es eine Windows-Version geben muss.
OT:
Interessanter Beitrag übrigens auf Mac-TV:
Microsofts Kampf gegen QuickTime: Die QuickTime-Story -> http://www.mac-tv.de/index.lasso?Rubrik=Free
Soweit ich weiss wird QT zurzeit kräftig überarbeitet :)
Ganon
2007-05-05, 10:56:40
Bei itunes liegt das wohl auch daran, da es eine Windows-Version geben muss.
QuickTimePlayer hat seit Version 7 auch Cocoa-Abhängigkeiten (die iTunes nicht hat), also kann es daran nicht liegen. ;)
Was Universal Binary verhindert ist CarbonCFM (Code Fragment Manager), was eine kleine OS9-Emulation ist. Davon ist CS3 bereinigt worden.
Nicht das ich CFM toll finde (genau das Gegenteil ist der Fall) aber warum läuft denn CFM auf PPC und nicht auf Intel?
Ganon
2007-05-07, 10:26:39
Nicht das ich CFM toll finde (genau das Gegenteil ist der Fall) aber warum läuft denn CFM auf PPC und nicht auf Intel?
Weil Apple es so will. Die Software-Hersteller sollen endlich den lahmen OS9-Code aus ihren Anwendungen schmeißen.
CarbonCFM war für den Übergang gedacht und nicht als Dauerlösung. Und das die großen Software-Hersteller vom Wegfall von CarbonCFM so "überrascht" waren, zeigt das sie nicht mal im Ansatz daran gedacht haben, es mal zu verbessern. Apple sagt schon seit Jahren das CarbonCFM nicht immer da sein wird.
Genauso betrifft es jetzt andere alte API-Versionen (z.B. QuickTime und QuickDraw) in 64bit-Versionen von OS X. Diese sind dort aber absolut nicht mehr enthalten. Wer eine 64bit-Anwendung liefern will, muss seinen Code modernisieren (wenn er diese Funktionen genutzt hat).
das cfm nicht mehr sinnvoll ist, sollte klar sein!
mir geht es aber jetzt darum, warum cfm aus technischen angeblich auch nicht unter intel laufen würde, selbst wenn apple das wollte. ein gewisser user hat das zumindest mal behauptet, weil intel keine moderne cpu sei, die sowas kann (was auch immer das bedeuten soll).
Ganon
2007-05-07, 11:29:01
Das ist Käse. CFM ist ne normale Emulationsschicht. CFM und Classic sind verschwunden weil Apple das einfach nicht mehr haben will.
classic würde aber auf intel nur über emulation laufen. os9 gab es ja nativ für ppc.
aber klar, dass jetzt classic wenig sinn macht. wer das braucht, soll sich nach einem os9 emu umschauen.
zu cfm: das es käse ist, dachte ich mir schon ;)
CFM, was Du hier als "die alten und lahmen Krücken" bezeichnest ist durchaus schneller als Mach-O. Quark ist ein Beispiel dafür, wie Software beim portieren von CFM auf Mach-O deutlich an Performace verliert. (Da gibt es Vergleiche im Internet, Grafic Converter habe ich selber ausgestestet, ist je nach Aktion zwischen 5 und 50 % langsamer geworden.)
Kann ich mir absolut nicht vorstellen... wenn es langsamer geworden sein sollte, liegt es sicherlich an etwas anderem
CFM lässt sich nur leider nicht auf Intel portieren. Und Cocoa ist noch mal langsamer, als Carbon-Mach-O.
halte ich auch für ein gerücht.
Ganon
2007-05-07, 12:24:22
Zitate von ut sind reichtlich sinnlos. ;) Der Typ hat sie, seit dem Intel-Switch, nicht mehr alle beisammen ;)
ste^2
2007-05-07, 14:15:57
Ist CFM nicht ziemlich nah an PPC angepasst? Aber egal, wird ja eh nicht mehr benötigt.
Erst seit dem Switch?
Der scheint sich übrigens bei Macuser abgemeldet zu haben. Das ist durchaus nicht unüblich bei Macuser, dass mal ein User sich abmelden lässt. Er hat aber gleich noch seinen Namen löschen lassen -> abgemeldeter Benutzer. :D Das ist wohl neu...
Ganon
2007-05-07, 14:16:11
@Coda
Wie man es nimmt. Er hat zwar damals immer x86er schlechter geredet als sie es waren, aber hielt sich damit eigentlich in einem Forum (MacUser), wo eh die Masse keine Ahnung hatte und auch eigentlich nur in entsprechenden Themen.
Jetzt trollt er sich durch viele Foren und Newsseiten und verbreitet dort Schwachsinn und auch eigentlich, wenn es nichts mit dem Thema zu tun hat.
Wenn du viele von denen sehen willst, geh mal PPCNUX.de besuchen :D
@ste^2
OS9 eben, aber auch nichts was mit nicht mit entsprechenden Aufwand auch hinbekommen hätte. ;) Nur "wozu"?
Mit dem Framework "YellowBox" von Rhapsody sollen Cocoa-Anwendungen sogar unter Windows gelaufen sein. Wäre dann sicherlich heute auch noch möglich.
Ganon
2007-05-07, 15:53:01
Cocoa hat sich aber auch weiterentwickelt ;)
Die PPC-Version von Leopard wird aber auch kein CFM mehr haben oder?
Ganon
2007-05-08, 15:02:05
Afaik hat die PPC32-Version es noch. PPC64, IA32 und x86_64 werden diese nicht mehr haben.
adobe ist im verhältnis performance zu leistung auf sämtlicher programmebene - SCHROTT -
war schon immer so - wird auch immer so sein.
:)
Angeblich ist der neue Finder in 10.5 in Cocoa geschrieben. Warum hatte der alte Carbon-Finder eigentlich den Beachball beim Warten? Bei Carbon kommt doch sonst die Eieruhr?
64-bit support in Leopard: no Carbon love
http://arstechnica.com/journals/apple.ars/2007/06/13/64-Bit-support-in-leopard-no-carbon-love
Die Intel_OSX-Version muss ja ein PPC-CFM haben, damit über Rosetta die Apps ausgeführt werden können, die CFM voraussetzen.
Superguppy
2007-08-02, 11:24:50
Afaik hat die PPC32-Version es noch. PPC64, IA32 und x86_64 werden diese nicht mehr haben.
Erübrigt sich IA32 nicht, wenn sowieso alle Intel-Macs x86_64 können?
Ganon
2007-08-02, 12:30:37
Erübrigt sich IA32 nicht, wenn sowieso alle Intel-Macs x86_64 können?
Können nicht alle. ;) Die Ersten hatten noch ne 32bit CPU.
Können nicht alle. ;) Die Ersten hatten noch ne 32bit CPU.
Rein aus Interesse - weißt du zufällig, welche genau das waren? Eigentlich gab es doch bisher nur den Core Duo und den Core 2 Duo, oder (also abgesehen von den Xeons im Mac Pro)?
Senior Sanchez
2007-08-07, 07:39:15
Der Core Duo bzw. Core Solo (gabs im Mac Mini) sind 32-Bitter. Der Rest ist dann 64-Bit.
Ganon
2007-08-07, 08:27:52
Jup. Eben drum.
Core Solo und Core Duo sind schlicht "verbesserte" Pentium M.
Ah, danke euch beiden, wieder was gelernt. :)
Ich vermute mal, dass Apple mittlerweile Teile des Cocoa-Frameworks auf Windows portiert hat, da Safari meines Wissens eine reine Cocoa-Anwendung ist. Das würde vielleicht auch die vielen Bugs in der Windows-Version von Safari erklären, wohingegen die Mac-Beta ja wohl relativ problemlos läuft. Allerdings vermute ich, dass es so schnell noch kein platform-übergreifendes SDK geben wird, da sicherlich (noch) nicht das komplette Framework portiert ist. Ich würde aber nicht ausschließen, dass in den nächsten ein bis zwei Jahren sowas kommt.
Bleibt abzuwarten, was uns sonst noch mit Leopard ins Haus steht. Die meisten APIs scheinen ja intern stark auf die Ausnutzung von Multithreading optimiert worden zu sein. Wenn man den Postings einiger angeblicher ADC-Select-Mitglieder auf MacRumors glauben darf ist der Spinning-Beachball in Leopard quasi nicht mehr anzutreffen, auch nicht bei den "üblichen" Situationen wie z.B. Netzwerksachen im (dann-Cocoa-)Finder. Wäre natürlich nett, wenn Apple die Carbon-Bibliothek auch noch etwas optimiert hätte (wegen Photoshop), allerdings glaube ich wirklich nicht daran. Apple's Ziel wird wohl sein, die Leute zu Cocoa zu bewegen (womit sie ja eigentlich nicht unrecht haben ;) )
Und was die PPC-Diskussion angeht: Ohne den Intel-Switch hätten wir immernoch G4-Powerbooks. Damit hat sich die Diskussion erübrigt.
Ganon
2007-08-07, 14:35:34
Ich vermute mal, dass Apple mittlerweile Teile des Cocoa-Frameworks auf Windows portiert hat, da Safari meines Wissens eine reine Cocoa-Anwendung ist.
Nope. Safari für Windows ist komplett in C++ programmiert ohne Cocoa.
Nope. Safari für Windows ist komplett in C++ programmiert ohne Cocoa.
:eek:
Zukunft von Carbon:http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6
Zukunft von Carbon:http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/6http://www.ppcnux.de/?q=node/7105#comment-12362
Adobe: Photoshop CS4 64-Bit kommt nur für Windows
http://winfuture.de/news,38497.html
Der Schritt könnte sich für Apple auszahlen, wenn wirklich CS5 dann als 64Bit Cocoa-Anwendung kommt.
Durch diesen Schritt ist Adobe dann auf dem Mac dazu gezwungen, endlich den Uraltcode zu erneuern. Dann könnte die Situation passieren, dass ein CS5 auf einem Mac aufeinmal deutlich besser läuft, als ein CS5 unter Windows. Unter Windows ist Adobe kann Adobe ihren Uraltcode ja weitestgehend weiternutzen.
Hätte Apple nicht die Möglichkeiten von Carbon und 64Bit so stark eingeschränkt, dann hätte man Adobe vermutlich nie zu Cocoa bekommen.
Ganon
2008-04-03, 20:59:39
Weil ich von langjährigen MacOS-Software-Entwicklern immer einen auf den Deckel bekomme weil ich Carbon so verallgemeinere, will ich das hier auch mal weiterreichen :D
Carbon ist sehr wohl auf 64bit portiert worden, sonst würde Cocoa nicht laufen. ;) Der einzige Part der nicht auf 64bit portiert wurde ist die HIToolbox. Das ist quasi die GUI von Carbon.
Alles andere von Carbon (File, Network, etc. pp.) liegt vollständig in 64bit vor.
Verständlicher Schritt, so muss Apple nur noch 2 GUI-APIs entwickeln und nicht 3. Zumal Apple sowieso momentan 64bit-Only-Features in die APIs und Sprache einbaut. ObjC 2.0 ist in der 64bit Runtime etwas featurereicher als die 32bit-Version.
Ænima
2008-04-03, 21:50:22
Ich denke Adobe hat mehr schuld, sie hatten viel zeit das umzustellen :)
Wie gut ist der Adobe-Code unter Windows? Unter Mac OSX sagt man dem Adobe-Code immer nach, dass dieser voll mit Altlasten ist (die zwar durch den Wegfall von Carbon-CFM entschärft worden sind aber immer noch genügend vorhanden sein sollen).
Wenn der Windows-Code von Adobe ebenfalls nicht prickelnd ist, könnte die Situation entstehen, dass CS5 auf dem Mac eine deutlich besser Code-Basis hat und folglich besser läuft (= da Adobe auf dem Mac gezwungen wird vieles neu zu machen), als unter Windows. Das wäre dann ein Bummerang auf die ganzen Windoozer, die sich jetzt über die fehlender 64Bit Version lustig machen.
Aber wie Ganon schon angedeutet hat, müsste Adobe ja nur die Gui auf Cocoa umstellen oder?
Ganon
2008-04-04, 00:13:24
Unter der Haube dürfte der Code identisch sein. Das Problem am "alten" Photoshop lag nur schlicht daran das dieser noch über die Emulationsschicht Carbon-CFM lief (benötigt für die Zeit wo Photoshop noch unter OS9 laufen sollte). Dies wurde ja entfernt und durch die entsprechend neuen Carbon-Routinen ersetzt.
Das hatte mit der GUI aber nicht viel zu tun.
Warum Adobe nicht gleich auf Bibliotheken wie Qt setzt ist mir trotzdem schleierhaft. Qt hat zwar erst eine Alpha von Qt welche Cocoa nutzt, aber das dürfte Adobe doch deutlich günstiger kommen als für jede Plattform Entwickler abzustellen, die nur am rumportieren sind. Ne Qt Lizenz haben sie ja, laut Trolltech.
Auch der Spiegel berichtet:
http://www.spiegel.de/netzwelt/tech/0,1518,545147,00.html
Carbon ist sehr wohl auf 64bit portiert worden, sonst würde Cocoa nicht laufen. ;) Der einzige Part der nicht auf 64bit portiert wurde ist die HIToolbox. Das ist quasi die GUI von Carbon.
Alles andere von Carbon (File, Network, etc. pp.) liegt vollständig in 64bit vor.
Das ist mir bekannt. Trotzdem blicke ich irgendwie als Laie nicht wirklich durch (wie übrigens die wenigsten IMHO).
Ganon
2008-04-04, 08:11:33
Auch der Spiegel berichtet:
http://www.spiegel.de/netzwelt/tech/0,1518,545147,00.html
Wenn da nicht Spiegel stehen würde, würde ich bald sagen "Bild" :ugly:
Carbon ist sehr wohl auf 64bit portiert worden, sonst würde Cocoa nicht laufen. ;) Der einzige Part der nicht auf 64bit portiert wurde ist die HIToolbox. Das ist quasi die GUI von Carbon.
Alles andere von Carbon
Das bis auf die HIToolbox alles auf 64Bit portiert ist, habe ich gehört. Aber das Cocoa von Carbon abhängt ist mir neu. Unter Nextstep gab es auch Cocoa ohne Carbon!
http://www.carbondev.com/site/?page=64-bit+Carbon
Superguppy
2008-06-11, 13:22:42
Wie es scheint, wird wohl Carbon gestrichen werden - ein weiterer alter Zopf, von dem sich Apple trennt.
http://www.macnotes.de/2008/06/10/kommentar-quantensprung-mit-snow-leopard/
(Ja ich weiß der Thread ist alt, aber ich musst an genau diesen Thread denken, wie ich darüber gelesen habe.)
Das wage ich zu bezweifeln, denn unter der Haube ist sehr viel in Carbon, wie z.B. die ganzen Core-Service, auf die man auch über Cocoa zugreifen kann. Das müsste ansonsten alles neu geschrieben werden...
Seiten wie Mactechnews verbreiten halt viel dummes Zeug, da dort "DAUs" die Artikel schreiben. Es wird vermutlich so kommen, dass die HiToolbox rausfliegt (zumindest nicht als 64Bit erscheinen wird). Das ist aber keine Überraschung und das hat Apple schon vor Ewigkeiten gesagt oder angedeutet, dass es die HiToolbox nicht ewig geben wird.
Oder anders ausgedrückt:
Bisherige (32Bit)-Carbon-Anwendungen werden vermutlich weiterhin (erstmal) laufen. Bei 64Bit ist aber Carbon draussen - zumindest direkt (indirekt vermutlich nicht). Das heisst wer neue Anwendungen schreibt, sollte am besten gleich auf Cocoa setzen.
Seiten wie Mactechnews verbreiten halt viel dummes Zeug, da dort "DAUs" die Artikel schreiben.
Ziemlich krasse Aussage! Hast du für solche Theorien auch irgendwelche Beweise?
Ziemlich krasse Aussage! Hast du für solche Theorien auch irgendwelche Beweise?
Ja ist krass. Aber zu dem Schluss kommt man (und damit stehe ich nicht alleine da), wenn man dort mal längere Zeit mitgelesen hat und die dortigen Autoren mal auf die Idee kommen, nicht nur eine englische News zusammen zu fassen, sondern auch zu bewerten oder einen Artikel mit eigenen Gedanken zu schreiben. Dann merkt man ziemlich schnell, dass es dort mit Hintergrundwissen nicht weit ist. Ganon hatte sich glaube ich vor einigen Monaten ebenfalls schonmal in die Richtung geäußert. Aber OK, ich ziehe die Aussage zurück, da sie alles andere als Nett ist. Löschen geht leider nicht. Soll sich jeder selber sein Bild machen.
Ah ja, noch einen Nachtrag: Kam schon mehrmals vor, dass dort Kommentare die in die Richtung gehen einfach gelöscht werden oder der entsprechende User gleich gebannt wird. Kritik, selbst wenn die dort ordentlich vorgetragen wird, wird wohl nicht gerne gesehen.
Beispiel: http://www.macmark.de/mtn.php
Ganon
2008-06-11, 14:07:33
Oder anders ausgedrückt:
Bisherige (32Bit)-Carbon-Anwendungen werden vermutlich weiterhin (erstmal) laufen. Bei 64Bit ist aber Carbon draussen - zumindest direkt (indirekt vermutlich nicht). Das heisst wer neue Anwendungen schreibt, sollte am besten gleich auf Cocoa setzen.
Nope. Den Fall haben wir ja bereits mit Leopard. HIToolbox ist zwar da, aber nur 32bit und alle sollten umsteigen.
Da OS X in Snow Leopard in vielen Bereichen eine Runderneuerung bekommt (z.B. QuickTime wird komplett ausgetauscht durch QuickTimeX), fliegen gleichzeitig auch alle "alten" Teile raus, die auf das alte QuickTime gesetzt haben. So dann auch die HIToolbox. Die ist dann nicht einfach nur als 32bit verfügbar, sondern fliegt KOMPLETT raus.
Carbon als Gesamtframework bleibt sicher erhalten, da es auch in Leopard schon als 64bit da ist. Das ist auch nicht weiter tragisch, da es intern eh nur "eine" Schnittstelle gibt. Die CoreFoundation. Die heißt nicht nur so weil es cool klingt, sondern weil sie es halt ist.
Das Einzige was stört ist die HIToolbox. Das ist uraltes Gemüse und bremst alles.
Wenn die weg ist, kann's endlich wieder weiter gehen. Sieht man ja, das QuickTime gleich eben mal komplett ausgetauscht wird durch eine runderneuerte Version.
Die Entwickler haben ja noch ein Jahr Zeit ihre Software umzustellen. Und davor hatten sie auch schon 5 Jahre Zeit und mehr. ;)
Genau das sage ich doch. :)
Ah ja, noch einen Nachtrag: Kam schon mehrmals vor, dass dort Kommentare die in die Richtung gehen einfach gelöscht werden oder der entsprechende User gleich gebannt wird. Kritik, selbst wenn die dort ordentlich vorgetragen wird, wird wohl nicht gerne gesehen.
Beispiel: http://www.macmark.de/mtn.php
Danke für den Link, sehr informative.
QT 4.5
"In diesem Kontext unterstützt Qt jetzt auch Apples Cocoa-Framework, wodurch auch 64-bit-Anwendungen unterstützt werden. Bislang gab es allein Unterstützung für das Carbon-Framework."
http://www.heise.de/newsticker/Qt-4-5-und-Entwicklungsumgebung-Qt-Creator-veroeffentlicht--/meldung/133842
"Qt für Mac wurde neu geschrieben und verwendet jetzt das Cocoa-API, womit auch eine 64-Bit-Speicheradressierung verfügbar ist. Eine 64-Bit-Unterstützung soll sich so durch einfaches Neukompilieren erreichen lassen, wohingegen bei Carbon die Anwendung hätte angepasst werden müssen."
http://www.golem.de/0903/65610.html
Angeblich ist auch ODT drin, denn Golem schreibt:
"Entwickler können mit Qt nun OpenDocument-Dateien schreiben - die Leseunterstützung wird erst zu einem späteren Zeitpunkt folgen."
Mehr Infos und Download:
http://www.qtsoftware.com/products/platform/qt-for-mac
QT 4.5
"In diesem Kontext unterstützt Qt jetzt auch Apples Cocoa-Framework, wodurch auch 64-bit-Anwendungen unterstützt werden. Bislang gab es allein Unterstützung für das Carbon-Framework."
http://www.heise.de/newsticker/Qt-4-5-und-Entwicklungsumgebung-Qt-Creator-veroeffentlicht--/meldung/133842
Ist es damit auch möglich auf Cocoa-Features wie die Rechtschreibprüfung zuzugreifen? Das hätte ich nämlich gerne bei LyX, das auf auf QT aufsetzt (und für das es leider keinen Cocoa-Port gibt).
Ganon
2009-06-08, 11:52:01
Sofern sie es richtig eingebunden haben, müsste die Rechtschriebkontrolle automatisch funktionieren. Aber dazu muss LyX auch auf das aktuelle QT4 portiert werden, sofern es das nicht ist.
LyX 1.6.3 introduces some goodies provided by Qt 4.5 (menu support for fullscreen mode in linux, close button on tabs). Of course these improvements (as well as some Qt-related fixes) only show up if LyX is compiled against Qt 4.5.
http://www.lyx.org/News#item1
Habe hier MacTeX installiert und anschliessend LyX (angebotene DMG) und sehe davon leider nichts.
From NeXTSTEP to Cocoa: Erik Buck on the Development of Cocoa and Objective-C
http://www.informit.com/articles/article.aspx?p=1353402
In PSI 0.13 (RC3) basiert auf QT 4.5.1 und es funktioniert auch die Rechtschreibkorrektur (nehme an, dass es die von OS X ist).
Übrigens unterstützt PSI 0.13 endlich VoIP (Jabber). =)
http://psi-im.org/
In LyX hingegen klappt die Rechtschreibkorrektur über Cocoa noch nicht. Ich vermute, dass LyX noch Carbon nutzt, trotz aktueller QT Version. Ich glaube man hat da als Entwickler die Wahl.
Im Feature-Poll steht allerdings in der Wunschliste besser OSX Integration: http://wiki.lyx.org/LyX/FeaturePoll
Scribus 1.3.5 ist gegen Qt 4.5.2 kompiliert. Ist aber noch beta (Scribus).
http://www.pro-linux.de/news/2009/14557.html
THE COCOA ADVANTAGE FOR USERS
http://daringfireball.net/2009/09/itunes_and_cocoa
Was hat dieses Cocotron genau auf sich? Habe ich eben entdeckt:
http://www.cocotron.org/Info
http://lievendekeyser.net/brol/CocotronTest.png
Same code, same Interface Builder file, both built from Xcode.
Christopher Lloyd und David Young arbeiten im Rahmen ihres Open-Source-Projekts "The Cocotron" an einer freien Implementierung von Cocoa bzw. wie es auf der Projekt-Website heißt, eines "Objective-C API" ,das dem von Apples Foundation und AppKit sehr nahe kommt. Damit sollen sich Mac-Applikationen unter Windows, Linux und Solaris nutzen lassen.
http://www.golem.de/0612/49627.html
Ganon
2009-12-29, 23:21:02
Hmm... nutzen wohl kein GNUStep... das bräuchte man nur auf Windows portieren und wäre fast fertig.... aber naja, OpenSource und doppelte Entwicklung... ist ja immer so.
Hmmm... es gibt doch einen GNUStep Installer für Windows, wenn ich richtig gesehen habe?
Vielleicht unterscheiden sich die Implementierungen im Detail bzw. vielleicht ist GNUStep nicht auf "aktuellem" Stand? Hat jemand Infos, so dass man sich das Nachlesen sparen kann? :D
Hat eigentlich hier irgendwer sich mal mit Etoilé befasst?
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7711892#post7711892
Btw: "Expertendiskussion" zu Cocoa vs. Carbon
http://www.mcnix.de/?q=node/419#comment-1229
Wie sieht das bei Crossplattformsoftware aus mit Cocoa-Gui?
Objective-C läßt sich nur schwer mit C++ kombinieren, obwohl es Objective-C++ gibt. Nur muß man einen C++ Programmierstil pflegen, der alles andere als schön ist und eher dem Stand von C with Classes entspricht. Das macht es aufwendig, ein Cocoa Frontend für einen C++ Core zu programmieren. In C++ benutzt man intensiv das RAII Idiom, was in Zusammenhang mit Objective-C++ gar nicht möglich ist. Das führt dazu, daß man den kompletten C++ Code isolieren und wrappen muß, so daß niemals Exceptions in Objective-C Code eskalieren (oder umgekehrt), und man muß penibel darauf achten, daß beim Werfen von Exceptions die C++ Objekte in Objective-C Klassen manuell zerstört werden, die Objective-C++ Laufzeitumgebung macht das nämlich nicht. Das liegt daran, daß Objective-C keine echten Exceptions kennt, sondern nur eine Art von jongjmp() Wrapper hat, und somit kein "stack unwinding" macht. => RAII funktioniert so einfach nicht.
Technisch ist es möglich beides zusammen zu bringen, nur lohnt sich das nicht so richtig. Man wird sehen, ob es noch jemanden gibt, der bereit ist die Arbeit zu machen.
http://www.mcnix.de/?q=node/419#comments
"As one wise friend observed to me this week, AppKit may be the next Carbon. UIKit is the frontier."
http://daringfireball.net/linked/2010/01/30/omni-ipad
"Why do I care so much about NeXT computers? Because we at id Software developed the groundbreaking titles DOOM and Quake on the NeXTSTEP 3.3 OS running on a variety of hardware for about 4 years. I still remember the wonderful time I had coding DoomEd and QuakeEd in Objective-C; there was nothing like it before and there still is no environment quite like it even today."
http://rome.ro/2006/12/apple-next-merger-birthday.html
MS Office 2016 für Mac:
yes. 3 remaining Carbon API calls that do not have sufficient Cocoa replacements, but everything else is NS or CF.
https://twitter.com/schwieb/status/573530799045152768
Have to have iOS 64-bit ready for June 1. Lots of shared code so iOS work benefits the Mac side too.
https://twitter.com/Schwieb/status/573541943461814272
Die neuen Office Anwendungen, wie z.B. Word, laufen in einer Sandbox.
I posted this in the other Ars story on Mac Office. Regarding 64-bit and the reasons the apps aren't there yet:
First, although all the places we interact with the OS were rewritten to use Cocoa, the vast majority of the suite is written in C++ (for example, Excel's recall engine, Word's layout engine, etc are all C++ and use mostly common code on all platforms). That code doesn't become 64-bit savvy by waving a magic Cocoa wand over it.
Second, we're focusing on bringing the iOS apps up to 64-bit first. They have a hard deadline of June 1 to be 64-bit (Apple policy for submitting to the iOS App Store) so we have to get that done.
Third, Visual Basic is a large technical challenge to move to another architecture/platform. Some of you may have read my blog about that challenge to move it to Intel back in 2008. We don't have VB on iOS, so we can move ahead on iOS without solving that problem first.
That said, the Mac apps are definitely moving to 64-bit. All the work we do for iOS also helps the Mac because they share a huge portion of code, including the C++ components. We'll get there in the relatively near future, but I cannot share any specific date.
http://arstechnica.com/information-technology/2015/03/office-for-mac-2016-hands-on-a-vital-upgrade-with-some-kinks-to-work-out/?comments=1&start=120
MS Office 2016 Mac
64-bit is coming. Coercing VB into understanding the Mac 64-bit ABI (http://www.x86-64.org/documentation/abi.pdf) which varies *significantly* from the ABI used by Windows for 64-bit is our last remaining big challenge. I'm driving the 64-bit transition work. :)
Schwieb
http://arstechnica.com/civis/viewtopic.php?f=19&t=1258233&start=1160
... und ich bin mir ziemlich sicher, dass ich irgendwo vor mehreren Wochen mal gelesen habe, dass in Office 2016 Mac zum Großteil der gleiche Code wie in der Win-Version steckt und MS dafür einen Wrapper nutzt. Ich meine das war in den Kommtentaren von irgendeinem ArsTechnica Artikel zu Office.
I wish Windows and OS X had agreed on LLP64 vs LP64. Dealing with polymorphic intrinsic “long” is a pain.
https://twitter.com/Schwieb/status/702725602982277120
Mac Office and the Transition to 64-bit
https://dev.office.com/mac-office-64-bit-transition
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.