為了驗證設計可行性，一般我會先快速建模，用delphi實驗一下，因為VCL和編譯器以及OO的思想使得模型實現起來非常快，尤其自帶基礎型別String非常好用而且速度極快，但是原始碼裡是看不到的，編譯器自動支援，然而在測試大規模hook api的時候，字串操作會偶爾缺失中間的某個位元組，這就是我為何不相信第三方庫的原因了，在追影C實現的掛鉤模組中，我沒有使用任何第三方庫(記錄模組使用了cuckoo monitor，掛鉤模組和記錄器是兩個東西)，甚至連memcpy這些都自己用匯編做了實現，使得掛鉤模組中的一切可控，隨時知道問題出在哪裡。在底層的開發中，任何黑箱對我來說都是一種隱患，當出問題的時候我不得不開啟每個黑箱，去審計大量的第三方程式碼，事實上也不止一次發現第三方程式碼中存在大量問題。也是帶著這種懷疑精神，我逆向了編譯器是如何實現其自帶的string型別。

結果如下：

struct unicodestring{

dword reference;

dword length;

word content[];

}

跟COM的做法有點類似。每次進入有字串型別的函式前，編譯器自動加上一個增加引用的呼叫，退出函式前減少引用。我推測在引用為0的時候會釋放記憶體，跟COM的做法一樣。而通過反彙編發現，實際上字串變數內的地址指向的是content的地址，而不是unicodestring的地址，編譯器通過content地址的偏移去操作reference和length，由於提前知道了長度，比通過檢查\0結尾，把整個串擼一遍的字串操作要快的多。