Re: GCC for Mac OS X (fwd)

[Darren Schreiber]

I have been trying to keep on top of Mac OS X developments and I can
clarify a little of what Ted said.

Mac OS X will integrate a number of features.

1.  At the core is Darwin -- based on the Mach kernel and FreeBSD, Apple is
touting this as a tried and true Unix version with the benefits of
stability and security.  Darwin is also going to be more or less "open
source."

2.  On top of that will be a graphics environment built with Quartz (a
version of Adobe technology).  Quartz will enhance the visual interface,
but also have cool features like allowing all programs to save files in
PDF.  Also, Apple will be integrating OpenGL, for enhanced 2D and 3D
graphics.

3.  The next level of the OS will be in three distinct packages:
   A.  Classic -- will allow full legacy compatibility.  All existing MacOS
software will run as-is, but not benefit from the enhancements offered with
the Darwin core.

   B.  Carbon -- allows software to be easily modified to take advantage of
preemptive multitasking, protected memory, and the other benefits of using
a Unix core.

   C.  Cocoa -- this is where Objective C comes in.  This will provide a
"whole new toolbox for building the best next-generation applications."

4.  On top of it all is a new user-interface, Aqua, that will take
advantage of modern processor speeds and graphic capability.  As it's name
would suggest, its got a number of translucent, flowing images and is
intended to make it easier for our grandmothers to use and for hardcore
users to get stuff done.

The story I have heard regarding Objective C is that Apple is currently
downplaying the Cocoa aspect in order to build developer support.  They
want to convey the message that little (i.e. Carbon) or nothing (i.e.
Classic) will need to be done for their products to work with OS X.

But, my understanding is that once OS X is out (late summer or fall) and
accepted, they will start touting the Objective C tools.

Building up a large user base of Objective C coders will obviously have
benefits for Swarm.  Perhaps all the out of print books on the language
will come back in and some new stuff written.

Obviously, I'm a big Mac/Apple fan... so take it all with a grain of salt.
But, I (and the stock market apparently) believe Apple has some promising
new stuff coming out soon.

        Darren



>The main hurdle for running ObjC Swarm applications on non-Unix platforms
>has always been the dependence on gcc's version of ObjC (since there's no
>standard for ObjC). The Swarm team will hopefully correct me if I'm wrong
>but I think there's two implications. First, the fact that gcc is being
>ported to MacOS X, along with the fact that MacOS X will be "FreeBSD with
>a Mac GUI", means that eventually you will be able to run ObjC Swarm
>applications natively under MacOS X (FreeBSD is a free version of Unix,
>analogous to Linux, so almost everything you can do on Linux should also
>be possible on FreeBSD/MacOS X). Second, there would perhaps be a
>possibility of making a real "MacSwarm" variant, with native MacOS
>menus, etc.
>
>At one point Apple was pushing ObjC as the canonical programming language
>for MacOS X (because they bought NeXT). I think they've backed down from
>that, but MacOS X *may* still have very good ObjC support (perhaps even
>better than Unix), for all of you ObjC fans. I haven't kept up with all of
>Apple's announcements about MacOS X, though, so I might be wrong on this
>point.
>-Ted
>
>--
>Ted Belding                              address@hidden
>University of Michigan Center for the Study of Complex Systems
>Homepage: http://www-personal.umich.edu/~streak/
>PGP key:  http://www-personal.umich.edu/~streak/pgp-key.html
>
>On Sat, 12 Feb 2000, Darren Schreiber wrote:
>
>> Thanks for that forward Ted.  As one of the Mac Fans here I'm particularly
>> interested in this kind of info.
>>
>> Of course, I'm still not sure I understand the all the implications.  If
>> GCC for MacOS X becomes fully compliant with the standard, does that mean
>> that Swarm would easily (or reasonably easily) compile for it?
>>
>> Thanks in advance...
>>
>>      Darren
>>
>>
>> >---------- Forwarded message ----------
>> >Date: Fri, 11 Feb 2000 15:34:31 -0800
>> From: Stan Shebs <address@hidden>
>> >To: address@hidden
>> >Subject: GCC for Mac OS X
>> >
>> >Hi all, some of you may know me from GDB, and a few with long memories
>> >may remember that I did a couple Mac ports of GNU a while back (those
>> >silly mpw-* files scattered everywhere are my fault).
>> >
>> >I've just started working for Apple's Mac OS X tools team.  This may come
>> >as a surprise, but Mac OS X is basically FreeBSD 3.2 with a GUI.  Not only
>> >that, but in a few months it will be shipping on every new Mac - so yes
>> >indeed, your grandmother will be running Unix!
>> >
>> >Anyway, my tasks here are twofold: 1) to reduce the divergence between
>> >Apple's GCC and FSF GCC, and 2) to help improve the compiler in various
>> >ways.  Apple has a half-dozen engineers working on GCC that have been
>> >quietly following along with the development trunk, but the set of
>> >patches is still pretty large.  I'll be looking at the local patches,
>> >and sending in those that seem worthwhile for the mainstream.  (Apple
>> >has a blanket assignment for GDB already, but I think we still need to
>> >do one for GCC.)
>> >
>> >At the same time, now that GCC is being used heavily by Apple's OS
>> >developers, as well as by 3rd parties busily porting to Mac OS X,
>> >a number of issues have cropped up.  While the team here is obligated
>> >to resolve them one way or another, ideally we'd like to do things in
>> >a way that will be of interest to the whole GCC community, and so I
>> >plan to be sending a lot of mail to this list (get your killfiles set
>> >up now :-) ), asking for ideas and suggestions.
>> >
>> >So far I'm aware of about four major areas that need attention:
>> >
>> >1. C++ support.  Apparently there have been a number of reports of
>> >C++ constructs allowed by other Mac compilers, but that fail with GCC.
>> >Some cases are just user error, others are compiler limitations.
>> >I'll report on these as specific cases come up.
>> >
>> >2. Objective C.  ObjC has not seen a lot of evolution lately, but
>> >it's still in use.
>> >
>> >3. PowerPC code quality.  Apple has more than a few bit-twiddling
>> >graphics engineers who pore over inner loops and such.  They need
>> >the compiler to generate faster code.  Exception handling and
>> >AltiVec support are two specific areas; for instance, Apple is
>> >using a big hairy patch from Motorola for AltiVec code gen, but
>> >from what I've seen of the patch so far, it seems problematic
>> >for mainstream GCC.
>> >
>> >4. Compiler turnaround.  Mac developers are used to the fast
>> >compile times offered by Metrowerks, and are dismayed by GCC's
>> >slowness.  Do we need precompiled headers?  Should file system
>> >probes be cached?  There are a lot of theories going around, but
>> >facts are in short supply.  But however it's accomplished, the
>> >compiler needs to go faster.
>> >
>> >I'm sure more issues will arise in the future, but these are
>> >the current biggies for which I'll be asking for guidance.
>> >Thanks for your attention, and looking forward to working with
>> >everybody on improving GCC!
>> >
>> >Stan Shebs
>> >address@hidden
>> >
>> >
>> >                  ==================================
>> >   Swarm-Support is for discussion of the technical details of the day
>> >   to day usage of Swarm.  For list administration needs (esp.
>> >   [un]subscribing), please send a message to <address@hidden>
>> >   with "help" in the body of the message.
>>
>>
>> _____________________________________________
>>
>>               Darren Schreiber
>>                Attorney at Law
>>               Graduate Student
>>           Political Science, UCLA
>>              address@hidden
>>         http://www.bol.ucla.edu/~dschreib
>>
>>                   ==================================
>>    Swarm-Support is for discussion of the technical details of the day
>>    to day usage of Swarm.  For list administration needs (esp.
>>    [un]subscribing), please send a message to <address@hidden>
>>    with "help" in the body of the message.
>>
>
>
>                  ==================================
>   Swarm-Support is for discussion of the technical details of the day
>   to day usage of Swarm.  For list administration needs (esp.
>   [un]subscribing), please send a message to <address@hidden>
>   with "help" in the body of the message.


_____________________________________________

                 Darren Schreiber
                  Attorney at Law
                 Graduate Student
             Political Science, UCLA
                address@hidden
        http://www.bol.ucla.edu/~dschreib

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.