jsOS

Sistema operacional experimental · x86-64 · v0.6.0

Um kernel em JavaScript que carrega drivers reais do Windows.

O jsOS inicia direto no hardware virtual, sem outro sistema por baixo, e usa o QuickJS como motor do kernel. Os subsistemas do Windows NT, como objetos, I/O, memória, processos, Registro e segurança, são escritos em JavaScript. O progresso é medido com binários originais da Microsoft, como ntdll.dll, kernel32.dll, kbdclass.sys e cng.sys.

Ver o que já roda Como funciona

Estado em 12/10/2026 O DriverEntry de um driver proprietário de terceiros, de codinome Kyo, retornou sucesso no jsOS. O serviço de usuário que acompanha esse driver ainda não roda por completo.

Experimental operating system · x86-64 · v0.6.0

A JavaScript kernel that loads real Windows drivers.

jsOS boots straight on virtual hardware, with no other operating system underneath, and uses QuickJS as its kernel engine. The Windows NT subsystems, such as objects, I/O, memory, processes, the Registry and security, are written in JavaScript. Progress is measured with original Microsoft binaries such as ntdll.dll, kernel32.dll, kbdclass.sys and cng.sys.

See what runs How it works

Status on Oct 12, 2026 The DriverEntry of a third-party proprietary driver, codenamed Kyo, returned success on jsOS. The user-mode service that comes with that driver does not fully run yet.

COM1 · log serial do bootCOM1 · boot serial log12/10/2026 · trecho real, abreviadoOct 12, 2026 · real excerpt, abridged · kernel messages in Portuguese 
BEAPKGL6[jsOS] kernel 64-bit vivo (BIOS real mode -> long mode)
HELLO_KERNEL_OK
[boot] fase 0: nanokernel + objetos + registry
[clock] TSC = 3200.1 MHz
[irq] IDT carregada; LAPIC timer 100Hz + IRQ1 teclado
[mm] PFN: 352256 frames (1376 MB), 3 E820 ranges
[smp] CPUs na MADT: 4 (BSP apicId=0, APs=3)
[smp] CPU 1 online (apicId=1)
[smp] CPU 2 online (apicId=2)
[smp] CPU 3 online (apicId=3)
[boot] fase 1: I/O manager + drivers + servicos
[boot] NTFS montado em D:
[driver] echo.sys: DriverEntry (WDK real, compilado com MSVC)
...
KERNEL_JS_OK
[usermode] ntdll.dll real (NTFS) em 0x180000000 (2434 exports, 473 syscalls mapeados)
[usermode] entrando em ring 3: usertest.exe entry 0x140001000 pilha 0x7ffffffff8
jsOS ring 3: syscall real OK
[usermode] usertest.exe saiu: codigo 0x42
USERMODE_OK
  • 789exports no PE do kernelexports in the kernel PE
  • ≈152 mil≈152klinhas de JavaScript no kernellines of JavaScript in the kernel
  • 4 CPUsonline no QEMU com WHPXonline in QEMU with WHPX
  • 0x00000000retorno do DriverEntry do Kyoreturn value of Kyo's DriverEntry

Como funciona

A CPU só executa código de máquina. Por isso o jsOS tem uma camada fina em C e Assembly para o boot, as interrupções, a troca de privilégio e o motor QuickJS. Acima dela, o sistema é JavaScript, organizado como a árvore de código do Windows NT: ob, io, mm, ke, ps, cm e se. Os termos técnicos estão explicados no glossário, no fim da página.

  1. Binários originais do Windows

    ntdll.dll, kernel32.dll e kernelbase.dll em ring 3. cng.sys, ci.dll, kbdclass.sys e i8042prt.sys em ring 0. Vêm da instalação local do Windows e não fazem parte do jsOS.

    • PE x64
    • ring 0 e 3
  2. O sistema em JavaScript

    Object Manager, I/O e PnP, memória, processos e threads, Registro, segurança, ALPC, NTFS, loader PE e os exports do ntoskrnl.

    • JavaScript
    • ≈152 mil linhas
  3. Motor e primitivas

    O QuickJS roda dentro do kernel. As primitivas os.* são a única porta do JavaScript para portas de I/O, memória física, MSRs e CPUID.

    • C
    • QuickJS
  4. Transições nativas

    IRQs e exceções, conversão da ABI Microsoft x64, SYSCALL/SYSRET e o contexto salvo de cada thread.

    • C e Assembly
  5. Boot

    Setor de boot e stage2: modo real, mapa E820, A20, GDT, leitura do disco por ATA, paginação e long mode.

    • Assembly
  6. Máquina virtual

    QEMU com TCG ou WHPX, 4 GiB de RAM, quatro CPUs e um segundo disco com NTFS.

    • QEMU

Uma chamada de driver, passo a passo

  1. Um driver .sys chama IoCreateDevice.

  2. No carregamento, o loader PE do jsOS ligou esse import à entrada 128 da tabela de trampolins.

  3. O trampolim converte a chamada da ABI Microsoft x64 e entra no motor em C.

  4. O C entrega a chamada a Ntoskrnl.handle, em JavaScript.

  5. O handler cria o DEVICE_OBJECT na memória do convidado, com o layout x64 do WDK, e devolve um NTSTATUS.

Programas de usuário seguem o loader real da ntdll: LdrInitializeThunk → NtContinue → RtlUserThreadStart → entrada do programa. As chamadas de sistema voltam ao kernel por SYSCALL/SYSRET e são atendidas em JavaScript.

COM1 · carga do echo.systrecho real 
[pe] imports de ntoskrnl.exe
[pe]   DbgPrint -> api #32
[pe]   IofCompleteRequest -> api #135
[pe]   IoCreateDevice -> api #128
[pe]   IoCreateSymbolicLink -> api #129
[pe]   RtlInitUnicodeString -> api #348
[pe] entry point = 0x1121000
[driver] echo.sys: DriverEntry (WDK real, compilado com MSVC)
[driver] echo.sys: PNP START_DEVICE

How it works

A CPU only runs machine code. That is why jsOS keeps a thin layer of C and Assembly for booting, interrupts, privilege switches and the QuickJS engine. Above it, the system is JavaScript, organized like the Windows NT source tree: ob, io, mm, ke, ps, cm and se. Technical terms are explained in the glossary at the end of the page.

  1. Original Windows binaries

    ntdll.dll, kernel32.dll and kernelbase.dll in ring 3. cng.sys, ci.dll, kbdclass.sys and i8042prt.sys in ring 0. They come from the local Windows installation and are not part of jsOS.

    • PE x64
    • ring 0 and 3
  2. The system in JavaScript

    Object Manager, I/O and PnP, memory, processes and threads, the Registry, security, ALPC, NTFS, the PE loader and the ntoskrnl exports.

    • JavaScript
    • ≈152k lines
  3. Engine and primitives

    QuickJS runs inside the kernel. The os.* primitives are JavaScript's only door to I/O ports, physical memory, MSRs and CPUID.

    • C
    • QuickJS
  4. Native transitions

    IRQs and exceptions, conversion from the Microsoft x64 ABI, SYSCALL/SYSRET and each thread's saved context.

    • C and Assembly
  5. Boot

    Boot sector and stage2: real mode, the E820 memory map, A20, GDT, disk reads over ATA, paging and long mode.

    • Assembly
  6. Virtual machine

    QEMU with TCG or WHPX, 4 GiB of RAM, four CPUs and a second disk with NTFS.

    • QEMU

A driver call, step by step

  1. A .sys driver calls IoCreateDevice.

  2. At load time, the jsOS PE loader bound that import to entry 128 of the trampoline table.

  3. The trampoline converts the call from the Microsoft x64 ABI and enters the C engine.

  4. The C code hands the call to Ntoskrnl.handle, in JavaScript.

  5. The handler builds the DEVICE_OBJECT in guest memory, with the WDK x64 layout, and returns an NTSTATUS.

User programs go through the real ntdll loader: LdrInitializeThunk → NtContinue → RtlUserThreadStart → program entry point. System calls come back into the kernel through SYSCALL/SYSRET and are handled in JavaScript.

COM1 · loading echo.sysreal excerpt 
[pe] imports de ntoskrnl.exe
[pe]   DbgPrint -> api #32
[pe]   IofCompleteRequest -> api #135
[pe]   IoCreateDevice -> api #128
[pe]   IoCreateSymbolicLink -> api #129
[pe]   RtlInitUnicodeString -> api #348
[pe] entry point = 0x1121000
[driver] echo.sys: DriverEntry (WDK real, compilado com MSVC)
[driver] echo.sys: PNP START_DEVICE

O que já roda

Cada item tem uma prova: o marcador que o teste espera no log serial ou o resultado registrado na execução. O selo indica se o recurso está comprovado, parcial ou em andamento.

  • Comprovado

    Boot próprio e várias CPUs

    O setor de boot e o stage2, em Assembly, levam a CPU do modo real ao long mode. O kernel lê a tabela MADT da ACPI, acorda os outros núcleos com INIT-SIPI-SIPI e entrega trabalho nativo a cada um. 

    [smp] CPUs na MADT: 4 (BSP apicId=0, APs=3)
  • Parcial

    Subsistemas do NT em JavaScript

    Object Manager com handles e referências, I/O Manager com IRPs e PnP, Memory Manager com PFN, PTEs e seções, eventos, timers e DPCs, Registro, tokens e ALPC. A compatibilidade completa ainda está em desenvolvimento. 

    KERNEL_JS_OK
  • Comprovado

    Teclado com drivers da Microsoft

    O i8042prt.sys e o kbdclass.sys originais carregam pela pilha PnP e ligam a ISR à IRQ1. O teste injeta uma tecla pelo QEMU, e o MakeCode 0x1E percorre ISR, DPC e callback até a leitura do kbdclass, o mesmo caminho que alimenta o shell. 

    KBDTEST_OK
  • Comprovado

    Programas em ring 3 com DLLs reais

    A ntdll.dll original inicia o processo, e as chamadas de sistema chegam ao kernel por SYSCALL/SYSRET. Os testes em C usam heap, arquivos, threads, TLS, SEH, Registro e CryptoAPI pelas DLLs da Microsoft. 

    WIN32_RUNTIME_OK
  • Parcial

    NTFS com leitura e escrita

    MFT, runlists, índices B-tree e bitmaps, com gravação até o disco ATA. Os testes conferem os dados depois de fechar e remontar o volume. Ainda faltam journal, ACLs e expansão da MFT. 

    [boot] NTFS montado em D:
  • Comprovado

    Serviços e o comando sc

    A base de serviços fica no Registro, e o protocolo SCMR passa por ALPC/LRPC com sechost.dll e rpcrt4.dll reais. No shell, o sc cria, inicia e para drivers e serviços pelo carregador real. 

    SERVICE_NATIVE_DISPATCH_START_STOP_OK
  • Comprovado

    Code Integrity original

    A ci.dll da Microsoft inicializa suas fases e valida a assinatura do driver Kyo com nível 8. Uma cópia com um único byte alterado é rejeitada. 

    CiValidateImageHeader = 0 (nível 8)
  • Em andamento

    Kyo: driver e serviço

    Kyo é o codinome de um driver proprietário de terceiros e do serviço de usuário que o acompanha. O driver passa pela CI, e o DriverEntry retorna sucesso depois de 12.532 chamadas de API, 176 s após o início do QEMU. O serviço e a comunicação entre os dois ainda não funcionam. 

    DriverEntry = 0x00000000

Como ler as provas

Os testes iniciam o jsOS no QEMU e esperam marcadores no log serial (COM1). Estes são os principais.

Marcador Significa que
BEAPKGL6 o stage2 avançou do modo real até o long mode
HELLO_KERNEL_OK o host em C está vivo
KERNEL_JS_OK o kernel em JavaScript foi montado e está executando
USERMODE_OK o programa de teste voltou do ring 3 com o código esperado
WIN32_RUNTIME_OK os testes com KERNEL32 e KERNELBASE reais passaram
SELFTEST_OK o autoteste do kernel passou
KBDTEST_OK uma tecla atravessou a pilha nativa de teclado

What already runs

Each item has proof: the marker the test expects in the serial log, or the result recorded during the run. The badge shows whether the feature is proven, partial or in progress.

  • Proven

    Own boot and multiple CPUs

    The boot sector and stage2, in Assembly, take the CPU from real mode to long mode. The kernel reads the ACPI MADT table, wakes the other cores with INIT-SIPI-SIPI and hands native work to each of them. 

    [smp] CPUs na MADT: 4 (BSP apicId=0, APs=3)
  • Partial

    NT subsystems in JavaScript

    Object Manager with handles and references, I/O Manager with IRPs and PnP, Memory Manager with PFN, PTEs and sections, events, timers and DPCs, the Registry, tokens and ALPC. Full compatibility is still in development. 

    KERNEL_JS_OK
  • Proven

    Keyboard with Microsoft drivers

    The original i8042prt.sys and kbdclass.sys load through the PnP stack and connect their ISR to IRQ1. The test injects a key through QEMU, and MakeCode 0x1E travels through the ISR, the DPC and the callback up to the kbdclass read, the same path that feeds the shell. 

    KBDTEST_OK
  • Proven

    Ring 3 programs with real DLLs

    The original ntdll.dll starts the process, and system calls reach the kernel through SYSCALL/SYSRET. The C tests use the heap, files, threads, TLS, SEH, the Registry and CryptoAPI through Microsoft's DLLs. 

    WIN32_RUNTIME_OK
  • Partial

    NTFS with reads and writes

    MFT, runlists, B-tree indexes and bitmaps, with writes all the way to the ATA disk. The tests check the data after closing and remounting the volume. Journal, ACLs and MFT growth are still missing. 

    [boot] NTFS montado em D:
  • Proven

    Services and the sc command

    The service database lives in the Registry, and the SCMR protocol runs over ALPC/LRPC with the real sechost.dll and rpcrt4.dll. In the shell, sc creates, starts and stops drivers and services through the real loader. 

    SERVICE_NATIVE_DISPATCH_START_STOP_OK
  • Proven

    Original Code Integrity

    Microsoft's ci.dll initializes its phases and validates the Kyo driver's signature at level 8. A copy with a single altered byte is rejected. 

    CiValidateImageHeader = 0 (level 8)
  • In progress

    Kyo: driver and service

    Kyo is the codename of a third-party proprietary driver and the user-mode service that comes with it. The driver passes CI, and DriverEntry returns success after 12,532 API calls, 176 s after QEMU starts. The service and the communication between the two do not work yet. 

    DriverEntry = 0x00000000

How to read the proofs

The tests start jsOS in QEMU and wait for markers in the serial log (COM1). These are the main ones.

Marker Means that
BEAPKGL6 stage2 went from real mode to long mode
HELLO_KERNEL_OK the C host is alive
KERNEL_JS_OK the JavaScript kernel is assembled and running
USERMODE_OK the test program came back from ring 3 with the expected code
WIN32_RUNTIME_OK the tests with the real KERNEL32 and KERNELBASE passed
SELFTEST_OK the kernel self-test passed
KBDTEST_OK a key went through the native keyboard stack

Na tela

O console escreve direto na memória de vídeo VGA, em 0xB8000, no modo texto de 80 colunas por 25 linhas. Depois do boot, o shell do jsOS espera comandos.

Tela preta do jsOS v0.3.0 em modo texto: kernel 100% JavaScript, bare metal x86-64, RAM de 127 MB e o prompt jsOS> esperando um comando.
Captura real da tela do jsOS v0.3.0, de agosto de 2026.

Comandos do shell

help, version
ajuda e versão do sistema
ls, cat, write, rm
arquivos do sistema de arquivos em memória
run, spawn, ps, kill
programas em JavaScript e processos
exec
executa um .exe do Windows (PE32+)
loaddriver
carrega um driver .sys
sc
consulta e controla serviços e drivers
objects
mostra o namespace do Object Manager
mem, selftest
uso de memória e autoteste do kernel
echo, clear, halt
texto, limpar a tela e desligar

On screen

The console writes straight into VGA video memory at 0xB8000, in 80×25 text mode. After boot, the jsOS shell waits for commands.

Black jsOS v0.3.0 text-mode screen: kernel 100% JavaScript, bare metal x86-64, 127 MB of RAM and the jsOS> prompt waiting for a command.
Real capture of the jsOS v0.3.0 screen, August 2026.

Shell commands

help, version
help and system version
ls, cat, write, rm
files in the in-memory file system
run, spawn, ps, kill
JavaScript programs and processes
exec
runs a Windows .exe (PE32+)
loaddriver
loads a .sys driver
sc
queries and controls services and drivers
objects
shows the Object Manager namespace
mem, selftest
memory usage and kernel self-test
echo, clear, halt
text, clear the screen and shut down

O que ainda falta

O projeto registra o que foi comprovado e o que ainda não foi. Estes são os limites atuais mais importantes.

  • Janelas e desenho: USER32, GDI32 e Win32k cobrem só a inicialização testada.
  • Um processo de usuário por vez, com CR3 compartilhado.
  • Sem XSTATE/AVX e sem crescimento de pilha por guard page.
  • NTFS sem journal, ACLs persistentes nem arquivos comprimidos ou esparsos.
  • O Registro fica só na RAM, então a configuração se perde ao reiniciar.
  • O motor JavaScript roda na CPU principal. As outras executam jobs nativos.
  • O código JavaScript ainda não é preemptado pelo timer.
  • O serviço de usuário do Kyo e a comunicação dele com o driver.
  • Nunca foi validado em hardware físico. O desenvolvimento usa o QEMU.

What is still missing

The project records what has been proven and what has not. These are the most important current limits.

  • Windows and drawing: USER32, GDI32 and Win32k cover only the tested initialization.
  • One user process at a time, with a shared CR3.
  • No XSTATE/AVX and no stack growth through guard pages.
  • NTFS without a journal, persistent ACLs, or compressed and sparse files.
  • The Registry lives only in RAM, so configuration is lost on reboot.
  • The JavaScript engine runs on the main CPU. The other CPUs run native jobs.
  • The timer does not preempt JavaScript code yet.
  • Kyo's user-mode service and its communication with the driver.
  • Never validated on physical hardware. Development uses QEMU.

Linha do tempo

Do primeiro commit ao DriverEntry do Kyo, segundo o histórico de desenvolvimento.

  1. Primeiro commit

    Boot próprio, QuickJS no kernel, loader PE e os primeiros drivers .sys com IRPs. No mesmo dia vieram Registro, DPCs, threads de kernel, Memory Manager, Power Manager e o início do SMP.

  2. Dispatcher, WDM e PCI

    Eventos, mutexes e timers com TSC, pilha de dispositivos WDM, barramento PCI em JavaScript e IRQ com preempção sob WHPX. O kbdclass.sys da Microsoft carrega.

  3. Teclado de verdade

    O i8042prt.sys e o kbdclass.sys entregam o scancode de ponta a ponta até o shell.

  4. Pilha de armazenamento

    atapi, ataport, disk, classpnp e mountmgr originais entram no boot. Dois dias depois, o atapi ficou em espera, e o disco voltou ao driver ATA em JavaScript.

  5. Runtime NT consolidado

    Processos em ring 3 com DLLs reais, NTFS com escrita, ALPC e serviços entram no projeto. O kernel passa a ter 729 exports.

  6. A CI original inicializa

    CiInitialize, CiInitializePolicy e CiInitializePhase2 retornam 0 com a ci.dll da Microsoft.

  7. CI no boot normal

    A validação de imagens passa a usar a CI real no boot normal, e o diagnóstico do Kyo passa para o backend WHP.

  8. Firmware e diagnóstico contínuo

    ExGetFirmwareEnvironmentVariable passa a usar o provedor de BIOS real, e o trace do Kyo continua depois do DriverEntry.

  9. DriverEntry = 0

    O driver Kyo retorna sucesso em 176 s no build principal, depois de 12.532 chamadas de API.

Timeline

From the first commit to Kyo's DriverEntry, according to the development history.

  1. First commit

    Own boot, QuickJS in the kernel, the PE loader and the first .sys drivers with IRPs. The same day brought the Registry, DPCs, kernel threads, the Memory Manager, the Power Manager and the start of SMP.

  2. Dispatcher, WDM and PCI

    Events, mutexes and TSC-based timers, the WDM device stack, a PCI bus in JavaScript and IRQ preemption under WHPX. Microsoft's kbdclass.sys loads.

  3. A real keyboard

    i8042prt.sys and kbdclass.sys deliver the scancode end to end, all the way to the shell.

  4. Storage stack

    The original atapi, ataport, disk, classpnp and mountmgr join the boot. Two days later, atapi was put on hold and the disk went back to the JavaScript ATA driver.

  5. NT runtime consolidated

    Ring 3 processes with real DLLs, NTFS writes, ALPC and services join the project. The kernel reaches 729 exports.

  6. The original CI initializes

    CiInitialize, CiInitializePolicy and CiInitializePhase2 return 0 with Microsoft's ci.dll.

  7. CI in the normal boot

    Image validation now uses the real CI in the normal boot, and Kyo's diagnostics move to the WHP backend.

  8. Firmware and continuous diagnostics

    ExGetFirmwareEnvironmentVariable now uses the real BIOS provider, and Kyo's trace continues after DriverEntry.

  9. DriverEntry = 0

    The Kyo driver returns success in 176 s on the main build, after 12,532 API calls.

Perguntas

É um emulador do Windows?

Não. Quem emula a máquina é o QEMU. O jsOS é o sistema operacional que roda nela: os binários do Windows executam direto na CPU virtual, e o jsOS atende as chamadas que eles fazem ao kernel.

Por que existe C e Assembly num sistema em JavaScript?

A CPU só executa código de máquina. O boot, as entradas de interrupção, a troca de nível de privilégio e o próprio QuickJS são nativos. Os gerenciadores do kernel, os drivers em JavaScript e o loader PE são JavaScript.

Ele roda qualquer programa do Windows?

Ainda não. Os testes cobrem contratos específicos com as DLLs originais. Não há janelas nem desenho, e só um processo de usuário roda por vez.

O código-fonte está disponível?

Não. O jsOS é um projeto pessoal de código fechado. Esta página mostra como ele funciona e o que já foi comprovado.

O que é o Kyo?

É o codinome de um driver proprietário de terceiros e do serviço que o acompanha, usados como o teste de compatibilidade mais exigente do kernel. O nome real não é divulgado, e os arquivos dele não são distribuídos.

O jsOS inclui arquivos do Windows?

Não. DLLs, drivers e tabelas NLS vêm da instalação local do Windows, no computador onde o jsOS é testado, e são copiados para o disco da máquina virtual na hora do build. Nada disso é distribuído.

Dá para rodar jogos?

Não. O jsOS não tem interface gráfica nem DirectX.

Funciona em um PC de verdade?

Ainda não foi validado em hardware físico. O desenvolvimento e os testes usam o QEMU no Windows 10 x64, com TCG ou WHPX.

FAQ

Is it a Windows emulator?

No. QEMU emulates the machine. jsOS is the operating system running on it: Windows binaries execute directly on the virtual CPU, and jsOS answers the calls they make to the kernel.

Why is there C and Assembly in a JavaScript system?

A CPU only runs machine code. The boot, the interrupt entry points, privilege-level switches and QuickJS itself are native. The kernel managers, the JavaScript drivers and the PE loader are JavaScript.

Does it run any Windows program?

Not yet. The tests cover specific contracts with the original DLLs. There are no windows or drawing, and only one user process runs at a time.

Is the source code available?

No. jsOS is a closed-source personal project. This page shows how it works and what has been proven.

What is Kyo?

The codename of a third-party proprietary driver and the service that comes with it, used as the kernel's most demanding compatibility test. The real name is not disclosed, and its files are not distributed.

Does jsOS include Windows files?

No. DLLs, drivers and NLS tables come from the local Windows installation on the test machine and are copied to the virtual machine's disk at build time. None of it is distributed.

Can it run games?

No. jsOS has no graphical interface and no DirectX.

Does it work on a real PC?

It has not been validated on physical hardware. Development and testing use QEMU on Windows 10 x64, with TCG or WHPX.

Glossário

Os termos técnicos que aparecem nesta página, em poucas palavras.

ACPI e MADT
Tabelas que o firmware entrega ao sistema para descrever o hardware. A MADT lista os processadores e os controladores de interrupção.
ALPC
Advanced Local Procedure Call. O mecanismo do NT para troca de mensagens entre processos, usado por serviços e por RPC.
CI (Code Integrity)
O componente do Windows (ci.dll) que confere a assinatura digital de drivers e programas antes de eles rodarem.
DPC
Deferred Procedure Call. Trabalho que uma interrupção agenda para rodar logo depois, num nível de prioridade (IRQL) mais baixo, para a interrupção terminar rápido.
DriverEntry
A função de entrada de um driver do Windows. O kernel a chama ao carregar o driver, e ela devolve um NTSTATUS.
IRP
I/O Request Packet. A estrutura que o I/O Manager envia aos drivers para cada pedido: abrir, ler, escrever ou controlar um dispositivo.
Log serial (COM1)
A saída de texto da porta serial da máquina virtual. Os testes leem esse log em busca dos marcadores.
Long mode
O modo de 64 bits dos processadores x86-64. O boot passa pelo modo real (16 bits) e pelo modo protegido (32 bits) antes de chegar nele.
ntdll.dll
A DLL mais baixa do modo usuário no Windows. Ela carrega os programas e faz as chamadas de sistema.
NTSTATUS
O código de resultado de 32 bits do kernel do Windows. 0x00000000 é STATUS_SUCCESS; valores que começam com 0xC indicam erro.
PE
Portable Executable. O formato dos arquivos .exe, .dll e .sys do Windows.
PFN e PTE
O banco de páginas físicas da memória (PFN) e as entradas da tabela de páginas (PTE), que ligam endereços virtuais a endereços físicos.
PnP
Plug and Play. A parte do kernel que descobre dispositivos, escolhe os drivers e entrega recursos como portas e interrupções.
QEMU, TCG e WHPX
QEMU é a máquina virtual onde o jsOS roda. No modo TCG, o QEMU emula a CPU por software; com o WHPX, usa a virtualização do processador pelo Windows Hypervisor Platform.
QuickJS
Um motor JavaScript pequeno, escrito em C. No jsOS, ele roda dentro do kernel.
Ring 0 e ring 3
Níveis de privilégio da CPU. Kernel e drivers rodam em ring 0; programas de usuário rodam em ring 3, sem acesso direto ao hardware.
SCM
Service Control Manager. O gerenciador que instala, inicia e para serviços e drivers no Windows.
SYSCALL/SYSRET
Instruções do x86-64 que levam um programa de usuário para dentro do kernel e de volta, numa chamada de sistema.

Glossary

The technical terms used on this page, in a few words.

ACPI and MADT
Tables the firmware hands to the system to describe the hardware. The MADT lists the processors and interrupt controllers.
ALPC
Advanced Local Procedure Call. The NT mechanism for passing messages between processes, used by services and RPC.
CI (Code Integrity)
The Windows component (ci.dll) that checks the digital signature of drivers and programs before they run.
COM1 serial log
Text output from the virtual machine's serial port. The tests read this log looking for markers.
DPC
Deferred Procedure Call. Work an interrupt schedules to run right after it, at a lower priority level (IRQL), so the interrupt can finish quickly.
DriverEntry
A Windows driver's entry function. The kernel calls it when loading the driver, and it returns an NTSTATUS.
IRP
I/O Request Packet. The structure the I/O Manager sends to drivers for each request: open, read, write or control a device.
Long mode
The 64-bit mode of x86-64 processors. The boot goes through real mode (16-bit) and protected mode (32-bit) before reaching it.
ntdll.dll
The lowest user-mode DLL on Windows. It loads programs and makes the system calls.
NTSTATUS
The 32-bit result code of the Windows kernel. 0x00000000 is STATUS_SUCCESS; values starting with 0xC are errors.
PE
Portable Executable. The file format of Windows .exe, .dll and .sys files.
PFN and PTE
The database of physical memory pages (PFN) and the page table entries (PTE) that map virtual addresses to physical ones.
PnP
Plug and Play. The part of the kernel that discovers devices, picks drivers and hands out resources such as ports and interrupts.
QEMU, TCG and WHPX
QEMU is the virtual machine jsOS runs in. In TCG mode, QEMU emulates the CPU in software; with WHPX, it uses the processor's virtualization through the Windows Hypervisor Platform.
QuickJS
A small JavaScript engine written in C. In jsOS, it runs inside the kernel.
Ring 0 and ring 3
CPU privilege levels. The kernel and drivers run in ring 0; user programs run in ring 3, without direct access to the hardware.
SCM
Service Control Manager. The manager that installs, starts and stops services and drivers on Windows.
SYSCALL/SYSRET
x86-64 instructions that take a user program into the kernel and back during a system call.