NDuiker項目第3天

 

今天是周六了，原本以為是很輕鬆的一天，結果只有到了這個時候才能將今天的Blog寫上去。

昨天NDuiker項目進展的不是很好，^_^，其實剛剛開始嘛。

現在總結一下遇到的技術問題：

在測試執行檔案為Dos、16位、32位程式的時候，費了很大的功夫，在網上找到了一些資料，

Visual Basic .NET definition

Declare Function GetBinaryType Lib "kernel32" Alias "GetBinaryTypeA" (ByVal lpApplicationName As String, ByRef lpBinaryType As Integer) As Integer 

C# definition

[DllImport("kernel32.dll", SetLastError=true)] static extern int GetBinaryTypeA ( string lpApplicationName, ref int lpBinaryType) 

其實這個API在MSDN中就可以找到，關鍵是找到了一個可以查詢.Net Api的網站

http://www.webtropy.com/articles

這個網站很好的，提供標準的.Net API 查詢還給出標準的範例

但是在使用這個API的過程中一切正常，但是在判斷檔案位元的時候出現了問題，目前只能判斷檔案是否為可執行檔，無法繼續深入的判斷。很是鬱悶，正在找解決辦法。

在具體的解決中也發現了一些API和有趣的類，雖然現在用不到，但是就當學習了吧

Knowledge Base 

How to Use Functions in VERSION.DLL -- A 32-bit Sample App（實驗了，但是還是失敗，無法識別，鬱悶）

OSFeature 類

這個類很好的，以前在使用Delphi的一些皮膚的時候，就發現表單的漸層效果，但是這些效果只能在特定的系統中展示，現在通過這個類，就很容易檢查作業系統的支援情況了。

昨天的總結基本上這樣了，總的來說只解決了檔案是否為可執行檔的問題，但是總比通過檔案名稱來判斷要好的多。

對Nduiker項目的一些新的想法：

在這些天的思考中，對NDuiker項目的雛形有了更深一步的思考，首先NDuiker可以將大量孤立的基於CommandLine的程式整合為一個可用的程式，雖然有很多的方法可以在程式中調用別的程式，但是如何將多個平台的產品有機的結合，commandline也許是最好的辦法吧。目前對互動性質的CommandLine程式還沒有較好的解決辦法。

雖然通過批次檔可以完成程式的串連，但是要麼批次檔比較龐大，多種功能結合為一個大的程式，或者調用混亂，指令碼程式移植和轉移都十分複雜。關鍵的是大多數程式全都躺在每個人的硬碟上，這是多麼大的浪費。

所以NDuiker的使命是將這些指令碼有機的結合起來，逐漸形成標準的代碼塊，通過可視化的方式將各種程式有機的結合起來，以此長生巨大的生產力。

NDuiker應該可以利用現有指令碼的優點，同時藉助.Net的強大功能提高指令碼的運行效率，同時提高指令碼的安全性（很多指令碼中包含使用者名稱、口令、伺服器位址等關鍵資訊）。

NDuiker應該形成標準的CommandLine Web服務，方便程式員來瞭解、交流和使用Command Line,而不是讓好的功能只躺在協助裡。

NDuiker也應該建議軟體廠商重視CommandLine的開發和應用，使CommandLine達到一個統一和方便的調用，進一步方便程式員的使用。

哦，也許NDuiker 應該叫做 NCommandLine更好呢？幫我選一個吧。

我們現在的任務還是規劃項目的功能和具體的開發方向。

近期主要是收集各種進階的CommandLine應用。

其次是完成一些項目開發的協助工具輔助，比如CommandLine管理工具，一個基於XML的CommandLine內容管理工具。

同時完成一些相關技術的前探。

今天到這吧，明天在來吧。

好的程式都應該支援命令列。