这两天给老婆补作业，也顺便操起了Asp.net的旧业。是一个内容管理系统，由于权限设置的原因，坚决不允许将文档或者程序存放在一个IIS无法访问的目录，以免造成泄密事件。因此要采用利用Asp.Net读出文件内容后回写到浏览器中的方法，看了uestc95 的[.NET Tips 1001]ASP.NET直接下载一个文件，而不是在IE中打开它 后很有启发，不过偷懒的天性是我觉得这个方法有点麻烦。好在发现Response.Writefile 这个方法,可以最大限度的减少同志们的工作量。，代码如下
Response.Clear()
Response.ContentType = "application/octet-stream"
Response.AddHeader("Content-Disposition", "attachment;FileName=" + HttpUtility.UrlEncode(filename, System.Text.Encoding.UTF8))
Response.WriteFile(filepath+filname)
Response.End()
当然大家可以在这里添加一些权限判断的代码。
以前写过一个监视GMail的邮箱的程序的思路：控制IE中的IFrame和Frames实现GMail自动登录 不过今天看了Google 的 Gmail Notifier 感觉好多了。不知道是用什么技术实现的？感觉上应该是差不多的技术。 不过现在这个软件不支持多用户，也不支持重新登陆，这样对于像我这样有N个GMail帐户的无聊认识就太不方便了。
奥运会期间，google 的图标天天换，现在每天都要观察一下 最新的奥运奖牌和Google的每日奥运图片。
或许你看到这个标题会感到非常的惊讶，因为截至到现在，恐怕是没有多少人没有使用过XML文档了吧。
不过如果你是一个VC6或者是VC7中native code的使用者的话，我想您或许会产生一些兴趣。
在MFC中没有提供对XML的操作的类，如果是忠实的COM支持者的话，可以选择使用微软的MSXML DOM 来操作一个xml文件。
如果是开源，又或者是对跨平台的支持的话，您可以选择使用WFC,XML4C 当然还有apache 的著名的Xerces C++ 来操作，使用这些类库基本上都可以比较简单方便高效的实现对xml文件的读写。并且都支持XML 的最新标准。
不过，不要忘记一件事情，需要使用VC来读写XML文件的基本上都是一些配置文件，比如Visual Studio .net 的工程文件，这样的文件的大小一般都会限制在一定的容量以内。如果我们采用上面的任何一个方法，都需要下载几M甚至10几M的库文件。真的是有些不合算。
感谢sourceforge,感谢google 给我们提供了足够多的资源来简化我们的开发，在这里我给大家介绍一个短小精悍的XML parse class----TinyXml,tinyXml 不光短小，效率也是很高，而且使用这个class 可以很快地定位 我们需要在Xml中定位的Node。它提供了一个叫做 TiXmlNode* FirstChild ( const std::string& _value ) 的方法，以最简单的方式开始我们对 Xml 文件节点的读写。
经过实践，发现这个class 读写xml 的速度也还是很不错的，要是说缺点，就是对Unicode的支持还有一些bug。比如说下面的xml 标签的解释就有bug
<Filter Name="程序" Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx">
但是如果你改成
<Filter Name="程序file" Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx">
的话，就可以了。
不过话又说回来了，开源就有这个好处，随时发现Bug,随时Fix Bug.
今天看了如何判断Assembly是Debug还是Release？这篇文章，收获很大，但是这个方法还是有自己的缺陷，使用这个方法必须保证这个DLL或者EXE程序参照自己的这个方法来实现？有没有办法判断这个程序是Debug版本的还是Release版本的呢？
在Win32环境下，一般来讲，由于大量的编译信息会保存在Exe或DLL文件中，因此这些文件的size都会比较大，我一般来判断这个文件是DLL还是Release版本都是通过对二进制码的分析得到的。
Debug版本的程序中一般都会保存PDB文件的保存路径，因此我就用这个方法来判断是不是Debug:)
在Dotnet环境下，Framework提供了一个DebuggableAttribute 的class,可以通过如下的代码实现对其编译属性的判断。
try
{
Cursor = Cursors.WaitCursor;
Assembly assm = Assembly.LoadFrom(filename);
bool found = assm.GetCustomAttributes(typeof(DebuggableAttribute), false).Length > 0;
buildType = found ? "Debug" : "Release";
}
catch
{
buildType = "<error>";
}
finally
{
Cursor = Cursors.Default;
}
出处：http://www.sliver.com/dotnet/IsDebug/
程序下载(code)：http://www.sliver.com/dotnet/IsDebug/IsDebugSource.zip
安全设计的一个准则就是：除了你，没有人可以冒充你。
什么意思呢？就是一个安全的系统中，即使是管理员也无法知道别人的密码，甚至是系统的设计者也不能冒充别人进入，或许你是管理员，你可以任意修改别人的密码，但是由于修改密码的操作是会被记录在案的，因此你仍然无法做到神不知鬼不觉地冒充别人做坏事。
安全的设计是系统的最后一道防线，完善的一个安全系统，不是说我如何如何能够抵御别人的攻击，而是在我已经被攻陷后还如何最大限度的保护我自己。
所以我们有了各种各样的密码算法，RSA，DES,BlowFish,他们的出发点都是一个开放的算法加上一个外接的密钥。但是我发现在很多的系统中，大家都忽略了一个问题，密码以什么形式保存呢？
答案当然是加密保存了，不错，这样作为我这样的一个试图非法进入一个系统的供给者来说，确实是没有办法得到管理员的密码。但是如果简单的将密码单独加密保存的话，如果我将自己的密码的加密后的字符串更新到管理员的密码字段后，我就可以利用我的密码堂而皇之的进入到系统，而不留任何痕迹。
比如：加入我的密码是:123,加密后的字符串是 BF123FGHOO8hL258BgRR 管理员的密码加密后的字符串是HHKK55RR))99uuKK!!33 我不知道这套系统的设计算法，更无从知道所谓的密钥是多少，但是我知道BF123FGHOO8hL258BgRR 代表的是123,我只要将管理员的密码加密串也更新成BF123FGHOO8hL258BgRR 我就可以用 123 登陆了。
要解决这样的问题，则不能简单的将密码加密，最起码也要将用户名揉到密码串中统一加密，这样就没有办法使用这种方法了。
现在的社会中，密码是我们的最后一道生命线，真的希望大家在设计系统的时候，如果牵扯到密码，一定要尽可能的为用户多考虑一些。
BTW(增加一些内容)：
永远不要还原用户的密码，因为现代社会中大多数人会将自己在不同场合使用的密码设置成一样的，这样就会出现你的系统中的密码其实很有可能就是该用户银行的存折密码，我以前曾经用$@#$@#方法得到过一个免费网站的用户数据库，该数据库的密码是明文保存，我尝试了80%的用户在该站点的用户密码和他们登记的邮箱的用户和密码是匹配的，所以我现在就不敢在一些不值得信任的站点使用我的最高级别的密码。
在现实的工业控制中，经常需要采用一些实时控制的技术，比如大型钢厂的轧钢系统和大型变电站的实时报警系统，事实上Windows不是一个实时操作系统，一个比较流行的实时OS是VxWorks.但是基于VxWorks的实时系统究竟能否实现实时或者能够实现多少精度的实时呢？因为我们知道，真正的实时系统是不存在的，我目前了解到的最高精度的实时反应是20皮秒（但是记住，这个不是实时系统，仅仅是两个信号的间隔）。
我们需要有一套操作简单，真实可靠的系统对实时系统进行检测，不错，高精度的示波器和逻辑分析仪可以实现一定程度的实时系统的检测，因为所谓对实时系统的检测，无非就是一些控制信号和控制指令的反应时间，但是由于示波器和逻辑分析仪的不直观，我们无法对一个实时系统长时间的运行进行有效的测试。而且这样的系统也很难融入到一个现有的系统进行实时测试。
需要说明的是，单纯的软件是无法完成这样的系统的，我们需要一些高性能的数据采集卡来完成我们的系统测试。首先我们需要一款能够将模拟信号转换为数字信号的数据采集卡，这块数据采集要求能够达到200M以上的数据传输率。我们知道由于Windows不是一个实时的系统，因此想要如此高速的传送数据几乎是不可能的，因此必须采用DMA的方式，通过硬件地址映射将数据直接输出到内存。
软件方面是绝对没有可能用.Net来完成的，由于大量的与硬件的交互动作，以及与底层驱动直接的接口有时很难划分，因此整个软件仍然采用DDK+VC的方法来实现。经过最终的试验测试，发现Windows系统可以在很大程度内将自己的系统反应控制在5ms以内，但是有的时候会产生上百毫秒的误差，由于windows的任务调度的限制，完全无法完成实时系统的任务，甚至是低精度任务。而VxWorks可以做到长时间的10微秒以内的稳定工作，虽然在VxWorks下的软件开发相对于Windows下开发，成本提高太多，但是根据实际的试验数据来看，这些成本的投入还是合算的。
后记：这篇文章完全没有贬低windows系统的意思，事实上windows的表现完全超出了我的预期，Unix系统的实时性好于Windows但是也无法达到实时的效果。Vxworks的表现的确不错，但是开发成本过高。
与实时系统相关的一些知识的介绍：
VxWorks白皮书: http://www.windriver.com/whitepapers/wp_vxworks_vxvmi.pdf
Tornadohttp://www.windriver.com/products/development_tools/ide/tornado2/tornado_2.pdf
Labview/RT 很有特色的一个实时OS: http://www.ni.com/realtime/