Exercise 2: Why Windows Uses CALL, Not a SYSCALL-Style Instruction — Possible Solution
====================================================================

WHAT'S FUNDAMENTALLY DIFFERENT
------------------------------
Per this chapter's own explanation, Linux exposes a STABLE, DOCUMENTED,
directly-invokable syscall interface — a fixed set of syscall numbers
and a dedicated instruction (SYSCALL) that an assembly program is
explicitly permitted, and expected, to use directly to ask the kernel
for services. Windows takes the opposite position: its own internal
syscall numbers and mechanisms are treated as PRIVATE implementation
detail, explicitly not guaranteed to stay the same between versions
or even routine updates. Windows never intended for application code
to invoke its internal syscalls directly at all.

WHY THIS MEANS AN ORDINARY CALL, NOT A SYSCALL-STYLE INSTRUCTION
------------------------------
Since Windows doesn't offer a stable direct syscall contract for
applications to target, the only STABLE thing an application can
actually rely on is the Windows API itself — ordinary functions
(like WriteFile or ExitProcess) exposed through system DLLs such as
kernel32.dll. Per this chapter's own explanation, those functions
internally make whatever the real, unstable syscalls happen to be on
that particular Windows version, but the application itself never
needs to know or touch those internal details — it just calls the
DLL function like any other ordinary function, using assembly2-5's
own Microsoft x64 calling convention (an ordinary CALL instruction,
not a syscall-style instruction), because that's the actual stable
boundary Windows guarantees.

THE ROOT DIFFERENCE
------------------------------
Linux treats "the syscall interface itself" as the stable public
contract application code targets directly. Windows treats "the
Windows API function surface" as the stable public contract, with the
real internal syscalls hidden and free to change underneath it. A
CALL instruction is simply how you invoke an ordinary function — and
on Windows, the Windows API functions ARE the intended, sanctioned
way to reach OS services, so an ordinary function-call instruction is
exactly the right tool, with no separate syscall-style instruction
needed or provided for applications at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
It identifies the specific difference in what each OS treats as its
own STABLE public contract (the syscall interface itself vs. the DLL
function surface), and explains why that difference in what's
"safe to target directly" is exactly what determines whether a
program uses a syscall-style instruction or an ordinary function call.