{"id":15047545,"url":"https://github.com/jxy-s/stlkrn","last_synced_at":"2025-09-02T11:06:28.430Z","repository":{"id":37322730,"uuid":"380637935","full_name":"jxy-s/stlkrn","owner":"jxy-s","description":"C++ STL in the Windows Kernel with C++ Exception Support","archived":false,"fork":false,"pushed_at":"2023-08-16T15:38:59.000Z","size":226,"stargazers_count":407,"open_issues_count":5,"forks_count":79,"subscribers_count":13,"default_branch":"main","last_synced_at":"2025-03-29T14:08:11.513Z","etag":null,"topics":["cpp","cpp-library","cpp-programming","cpp14","cpp14-library","cpp17","cpp17-library","cpp20","cpp20-library","kernel-driver","msvc","msvc-windows","msvcrt","msvcrtl","stl","stl-containers","windows-driver","windows-kernel"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jxy-s.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-06-27T02:55:41.000Z","updated_at":"2025-03-28T14:28:07.000Z","dependencies_parsed_at":"2024-12-22T10:10:53.326Z","dependency_job_id":"c8eed3ed-e29c-4034-90db-07fe3c1b9f7d","html_url":"https://github.com/jxy-s/stlkrn","commit_stats":{"total_commits":14,"total_committers":3,"mean_commits":4.666666666666667,"dds":0.2857142857142857,"last_synced_commit":"26af6fc495bb9ee322b8e0ae206a39004a5a7086"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jxy-s%2Fstlkrn","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jxy-s%2Fstlkrn/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jxy-s%2Fstlkrn/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jxy-s%2Fstlkrn/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jxy-s","download_url":"https://codeload.github.com/jxy-s/stlkrn/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247353731,"owners_count":20925329,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cpp","cpp-library","cpp-programming","cpp14","cpp14-library","cpp17","cpp17-library","cpp20","cpp20-library","kernel-driver","msvc","msvc-windows","msvcrt","msvcrtl","stl","stl-containers","windows-driver","windows-kernel"],"created_at":"2024-09-24T20:59:59.947Z","updated_at":"2025-04-05T15:05:34.622Z","avatar_url":"https://github.com/jxy-s.png","language":"C++","funding_links":[],"categories":["Other notes and common problems","C++"],"sub_categories":[],"readme":"# C++ STL in Windows Drivers \nThis project uses MSVC C++ STL in a Windows Kernel Driver. In this solution \n`jxystl.lib` is implemented as a kernel-tuned, pool type/tag aware, template \nlibrary and MSVC implementation. Which, under the hood, uses the MSVC C++ STL.\n\n```cpp\n#include \u003cwdm.h\u003e\n#include \u003cjxy/string.hpp\u003e\n\nextern \"C\"\nNTSTATUS DriverEntry(\n    PDRIVER_OBJECT DriverObject,\n    PUNICODE_STRING RegistryPath)\n{\n    jxy::wstring\u003cPagedPool, '0GAT'\u003e helloWorld;\n\n    try\n    {\n        helloWorld.assign(L\"Hello, World!\");\n    }\n    catch (const std::bad_alloc\u0026)\n    {\n        return STATUS_INSUFFICIENT_RESOURCES;\n    }\n\n    return STATUS_SUCCESS;\n}\n```\n\n```\n1: kd\u003e dv\n   DriverObject = 0xffffca83`5380d300 Driver \"\\Driver\\stlkrn\"\n   RegistryPath = 0xffffca83`5227f000 \"\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet001\\Services\\stlkrn\"\n     helloWorld = \"Hello, World!\"\n```\n\n## Supported Standards\n\n| Standard | Supported | Notes |\n| :------: | :-------: | ----- |\n| cpp11    | No        | untested, your milage my vary |\n| cpp14    | **Yes**   |       |\n| cpp17    | **Yes**   |       |\n| cpp20    | **Yes**   |       |\n\nThe test driver in this solution, `stdtest.sys`, houses the unit tests for the \nproject. Unit tests are run in the kernel with driver verifier. The unit test \nframework is bare bones but is sufficient for exercising `jxystl.lib`.\n\nAnother driver implemented in this solution, `stdkrn.sys`, puts `jxystl.lib` \nto use in a practical scenario. It uses various `std` namespace facilities and \ncontainers (wrapped under the `jxy` namespace). This driver registers for \nprocess, thread, and image notifications; then uses modern C++ to track \nprocess contexts, thread contexts, and module contexts.\n\n## Exception Handling - `vcrtl`\nException handling enables C++ objects to unwind when an exception is thrown.\nThis is a core feature of C++ which gets little attention for kernel drivers. \nMicrosoft does not natively support C++ exceptions for kernel drivers.\n\nC++ exception handling is made possible by [avakar's vcrtl libraray][github.vcrtl].\nThis project would have been far more work without avakar's awesome contribution. \nFor information on exception handling in Windows Drivers head over to \n[avakar's vcrtl github][github.vcrtl]. Also, [this page][github.vcrtl.x64] \ngives excellent details on exception handling on AMD64.\n\n## MSVC C++ STL Support - `jxystl`\nWindows Kernel allocations are associated with a memory pool. Further, pool \ntagging is built into the Windows Kernel. Pool tagging facilitates tracking of \nallocations made by drivers. This tagging facility enables debugging and \nmonitoring of allocations.\n\nThe `jxy` namespace, in this solution, empowers development of Windows drivers\nusing the `std` namespace objects with pool typing and tagging.\n\nThe library opts not to implement \"global\" `new`/`delete` operators. It \nimplements only `new`/`delete` operators with pool typing and tagging \ncapability. This requires specifying pool types and tags. If some functionality \nis used that would require a \"global allocator\" it will not link. This is an \nintentional design decision such that no global allocators are used, all \nallocations must specify a pool type and tag.\n\nThe `jxy` namespace implements allocators and deleters which conform to the \nstandard for use in template containers. These allocators and deleters are \npool type/tag aware. They require specifying the pool type and tag and prevent \nconversions/rebinding across tool types and tags - they should be used in place \nof the STL allocators.\n\n```cpp\njxy::allocator\u003cT, PagedPool, '0GAT'\u003e;\njxy::default_delete\u003cT, PagedPool, '0GAT'\u003e;\n```\n\n`jxystl.lib` implements necessary \"fill\" functionality for use of MSVC STL \ncontainers. The implementations (in `msvcfill.cpp`) are considerate to the \nkernel. This functionality enables the MSVC STL containers to link to \nkernel-appropriate functionality. This also means that if some `std` container \nfunctionality is used that doesn't have \"fill\" functionality behind  it - the \nlinker will fail. This is an intentional design decision such that any \nimplementations are thought through for use in the kernel.\n\nCRT initialization and atexit functionality is intentionally not supported. \nOrder of CRT initialization is unclear and non-obvious. When a kernel driver \nloads global data should be clearly setup and torn down during driver load and \nunload. Global CRT initialization \"hides\" this initialization in a non-obvious \nway. Further, CRT atexit functionality is not supported. Emission of necessary \nsynchronization enabling local static initialization of C++ objects is not done \nby the compiler.  And would introduces non-obvious synchronization in the \nkernel. Lack of CRT initialization and atexit support is an intentional design \ndecision. I strongly recommend avoiding it when developing kernel drivers.\n\nAs an example, the `jxy` namespace \"wraps\" `std::vector` and forces use of \npool types and tags:\n\n```cpp\nnamespace jxy\n{\n\ntemplate \u003ctypename T, \n          POOL_TYPE t_PoolType, \n          ULONG t_PoolTag, \n          typename TAllocator = jxy::allocator\u003cT, t_PoolType, t_PoolTag\u003e\u003e \nusing vector = std::vector\u003cT, TAllocator\u003e;\n\n}\n\njxy::vector\u003cint, PagedPool, '0GAT'\u003e integers;\n```\n\n```\nstlkrn!DriverEntry+0xea:\n0: kd\u003e dx integers\nintegers                 : { size=10 } [Type: std::vector\u003cint,jxy::details::allocator\u003cint,1,809976148\u003e \u003e]\n    [\u003cRaw View\u003e]     [Type: std::vector\u003cint,jxy::details::allocator\u003cint,1,809976148\u003e \u003e]\n    [capacity]       : 10\n    [allocator]      : {...} [Type: std::_Compressed_pair\u003cjxy::details::allocator\u003cint,1,809976148\u003e,std::_Vector_val\u003cstd::_Simple_types\u003cint\u003e \u003e,1\u003e]\n    [0]              : 1 [Type: int]\n    [1]              : 2 [Type: int]\n    [2]              : 3 [Type: int]\n    [3]              : 4 [Type: int]\n    [4]              : 5 [Type: int]\n    [5]              : 6 [Type: int]\n    [6]              : 7 [Type: int]\n    [7]              : 8 [Type: int]\n    [8]              : 9 [Type: int]\n    [9]              : 10 [Type: int]\n```\n\nBelow is table of functionality under the `jxy` namespace:\n\n| jxy | STL equivalent | Include | Notes |\n| ------ | -------------- | ------- | ----- |\n| `jxy::allocator` | `std::allocator` | `\u003cjxy/memory.hpp\u003e` | |\n| `jxy::default_delete` | `std::default_delete` | `\u003cjxy/memory.hpp\u003e` | |\n| `jxy::unique_ptr` | `std::unique_ptr` | `\u003cjxy/memory.hpp\u003e` | |\n| `jxy::shared_ptr` | `std::shared_ptr` | `\u003cjxy/memory.hpp\u003e` | |\n| `jxy::basic_string` | `std::basic_string` | `\u003cjxy/string.hpp\u003e`| |\n| `jxy::string` | `std::string` | `\u003cjxy/string.hpp\u003e` | |\n| `jxy::wstring` | `std::wstring` | `\u003cjxy/string.hpp\u003e` | |\n| `jxy::vector` | `std::vector` | `\u003cjxy/vector.hpp\u003e` | |\n| `jxy::map` | `std::map` | `\u003cjxy/map.hpp\u003e` | |\n| `jxy::multimap` | `std::miltimap` | `\u003cjxy/map.hpp\u003e` | |\n| `jxy::mutex` | `std::mutex` | `\u003cjxy/locks.hpp\u003e` | Uses `KGUARDED_MUTEX` |\n| `jxy::shared_mutex` | `std::shared_mutex` | `\u003cjxy/locks.hpp\u003e` | Uses `EX_PUSH_LOCK` |\n| `jxy::unique_lock` | `std::unique_lock` | `\u003cjxy/locks.hpp\u003e` | |\n| `jxy::shared_lock` | `std::shared_lock` | `\u003cjxy/locks.hpp\u003e` | |\n| `jxy::scope_resource` | None | `\u003cjxy/scope.hpp\u003e` | Similar to `std::experimental::unique_resource` |\n| `jxy::scope_exit` | None | `\u003cjxy/scope.hpp\u003e` | Similar to `std::experimental::scope_exit` |\n| `jxy::thread` | `std::thread` | `\u003cjxy/thread.hpp\u003e` | |\n| `jxy::deque` | `std::deque` | `\u003cjxy/deque.hpp\u003e` | |\n| `jxy::queue` | `std:queue` | `\u003cjxy/queue.hpp\u003e` | |\n| `jxy::priority_queue` | `std::priority_queue` | `\u003cjxy/queue.hpp\u003e` | |\n| `jxy::set` | `std::set` | `\u003cjxy/set.hpp\u003e` | |\n| `jxy::multiset` | `std::multiset` | `\u003cjxy/set.hpp\u003e` | |\n| `jxy::stack` | `std::stack` | `\u003cjxy/stack.hpp\u003e` | |\n\n## Tests - `stltest.sys`\n\nThe `stltest` project implements a driver that runs some tests against jxystl, \nusage of STL, and exceptions in the Windows Kernel.\n\n## Practical Usage - `stlkrn.sys` \nThe `stlkrn` project is a Windows Driver that uses `jxystl.lib` to implement \nprocess, thread, and module tracking in the Windows Kernel.\n\n`stlkrn.sys` registers for process, thread, and image notifications using \nfunctionality exported by `ntoskrnl`. Using these callbacks it tracks \nprocesses, threads, and image loads in various objects which use `jxy::map`, \n`jxy::shared_mutex`, `jxy::wstring`, and more.\n\nThe driver has two singletons. `jxy::ProcessMap` and `jxy::ThreadMap`, these \nare constructed when the driver loads (`DriverEntry`) and torn down when \nthe driver unloads (`DriverUnload`). It is worth noting here each process \ntracked in the `jxy::ProcessMap` (implemented as `jxy::ProcessContext`) also \nmanages a `jxy::ThreadMap`. Each \"context\" (`jxy::ProcessContext`, \n`jxy::ThreadContext`, and `jxy::ModuleContext`) is a shared (referenced) \nobject (`jxy::shared_ptr`). Therefore, the thread context that exists in the \nthread map singleton is the same context associated with the process context.\n\nKey components of `stlkrn.sys`:\n\n| Object | Purpose | Source | Notes |\n| ------ | ------- | ------ | ----- |\n| `jxy::ProcessContext` | Information for a process running on the system. | `process_context.hpp/cpp` | Uses `jxy::wstring`. Has thread (`jxy::ThreadMap`) and module (`jxy::ModuleMap`) map members. | \n| `jxy::ThreadContext` | Information for a thread running on the system. | `thread_context.hpp/cpp` | Uses `std::atomic`. |\n| `jxy::ModuleContext` | Information for an image loaded in a given process. | `module_context.hpp/cpp` | Uses `jxy::wstring` and `jxy::shared_mutex`. |\n| `jxy::ProcessMap` | Singleton, maps shared `jxy::ProcessContext` objects to a PID. | `process_map.hpp/cpp` | Singleton is accessed via `jxy::GetProcessMap`. Uses `jxy::shared_mutex` and `jxy::map`. |\n| `jxy::ThreadMap` | Maps shared `jxy::ThreadContext` objects to a TID. | `thread_map.hpp/cpp` | The global thread table (singleton) is accessed via `jxy::GetThreadMap`. Each `jxy::ProcessContext` also has a thread map which is accessed through `jxy::ProcessContext::GetThreads`. Uses `jxy::shared_mutex` and `jxy::map`. |\n| `jxy::GetModuleMap` | Maps shared `jxy::ModuleContext` to a loaded image extents (base and end address). | `module_map.hpp/cpp` | Each process context has a module map member. Loaded images for a given process are tracked using this object. Uses `jxy::shared_mutex` and `jxy::map` |\n\n`std::unordered_map` would have been a better choice over the ordered tree (`std::map`) \nfor the object maps. There is a reason this isn't used (see `TODO` section).\n\n```\nstlkrn!jxy::nt::CreateProcessNotifyRoutine+0xa6:\n3: kd\u003e dx proc\nproc                 : {...} [Type: std::shared_ptr\u003cjxy::ProcessContext\u003e]\n    [\u003cRaw View\u003e]     [Type: std::shared_ptr\u003cjxy::ProcessContext\u003e]\n    [ptr]            : 0xffffaa020d73cf70 [Type: jxy::ProcessContext *]\n    [control block]  : custom deleter, custom allocator [Type: std::_Ref_count_resource_alloc\u003cjxy::ProcessContext *,jxy::details::default_delete\u003cjxy::ProcessContext,1,1668307018\u003e,jxy::details::allocator\u003cjxy::ProcessContext,1,1668307018\u003e \u003e (derived from std::_Ref_count_base)]\n    [+0x000] m_ProcessId      : 0x2760 [Type: unsigned int]\n    [+0x004] m_SessionId      : 0x2 [Type: unsigned int]\n    [+0x008] m_ParentProcessId : 0xcc4 [Type: unsigned int]\n    [+0x010] m_FileName       : \"\\Device\\HarddiskVolume4\\Windows\\System32\\cmd.exe\" [Type: std::basic_string\u003cunsigned short,std::char_traits\u003cunsigned short\u003e,jxy::details::allocator\u003cunsigned short,1,1852856394\u003e \u003e]\n    [+0x030] m_FilePart       : \"cmd.exe\" [Type: std::basic_string\u003cunsigned short,std::char_traits\u003cunsigned short\u003e,jxy::details::allocator\u003cunsigned short,1,1886410826\u003e \u003e]\n    [+0x050] m_CreatorProcessId : 0x1b08 [Type: unsigned int]\n    [+0x054] m_CreatorThreadId : 0x26a0 [Type: unsigned int]\n    [+0x058] m_Threads        [Type: jxy::ThreadMap]\n    [+0x070] m_Modules        [Type: jxy::ModuleMap]\n```\n\n## TODO\nI had wanted to include `std::unordered_map` initially, however it uses `ceilf`.\nFloating point arithmetic in the Windows Kernel comes with some challenges. \nSo, for now it is omitted until an appropriate solution is designed.\n\n## Disclaimer\nThis solution is a passion project. At this time it is not intended for \nproduction code. `x64` is well tested and stable, `stlkrn.sys` passes full \ndriver verifier options (including randomized low resource simulation). \nException handling at or above dispatch has been tested, but not in practical \nuse cases. `x86` has *not* been tested.  There is functionality under the \n`jxy` namespace that is incomplete/unused/untested.  _Your milage may vary_ - \nI would like to continue this work over time, if any issues/bugs are found \nfeel free to open issues against this repo.\n\n## Related Work\n\nThis project provides STL support in the Windows Kernel by using as much of the \nSTL facility as possible. There are other solutions for use of STL in kernel \ndevelopment. This section will outline alternatives, first I will summarize \nthis work:\n\nThis Project:\n - Uses the STL directly. Does **not** reimplement any STL functionality unless absolutely necessary.\n - Requires pool types and tags. No global `new` or `delete` is implemented.\n - Forbid moving data between objects of different pools or tags.\n - Avoids CRT initialization and `atexit` functionality. CRT initialization order \n   is non-obvious, driver initialization and teardown *should be obvious*. `atexit` functionality \n   may introduce data races for kernel code, `atexit` is not implemented.\n\n[Bareflank Hypervisor][github.bareflank]:\n\nBareflank implements support for running C++ in their hypervisor. They have full STL and CRT \nsupport. This is a comprehensive project that enables a plethora features of the standard in \nkernel mode (including exceptions). As I understand their solution forces `NonPagedPool` on global \n`new`/`delete` allocations. I have to commend Bareflank with their implementation, it's well \nthought out and cross platform. However the Windows implementation builds through cygwin and \n\"shims\" in support for the Windows kernel. In comparison, this project aims to be considerate to \nthe Windows kernel. It enables specifying pool tags and types (paged vs non-paged) and hopes \nto minimize \"sharp edges\" associated with using C++ and the STL in kernel mode. All that said, \nBareflank is impressive for what is does. For an excellent presentation on Bareflank's support of \nC++ I highly recommend watching [Dr. Rian Quinn's presentation at cppcon 2016][channel9.bareflank].\n\n[Win32KernelSTL][github.Win32KernelSTL]:\n\nThe Win32KernelSTL project does allow you to use STL functionality directly in the kernel. The project \nimplements global `new`/`delete` and forces `NonPagedPool`, it implements CRT initialization support, \nand bugchecks when a cpp exception is thrown. It makes no attempt to do cpp exception unwinding. Due \nto the assumptions it makes I find it unpractical for any serious use cases. The code is reasonably \nclear and documented, I recommend giving this project a browse for educating around C++ support in the \nkernel. One note, the CRT code in Win32KernelSTL does implement `atexit` but keep in mind there is no \nsynchronization emitted by the compiler here (as opposed to user mode). So a local static requiring \ninsertion of an entry in the `atexit` list may race causing a double-init or double-free.\n\n[Driver Plus Plus][github.dxx]:\n\nThis project implements necessary C++ facility for pulling in a number of C++ solutions into \nkernel mode (`EASTL`, `msgpack`, etc.). Driver Plus Plus implements CRT initialization and global \n`new`/`delete` support (which forces `NonPagedPool`). Again this is counter to the goals of this \nproject. However, this project does enable a lot of great C++ facility for use in kernel mode. It \ndoes make modifications to the C++ solutions it pulls in to shim in support for it's use cases. \nDriver Plus Plus also makes the assumption around `atexit` as mentioned previously.\n\n[KTL - DymOK93][github.ktl.DymOK93]\n\nKTL (Windows Kernel Template Library by DymOK93) reimplements a good amount of modern C++ and is\nactively developing more support for use in the Windows Kernel. It also has support for RAII around \nmany kernel primitives, provides native `ANSI_STRING` and `UNICODE_STRING` support, it provides \nsome useful wrappers for registering kernel callbacks, and more convenience features around the \nWindows Kernel. It implements global `new`/`delete` and has a preprocessor definition \n(`KTL_USING_NON_PAGED_NEW_AS_DEFAULT`) for switching between default paged or non-paged, which is \ngood. However, it uses a single pool tag (`KTL_HEAP_TAG`). Further, the existing allocator templates \ndon't enable a developer to specify a pool tag, so using this library as-is causes all allocations \nto be tagged with the same pool tag. That said, it would be reasonable to implement a custom \nallocator that empowers tagging of allocations. The library does have exception support, albeit \nonly x64. The exception support in KTL is based on [avakar's][github.vcrtl] with enhancements and \nfixes. I commend the work here and I'm impressed by the amount of facility that exists, it is \nreasonably feature packed and under active development. I would like to explore using it more in \nthe future, and potentially collaborating on better exception support for both `stlkrn` and `KTL`. \nReimplementation of STL functionality, lack of native pool tagging support, and the global \nallocators are counter to the ideologies of this project.\n\n[KTL - MeeSong][github.ktl.MeeSong]:\n\nKTL (Windows Kernel Template Library by MeeSong) reimplements a good amount of modern C++ \nfunctionality for use in the Windows Kernel. It also implements global `new`/`delete` but does a \ndecent job at providing facility for specifying pool tags and types where possible. However this \ndoes mean the global allocator might hide an allocation in a non-obvious pool. Further the template \nallocators in this project carry the cost of two points for an allocator and deallocator object, \nI am also concerned that conversion between the allocator types may allow for cross pool/tag \nallocs/frees. Overall I'm impressed by the amount of facility that is implemented here. \nReimplementation of STL functionality and the global allocators are counter to the ideologies of \nthis project.\n\n[Kernel-Bridge][github.KernelBridge]:\n\nKernel-Bridge implements some great facility for Windows Kernel development. The library provides \nwrappers for registering for Windows callbacks using C++ objects. I would like to find more time \nto use and investigate this solution. It does implement CRT support. The `atexit` functionality \nimplemented is not dynamic - it uses a static array, if it runs out of slots, it fails. The \ndefault `new`/`delete` forces `NonPagedPool`. It does not have full exception support, it will \nbugcheck if a cpp exception is thrown - it will not unwind objects on the stack.\n\n## Credits\nThis repository draws from some preexisting work. Credits to their authors.\n\n- [C++ Exceptions in Windows Drivers][github.vcrtl]  \nThis project implements parts of the Visual Studio runtime library that are \nneeded for C++ exception handling. Currently, x86 and x64 platforms are \nsupported.\n- [Process Hacker Native API Headers][github.phnt]   \nCollection of Native API header files. Gathered from Microsoft header files and \nsymbol files, as well as a lot of reverse engineering and guessing.\n\n[//]: # (Hyperlink IDs)\n[github.vcrtl]: https://github.com/avakar/vcrtl\n[github.vcrtl.x64]: https://github.com/avakar/vcrtl/tree/master/src/x64\n[github.phnt]: https://github.com/processhacker/phnt\n[github.bareflank]: https://github.com/Bareflank/hypervisor\n[channel9.bareflank]: https://channel9.msdn.com/Events/CPP/CppCon-2016/CppCon-2016-Rian-Quinn-Making-C-and-the-STL-Work-in-the-Linux--Windows-Kernels\n[github.Win32KernelSTL]: https://github.com/DragonQuestHero/Win32KernelSTL\n[github.dxx]: https://github.com/sidyhe/dxx\n[github.ktl.DymOK93]: https://github.com/DymOK93/KTL\n[github.ktl.MeeSong]: https://github.com/MeeSong/KTL\n[github.KernelBridge]: https://github.com/HoShiMin/Kernel-Bridge","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjxy-s%2Fstlkrn","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjxy-s%2Fstlkrn","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjxy-s%2Fstlkrn/lists"}