在我看来，男人和女人，最起码都是一个人，而一个人就应该是独立的，自由的，有自己的思想。对于任何一个人来说，他或她只属于自己，而非任何其他人。男女通过婚姻来建立一种约束关系我认为是丝毫不可靠的，因为他（她）在任何时候都有权利提出解除这种关系，这和奴隶和奴隶主的关系是不同的。
孩子是一种理想的约束条件，因为孩子各占有父母的一半基因，也就是说，男人和女人把孩子抚养长大有助于传播他们自身的基因，这是符合人的本能的。但是，大多数情况下，离婚本身不会影响到孩子的生命，所以孩子的这种约束条件看来也不是那么牢靠。
在我没有找到更有力的理由之前，我还是认为没有结婚的必要。和心爱的人白头偕老需要的不是约束，而是理解和尊重等等。当然，从法律上来说，要终结婚姻这种关系可能还需要很长时间，甚至是永远。
昨天重新拿起放下了几个月的管子，突然发现竟然没有一首自己急切想吹的曲子。可能是现在为学习而忙碌，可能是太久没有接触多少古典音乐，也有可能自己已经深受同宿舍广东人的影响（指流行和摇滚方面），但无论如何，基本上没有那种久违的感觉，那种热情。
双簧管有几个比其他乐器更困难的地方。一是对乐器要求很高，好乐器和差乐器的差别比其他乐器还要大些。二是对簧片的要求极高，这一点从双簧管的名称就可以看出来，双簧比单簧更难控制，所以簧片的材质、厚薄、形状都要和演奏者相适宜，像我这样的业余爱好者很难掌握火候。三是双簧管的可用的乐谱太少，这一点和钢琴比较最明显了，也是没办法的是，谁叫别人的表现力强呢？
到我目前这个地步，只有两条路，一是进入专业的练习和演奏，成为职业演奏者，或者就此永远停留到现在这个水平。我只能说，如果不是我的这个判断有错的话，就是双簧管的可发展潜力太小了，至少对我来说是如此。
还是希望在以后有了固定工作和固定住处后，能学习钢琴。
最近买了一本 OpenGL 的书，似乎很有名，叫 《OpenGL 超级宝典》（OpenGL SuperBible）。差不多看到第四章了，感觉书写得不错，翻译也过得去（经常去 China-Pub 看到那些人在骂译者翻译得烂，当然在西红柿和鸡蛋中也能偶尔见得到一两本说翻译得好的。不过总觉得，如果我这里写“翻译也很不错”，那就有一种鸡蛋不久将临的感觉）。
因为原来也学过 DirectX，所以看到这本书时，还是燃起了对 3D 编程的热情，总还是想比较一下 OpenGL 和 DirectX。很早就听说过 OpenGL，也总是听闻它的效率在很多时候要高于鼎鼎大名的 D3D，或者至少不会比 D3D 更低吧。不过在心中总还是觉得 OpenGL 这个名词闪耀着神秘的光芒，一直不敢去碰它。当然，很大的原因是出于对 C 语言本身的畏惧的。以前用 DirectX 也是用的它的 Managed 版，用 C# 编。现在想起去年拿着自己一个人编了 3 个月的所谓的 “3D引擎” 去参加软件大赛，结果灰头土脸回来的感觉，一方面觉得自己太过骄傲和不自量力，另一方面也觉得 DirectX，即使是 Managed DirectX 也还是太繁杂。就是到参赛的当天凌晨，我都还在为怎么样打开全屏模式而不会出现 Exception 而苦恼。总之，DirectX 给我留下的印象不好。
不过话又说回来，那段时间也不是白学了，至少我对 Viewport, Cull 这些名词，矩阵操作，纹理和碰撞这些概念都有了实际的接触。现在再来看 OpenGL，发现好像一切都还是那么亲切。我不是专门搞图形的，对那些复杂的数学不仅是小学，就是现在大三了都还是既不喜欢也不强悍。但我是一个游戏迷，我想这个理由就足够我去研究图形接口了。
OpenGL 和 DirectX 最大的区别，我觉得在于 DirectX 是微软一家发明和维护的技术，而 OpenGL 仅仅是一系列的接口（API），具体实现是各个公司和个人（如果可能的话）去做的。这样，同一个 OpenGL 游戏使用微软的 OpenGL 库和使用 SGI 公司的库可能有很大的区别。（总还是感觉微软的 Win32 API 是那么地名不副实，自己写一套借口，自己实现，还不准别人去实现，这叫什么接口？不就是一个 Public 函数么？）
OpenGL 的结构好像比 DirectX 更简洁，简洁到让人怀疑它能不能完成程序员们需要的功能。打个比方，DirectX 就像 C++，面向对象；OpenGL 就像 C，面向过程。大家都知道 C++ 是 C 的超集，但没人怀疑 C 是最适合系统编程的语言之一。从第一印象来说，比起 DirectX，我更喜欢 OpenGL（大家都知道人们往往对第一次接触的东西印象最好）。正如 OpenGL SuperBible 里面讲到的，“John (Carmack) 证明了为了完成相同的任务（渲染一些三角形），OpenGL 只需要使用 10 行左右的代码，而 Direct3D 则需要 2 到 3 页的代码”。
目前的打算是，有时间用 OpenGL 重新写一次上次软件大赛的参赛作品，倒时候再来讨论 OpenGL 应该更有说服力了。
另外，似乎 Microsoft 已经被踢出 OpenGL ARB 了，看来我也无缘看到书中所说的 “Microsoft 如此大胆地进行误导，为什么它还没有从 ARB 中被踢出来呢？这一直是一个谜，一定存在一些不可告人的秘密” 了。:-(
那天去了大伯家，和他讨论了很多，茶是大伯喜爱之物，自然也成为主要话题。我们谈到茶的分类，茶的加工，品茶艺术，着实令我开了不少眼界。听说大红袍这种茶极其珍贵，非平常人吃得到，我们开玩笑说，等以后有钱有权了，国家首脑来接见，问我们要什么，我们就要大红袍！
谈完茶，我们又来谈茶壶。大伯收集了很多宜兴紫砂壶，全都拿了出来给我看。其中的一把子冶壶，特别独特，全身粗砂，壶身刻着
“画竹多而作书少，人道余书无竹好。偶然作此当竹看，又道竹不如老。子冶自记。”
同时刻有几支竹。壶底有“子冶”二字。另外不同的是，壶盖用的是桥式柄，不像其他的壶都是圆柄。而壶底由三只脚来托住，而非整个壶底。
他说，收藏东西也是有一个境界在里面。一般刚开始收集东西的人都爱收藏那种带彩的东西，比如这个花瓶，彩绘油墨。再忘深里去，一般就越来越喜欢淡雅的东西了，到了最后，一般都喜欢素的东西。再比如说玉。一般的玉都是拿来刻成各种各样的图案，而真正最好的玉肯定是它最自然的形态，为什么呢？因为比如我是工匠，拿到这么好的一块玉，自己肯定知道他的价值，肯定会想，我来雕刻它根本就是糟蹋了这么完美的一件东西。而历代的工匠都这么想，所以那些流传至今仍然保持原始风貌的玉才是极上品。乾隆也算是有点鉴赏力和修养的人了，他拿到那些好玉，从来都是不动，或者只是雕一点，有个意味就行了。
其实，音乐又何尝不是如此呢？想当初，我对约翰施特劳斯的音乐如痴如醉，认为这比那些港台流行歌曲好听得多，有意义得多。而现在，那些 CD 早已束之高阁，取而代之的是曾经认为绝对无法接受的巴赫、贝多芬。现在我认为我比以前要深刻得多了，成熟得多了，我认为巴赫的音乐才具有真正音乐上的美，那以后呢？我还是那么多年时间好活，等到我老了，我又会怎么看待现在我的想法呢？幼稚么？无所谓，这是必经之路。
一切的艺术都是共通的。为什么我在听到大伯谈论收藏时我会想到音乐呢？我觉得在人的大脑里，艺术占据着一个很特殊的位置，它不同于我们一般的生活。每当我接触到那个地方时，总会有莫名的冲动。可以将之理解为虚荣，因为我认为在这个世界上真正接触到艺术的人并不多，而我就是其中的一个。我认为我很幸运，因为现在的我懂得什么是艺术，艺术能带给我什么，因此我才会毫不犹豫地去追求艺术。如果我不是 8 岁或者更早接触音乐，我可能一辈子都无法到达我现在这个水平，因为我会犹豫，会茫然。什么是艺术？我无法告诉你，它就是一种感情，一种和性相媲美的快乐，只能有幸者自己去体会。
临走时，大伯把那把子冶壶送了给我。
看到 Borland 公司的一篇通告 “Borland to Acquire Software Quality Company, Segue Software; Announces Plan to Divest IDE Product Lines”，其中说道 Borland 准备卖掉他们的 IDE 产品，全力发展他们的 ALM (Application Lifecycle Management) 市场。看来 Delphi 在 Visual Studio 和 Eclipse 的挤压下，最终还是选择了放弃 IDE 这个市场。那么 Delphi, C++ Builder 这些曾经优秀的软件是否将永远离开我们呢？
其实 Borland 并不是没有好软件。记得高中的时候，有一天星期六，我和 Alex 一起去电脑城买 Delphi。当时觉得 API 是一件极为神秘而伟大的东西，而比较熟悉的 VB 在这方面天生不足，强大的 C, C++ 我们又望而生畏。正没个准头时，我突然发现了 Delphi 6。那时我从没用过 Delphi，甚至连 Pascal 都只闻其名。买了一套回来试用，逐渐发现 VCL 库是多么的方便和强大，只需要引用一个头文件，就可以轻松调用 API。这是它让我爱不释手的原因之一。记得那一个学期，就靠每天中午本该睡午觉的时候，我就偷偷起来编程序，最后做出了算是我第一个比较完整的程序 Animations' （这个名字至今仍被 Alex 嘲笑，他认为这是世上最好的媒体播放软件）。无论如何，通过 Delphi，我认识了什么是 API，什么是传出传入变量，什么是 Pascal 和 Object Pascal，什么是自建控件，当然，还有 procedure 这个词。在那个时候，我颇为我的 Delphi 可能比 Alex 操得熟而自豪。
就现在为止，我仍然认为 Pascal 是一门非常严谨的语言。在我学习了编译原理以后，我越来越对它有所了解和理解，也发现了它作为传统编程语言教学范例的原因。确实，它的语言特点比 C, VB 等等静态语言更符合编译过程的需要，单就变量声明来说，var 的使用，变量-类型的顺序，所有变量声明的位置集中，这些都为编译器提供了准确和便利。我没有具体研究 Pascal 每一条产生式，但是我想，要在里面找到具有二义的文法应该是不可能的。但是可能正是这些本来优秀的特性导致了 Pascal 本身的不足。Pascal 产生的原因就是为了教学目的，似乎 Pascal 天生就不善应酬越来越多的对灵活性要求越来越大的场合。C 不同，C 生来就是杀手，就是为了写出更好更灵活的程序而诞生的。我想这就是为什么 C 语言 30 余年来还大行其道，而 Pascal 始终未能登入大雅之堂的原因吧。
在我印象中，Delphi 7 和 Delphi 6 似乎没有什么不同，即使在界面上，除了 Splash 外，也几乎完全一样 (这在微软的产品中几乎是不可能出现的，是不允许出现的：）)。好像在数据库方面有所加强，不过我承认那时候我对数据库的认识也仅限于 Access。很遗憾，大家都说用 Delphi 不用它的数据库组建就想去了雅典不去太阳神庙一样，我就是这么一个人。
C# 出来了。这个带有 C 字样的语言立刻吸引了我，因为我一直对 C 语言抱有敬畏，即希望接近它，有怕被它拒绝。以前多次的尝试的失败这次在 C# 面前没有出现，原因是，我发现 C# 中有很多东西是在 Object Pascal 里面见过的。比起 VB 来说，Pascal 当然更接近 C 语言范畴，应该说，Pascal 作为了我接触 C 类语言的跳板。直到后来，我认真捧起 《C Primer Plus》，发现 C# 和 C 也异曲同工时，我才算真正学会了神秘的 C 语言。无疑的，没有 Delphi，我没那么容易能走到今天这步，所以我一直对 Delphi 抱有好感。
Delphi 8 无疑令人遗憾。我认为我没有多少权力来评价它，因为我使用它的时间总共不到 2 个小时。从界面上说，Delphi 8 有了很大改变，这让每一个 Delphi 的忠实玩家不得不花点时间来熟悉和自定义。从内容上说，感觉 Delphi 8 是一个 .NET + VCL 的……说好听点，混合体；说难听点，杂种。没有了 Object Pascal，我实在找不到以往使用 Delphi 的感觉。有了 .NET，我又实在找不到我放弃 VS2003 而转投 Delphi 8 的理由。Delphi 8 真的称得上“迈入 .NET 平台的最佳利器，将带给您无穷的潜力与展望。”吗？我觉得设一个投票，看看到底有多少人是从 Delphi 认识 .NET，这最能说明问题。
从那个时候起，Delphi 再也不是不可替代的了，因为它走了 .NET 的道路，这是微软的道路。在 .NET 领域，相信更多的人会选择 .NET 创立者门下拜师，Borland 又扮演了什么样的角色呢？我想，如果微软比作少林寺，那么 Borland 就是少林寺俗家弟子。他不会没有门徒，但绝对没法修得最高深的武功。别人 Microsoft 秘不示人的功夫可是有名的呢！直道现在的 Delphi 2005, Delphi 2006，我都没有再试用过了，看着那成 G 的 ISO，真是怀念当年 1 张 CD 打遍天下的时候啊。
说完 Delphi，在来说说，JBuilder。C++ Builder 我没用过，因为我接触 C 语言比较晚，而 Java，那我就是被逼着学的了。大二分布式的课，老师要求用 Java 写程序。我首先试了那时已经赫赫有名的 Eclipse，发觉和 Dev-C++ 有相同的毛病：调试。不知道那个调试器怎么回事，总是出现意想不到的结果，调个程序跟上战场似的得小心翼翼。没办法，只得再试试 JBuilder。JBuilder 2005 让我比较满意，至少在调试方面我感觉没什么压力。因为我对 Java 仍然持保留态度，所以没对 JBuilder 2005 进行更多的探索。不过有两点很令人不爽：1) 运行个程序还得先手动创建一个 Profile，难道就没有默认的提供选择吗？2) 用 Java 做窗口做界面，其过程似乎还停留在 Pre-VB 时代。这应该是 Java 本身的不足，看来 Java 对 EJB 这类不需要 GUI 的东西更感兴趣。巧的是，这两点微软都做得很好，看来我中微软的毒不浅哪。（我在想，Eclipse 不也是 Java 写的么？它的界面怎么这么漂亮？）
现在，Borland 要卖掉 IDE 了。如果 Delphi 以后消失了，Borland 不再是现在的 Borland 了，又还会有多少人记住这些名字，又能记住多久呢？
春节这几天，除了探亲访友，就是解决一系列的 Bug。我发现，用 CreateFile 打开一个分区后，再用 CreateFile 打开同一分区下的一个文件，并修改它，这时，再用 WriteFile 操作这个分区的 FAT，将无法实际写入分区——即使用 ReadFile 读出数据确认确实修改了，但实际数据并未修改。对于这个问题，可以在修改文件之前先用 CloseHandle 关闭分区，再在修改完文件后打开分区。
另外，如果在打开文件（CreateFile）时没有加 FILE_FLAG_WRITE_THROUGH 参数，还会有一点其它问题。经常是在程序中修改了文件内容，再读文件的 Short Directory Entry，发现其中的文件大小仍然是修改前的大小。似乎用 FlushFileBuffers 可以把系统缓存写回磁盘，但我没成功。另外，好像 CreateFile 打开分区，不管加不加 FILE_FLAG_WRITE_THROUGH 都默认是不是用缓存。
总之，感觉通过 CreateFile 直接操作磁盘确实很方便，但是也有互斥上的问题，因为 CreateFile 要求打开分区必须加上 FILE_SHARE_WRITE。通过中断操作磁盘应该就不会有这样的问题，但是那就比较麻烦了。
