DOS不能工作在保護模式
讓CPU工作在保護模式很容易，但CPU工作在保護模式時你無法調用DOS和BIOS服務，為什麼呢？因為DOS和BIOS的代碼是按照在真實模式下運行的方式寫的，不符合保護模式程式的規範，比如，在真實模式下，DOS下的程式碼可以把任意數值放到段寄存器（CS、DS、ES、SS）中，只要不超過64K就可以，但在保護模式下，段寄存器只能放一個已經存在的selector的值，任何其它的值都將引起一個“General Protection Fault”錯誤異常。
所以，如果程式讓CPU進入保護模式，並且調用DOS服務，比如列印一行資訊，將馬上使系統崩潰，如果你不明白這一點，恐怕連一個最簡單的“Hello World”程式都寫不出來。
更糟糕的是，雖然應用程式不能調用DOS和BIOS服務，但DOS和BIOS卻必須要運行，比如時鐘晶片產生的硬體中斷，每秒18.2次的時鐘中斷等，時鐘中斷是BIOS的一部分，工作在真實模式。
所以，哪怕程式不調用任何真實模式代碼，一些非同步的系統事件仍然會發生，機器仍然會很快崩潰，所以，要在DOS下進入保護模式，必須首先解決DOS/BIOS和保護模式之間的這種衝突。
DOS Extender允許DOS和保護模式共存
如果你不想寫一個保護模式下的作業系統來完全取代DOS和BIOS，解決衝突的辦法是在你的應用程式和DOS/BIOS之間加入一個軟體層，這個軟體層可以視情況讓CPU在真實模式和保護模式之間切換，這個軟體層叫做DOS Extender。
在DOS Extender下，當保護模式下的程式要調用真實模式下的服務時，Extender給這個調用設置一個陷阱，把CPU切換到真實模式，再重新發出 這個調用，等待其完成調用，然戶再切換回保護模式，並返回到那個調用真實模式代碼的應用程式中，像時鐘中斷、鍵盤這樣的硬體中斷，也會被Extender設 置一個陷阱，並產生保護模式到真實模式的切換和返回。
你可能會想，這種方式會使應用程式運行變的很慢，然而在實際應用中，大多數程式並不會頻繁地調用OS的服務，即使調用很多，由於大多數的OS服務都是存取外部設備，比如硬碟，而這些設備的速度比起CPU而言是非常慢的，所以很少有人注意到模式切換上的系統開銷。
DJGPP v1.X和go32 Extender
在DJGPP v1.x中使用的go32程式，就是這樣一個DOS Extender，每個程式啟動時都會自動地裝載go32，go32除了完成DOS Extender的任務外，還接管下面一些與DJGPP相關的任務。
• 裝載應用程式，並為運行做好準備
由於DJGPP的執行檔使用COFF格式，DOS看不懂這種格式，go32負責讀取 COFF頭並初始化代碼、資料和其它檔頭中的分段
• 提供UNIX形式的命令列擴展
• 保護模式下浮點運算模擬
• 圖形支援
go32中有一些特殊的代碼，使其能夠適應各種各樣的進入保護模式的方法並管理擴展記憶體，所以他可以工作在任何DOS配置下，但這也使其產生一些不能忽視的缺陷，就是Extender必須被裝入常設記憶體，並且每個程式實例大約要佔用130KB的記憶體，大多數情況下DOS啟動以後都會有500-600K剩餘的常設記憶體，這意味著一個DJGPP程式只能有3-4級的嵌套。這是一個很嚴重的限制，DJGPP v2.x已經解決了這個問題。
DJGPP v2.X與DPMI服務
DJGPP v2.x放棄了Extender，取而代之的是需要一個已經運行的DPMI服務，DPMI：DOS Protected-Mode Interface的縮寫，是一個特殊的API，它允許保護模式的應用程式在DOS的上層運行，他定義了 一些函數，使保護模式下的程式（稱為DPMI客戶）可以做一些諸如：進入保護模式、分配記憶體和段描述符、調用真實模式的服務、連接中斷等等，許多使用 Intel CPU的作業系統都有DPMI服務，包括windows的所有版本，OS/2，以及LINUX DOS模擬器都是著名的例子，還有一些持有專 利的DOS下的DPMI伺服器，通常和DOS的記憶體管理器捆綁在一起，比如QEMM和386MAX，FreeDOS 也包含有一個DPMI伺服器作為缺省設置的一部分，對於那些沒有DPMI伺服器的系統，DJGPP v2.x提供一個免費的DPMI伺服器，叫做 CWSDPMI，CWSDPMI很多地方使用了go32的代碼，DJGPP啟動代碼檢查DPMI服務，如果沒有，將自動搜索並載入 cwsdpmi.exe----CWSDPMI伺服器。
DPMI伺服器（又稱為DPMI HOST）可以解決運行在DOS上層的保護模式程式的大部分問題，餘下的那些在1.x版本中由go32完成的函數，在v2.x中被DJGPP的啟動代碼接管並放在低級函式程式庫中，下面簡短地說一下DJGPP啟動代碼的兩個特點。
DJGPP v2.x的啟動代碼
DJGPP v2.x啟動代碼包括兩部分：短小的裝載程式和庫啟動模組，前者是由組合語言寫成，是一段有特殊作用的組合語言程式，叫做djasm，它是一段 16-bit的DOS可執行程式，這個短小的裝載程式會被連結到每一個DJGPP程式中，是唯一一部分可以被DOS識別的部分，其餘部分----COFF 可執行文檔----在DOS看來只是一些奇怪的資料。
第二部分是一個庫模組，它包括許多模組，有些用C寫成，有些用彙編寫成，當裝載程式把程式調入並初始化完成後，這裡就是COFF格式程式的入口點。
裝載程式完成以下工作：
• 為傳輸緩衝區申請記憶體
這個緩衝區用於在DOS服務和程式之間傳送資料。
• 檢查是否DPMI服務已經運行
以下兩種情況說明DPMI已經啟動
(1)有一個常駐記憶體的DPMI伺服器，比如windows中內置的DPMI伺服器
(2)當前程式是一個嵌套的DJGPP程式，他的父程式已經啟動了CWSDPMI
如果DPMI服務還沒有啟動，則裝入CWSDPMI。首先在目前的目錄下搜索cwsdpmi.Exe， 然後到環境變數PATH指定的目錄下去查找。
• 把COFF可執行部分的檔頭裝入記憶體
需要知道要為DJGPP程式申請多少記憶體
• 調用DPMI host提供的入口點，把CPU切換到保護模式
注意：裝入程式的其餘部分運行在保護模式下
• 為程式碼和資料申請記憶體空間
通過DPMI的功能調用可以為代碼和資料申請段描述符和記憶體空間，並設置基底位址、 界限和許可權。
• 把COFF格式的可執行部分調入記憶體
通過DPMI服務調用DOS（主要指檔操作）服務，把代碼、資料和BSS節讀入上 面申請的記憶體中，DPMI服務允許你從保護模式下調用真實模式下的服務。
• 跳轉到COFF鏡像的入口點執行
這個入口點在上面提到過的庫啟動模組中。
下面是庫啟動代碼部分完成的工作
• 生成一個不受約束的空頁
這將產生一個NULL Pointer dereference的錯誤，並將觸發一個異常處理，程式 會收到SIGSEGV信號，但這個功能並非基本DPMI 0.9規範中的一部分，所以 windows和其它許多有專利的DPMI伺服器並不支持這個功能，但CWSDPMI支援這 一功能。
• 改變申請記憶體的資料段的大小
這個聽起來簡單，但由於DPMI記憶體調用的特殊性，實際上是非常複雜的，例如： 它需要把一段真實模式下的16-bit代碼調入常設記憶體的緩衝區並運行。
• 設置程式的堆疊
DJGPP程式堆疊的缺省大小是512KB，但應用程式或改變設置都可以改變堆疊大小
• 為存取常設記憶體申請selector
與DOS/BIOS函數之間傳遞資料，或者像視頻界面上的顯示緩衝區那種使用記憶體 映射的設備，許多DOS程式需要存取常設記憶體，但由於在缺省情況下，常設記憶體並 沒有映射在程式的資料段中，為了存取常設記憶體，使用了一個特殊的selector---- _dos_ds。
• 初始化信號管理
需要連結一些硬體中斷，例如：按下CTRL-
• 拷貝程式的環境變數到environ[]陣列中
• 讀出定義了DJGPP附加環境變數的檔
• 獲得並解釋命令列參數
• 如果需要，設置x87 FPU並載入浮點運算模擬器
• 調用靜態構造函數
• 調用用用程式的主函數
沒有留言:
張貼留言