WWDC 2006 Predictions
It's the weekend before WWDC, so it must time for brazen predictions. Without futher ado:
Resolution Independence
I think this is pretty much a given. They've been hinting about this for years, and lcd screens are getting so cheap these days that the manufacturers will be looking for a new differentiator. I suspect lots and lots of apps will have to be modified to not look like crap with this, however -- it is so very hard to resist doing slightly janky things to make your apps purty. But for the sake of resolution independence we will have to accept a certain amount of fuzziness on low resolution displays.
New View Technologies
Brent Simmons is on record saying there won't be any major View changes in Leopard. While he's probably right (Resolution Independence alone is going to rock the boat enough), I wouldn't be at all surprised if there were more. The current programmatic drawing paradigm is starting the get really clunky. In the olden days, calls to drawing routines wrote directly into the framebuffer, or into an offscreen buffer which was then copied to the framebuffer. Nowadays, a graphics context usually keeps a log of all the drawing requests and replays it against the framebuffer every 60th of a second, or so. This is why asking for the current color of a given pixel is such a no-no -- to answer the query the OS has to wait until the stored log has been played against the framebuffer. This will instantly halve your framerate.
But this logging business is a little silly. It provides backwards compatibility, but forces us to send a bunch of drawing commands to the graphics card 60 times a second. Now that graphics cards are advanced enough to run simple programs that process polygon vertexes and pixels, why not specify your view as one of these programs? The view would be written in something like quartz composer and would be parameterized by thing like a bounds rect, content value, elapsed time parameter, etc. Then in your drawing code, rather than actually drawing the gradients and images you need, you would send the appropriate parameter values to the shading language program on the graphics card.
This is good, because it lets the GPU do the things it is designed for (getting a pixel color from the framebuffer to the GPU is usually a lot faster than getting it from the framebuffer to the CPU) and leaves the CPU to do things that require a more expressive environment (like layout and control tracking). Decoupling the actual drawing from the main program also makes it easier to try to send output to a remote screen, a la NXHost.
Well, one can hope, right?
64-bit UI Apps
I expect Leopard to support 64-bit UI apps. In six months probably every Mac shipping will have a 64-bit processor -- for marketing reasons alone it makes sense for Leopard to support 64-bit user applications. Still, there are big disadvantages to going to 64-bit. RAM usage of many applications will nearly double because the amount of RAM needed to store a pointer will double. Storage requirements for the OS could possibly quadruple: there would need to be separate binaries for ppc, ppc64, i386, and x64 (or whatever it is called). Ouch. It is enough of a pain that I wonder if it is worth it to support ppc64 at all. (But if they didn't, then no machine any developer had would be able to run the 64-bit parts of the Leopard Preview when it was released). Since ppc32 code can run unmodified in 64-bit processes, they might use some thunking tricks to get ppc32 code to call ppc64 libraries, but what's the point? They need the ppc32 code for all the G4's running out there. Unfortunately, I think were looking at multi-disc installs again.
Hypervisor
I think, unfortunately, we are entering the era where commercial OS developers will use hypervisors to support their DRM schemes. Hypervisors are also good for providing virtual machines to run multiple operating systems, so maybe this feature will be the sugar used to coat the bitter pill. All of the shipped x86 Macs have hardware support for hypervisors (except perhaps the developer preview machines) and PPC is inherently virtualizable, so it would be possible to do this. If Apple does place a hypervisor underneath OS X, we can be reasonably certain it will be closed source.
With Open Source Darwin?
Call me an optimist, but I think Leopard's version of xnu will be open source. My guess is that during the x86 death march someone decided it wasn't worth it to gussy up the x86 xnu under Tiger for open source release. It is also possible there is proprietary code in the x86 kernel that Apple doesn't have rights to release, but I have a hard time believing that code couldn't, in the long term, be factored out into a closed source KEXT. We'll find out on Monday, I guess.
An End to SIMBLs, haxies, mach_inject, etc.
On x86 Tiger is is getting harder and harder to inspect other processes, even ones you own. Prohibiting code injection makes it harder for trojans and viruses to propagate themselves, makes it easier for Apple to protect their DRM, and makes hacks of serial code verifiers much more difficult. If this doesn't come in Leopard, it will come sometime soon. At the very least, I expect application developers (with possible user override) to designate their apps protected from injection. Of course apps that allow plugins would have to implement some kind of code signing so they would know what plugins to trust -- that's what the Trusted Platform Module is for, right? Expect howls of outrage if this actually happens. I'm not sure the increased security is worth the hassle. But then we haven't had a real MacOS X virus outbreak. Yet.
A happy medium would be to ask the user the first time something tries to inject code into a particular application. This way unsanity could still exist.
Better integration between Xcode and Interface Builder
Now that we finally have good filesystem event notification, I think its time for Interface Builder to notice when I add actions and outlets to my headers in Xcode. It really pisses me off to have to do this manually. There are good reasons to keep IB and Xcode decoupled, but for small developers, at least, increased integration would be a major timesaver. Hopefully they'll also make it easier to use my custom views and cells in IB. This would make a big difference in ease of prototyping.
Wish List
I'll refrain from enumerating my wishes, since doing so virtually guarantees that they won't come true. Maybe after the keynote I'll put up a bitch list about what we didn't get.