stlkrn

C ++ STL ในไดรเวอร์ Windows

โครงการนี้ใช้ MSVC C ++ STL ในไดรเวอร์เคอร์เนล Windows ในโซลูชันนี้ jxystl.lib ถูกนำไปใช้เป็นเคอร์เนลที่ปรับแต่งประเภทพูล/แท็กรับรู้ไลบรารีเทมเพลตและการใช้งาน MSVC ซึ่งภายใต้ฮูดใช้ MSVC C ++ STL

# include < wdm.h >
# include < jxy/string.hpp >

extern " C "
NTSTATUS DriverEntry (
    PDRIVER_OBJECT DriverObject,
    PUNICODE_STRING RegistryPath)
{
    jxy::wstring<PagedPool, ' 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 "Driverstlkrn"
   RegistryPath = 0xffffca83`5227f000 "REGISTRYMACHINESYSTEMControlSet001Servicesstlkrn"
     helloWorld = "Hello, World!"

มาตรฐานที่รองรับ

มาตรฐาน	ที่ได้รับการสนับสนุน	หมายเหตุ
CPP11	เลขที่	ไม่ผ่านการทดสอบไมล์ของคุณแตกต่างกันไป
CPP14	ใช่
CPP17	ใช่
CPP20	ใช่

ไดรเวอร์ทดสอบในโซลูชันนี้ stdtest.sys เป็นที่ตั้งของการทดสอบหน่วยสำหรับโครงการ การทดสอบหน่วยจะทำงานในเคอร์เนลด้วยตัวตรวจสอบไดรเวอร์ เฟรมเวิร์กการทดสอบหน่วยเป็นกระดูกเปลือย แต่เพียงพอสำหรับการออกกำลังกาย jxystl.lib

ไดรเวอร์อื่นที่ใช้ในโซลูชันนี้ stdkrn.sys ทำให้ jxystl.lib ใช้ในสถานการณ์จริง มันใช้สิ่งอำนวยความสะดวกและภาชนะบรรจุ std Namespace ต่างๆ (ห่อภายใต้เนมสเป jxy ) ไดรเวอร์นี้ลงทะเบียนสำหรับกระบวนการเธรดและการแจ้งเตือนภาพ จากนั้นใช้ C ++ ที่ทันสมัยเพื่อติดตามบริบทของกระบวนการบริบทเธรดและบริบทของโมดูล

การจัดการข้อยกเว้น - vcrtl

การจัดการข้อยกเว้นช่วยให้วัตถุ C ++ สามารถผ่อนคลายได้เมื่อมีการโยนข้อยกเว้น นี่เป็นคุณสมบัติหลักของ C ++ ซึ่งได้รับความสนใจเพียงเล็กน้อยสำหรับไดรเวอร์เคอร์เนล Microsoft ไม่สนับสนุนข้อยกเว้น C ++ สำหรับไดรเวอร์เคอร์เนล

การจัดการข้อยกเว้น C ++ ทำได้โดย VCRTL Libraray ของ Avakar โครงการนี้จะทำงานได้มากกว่าโดยไม่ต้องมีส่วนร่วมที่ยอดเยี่ยมของ Avakar สำหรับข้อมูลเกี่ยวกับการจัดการข้อยกเว้นในไดรเวอร์ Windows ตรงไปที่ VCRTL GitHub ของ Avakar นอกจากนี้หน้านี้ยังให้รายละเอียดที่ยอดเยี่ยมเกี่ยวกับการจัดการข้อยกเว้นบน AMD64

การสนับสนุน MSVC C ++ STL - jxystl

การจัดสรรเคอร์เนล Windows เกี่ยวข้องกับพูลหน่วยความจำ นอกจากนี้การติดแท็กพูลจะถูกสร้างขึ้นในเคอร์เนล Windows การติดแท็กสระว่ายน้ำอำนวยความสะดวกในการติดตามการจัดสรรที่ทำโดยไดรเวอร์ สิ่งอำนวยความสะดวกในการติดแท็กนี้ช่วยให้สามารถทำการดีบักและตรวจสอบการจัดสรร

เนมสเปซ jxy ในโซลูชันนี้ช่วยให้การพัฒนาไดรเวอร์ Windows โดยใช้วัตถุ std เนมสเปซที่มีการพิมพ์พูลและการติดแท็ก

ห้องสมุดเลือกที่จะไม่ใช้ผู้ให้บริการ new / delete "Global" มันใช้เฉพาะผู้ให้บริการ new / delete ด้วยการพิมพ์พูลและความสามารถในการติดแท็ก สิ่งนี้ต้องการการระบุประเภทพูลและแท็ก หากมีการใช้ฟังก์ชันการทำงานบางอย่างที่ต้องใช้ "Global Allocator" มันจะไม่เชื่อมโยง นี่คือการตัดสินใจออกแบบโดยเจตนาเพื่อให้ไม่มีการจัดสรรทั่วโลกการจัดสรรทั้งหมดจะต้องระบุประเภทพูลและแท็ก

jxy namespace ใช้การจัดสรรและการลบซึ่งสอดคล้องกับมาตรฐานสำหรับใช้ในคอนเทนเนอร์เทมเพลต การจัดสรรและการลบเหล่านี้เป็นประเภทพูล/แท็กรับรู้ พวกเขาต้องการการระบุประเภทของพูลและแท็กและป้องกันการแปลง/การรีคืนข้ามประเภทเครื่องมือและแท็ก - ควรใช้แทนการจัดสรร STL

jxy::allocator<T, PagedPool, ' 0GAT ' >;
jxy::default_delete<T, PagedPool, ' 0GAT ' >;

jxystl.lib ใช้ฟังก์ชัน "เติม" ที่จำเป็นสำหรับการใช้คอนเทนเนอร์ MSVC STL การใช้งาน (ใน msvcfill.cpp ) มีความสำคัญกับเคอร์เนล ฟังก์ชั่นนี้ช่วยให้คอนเทนเนอร์ MSVC STL สามารถเชื่อมโยงไปยังฟังก์ชันการทำงานที่เหมาะสมกับเคอร์เนล นอกจากนี้ยังหมายความว่าหากมีการใช้ฟังก์ชันการทำงานของคอนเทนเนอร์ std บางอย่างที่ไม่มีฟังก์ชั่น "เติม" อยู่ด้านหลัง - ตัวเชื่อมโยงจะล้มเหลว นี่คือการตัดสินใจออกแบบโดยเจตนาเช่นการใช้งานใด ๆ ที่ใช้ในการใช้งานในเคอร์เนล

การเริ่มต้น CRT และฟังก์ชั่น atexit ไม่ได้รับการสนับสนุนโดยเจตนา คำสั่งของการเริ่มต้น CRT นั้นไม่ชัดเจนและไม่ชัดเจน เมื่อไดรเวอร์เคอร์เนลโหลดข้อมูลทั่วโลกควรตั้งค่าและฉีกขาดอย่างชัดเจนในระหว่างการโหลดไดรเวอร์และขนถ่าย การเริ่มต้น CRT ทั่วโลก "ซ่อน" การเริ่มต้นนี้ในลักษณะที่ไม่ชัดเจน นอกจากนี้ยังไม่รองรับฟังก์ชั่น CRT atexit การปล่อยการซิงโครไนซ์ที่จำเป็นเพื่อให้การเริ่มต้นแบบคงที่ในท้องถิ่นของวัตถุ C ++ ไม่ได้ทำโดยคอมไพเลอร์ และจะแนะนำการซิงโครไนซ์ที่ไม่ชัดเจนในเคอร์เนล การขาดการกำหนดค่าเริ่มต้น CRT และการสนับสนุน ATEXIT เป็นการตัดสินใจออกแบบโดยเจตนา ฉันขอแนะนำให้หลีกเลี่ยงเมื่อพัฒนาไดรเวอร์เคอร์เนล

ตัวอย่างเช่น jxy namespace "wraps" std::vector และกองกำลังใช้ประเภทพูลและแท็ก:

 namespace jxy
{

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

}

jxy::vector< int , PagedPool, ' 0GAT ' > integers;

 stlkrn!DriverEntry+0xea:
0: kd> dx integers
integers                 : { size=10 } [Type: std::vector<int,jxy::details::allocator<int,1,809976148> >]
    [<Raw View>]     [Type: std::vector<int,jxy::details::allocator<int,1,809976148> >]
    [capacity]       : 10
    [allocator]      : {...} [Type: std::_Compressed_pair<jxy::details::allocator<int,1,809976148>,std::_Vector_val<std::_Simple_types<int> >,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]

ด้านล่างนี้เป็นตารางการทำงานภายใต้เนมสเปซ jxy :

jxy	STL เทียบเท่า	รวม	หมายเหตุ
jxy::allocator	std::allocator	<jxy/memory.hpp>
jxy::default_delete	std::default_delete	<jxy/memory.hpp>
jxy::unique_ptr	std::unique_ptr	<jxy/memory.hpp>
jxy::shared_ptr	std::shared_ptr	<jxy/memory.hpp>
jxy::basic_string	std::basic_string	<jxy/string.hpp>
jxy::string	std::string	<jxy/string.hpp>
jxy::wstring	std::wstring	<jxy/string.hpp>
jxy::vector	std::vector	<jxy/vector.hpp>
jxy::map	std::map	<jxy/map.hpp>
jxy::multimap	std::miltimap	<jxy/map.hpp>
jxy::mutex	std::mutex	<jxy/locks.hpp>	ใช้ KGUARDED_MUTEX
jxy::shared_mutex	std::shared_mutex	<jxy/locks.hpp>	ใช้ EX_PUSH_LOCK
jxy::unique_lock	std::unique_lock	<jxy/locks.hpp>
jxy::shared_lock	std::shared_lock	<jxy/locks.hpp>
jxy::scope_resource	ไม่มี	<jxy/scope.hpp>	คล้ายกับ std::experimental::unique_resource
jxy::scope_exit	ไม่มี	<jxy/scope.hpp>	คล้ายกับ std::experimental::scope_exit
jxy::thread	std::thread	<jxy/thread.hpp>
jxy::deque	std::deque	<jxy/deque.hpp>
jxy::queue	std:queue	<jxy/queue.hpp>
jxy::priority_queue	std::priority_queue	<jxy/queue.hpp>
jxy::set	std::set	<jxy/set.hpp>
jxy::multiset	std::multiset	<jxy/set.hpp>
jxy::stack	std::stack	<jxy/stack.hpp>

การทดสอบ - stltest.sys

โครงการ stltest ใช้ไดรเวอร์ที่ใช้การทดสอบบางอย่างกับ JXYSTL การใช้ STL และข้อยกเว้นในเคอร์เนล Windows

การใช้งานจริง - stlkrn.sys

โครงการ stlkrn เป็นไดรเวอร์ Windows ที่ใช้ jxystl.lib เพื่อใช้กระบวนการเธรดและการติดตามโมดูลในเคอร์เนล Windows

stlkrn.sys ลงทะเบียนสำหรับกระบวนการเธรดและการแจ้งเตือนภาพโดยใช้ฟังก์ชั่นที่ส่งออกโดย ntoskrnl การใช้การเรียกกลับเหล่านี้จะติดตามกระบวนการเธรดและการโหลดภาพในวัตถุต่าง ๆ ที่ใช้ jxy::map , jxy::shared_mutex , jxy::wstring และอื่น ๆ

คนขับมีสองซิงเกิล jxy::ProcessMap และ jxy::ThreadMap สิ่งเหล่านี้จะถูกสร้างขึ้นเมื่อไดรเวอร์โหลด ( DriverEntry ) และฉีกขาดเมื่อไดรเวอร์ขนถ่าย ( DriverUnload ) เป็นที่น่าสังเกตว่าแต่ละกระบวนการติดตามใน jxy::ProcessMap (นำมาใช้เป็น jxy::ProcessContext ) ยังจัดการ jxy::ThreadMap แต่ละ "บริบท" ( jxy::ProcessContext , jxy::ThreadContext และ jxy::ModuleContext ) เป็นวัตถุที่แชร์ (อ้างอิง) ( jxy::shared_ptr ) ดังนั้นบริบทของเธรดที่มีอยู่ในแผนที่เธรด Singleton จึงเป็นบริบทเดียวกับที่เกี่ยวข้องกับบริบทของกระบวนการ

ส่วนประกอบสำคัญของ stlkrn.sys :

วัตถุ	วัตถุประสงค์	แหล่งที่มา	หมายเหตุ
jxy::ProcessContext	ข้อมูลสำหรับกระบวนการที่ทำงานบนระบบ	process_context.hpp/cpp	ใช้ jxy::wstring มีเธรด ( jxy::ThreadMap ) และโมดูล ( jxy::ModuleMap ) สมาชิกแผนที่
jxy::ThreadContext	ข้อมูลสำหรับเธรดที่ทำงานบนระบบ	thread_context.hpp/cpp	ใช้ std::atomic
jxy::ModuleContext	ข้อมูลสำหรับภาพที่โหลดในกระบวนการที่กำหนด	module_context.hpp/cpp	ใช้ jxy::wstring และ jxy::shared_mutex
jxy::ProcessMap	Singleton, แผนที่ที่ใช้ร่วมกัน jxy::ProcessContext วัตถุไปยัง PID	process_map.hpp/cpp	Singleton เข้าถึงได้ผ่าน jxy::GetProcessMap ใช้ jxy::shared_mutex และ jxy::map
jxy::ThreadMap	แผนที่ที่ใช้ร่วมกัน jxy::ThreadContext วัตถุไปยัง TID	thread_map.hpp/cpp	Global Thread Table (Singleton) สามารถเข้าถึงได้ผ่าน jxy::GetThreadMap แต่ละ jxy::ProcessContext ยังมีแผนที่เธรดที่เข้าถึงได้ผ่าน jxy::ProcessContext::GetThreads ใช้ jxy::shared_mutex และ jxy::map
jxy::GetModuleMap	แผนที่ที่ใช้ร่วมกัน jxy::ModuleContext ไปยังส่วนขยายของภาพที่โหลด (ที่อยู่ฐานและท้าย)	module_map.hpp/cpp	แต่ละบริบทกระบวนการมีสมาชิกแผนที่โมดูล ภาพที่โหลดสำหรับกระบวนการที่กำหนดจะถูกติดตามโดยใช้วัตถุนี้ ใช้ jxy::shared_mutex และ jxy::map

std::unordered_map น่าจะเป็นตัวเลือกที่ดีกว่าสำหรับต้นไม้ที่สั่ง ( std::map ) สำหรับแผนที่วัตถุ มีเหตุผลที่ไม่ได้ใช้ (ดูส่วนสิ่ง TODO )

 stlkrn!jxy::nt::CreateProcessNotifyRoutine+0xa6:
3: kd> dx proc
proc                 : {...} [Type: std::shared_ptr<jxy::ProcessContext>]
    [<Raw View>]     [Type: std::shared_ptr<jxy::ProcessContext>]
    [ptr]            : 0xffffaa020d73cf70 [Type: jxy::ProcessContext *]
    [control block]  : custom deleter, custom allocator [Type: std::_Ref_count_resource_alloc<jxy::ProcessContext *,jxy::details::default_delete<jxy::ProcessContext,1,1668307018>,jxy::details::allocator<jxy::ProcessContext,1,1668307018> > (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       : "DeviceHarddiskVolume4WindowsSystem32cmd.exe" [Type: std::basic_string<unsigned short,std::char_traits<unsigned short>,jxy::details::allocator<unsigned short,1,1852856394> >]
    [+0x030] m_FilePart       : "cmd.exe" [Type: std::basic_string<unsigned short,std::char_traits<unsigned short>,jxy::details::allocator<unsigned short,1,1886410826> >]
    [+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]

สิ่งที่ต้องทำ

ฉันต้องการรวม std::unordered_map ในขั้นต้นอย่างไรก็ตามมันใช้ ceilf เลขคณิตจุดลอยตัวในเคอร์เนล Windows มาพร้อมกับความท้าทายบางอย่าง ดังนั้นสำหรับตอนนี้มันถูกละเว้นจนกว่าจะมีการออกแบบวิธีแก้ปัญหาที่เหมาะสม

คำเตือน

โซลูชันนี้เป็นโครงการความหลงใหล ในเวลานี้มันไม่ได้มีไว้สำหรับรหัสการผลิต x64 ได้รับการทดสอบอย่างดีและมีเสถียรภาพ stlkrn.sys ผ่านตัวเลือกตัวเลือกไดรเวอร์เต็มรูปแบบ (รวมถึงการจำลองทรัพยากรต่ำแบบสุ่ม) การจัดการข้อยกเว้นที่หรือสูงกว่าการจัดส่งได้รับการทดสอบ แต่ไม่ได้อยู่ในกรณีการใช้งานจริง x86 ยัง ไม่ ได้รับการทดสอบ มีฟังก์ชั่นภายใต้เนมสเปซ jxy ที่ไม่สมบูรณ์/ไม่ได้ใช้/ยังไม่ได้ทดสอบ ระยะทางของคุณอาจแตกต่างกันไป - ฉันต้องการทำงานนี้ต่อไปในช่วงเวลาหนึ่งหากพบปัญหา/ข้อบกพร่องใด ๆ โปรดเปิดปัญหากับ repo นี้

งานที่เกี่ยวข้อง

โครงการนี้ให้การสนับสนุน STL ในเคอร์เนล Windows โดยใช้สิ่งอำนวยความสะดวก STL ให้ได้มากที่สุด มีวิธีแก้ปัญหาอื่น ๆ สำหรับการใช้ STL ในการพัฒนาเคอร์เนล ส่วนนี้จะร่างทางเลือกก่อนอื่นฉันจะสรุปงานนี้:

โครงการนี้:

• ใช้ STL โดยตรง ไม่ได้ ปรับปรุงฟังก์ชั่น STL ใด ๆ อีกครั้งเว้นแต่จำเป็นอย่างยิ่ง
• ต้องใช้ประเภทพูลและแท็ก ไม่มีการใช้ new หรือ delete ทั่วโลก
• ห้ามการเคลื่อนย้ายข้อมูลระหว่างวัตถุของพูลหรือแท็กที่แตกต่างกัน
• หลีกเลี่ยงการเริ่มต้น CRT และฟังก์ชั่น atexit ลำดับการเริ่มต้น CRT นั้นไม่ชัดเจนการเริ่มต้นของไดรเวอร์และการฉีกขาด ควรชัดเจน ฟังก์ชันการทำงาน atexit อาจแนะนำการแข่งขันข้อมูลสำหรับรหัสเคอร์เนลไม่ได้ใช้งาน atexit

Hypervisor Bareflank:

Bareflank ใช้การสนับสนุนสำหรับการเรียกใช้ C ++ ในไฮเปอร์ไวเซอร์ของพวกเขา พวกเขามีการสนับสนุน STL และ CRT เต็มรูปแบบ นี่เป็นโครงการที่ครอบคลุมซึ่งช่วยให้คุณสมบัติมากมายของมาตรฐานในโหมดเคอร์เนล (รวมถึงข้อยกเว้น) เมื่อฉันเข้าใจว่าการแก้ปัญหาของพวกเขาบังคับให้ NonPagedPool ในการจัดสรร new / delete ทั่วโลก ฉันต้องยกย่อง Bareflank ด้วยการใช้งานของพวกเขามันเป็นความคิดที่ดีและข้ามแพลตฟอร์ม อย่างไรก็ตามการใช้งาน Windows สร้างผ่าน Cygwin และ "Shims" เพื่อรองรับเคอร์เนล Windows ในการเปรียบเทียบโครงการนี้มีจุดมุ่งหมายที่จะคำนึงถึงเคอร์เนล Windows มันช่วยให้ระบุแท็กและประเภทพูล (เพจ vs ที่ไม่ใช่หน้าจอ) และหวังว่าจะลด "ขอบคม" ที่เกี่ยวข้องกับการใช้ C ++ และ STL ในโหมดเคอร์เนล ทั้งหมดที่กล่าวมา Bareflank นั้นน่าประทับใจสำหรับสิ่งที่ทำ สำหรับการนำเสนอที่ยอดเยี่ยมเกี่ยวกับการสนับสนุนของ Bareflank เกี่ยวกับ C ++ ฉันขอแนะนำให้ดูการนำเสนอของ Dr. Rian Quinn ที่ CPPCON 2016

Win32Kernelstl:

โครงการ Win32Kernelstl ช่วยให้คุณใช้ฟังก์ชัน STL โดยตรงในเคอร์เนล โครงการดำเนินการ new ทั่วโลก / delete และบังคับให้ NonPagedPool ทั่วโลกใช้การสนับสนุนการเริ่มต้น CRT และ BugChecks เมื่อมีการโยนข้อยกเว้น CPP มันไม่ได้พยายามที่จะทำข้อยกเว้น CPP ที่คลี่คลาย เนื่องจากสมมติฐานทำให้ฉันพบว่ามันไม่ได้ผลสำหรับกรณีการใช้งานที่ร้ายแรงใด ๆ รหัสมีความชัดเจนและบันทึกไว้อย่างสมเหตุสมผลฉันขอแนะนำให้โครงการนี้เรียกดูการให้ความรู้เกี่ยวกับการสนับสนุน C ++ ในเคอร์เนล หมายเหตุหนึ่งรหัส CRT ใน Win32Kernelstl ใช้งาน atexit แต่โปรดทราบว่าไม่มีการซิงโครไนซ์ที่ถูกปล่อยออกมาจากคอมไพเลอร์ที่นี่ (ตรงข้ามกับโหมดผู้ใช้) ดังนั้นการคงที่ในท้องถิ่นที่ต้องมีการแทรกรายการในรายการ atexit อาจแข่งกันทำให้เกิดสองครั้งหรือไม่ฟรีสองครั้ง

Driver Plus:

โครงการนี้ใช้สิ่งอำนวยความสะดวก C ++ ที่จำเป็นสำหรับการดึงโซลูชัน C ++ จำนวนมากเข้าสู่โหมดเคอร์เนล ( EASTL , msgpack ฯลฯ ) Driver Plus ใช้การเริ่มต้น CRT และการสนับสนุน new / delete ทั่วโลก (ซึ่งบังคับให้ NonPagedPool ) อีกครั้งนี่คือการตอบสนองต่อเป้าหมายของโครงการนี้ อย่างไรก็ตามโครงการนี้เปิดใช้งานสิ่งอำนวยความสะดวก C ++ ที่ยอดเยี่ยมมากมายสำหรับใช้ในโหมดเคอร์เนล มันทำการปรับเปลี่ยนโซลูชัน C ++ ที่ดึงเข้ามาเพื่อสนับสนุนกรณีการใช้งาน Driver Plus ยังทำให้สมมติฐานเกี่ยวกับ atexit ดังที่ได้กล่าวไว้ก่อนหน้านี้

ktl - dymok93

KTL (Library เทมเพลตเคอร์เนล Windows โดย Dymok93) นำเสนอ C ++ ที่ทันสมัยในปริมาณที่ดีและกำลังพัฒนาการสนับสนุนมากขึ้นสำหรับการใช้งานในเคอร์เนล Windows นอกจากนี้ยังมีการสนับสนุนสำหรับ RAII รอบ ๆ เคอร์เนลดั้งเดิมหลายแห่งให้การสนับสนุน ANSI_STRING แบบดั้งเดิมและ UNICODE_STRING ซึ่งให้การห่อหุ้มที่มีประโยชน์สำหรับการลงทะเบียนการเรียกกลับเคอร์เนลและคุณสมบัติความสะดวกสบายรอบ ๆ เคอร์เนล Windows มันใช้งาน new / delete ทั่วโลกและมีคำจำกัดความของตัวประมวลผลล่วงหน้า ( KTL_USING_NON_PAGED_NEW_AS_DEFAULT ) สำหรับการสลับระหว่างค่าเริ่มต้นหรือไม่ใช่เพจซึ่งเป็นสิ่งที่ดี อย่างไรก็ตามมันใช้แท็กพูลเดียว ( KTL_HEAP_TAG ) นอกจากนี้เทมเพลตการจัดสรรที่มีอยู่จะไม่เปิดใช้งานนักพัฒนาเพื่อระบุแท็กพูลดังนั้นการใช้ไลบรารีนี้เป็นสาเหตุที่ทำให้การจัดสรรทั้งหมดถูกแท็กด้วยแท็กสระเดียวกัน ที่กล่าวว่ามันจะสมเหตุสมผลที่จะใช้ตัวจัดสรรที่กำหนดเองที่ให้อำนาจในการติดตั้งการจัดสรร ห้องสมุดมีการสนับสนุนข้อยกเว้นแม้ว่าจะมีเพียง x64 เท่านั้น การสนับสนุนข้อยกเว้นใน KTL ขึ้นอยู่กับ Avakar's พร้อมการปรับปรุงและการแก้ไข ฉันขอชมเชยงานที่นี่และฉันประทับใจกับปริมาณของสิ่งอำนวยความสะดวกที่มีอยู่มันมีคุณสมบัติที่เต็มไปด้วยพอสมควรและอยู่ภายใต้การพัฒนาที่ใช้งานอยู่ ฉันต้องการสำรวจโดยใช้มันมากขึ้นในอนาคตและอาจร่วมมือกันในการสนับสนุนข้อยกเว้นที่ดีกว่าสำหรับทั้ง stlkrn และ KTL การปรับปรุงฟังก์ชันการทำงานของ STL การขาดการสนับสนุนการติดแท็กสระว่ายน้ำพื้นเมืองและการจัดสรรทั่วโลกเป็นสิ่งที่ตอบสนองต่ออุดมการณ์ของโครงการนี้

KTL - Meesong:

KTL (Library เทมเพลตเคอร์เนล Windows โดย Meesong) เปิดใช้งานการทำงานของฟังก์ชัน C ++ ที่ทันสมัยจำนวนมากสำหรับใช้ในเคอร์เนล Windows นอกจากนี้ยังใช้ new / delete ทั่วโลก แต่ทำงานได้ดีในการจัดหาสิ่งอำนวยความสะดวกสำหรับการระบุแท็กสระว่ายน้ำและประเภทที่เป็นไปได้ อย่างไรก็ตามนี่หมายความว่าผู้จัดสรรทั่วโลกอาจซ่อนการจัดสรรในกลุ่มที่ไม่ชัดเจน นอกจากนี้การจัดสรรเทมเพลตในโครงการนี้มีค่าใช้จ่ายสองจุดสำหรับวัตถุจัดสรรและวัตถุเจือจางฉันยังกังวลว่าการแปลงระหว่างประเภทการจัดสรรอาจอนุญาตให้มีการจัดสรร/FREES ข้ามพูล/แท็ก โดยรวมฉันประทับใจกับปริมาณของสิ่งอำนวยความสะดวกที่ดำเนินการที่นี่ การปรับปรุงฟังก์ชั่น STL ใหม่และผู้จัดสรรทั่วโลกนั้นเป็นสิ่งที่ตรงกันข้ามกับอุดมการณ์ของโครงการนี้

เคอร์เนลบริดจ์:

Kernel-Bridge ใช้สิ่งอำนวยความสะดวกที่ยอดเยี่ยมสำหรับการพัฒนาเคอร์เนล Windows ไลบรารีให้ wrappers สำหรับการลงทะเบียนสำหรับการเรียกกลับของ Windows โดยใช้วัตถุ C ++ ฉันต้องการหาเวลามากขึ้นในการใช้และตรวจสอบโซลูชันนี้ มันใช้การสนับสนุน CRT ฟังก์ชั่น atexit ที่ใช้งานไม่ใช่แบบไดนามิก - มันใช้อาร์เรย์แบบคงที่หากมันหมดช่องว่างมันก็ล้มเหลว กองกำลัง new / delete เริ่มต้น NonPagedPool มันไม่มีการสนับสนุนข้อยกเว้นเต็มรูปแบบมันจะ bugcheck หากมีการโยนข้อยกเว้น CPP - มันจะไม่ผ่อนคลายวัตถุบนสแต็ก

การให้เครดิต

ที่เก็บนี้ดึงมาจากงานที่มีอยู่ก่อน เครดิตกับผู้แต่ง

• ข้อยกเว้น C ++ ในไดรเวอร์ Windows
  โครงการนี้ใช้ส่วนหนึ่งของห้องสมุด Visual Studio Runtime ที่จำเป็นสำหรับการจัดการข้อยกเว้น C ++ ปัจจุบันรองรับแพลตฟอร์ม x86 และ x64
• ประมวลผลส่วนหัว API ของแฮ็กเกอร์
  การรวบรวมไฟล์ส่วนหัว API ดั้งเดิม รวบรวมจากไฟล์ส่วนหัวของ Microsoft และไฟล์สัญลักษณ์รวมถึงวิศวกรรมย้อนกลับและการคาดเดาจำนวนมาก