Windows 8-bit 256 color palette

Some people like to say the internet is forever. Unfortunately, it’s not. I recently needed to track down a 256 color Windows system palettes from the Windows 95/98 era. In less than 20 years, the internet has all but forgotten what the color palette might have been.

This is my best attempt at reconstructing it from various pieces of information I was able to find around the web. This is a true-to-color gif image, so the color values haven’t been corrupted by downsampling.

The actual color values can be downloaded here.

256 color 8-bit Windows system palette

JAVA Diamond Square Generator

For a proof-of-concept GLSL shader I’ve been working on, I needed a random Diamond Square texture as input; a little bit of work yielded me this JAVA applet, which I then was able to easily fine-tune for my needs: Source Code: (Download)

Magic Triangle w/Kerberos in OS X 10.6

I was recently handed the task of integrating Mac OS X 10.6 into our so-called Magic Triangle authentication environment. To make things more interesting, Macs here are treated as UNIX workstations, and thus not bound to AD.

A quick search on Google yielded a long discussion on Kerberos support (or not) in Mac OS X 10.6 on RedHat Engineer Vincent Danen’s blog, and eventually to a his Wiki discussing Kerberos on Mac OS X

I’ll summarize the relevant tips here:

  • /etc/krb5.conf is /Library/Preferences/ on Mac OS X
  • /System/Library/LaunchAgents/ should use -R instead of -B (to auto-renew tickets)

Thanks to Apple’s support of Open Source, I was able to check out the source code for the module that they use in OS X 10.6. With this, I was enable to enable debugging in a custom application and determine how to get authentication working.

Apple has some additional tips here:

Distributing a single screen saver for 10.4, 10.5 and 10.6

In an earlier post, I discussed some Xcode settings that would simplify creating a Universal Binary screensaver that would run on all three versions of Mac OS X. Since that post, I’ve run into some problems and had some feedback, and discovered additional possible problems and solutions.

First off, there are a confusing number of settings related to architecture and SDK selection:

    Settings in the pop-up in the upper-left of the Xcode window:

  • Active SDK – affects the -isysroot argument to gcc
  • Active Architecture – affects the -arch argument to gcc
  • *above ONLY if the “Build Active Architecture Only” box is Unchecked in the Project Info
  • Settings in the Project Info, under the Build tab

  • Base SDK (SDKROOT variable)
  • Mac OS X Deployment Target (MACOSX_DEPLOYMENT_TARGET)

Further, within your code, you may reference the following two macros:


Through reading Apple’s documentation and a process of trial and error, I have come to the following conclusions:

  • MAC_OS_X_VERSION_MIN_REQUIRED is based on MACOSX_DEPLOYMENT_TARGET, and is the minimum version of OS X which you can expect your code to run on. This is generally based on the Base SDK setting above.
  • MAC_OS_X_VERSION_MAX_ALLOWED is the latest version of the Mac OS X API that you code uses native APIs from. This is generally based on the Mac OS X Deployment Target setting above, unless the Active SDK setting is less than the Mac OS X Deployment Target.
  • Because of the above side-effect, it seems the best practice is to leave the Active SDK setting to the latest version of the Mac OS X SDK your program will run on, regardless of architecture.
  • APIs between MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will be weak linked.
  • For more complete documentation, read up on Apple’s Technote TN2064

Here’s an example of the settings that I now use:

MAIL FROM vs From vs Sender – exploiting SPF

After 10 years of managing computer networks, I still learn something new almost every day. This week I inadvertently discovered that there were many more ways of “identifying” the sender of an e-mail that I had ever known (or in this case, of spoofing the sender an an e-mail).

Despite having multiple layers of SPAM protection, including strict SPF records and advanced content filtering, a particular set of SPAM was cleanly passing every layer of protection – this set of spam claimed, no less, to have originated internally (Clearly, this was not the case).

So, here’s how mail is identified:

A) MAIL FROM: (Also known as the envelope address)
B) Mail headers:
B1) From: (Generally what you see in your mail client)
B2) Sender:
B3) Reply-To: (Hitting “Reply” will usually go to this address)
B4) Resent-From:
B5) Resent-Sender:
B6) Resent-Reply-To:

The SPF specifications look explicitly at the envelope address; which is rarely ever seen by more than the e-mail relays. So, some clever spammer has been sending out a deluge of e-mail with forged mail headers that all match our own e-mail domain, but sending a different identity in the MAIL FROM – which conveniently passed SPF with flying colors. The e-mail client then looked at the forged headers, which contained our own (white listed) domain. The rest is history.

… or was, until I added a few lines of code to our mimedefang-filter. Any e-mails with headers claiming to be sent from our own domain are now cross-checked against the MAIL FROM:. If the domains don’t match; poof, the message is silently discarded.