Web Excursions 2021-08-29

Watching Windows 95 running until a glorious death; why Xcode tools are slow after reboot.


Windows 95 Crash Stream - YouTube

Windows 95 can only run for 49.7 days before crashing, and I've had a win95 box slowly counting up until that date. Here's the final couple hours, complete with some MIDI tunes played on a Roland SC-55.

@foone on Twitter: Because Windows 95 stores the time since boot as milliseconds, in an unsigned 32bit integer. after 49.7 days, that number overflows to 0, and the machine hangs.

Watch Windows 95 crash live as it exceeds 49.7 days uptime [video] | Hacker News

hyperrail:

  • Microsoft used to release a "checked" build for each version of Windows on MSDN/Visual Studio Subscription downloads.

  • This was a build with the same compiler optimization settings as the release build,

    • but with debug-build-only assertions and checks included.

    • In the checked build kernel, the system uptime had 49 days artificially added to it

    • precisely to help developers find out problems like this.

krylon:

  • Having used Windows 95 back in the day, I am deeply impressed someone managed to keep it from crashing for so long.


Why Xcode tools are slow after reboot

  • The /usr/bin/git executable on macOS is just a stub

    • that calls the _xcselect_invoke_xcrun function

    • in the /usr/lib/libxcselect.dylib library,

    • which you can see by using the /usr/bin/otool command-line tool —

      • which coincidentally is also just a stub

      • that calls the _xcselect_invoke_xcrun function.

  • By the way, if you're looking for /usr/lib/libxcselect.dylib on disk you may not find it, because Big Sur.

  • The actual tools are inside the Xcode app bundle:

$ xcrun --find git /Applications/Xcode.app/Contents/Developer/usr/bin/git 
  • When you attempt to run one of the developer tools, the _xcselect_invoke_xcrun function must look up the actual path of the tool.

    • The paths of Xcode and the developer tools are cached on disk in a database file named xcrun_db located in your $TMPDIR.

    • (In Terminal, call echo $TMPDIR to see the temporary directory path.)

  • the first time you run a developer tool after reboot, the xcrun_db cache needs to be regenerated.

  • after reboot, the process syspolicyd went crazy and used almost 100% CPU until the command [to locate the devtool] finished.

    • seemed to be spending a lot of time in the security framework checking code signing.

    • this is different to the situation where syspolicyd acts as the culprit in checking notarization of unsigned executables

      • syspolicyd does not even attempt any network connections in this case

      • the tools in /usr/bin/ and Xcode itself are signed

  • A way to accelerate: disable System Integrity Protection. Seriously, that works.