今天是周六了，原本以为是很轻松的一天，结果只有到了这个时候才能将今天的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内容管理工具。
同时完成一些相关技术的前探。
今天到这吧，明天在来吧。
好的程序都应该支持命令行。