• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: C'mon Apple! DECIDE!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C'mon Apple! DECIDE!


  • Subject: Re: C'mon Apple! DECIDE!
  • From: Charles Srstka <email@hidden>
  • Date: Sun, 28 Apr 2002 19:52:33 -0500

Carbon will survive forever. I don't have any problem with that, and I don't see why anyone else should either. We can call any Carbon code we want from our Cocoa apps without problems, and I rather like that flexibility. Without access to Carbon, you can't use FSRefs, aliases, the resource manager, etc., and you have no alternative to certain Cocoa methods that don't work properly (cough... -[NSWorkspace unmountAndEjectDeviceAtPath:]... cough). Having options is good. And people can even wrap up Carbon calls within nice Objective-C objects to make Carbon functions just as nice as their Cocoa equivalents.

Charles

On Sunday, April 28, 2002, at 07:10 AM, Mamdouh wrote:

Hi...

I just have some thoughts about the "If Carbon will survive" issue thats going on!
Im only 15 and pretty new to programming, and i must say that Cocoa helped me understand a lot of the OOP procedures, but excuse me if what im writing is far out stupid and if im getting the hole programming thing all wrong!

I was thinking about the "If Carbon will survive" issue and began asking myself the $ million question: Will Carbon survive, and will the big software houses investigate in writing cocoa versions of there apps?... Well in my mind its like this: Carbon will survive as long as Cocoa seems to be to big an opstikle for the big software companies who deliver the big apps! So its only a question of when the big software houses give Cocoa a seriuose try. Writing a Cocoa version of the Carbon apps isn't actually as hard as it might seem! Its a matter of overcoming the fear of a new programming system! I made an example and i hope this is right:

To make it as hard as possible lets take the biggest app and the probably the hardest app to write on the market: Photoshop (7.0). A pure Carbon app... Many believe that "it will be impossible to write a Cocoa version of such a huge app since it has to be avalible to other platforms (Windows), and the old Mac frameworks and the Windows frameworks are very much alike, and since OPENSTEP isn't avalible on any other platforms any more, Carbon is the only way!" I disagree:
The old Mac and the Windows frameworks are not alike... They are actually as different as can be! Lets brake it down for a second:

What makes an app like photoshop such a hit: its capability4sphotoshop! And where are photoshop capability4s: in its drawing system and brushes! Without the brushes Photoshop would be nada! And its easy to see that the brushes in the Windows version of photoshop are EXACTLY the same as the ones on Mac, no differences what so ever! So its obvious that the brushes are written in a way so they use no system calls, and only interact with the drawing system INSIDE photoshop, which again must be the same over platforms or else it would produce different result when drawing on different platforms! So the brushes and the drawing system must be in pure C/C++ and use no system calls! And guess what: You can use C/C++ inside cocoa in the form of Objective-C++ or as pure C/C++ as in the Apple example:

http://developer.apple.com/samplecode/Sample_Code/Cocoa/Cocoa_With_Carbon_or_CPP.
htm

So since the capability4s of Photoshop are already avalible and dont need a rewrite, the only thing they have to (re)write are things like opening files, saving files, and the interface which could be done in a matter of hours with interfacebuilder. All small things that ven i can make. And ALL of these things can be done in a matter of 150-200 lines of code (which again doesn't have to be Obj-C since Obj-C++ is avalible)... So actually the port of such a an app doesn't need so much work as the companiecompanys think! And i believe its Apples job to teach to big software companies what i just wrote! The example above could have been with any other app: like filemaker (The server (v. 5.5) is actually already in Cocoa :) : Again the database engine is probably also in a non system calling way, and again just write the file I/O and the interface and: its running!

Apple have already decided! The big software companies just need to decide. And Apple has to help them decide byt teaching them more an more about the portingfase! So until they decide Apple will have to keep Carbon alive!

This is a pretty long mail but i thought that i just had to get it out!
Maybe im right and maybe im getting the hole programming thing all wrong! But i would love some comments and opinions!

TIA
Mamdouh
Student/Programmer
Denmark
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re:C'mon Apple! DECIDE! (From: Mamdouh <email@hidden>)

  • Prev by Date: Re: Custom TextField/fieldEditor
  • Next by Date: Re: setting color of a progress indicator?
  • Previous by thread: Re:C'mon Apple! DECIDE!
  • Next by thread: Re: C'mon Apple! DECIDE!
  • Index(es):
    • Date
    • Thread