Solipsism Gradient

I’ve written about Apple’s use of the TPM chip before. My basic conclusion was, there’s no evidence Apple is using the chip for anything sinister, or at all in current versions (Tiger). However, I also said Apple should use the chip as a basis for secure vitualization in Leopard:

…Apple should write a fully trusted hypervisor into the EFI (using the TPM) and run everything inside virtual machines, including Mac OS X for Intel itself. Booting some version of Windows into a second VM would be easy, then, and there wouldn’t be a full version of Mac OS X for Intel for people to run on standard PCs either. I don’t think dual-booting is a good solution, I believe Apple was just testing the waters with BootCamp.

I still think virtualization is a good idea… however, there’s new evidence that Apple doesn’t think so, or at least not in conjunction with the TPM chip.

First, ifixit posted a disassembly of the new Core 2 Duo MacBook Pros, with zoomed-in photos of the logic board. They’re not detailed enough to show all IC part numbers, but I can say with some confidence that there’s no TPM chip at all. However, to the right of the RAM socket in the second picture, there’s an empty space for a 28-pin flat-pack IC – just the size of the Infineon SLB9635TT chip found on all previous Intel Macs. I’ve been searching for a similarly detailed picture of the Mac Pro’s motherboard, with no luck so far.

Second, Amit Singh of Mac OS X Internals fame – which I bought and read recently, BTW – has posted, in his usual precise style, details on how to use those Macs’ TPM chip. Here are some salient points:

The media has been discussing “Apple’s use of TPM” for a long time now. There have been numerous reports of system attackers bypassing “Apple’s TPM protection” and finding “Apple’s TPM keys.” Nevertheless, it is important to note that Apple does not use the TPM. If you have a TPM-equipped Macintosh computer, you can use the TPM for its intended purpose, with no side effect on the normal working of Mac OS X.

…

At the time of this writing (October 2006), the newest Apple computer models, such as the MacPro and the revised MacBook Pro do not contain an onboard TPM. Theoretically, Apple could bring the TPM back, perhaps, if there were enough interest (after all, it is increasingly common to find TPMs in current notebook computers), but that’s another story.

He then goes on with very detailed instructions on how to write, install and use a device driver for the TPM chip.

All this is very interesting, but as the TPM isn’t anymore standard equipment you could rely on finding on any Intel Mac, this is more an academic exercise. I doubt that Apple will implement anything important in Leopard that won’t run on the new Pro machines, so no trusted hypervisor for me. Ah well…

We’re also packing for yet another trip. If all goes well, we’ll be in Milano (Italy) early on Sunday, catch a train to Venezia, and from there start the first of two Mediterranean cruises. In between we’ll visit friends in Verona. Back around the end of November…

Of course, I’ll take my trusty laptop and plan to make excellent progress on the XRay II project. So stay tuned for developments.

Yet Another interim progress report on XRay II.

Turns out some of my problems with the hex editor were due to overuse of the idea to have my scrollview’s delegate do everything (including standing in for the First Responder). So I changed back to a simpler model. I now have a single view inside my scroll view as the delegate, and it stays in place – it just checks the scrollbar’s status to decide what to draw.

As this subview is declared as NSView<NSTextInput> – meaning it’s a plain subclass of NSView that obeys the NSTextInput protocol – it’s also a descendant of NSResponder, and now stuff started “just working”. Seems obvious in retrospect, of course. There’s lots of details about implementing that protocol, but it’s mostly working now; I’m still not doing any actual editing, but that’s the top item on my list of things to do next.

Several other issues are being worked on in the meantime. Many things are more complex than I anticipated, but I believe the final result will be worthwhile. The actual plugin interface is still mutating from day to day, mostly because the actual usage patterns are hard to anticipate. I have two plugins partially working: File Metadata and File Forks (which use the basic hex editor to do its work).

I’m now making a separate version of the main XRay II application to be used as the plugin developer base. This will be a stripped-down version of the application: it’ll run only the two basic plugins and a third one, the one being developed. It will also have some debugging infrastructure in place.

Next, I’ll use this to start up projects for at least two more, perhaps more, plugins of different types, both reusing basic UI elements from the main application. Hopefully this will give me enough variations to publish a rich but robust plugin interface. I envision stopping development on the main application as soon as possible – perhaps even this year, if all goes well – and doing all the rest inside plugins.

Autoresizing NSTextFields are now working quite well, except in one instance – when there are several of them stacked and the window is resized several times very rapidly. I’ve left this alone for now while tackling another problem: text editing. Let me explain this a little.

One of my basic UI elements is a fast hex editor view. Here’s what it looks like at present:

Three columns, hex displacement at the left, hex characters in the center, MacOSRoman (or any other encoding) to the right. All in a scrolling view. That’s where things began to get strange. For normal Cocoa use, you’d normally define an NSTextView inside an NSScrollView. The three columns might be done by NSTextBlocks, as this will be Tiger-only. Or three different NSTextContainers, each one referencing an aspect of the same NSTextStorage…

The main stumbling point here is, I want to be able to edit very large files with no performance penalty. Files tens of gigabytes in size or even larger. All the standard Cocoa text objects above are out; they use 32-bit offsets and ranges for text sizes and selections, meaning things are limited to 4GB (or even 2GB in some cases). Also, NSTextView becomes slow as molasses well before text sizes reach those magnitudes, as the entire text needs to be laid out first to determine line breaks. Also, RAM requirements to generate the hex interpretation go up – remember a standard Mac OS X app can allocate just a little over 2GB of RAM. Finally, NSScrollView uses floats to track the scroll thumb position, meaning that scroll tracking becomes imprecise when you’re trying to track millions of lines.

Well, my fate apparently is to recode most of the NeXT-era UI widgets anyway – see RBSplitView. I tackled the scroller problem first, as I needed it for the file browser anyway, and soon had a special scroll view that tracked scrolling positions with unsigned 64-bit displacements – large enough for the largest file supported by Mac OS X – and faster and simpler than the standard one. It basically consists of the vertical NSScroller and the empty (document) space to its left; no intervening NSClipView. Any subviews are relocated by the offset when the scroller changes and drawing is optimized to the visible portion.

I also put in the option to have the view’s delegate redraw the visible portion directly – this was the idea I had to optimize the hex editor. Indeed, drawing is very fast; I have my own cached CoreGraphics bitmaps of the characters, and blit them to the visible portion of the sscroll view. And only the necessary part of the displayed file needs to be accessed, thanks to mapping only that part to memory with mmap(). And putting in editing later would be easy once the display portion is finished…

Famous last words. Turns out that the Cocoa text system is rather more complex than I expected – the standard NSTextView/NSTextField objects hide that very successfully from the “normal” developer. After several days of reading the very terse docs, and trying to find out which methods are called where, I’m finally at a point where the normal text input methods are working. However, I still can’t figure out how the standard copy/cut/paste menu items are enabled, and the whole process is still too clunky for wider use.

Stay tuned for developments…

Jon Rentzsch’s C4 Conference, zeroth issue, is over. And by all accounts, a great success; wish I could have attended, but I’d already spent my conference credits on WWDC this year.

Maybe next year I’ll manage it, if I can attend something else important/interesting in the US before or afterwards. Meanwhile, here’s the best bit:

In most conferences, some folks will congregate in the hallways to hang out…

But with C4, I didn?t catch any conversations in the hallway. Olof said “The main room was the hallway. It was all hallway.”

Sounds good to me…

I’ll wait for the videos to become available, but I already know I’ll want to comment on John Gruber‘s talk.

Still on the subject of network backup devices, I hadn’t been to Tom’s Networking for quite some time, and their page on NAS devices is very informative. There are quite a number of new options coming out; well worth a visit.

So, I needed to autoresize NSTextFields in XRay II (vertically only). Sort of a poor man’s WebView. This had to “just work” on certain NSTextFields used by third-party plugins, though, without any extra code or subclassing by the plugin writer.

There are two problems there. One is finding out the actual optimum vertical size, while editing and while not, for any type of border or bezel. Here’s the code I finally worked out, with the kind help of Daniel Jalkut:

- (NSSize)minSizeForContent {
   NSRect frame = [self frame];
   NSRect newf = frame;
   NSTextView* editor = nil;
   if ((editor = (NSTextView*)[self currentEditor])) {
      newf = [[editor layoutManager] usedRectForTextContainer:[editor textContainer]];
      newf.size.height += frame.size.height-[[self cell] drawingRectForBounds:frame].size.height;
   } else {
      newf.size.height = HUGE_VALF;
      newf.size = [[self cell] cellSizeForBounds:newf];
   }
   frame.size.height = newf.size.height;
   return frame.size;
}

So I put this into a category of NSTextField and did some runtime diddling with implementation pointers, but for other uses it could well be in a subclass.

The second problem is properly pushing down the views below the field when it is resized. The solution I ended up coding is a little too gnarly to post here, and it depends on the field and its sibling views being inside a custom NSView subclass with flipped coordinates… still, it seems to work well enough now, so I’ll leave it there and work on other stuff.

Panasonic quickly followed with the Words Gear. 1024×600 pixels at 211 dpi, half the weight of the Sony Reader, and the form factor is like a paperback with 20mm sawed off the bottom. It has an SD card slot, which is a good idea, and the design looks better; however it seems to use a standard LCD screen instead of e-paper, which means lower battery life.