The Current State of OS 10.6 (Or: It's Coming Way Later Than You Think)

[mkrishnan]

Apple can't deprecate the whole software ecosystem; they may as well junk OS X at that point.

I see what you're saying. So I'm guessing the vast majority of drivers on the market for Intel OS X today are in 32 bit variant?

 

[wrldwzrd89]

I see what you're saying. So I'm guessing the vast majority of drivers on the market for Intel OS X today are in 32 bit variant?

You're right, but I think you're not pessimistic enough. 100% of the PPC drivers are 32-bit, right? I strongly suspect that 100% of the Intel drivers in production now are 32-bit too, for the simple reason that a 64-bit driver and a 32-bit kernel can't communicate with each other.

 

[mkrishnan]

You're right, but I think you're not pessimistic enough. 100% of the PPC drivers are 32-bit, right? I strongly suspect that 100% of the Intel drivers in production now are 32-bit too, for the simple reason that a 64-bit driver and a 32-bit kernel can't communicate with each other.

I'm hoping (I guess, probably still unrealistically) that the fact that the Intel transition kind of, at least temporarily, wiped out a lot of the smaller, non-Apple development environments and made people adopt programming conventions required by XCode, that maybe the Intel transition will still help make it easier to get the 64 bit drivers out there? (Also, with Apple, it's not like I'm installing that many drivers for things, outside of the ones Apple ships. My scanner is pretty much the only thing I own for my Mac that needed a driver).

Or perhaps they will do something more transparent where the system can seamlessly drop to 32 bit kernel operation with 64 bit features disabled whenever there are not complete 64 bit drivers available, so that it will essentially seem like the system continues to work either way?

 

[wrldwzrd89]

I'm hoping (I guess, probably still unrealistically) that the fact that the Intel transition kind of, at least temporarily, wiped out a lot of the smaller, non-Apple development environments and made people adopt programming conventions required by XCode, that maybe the Intel transition will still help make it easier to get the 64 bit drivers out there? (Also, with Apple, it's not like I'm installing that many drivers for things, outside of the ones Apple ships. My scanner is pretty much the only thing I own for my Mac that needed a driver).

Or perhaps they will do something more transparent where the system can seamlessly drop to 32 bit kernel operation with 64 bit features disabled whenever there are not complete 64 bit drivers available, so that it will essentially seem like the system continues to work either way?

I hope so... that would be ideal, if what you're saying turns out to be true. Even if the worst-case scenario arrives, and all drivers need an update, the mass migration to Xcode that happened with the Intel transition will make the updating process considerably simpler. In general, most programs that don't make assumptions about data type lengths will work with no changes when recompiled in 64-bit mode. Since about 95% of programs out there don't have to worry about data type lengths anyway (this is just a rough estimate), this means that 95% of drivers will need only a recompile.

 

[mkrishnan]

On that topic, I was wondering this... before the Intel transition, people were using all kinds of little custom development environments and things to develop OS X software. Is it pretty true that development at major software and driver vendors is now being done in XCode, or have they gone back to using Intel versions of God-knows-what?

 

[wrldwzrd89]

On that topic, I was wondering this... before the Intel transition, people were using all kinds of little custom development environments and things to develop OS X software. Is it pretty true that development at major software and driver vendors is now being done in XCode, or have they gone back to using Intel versions of God-knows-what?

The Java and Python developers (such as myself) never had to do anything different, since their old IDEs "just worked". Anyone developing native apps for Mac OS X (i.e. using Objective-C and Cocoa, or C++ and Carbon) has either folded or moved to Xcode - there really isn't any viable alternative if you want to make universal binaries. Sure, there are things like RealBASIC with their experimental UB support, but these don't count.

 

[Amdahl]

I hope so... that would be ideal, if what you're saying turns out to be true. Even if the worst-case scenario arrives, and all drivers need an update, the mass migration to Xcode that happened with the Intel transition will make the updating process considerably simpler. In general, most programs that don't make assumptions about data type lengths will work with no changes when recompiled in 64-bit mode. Since about 95% of programs out there don't have to worry about data type lengths anyway (this is just a rough estimate), this means that 95% of drivers will need only a recompile.

You are completely wrong. Every driver needs major changes to deal with 64-bit pointers in all OS data structures, in DMA control+bus control, etc. The problem, as Vista demonstrated, is many devices will not get new drivers ever.

On that topic, I was wondering this... before the Intel transition, people were using all kinds of little custom development environments and things to develop OS X software. Is it pretty true that development at major software and driver vendors is now being done in XCode, or have they gone back to using Intel versions of God-knows-what?

Device drivers are, by definition, not platform independent. The development environment issues are not usually a problem. That is considered part of the job in device driver work.

 

[wrldwzrd89]

You are completely wrong.

Oh? I must admit, though - I've yet to write a program that wouldn't work in 64-bit mode after a recompile with the appropriate switch enabled. If I'm wrong about how the 64-bit transition will go, then there's obviously something I'm missing that I'm not aware of.

 

[Riemann Zeta]

^^ Yes, unfortunately device drivers are different than regular software when it comes to things like CPU architecture. Basically, any kernel-mode driver (i.e. one that can talk directly to the hardware and thus runs at the lowest possible level for the OS) has to be written to the exact specifications of the kernel. An OS kernel can't swing both ways--a 32bit kernel can only have pure 32bit extensions and a 64bit kernel can only have pure 64bit extensions, since memory mapping differs between the two architectures.

Software, on the other hand, is fine, as any modern OS does not allow regular old executable programs to run in kernel-mode (that would be quite a security/stability risk). They run in user-mode and can only make calls to the APIs of the OS kernel, which then speaks to the hardware and returns things to the programs. In user-mode, OS developers have come up with all sorts of funky ways to allow 32bit code and 64bit code to coexist.

 

[mkrishnan]

The problem, as Vista demonstrated, is many devices will not get new drivers ever. [...] That is considered part of the job in device driver work.

This is exactly the problem with these kinds of transitions. Both of these statements are quite correct. It is the job in device driver programming, and the vendor responsibility, and it will not get done in many cases....

 

[wrldwzrd89]

This is exactly the problem with these kinds of transitions. Both of these statements are quite correct. It is the job in device driver programming, and the vendor responsibility, and it will not get done in many cases....

^^ Yes, unfortunately device drivers are different than regular software when it comes to things like CPU architecture. Basically, any kernel-mode driver (i.e. one that can talk directly to the hardware and thus runs at the lowest possible level for the OS) has to be written to the exact specifications of the kernel. An OS kernel can't swing both ways--a 32bit kernel can only have pure 32bit extensions and a 64bit kernel can only have pure 64bit extensions, since memory mapping differs between the two architectures.

Software, on the other hand, is fine, as any modern OS does not allow regular old executable programs to run in kernel-mode (that would be quite a security/stability risk). They run in user-mode and can only make calls to the APIs of the OS kernel, which then speaks to the hardware and returns things to the programs. In user-mode, OS developers have come up with all sorts of funky ways to allow 32bit code and 64bit code to coexist.

You are completely wrong. Every driver needs major changes to deal with 64-bit pointers in all OS data structures, in DMA control+bus control, etc. The problem, as Vista demonstrated, is many devices will not get new drivers ever.

Device drivers are, by definition, not platform independent. The development environment issues are not usually a problem. That is considered part of the job in device driver work.

Thanks, all of you. You explained exactly what I wasn't aware of. That said, I do hope the printer and MFD manufacturers release new drivers for their current models, at the very least, for Snow Leopard... otherwise us users will be in a big bind.

 

[Riemann Zeta]

^^ Printers are always the kiss of death when it comes to driver support. Printer manufactures suck at releasing updated drivers or novel OS drivers in a timely manner. Since they release so many new models per year and usually charge more for the ink/toner than the printer itself, they just hope that you will buy a new model. I hope that Mac OS already treats all of its printer drivers as user-mode, rather than kernel-mode drivers, otherwise we are entering a (temporary) no-print zone with pure 64bit OS 10.6. Vista will not install any kind of (NT5-era) kernel-mode print driver and Vista x64 is very picky about its printer drivers in general.

Realistically, there is no reason why a printer would need a kernel-mode driver. Printing has got to be the lowest priority, least important OS subsystem in terms of performance, so why does a printer need to directly touch the hardware? For the most important real-time critical subsystems like graphic rendering (either OpenGL or Direct3D), it is easy to see why kernel-mode performance is required; but printing?

 

[Tallest Skil]

^^ Printers are always the kiss of death when it comes to driver support. Printer manufactures suck at releasing updated drivers or novel OS drivers in a timely manner.

Or HAVING drivers. The supposedly web-based SyncThru service of Samsung's doesn't even work on my computer, and so I can't set up an ad-hoc Wi-Fi network over which to print, and therefore can't print at all.

"Just use USB..." You think I haven't tried it? It doesn't work.

 

[jf8]

OS X doesn't seem to use kernel mode printer drivers.

First. Windows 7 is nothing but a framework as current. The framework for OS 10 has been in continuous development for a decade now.

Windows NT has been in continuous development since the early 90s. The recently released Beta 1 of Windows 7 is supposed to be feature complete, although apparently not all features have been revealed / are enabled...