In the MicroUI example here, there are buttons and text labels and other kinds of controls, but no ability for an outside process to enumerate or interact with the controls. Any program will just set a single giant window with no text and no controls inside. Accessibility software can still hook text output APIs, but not if it also uses custom font rendering.

Anyway, the Windows accessibility API is just implementing a few COM objects, and COM (other than the specific ABI used for storing the vtable and function call convention) is not necessarily specific to Win32.

Before Vista, there were two rects, the Window Rect (which included the title bar, menu bar, and the resize border), and the Client Rect, which includes the work area of the window.

Once Vista came around, Window Rects became completely different. After a window becomes shown, the Window Rect expands outwards (around 8 pixels or so) to include a drop shadow and larger resize area. So it's no longer just Window Rect and Client Rect, now there's a third rect called the DWM Extended Frame Bounds, and that corresponds to what the Window Rect used to be on earlier versions of Windows.

To try to make things more compatible, the Window Rect will behave like older versions of windows before the window is shown, and there is no way to access DWM Extended Frame Bounds before a window is shown. But once a window is shown, your Window Rect is bigger now, and in a different location. Programs that try to move the window will instead move it to a location 8 pixels down-right of the target location. Programs that try to resize the window will instead make it 16 pixels too narrow and short. If a program tried to remember the difference between the Client Rect and Window Rect, suddenly that number changed just because the window got shown.

So newer programs need to ask for the DWM Extended Frame Bounds to get an idea of where their window actually is. And it also happens that DWM Extended Frame Bounds are not DPI adjusted, but the Window Rect and Client Rect are. So you need to DPI adjust it into a coordinate system which matches the Window Rect. Now you finally have your three rects, and can properly place a window somewhere on the screen.

Embedding a public random number also doesn't resist tampering, unlike signed timestamps.

The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.

The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)

Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.