:::info 這章節主要在講編譯流程、編譯器、鏈接器的概念 ::: 在日常開發過程中，我們很少需要關注編譯和鏈接過程，通常 IDE 都幫你搞定了，往往只需要按一下 Build，執行檔就建構出來了。但正是如此，才有很多的 compiler 或 linker error 讓我們無所適從，這些錯誤信息有時候晦澀難懂，讓我們難以迅速定位和解決問題。或是程式執行的效能瓶頸我們束手無策。 我們只看到問題的現象，而很難看清本質，這些問題的本質就是軟體運行背後的機制，和支撐軟體運行的平台和工具，唯有了解這些機制細節，才能在面對這些問題時得心應手。 2.1 被隱藏的過程 一個簡單的 "Hello, World" 可以透過編譯執行它，來測試開發環境

3.1 目的檔的格式 目的檔(Object File)編譯器編譯原始碼產生的檔案就叫做 Object File 基本上和執行檔格式相同 沒經過連結(Linking)有些符號、位址還沒調整 不同系統的執行檔格式名稱: Windows: PE (Portable Executable) Linux: ELF (Executable Linkable Format) macOS: Mach-O (Mach Object File Format)

6.1 Process Virtual Address Space 每個程式執行起來後，都有自己的虛擬地址空間(Virtual Address Space)，大小受限於 CPU 的尋址上限，即 CPU 的位寬 (32bit or 64bit)，對於 32bit CPU 來說，虛擬地址的位置就是 0x00000000 ~ 0xFFFFFFFF；對於 64 bit CPU 來說，就是 0x0000000000000000 ~ 0xFFFFFFFFFFFFFFFF (約 16 EB)。 在 C 語言中，pointer 的大小可以推測出虛擬地址空間的大小，32bit 下就是 4byte；64bit 下就是 8byte。 OS 為了達到監控 process 的目的，不讓 process 任意使用記憶體，包含大小以及位置。如果 process 讀取了未經授權的記憶體位置，在 Windows 下就是 Access Violation、Linux 下就是 Segmentation fault。  32-bit 程式整個能使用的虛擬記憶體 4GB 的空間被劃分成兩個部分: 0xC0000000 ~ 0xFFFFFFFF 是作業系統、0x00000000 ~ 0xBFFFFFFF 是 User Process。

4.1 空間與地址分配 有兩個 Object File，如何將他們連結成一個可執行檔 /* a.c */ extern int shared; int main() { int a = 100; swap(&a, &shared);

5.1 簡介 PE 和 ELF 都源自 COFF 格式 PE: 32bit, PE32+: 64bit 和 ELF 一樣 PE 也是基於 section 的格式，程式碼放 .code 資料放 .data 也允許在程式中指定 section 位置，像 gcc 中的 __attribute__((section("name"))) #pragma data_seg("FOO") int bar = 1; #pragma data_seg(".data") 5.2 PE 的前身 - COFF

OpenGL 環境設置 不限制使用之工具，以下提供三組環境供參考： :::info 作業模板 https://github.com/roy4801/1091-computer-graphics ::: Windows 環境設定 Linux 環境設定