從解決 dotNet ComboBox 文字無法置中問題領略自繪元件的威力

作業系統歷經不斷的發展，從以前古老的 OS/2、DOS、Win3.0 到現在的 Win7、Win10、Linux 3.x系統在視窗子系統的部分越來越強大，像微軟最新的 WPF 框架其 UI 繪圖引擎甚至已經以

DirectXGraphics（前身為 DirectDraw 與 Direct3D）為基礎可以使用 GPU 硬體達到高速繪製 UI

的能力，從作業系統不斷演進與增強 GUI 子系統就可以知道，現代化的程式設計 GUI 的程式

設計是相當重要的一部分，也是複雜度很高的部分，一位工程師有可能完全掌握某些演算法程式的撰寫，可是基本上不可能完全掌握 OS 所有 UI 繪圖相關的 API，常常遇到的窘境正是

演算法有了，可是對應的 UI 卻不能很好的做出視覺化的呈現，導致客戶放棄功能強大卻難用

的操作介面，轉而選擇能夠簡單直覺操作的良好 UI，也許功能比原先同性質的軟體弱。

Win64 環境下位址算術的陷阱 A+B != A - (-B)

位址算術（address arithmetic/pointer arithmetic）顧名思意就是對某物件的位址進行加減乘除的運算，也就是算術運算子也可以套用在位址變數上進行操作，其目的往往是為了取得物件的部分內容稱為 upcasting，或是從結構中的某一個欄位間接推算其他欄位的頭位址，另外一個常用的目的是為了指向下一個內容物，如圖 1 當一個指向型別 T 的頭位址 p 要跳至下一個物件的頭位址時，只要將頭位址 p 加上指向型別 T 的大小就可以取得下一個物件的頭位址。

講講 John Carmack 的快速反平方根演算法

本篇的主題很簡單，講講怎麼快速計算 反平方根

圖1. 反平方根函數，但是要如何快速計算此式呢？

設計 Sequencer 直接驅動 HCTL-2020

自從 1945 年春天 ENIAC 誕生以來，電腦科技快速的滲透至人們的生活中，現在是 2014 年

也就是說電腦的發明才 70 而已，尚不足 100，現代的人們甚至已經拿著功能遠遠超越遠古

電腦的各種移動式嵌入裝置，手指在螢幕前滑個不停，這些嵌入式裝置內的 CPU 功能都是

極端的複雜，而且種類繁多，功能強大，有心學習的人也可以很便宜的買到相關的學習版

例如現在當紅的 ARM 架構，熱門的開發版如 STM32F4-Discovery，這些在以前對一般人

談談應用程式介面的風格 - Flat C APIs (完)

來講講今天的主題吧，應用程式介面的風格，也就是一般常說的 API Style，相信有寫過比較
大型軟體的讀者們一定都會有呼叫 API 的經驗，例如讀者想要開發 OpenGL 的程式，那得要
先安裝 OpenGL SDK，然後才開始呼叫 OpenGL 的 API 來設計相關的繪圖程式，所以這邊要
先釐清一下許多人常常搞混的兩個名詞 SDK 跟 API，簡單的來說，SDK 是一組軟體工具包
一般來說具有平台相依性，會需要安裝 SDK 就表示讀者的程式可能用到了一些特殊的 API
可能是一條而已，也可能大量使用，不安裝該 SDK 的話，程式就無法建構，通常 SDK 裡面
都包含了一大堆 Header File、Library File 還有 Binary File，講得更廣應該還要包含完整的範例
、教學手冊、文件，有些巨型的程式庫還會有工具集 (Utilities)，一個很好的例子就是 DirectX
當然學習 DirectX 並不是一件容易的事情，另外一個經典的例子就是 FMOD。

應用動態配置記憶體 - 大數乘二算爆你的電腦

好久沒有發文了，又快要被博主通緝了，所以就來談談今天的標題，" 大數乘二 "。
" 大數乘二 " 演算法的開發可以讓讀者練習動態配置記憶體的應用，另外可以複習
一下讀者們可能已經遺忘的對數計算，另外可以順便練習一下條件型的迴圈使用
所以學習寫程式直接透過綜合演練是比較有用，例如在下除了 "C++ : The Core Language"
與 K&R 那本經典的 C 語言書籍，剩下的知識都是直接閱讀各領域的專案原始碼獲得，所以
在下認為純程式語言的書沒啥用，當然這是在下個人觀點，至少對在下是沒啥用，例如
對 C++ 而言，假如讀者沒有另外去學習像 Qt 或是去閱讀 Inside COM 等等這些技術，就很難
了解 C++ 的一些本質 ( 注: 可以參考以前的發文 領略 QT 視窗程式設計)，總之，語言一定
是拿來被應用，有需求才會被創造，所以回到本文，來看看為什麼  " 大數乘二 " 需要動態
配置記憶體呢？ 很簡單，因為用電腦內建的精度就算不出來了，只會給你一個科學記號的
近似值，可是假如要超越 CPU 演算的精度，那就得自己實作演算法。

以 disasm 為例讓我們真槍實彈挑戰軟體的移植與編譯

今天本文的標題很簡單，讓我們來練習自己移植與編譯軟體的原始碼，講專業的一點就是
學習軟體環境的建構技術，也就是說本文的目標就是要示範給各位讀者知道如何在一支自己
完全陌生的軟體源碼中，自己能夠排除錯誤，對於不存在的函式，能夠移植或撰寫相容函式
將原始碼中缺的部分給補齊，最後下達編譯與連結指令製造出該軟體的執行檔。

一種特別的參數傳遞技巧：直接嵌入立即資料於程式區段

相信有認真看過敝人曾經發過的幾篇呼叫慣例系列文章，應該已經很了解傳遞參數給函式背後
的基本原理，C 語言主要常用的不外乎就是 stdcall、cdecl 與 fastcall，在 x86-64 的環境裡面
也曾經提到過全部統一用 fastcall，可是參數在傳遞的過程中，讀者有沒有想過，是否能夠將
資料直接嵌入在程式區段中，而不需要宣告資料區段呢？這就是今天的主題，敝人將示範一種
特別的技巧，讓資料直接混合在程式區段內傳遞給一條簡單的 Windows API 作為示範。

講講 CFile、fstream 與 傳統 C 程式庫對於檔案讀取速度上的比較

在不發文的話，就要被樓主 K 頭了，所以今天就來講一個很實用的主題，就是在 C/C++ 中

developer（稱 developer，聽起來比較高級一點，programmer 讓人有一種做苦工的感覺）

常常需要打開硬碟內的檔案讀取資料吧，也許是一些設備存檔出來的報表資料，也許是一些

實驗數據，或者是一些軟體播放影音檔，不管用了多麼深奧的解碼技術，這些軟體的原始碼

一定都會有對檔案進行讀寫的動作，但是存取檔案的技巧其實有很多種類，這也是常常讓人

迷惑的地方，所以吾人就來講講一種我們常常會用到的檔案操作物件，來解解大家的迷惑

並且比較一下這些物件讀取檔案的速度。

簡單講講 USB Human Interface Device

恩，發本文的原因是看到了以前畢業的朋友在旁邊的對話框問了一些問題，我想這些問題

不是三言兩語可以解釋完畢，但是我也不想又太細究 HID 內部描述表格的解說與視窗上

HID APIs 家族詳細使用方法，主要以偏向解決問題與實作面上的一些重點，希望可以有些

許幫助，因為詳細的文獻找 USB Complete: The Developer's Guide fourth edition 細讀第 11 章與

第 12 章就有，HID Descriptor 變化多端不可能逐一介紹全部情形，詳細情形除了參考上面資料

也一定要自己讀過訂製 USB 規範組織的 USBIF 發布的標準文獻

Device Class Definition for HID - USB.org  ( HID1_11.pdf )‎

HID Usage Tables 1.12 - USB.org              ( Hut1_12v2.pdf )

因為背這個沒甚麼用，寫韌體軟體的時候在去查閱想要用的型式就好

至於 USB 規範那本 Spec ，恩 假設讀者有念過有概念  : )  這應該是基本功夫，USB 基本知識

不再解說，我們要針對面對多變 HID Descriptor 的型式，怎麼樣的令 HID Descriptor 使得軟韌

體會比較好處理。

從三元運算子講講 C/C++ 的運算式表達問題

在電腦科技氾濫的時代，幾乎所有的科技都用上了電腦，周遭所認識的朋友們大概也脫離不
了在自己的計畫案中，需要寫寫程式，但是除了使用程式庫，會呼叫 API 寫寫應用程式外
( 當然牽涉到特殊領域的 API 那還得要另外學習該領域相關知識 譬如說 UI 或 核心同步物件 )
大概很少人會實際認真的想想，真正基本面的功夫掌握得如何，這正是本篇要講的話題
今天就來講講 C/C++ 語言本身一些進階的主題。

直接交換兩個雙精度用 XMM 暫存器

好久沒發文了，在不發文就對不起博主給我這個寶貴的空間了，今天要探討的主題很簡單
也很好懂，設計一條可以交換兩個雙精度浮點數的函式，數值互換是很基本的數學函式
，但是卻很重要，不少演算法裡頭，都會用到這種基本功能，當然本文不會研究甚麼艱澀
的演算法，這個主題是要透過實作 交換兩個雙精度浮點數的函式 來讓讀者認識現在新的
x86 CPU 內部的 XMM 暫存器 與 初步的了解如何在組合語言中搬移雙精度浮點數。

從轉譯 ZoomIn 工具講講撰寫組語的一些樂趣與困難

常常用 Visual C++ 寫古典 Win32 程式的人應該都知道，經典的第六版之所以歷久不衰
除了本身整合開發環境高效率，體積小，還可以將專案 dsp 檔轉成標準的 makefile 檔之外
就是第六版還附有所謂 17 大經典工具，這些工具被稱為 SDK Tools，它們會被稱為
經典不僅僅是各個程式小巧，而且每一支都很實用，更棒的就是這些工具本身原始碼
也是公開可以研究，這些工具不僅輔助開發程式的利器，本身每支工具的原始碼就是
示範 Win32 許多重要 API 的經典寶庫，我學習 Windows 程式設計的歷史中，絕大部分的
功底就是念透這些工具的原始碼，這個比買一本書看還有用，其中有六支值得仔細閱讀

關於感測器電路的一些經驗談(some tips about sensor)

　　這幾個月來，我發現我對於電路實作與理論的應用，其實還有段差距，故將一些我實際碰到的問題以及解決方法寫下來。

　　基本上我還是在處理感測器的電路，這時候會用到MCU的A/D去讀取實際的類比訊號進來，但是讀值可信嗎?

領略 QT 視窗程式設計

   我們都知道視窗程式設計一直都是讓人頭痛的問題，相信有用系統的 Native API 寫過 GUI
介面的讀者們都可以體會，不管是 MS Windows 還是 Unix 上的 X Window System 或者是
少數有些人可能有過 MAC OS 下 GUI 程設經驗 ( 我指的是更古老的 MAC 系統，非 OS X )，
使用系統的 Native API 撰寫 GUI 是很痛苦的工程，但是我的過來經驗是有過 Native Level
的 GUI 編程其實還是很有用，因為你會了解到任何 OS 下 GUI 子系統的基本法則都很相似
主要基本觀念不外乎就是 GUI 子系統 (有時候會稱為 Window Manager) 會不斷監控各種
視窗訊息並且將訊息傳送給應用程式，一個完整的應用程式一般會有很多的回呼函式來
回應各種訊息，假如不想處理訊息的就利用特殊的 API 送回系統，已經處理過的就不用送回
系統，而訊息一般都會被轉譯或分派，但是一般不需理會，只要在已經註冊好的視窗回呼函
式用 Switch Case 敘述作訊息攔截撰寫對應動作的程式，這就是系統底層怎麼運作 GUI 程式
的基本原理，當然沒這麼簡單，因為有些訊息往往還會夾帶通知，這樣可以更精確的獲得
UI 本身更細部的行為改變，而且不同訊息所夾帶的附加資訊又不同，所以一般寫比較複雜
的 GUI 程式都要花許多時間查閱資料，基本上 Native GUI API 就是一大堆系統提供的
C 函式組合的集合，不妨將這個基本觀念用圖來表示 ( 這邊以 Windows 系統為例 )：

用 SL811HS 學習 USB 介面 - Part01

     通用序列匯流排 (USB) 是有史以來最成功的通訊介面，目前有數億計的 USB 設備存在於

這個世界上，許多晶片設計公司都已經紛紛推出針對不同裝置設計的 USB 橋接器晶片，像
常見的裝置如：鍵盤、滑鼠、掃描器介面、影像、印表機、磁碟控制器、網路介面、序列埠、並列埠甚至是一些特殊介面 CAN ( Controller Area Network )、GPIB (標準化後又稱 IEEE
 488)，吾人碰巧有用過 USB-GPIB 的有趣經驗，這是因為以前有一台示波器後面有一個
USB 埠在好奇心的驅使下接上電腦發現電腦識別為 TEK-USB-488 設備，才知道原來這是
有內建了 USB-GPIB 轉接晶片的示波器，透過這個介面，可以直接用 C/C++ 程式下 SCPI
(Standard Commands for Programmable Instruments) 指令直接控制示波器的設定，像是
螢幕亮度，語系，調整時間刻度，電壓刻度，擷取示波器上的數值。

[QT] 執行檔上的圖示更改(icon change)

QT Creator的做法

首先準備好一個icon檔　可用Irfan view製作
接下來點選project->Add new->general　產生一個.txt檔
將其檔名改為xxx.rc
且內容為

IDI_ICON1 ICON DISCARDABLE "xxx.ico"

從動態二維陣列配置技巧領略 Windows 程式設計

由於 SL811 與 USB Protocol 相關資料還在整理中，這系列文章可能還不會馬上出爐，因此
先來看一看小主題，也就是標題所述帶領讀者寫一支簡單的動態二維陣列配置程式，可是
讀者可能會有疑問，這跟 Windows 程式設計有甚麼關係呢 ? 因為這支程式用純 Windows
API 撰寫，完全不使用 Microsoft Visual C++ Runtime Library DLL (後簡稱 MSVCRT DLL)
內的 malloc，也就是讀者將不只知道動態二維陣列配置的概念，還會了解如何呼叫視窗系統的 API 實現這種功能，這會建立讀者對於 "行程" 最基本的觀念。另外，會解說這個主題的次要原因是最近處理了一些巨大的二維資料陣列問題，問題根源在於繪圖視窗是執行階段才被動態建立，所以作為緩衝區之二維陣列不可能先行宣告，因此必須設計一組可以動態配置二維陣列的 C 介面用於根據繪圖視窗大小動態配置二維陣列，因此想說用這篇講述怎麼完全都用一維
角度模擬任意 N 維陣列的基本原理。

使用 Visual Studio 開發 C51 專案程式

好久沒有發文了，今天來談談關於 8051 MCU 的開發環境，8051 被認為是應用相當廣泛歷久不衰的古老 MCU，在眾多工程人員的努力下，8051仍然持續被重新設計與進化，現代新型的 8051 一般來說都經過架構與製程上的改造，架構上的改造像重新使用RISC架構設計的8051，或是外掛其他周邊例如加入常用的 I2C 與 SPI 或是像有名的 Cypress CY7C68013A 這顆超級 8051 帶有特殊的周邊主要是內建 USB 2.0 控制器 與 GPIF (General Programmable Interface)，GPIF 不是 GPIO 不要弄混，這是一種很奇特的介面，它的功能很像 CPLD，可以產生開發者想要的特殊通訊波形，使得 USB 2.0 控制器可以直接與 GPIF 連接的外部裝置直接通訊，8051 核心本身不用介入控制，達到高速傳輸的目的，有點像可程式化的 DMA。製程上的改造使得 8051越做越小顆，像 C8051F320 小小一顆 7x7mm^2 還內建有USB全速控制器，NI 公司的 USB 轉 I2C 與 SPI 產品就是用這顆做的喔。雖然 8051 有許多變種，但是 8051 的核心在怎麼變，軟體開發層面都一樣，因為所有 8051 組合語言指令集都長得一樣，所以用 C 語言開發 8051 程式當然就只需要一種編譯器，最有名的就屬  Keil C Compiler，另外還有開放原始碼專案的 SDCC。雖然 Keil C51 Tool Chain很好用，可是 Keil 的程式環境就令吾人不深感不方便，尤其對我們這些原本搞 Windows 或 Linux 下寫 GUI 應用程式跳過去也搞搞微處理器的人來說，Keil 的程式編輯器實在太陽春，所以就浮現一個簡單的想法，我只要 Keil C51 Tool Chain，程式編輯與編譯環境用 Visual Studio !!

C語言函式呼叫慣例 ( fastcall ) (完) Part3

Part2 講到關於重要的 cdecl 呼叫慣例分析後，應該已經可以掌握
或是已經記憶在腦袋裡面了，stdcall 與 cdecl 其實長得差不多，除了
函式編譯後的符號名稱不同 與 cdecl 要自己平衡堆疊外，參數傳遞方式
是一樣，由右至左推入堆疊，使得在函式內部取用參數時，剛剛好是從
param 1 開始拿取，另外一個重點在於假如使用編譯器標準處理 Prologue 與
Epilogue Code，那執行完 Prologue Code 時，Stack 的內容一定是

Stack : param n, param n-1, ... , param 1, return address, ebp <== [TOS]

所以 [esp - 8] 必然是函式第一參數值，這些應該要牢記。