1.8驅(qū)動代碼中和區(qū)別-24課

1、1.8 驅(qū)動代碼中C和C+代碼區(qū)別-24課A、函數(shù)調(diào)用約定 B、C和C+編譯方式C、用C+方式編譯驅(qū)動 D、C代碼升級至C+E、優(yōu)化21課的代碼課時：16分*.c當(dāng)文件后綴名為*.c時 編譯器將會用C編譯器方式編譯*.cpp當(dāng)文件后綴名為*.cpp時 編譯器將會用C+編譯器方式編譯區(qū)別:解決辦法在需要用到C方式編譯的函數(shù)前加extern C需要用C方式編譯的頭文件做如下修改#pragma once #ifdef cplusplus extern C#endif#include /這里包含需要用C方式編譯的頭文件 #ifdef cplusplus#endif1errors in director

2、y g:驅(qū)動教程024_驅(qū)動代碼中c和c+代碼區(qū)別mini_ddk 1mini_ddk.obj : error LNK2001: unresolved external symbol struct_ServiceDescriptorTable * KeServiceDescriptorTable (?KeServiceDescriptorTable3PAU_ServiceDescriptorTableA) 1bufferoverflowk.lib(gs_support.obj) : error LNK2019: unresolved external symbol _DriverEntry8

3、referenced in function _GsDriverEntry8 1sysi386ddk_helloworld.sys : error LNK1120: 2 unresolved externals?DriverEntryYGJPAU_DRIVER_OBJECTPAU_UNICODE_STRINGZ_DriverEntry8 /要求格式?DriverEntryYGJPAU_DRIVER_OBJECTPAU_UNICODE_STRINGZ?實例 修改21課的代碼 升級到C+編譯模式A、為入口函數(shù) 添加extern C B、修改Source文件C、修改21課的BUGextern C d

4、eclspec(naked) stdcalltest(int a, int b)前面已經(jīng)完成了初級內(nèi)核代碼的編寫，已經(jīng)是一個小巧完整的驅(qū)動文件了，本節(jié)課要講解一下理論知識。編譯器認(rèn)死理兒，載入文件時.C就按C方式.CPP就按C+方式。我們將之前的.C文件改成.CPP,再用BUILD編譯一下就發(fā)現(xiàn)了一大堆的錯誤,解決的辦法寫在教案中.將代碼加入頭文件再次編譯后只剩下3個錯誤,頭文件的錯誤已經(jīng)沒有了,再看下錯誤信息(教案中的紅字).大概是說函數(shù)符號沒有找到,另外入口函數(shù)也沒找到,總體上是LINK鏈接錯誤,所以在這兩個函數(shù)前也要加入extern C按照C方式編譯.然后看一下mini_ddl.obj里

5、入口函數(shù)被替換成了一個長串的入口函數(shù)?DriverEntryYGJPAU_DRIVER_OBJECTPAU_UNICODE_STRINGZ ?在 C 方式的時候是原來的入口函數(shù)_DriverEntry8雖然 DDK 方式編譯成功了,但是在 VC+中還是提示錯誤,這是一個非常經(jīng)典的錯誤,我們在 屬性頁 - C/C+ - 高級 -編譯為 里面設(shè)置為”默認(rèn)”或者”編譯為 C+代碼”.還有在上節(jié)課的測試中有一個 BUG,因為在卸載函數(shù)中是直接恢復(fù)代碼,應(yīng)該加上一個判斷,如果在未HOOK 的情況下就不要再做代碼恢復(fù)了.比如在虛擬機里測試前面課程的代碼在卸載的時候就藍(lán)屏了,而更改后的代碼就不會藍(lán)屏了.前面我