Cancel 一個 pending 中的 Synchronous IRP

其實這個問題一直沒有發現，因為我的 Device 都會很快就回應這個 IRP 了啊，哪裡知道別人家的會跑到一半就死掉，然後這個 IRP 就不會被 Cancel 掉，接著系統就藍底白字....。 解決方法很簡單： 在 SendAndWaitUrb() 裡面，先設定 IRP 的 CompleteRoutine，然後在這個 CompleteRoutine 內，觸發 Event，並回傳 STATUS_MORE_PROCESSING_REQUIRED。接著只要在 KeWaitForSingleObject(Irp) 時 Timeout，就呼叫 IoCancelIrp()，然後再 KeWaitForSingleObject(Irp)，IRP 就會被 Cancel 啦。 因為 Synchronous IRP 都是系統會回收，所以也不用呼叫 IoFreeIrp。

C# 越來越鳥了 (2)

http://dotnetjunkies.com/WebLog/johnwood/archive/2005/08/31/132267.aspx Thread 不能存取 Component 的原因竟然是：Windows Forms 的元件不是 Thread-Safe。我被打敗了，微軟是越混越回去了嗎？我記得 MFC 沒有這限制啊（還是它有但是我沒遇到....）。可是你搞出一套 GUI component 卻因為它不是 Thread-Safe，然後只好在別的 Thread 存取它時丟出一個 Exception，說不能這樣作，這...這....會不會太不負責任了點？

C# 越來越鳥了

我知道我不想看那麼多文件，但是它的限制好多啊....。連 Control 產生的 Thread 都沒辦法使用這個 Control 內的任何元件，這....這....我記得 Java 沒這個限制啊。根據 MS 的說法，它是怕這樣會有兩個 Thread 去存取這個元件，導致該元件的狀態不一致，可是我沒差啊，又不會死，結果 C# 就說這樣不行，去你的。結果要達成目的的話，得多寫好多 code，這樣不是本末倒置嗎？ 好吧，Thread 不能存取 Control 內的元件，那我在 Control 內用 Timer 總可以了吧？結果要搞定一個 Timer 還真是麻煩，這又牽涉到 Delegate 的方式，偏偏我對 Delegate 不熟，這樣又不能馬上用，真是自己找麻煩...。 看來得找個時間好好把 C# 的 Delegate 架構給搞清楚了。

ShellExecute() 在 C# 的替代法

使用 ShellExecute() 開檔案是很愜意沒錯，但是遇到一些很怪的檔案，如韓文或日文，就會回傳 ERROR_FILE_NOT_FOUND，真是有夠 OOXX 了，難怪 Servant Salamander 會有這種問題。偏偏我的動物常常會抓這類檔案回來....。 去用 google 查一下是不是有替代的 C# class 可以使用，咦，還真的有耶，賺到了：

    System.Diagnostics.Process.Start(FileName);
    System.Diagnostics.Process.Start("IExplore.exe", "www.google.com");

呵呵，所有的檔案都可以開了，真的滿爽的。 附帶一題，MSDN Library 實在是很難查（事實上是很慢），用 JDK 的 HTML 方式不是很好嗎？簡單且快速。

因為 Servant Salamander 過期了，加上它不支援 Unicode，所以打算用 C# 寫一個來替代它。 一開始用 ListView 元件，結果遇到 ListView 元件不支援字型的縮放，格線永遠是那麼大。失敗。改用 DataGridView 就好了。 其他的功能倒是還蠻好實做出來的。不過，現在遇到 Shell 相關的部份倒是蠻麻煩的。目前想要去抓每個檔案的 Context Menu，結果就遇到 COM。COM 是還好，但是 C# 對 COM 的支援實在是有點跛腳，還得自己弄個類似 IDL 的東西，然後透過 Windows Native API 取得 COM Object，如果只是這樣就算了，問題是 Windows API 回傳的是一個 pointer，C# 不允許我用 pointer 啊，所以抓到的 pointer 還得轉成一個 Class Object....，有點拿石頭砸自己的腳的味道。之前想用 C# 寫 DirectShow Application，也是遇到相關問題，結果就放棄了，想不到還會遇到。 這樣跟用 Java 寫有什麼兩樣....而且要執行我的程式還得灌 .Net Framework 2.0.....。

在 Testcap 內新增 Audio Capture Pin，並且讓 Windows 的音效裝置可以選擇它

說實在的，這個問題在 microsoft.public.development.device.drivers 討論區內有人提過，不過講的不是很清楚。

Testcap 的 filter graph:



一開始我的想法很簡單：讓 testcap 自己長出一根 Audio Capture Pin，如此 Windows 應該會把這個裝置當作麥克風來使用吧...，結果當然是不行啦。看完討論區之後，發現，喔，原來我們在 Windows 的『聲音及音訊裝置』內看到的『音訊』都是 SysAudio.sys 這隻 driver 所 enumerate 完所有的 Audio Device 之後再回報給 Windows，所以是 SysAudio.sys 不認為 testcap 是個 audio capture device。

Testcap 的 filter graph:



所以，要如何讓 SysAudio.sys 認為 testcap 是個 Audio Capture Device？用圖來講比較簡單：




SysAudio.sys 要認定一個 Audio Capture Device 的條件有：
1. 有 Analog Audio Input Pin
2. 有 Audio Output Pin
3. 這兩根 Pin 之間必須有一個以上的 Node 存在。

Node 跟 Connection 在 DDK 的定義為：描述一個 Filter 內部的連接狀態。很模糊對不對？去看完 USB Video 或 Audio Class 之後就會比較清楚了。簡言之，就是讓 Host 能夠知道你這個裝置到底有哪些特異功能可以使用，如 Video 的話，就是能不能調整 Brigntness、Hue 等等，如果是 Audio 的話，就是能不能調整音量大小等等。