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 stubthat calls the
_xcselect_invoke_xcrun
functionin 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.