1. 11
  1. 5

    Storing data inside an executable is a great and underused technique. I’m not sure it’s entirely practical to do it with often-changing data like a blog, but I’m guessing this was more of a for-fun project.

    This reminds me that early in Mac OS X development, circa 1999, there was internal debate whether to package applications as directories-that-look-like-files (bundles) as in NeXT, or as single files as in classic MacOS. The OpenStep (Cocoa) convention was to access app resources as individual files in the app directory, which argued for keeping the bundle design, but the people on the Carbon side didn’t like the bloat that implied.

    There was (I heard) a prototype that embedded the OpenStep-style resource directory in the app’s executable as a Zip (or tar?) archive. At launch time they mounted a virtual filesystem on it and pointed the OpenStep API at that as its Resources directory. It worked, but it got vetoed because it slowed down app launch too much.

    I always wished they’d gone that route but implemented the virtual zip filesystem at a higher level that didn’t require work by the kernel/filesystem. Almost all access to Cocoa resources goes through a few methods in NSData, NSString, NSFileManager, so it probably wouldn’t have taken a ton of work. And it would probably have sped up launch times by eliminating the need to open and close a bunch of file descriptors.

    (Not that I could have done anything about it. I was still on the Java team at the time, and I hadn’t even learned Obj-C or OpenStep/Cocoa yet.)

    1. 2

      OpenStep was (is) a great programming environment, indeed. Admittedly, zb is (if you don’t like to use CI tools) a rather impractical tool for writing a dozen new entries a day, but for low-activity websites, it can be useful, I guess.

      Other than that, it was mostly for fun.