Daniel Eran Dilger in San Francisco
Random header image... Refresh for more!

Inside Mac OS X Snow Leopard: 64-bits

Daniel Eran Dilger

As jingle-pundits desperately try to denigrate Snow Leopard as a “Service Pack,” Apple’s new operating system reference release actually expands the reach of the Mac platform in several important and under-reported new directions. Here’s the second in a series looking closer at some of Snow Leopard’s well-known, but often misrepresented or misunderstood features.

Inside Mac OS X Snow Leopard: 64-bits.
The 64-bit Kernel

It seems fashionable to describe Snow Leopard’s new 64-bit kernel as a problem for Mac users with 32-bit EFI (the startup firmware that launches the operating system). It’s true, 64-bit Core2 Duo machines prior to 2008 still run Snow Leopard’s 64-bit apps using a 32-bit kernel, because Apple’s 64-bit kernel requires both a 64-bit processor (a Core2 Duo or better) and 64-bit EFI.

The 64-bit edition of Windows XP or Vista will run on 64-bit Macs with 32-bit EFI via Boot Camp because Windows doesn’t use EFI; it still lives in the simpler world of BIOS.

However, running a 64-bit kernel on these machines is of limited benefit. While there are certain advantages with the move to a 64-bit kernel, including new security enhancements, the primary benefit of a 64-bit kernel is being able to directly work with significantly more than 4GB of RAM, something that most existing consumer Macs and generic PCs can’t do anyway.

For this reason, Snow Leopard also defaults to running its 32-bit kernel even on consumer models with 64-bit EFI. This prevents mainstream users from running into problems related to incompatible kernel extensions and device drivers (such as printer software), which aren’t yet 64-bit.

This problem has helped repress the popularity of the 64-bit editions of Windows over the last several years, but won’t hold up 64-bit Mac adoption because there is only one edition of Snow Leopard, one that runs on all Intel Macs and simply adjusts itself to the limitations of the given hardware.

Users who want to run the new 64-bit kernel on late modeled Macs (pretty much anything released after early 2008) can do so by booting with the 6 and 4 keys held down. If you’re wondering whether your Mac has a 64-bit EFI firmware, you can type the command “ioreg -l -p IODeviceTree | grep firmware-abi” into the Terminal. The response will identify the machine as either having 32-bit or 64-bit EFI.

64-bit System Apps

What Snow Leopard does do is bring all Core2 Duo, 64-bit Macs (pretty much everything sold since 2007) up to speed with 64-bit system apps, from the Finder and Dock to iChat and Mail to background processes such as launchd and the system-wide spell checker. Running the 64-bit kernel or not, the singular version of Snow Leopard always runs 64-bit apps when running on 64-bit hardware; in contrast, no 32-bit editions of Windows can run 64-bit apps, even on 64-bit capable hardware.

Snow Leopard’s upgrade to 64-bit system apps provides an overall speed boost due to limitations in the original design of Intel’s 32-bit chips; the move to the new 64-bit x64 processor model, originally developed by AMD, solves these issues. Moving to 64-bit apps on other processor families, such as PowerPC, does not yield the same boost, but rather only incurs additional overhead, one of the reasons Snow Leopard is Intel-only.

Windows XP/Vista/7 users also benefit from running 64-bit apps, but Windows can only run 64-bit apps using the 64-bit kernel provided with the 64-bit “edition.” This prevents mainstream generic PC users from realizing the benefits of the move to 64-bits unless they are equipped to make the full jump, which requires lining up 64-bit kernel drivers for all their hardware. This sticky bit has kept 64-bit adoption on Windows very low despite the significant advantages related to making the move.

Snow Leopard does not share this problem, because it has no problem running 64-bit apps using its 32-bit kernel. Additionally, Apple’s unique Universal Binary specification packs both 32-bit and 64-bit code into each application, making Snow Leopard’s 64-bit capable apps backwardly compatible with 32-bit Macs.

64-bit Third Party Apps

Snow Leopard also lays a strong foundation for 64-bit third party apps. While Leopard could run 64-bit graphical apps and even Tiger could run 64-bit background processes, the delivery of 64-bit Mac apps is just getting started. Even Apple is behind the curve on that front, with iWork, iLife, iTunes, and even its Pro Apps all still in 32-bit land. Microsoft Office and Adobe Creative Suite are also waiting for a 64-bit overhaul.

Snow Leopard’s 64-bit kernel enables new generations of Macs that can use far more memory, unlocking new potential and more efficient performance by easing existing bottlenecks and allowing more aggressive caching, particularly for kernel i/o such as disk access. Third party Mac software titles that can benefit from the jump to 64-bits will likely begin to transition to full 64-bit capable binaries at a faster pace than the Windows side overall, because the majority of the installed base of Windows PCs are still running the 32-bit edition of XP, which unlike Snow Leopard, can’t run 64-bit apps at all.

Snow Leopard delivers a performance boost to existing users of 64-bit Macs, but it really lays a foundation for 64-bit, high performance computing in the next few years. Thanks to the long standing 32-bit barrier that has held up the PC demand for large amounts of memory, RAM is now cheaper than ever, making the ability to install large amounts of memory that the operating system can actually use something that mainstream Mac users will hold as an advantage over the mainstream of 32-bit PC users.

That’s because mainstream generic PCs are limited not just to 4GB of RAM, but also incur additional artificial limitations under Windows, where the operating system takes 2GB leaving only 2GB available for the running application. Mac OS X, like Linux, has always allowed applications the full 4GB available on the Intel architecture. This difference has given Windows a translation lookaside buffer performance advantage in the past, but Snow Leopard’s new 64-bit applications erase this lead and instead provide Macs with the upper hand relative to the billion installed base of Windows PCs.

Additionally, as all modern Macs transition to 64-bit apps in a single leap, the Windows installed base will effectively splinter between the mass market of low end, 32-bit offerings (including the large increase in netbooks) and the higher end of 64-bit pros and gamers who will collectively amount to a population not dramatically larger than the Mac installed base, dramatically leveling the competitive playing field in the 64-bit arena.

64-bit Cocoa

Meanwhile, Apple is now arriving back to its original strategy in delivering Cocoa as the primary graphical API for Mac OS X applications. This marks the end of Apple’s decade of compatibility appeasement to Adobe and Microsoft, both of whom led a third-party refusal to update existing apps from the old Mac OS routines to the advanced new frameworks Apple acquired from Steve Job’s NeXT. Going forward, anyone who wants to deliver 64-bit graphical apps has to build them using a Cocoa interface.

Apple was powerless to force the issue a decade ago, when the Mac platform didn’t seem to have much potential left and the new Mac OS X could not offer any guarantees of its survival or success to third party developers. That has all changed. Apple now operates a strong platform that has been rapidly outpacing the growth in generic PC sales by a significant factor for several years now.

Developers now know there is money to be made in shipping third party apps for Mac OS X. Additionally, the tools used to build new Mac apps are essentially identical to those used to develop apps for the iPhone and iPod touch, the leading mobile platform by a wide margin.

Apple’s singular focus on Cocoa will greatly simplify the company’s development efforts, as it won’t be having to move both Cocoa and Carbon into graphical 64-bit land. While Adobe has complained that Apple’s decision to freeze Carbon in a 32-bit maintenance mode has prevented it from delivering a 64-bit version of CS4, the simplified Cocoa roadmap will force Adobe to get on the ball with the next release, upgrading Creative Suite in two directions (Cocoa and 64-bit) rather than dragging along the Carbon past into another decade.

Microsoft and other significant Mac developers will also have to get on the Cocoa bandwagon in order to stay relevant on Apple’s 64-bit Mac platform for the next decade. The Mac already has much more visibility, market relevance and software profitability than its market share would suggest, thanks in part to Apple’s bold capacity to decisively burn its legacy bridges in order to give developers a single, clear option for future development, just as it did on the iPhone.

Of course, Apple itself needs to deliver 64-bit versions of its own Logic Studio, Final Cut Studio, and Aperture, too. The company was previously outpaced by its third party developers in the move to PowerPC, and to a lesser extent, in the move to Intel Macs. Apple’s position as both a platform vendor and an application developer should help it to deliver practical, usable tools for its own developers.

Apple’s leadership in laying out a strong 64-bit future in Snow Leopard has created a strong foundation that will enable the Mac to move ahead in important ways. However, there’s more going on in Snow Leopard than just new progress in supporting 64-bit CPUs. The next segment will look at how Apple has pioneered efficient use of GPUs, and what it means for today’s Macs and for coming generations.

Inside Mac OS X Snow Leopard: QuickTime X

Snow Leopard Server (Developer Reference)

Daniel Eran Dilger is the author of “Snow Leopard Server (Developer Reference),” a new book from Wiley available now for pre-order at a special price from Amazon.

25 comments

1 Thomas { 09.02.09 at 10:10 am }

As I suspected….nothing I use on a regular basis is in 64-bit. All that power…unused…

2 Raymond { 09.02.09 at 10:16 am }

Dan,
I read this article over at Appleinsider and I was surprised not to see the name Prince McClean. I never quite understood the point of the alias as you never kept it much of a secret.

Also is it just me or do some of the commenters over on AI have it in for your articles. Though you may not want to comment on that as you’re currently working with Appleinsider.

3 Conrad MacIntyre { 09.02.09 at 11:16 am }

“As I suspected….nothing I use on a regular basis is in 64-bit. All that power…unused…”

Yeah, you won’t use things like Finder, Dock, Mail, Safari, launchd (check your Activity Monitor – I bet you use this one a lot) and with the release of iLife 2010, iTunes, iPhoto, iMovie, etc. Plus in the coming years as PowerPC falls further into the past developers will be forced to make all their power apps run in 64-bit (like Daniel said) so we’ll see this snappier and RAM-friendly versions of Photoshop, Final Cut, iWork, and even games. Wait until the system req’s for some of these 64-bit capable games comes down the pipe.

Anywho… good article, looking forward to the next.

4 daGUY { 09.02.09 at 11:45 am }

Great article. Forgive me if this is a dumb question (I’m not well-versed in this stuff), but why is it that on Windows you need a 64-bit kernel to run 64-bit apps, whereas Snow Leopard can run 64-bit apps on top of a 32-bit kernel? Is there some technical reason that prevents Microsoft from doing this?

I agree that as long as that limitation is in place, it’ll significantly hamper 64-bit adoption on the Windows side. It creates a catch-22: users can’t move to 64-bit apps until they can run the 64-bit kernel (which requires 64-bit drivers), and developers aren’t motivated to create 64-bit apps because nobody can really run them. It’s a stalemate – each side is waiting for the other, so neither can make a move.

Apple neatly avoids this by making it possible to run 64-bit apps on a 32-bit kernel, while also selling a single OS that can boot into either kernel, and offering universal binaries that can package 32- and 64-bit executables together. To the end user, it’s completely transparent, as it should be. Just like they did with Rosetta and the move from PowerPC to Intel.

5 gus2000 { 09.02.09 at 1:44 pm }

Is that “jingle-pundits” or “jingo-pundits”?

Sadly, Microsoft’s offerings lack compatibility in both directions. Under Win/64, older 32-bit apps run under 32-bit emulation which has caused problems for some apps, most notably iTunes. Apple’s solution to the 64-bit transition was much more elegant than Microsoft’s kludges.

I, too, would second the request for a technological explanation of how Apple can run 64-bit apps under a 32-bit kernel (and why MS cannot). That’s some impressive voodoo.

6 bartfat { 09.02.09 at 3:54 pm }

@daGuy and gus2000

Well, MS decided to bolt 64-bit onto the Windows kernel (on a separate edition that you would have to pay for out of pocket), but didn’t allow developers the ability to deploy fat binaries that had both 32-bit code and 64-bit code that could run on either 32-bit kernels or 64-bit kernels. So they messed up in two ways… they didn’t allow developers the ability to have fat binaries like Apple’s, so they could transition the applications over to 64-bit, and there isn’t as much of a performance benefit from Windows, since it doesn’t have a feature like Grand Central Dispatch in Snow Leopard, that allows the developers to easily utilize multiple cores without the guesswork of trying to figure out exactly how many cores are in the user’s computer.

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/12

But the other thing is that the decision was made that 64-bit Windows was going to REQUIRE 64-bit device drivers, and I think that’s what really killed off adoption. Snow Leopard doesn’t force users to choose between having 64-bit device drivers and 32-bit device drivers, because they don’t require you to use a 64-bit kernel to use 64-bit applications. Well, another side impact of MS’s implementation of 64-bit drivers meant that drivers had to be signed by MS themselves, which meant that third parties would have to release their source code to MS. And no third party would want to do that, mainly because MS has a bad habit of taking licensed IP from others and reselling it.

7 gus2000 { 09.02.09 at 4:34 pm }

Fat binaries allow 64-bit apps to run on 32-bit HARDWARE (by using the 32-bit copy of the binary). Even under SL the kernel is running is 32-bit, so how on earth does a 64-bit app work?

The kernel is the abstraction layer between the app and the hardware. So how does that 64-bit code squeeze through the 32-bit kernel to get to the 64-bit CPU? How does the app address more than 4GB of RAM when the kernel itself cannot?

I’m guessing the answer is complicated, because if it was easy then even Microsoft would have figured it out by now.

8 robomac { 09.02.09 at 9:41 pm }

I hear Win7 has an improved 64bit and 32bit support. How does Win7 64bit-ness compare with Snow Leopard?

I think you are bashing Windows a bit too harsh, Daniel. The real truth is Win7 is a very solid release (yes I have it on my Core Duo notebook installed) and while it may not be as sweet nor can be as solid as a Unix-based OS, it does work and that’s all that really matters for most people and the enterprise as a whole.

If Snow Leopard is just a lovely OS that can’t run enterprise-critical apps – hello, Apple! bundle Win7 with Snow & VMWare!

Sure, SL fits just great in creative departments but I can’t see Macs in engineering, production, administration, and places where Windows apps are dominant.

64-bit is surely a nice fun feature to have for gaming, data warehousing, and such. I can’t see it improving most used apps and even multimedia since SIMD/VLIW vector processing (some 128 & 256 bits wide) cores are already in use along with 32-bit CPU cores.

Ciao

9 The Mad Hatter { 09.02.09 at 11:25 pm }

Developers now know there is money to be made in shipping third party apps for Mac OS X. Additionally, the tools used to build new Mac apps are essentially identical to those used to develop apps for the iPhone and iPod touch, the leading mobile platform by a wide margin.

Yeah, and this gives the independents a real chance to blow away the big boys, as they are more easily able to update their software to take advantage of 64 bit processing. I expect that there will be an interesting shake out, with some of the larger companies loosing significant market share.

10 daGUY { 09.03.09 at 12:28 am }

@bartfat: So are you saying that it was just an arbitrary decision not to allow 64-bit Windows apps on a 32-bit kernel and not a technical limitation? If so, why on earth would MS do that? As I said above, that effectively kills adoption. And clearly it’s possible to run 64-bit apps on a 32-bit kernel since Apple’s doing it.

Actually, come to think of it, I don’t see how it could be a technical limitation, since Macs now use the same underlying hardware as PCs. If the hardware is the same and Apple can get 64-bit apps running on a 32-bit kernel, why can’t Microsoft?

11 drheywood { 09.03.09 at 7:12 am }

Regarding why Windows 64 can’t run 32-bit apps:

I believe Daniel goes into great detail about this here:
http://www.roughlydrafted.com/2008/06/17/myths-of-snow-leopard-2-32-bit-support/

12 jeremyw.sherman { 09.03.09 at 2:19 pm }

@gus2000

Fat binaries allow 64-bit apps to run on 32-bit HARDWARE (by using the 32-bit copy of the binary).
Fat binaries are a wrapper around multiple independent executables. Any of these individual executables can target any platform. A fat binary that includes only x86_64 and ppc64 executables will simply fail to run on 32-bit processors without some sort of emulation layer and a kernel extension to use it.

The kernel is the abstraction layer between the app and the hardware. So how does that 64-bit code squeeze through the 32-bit kernel to get to the 64-bit CPU?
64-bit code runs directly on the 64-bit CPU. In the case of Intel’s 64-bit x86_64 CPUs, the CPU can also execute 32-bit i386 code – x86_64 extends the i386 instruction set, rather than completely replacing it, as the Itanium did. The kernel only acts as a gatekeeper for certain resources. Since all calls involving the kernel under Mac OS X are made indirectly through the Apple-provided libSystem dynamic library, the details of calling into a 32-bit or 64-bit kernel from any executable are handled once and for all by Apple.

How does the app address more than 4GB of RAM when the kernel itself cannot?
The app can address more than 4 GiB of memory because it is using 64-bit pointers. Part of the work libSystem does for calling into a 32-bit kernel might involve ensuring that all values provided by the application in memory that the kernel will need access to are copied into the 32-bit address space.

Amit Singh’s magnum opus, Mac OS X Internals, goes into all the gory details. I have not consulted that while writing this, so any misstatements are my fault.

13 ShabbaRanks { 09.03.09 at 3:29 pm }

@ bartfat

My uncle, a longstanding Windows developer, thinks It could be down to device drivers themselves. On some operating systems like OS X and Linux the drivers run inside the OS kernel so its possible to provide a sort of emulation layer for 64 bit apps to talk to. With Windows the device drivers run outside the kernel so emulation is not possible. 

Given Microsoft’s history this is likely a conscious decision as they may expect users to simply upgrade to 64bit and use the 32bit compatabilty emulation until everyone has transitioned to 64bit. This is what they did with Windows 95 using MSDOS for 16bit compatability. They had an easy ride then though as PCs, as we know them today, were only just taking off so most peoples first PC experience will have been 32bit and they won’t have noticed. Drivers were relatively quick to come into being.   

This relates to Microsoft’s inability to sell Vista. They couldn’t sell Vista because it’s asking people to buy more powerful PCs to have a harder time doing the tasks they currently do well and easily now in XP with low powered, cheap PC hardware. This is very like their position on introducing 64bit Windows. A better solution in the modern world is that offered by Linux & OS X. Introduce 64bit compatability gradually and seamlessly behind the scenes without demanding the consumer to keep on top of developments.    

However, all this is just my guess.     

14 ShabbaRanks { 09.03.09 at 3:41 pm }

Sorry, with regards to Linux transtion to 64bit it should be noted that Linux/Unix operating systems do not have such problems with open source drivers that are already available for a 32-bit os, as 64 bit builds can be made from them.

:-)

15 The Mad Hatter { 09.03.09 at 11:48 pm }

I think you are bashing Windows a bit too harsh, Daniel. The real truth is Win7 is a very solid release (yes I have it on my Core Duo notebook installed) and while it may not be as sweet nor can be as solid as a Unix-based OS, it does work and that’s all that really matters for most people and the enterprise as a whole.

If Snow Leopard is just a lovely OS that can’t run enterprise-critical apps – hello, Apple! bundle Win7 with Snow & VMWare!

Well bright guy, I use Leopard for enterprise apps, and it works fine. In fact it works far better than XP or Vista (don’t intend to try Vista 7, why would I go from a winner to something produced by Microsloth?).

Sure, SL fits just great in creative departments but I can’t see Macs in engineering, production, administration, and places where Windows apps are dominant.

In that case you are blind. I’m using it for engineering/production/administration. It’s great, don’t have to worry about viruses, and automatic incremental backups make my life easy. Quite frankly three years ago I would have agreed with you. But I was totally wrong. It blows Windows away as an engineering/production/administration computer.

16 robomac { 09.04.09 at 12:46 am }

@madhatter – don’t get me wrong Macs are great. I use them where they are perfect – home, small biz, kids, wife, and even at grandma’s.

I use an old dual G5 Power Mac for multimedia roles and it’s great. Three Mac minis power my TVs and network home server. Macbook for the wife. iMac for the kids.

See a pattern there, ‘hatter? I love Macs. Have used Macs since the Mac II and Apple IIGS as a junior high geektoid. I know Mac history and thanks to Dan’s weekly history lessons I get flashbacks.

Your opinion about the Mac’s role in the enterprise though is an illusion and a wishful thinking for you and others like our man Dan Eran.

I too would like to see more Macs running Ansoft Designer, LINC2, Microwave Office, Matlab, LabVIEW, PADS, and other engineering apps (where I work). It just not gonna happen, man! Replacing MS Office with iWork will not cut it. What critical enterprise apps are you talking about? Oracle? DB2? SAP? What? None of those are OSX and MS Orifice is not a critical app, period.

Now that Win 7 will be a solid release, the enterprise will migrate from XP to 7 and not from XP to Snow Leopard unless somehow Apple managed to include the old “Red Box” idea to run .Net/Win32 apps natively. Keep in mind that many companies code some of their critical apps using Windows tools – aka .Net Visual Studio, Delphi, etc. If finance or production dept runs on custom code based on .Net or Win32 then forget Macs there, period. Unless, of course, Macs run Windows 7 on bare metal not virtualization.

So, when Daniel proves to me that the enterprise will gravitate to OSX with the release of Snow Leopard and not Windows 7 then I will praise his Mac illusions for I too have my own opinions on tech (no just Mac) matters.

17 tron { 09.04.09 at 3:16 am }

Extending from what 12jeremyw.sherman says on how this works, the kernel and programs run in separate address spaces from each other. They are essentially different programs. Some operating systems are designed in such a way that user programs “map” into the kernel address space for direct access. Those operating systems can’t easily mix 32 bit and 64 bit virtual memory tables, but Mac OS X doesn’t use that technique, which is frankly a holdover from an earlier time.

All modern kernels use internal functions to “copy” information from user-mode programs. These functions can easily be given 64 bit integers. Only such calls would need to understand the 64 bit virtual memory tables or interact with the 64 bit features of the Intel chips. Because of this, the holdover of mapping user programs into the kernel address space is a minor optimization at best which can be done away with easily.

The structure of Mach, which underlies Mac OS X, probably also makes this easier, and may also make it easier to mix 32 bit drivers into 64 bit kernels, since Mach has a stronger kernel component separation model than many other Unix kernels, and makes much more use of message passing paradigms than other kernels which make more use of direct function calls.

As for user programs addressing more memory, memory is divided into physical 4K or 8K page frames. These are manipulated by the kernel and attached to file caches or virtual memory page tables through data structure manipulations. The kernel does not need to address all of physical memory through virtual addresses in order to do any of this. In the 70′s it was quite common for operating systems running on 16 bit processors to work with several megabytes of physical memory using these kinds of techniques, so this is nothing new.

It seem a bit annoying, even so, that 32 bit EFI forces use of 32 bit kernels in Mac OS X. This means that the kernel runs somewhat slower than it could, though this probably doesn’t have too many other effects.

18 MacNotables » Blog Archive » MacNotables #938: Bob LeVitus Says Snow Leopard is for Dummies (and The Rest of Us), and It’s Only Rock and Roll, But… { 09.04.09 at 11:00 am }

[...] Inside Mac OS X Snow Leopard: 64-bits by Daniel Eran Dilger on Roughly Drafted [...]

19 ShabbaRanks { 09.04.09 at 1:57 pm }

I swear this is the last time I like to another site but this particular blog post is hilarious. The comment war after is even better.
http://community.winsupersite.com/blogs/paul/archive/2009/08/31/snow-leopard-great-news-for-windows-7-too.aspx

Honestly the last time.

20 The Mad Hatter { 09.05.09 at 1:08 am }

I too would like to see more Macs running Ansoft Designer, LINC2, Microwave Office, Matlab, LabVIEW, PADS, and other engineering apps (where I work). It just not gonna happen, man! Replacing MS Office with iWork will not cut it. What critical enterprise apps are you talking about? Oracle? DB2? SAP? What? None of those are OSX and MS Orifice is not a critical app, period.

Replacing Orifice with IWork is probably one of the best moves you can make, Orifice is a total piece of junk. Out of the software that you mentioned, Labview is the only one I recognized, and it’s available on OSX.
I do a lot of CAD work – while it’s limited TurboCAD offers great value for the cost. If you are a pro and doing a lot of heavy design work (which I’m not, I’m a salesman) Punch Shark FX is a killer package.
And that takes care of me.

Now that Win 7 will be a solid release, the enterprise will migrate from XP to 7 and not from XP to Snow Leopard unless somehow Apple managed to include the old “Red Box” idea to run .Net/Win32 apps natively. Keep in mind that many companies code some of their critical apps using Windows tools – aka .Net Visual Studio, Delphi, etc. If finance or production dept runs on custom code based on .Net or Win32 then forget Macs there, period. Unless, of course, Macs run Windows 7 on bare metal not virtualization.

In my case, that’s not an issue. Because of who and what I am, IT has to put up with what I want, not the other way around. There are advantages to being at the top of the food chain.

21 JohnWatkins { 09.05.09 at 9:30 am }

TMH, for CAD I like Ashlar’sCobalt, It’s great for sketching or doodling a design, but itss a very full engineering package too — good enough for Burt Rutan to do his Aeronautical design. And hey Google’s SketchUp Prois perfect for exhibit design (not engineering, I know.)

Robomac, whether you think Macs “can run enterprise critical Apps” depends on your “enterprise” and what is “critical” to it. Macs are a solid presence in many enterprises especially Unix centric and academic/research-oriented areas (take a look at bioinformatics.)

While I’m sure they are important to you and others, none of the apps you mentioned are important to me. Obviously, the more esoteric the app, the more likely it will be limited to the platform it was originally developed on. There are often quite nice, but little known alternative SW packages available on the Mac. Options on OS X are expanding exponentially and will only continue to do so for a long time.

22 JohnWatkins { 09.05.09 at 1:42 pm }

Robomac,
Like I said, I really have no experience or knowledge of the software you mentioned, but I’m sure you would have to agree it is pretty esoteric stuff. The one package I have heard of is MatLab, and again I know next to nothing about it, but I have heard it compared with Mathematica, which was originally developed on and for the Mac (although Apple was slow on the uptake as I remember.)
Although I’m sure each package has its strengths and weaknesses, is it really a deal-breaker not having MatLab on the Mac when Mathematica is available?

TMH
While iWork is an elegant and better replacement for MS Office in many ways (and probably for most users,) Numbers, as cool as is is in places, is pathetic for any meaningful number crunching. Even doing a mildly mortgage comparison is more than it can handle. Maybe in another version or two, it will become acceptable.

23 JohnWatkins { 09.05.09 at 1:46 pm }

correction:
. . . . Even doing a mildly [complex] mortgage comparison . . .

24 T. Durden { 09.05.09 at 4:25 pm }

MatLab, SimuLink and LabView are all available for Mac OS X. Didn’t check the others in the list from robomac, but I’m sure some others are available as well. Being an engineer and mathematician, I can find all I need on the Mac.

25 warlock7 { 09.06.09 at 12:26 pm }

So. Why has the ability to boot into 64bit kernel mode been disabled on MacBooks? I have a late 2008 MacBook. Early unibody, identical specs to the MacBook Pro, aside from the monitor resolution, of the same time period which will boot into 64bit kernel mode. Is this an accident due to the name of the device being the same as the now white models?

You must log in to post a comment.