<p>Kid: Mr. Sackett schedules his course so that Salem Witch Trials time perfectly with Halloween!</p><p>Me: Sure, that&#39;s easy for a history teacher. But I do the same in a *CS* course!</p><p>Can you guess the topic? (In PL, GC would be a natural fit; but this is in accelerated intro.)</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> isn&#39;t that sort of how they implemented Win32 on top of Win16 for windows 95. and Win16 on top of Win32 for NT. and Win32 on top of Win64 for 64-bit Windows</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> &quot;I think it would be really funny if you could generate stub libraries for msvcrt and then link your Linux software against it&quot;</p><p>I would consider using this.</p><p>I think the real galaxy brain would be something for Windows that can link a PE with a static/dynamic lib while converting between the multiple incompatible Windows C++ calling conventions. But that might require a level of dynamism not actually possible in PE world.</p>

<p>PROBLEM:</p><p>CATHERINE: by the way something that I think would be really cool is a dynamic linker that can automatically thunk between calling conventions, like Win32 stdcall and SysV. I think it would be really funny if you could generate stub libraries for msvcrt and then link your Linux software against it. I want to see Busybox run on top of ntdll.dll</p>

<p>PROBLEM: Python packaging</p><p>SOLUTION: once you do all of the steps above it reduces to an existing, solved problem</p>

<p>PROBLEM: writing portable interposition payloads is challenging due to the nature of the pre-load environment they operate in, and the esoteric knowledge required to write them in assembly</p><p>SOLUTION: design a Rust harness compiling down to a #![no_core], #![no_builtins] crate needing only a minimal amount of reusable assembly code, and that can be built, deployed, and interposed with minimal effort</p>

<p>PROBLEM: modifying the linking and loading characteristics of binaries is difficult, and doesn&#39;t necessarily get easier with builds from source</p><p>SOLUTION: design and implement a binary-to-binary compiler (like a conceptual inverse of a source-to-source compiler) that provides a rich array of transformations through the use of an intermediate representation that yields itself to composition of operations</p>

<p>PROBLEM: although Linux intentionally limits the amount of ELF program headers to 1024, a different (possibly untentional) limit puts a hard cap at around 300 PT_LOADs, if you want the kernel to not stamp your binaries with -ENOEXEC despite not even asking your PT_INTERP</p><p>SOLUTION: by interposing a pre-linker before the program interpreter takes over, any amount of loadable segments can be mapped by the kernel as a single PT_LOAD and then split into appropriately protected regions before linking</p>

<p>I just invented what I describe as &quot;fractal dynamic linking&quot;</p>