C++ STL in the Windows Kernel with C++ Exception Support

Overview

C++ STL in Windows Drivers

This project uses MSVC C++ STL in a Windows Kernel Driver. In this solution jxystl.lib is implemented as a kernel-tuned, pool type/tag aware, template library and MSVC implementation. Which, under the hood, uses the MSVC C++ STL.

helloWorld; try { helloWorld.assign(L"Hello, World!"); } catch (const std::bad_alloc&) { return STATUS_INSUFFICIENT_RESOURCES; } return STATUS_SUCCESS; } ">
#include <wdm.h>
#include <jxy/string.hpp>

extern "C"
NTSTATUS DriverEntry(
    PDRIVER_OBJECT DriverObject,
    PUNICODE_STRING RegistryPath)
{
    jxy::wstring'0GAT'> helloWorld;

    try
    {
        helloWorld.assign(L"Hello, World!");
    }
    catch (const std::bad_alloc&)
    {
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    return STATUS_SUCCESS;
}
1: kd> dv
   DriverObject = 0xffffca83`5380d300 Driver "\Driver\stlkrn"
   RegistryPath = 0xffffca83`5227f000 "\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\stlkrn"
     helloWorld = "Hello, World!"

The driver implemented in this solution, stdkrn.sys, uses various std namespace containers, wrapped under the jxy namespace. This driver registers for process, thread, and image notifications; then uses modern C++ to track process contexts, thread contexts, and module contexts.

Exception Handling - vcrtl

Exception handling enables C++ objects to unwind when an exception is thrown. This is a core feature of C++ which gets little attention for kernel drivers. Microsoft does not natively support C++ exceptions for kernel drivers.

C++ exception handling is made possible by avakar's vcrtl libraray. This project would have been far more work without avakar's awesome contribution. For information on exception handling in Windows Drivers head over to avakar's vcrtl github. Also, this page gives excellent details on exception handling on AMD64.

MSVC C++ STL Support - jxystl

Windows Kernel allocations are associated with a memory pool. Further, pool tagging is built into the Windows Kernel. Pool tagging facilitates tracking of allocations made by drivers. This tagging facility enables debugging and monitoring of allocations.

The jxy namespace, in this solution, empowers development of Windows drivers using the std namespace objects with pool typing and tagging.

The library opts not to implement "global" new/delete operators. It implements only new/delete operators with pool typing and tagging capability. This requires specifying pool types and tags. If some functionality is used that would require a "global allocator" it will not link. This is an intentional design decision such that no global allocators are used, all allocations must specify a pool type and tag.

The jxy namespace implements allocators and deleters which conform to the standard for use in template containers. These allocators and deleters are pool type/tag aware. They require specifying the pool type and tag and prevent conversions/rebinding across tool types and tags - they should be used in place of the STL allocators.

jxy::allocator'0GAT'>;
jxy::default_delete'0GAT'>;

jxystl.lib implements necessary "fill" functionality for use of MSVC STL containers. The implementations (in msvcfill.cpp) are considerate to the kernel. This functionality enables the MSVC STL containers to link to kernel-appropriate functionality. This also means that if some std container functionality is used that doesn't have "fill" functionality behind it - the linker will fail. This is an intentional design decision such that any implementations are thought through for use in the kernel.

CRT initialization and atexit functionality is intentionally not supported. Order of CRT initialization is unclear and non-obvious. When a kernel driver loads global data should be clearly setup and torn down during driver load and unload. Global CRT initialization "hides" this initialization in a non-obvious way. Further, CRT atexit functionality is not supported. Emission of necessary synchronization enabling local static initialization of C++ objects is not done by the compiler. And would introduces non-obvious synchronization in the kernel. Lack of CRT initialization and atexit support is an intentional design decision. I strongly recommend avoiding it when developing kernel drivers.

As an example, the jxy namespace "wraps" std::vector and forces use of pool types and tags:

namespace jxy
{

template <typename T, 
          POOL_TYPE t_PoolType, 
          ULONG t_PoolTag, 
          typename TAllocator = jxy::allocator> 
using vector = std::vector;

}

jxy::vector<int, PagedPool, '0GAT'> integers;
stlkrn!DriverEntry+0xea:
0: kd> dx integers
integers                 : { size=10 } [Type: std::vector >]
    []     [Type: std::vector >]
    [capacity]       : 10
    [allocator]      : {...} [Type: std::_Compressed_pair,std::_Vector_val >,1>]
    [0]              : 1 [Type: int]
    [1]              : 2 [Type: int]
    [2]              : 3 [Type: int]
    [3]              : 4 [Type: int]
    [4]              : 5 [Type: int]
    [5]              : 6 [Type: int]
    [6]              : 7 [Type: int]
    [7]              : 8 [Type: int]
    [8]              : 9 [Type: int]
    [9]              : 10 [Type: int]

Below is table of functionality under the jxy namespace:

jxylib STL equivalent Include Notes
jxy::allocator std::allocator
jxy::default_delete std::default_delete
jxy::unique_ptr std::unique_ptr
jxy::shared_ptr std::shared_ptr
jxy::basic_string std::basic_string
jxy::string std::string
jxy::wstring std::wstring
jxy::vector std::vector
jxy::map std::map
jxy::multimap std::miltimap
jxy::mutex std::mutex Uses KGUARDED_MUTEX
jxy::shared_mutex std::shared_mutex Uses EX_PUSH_LOCK
jxy::unique_lock std::unique_lock
jxy::shared_lock std::shared_lock
jxy::scope_resource None Similar to std::experimental::unique_resource
jxy::scope_exit None Similar to std::experimental::scope_exit
jxy::thread std::thread
jxy::deque std::deque
jxy::queue std:queue
jxy::priority_queue std::priority_queue
jxy::set std::set
jxy::multiset std::multiset
jxy::stack std::stack

Tests - stltest.sys

The stltest project implements a driver that runs some tests against jxystl, usage of STL, and exceptions in the Windows Kernel.

Practical Usage - stlkrn.sys

The stlkrn project is a Windows Driver that uses jxylib to implement process, thread, and module tracking in the Windows Kernel.

stlkrn.sys registers for process, thread, and image notifications using functionality exported by ntoskrnl. Using these callbacks it tracks processes, threads, and image loads in various objects which use jxy::map, jxy::shared_mutex, jxy::wstring, and more.

The driver has two singletons. jxy::ProcessMap and jxy::ThreadMap, these are constructed when the driver loads (DriverEntry) and torn down when the driver unloads (DriverUnload). It is worth noting here each process tracked in the jxy::ProcessMap (implemented as jxy::ProcessContext) also manages a jxy::ThreadMap. Each "context" (jxy::ProcessContext, jxy::ThreadContext, and jxy::ModuleContext) is a shared (referenced) object (jxy::shared_ptr). Therefore, the thread context that exists in the thread map singleton is the same context associated with the process context.

Key components of stlkrn.sys:

Object Purpose Source Notes
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.
jxy::ThreadContext Information for a thread running on the system. thread_context.hpp/cpp Uses std::atomic.
jxy::ModuleContext Information for an image loaded in a given process. module_context.hpp/cpp Uses jxy::wstring and jxy::shared_mutex.
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.
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.
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

std::unordered_map would have been a better choice over the ordered tree (std::map) for the object maps. There is a reason this isn't used (see TODO section).

,jxy::details::allocator >] [+0x030] m_FilePart : "cmd.exe" [Type: std::basic_string,jxy::details::allocator >] [+0x050] m_CreatorProcessId : 0x1b08 [Type: unsigned int] [+0x054] m_CreatorThreadId : 0x26a0 [Type: unsigned int] [+0x058] m_Threads [Type: jxy::ThreadMap] [+0x070] m_Modules [Type: jxy::ModuleMap] ">
stlkrn!jxy::nt::CreateProcessNotifyRoutine+0xa6:
3: kd> dx proc
proc                 : {...} [Type: std::shared_ptr]
    []     [Type: std::shared_ptr]
    [ptr]            : 0xffffaa020d73cf70 [Type: jxy::ProcessContext *]
    [control block]  : custom deleter, custom allocator [Type: std::_Ref_count_resource_alloc,jxy::details::allocator > (derived from std::_Ref_count_base)]
    [+0x000] m_ProcessId      : 0x2760 [Type: unsigned int]
    [+0x004] m_SessionId      : 0x2 [Type: unsigned int]
    [+0x008] m_ParentProcessId : 0xcc4 [Type: unsigned int]
    [+0x010] m_FileName       : "\Device\HarddiskVolume4\Windows\System32\cmd.exe" [Type: std::basic_string,jxy::details::allocator >]
    [+0x030] m_FilePart       : "cmd.exe" [Type: std::basic_string,jxy::details::allocator >]
    [+0x050] m_CreatorProcessId : 0x1b08 [Type: unsigned int]
    [+0x054] m_CreatorThreadId : 0x26a0 [Type: unsigned int]
    [+0x058] m_Threads        [Type: jxy::ThreadMap]
    [+0x070] m_Modules        [Type: jxy::ModuleMap]

TODO

Although jxy::shared_ptr is supported through std::shared_ptr directly. This implementation could be improved. Internally, std::shared_ptr will use a global new allocation in some circumstances. To avoid this jxy::make_shared is implemented to associate the appropriate pool tagged/typed allocator and deleter. This introduces an extra control block allocation for the shared reference, which is what std::make_shared aims to avoid. Unfortunately, attaching a control block to the container is not public functionality. This could be improved with some support by MSVC or by hand-rolling a jxy::shared_ptr which is better tuned for kernel-use.

I had wanted to include std::unordered_map initially, however it uses ceilf. Floating point arithmetic in the Windows Kernel comes with some challenges. So, for now it is omitted until an appropriate solution is designed.

Disclaimer

This solution is a passion project. At this time it is not intended for production code. x64 is well tested and stable, stlkrn.sys passes full driver verifier options (including randomized low resource simulation). Exception handling at or above dispatch has been tested, but not in practical use cases. x86 has not been tested. There is functionality under the jxy namespace that is incomplete/unused/untested. Your milage may vary - I would like to continue this work over time, if any issues/bugs are found feel free to open issues against this repo.

Related Work

This project provides STL support in the Windows Kernel by using as much of the STL facility as possible. There are other solutions for use of STL in kernel development. This section will outline alternatives, first I will summarize this work:

This Project:

  • Uses the STL directly. Does not reimplement any STL functionality unless absolutely necessary.
  • Requires pool types and tags. No global new or delete is implemented.
  • Forbid moving data between objects of different pools or tags.
  • Avoids CRT initialization and atexit functionality. CRT initialization order is non-obvious, driver initialization and teardown should be obvious. atexit functionality may introduce data races for kernel code, atexit is not implemented.

Bareflank Hypervisor:

Bareflank implements support for running C++ in their hypervisor. They have full STL and CRT support. This is a comprehensive project that enables a plethora features of the standard in kernel mode (including exceptions). As I understand their solution forces NonPagedPool on global new/delete allocations. I have to commend Bareflank with their implementation, it's well thought out and cross platform. However the Windows implementation builds through cygwin and "shims" in support for the Windows kernel. In comparison, this project aims to be considerate to the Windows kernel. It enables specifying pool tags and types (paged vs non-paged) and hopes to minimize "sharp edges" associated with using C++ and the STL in kernel mode. All that said, Bareflank is impressive for what is does. For an excellent presentation on Bareflank's support of C++ I highly recommend watching Dr. Rian Quinn's presentation at cppcon 2016.

Win32KernelSTL:

The Win32KernelSTL project does allow you to use STL functionality directly in the kernel. The project implements global new/delete and forces NonPagedPool, it implements CRT initialization support, and bugchecks when a cpp exception is thrown. It makes no attempt to do cpp exception unwinding. Due to the assumptions it makes I find it unpractical for any serious use cases. The code is reasonably clear and documented, I recommend giving this project a browse for educating around C++ support in the kernel. One note, the CRT code in Win32KernelSTL does implement atexit but keep in mind there is no synchronization emitted by the compiler here (as opposed to user mode). So a local static requiring insertion of an entry in the atexit list may race causing a double-init or double-free.

Driver Plus Plus:

This project implements necessary C++ facility for pulling in a number of C++ solutions into kernel mode (EASTL, msgpack, etc.). Driver Plus Plus implements CRT initialization and global new/delete support (which forces NonPagedPool). Again this is counter to the goals of this project. However, this project does enable a lot of great C++ facility for use in kernel mode. It does make modifications to the C++ solutions it pulls in to shim in support for it's use cases. Driver Plus Plus also makes the assumption around atexit as mentioned previously.

KTL:

KTL (Windows Kernel Template Library) reimplements a good amount of modern C++ functionality for use in the Windows Kernel. It also implements global new/delete but does a decent job at providing facility for specifying pool tags and types where possible. However this does mean the global allocator might hide an allocation in a non-obvious pool. Further the template allocators in this project carry the cost of two points for an allocator and deallocator object, I am also concerned that conversion between the allocator types may allow for cross pool/tag allocs/frees. Overall I'm impressed by the amount of facility that is implemented here. Reimplementation of STL functionality and the global allocators are counter to the ideologies of this project.

Kernel-Bridge:

Kernel-Bridge implements some great facility for Windows Kernel development. The library provides wrappers for registering for Windows callbacks using C++ objects. I would like to find more time to use and investigate this solution. It does implement CRT support. The atexit functionality implemented is not dynamic - it uses a static array, if it runs out of slots, it fails. The default new/delete forces NonPagedPool. It does not have full exception support, it will bugcheck if a cpp exception is thrown - it will not unwind objects on the stack.

Credits

This repository draws from some preexisting work. Credits to their authors.

  • C++ Exceptions in Windows Drivers
    This project implements parts of the Visual Studio runtime library that are needed for C++ exception handling. Currently, x86 and x64 platforms are supported.
  • Process Hacker Native API Headers
    Collection of Native API header files. Gathered from Microsoft header files and symbol files, as well as a lot of reverse engineering and guessing.
Issues
  •  destructor and constructor not work

    destructor and constructor not work

    As the title described, the destructor and constructor function do not work. You can write a print in the destructor and constructor function to test.

    opened by wangzhankun 6
  • Add support for C++20

    Add support for C++20

    Hi,

    The project doesn't compile if the language standard is set to ISO C++20 Standard (/std:c++20):

    2>------ Build started: Project: stltest, Configuration: Debug x64 ------
    2>Building 'stltest' with toolset 'WindowsKernelModeDriver10.0' and the 'Desktop' target platform.
    2>deque_tests.cpp
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(469,66): error C2027: use of undefined type 'std::_Replace_first_parameter<_Other,_Ty>'
    2>        with
    2>        [
    2>            _Other=int,
    2>            _Ty=jxy::details::allocator<int,PagedPool,809976148>
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(469): message : see declaration of 'std::_Replace_first_parameter<_Other,_Ty>'
    2>        with
    2>        [
    2>            _Other=int,
    2>            _Ty=jxy::details::allocator<int,PagedPool,809976148>
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(582): message : see reference to class template instantiation 'std::_Get_rebind_type<_Alloc,_Ty,void>' being compiled
    2>        with
    2>        [
    2>            _Alloc=jxy::details::allocator<int,PagedPool,809976148>,
    2>            _Ty=int
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(756): message : see reference to alias template instantiation 'std::_Normal_allocator_traits<_Alloc>::rebind_alloc<_Ty>' being compiled
    2>        with
    2>        [
    2>            _Alloc=jxy::details::allocator<int,PagedPool,809976148>,
    2>            _Ty=int
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(582): message : see reference to alias template instantiation 'std::_Rebind_alloc_t<jxy::details::allocator<T,PagedPool,809976148>,_Ty>' being compiled
    2>        with
    2>        [
    2>            T=int,
    2>            _Ty=int
    2>        ]
    2>E:\Files\Code\C++\keval\kevald\stlkrn\stltest\deque_tests.cpp(16): message : see reference to class template instantiation 'std::deque<int,jxy::details::allocator<T,PagedPool,809976148>>' being compiled
    2>        with
    2>        [
    2>            T=int
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(469,60): error C2061: syntax error: identifier 'type'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(573,69): error C2794: 'type': is not a member of any direct or indirect base class of 'std::_Get_rebind_type<_Alloc,_Ty,void>'
    2>        with
    2>        [
    2>            _Alloc=jxy::details::allocator<int,PagedPool,809976148>,
    2>            _Ty=int
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(582,53): error C2938: 'std::_Normal_allocator_traits<_Alloc>::rebind_alloc' : Failed to specialize alias template
    2>        with
    2>        [
    2>            _Alloc=jxy::details::allocator<int,PagedPool,809976148>
    2>        ]
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(582,53): error C2938: 'std::_Rebind_alloc_t' : Failed to specialize alias template
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(584,76): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(591,55): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(591,89): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(592,36): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(592,68): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(592,101): error C2993: 'unknown-type': is not a valid type for non-type template parameter '_Test'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(595,58): error C2955: 'std::_Deque_val': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(540): message : see declaration of 'std::_Deque_val'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(600,52): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(600,52): error C2039: 'size_type': is not a member of 'std::allocator_traits<_Alloc>'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(600,1): error C2061: syntax error: identifier 'size_type'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(601,52): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(601,52): error C2039: 'difference_type': is not a member of 'std::allocator_traits<_Alloc>'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(601,1): error C2061: syntax error: identifier 'difference_type'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(602,52): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(602,52): error C2039: 'pointer': is not a member of 'std::allocator_traits<_Alloc>'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(602,1): error C2061: syntax error: identifier 'pointer'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(603,52): error C2955: 'std::allocator_traits': use of class template requires template argument list
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\xmemory(737): message : see declaration of 'std::allocator_traits'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(603,52): error C2039: 'const_pointer': is not a member of 'std::allocator_traits<_Alloc>'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(603,1): error C2061: syntax error: identifier 'const_pointer'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(607,55): error C3203: '_Deque_val': unspecialized class template can't be used as a template argument for template parameter '_Mydeque', expected a real type
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(608,61): error C3203: '_Deque_val': unspecialized class template can't be used as a template argument for template parameter '_Mydeque', expected a real type
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(609,65): error C3203: '_Deque_val': unspecialized class template can't be used as a template argument for template parameter '_Mydeque', expected a real type
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(610,71): error C3203: '_Deque_val': unspecialized class template can't be used as a template argument for template parameter '_Mydeque', expected a real type
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(614,22): error C2131: expression did not evaluate to a constant
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(595,58): message : failure was caused by non-constant arguments or reference to a non-constant symbol
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(595,58): message : see usage of 'std::_Deque_val<_Val_types>::_Block_size'
    2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\deque(624,39): error C2061: syntax error: identifier 'size_type'
    
    [...]
    

    Help would be greatly appreciated 😺

    opened by SilverTuxedo 2
  • how to integrate into my driver

    how to integrate into my driver

    Hi, I have include the lib and the header into my driver. But when I try to build the driver. I have the following errors:

    #error:  "_HAS_EXCEPTIONS == 0 is not supported."	Poc	D:\Windows Kits\10\Include\10.0.19041.0\km\crt\xstddef	26	
    “_CRT_STRINGIZE”:  multidefined
    "_CRT_STRINGIZE" multidefined
    "_STD": multidefined
    
    opened by wangzhankun 1
  • Can't build static library on Visual Studio 2022 & WDK 10.1.22000

    Can't build static library on Visual Studio 2022 & WDK 10.1.22000

    Hi, I'm trying to build jxystl.lib. In order to do it I have written CMakeLists.txt file that build the library, using FindWDK. CMakeLists.txt:

    cmake_minimum_required(VERSION 3.15 FATAL_ERROR)
    project(jxystl LANGUAGES CXX)
    
    # Static file linking
    set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
    
    # Set C++ settings
    set(CMAKE_CXX_STANDARD 17)
    set(CMAKE_CXX_STANDARD_REQUIRED YES)
    set(CMAKE_CXX_EXTENSIONS NO)
    
    # Append FindWDK to cmake modules and enable it
    list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/third-party/FindWDK/cmake")
    find_package(WDK REQUIRED)
    
    # Source & Headers files
    file(GLOB ${PROJECT_NAME}_LIST
    	"${CMAKE_CURRENT_SOURCE_DIR}/jxystl/*.c"
    	"${CMAKE_CURRENT_SOURCE_DIR}/jxystl/*.cc"
    	"${CMAKE_CURRENT_SOURCE_DIR}/jxystl/*.cpp"
    	"${CMAKE_CURRENT_SOURCE_DIR}/jxystl/*.cxx"
    )
    file(GLOB ${PROJECT_NAME}_LIST_H
    	"${CMAKE_CURRENT_SOURCE_DIR}/include/jxy/*.h"
    	"${CMAKE_CURRENT_SOURCE_DIR}/include/jxy/*.hh"
    	"${CMAKE_CURRENT_SOURCE_DIR}/include/jxy/*.hpp"
    	"${CMAKE_CURRENT_SOURCE_DIR}/include/jxy/*.hxx"
    )
    
    wdk_add_library(${PROJECT_NAME} STATIC
    	KMDF 1.15
    	${${PROJECT_NAME}_LIST}
    	${${PROJECT_NAME}_LIST_H}
    )
    
    target_link_libraries(${PROJECT_NAME}
    	"${CMAKE_CURRENT_SOURCE_DIR}/third-party/vcrtl/x64/vcrtl_driver.lib"
    )
    
    target_include_directories(${PROJECT_NAME} PUBLIC
    	"${CMAKE_CURRENT_SOURCE_DIR}/include"
    )
    

    But I get a lot of errors: image

    opened by sccoouut 1
  • Update readme to describe DymOK93 KTL

    Update readme to describe DymOK93 KTL

    @DymOK93 reached out to me on https://github.com/DymOK93/KTL. I had only located MeeSong's KTL library when updating the project README to draw comparisons between other existing projects.

    This PR adds an explanation of https://github.com/DymOK93/KTL the readme and draws comparisons to the ideologies of the stlkrn project.

    opened by jxy-s 0
  • Optimize make_shared using allocate_shared

    Optimize make_shared using allocate_shared

    This PR updates jxy::make_shared to force use of std::allocate_shared. Since std::make_shared provides no way to specify the allocator, the old implementation would cause an extra allocation for the control block since it would allocate the object and construct the jxy::shared_ptr with it (which internally must allocate the control block using the specified allocator). This now is avoided with std::allocate_shared 🎉!

    Thanks grandpa (you know who you are 😉) for brining std::allocate_shared to my attention!

    opened by jxy-s 0
  • Add allocator::rebind for c++20

    Add allocator::rebind for c++20

    The rebind member has been removed from std::allocator in c++20 following its deprecation in c++17. However, since the jxy allocator cannot be constructed like the default allocator due to its custom template parameters, it must define this member.

    Fixes #2

    opened by SilverTuxedo 0
  • Implement unordered container support, xhash no floating point

    Implement unordered container support, xhash no floating point

    This PR will add support for unordered containers (unordered_map, unordered_multimap, unordered_set, and unordered_multiset).

    To do this I must patch xhash from the MSVC STL to eliminate the floating point arithmetic. I do this by copying xhash out of the MSVC STL and applying changes under the _XHASH_NO_FLOATING_POINT define. I then directly include the patched version through jxy/unordered_map.hpp and jxy/unordered_set.hpp defining _XHASH_NO_FLOATING_POINT to 1 before doing so.

    The solution here isn't ideal. I would much rather PR this into MSVC directly. I have a branch that does this for MSVC (https://github.com/microsoft/STL/compare/main...jxy-s:xhash-no-floating-point) and I will engage with the MSVC community on it. However, the likelihood of this happening in a timely manner (if at all) is slim - it is, understandably, simply not a priority for them.

    opened by jxy-s 0
  • build errors when build on WDK10 x64

    build errors when build on WDK10 x64

    Hi every body. When I build your project many errors occurred. I spent some hours for fix this issue but I couldn't to fix this errors. how to fix this issues? image

    opened by mohamadrezashafie 3
Owner
Johnny Shaw
Johnny Shaw
Library that simplify to find header for class from STL library.

Library that simplify to find header for class from STL library. Instead of searching header for some class you can just include header with the class name.

null 6 Jun 7, 2022
A size-optimized STL implementation.

uSTL This library is obsolete. Please use the official gcc C++ standard library. uSTL is a partial implementation of the C++ standard library that foc

Mike Sharov 397 Jun 24, 2022
Guidelines Support Library

GSL: Guidelines Support Library The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guideline

Microsoft 5k Jun 20, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

gsl-lite 741 Jun 27, 2022
C++11/14/17 std::optional with functional-style extensions and reference support

optional Single header implementation of std::optional with functional-style extensions and support for references. Clang + GCC: MSVC: std::optional i

Sy Brand 643 Jun 21, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

gsl-lite 741 Jun 27, 2022
Guidelines Support Library

GSL: Guidelines Support Library The Guidelines Support Library (GSL) contains functions and types that are suggested for use by the C++ Core Guideline

Microsoft 5k Jun 25, 2022
Bsl - Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to support the development of critical systems applications

Description The Bareflank Support Library (BSL) is a Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to su

Bareflank 63 Jun 18, 2022
GNU Scientific Library with CMake build support and AMPL bindings

GSL - GNU Scientific Library This is GSL, the GNU Scientific Library, a collection of numerical routines for scientific computing. GSL is free softwar

AMPL 400 Jun 16, 2022
Simple Kernel Mode Data Pointer Swap, Credits To FoxiTV On UC for Great Resources About This Topic

Data-Pointer-Swap Simple Kernel Mode Data Pointer Swap, Credits To FoxiTV On UC for Great Resources About This Topic. This Source Was Made Back In Aug

null 7 Apr 1, 2022
Windows Implementation Library

Windows Implementation Libraries (WIL) The Windows Implementation Libraries (WIL) is a header-only C++ library created to make life easier for develop

Microsoft 2k Jun 26, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

null 6.3k Jun 27, 2022
Cross-platform STL-styled and STL-compatible library with implementing containers, ranges, iterators, type traits and other tools; actors system; type-safe config interface.

Yato A small repository where I'm gatherting useful snippets and abstractions for C++ development. Yato includes 3 main modules: multidimensional cont

Alexey 9 Mar 7, 2022
LLVM libc++ without exception and RTTI, specifically for Android.

libc++ LLVM libc++, specifically for Android, removing exception and RTTI support. Source code is extracted from AOSP's llvm-project repository: git c

John Wu 39 Jun 18, 2022
ThreadPool - A fastest, exception-safety and pure C++17 thread pool.

Warnings Since commit 468129863ec65c0b4ede02e8581bea682351a6d2, I move ThreadPool to C++17. (To use std::apply.) In addition, the rule of passing para

Han-Kuan Chen 121 Jun 4, 2022
C++14 asynchronous allocation aware futures (supporting then, exception handling, coroutines and connections)

Continuable is a C++14 library that provides full support for: lazy async continuation chaining based on callbacks (then) and expression templates, ca

Denis Blank 754 Jun 11, 2022
hotpatching, closures, lambdas, and signal-based exception handling in GNU C

Handy Headers GCC/clang is required for all headers exception.h try/except blocks in C Works with actual signals int main(){ int e; try{ //brackets

null 4 May 28, 2022
This project aims to facilitate debugging a kernel driver in windows by adding support for a code change on the fly without reboot/unload, and more!

BSOD Survivor Tired of always telling yourself when you got a BSOD that what if I could just return to the caller function which caused the BSOD, and

Ido Westler 142 Jun 20, 2022
stdgpu: Efficient STL-like Data Structures on the GPU

stdgpu: Efficient STL-like Data Structures on the GPU Features | Examples | Documentation | Building | Integration | Contributing | License | Contact

Patrick Stotko 705 Jun 27, 2022
STL compatible C++ memory allocator library using a new RawAllocator concept that is similar to an Allocator but easier to use and write.

memory The C++ STL allocator model has various flaws. For example, they are fixed to a certain type, because they are almost necessarily required to b

Jonathan Müller 1.1k Jun 15, 2022
Library of generic and type safe containers in pure C language (C99 or C11) for a wide collection of container (comparable to the C++ STL).

M*LIB: Generic type-safe Container Library for C language Overview M*LIB (M star lib) is a C library enabling to use generic and type safe container i

PpHd 493 Jun 20, 2022
30 Seconds of C++ (STL in C++). Read More about 30C++ here 👉

30 Seconds of C++ (STL in C++). Read More about 30C++ here ??

Bhupesh Varshney 1.2k Jun 26, 2022
Low dependency(C++11 STL only), good portability, header-only, deep neural networks for embedded

LKYDeepNN LKYDeepNN 可訓練的深度類神經網路 (Deep Neural Network) 函式庫。 輕量,核心部份只依賴 C++11 標準函式庫,低相依性、好移植,方便在嵌入式系統上使用。 Class diagram 附有訓練視覺化 demo 程式 訓練視覺化程式以 OpenCV

Lin Kao-Yuan 39 Apr 27, 2022
from Microsoft STL, but multi-platform

mscharconv <charconv> from Microsoft STL, but multi-platform. Tested with MSVC, gcc, and clang on Windows, Linux, and macOS (will likely work on other

Borislav Stanimirov 35 Jun 8, 2022
This program converts ASCII STL files to RT files for miniRT.

STL to RT This program converts ASCII STL files to RT files for miniRT. Input the ASCII STL file to the standard input and output the RT file from the

null 5 Mar 29, 2021
A minimal, toy programming language implemented in C++ and STL.

od Programming Language Mod (or ModLang) is a minimal, toy programming language implemented in C++ and STL (Standard Template Library) with no other e

Pranav Shridhar 26 Apr 28, 2022
pngtostl is a program that converts a PNG image into STL 3D models

pngtostl is a program that converts a PNG image into a litophane, in STL format, suitable to be printed by entry level 3D printers.

Salvatore Sanfilippo 157 Jun 6, 2022