Edward Thomson

Engadget has an article on how to remove the Windows BSOD icon in 10.5. They seem to think that removing it is a good idea - since it's "so pompous and galling".

I call shenanigans. Pompous? Maybe. Galling? Give me a break.

It's true, Microsoft would never do something like this. Mostly because Microsoft cares precious little about interoperability with other network filesystems. CIFS is good enough for everybody - how's that for smug?

I suggest ignoring the whiners and embracing the BSOD icon. And then take it a step further: install xscreensaver and use the BSOD screensaver. Then smile when people tell you "there's something wrong with your computer!"

Since I'm travelling more often, Internet service can be unreliable. Sometimes I need to get network access while I'm on the road, or maybe I just need to lookup a phone number or an address but don't want to pay the sometimes exorbitant access fees at a hotel.

Fortunately, I've got a Bluetooth enabled cell phone from Cingular. Its GPRS capabilities mean that I can use it as a Bluetooth modem on my new MacBook^[1]. It makes for an interesting trade-off between an (admittedly, painfully) slow connection and the convenience of not trying to find a coffee shop with open wireless.

The setup required a lot of trial and error, and I'd forgotten most of it since I made this work on my old PowerBook. Once you get it down, though, it's really easy, so I thought I'd share it in case it's useful to someone else^[2]:

If you have a GPRS-capable phone:

1. Get on a data plan from your cell phone provider. My initial plan with Cingular had no data service, and I couldn't make any data connection (even on pay-per-byte.) Check the plan carefully - a few years ago, it was cheaper to go on the Cingular's pay-per-byte plan than even their "best deal" of a plan. I suspect this has been changed by now.
2. Download the Motorola GPRS modem scripts from Ross Barkman's page. Make sure you get the GPRS scripts, as GSM and GPRS aren't compatible. (But see below if you only have GSM.)
3. Drop the scripts into /Library/Modem Scripts
4. If you haven't already, Bond with your Bluetooth modem: make your phone discoverable, go to the Bluetooth Setup Assistant and enter the various magic to bond your phone with your computer.
5. Open up your Network Preferences, select your Bluetooth modem, and click Configure.
6. Here's the trial and error part. You'll need to enter these settings for PPP:
     Account Name:   ISPDA@CINGULARGPRS.COM
     Password:   CINGULAR1
     Telephone Number:   WAP.CINGULAR
7. Now, pop over to the Bluetooth Modem tab and set Modem to "Motorola GPRS CID1".

--- www.l.google.com ping statistics ---
27 packets transmitted, 25 packets received, 7% packet loss
round-trip min/avg/max/stddev = 601.630/916.474/1683.816/261.931 ms

Hey, I warned you that it was painful.

If you're lucky enough to have GPRS service - this used to be called "Internet Express Data Connect" - then change the username to "ISP.CINGULAR", and you'll get upgraded to nearly a whopping 128kb/s.

If you have problems with this, it's possible your plan (or your phone) is GSM-only. Expect still slower speeds - a whopping 14.4kb/s that will make you think you're living in 1991 all over again. And you'll need to change a few things around:

1. Download the GSM scripts from Ross Barkman's page instead. Install them in /Library/Modem Scripts.
2. In PPP settings, change your phone number to "*99#".
3. In your Bluetooth Modem tab, set your Modem to "Motorola GSM V.110 14.4k" ^[3].

So, there it is. Enjoy your ridiculously stone-age slow internet access from the side of the road!

1. Whee - a new MacBook Pro! I was excited about ditching my aging PowerBook, but I was worried about it being powerful enough to replace my PowerMac. No sweat - this thing is fast.
2. And, admittedly, because my memory's bad and I don't want to have to hunt down the modem scripts and go through the trial and error yet again.
3. Yes, 14.4k. It's like 1991 all over again.

I'm proud to note that Teamprise 1.1 was released this morning, which adds support for NTLM2 authentication, fixes several small bugs and is released for Mac OS X as a Universal Binary.

NTLM2 is a challenge-response authentication system that is frequently used by IIS (and thus, Team Foundation Server) installs for additional security above HTTP Basic authentication^[1]. We released Teamprise 1.0 without support for NTLM2 authentication (we supported the older LM style) because Microsoft has not openly published the specification for NTLM2, and we believed that most TFS installations would not need it -- those worried about security would opt for SSL and encrypt the entire transport, not just the authentication^[2].

Unfortunately, enabling NTLM2 in Team Foundation Server - and disabling other authentication methods - seems like a win with no drawbacks, and most administrators went ahead with it. We quickly realized that Teamprise needed support for NTLM2.

Fortunately, the Samba team^[3] has documented much of the work they've done in reverse engineering of NTLMSSP^[4] for CIFS, and the Apache HTTPClient team has implemented LM authentication over HTTP. Between these two, we got a good head start, and the powerful protocol analyzer Ethereal helped us with the trial and error to figure out the rest, and we are very pleased to support NTLM2 in Teamprise 1.1.

Further additions to Teamprise 1.1 include Universal Binary support for Mac OS X -- another feature I'm very pleased with. As the Mac guy, I was a bit embarassed to release Teamprise 1.0 with PPC-only support, even though we delivered Intel Mac binaries to beta testers. Fortunately, all went well, and we're releasing Teamprise 1.1 as a Universal Binary. I believe this brings the Mac version onto a level playing field with Windows and Linux.

Teamprise 1.1 is not a critical update for those that are happily using Teamprise 1.0, but if you've been waiting on evaluating Teamprise until NTLM2 support was available, or if you're using Teamprise 1.0 on an Intel Mac, Teamprise 1.1 is a nice little release we think you'll be very happy with.

1. Note that HTTP Digest is at least equally secure -- and presumably more so, since the NTLM2 specification is closed and has not been formally peer reviewed.
2. If you are that worried about security, it is still recommended that you use SSL -- using NTLM2 alone leaves precious data flying across the wire in cleartext.
3. Special thanks to Christopher Hertel for his work on NTLMSSP
4. The terminology gets a bit hairy here, especially with the commonality in names. LM, NTLM and NTLM2 are all crypto-based authentication protocols, while NTLMSSP is the definition of the message protocol that delivers them. Ie, you receive an NTLM challenge in an NTLMSSP message, you then send your NTLM response in an NTLMSSP message.

I've previously mentioned that SWT-based Java apps need some work to run on Intel Macs. This is still true if you're building against Eclipse 3.1.

Fortunately, it's dead simple - all you need to do is download the Universal Eclipse 3.1.2 (available as an attachment to Bug 98889) and copy some of its files into your app.

First, you need the JAR containing the architecture-specific SWT jnilib. Assuming Eclipse is unpacked into /Applications/Eclipse, and you're in your app's .app folder:

If you're building an RCP-based app, you should update the Eclipse launcher, too -- otherwise Rosetta will drag along and you'll have a several second delay when starting your app. Thanks to the simplicity of the launcher - which determines class loading based on the name it's called by - you can just copy the Univeral Eclipse launcher onto your app's launcher. Assuming you're in your .app folder, and your app is called MyRCPApp:

There it is -- zip this up and you've got a Universal app. (Or better yet, update your 3.1.2 delta pack so your build process does this automatically) and you've got a Universal build.

(Sorry if this seems elementary or obvious -- I was feeling bad about not having updated my blog recently, and I thought an easy entry would kickstart me into writing more!)

Teamprise and Microsoft Team Foundation Server users can now access their source code control directly from the TextMate editor.

TextMate is a popular developer-oriented text editor for Mac OS X. It's particularly popular in the interpreted language camps due to its light weight, high configurability and out-of-the-box support for many languages. Rightly so - it's a great programming text editor, and I've been using it anytime I don't need the full featureset of an IDE like Eclipse.

My only complaint with TextMate was that I constantly had to flip between my editor window and Teamprise Explorer so that I could check out and check in files.

TextMate ships with support for source control repositories in the form of Subversion and CVS. This is nice - but I need to check in to a TFS server. No problem! Thanks to TextMate's configurable architecture, I was able to roll my own interface to Teamprise in the form of a command "bundle."

The TextMate support for Teamprise went surprisingly smoothly. Using the Subversion and CVS bundles as a guide, I had a working prototype using the Teamprise command line client in just a bit over an hour. After that, I went back in to add a few features and polish the checkin functionality using a helpful utility included in the Subversion bundle. Now major features are supported -- add, delete, check out, check in, view history, undo changes, etc.

You can download this bundle at http://people.teamprise.com/~ethomson/teamprise/textmate/.

I'll admit, it's no stellar piece of engineering, and there are surely bugs. This was one of those little utilities born of necessity. That said, I hope the other Mac-based TFS users find some utility with it.

Of course, you will need a copy of the Teamprise Command Line Client and a Teamprise client license. This is not officially supported by Teamprise.

Apple had the "Switch" campaign. Maybe you remember -- some famous, not so famous, and soon-to-be-famous^[1] people talking about how their Macs are so much better than their PCs.

And a Mac is much better than your PC^[2]. Yes, this sounds like religious fanboy zealotry -- and to be fair, it is -- but that doesn't mean I'm necessarily wrong. At home, I use Windows approximately never^[3], and I've relegated Linux solely to my servers. Macs "just work" so often, and so well, that I'd rather just use my computer than spend all my time maintaining it.

There are already scores of religious fanboy zealots who are going to tell you - in great detail - how great the Mac is, and why you should switch. I'm not going to. I'll let them convince you. But beware. Just because the Mac is an excellent computer, that doesn't mean it's panacea. Here are some things you're going to want to pay attention to as you switch:

• Get a new keyboard. Somehow, the Apple USB keyboard gets worse with each new revision. It's mushy, click-negative, the key travel feels really short and they break easily^[4]. I particularly like the old IBM keyboards which "make it sound like the world's ending" when you type in your passphrase. Unicomp owns the IBM/Lexmark keyboard patents now, and recently delivered a Mac-friendly USB model of their 104 key stiff buckling-spring keyboard.

  Caveats: you lose the keys that control volume, brightness, and eject, so you'll want to add them to the menu bar. You'll also want to go into the Keyboard Preferences and swap Option and Command because the default keymapping for non-Apple keyboards is backward.

• Get an old mouse.
  Two years ago, that annoying one button mouse would have been at the top of my "replace this immediately" list. One button!? That's two less than there should be! It might have been cute in System 7, where you only needed one button but it's impossible in OS X.

  The mighty mouse is better -- in fact, I like the scroll "ball" a lot - it's a great feature. But the one-piece top makes it hard to get a positive click ("was that the left or right button, dammit!?") and if you're trying to go cord-free, their wireless mouse is still just one button. One day Apple will realize that most computer users have more than one usable digit on their dominant hand, and finally make a mouse that is both usable and meets their exacting aesthetic criteria for releasing a pointing rodent. Until then, just keep your existing mouse.

• Ditch Safari. Quickly.
  All the Mac users are going to tell you how great Safari is. What they actually mean is "it's really great compared to Internet Explorer." What they neglect to mention is that next to Firefox, it's sort of a pile of poo. On paper, it looks great - it's got all the modernities like tabs, RSS, popup blocking. And I could forgive the schizoid Apple UI. But I can't forgive The Beachball. When you've got a lot of pages open, it drags. Even on a dual G5 with 4GB of RAM. Open up a bunch of pages. Open another -- while that page is loading, raise a different Safari window. Beachball. Open a few links off a page in new tabs, then try to raise one of those tabs. Beachball. The whole app is blocking for seconds at a time. And God help you if you try to go to a poorly designed page. The dreaded foodtv.com's Flash search box kills Safari for a full minute, even with nothing else going on.

  The best thing going for Safari is its ability to download Camino which is Mozilla's rendering engine wrapped up in a more Mac-like UI, and the add-on CamiTools, which lets you tweak Camino quite a bit.

• Ditch iChat, too.
  If you ever use any sort of Instant Messaging, iChat will seem great. Rather, if you use AIM, iChat will seem great. Eventually, you'll want to talk over some other protocol, and you'll start looking for the multiprotocol plugins. Don't bother, by this point you've already outgrown it. Just download Adium instead. It's a free, multi-protocol instant messaging client built on GAIM.

• And Apple Mail?
  You're on your own with this one. Apple Mail in 10.4 works pretty well, but still has some big annoyances. (You will submit to the Global Inbox. You will restructure your IMAP folders to suit its needs. You will wait for its pokey IMAP implementation.) But it integrates well with the other Apple apps (notably Address Book.) I used to hate it, and used Thunderbird instead. Lately it's been growing on me. You'll have to make up your own mind.

• Don't expect to be able to compile anything yourself.
  So you like that pretty little shell, huh? This really is one of the big advantages to OS X - it's BSD under the hood. You're going to love that, right up until the time you want to run some little utility that was disappointingly not included with the OS X core. (Which is most.) At that point you're going to try to compile it yourself. I pity the fool.

  Despite the fact that you're back in 1990 with regard to tracking down and building dependencies yourself, and managing conflicting system libraries, you're going to be lucky if the software compiles out of the box. For example, I was trying to build an app that included a file called String.h. It also did #include <string> to include the system string library. It took about an hour for my sluggish brain to realize that HFS+ is case insensitive, and those would be the same file.

  Fortunately, there are several package management tools for OS X, meaning someone's taken care of making sure that libfreetype (and its dependencies) build cleanly and easily. Unfortunately, there are several package management tools... that is, the effort is split and lots of work is duplicated. There's DarwinPorts, which is based on FreeBSD's port system, Fink, which is based on Debian's apt system, and Portage, which is based on Gentoo's package management of the same name. I've tried them all, and I believe DarwinPorts sucks the least^[5]. But then, that's not saying much.

• Install Xcode and X11.
  If you're a developer or coming from a Unix background, you'll need them or want them eventually. Downloading Xcode takes hours, and Apple doesn't distribute X11 on anything but your install CD^[6]. Just install them when you get your machine, otherwise you'll be cursing up a storm when you actually need them.

• Your computer has amnesia.
  It will forget its name. Rather, it will trust some random DHCP server to set its hostname for it. So, next time you're in a coffee shop, suddenly your computer went from whatever cute name you have for it^[7] to shop-dhcp-4224 and that's no good. Edit /etc/hostconfig and add the line:

  HOSTNAME=yourcutehostname.domain.com

  After that, it will ignore that DHCP server that thinks it knows better.

• If you're a graphic designer, wait.
  Don't make the switch (at least to an Intel Mac) if you rely heavily on Adobe Creative Suite. Yes, they work in Rosetta, and yes, those Core Duos are fast. But CS2 runs slow as hell on an Intel Mac thanks to Adobe's stubborn insistence that they don't need to pay attention to Apple's roadmap.

  It still runs great on a G4 desktop, but do you really want to invest in a technology that's about to be replaced by the Bigger Better Deal?

• Get a wireless card
  If you get a PowerBook or a MacBook Pro, your wireless signal is going to suck. The antenna is housed in Aluminum. You might as well build a faraday cage around your laptop for all the signal you're going to get. That's not to say that it won't work -- it will. Just not well. I carry around a 802.11 PC Card in my bag and use OrangeWare's Wireless Drivers for Mac to get some extra signal in a pinch, like when I'm in an airport, a hotel room, or the room across the hall from my access point at home.
  

Of course, there are going to be some things that are going to piss you off that you have no control over:

• Apple's schizoid UI Is it a normal window? Is it polished metal? Who knows! Some programs in iLife (but not iWork) use the polished metal theme, some use the normal Mac theme. There's no distinction as to which one is used, and third-party developers are free to use either (or worse, both.) Personally, I'm not a big fan of the polished metal theme, but either way: Apple should pick a theme and run with it. To my knowledge, there's no simple way to get around this one.

• You will not play games.
  At least not any fancy games written in the last few years, like Quake I or Wolfenstein 3D. There might be a Minesweeper somewhere. No, seriously, it's not that bad, the studios do eventually release a Mac version of their games. And it sometimes works, mostly. I got into SimCity 4 for a little while (when it was released for OS X -- long after the Windows users were already tired of it) and it had big problems with my PowerBook's graphics card. Tearing everywhere. They released a patch which improved the situation, but didn't fix it entirely. Meh. I guess that's why I've got a Super Nintendo.

• The other Mac users.
  You'll have to adjust to the idea that you're joining a userbase of raving zealots^[8], who believe that Steve Jobs is the Second Coming. It will annoy the hell out of you at first, and you'll say things like "yeah, but I'm not like the other Mac users." I used to say those things. Eventually, you'll become an Apple apologist, too.
  

Hopefully you're not scared away by now. Sure, it's got its issues, but what OS doesn't? I could write a book about the annoyances of using Windows XP^[9] or Linux on a desktop. But with a few little tweaks, my Macs just work.

1. Yes, that's an Ellen Feiss reference. Beep beep beep.
2. I'm talking about for your home, not for work. But don't get too sure -- the religious fanboy zealots are coming for your office computer next.
3. The computer in my bedroom doubles as a TV. If Apple puts a tuner in a Mac Mini and makes Front Row talk to it, I'm ditching that PC too.
4. The last keyboard Apple shipped me worked for two days before the USB stopped working.
5. This coming from a guy who is still in love with Debian's apt system. I really wanted to like fink, but it's immature and incomplete. You'll really be happier with DarwinPorts, especially if you're going to develop software that links against these libraries. It's not at all painful to develop a build script that uses DarwinPorts to build redistributable packages. But that's another article.
6. I did see an unofficial download page for X11.app, but I tend not to trust third parties unless I knew the MD5 signature of the original. And then we're back to needing the install CD again...
7. I suggest comic characters. In fact, I'm writing this on tankgirl right now, and saving it to thetick. Spoon!
8. Unless you're switching from Linux, in which case you're already used to it.
9. I was going to suggest that Windows might be better now than when I used it day-to-day, but then I remembered that it's still the same version!^[10] Hah! In the time Windows XP has been out, OS X has gone from 10.0 to 10.5.
10. I know, some day Vista will ship, and it'll finally start to look like OS 10.2. Some day...

Since Teamprise is a front-end to Microsoft software, and it's cross-platform, it stands to reason that I'd need a Windows box to poke around with from time to time. And since VirtualPC is so painfully slow on my G5, I decided to make Boot Camp run on the iMac.

I've got to say: installation of Windows with Boot Camp was painless. Really, aside from the 39 minute^[1] installation of XP, the whole process took just a few minutes. Dynamically resizing HFS+ partitions while they're mounted? Absolutely awesome!

XP hums on this baby. So much nicer than VirtualPC.

Update: After my initial success, I got cocky. I resized my HFS+ partition again, to make room for Linux. I wanted it to triple-boot OS X, XP and Ubuntu. The Ubuntu will only run in text mode (the assumption about the refresh rate for the LCD is wrong), but it does run. Everything installs fine - seemingly - until it tries to run elilo to update the bootloader. Then things were very unhappy. Strangely, Windows crapped out at the same time^[2], so now I have neither Windows nor Ubuntu working. OS X, of course, still rocks. So I'm off to reinstall Windows^[3] again.

1. Why do all Windows installations take 39 minutes? Rather, why do all Windows installations claim they're going to take 39 minutes? Why 39? They might as well have just said 42, at least that would have been funny.
2. Unknown if elilo twiddled something with Windows, or if the two are unrelated.
3. That's right, another "39" minutes...

While Teamprise officially supports Mac OS X (PPC), it will come as a disappointment to the rest of the mac zealots out there that the Teamprise Client Suite is not officially supported in OS X for x86. If I were reading about a product release in April 2006, and it included OS X PPC support but no OS X Intel support, I'd start wondering. After all, it's April 2006! Apple's shipping three machines with Intel chips, and the developer box has been available for nearly a year! Apple says making Universal applications is trivial, you just check another box in XCode! So why no Intel support?

Well, it's not always as trivial as checking another box - and leaving Intel support out of 1.0 was actually a trivial decision.

Remember that the Teamprise Client Suite is composed of three applications:

• Teamprise Plugin for Eclipse
  A plugin for Eclipse and Eclipse-based IDEs which provides access to Microsoft Team Foundation Server version control and work item tracking. Being an Eclipse plugin, this code is written in Java using SWT for its UI.
  
• Teamprise Explorer
  A standalone application for cross-platform access to Microsoft Team Foundation Server. Explorer is an Rich Client Platform application - since all the code necessary to access TFS exists in the plugin, along with a whole bunch of dialogs and UI code, it would be silly to rewrite that. Thus, Explorer is a Java app using SWT for its UI.
  
• Teamprise Command Line Client
  An emulation of Microsoft's TFS Command Line Client. Again, it uses the base of Teamprise, and so is written in Java.

But wait, you say - Java should be even more portable! The Intel Macs have Java 1.5 already installed. They should just be able to run that bytecode!

Ah, again, it's not that easy. See, we're not exactly 100% pure Java. We have some native functions to do some various things we can't do in Java. We'd also need to port these native functions to Intel. But this should take just a few minutes, right? Pass the -arch flags to gcc and you'll get a Universal library, right?

Yep, but there's still more. As I mentioned, we use SWT for our UI. It's basically a wrapper for native system calls. Where once Java apps were strange looking and slow, SWT writes directly to Carbon on OS X. The result is a real native-feeling^[1] application, and you should never know it was written in Java. SWT is great if you want to target a lot of platforms without having to think too much about it. Unless, of course, one of those platforms is OS X on Intel.

See, when Eclipse 3.1 was released, there were no Intel Macs. Eclipse 3.2 will support them when it's released this year. Until then, there is no official version of SWT and RCP for Intel Macs. We could have, a few months ago, made a big plunge and dumped Eclipse 3.1 in favor of one of the milestones of Eclipse 3.2 and gotten support for Intel Macs, but we'd be building against a prerelease for the platform we rely upon. It was clearly too big a risk to make a jump that big, that late in the development cycle.

So what's to be done? What if you've got a shiny new MacBook Pro, you're running Eclipse 3.2M6, and you want to access a Team Foundation Server?

Well, it's not as dire as it may have sounded -- first, all our native code is already Universal, so if you happen to have an Intel Mac, both the Command Line Client and the Plugin will run. (The Command Line Client has no dependencies on SWT or RCP, and the Plugin will use your version of Eclipse's SWT.) I've done simple testing on my iMac and I can verify that both the Command Line Client and Plugin run and pass simple tests. Please note, however, that this was a stopgap solution for Intel Mac users, and has not been thoroughly tested. It is not officially supported by Teamprise.

That just leaves Teamprise Explorer. And I'll tell you what - if you need Explorer for Intel Macs, send an email to feedback@teamprise.com, and we'll build a copy just for you. (Again, not officially supported.)

Hey, it's still better than what you'll get out of Adobe.

1. To be fair, SWT feels very native, but still has a few UI quirks, particularly for the Mac. But that's another article.