在許多電腦的硬體架構中，為了不讓程式任意存取任何資源（例如隨機存取儲存器RAM），大部分的CPU架構都支援Kernel mode與User mode兩種執行模式，當然這種模式也得要OS有相關實際配合才有作用，像DOS就沒有Kernel/User mode的分別，所有以DOS執行的程式都可對任意資源執行任何行為，所以DOS上的病毒才能那麼囂張，動不動就格式化硬碟。　　一般來說， 應用程式是在User mode中執行程式，普通的數值計算或變數指派都可以在此模式完成，但是若要執行一些危及系統安全的指令（例如對磁碟寫入資料），而這些指令是不準在User mode中執行的，強要執行那些特殊指令只會讓系統給你一個錯誤資訊而已，應用程式必須呼叫一些OS定義好的函式才能達成那些功能，例如printf()，這些OS事先定義好的函式我們稱為system call（系統呼叫）。　　當應用程式執行了system call，並不是傻傻地讓應用程式想做什麼就做什麼，他們首先會嚴密地檢查這個呼叫的應用程式的許可權以及操作的內容（是否讀取不屬於自己的儲存器範圍，是否讀寫沒有許可權讀寫的檔案，是否想把資料往錯誤的裝置送過去......），若是有任何錯誤，system call將會停止執行並回傳一個錯誤代號，讓應用程式知道自己錯在何處。相反地一切檢查都沒問題，system call將會通知CPU進入Kernel mode，並依照應用程式送過來的引數執行特權指令。當特權指令執行完畢，system call將會通知CPU返回User mode，並回到應用程式中。　　Kernel/User mode架構是非常普遍的執行模式，幾乎可以在任何機器上看到這套架構，從電腦到機上盒，刷卡機等等電子商品，為了保護某些特別的指令不被搞不清楚狀況的程式開發者亂玩，OS開發者通常藉由定義system call告訴開發者們，哪些行為必須經過OS的過濾才能執行。　　當然Linux等Open source kernel的開發者可以自行定義並增加system call的數量， 豐富OS與應用程式的溝通介面，不過這種修改得經過非常小心的計劃與測試，因為在system call裡面執行的程式若是有錯，很可能讓整個OS崩潰（宕機）！例如許多沒有Open source的驅動程式（xVidia，ATx之類的顯示卡），由於Kernel的開發者無從得知那些驅動程式的演演算法，所以也無法保證那些驅動程式會不會讓Kernel執行到一半掛掉。　　事實上，所有第三方撰寫的驅動程式都會有這種問題，Windows常常被人臭罵有時候真的是無辜的，一切都是因為寫驅動程式的第三方公司功力太爛，寫出品質低落的驅動程式讓Windows壞到掛掉，微軟Windows小組也是滿腹苦水（在此並沒有袒護微軟的意思，只是陳述事實）。

核心模式和使用者模式

核模式，對應80x86的 ring0層，是作業系統的核心部分，裝置驅動程式就是執行在該模式下

使用者模式，對應80x86的ring3層，作業系統的使用者介面部分 （就是我們通常所說的win32 API）以及所有的使用者應用程式都執行在該級別

在核心模式下使用者可以訪問所有的記憶體和硬體資源。

在使用者模式下訪問受到限制，例如使用者訪問了禁區，則使用者程序將被殺死。使用者模式必須透過系統呼叫或庫函式切換至核心模式後，才允許訪問硬體資源