@@ -134,23 +134,36 @@ integers : { size=10 } [Type: std::vector<int,jxy::details::allo
134
134
135
135
Below is table of functionality under the ` jxy ` namespace:
136
136
137
- | jxylib | STL equivalent | Notes |
138
- | ------ | -------------- | ----- |
139
- | ` jxy::allocator ` | ` std::allocator ` | |
140
- | ` jxy::default_delete ` | ` std::default_delete ` | |
141
- | ` jxy::unique_ptr ` | ` std::unique_ptr ` | |
142
- | ` jxy::shared_ptr ` | ` std::shared_ptr ` | |
143
- | ` jxy::basic_string ` | ` std::basic_string ` | |
144
- | ` jxy::string ` | ` std::string ` | |
145
- | ` jxy::wstring ` | ` std::wstring ` | |
146
- | ` jxy::vector ` | ` std::vector ` | |
147
- | ` jxy::map ` | ` std::map ` | |
148
- | ` jxy::mutex ` | ` std::mutex ` | Uses ` KGUARDED_MUTEX ` |
149
- | ` jxy::shared_mutex ` | ` std::shared_mutex ` | Uses ` EX_PUSH_LOCK ` |
150
- | ` jxy::unique_lock ` | ` std::unique_lock ` | |
151
- | ` jxy::shared_lock ` | ` std::shared_lock ` | |
152
- | ` jxy::scope_resource ` | None | Similar to ` std::experimental::unique_resource ` |
153
- | ` jxy::scope_exit ` | None | Similar to ` std::experimental::scope_exit ` |
137
+ | jxylib | STL equivalent | Include | Notes |
138
+ | ------ | -------------- | ------- | ----- |
139
+ | ` jxy::allocator ` | ` std::allocator ` | ` <jxy/memory.hpp> ` | |
140
+ | ` jxy::default_delete ` | ` std::default_delete ` | ` <jxy/memory.hpp> ` | |
141
+ | ` jxy::unique_ptr ` | ` std::unique_ptr ` | ` <jxy/memory.hpp> ` | |
142
+ | ` jxy::shared_ptr ` | ` std::shared_ptr ` | ` <jxy/memory.hpp> ` | |
143
+ | ` jxy::basic_string ` | ` std::basic_string ` | ` <jxy/string.hpp> ` | |
144
+ | ` jxy::string ` | ` std::string ` | ` <jxy/string.hpp> ` | |
145
+ | ` jxy::wstring ` | ` std::wstring ` | ` <jxy/string.hpp> ` | |
146
+ | ` jxy::vector ` | ` std::vector ` | ` <jxy/vector.hpp> ` | |
147
+ | ` jxy::map ` | ` std::map ` | ` <jxy/map.hpp> ` | |
148
+ | ` jxy::multimap ` | ` std::miltimap ` | ` <jxy/map.hpp> ` | |
149
+ | ` jxy::mutex ` | ` std::mutex ` | ` <jxy/locks.hpp> ` | Uses ` KGUARDED_MUTEX ` |
150
+ | ` jxy::shared_mutex ` | ` std::shared_mutex ` | ` <jxy/locks.hpp> ` | Uses ` EX_PUSH_LOCK ` |
151
+ | ` jxy::unique_lock ` | ` std::unique_lock ` | ` <jxy/locks.hpp> ` | |
152
+ | ` jxy::shared_lock ` | ` std::shared_lock ` | ` <jxy/locks.hpp> ` | |
153
+ | ` jxy::scope_resource ` | None | ` <jxy/scope.hpp> ` | Similar to ` std::experimental::unique_resource ` |
154
+ | ` jxy::scope_exit ` | None | ` <jxy/scope.hpp> ` | Similar to ` std::experimental::scope_exit ` |
155
+ | ` jxy::thread ` | ` std::thread ` | ` <jxy/thread.hpp> ` | |
156
+ | ` jxy::deque ` | ` std::deque ` | ` <jxy/deque.hpp> ` | |
157
+ | ` jxy::queue ` | ` std:queue ` | ` <jxy/queue.hpp> ` | |
158
+ | ` jxy::priority_queue ` | ` std::priority_queue ` | ` <jxy/queue.hpp> ` | |
159
+ | ` jxy::set ` | ` std::set ` | ` <jxy/set.hpp> ` | |
160
+ | ` jxy::multiset ` | ` std::multiset ` | ` <jxy/set.hpp> ` | |
161
+ | ` jxy::stack ` | ` std::stack ` | ` <jxy/stack.hpp> ` | |
162
+
163
+ ## Tests - ` stltest.sys `
164
+
165
+ The ` stltest ` project implements a driver that runs some tests against jxystl,
166
+ usage of STL, and exceptions in the Windows Kernel.
154
167
155
168
## Practical Usage - ` stlkrn.sys `
156
169
The ` stlkrn ` project is a Windows Driver that uses ` jxylib ` to implement
@@ -227,6 +240,75 @@ use cases. `x86` has *not* been tested. There is functionality under the
227
240
I would like to continue this work over time, if any issues/bugs are found
228
241
feel free to open issues against this repo.
229
242
243
+ ## Related Work
244
+
245
+ This project provides STL support in the Windows Kernel by using as much of the
246
+ STL facility as possible. There are other solutions for use of STL in kernel
247
+ development. This section will outline alternatives, first I will summarize
248
+ this work:
249
+
250
+ This Project:
251
+ - Uses the STL directly. Does ** not** reimplement any STL functionality unless absolutely necessary.
252
+ - Requires pool types and tags. No global ` new ` or ` delete ` is implemented.
253
+ - Forbid moving data between objects of different pools or tags.
254
+ - Avoids CRT initialization and ` atexit ` functionality. CRT initialization order
255
+ is non-obvious, driver initialization and teardown * should be obvious* . ` atexit ` functionality
256
+ may introduce data races for kernel code, ` atexit ` is not implemented.
257
+
258
+ [ Bareflank Hypervisor] [ github.bareflank ] :
259
+
260
+ Bareflank implements support for running C++ in their hypervisor. They have full STL and CRT
261
+ support. This is a comprehensive project that enables a plethora features of the standard in
262
+ kernel mode (including exceptions). As I understand their solution forces ` NonPagedPool ` on global
263
+ ` new ` /` delete ` allocations. I have to commend Bareflank with their implementation, it's well
264
+ thought out and cross platform. However the Windows implementation builds through cygwin and
265
+ "shims" in support for the Windows kernel. In comparison, this project aims to be considerate to
266
+ the Windows kernel. It enables specifying pool tags and types (paged vs non-paged) and hopes
267
+ to minimize "sharp edges" associated with using C++ and the STL in kernel mode. All that said,
268
+ Bareflank is impressive for what is does. For an excellent presentation on Bareflank's support of
269
+ C++ I highly recommend watching [ Dr. Rian Quinn's presentation at cppcon 2016] [ channel9.bareflank ] .
270
+
271
+ [ Win32KernelSTL] [ github.Win32KernelSTL ] :
272
+
273
+ The Win32KernelSTL project does allow you to use STL functionality directly in the kernel. The project
274
+ implements global ` new ` /` delete ` and forces ` NonPagedPool ` , it implements CRT initialization support,
275
+ and bugchecks when a cpp exception is thrown. It makes no attempt to do cpp exception unwinding. Due
276
+ to the assumptions it makes I find it unpractical for any serious use cases. The code is reasonably
277
+ clear and documented, I recommend giving this project a browse for educating around C++ support in the
278
+ kernel. One note, the CRT code in Win32KernelSTL does implement ` atexit ` but keep in mind there is no
279
+ synchronization emitted by the compiler here (as opposed to user mode). So a local static requiring
280
+ insertion of an entry in the ` atexit ` list may race causing a double-init or double-free.
281
+
282
+ [ Driver Plus Plus] [ github.dxx ] :
283
+
284
+ This project implements necessary C++ facility for pulling in a number of C++ solutions into
285
+ kernel mode (` EASTL ` , ` msgpack ` , etc.). Driver Plus Plus implements CRT initialization and global
286
+ ` new ` /` delete ` support (which forces ` NonPagedPool ` ). Again this is counter to the goals of this
287
+ project. However, this project does enable a lot of great C++ facility for use in kernel mode. It
288
+ does make modifications to the C++ solutions it pulls in to shim in support for it's use cases.
289
+ Driver Plus Plus also makes the assumption around ` atexit ` as mentioned previously.
290
+
291
+ [ KTL] [ github.ktl ] :
292
+
293
+ KTL (Windows Kernel Template Library) reimplements a good amount of modern C++ functionality for
294
+ use in the Windows Kernel. It also implements global ` new ` /` delete ` but does a decent job
295
+ at providing facility for specifying pool tags and types where possible. However this does mean
296
+ the global allocator might hide an allocation in a non-obvious pool. Further the template
297
+ allocators in this project carry the cost of two points for an allocator and deallocator object,
298
+ I am also concerned that conversion between the allocator types may allow for cross pool/tag
299
+ allocs/frees. Overall I'm impressed by the amount of facility that is implemented here.
300
+ Reimplementation of STL functionality and the global allocators are counter to the ideologies of
301
+ this project.
302
+
303
+ [ Kernel-Bridge] [ github.KernelBridge ] :
304
+
305
+ Kernel-Bridge implements some great facility for Windows Kernel development. The library provides
306
+ wrappers for registering for Windows callbacks using C++ objects. I would like to find more time
307
+ to use and investigate this solution. It does implement CRT support. The ` atexit ` functionality
308
+ implemented is not dynamic - it uses a static array, if it runs out of slots, it fails. The
309
+ default ` new ` /` delete ` forces ` NonPagedPool ` . It does not have full exception support, it will
310
+ bugcheck if a cpp exception is thrown - it will not unwind objects on the stack.
311
+
230
312
## Credits
231
313
This repository draws from some preexisting work. Credits to their authors.
232
314
@@ -242,3 +324,9 @@ symbol files, as well as a lot of reverse engineering and guessing.
242
324
[ github.vcrtl ] : https://github.com/avakar/vcrtl
243
325
[ github.vcrtl.x64 ] : https://github.com/avakar/vcrtl/tree/master/src/x64
244
326
[ github.phnt ] : https://github.com/processhacker/phnt
327
+ [ github.bareflank ] : https://github.com/Bareflank/hypervisor
328
+ [ 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
329
+ [ github.Win32KernelSTL ] : https://github.com/DragonQuestHero/Win32KernelSTL
330
+ [ github.dxx ] : https://github.com/sidyhe/dxx
331
+ [ github.ktl ] : https://github.com/MeeSong/KTL
332
+ [ github.KernelBridge ] : https://github.com/HoShiMin/Kernel-Bridge
0 commit comments