Probably the most significant rewrite was from the original 68K assembly, not surprisingly championed by Jean-Louis Gassee who also opened up the hardware side.
Once code was in C (which was being standardized), they could work on porting across CPU's. The huge mistakes of Copland and Taligent were largely due to trying to also jump into some variant of C++ and object-oriented language at the OS level. Of course, that was at the same time Linus stuck with C for Linux and made much more relative headway.
This also gave Apple a lot more leverage in the application space. They spun applications out to Claris originally because the apps were such a pain point, but once C and MPW settled they could duck MS O$$ice leverage/fees with their own more integrated approach (and sell Works + round pink blobs to creatives et al). That made it feasible for Steve to ink the deal with Bill to keep Microsoft apps relevant on Mac's, when most of the other vendors were giving up on that 10% of PC share.
When I started at Apple in late 1995 there was still plenty of 68K assembly in the code base. Sometime when the push to PowerPC began the color picker code landed in my lap. While mostly in C, the RGB and HSB "wheels" were rendered using hand-coded assembly. (This allowed the user on a lowly Macintosh II to real-time drag the slider to adjust brightness or what have you and get a responsive color wheel updating.)
Having never written assembly it was fun pulling down a book on 68K assembly and determining how to do each instruction in straight C.
I remember one odd instruction — some kind of mask-and-shift-bit instruction — that I was unable to find documentation for in the book (pre-StackOverflow obv). Fortunately someone had a Motorola 68020 manual and the instruction I was looking for was there. It had not occurred to me that there were newer instructions for the '020 and that the color picker might use one. (After the fact it occurred to me that in the Macintosh line an '020 or better was the minimum CPU for color support).
A bit confuse here. I am not sure about coded in c part … osx is … but is os9 Pascal plus assembler?
To me, there is a struggle of transition but the strategy is to contain, extend/swap then extinguish, as today is Halloween let us quote the halloween paper, to kill the os9 the whole code base. Everything from assembler has to go … as hp once said you do not eat your own baby other will ….
Among these major 2 plus 1 then just announced transition, as steve said in my quote video above it is the brain transplant of os. That is hard part. Not the hardware as they start with emulation and the cpu power of powerpc and intel move them along “easily” (and arm but we do not know because of low end target of Qualcomm). The whole discussion on cpu is sort of misguided. It is not the cpu ….
Really the hardest part is the os part. Os9 to osx when the base is actually objective c … hence nextstep (the real osx) can move from hardware to software, and run on intel. Apple just to maintain it secretly for years.
Yes osx always can run on intel. Just os9 and all this carbon thing etc thing that is the baggage that has to leave behind. That is a decade of work. But not to migrate os9.
For the arm as pointed out by others, the NVIDIA is an issue. Given N can be a Trillion dollar firm … I think Apple car may not be the best next move. Apple ai for the rest of us might be. How to make that transition ….
> I am not sure about coded in c part … osx is … but is os9 Pascal plus assembler?
Not to any significant extent. The leaked System 7 code I've seen was mostly C and assembler, with a couple of isolated Pascal files in specific areas (mostly Apple Events and CommToolbox). I can't imagine they added much more Pascal after that.
With the rise of networking and multimedia this was also an incredibly chaotic time and I suspect some of the problems with the big OS rewrites stem from that. Microsoft did a better job getting something useful shipped. I don't know if it ever got documented but I'm curious whether there was any serious push to build on the nanokernel work incrementally rather than do the big rewrite.
Linus stuck with C, because Linux is an UNIX kernel clone, and Linus hates C++ no matter what, thus C.
Plenty of other OSes were quite successful using C++, BeOS (which only failed due to NeXT acquisition, could have been the other way around), Symbian, IBM mainframes eventually started adding C++ alongside PL/S and PL.8, on Windows many of those C APIs are actually C++ code exposed as extern "C" {}, and many other examples.
I’m curious, why is C bad at the OS level? It seems like having stuff like classes as improved structs would be helpful as long as you avoid pitfalls like virtual functions/STL containers. C++ compiled without the STL and specific features like virtual seems like entirely an improvement for writing an OS
OS's have limits on when you can do some stuff - for example allocating/deleting stuff in an interrupt handler (and the associated code that interacts with it) - mostly you code around this by just not doing it if you possibly can - but C++ might be doing this behind your back. And when you do need to do it you will likely use a special allocator and associated heap that knows how to interact safely with ISRs - just doing a 'new' without being able to say "where" and "how" is a problem. And then you have to be able to delete/free it the correct way too.
Essentially it means that an important chunk of the language and standard library are off limits in an important part of an OS, and lots of evil bugs are available to people new to the game who just blindly new stuff (or let the compiler do it behind their back)
RAII, templates and inline instead of macros, safer enums, strong types than plain C as less implicit conversions are allowed, namespaces instead of prefix, classes as modules with proper invariants, safer strings and arrays.
Once code was in C (which was being standardized), they could work on porting across CPU's. The huge mistakes of Copland and Taligent were largely due to trying to also jump into some variant of C++ and object-oriented language at the OS level. Of course, that was at the same time Linus stuck with C for Linux and made much more relative headway.
This also gave Apple a lot more leverage in the application space. They spun applications out to Claris originally because the apps were such a pain point, but once C and MPW settled they could duck MS O$$ice leverage/fees with their own more integrated approach (and sell Works + round pink blobs to creatives et al). That made it feasible for Steve to ink the deal with Bill to keep Microsoft apps relevant on Mac's, when most of the other vendors were giving up on that 10% of PC share.