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

1、1.8 驅(qū)動(dòng)代碼中C和C+代碼區(qū)別-24課A、函數(shù)調(diào)用約定 B、C和C+編譯方式C、用C+方式編譯驅(qū)動(dòng) D、C代碼升級(jí)至C+E、優(yōu)化21課的代碼課時(shí)：16分*.c當(dāng)文件后綴名為*.c時(shí) 編譯器將會(huì)用C編譯器方式編譯*.cpp當(dāng)文件后綴名為*.cpp時(shí) 編譯器將會(huì)用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ū)動(dòng)教程024_驅(qū)動(dòng)代碼中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?實(shí)例 修改21課的代碼 升級(jí)到C+編譯模式A、為入口函數(shù) 添加extern C B、修改Source文件C、修改21課的BUGextern C d

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

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