Languages: English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Français | Deutsch | Español | Italiano | Русский | العربية
CPU execution separates ISA admission, guest memory, backend transport and guest OS policy. NEVERD_ENABLE_CPU_EMULATION enables the x64/ARM64 CPU layer; NEVERD_ENABLE_DRIVER_EMULATION adds the bounded x64 Windows WDM/KMDF environment. The linux-elf64-v1 profile runs supported Linux ELF processes. See CPU execution, Guest process emulation and Windows driver emulation.
For supported native contracts, auto selects KVM on Linux, WHP on Windows or HVF on macOS, matching the guest ISA to the host. Cross-ISA execution uses Unicorn; software-cpu-v1 and the original V1 API retain software execution. An unavailable explicitly selected backend fails without fallback. Native execution checks admitted instructions, addresses and effects before entry. Host virtualization does not determine the guest OS: Darwin profiles separately model macOS, iOS and iOS Simulator. HVF needs the com.apple.security.hypervisor entitlement.
driver-strict / checked-x64-v1 covers bounded x64 execution; Windows driver loading remains x64. checked-aarch64-v1 and checked-user-aarch64-v1 include bounded ARM64 FP32/FP64, fixed-width SIMD and complete FPCR/FPSR/vector state. Native ARM64 HVF acceptance is recorded in the Mac guide; ARM64 KVM/WHP workload validation and complete Intel HVF acceptance remain pending. Supported CPU execution does not imply arbitrary driver or application compatibility.
windows-pe64-v1 supports bounded Windows x64/ARM64 console processes with PEB/TEB, static and dynamic TLS, DllMain, named Win32 APIs and explicit acyclic DLL graphs. Guest modules support named/ordinal code and data imports, DIR64 rebasing, forwarded exports and actual loader-list identities. LoadLibraryA / LoadLibraryW, FreeLibrary and GetProcAddress use the configured module catalogue. CRT/GUI, ARM64 frame-based user SEH, threads and general Windows application compatibility remain unfinished; native ARM64 KVM/WHP evidence is still pending.
WindowsSystemModules builds bounded PE64 model images for ntdll.dll, kernelbase.dll and kernel32.dll on both ISAs. Their mapped bases are shared by ASCII GetModuleHandleA / GetModuleHandleW, LoadLibraryA / LoadLibraryW and GetProcAddress; PEB/LDR and MEM_IMAGE describe those same images. Static imports, named queries and guest forwarders use the same API gates and export resolver. Providers stay pinned, have no guest initialization callbacks and do not prevent entry return after ordinary guest DLLs unload. Changed headers or export metadata stop lookup. Unknown system export names and nonzero system ordinal queries stop explicitly; case-only mismatches of modeled names and empty names return error 127, while a null query returns 87. Generated bytes and addresses are model policy; Windows DLL version layouts, native ordinals and cross-provider aliases are not reconstructed. WindowsSystemTests.cpp compares original x64/ARM64 executables with native Windows, including eight independent initial-thread returns.
GetEnvironmentVariableW, SetEnvironmentVariableW, GetEnvironmentStringsW, FreeEnvironmentStringsW, ExpandEnvironmentStringsW share the live guest environment block in PEB process parameters. Names are ASCII and case insensitive; values are UTF-16. Updates validate inputs, capacity and writable memory before publication. Snapshots remain independent after changes and release their guest backing on free. The block has a 64 KiB model limit; strings and expansions are bounded and check the workload deadline. Unknown pointer ownership, malformed blocks, ANSI code pages and overlapping expansion buffers remain unsupported. WindowsEnvironmentTests.cpp compares original x64/ARM64 fixtures across available backends and requires an independent native Windows oracle in CI.
WindowsProcessHeap now owns allocation, HeapReAlloc, free and size queries in one process heap. Resizing preserves the retained bytes; HEAP_ZERO_MEMORY clears newly exposed bytes, and HEAP_REALLOC_IN_PLACE_ONLY forbids movement. Failed resizing preserves the old block and returns NULL with ERROR_NOT_ENOUGH_MEMORY (8), matching the native observations. Separate page backing lets shrink/free return capacity, while staged growth and bounded copies observe the workload deadline. Custom heaps, exception-generating flags, unknown ownership and inaccessible copy/zero spans stop explicitly. WindowsHeapTests.cpp covers both ISAs, forced movement, budget reuse and failure atomicity; CI also runs the original EXE against native Windows.
Windows virtual memory adds VirtualAlloc, VirtualFree, VirtualProtect, VirtualQuery and current-process FlushInstructionCache. The OS layer owns reservations; AddressSpace remains the authority for committed pages, permissions and backing. Tests cover dynamic code rewriting, access faults and memory-budget reuse.
WindowsProcessExceptions implements AddVectoredExceptionHandler, RemoveVectoredExceptionHandler and RaiseException on one CPU with the process budget. Ordered handlers may register or remove handlers, raise nested exceptions, call modeled APIs, load DLLs and exit the process. x64/ARM64 data-access violations and x64 integer divide faults can resume after validated guest edits to CONTEXT; general registers, SIMD and supported FP state are preserved. Software exceptions resume through a real return instruction in the modeled provider. The model bounds registrations to 128 retained entries and nesting to 16 frames. Invalid dispositions, changed exception pointers, unsupported context fields and exhausted bounds fail explicitly. ARM64 frame-based SEH/unwinding, debugger delivery and execute/guard faults remain unsupported. WindowsExceptionTests.cpp compares original EXE/DLL scenarios against native Windows; native ARM64 KVM/WHP evidence remains pending. Software exception records carry EXCEPTION_SOFTWARE_ORIGINATE (0x80), independently of the caller’s noncontinuable flag; the original Windows executable checks the exact software and hardware flag values.
AddVectoredContinueHandler and RemoveVectoredContinueHandler maintain a separate ordered list, sharing the 128 retained registration limit with exception handlers. Continue callbacks run after a vectored exception handler accepts continuation; they see the same mutable exception record and CONTEXT. Final context validation happens after these callbacks, including nested exceptions and DLL notifications. Handles cannot be removed through the other handler family. WindowsContinuationTests.cpp compares original executables for ordering, short-circuiting, mutation, context repair, nested dispatch, loader callbacks and process exit against native Windows. The tested Windows x64 vectored path permits continuation with EXCEPTION_NONCONTINUABLE set; this does not establish frame-based SEH behavior. Native ARM64 execution remains unverified.
RtlCaptureContext is available through kernel32.dll and ntdll.dll for x64 and ARM64. Shared WindowsProcessContext and IntegerABI record the caller’s PC/SP without changing CPU state or LastError. Native Windows observations establish x64 flags 0x10000f, preservation of untouched home/debug/vector storage, and the legacy 32-bit x87 address fields; ARM64 records PC from LR and clears the saved X0/LR. Register values, SIMD and FP controls come from the guest; x64 selectors and the MXCSR capability mask follow the configured guest CPU. Invalid, unaligned or partly inaccessible destination records fail before publication. WindowsContextTests.cpp covers direct imports, provider lookup, VEH callbacks, cross-page output and failure atomicity. scripts/check_windows_context.py runs the original executable on Windows x64 and ARM64, with a separate native nonempty-x87 oracle. These ARM64 API observations do not establish native KVM/WHP execution. Context restore, stack walking and dynamic function tables remain separate work. WindowsProcessServices.def declares exact module restrictions: the modeled kernelbase.dll lookup returns ERROR_PROC_NOT_FOUND (127), matching native observations rather than creating an extra export. RtlCaptureContext.
WindowsProcessSEH uses shared X64SEH in os/windows/exception/ (NeverDEmulationWindowsException, available without drivers) for x64 __C_specific_handler and UNWIND_INFO V1. After VEH search it supports filters, finally callbacks, nonlocal handler transfer, nested/collided dispatch and rebased EXE/DLL frames, preserving nonvolatile GPR/XMM state. Filter continuation runs VCH with the same CONTEXT. WindowsSEHTests.cpp compares 23 original scenarios with native Windows; KVM/WHP/Unicorn share these semantics. Dispatch rechecks image generations, headers, unwind/scope bytes, personality code regions and IAT bindings under the process budget. Changed metadata or unloaded retained images fail explicitly. ARM64 frame SEH, C++ EH, dynamic function tables, general RtlUnwind/NtContinue, and unwinding across loader/VEH/VCH callback boundaries remain unsupported.
For EXCEPTION_NONCONTINUABLE, an x64 filter returning EXCEPTION_CONTINUE_EXECUTION dispatches STATUS_NONCONTINUABLE_EXCEPTION (0xc0000025, flags 0x81, null linked record) with a fresh context. VEH runs again before search restarts on the retained logical stack, preserving finally order and EXE/DLL frame identity under the same depth and execution budgets. The 23 native scenarios include 21 successful executions and two terminations: accepting this secondary exception in VEH/VCH remains unhandled even after restoring the original CONTEXT. The model reports that outcome as a runtime failure. Software exception addresses equal their saved PC; internal dispatcher addresses and register layout are model policy. Windows x64 CI.
Checked x64 now includes ordinary-RAM MOVS/STOS/LODS and CLD/STD, with per-element restart, cancellation and cross-page checks. CPU-specific zero-count upper-bit behavior and STOS/LODS device operands remain outside this contract.
Checked x64 also supports ordinary-RAM CMPS/SCAS with REPE/REPNE, including arithmetic flags, early termination, per-element stops and fault recovery. Device comparisons remain unsupported.
Native x64 and ARM64 startup probes validate bounded complete-state execution under an exclusive memory lease. XSAVE packets and ISA-aware page-table caches have one authoritative owner.
Native x64 FOP/FIP/FDP follow host save/restore rules: AMD may clear inactive x87 exception metadata. Startup probes validate these fields with a pending unmasked exception.