Wednesday, December 15

未来基于boost::function的native event

我曾经发现的native event的bug在汇报给微软以后,今天收到了回音
基本上在明年问世的VC2005里将有一个新的没有bug的基于boost::function的native eventn实现。
但那估计也激不起我多大兴趣了。因为我现在完全在期待Don Clugston完善他的FastDelegate,特别是Multi-cast delegates的实现。

Tuesday, July 13

解决无法看MSDN的鬼问题

我遇到奇怪的MSDN内容无法显示问题已经若干个月了。在我安装最新的2004.7版本以后更是完全无法使用MSDN了。我的开发环境是Windows XP Profession SP2+VS.NET 2003。MSDN的所有页面都显示'This page cannot be displayed' ,在我以前安装的msdn版本里还能有个别页面可以显示文字。这回变的更加彻底了。而我在另外一台windows2000的机器上安装这套MSDN则完全没有问题。
我google以后还真找到了难兄难弟http://www.dotnet247.com/247reference/msgs/48/243646.aspx,
"The help wouldn't work at all, I keep getting 'This page cannot be displayed' and the error is 'Cannot find server or DNS Error Internet Explorer', so finally I re-installed MSDN for VS.NET 2003 and i still keep getting the same problem. Even clicking on 'Help on Help' was coming up with the same error"

经过无数次的重装MSDN,uninstall 各种软件都无效后,发现了问题所在。如果我以另外一个account登录windows,msdn的内容就可以正确了。而ms-help协议实际就是安装在自己机器里的http,也是通过IE来访问的。所以判断可能是cache有问题了。
我使用另外一个具有administrator权限的帐号登录,找到C:\Documents and Settings\\Local Settings\Temporary Internet Files\Content.IE5 删除。回到我的account里,MSDN就完全正确了。
具体原因也许是index.dat 莫名其妙地被lock上了。也许就是也许。

参照: http://chuacw.hn.org/chewy/archive/2004/03/25/392.aspx

Wednesday, July 7

揭开native event的面纱
这是我的第3篇关与native event的随笔。第一篇对native event作了简介。第二篇报告一个BUG。这一篇我们看看native event是如何实现的,并且尝试解决我们遇到的BUG。

从VC7(Microsoft Visual C++ .NET (2002) )开始MSVC提供了native event这一机制,试图为C++引入一个实现delegate的办法。一共提供了4个扩展关键子:__event (定义一个event),__raise(触发一个event),__hook(将一个成员函数连到event上),__unhook(去掉指定的函数),和两个作用在类上的特性:event_source(一个事件源),event_receiver(一个事件接受者)。

为什么会提供这么多看上去很丑陋的关键子呢?这些关键子生成了什么样的代码呢?

可以使用下面的编译命令来编译我在第二篇随笔里的代码。

cl /Fx /Fas native_event.cpp

/Fx编译选项会生成一个native_event.mrg.cpp,这是MSVC编译器对特性作了展开以后生成的源代码。/Fas编译选项生成相应的汇编代码。

我们看看native_event.mrg.cpp就足够了解native event的实现方法了。

__event关键子被展开成为一个事件函数链表指针,一个虚构造体,一个模板构造体,3个模板函数,一个名为__RemoveAllEventHandlers的成员函数,一个与event名同名的inline函数。除此以外还有4个辅助结构体。 可见event机制是非常类似宏定义的实现方案。

__hook通过__AddEventHandler模板函数将函数指针追加到函数链表里。__unhook从链表中删除函数指针。

__raise本身没有什么用处。实际调用的事件函数的时候,会循环调用函数链表里的函数。函数链表的每个节点里都存储了对象实体指针(this)和成员函数指针。成员函数指针同void*指针的转换利用了__eventingGetAddr这个灵巧的辅助类。

虽然代码看上去有点乱,但并不是很长,应该很容易看懂。

我在第二篇随笔里提到的bug,发生在

int __isEqual(void* p, void* pfn)
{
return ((T*) p == this->p) && (__eventingGetAddr::__getMAddr(pfn) == (void ( T::*) ()) pmfn);
}
这个函数里。多继承的情况下对(void ( T::*) ()) 形式的指针做比较是比较微妙的,明明相等的指针确返回了false。查看汇编代码发现一共比较了8个byte,两个DWORD PTR,具体为什么这么做我还需要做一些分析。

看上去一个可行的代替方案是:

int __isEqual(void* p, void* pfn)
{
return ((T*) p == this->p) && pfn == __eventingGetAddr::__getVAddr((void (T::*) ()) pmfn));
}
将函数指针转换成void*,然后再做比较。从asm看到这产生了高效的代码。

这个BUG导致的后果就是:无法在ATL/WTL中使用native event。这使的这一机制几乎失去了意义。

警告:使用native event要小心。

建议:在MSVC改正BUG之前不要使用native event。

CodeProject里有一篇最近发表的文章提出一种FastDelegate方法,似乎是不错的single-target delegate 解决方案。boost的function和signals则是更加值得关注的。

Wednesday, July 07, 2004 2:49 PM

BUG Report: Failed When a Native Event is Unhooked with with Multi-Heritance
SYMPTOMS
当在一个使用多继承类作为event_receiver的未托管应用程序中unhook (__unhook) 一个native events时, 将会失败。__unhook将返回1(表明没有成功地unhook。在应用程序结束以后native event机制造成了内存泄漏.
CAUSE
这个问题发生在事件的接受者(event_receiver)是多继承类的情况下。在unhook的时候event的注入代码无法正确比较成员函数指针。
WORKAROUND
这个问题可以使用下面的代码重现:

#include

class A
{
int a;
};

class B
{
int b;
};

[event_source(native)]
class CSource
{
public:
__event void MyEvent(int nValue);
};

[event_receiver(native)]
class CReceiver : public A, public B //多继承
{
public:
void MyHandler1(int nValue) {
printf("MyHandler1 was called with value %d.\n", nValue);
}

void MyHandler2(int nValue) {
printf("MyHandler2 was called with value %d.\n", nValue);
}
};

int main() {
CSource source;
CReceiver receiver;

__unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);
__hook(&CSource::MyEvent, &source, &CReceiver::MyHandler1, &receiver);
__raise source.MyEvent(1);
__unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler1, &receiver);//失败
__hook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);
__raise source.MyEvent(2);
__unhook(&CSource::MyEvent, &source, &CReceiver::MyHandler2, &receiver);//失败

}


运行结果

MyHandler1 was called with value 1.
MyHandler2 was called with value 2.
MyHandler1 was called with value 2.

MyHandler2没有被正确unhook。

The information in this article applies to:

Microsoft Visual C++ .NET (2002)
Microsoft Visual C++ .NET (2003)
Visual C++ 2005 Express Edition Beta
Wednesday, July 07, 2004 11:10 AM

Thursday, May 13

WTL终于成为了一个Open Source项目。

昨天,WTL的创造者Nenad Stefanovic将最新的WTL版本7.5.4133放到了SourceForge.net上。这是继Wix之后的第二个由微软贡献的开放源代码项目。
可以说MS走出这一步,真的很不容易。从2003年4月12日MS的Pranish Kumar发mail说WTL将会开放到2004年5月12日真的走出这一步,耗时13个月。

另外听说WindowsXP的盗版用户也可以安装即将推出的SP2,MS的Barry Goffe说:"It was a tough choice, but we finally decided that even if someone has pirated copy of Windows, it is more important to keep him safe than it is to be concerned about the revenue issue."

无论怎样,看上去MS变得更加灵活和开放,他们对社会的贡献度变得更大。



To: wtl@yahoogroups.com
From: "Nenad Stefanovic"
Date: Wed, 12 May 2004 15:57:08 -0700
Subject: [wtl] ANN: WTL moves to Open Source!

Hello everybody,

WTL is now available as an Open Source project on SourceForge.net. WTL
is now part of the Microsoft Shared Code initiative that enables the
community to contribute to the project.

You can find the project at http://sourceforge.net/projects/wtl.

Feel free to send your questions/comments/suggestions to me.

Cheers,
Nenad

Wednesday, April 14

.Framework上一个不明确的地方

在中文版.Framework SDK文档的里的"从对话框的父窗体检索信息"一节写的不清楚,MSDN联接在这里

原文如下:
根据对话框的用途,可能希望访问该对话框的父窗体提供的信息。对话框的初始化可能需要此信息,或者此信息可能涉及有关父窗体的应用程序状态的特定详细资料。
使用该对话框的 Form.ParentForm 属性访问父窗体的公共成员。应当将由 ParentForm 属性返回的引用显式转换成适当的类型。 下列代码演示如何使用 ParentForm 属性访问父窗体上的属性(在此示例中为 Text 属性):

' Visual Basic
Public Sub GetParentText()
Dim x as String
x = CType(Me.ParentForm, Form1).Text
End Sub

// C#
public void GetParentText()
{
string x = ((Form1)this.ParentForm).Text
}


可是所谓的父窗体指的是什么呢?
这里的ParentForm属性只有在MDI环境下的子窗口才有效,可见父窗体指的是MDI风格的父窗口。(在MSDN里这之前的章节里根本没有提到过MDI字样)
如果你是通过一个普通的ShowDialog(me)显出出来的窗口,那么千万不要被MSDN误导,这时候的父窗口需要通过Owner属性取得。我想Owner更常用。

读MSDN很有用。我知道了Close()并不会真正关闭窗口,只是Hide()而已。Dispose()才是生死判官。呵呵。

Monday, April 12

奇怪的C#语法:缺省参数
C#不支持缺省参数。只能通过重栽来实现缺省参数的需求。VB.NET和C++都支持。可是特性(attribute)缺支持缺省参数。
另一方面,属性property的set里面有缺省参数value。

难道不自相矛盾吗???
1,使用System.IO.Path.GetFullPath(.)或者System.IO.Path.GetFullPath("c:")这样的命令,每次运行可能得到不同的结果。特别是是使用VS.NET开发时。而且Framework1.0和1.1的运行结果也可能不一致。比如:GetFullPath("c:")「注意不是C:\」,在VS.NET 2002下经常会得到C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE这样的结果,但有时也会得到C:\。即使你将CurrentPath设成C:\也没有用。由于Path的IL内部使用经过优化或者是native的nGetFullPathHelper()函数取得FullPath,我无法分析具体的原因。MSDN上也没有给出足够的信息。

2,通过继承Control来定制自己的控件的时候,请注意属性初始化的位置。
方案(1) 变量声明既初始化
Private _path As String = System.IO.Directory.GetCurrentDirectory ''初始位置
Public Property Path() As String
Get
Return _path
End Get
Set(ByVal Value As String)
_path = System.IO.Path.GetFullPath(Value)
End Set
End Property

方案(2)在New里初始化
Private _path As String
Public Property Path() As String
Get
Return _path
End Get
Set(ByVal Value As String)
_path = System.IO.Path.GetFullPath(Value)
End Set
End Property

Public Sub New()
MyBase.New()

Me._path = System.IO.Directory.GetCurrentDirectory ''初始位置
End Sub

方案1,一般情况下不会出现问题。方案2,VS.NET的DesignMode会自动将你项目所在目录的写入Form的InitializeComponent()里。
如同,
.... ...
MyControl.Path = "C:\MyProject\TestControl"
.... ...
这样你的程序配布到其他机器上的时候,可能会出现目录不存在的错误。

以上代码为VB.NET。

Thursday, April 8

不管你是否相信,BUG永远与我们同在。包括使用JAVA的"勇气"与"机遇"号火星探测器。
今天遇到的问题是来自.NET Framework 1.0/1.1的FileStream。

现象:
当我将一些文本内容写到软盘里的一个文件的时候,出现了IOException,磁盘容量已满。我的catch部分捕获了这个异常,但是我无论如何无法关闭已经打开的文件。结果就是在软盘里生成了一个0字节的文件,在我的程序不完全关闭的情况下,我用文件管理器无法删除它。

原因:
我发现这个异常是由Close引起的,Close方法在内部调用了Flush方法将缓冲区里的内容写到软盘里去的时候,发生了这个异常。异常发生以后,FileStream没有关闭文件句柄(HANDLE),导致文件一直被占用。即使我试图用CloseHandle来关闭文件句柄也不成功,原因是取得Handle这个属性在内部会调用Flush方法,导致异常发生。

解决办法:
1,不用.NET Framework 1.0/1.1提供的FileStream,自己封装Win32 API (太不现实了吧:s)
2,在write之前,先调用SetLength。SetLength这个方法会改变stream的大小,你需要预先计算一下你准备写多少字节到文件里去。如果磁盘已满,在这个方法上就会发生异常,这时候内部缓冲区里还没有内容,所以Close会正确关闭。
3,Close之前清空内部缓冲区。FileStream的设计者为了保证数据都会被写入文件,在这个类的很多地方都调用Flush来将内部缓冲区的内容写到磁盘上,而没有给用户提供直接操作这一缓冲区的方法。
只好用一些黑客手段达到目的了。
...
catch( IOException excep )
{
// 清空内部缓冲区
Type streamType = stream.GetType();
System.Reflection.FieldInfo field;
// 得到private int _writePos 的FieldInfo
field = streamType.GetField( "_writePos",BindingFlags.NonPublic | BindingFlags.Instance );
// 设置缓冲区指针的位置为0
field.SetValue( stream, (int)0 );
}
finally
{
stream.Close(); // Close 成功。
}

总结:
方法3无法保证对.NET Framework 今后的版本也有效。方法2对于很多情况不是很有效。方法1需要高超的技术水平。方法0,期待MS改进它的Framework 。

参考:
1,http://mag.autumn.org/Content.aspx?id=20040202140342(日文)
2,http://www.gdncom.jp/general/mllog/tech/techDetail.aspx?ID=215(日文)

Friday, March 26

dev-club上有一个让开心就好FT的问题
其实题目的本意是希望能够方便地调试存储过程,希望能将存储过程的执行log打出来。
照我的理解
由于存储过程编译执行的,内部处理不是简单的字符串置换,是无法实时输出完整的执行SQL的。
sql server内部有一个fn_get_sql函数,可以得到当前告诉锾存里的sql文,这个sql应该只是你的调用命令,而不是解析以后的存储过程内容。

如果希望在存储过程里输出一些信息到客户端以方便了解存储过程执行了那些条件分枝,可以使用PRINT命令。PRINT出来的结果,在客户端可以通过SqlException的Errors分别得到。每一行PRINT都会形成一个SqlError存储在Errors这个集合里。
但是这些信息只有发生SQL异常的时候才能得到,如何没有发生异常也得到调试信息,我不知道。
你知道吗?

Thursday, March 11

注意SIZE
对于一个严格的项目来说,画面的大小,颜色,所用的字体等等细味的地方都是有要求的。
今天遇到一个恼火的问题:我用VB.NET开发了10几个winform,按照设计规约设置了form的属性,包括字体,ControlMenu和size。这些属性都可以在design模式的属性窗里指定,真是很方便的。而且我还使用了form的继承这一技巧,使这10几个form的外观都一致。今天遇到的问题是我的程序拿到另外一台机器上,打开项目,一查看我设置的属性。为什么size都不对了呢???这真是一个涉及个人名誉的严重问题。这么点小事情也做不好可不行啊。

调查开始了.....(省略若干字)

答案:
在VS是根据我的设定生成的代码里根本就没有size这个属性,只有ClientSize。

MSDN上说窗体工作区的大小是除边框和标题栏外窗体的大小。窗体的工作区是窗体内可放置控件的区域。当执行图形操作或调整窗体上控件的大小和位置时,可以使用此属性获取正确的尺寸。若要获取整个窗体的大小,请使用 Size 属性或使用单个属性 Height 和 Width。

而这个size是根据windows的desktop设置决定的,你的windows使用不同的theme,不同的字体大小都会影响一个form的边框大小和标题栏大小。VS的生成程序聪明地用你指定的size减去当前的边框大小和标题栏大小,只需要记住clientsize就可以了。可是用户可是只能设置size啊,这样的在不同的theme下按照同一个开发约定开发出来的form大小就可能不一致。

这是一个BUG???我认为是。
重粒子@请去朝圣的MVP们转达民情。



Thursday, March 4

动机与价值

思归总是成为引导话提的先行者。
无论是理想主义也好现实主意也好,人类最基本的生存原则都是无法违背的。
小气的神的随笔"可能性 vs. 必要性"里有几句话给我留下了深刻印象:
"
人们若不是因为可能得到某种利益而行动就是因为他不得不这么做
人们看待事情的角度若不是以对自己是否有影响作为判断依据,就是以是否会对他人造成影响作为依据
人们做决定不是为了感受快乐就是为了逃避痛苦
"
编写程序使的程序员获得了快乐,这种快乐来自于人类本性。很小的孩子就知道在沙滩上建造城堡获得这种快乐,他使人有成就感,驾御心,驱动你去学习,从而获得魔术般的力量。
free的思想倡导我们将自己获得的快乐无偿地与人共享。商业的头脑则认为这不应该仅仅是快乐,而且也是财富,别人要获得它,就要做出等价交换。

我是倾向于后者的。曾经有人通过msn向我咨询一个商业系统的设计思想,那个系统每年为他们的公司创造几百上千万的利润,可是系统越来越庞大,开发人员换来换去,没有一个坚固的程序框架,意用性,扩展性都很差。那时候,我突然意识到不能无常地告诉他。针对他个人我只能告诉他去读什么书,看什么samples。针对公司,我就应该通过讲课的形式或者某种其他形式获得应有的报酬。那是一次思想的突变。个人的交流是相互学习的过程,单向的无偿请教则是培养懒惰的途径。

ms是最好的商业思想学习榜样,gates从一开始就认识到了正确的商业模式。给无数的人带来快乐的同时,自己也获得了巨大的财富。没有免费的午餐,但是有永远的谎言。linux是另外一种商业模式,而且是一种建立在谎言基础上的模式。redhat,ibm这些公司几乎是无偿地使用了无数为linux奉献过的头脑。他们遵循协议,公开source,他们是通过读懂或者会使用别人编写的代码来来获得利润。那些写code的人是没有报酬的。这是什么样的逻辑???
open source的自由风格影响ms这样的商业公司,使的他们明白商业的目的是要满足和提供给人们快乐,无论那是通过怎样的形式,获取最大的价值是不变的主题。

我们来看看ms发动mvp活动的动机是什么?
MVP往往是某个领域的专家,他们拥有自己的个人魅力和事业,对他们的关怀,免费提供各种好处,只需要很小的代价,就可以将ms的影响通过他们扩散到他们的周围去。
这种彼此愉悦的活动真是最好的商业举动。

MVP们不断帮助人的动力是什么?
是MVP的名誉?错
是他们的内心可以从帮助人这件事获得愉悦。因为这种举动证明他是有用的人,是可以影响别人的人。
倡导open source的人们其实同样是为了获得这种感觉。只不过没有一个ms这么大的公司去鼓励他们,给他们MVP这样的名号而已。

在很久以前听到"没有永远的朋友,只有永远的利益"这句话的时候,我才知道什么是社会。

重粒子@动机决定行为,行为决定价值


评论
# 回复: 动机与价值 3/4/2004 12:16 PM saucer
呵,好像是骂我?:-) 我同意你的观点,我感觉很大程度上这有点类似资本主义与共产主义之争 其实我很讨厌跟人争论,世界上很多事情不是黑白分明的,但经常地,有人喜欢把问题极端化,上纲上线,或者get personal,肆意骂人,就是平常温尔文雅,很讲道理的人,一涉及某些问题,就会变得非常偏执,“宗教性”,所以我往往敬而远之
# 回复: 动机与价值 3/4/2004 12:39 PM rIPPER
Zealot's zealotic zealotry.
# 回复: 动机与价值 3/4/2004 12:56 PM Daily Linux User
>gates从一开始就认识到了正确的商业模式。 >linux是另外一种商业模式. IMHO 应该说 Gates认识到了软件商业模式 RMS认识到了非商业模式 RedHat/IBM认识到了利用RMS的非商业模式的产品作为工具的商业模式 It's all about choices, RMS dont want to kill all businessman and rule the world (or does him?:-P), he just want to provied another choice.
# 回复: 动机与价值 3/4/2004 1:07 PM Daily Linux User
那些写code的人是没有报酬的。这是什么样的逻辑??? 有句话咋说?有钱难买我愿意啊 首先是Linus自己愿意用GPL发布的,又不是受了某商人之欺骗,被带沟里去了,而商人们按照游戏规则以此获利,也本来就是题中应有之意,难道Linus是白痴?或者难到他对他没有挣到产品带来的利润之大头发表过什么怨言? 那么谎言又在哪里?
# 回复: 动机与价值 3/4/2004 1:47 PM rIPPER
支持free 和 open soure的也不是个个都支持rms。不如就不会出这么多licence了。 再有了IBM这帮家伙的做法也没有什么啊,人人都可以卖GPL的东西,有本事把个发行版卖到x万刀,xx万刀都可以啊。 linux没有什么商业模式,所谓商业模式总是某个公司弄出来的。 很多玩free的人,动机大概就是为了fun。
# 回复: 动机与价值 3/4/2004 1:54 PM Daily Linux User
嗯,俺最开始收藏这个站就是因为JoyCode 开心就好 这样的名字实在太对俺胃口了
# 回复: 动机与价值 3/4/2004 2:13 PM DBlue
Linux之父出了一本书:Just For Fun(只是为了好玩,或云《乐者为王》)。 Linux本来就是为了一种乐趣存在。 而微软一开始就是为了商业利益存在。 而任何东西都有两面性,你说是吗?
# 回复: 动机与价值 3/4/2004 2:22 PM Daily Linux User
《乐者为王》 这名字停上去还是太有争权夺利那意思哈. 还是 开心就好 比较^^^^
# 回复: 动机与价值 3/4/2004 2:28 PM rIPPER
让人恶心的是有人一边在linux身上“施暴”,一边指责微软把他家大老婆windows和小妾office、各类server们锁在家里,不给大家一起爽。
# 回复: 动机与价值 3/4/2004 2:45 PM 丰腴者
rIPPER搞笑,有意思
# 回复: 动机与价值 3/4/2004 4:07 PM mvm
"微软一开始就是为了商业利益存在" 没办法啊,熙熙攘攘,皆为利往。 不过我觉得微软的程序员们——甚至包括我们这些做商业软件的,都是同时为了利益和个人成就感而存在的。 邵一波(大概不是这样拼的)做eachnet,一开始的动机是觉得国内没有拍卖网站不爽。当然,也开始也想到赚钱了。 两个动机都有。 我们应该承认人有私欲——私欲包括成就感,包括通过帮助别人带来的自我价值的实现,包括通过被别人admire带来的一种愉悦,包括通过自己的聪明才智和劳动换来物质的享受。都包括。 所以我觉得大家各取所需好了。总有一部分人很不看重物质享受和财物收入,那么他们完全可以按照自己的意愿搞free、搞open。但他们应该更兼容并包,不能搞排斥,不能自己搞了open和free,就认为commercial的是魔鬼、是异端邪说。 市场经济最大的特点就是一个愿打,一个愿挨。这是市场经济运作的基础。包括“看不见的手”在内,都逃不开这个道理。open/free soft和commercial的也是,一个愿打,一个愿挨,各取所需。open/free的支持者不应该把差异上升到伦理的高度——不要去讨论“好不好”。“好不好”是个伦理问题,是一生一世争论不休的——你说堕胎好还是不好? 我就感觉open/free的一些支持者过于狂热、排斥,视commercial为异端——这里的commercial当然不止microsoft/windows。Websphere也是commercial的,Photoshop也是commercial的,Dreamweaver也是commercial的,Counter Strike也是commercial的。 那么多游戏都是commercial的。commercial soft是美好生活不可或缺的重要部分。
# 回复: 动机与价值 3/4/2004 4:57 PM rIPPER
身在中国,它们对我都是free的,唯独电信的网费是一分一厘也少不了的。 我心里怀着小小的私心:狂热者们最好去各类电信服务供应商、电信设备提供商面前跪陈情愿,好让我免费上网、打电话(我自己是万万不会去的,所以只想着有人会代我完成,人总是爱坐享其成 :)。 虽然明知道决无可能,但始终觉得这份小小的心愿和某些举民族大旗、呼啸山林、聚众水泊(blogchina? :),即free且open的“好汉”们不懈努力要求微软开源、免费的壮举或是义举暗合。 因此我仍保留着这这份心愿,每每于夜深人静之时、四下无人之处细细咀嚼、暗自YY一番。
# 回复: 动机与价值 3/4/2004 5:50 PM Daily Linux User
做Commercial的痛骂做Free/Open的也一点都不少哈, 好象微软就说过Linux是邪恶的,是产业的病毒还是什么哈,CSDN上面更加上纲而下流的辱骂更是连篇类牍哈 想信双方如果在稍微严肃一点的发言中都不会这样的哈 当然有些比较极端的人那也很自然哈 不过您也千万别把Slastdot之类上的言论当真哈 而且您在Blog上散布FUD的密度也很高哈
# 回复: 动机与价值 3/4/2004 5:52 PM Daily Linux User
忘写了 那是 To: MVM not baryon ha !
# 回复: 动机与价值 3/4/2004 6:19 PM rIPPER
嘿嘿,mvm喜欢表达自己的意见,也蛮好的。
# 回复: 动机与价值 3/4/2004 7:16 PM kaka
说句不好听的,这个是典型的有奶便是娘的思想。 当一个企业过于强大,以至于垄断的时候,对一个国家,乃至世界来说都不是一件好事情。举个最简单的例子来说,二战后,欧洲先于美国开始商业喷气飞机制造。难道是美国当时飞机制造技术没有欧洲先进?不是,绝对不是。而是因为美国当时的飞机制造也少数几家所垄断,二战中遗留下来大量的制造螺旋桨飞机的资源还没有产出足够的利润。因而垄断的结果就是当欧洲人可以享受喷气旅行,而美国人却只能为了先添饱资本家的口袋,而继续着螺旋桨时代。这个就是垄断。 ms今天这么积极,也正是有着这些free/open的东西在和他竞争,如果没有了这些东西,ms绝对会成为科技进步的最大阻力。 那为什么只有free/open的东西呢?因为不free/open的东西,全给ms给弄死了。有几家公司能顶得住ms的“三招”。 至于MVP,我可以用电影《马尔可目.X》中的一段马尔可目.X话来告诉你:南北战争中的一天,北方军队开始进攻一个地方,农厂里面的黑奴开始逃跑,一个在田里工作的黑奴跑到屋子里面,对一个在房子里面工作的黑奴说,我们快逃吧,我们终于可以自由了。那个房子里工作的黑奴说,不,这是我的家,我爱我的主人,我的主人也爱我,我吃得饱,穿得暖,所以我不跑。难道那个不跑的黑奴得到他应该有的权利吗?不,不是,他是个彻底的奴隶。不会因为他比其他奴隶待遇好,而改变这一根本点。MVP也只不过是比普通用户稍微活得好点的ms的奴隶。 最后提醒你一下,free/open中的“/”是or的意思。free的不一定open,open的也不定fee,mysql就是open,但不是free,没有人说搞open就不能赚钱。GPL,GNU,BSD等都是不一样的。别一看open,感觉就让你革命成无产阶级了。 ps:我比较认同网上一个思想,至少我们要在道义上支持free/open的东西,虽然我们不一定需要去用他。 psps:感觉我是在浪费时间,这种讨论网上也太多了,没有想到我也会参与近来。
# 回复: 动机与价值 3/4/2004 8:02 PM Daily Linux User
GNU 8是一个协议哈,GPL揍是GNU的协议哈 要其他的例子主要的有LGPL,Apache,X,Eclipse的CPL,Mozilla等等哈……大多数最著名滴Free/Open滴东东都用自己的专有协议滴。 MS滴Shared Source也算一种哈。 奇怪……我说话怎么变味儿了
# 回复: 动机与价值 3/5/2004 9:06 AM rIPPER
嘿嘿,ms的shared source协议很宽松di,我准备弄它的源码修改修改包装一下拿去卖。 说到飞机的话题我最喜欢了。欧洲在二战还没有结束的时候已经研制成功可以实用的喷气发动机了,因此比米国先行一步也挺正常,用这个例子实在说明不了问题。再说彗星的金属疲劳问题让它变成了喷气时代航空安全的先行者:) 赶早对于消费者来说也不一定是好事。
# 回复: 动机与价值 3/5/2004 9:22 AM carfield
同意Daily Linux User open 的人攻击过 MS 的东西不好,但是好像没有说过通过软件赚钱是邪恶的,他们并没有排斥软件的价值 倒是M$说过Linux是邪恶的,是产业的病毒,是因为它们碍着自己的财路了
# 回复: 动机与价值 3/5/2004 9:36 AM mvm
我就不喜欢kaka那几句话: 什么叫做MVP只不过是日子过得比较好的奴隶? kaka不应该把关于问题的讨论上升到价值判断的角度,不应该诋毁那些MVP——大家都是混饭吃的,说什么奴隶不奴隶的?大家都是同胞好不好? to carfield: M$说过Linux是邪恶的——Linux的fans也说过类似的话。也有人说过通过软件赚钱是邪恶的。在相互攻击的问题上,两个阵营都有些人说过很不好听的话——这不,上面还有人说MVP是奴隶呢。 言犹在耳。 btw, to kaka, "free的不一定open,open的也不定free"这种问题,我想在博课堂这里,是不需要你来提醒的。藏龙卧虎的人很多,大家都是IT行业混得,这些都是基本常识了。不过我倒是建议如果还有没有看过这个网站的人都仔细看一下,一个个仔细读一下:http://www.opensource.org/licenses/ 我记得有这么一句话:你的所知就像你腕上的手表,别人没来问你时间的时候,不要主动把手表给人看。
# 回复: 动机与价值 3/5/2004 10:51 AM rIPPER
这许多license,如何读得完啊? 哪个指条明路,告诉我最open最free的一个,只需所取无需付出的那个,我好拿去卖钱了。 .TEXT是BSD的,是不是说明天我就可以包装了它叫卖了呢?知道的大侠指点俺一下。 MS说Linux是病毒其实不是针对Linux,而是指GPL。如果能考虑到在计算机软件方面两者完全不同价值取向,我想也不难理解MS为什么会这么说。误用了GPL会使MS的躯体被侵蚀,源码会被要求开发,MS当然害怕。Rotor(就是CLI啦http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7462-47D0-8E56-8DD34C6292F0&displaylang=en)支持FREEBSD,但是不敢(也许是不愿意,或者是害怕,谁知道呢)支持Linux。 MS现在也愿意开放一些源码,但是绝对不会用GPL。可能BSD更加对MS的胃口。 虽然起步比较晚,力度也不大(http://www.microsoft.com/resources/sharedsource/default.mspx),不过事情毕竟在往好的方向发展。 谁说MS不怕Linux呢? :)
# 回复: 动机与价值 3/5/2004 11:22 AM kaka
to:mvm 是的,大家都是赚钱。MVP也是一样。 但明明是在赚钱,就不要大喊为人民服务,这也太假了吧。
# 回复: 动机与价值 3/5/2004 12:14 PM mvm
to kaka: 赚钱为什么不能同时为人民服务? 所有作盈利性服务的行业,目的都是赚钱,但同时都有“顾客就是上帝”的口号,都会把“customer focused”作为自己的准则。 这两者不矛盾。 非黑即白是一种简单粗糙的方法。是不可取的。 to ripper: 我的粗浅理解是:BSD是最自由的。Kerbrose好像就是BSD的(因此也出现了很多问题,比如各种版本不兼容等)。
# 回复: 动机与价值 3/5/2004 1:12 PM rIPPER
谢谢mvm 关于矛盾,还是需要运用马克思主义的观点辨证的分析;关于ms和free/open的斗争,需要运用毛泽东同志的革命战争思想来把握;说到赚钱和为人民服务,那就用3gdb凑合着使使吧。 俺的终极目标是做一个高尚的人,一个纯粹的人,一个有道德的人,一个脱离了低级趣味的人,一个有益于人民的人(口号俺也会喊,做到嘛,下辈子再努力啦 )。 和楼上诸位共勉 :)
# 回复: 动机与价值 3/5/2004 3:53 PM mvm
今天在博客中国看到的:http://www.blogchina.com/new/display/24837.html 正文和下面的评论...
# 回复: 动机与价值 3/5/2004 4:45 PM rIPPER
嘿嘿,不知道这些跟帖算不算群众的呼声。 还是做BitTorrent的老哥好,直接要求donate。本来嘛,有钱捧个钱场,没钱的捧个人场...
# 回复: 动机与价值 3/5/2004 5:08 PM Daily Linux User
许可证来说Modified BSD最自由,但压根没有许可证的Public Domain似乎应该更自由,可惜没有多少好东东是Public Domain的. :-( 我记得很久以前有个调查,关于Free软件的Contributors主要是些什么人,结果发现大多是白天上班写商业软件或者别的职业,业余时间写自由软件的,当时这个调查主要讨论的是代码质量,说既然是同一帮人写的,代码质量应该是差不多的,呵呵.
# 回复: 动机与价值 3/5/2004 5:10 PM Daily Linux User
可惜中国没有PayPal啊,MyIE2也只好搞个注册来弄,无聊啊无聊.
# 回复: 动机与价值 3/5/2004 5:23 PM rIPPER
商业软件有进度压力、这个压力那个压力,自然要在质量方面打折。 自由软件嘛,俺开心就写,不开心就...@#%$^^不开心随便干什么都好,就是不写code。如此应该是自由软件质量高一点。 再说了既然要开源,总会更加注重代码的质量啊,代码的规范啊,设计的合理啊,因为关系面子问题嘛。商业软件就管不了这么多了。 到此为止,俺的重大发现是: 开源软件质量高是因为写软件的人怕自己的代码发布出去被人家嘲笑,所以自己review的比较多。 俺去年注册了个Paypal帐户,今年准备做一个网上乞讨的site,不知道能不能骗到老外的嘛呢。主题还没有想好,是中国持不同政见者好呢,还是饱受Outsourcing折磨的中国可怜程序员好呢?
# 回复: 动机与价值 3/5/2004 5:38 PM Daily Linux User
面子问题,今天TheRegister上正好说这个呢 http://www.theregister.co.uk/content/55/36029.html 不过,比较重要而受关注的自由项目,由其是无数人依赖你的基础库/必备应用,也会有进度压力呢,说不定还有商业软件依赖你发布,要是比自己号称的进度晚了太久会被骂的, 骗钱的话,可以弄个亚洲程序员反外包同盟,米国失业程序员会把救济金都捐给你.
# 回复: 动机与价值 6/6/2004 3:58 PM 你 好
顾客即上帝与为人民服务的关系
# re: 动机与价值 10/27/2004 7:32 PM
免费是一种运营模式,嫌钱才是目的,世界上的free是相对的!
# re: 动机与价值 10/27/2004 7:34 PM 支持
发起人,写的很好





Thursday, February 26

我所经历的review
从n年前大学的毕业设计开始到现在,大大小小的软件项目做了很多。切身体会是如果一个项目不想最后演变成垃圾,最重要的就是交流
我的大学毕业设计是给一个国外大公司的做的,当时自觉已是C语言高手,2周做个dos下的editor都是小case,何况有一个学期的时间去"发明"(笑)一个排序程序呢。除了验收前一天,硬盘损坏,通宵重写了部分代码以外,程序做的还算顺利。考验来自后来的code review,先是部长写了review计划书,指定参加review的人员,review的方式和目标。参加人员是同一个部门的先辈和我的同级生,5个人左右。review方式采用面对面方式(另外一种方式是回览,既将代码打印交给review人员,不讲解,由他们在自己方便的时间进行检查)。review的目标指出1000行代码应该发现的bug数目,当时的计划好像是每千行发现25个bug。
首先由我介绍这个程序用途,我的实现方案,然后一个函数一行一行的进行了讲解。其他人可以随时打断我。
"这个变量有什么用途?怎么会叫这个名字?"
"这段代码是不是应该这么写......."
"这里应该有一些注释"
"哦,我发现了一个bug!"
我们随时对出现的问题做讨论,有一个人负责记录我们讨论的结果,将不妥当程序的行号,原因,处理办法都记录在review报告书上。
经过两个小时的review,头冒汗声发抖,实实在在地发现很多以前想都没有想到的问题。
改正这些bug以后,感觉心里塌实了很多,对自己的程序质量有了很大的信心。

后来我也参加了其他人的document review, code review,一直到我带领项目,组织review。切实感觉review是非常好的质量保证手段同时它促进了集体技术水平的提高。
我带过一些刚毕业半年的newbie做过两个项目,没有review的话那结果将无法想像。
其中一个项目工期极其紧张,在设计好框架以后的两周里,5个pair居然没有一个能拿出可以运转的模块,计划可是2个人一组1周做出两个模块啊,当时真是急得火上房。主要是大家的思想还没有统一,对如何写出程序来还不清楚。关键时刻review发挥了重要作用。我参加了一组的coding工作,实际指导和暗示了程序的写法,随后立即进行review。通过作者们的讲解,以及大家的提问和讨论,大家清楚了程序越来是怎么编出来。以后的开发效率明显提高,10个人两个月50个模块(ASP+COM+Oracle StoreProcedure)艰苦地完成了,要知道10个人里面大部分是刚毕业半年的新手。

review不是万能的,也会导致一些问题
1,得罪人。在我指出一个同级生的bug时,他恨得要命,后来同我说,当时差点就想跑过来掐死我了(:>)
2,惨不人睹。有的code实在太难看,作者有时自己都看不懂了,review根本就无法进行,代码必须重写。
3,导致时间紧张。有时工期非常紧张,如果每个人的代码全都进行面对面review的话,会延误工期,这时候就需要manager做出判断,进行回览形式的review。
4,bug还是有的。不能完全依赖review来找出所有的bug,review以后的测试才是主要的除错手段。

重粒子@到了写回忆录的年纪了

Wednesday, February 18

今天早上从我订阅的讨论组里也看到了思归提到的这个联接We Are Morons: a quick look at the Win2k source || kuro5hin.org

以下内容全部删除

Thursday, February 5

我们需要什么样的研究态度?
我们做SE的人需要怎样的研究学习态度?

前几天在csdn上看过这篇介绍毕业生求职的文章,感叹我不如此公。8年前刚毕业的时候不如他,8年后也不如。看来我是白学了10几年的CS了。
做SE,学CS的人需要怎样的研究学习态度?
我想至少下面这几种态度是可怕的,要不得的。
1,只知皮毛就高谈阔论(危害性:低,容易辨别)
2,知晓某一方面的知识,就自吹是这个领域的专家。(危害性:中,不容易辨别,只有项目中后期才能看出来)
3,明知自己犯了错误,确为错误找理由,说明那是正确的。(危害性:大,道德有问题)

面对某一个问题,敢明白地承认自己不懂,自己做错了都是极其令人尊重的。

今天遇到了持第3种态度的人,受了刺激,胡言乱语几句。


注:
SE=System Enginer/Software Enginer
CS=Computer Science

Tuesday, February 3

MS也顶不住了。为了准备马上到来的MyDoom.B的攻击,微软准备了备用网站。
https://information.microsoft.com
早些时候,SCO集团也使用了备用网站www.thescogroup.com

如果,MyDoom.A和MyDoom.B是同一个人写出来的话,他们他/她最少价值50万美元。这就是一个程序员的价值,虽然不好兑现:>

网络的安全从来不是空洞的。即使我们这些整天摸键盘的人也是防不胜防的,想指望那些未入门,刚入门的初级用户了解网络的风险更是困难的事情。broadband的时代有broad risk。:s

Thursday, January 29

这几天国内在过年,MSN上在线的人都很少。生活在国外的思归倒是随笔不断。在他的一篇随笔里看到“头脑风暴”集体自由讨论专题的连接。粗读了一下,虽然并没有非常详细地介绍我关心的"高级头脑风暴",但是还是有价值的读物。
思考一个问题,不断地设问,从不同的角度看问题,联想,穷尽所能地列举各种可能所带来的好处,确实是学习,研究和工作的重要手段。无论这个方法叫做什么,都不是重要的事情。同妻一起作了近一年的强相关逻辑研究,好多激荡式的思考,热烈的争论都带来耳目一新的感觉。

大怪兽今天发现一个网址:Win32サブルーチンズ。里面有很多出色的介绍Win32编程书,很多已经是绝版的了。幸亏作者公开了那些书的内容。按照怪兽的说法这些内容是MSDN很好的补充。虽然没有时间看,但是也写到blog里存档。


Friday, January 16

BUGS
FeedDemon真是一个漂亮的shareware, 程序从界面到功能看上去都极其专业。用它来读blog和news确实方便。用了这个软件才真正感觉到基于XML的RSS不经意见就有所成就了。
这个软件在多国语言上还有一些bug,我只好用english界面。通过这个软件来看博客堂,我发现了博客堂的一个bug,就是RSS的头没有改成自己的。
我在.Text的source里找了一下,在Dottext.Web.Rss这个类里面,是用硬编码写的。
//Channel Description
writer.WriteElementString("title","WebLogs @ ASP.NET");
writer.WriteElementString("link","http://weblogs.asp.net");
writer.WriteElementString("description",".NETWeblogs by .NET Developers");
writer.WriteElementString("generator",Dottext.Framework.VersionInfo.Version);
这个BUG要是不改正,在加channel到FeedDemon的时候可能会和已经存在的WebLogs @ ASP.NET冲突,必须手动改名。而且随笔的出处联接也都是http://weblogs.asp.net。
.Text好多地方为了重用,搞的结构很复杂,在这个小地方用硬编码确实不可理解。也许是对RSS功能不是特别重视吧。

说到bug,我还遇到了asp.net 1.1的bug。在写一个page template的时候,我将form放入一个ascx中就会导致一个客户端script错误。详细的错误描述在msdn上有描述
http://support.microsoft.com/default.aspx?id=818803
这个bug需要等待一个新的NET Framework 1.1 service pack问世。
暂时的措施是:http://www.asp.net/Forums/ShowPost.aspx?PostID=206709

在另外一个地址上有一些已经发现的bug列标。
http://support.microsoft.com/default.aspx?kbid=821156

重粒子@BUG是程序的魅力之一

Wednesday, January 14

如此SB
1)恨不得大骂。竟然有如此SB的项目。
面对那个白痴项目,我想让它稍微聪明一点。对Oracle COM用一个类封装了一下,用起来类似MS的data access block。 居然被否定了一半。 原因是不能用缺省的VB弹出的出错信息。不是那个出错信息太少, 而是太多了。 靠靠。

2)最近连着读了日经BP网<中国故事--日本最大的离岸开发成功启示录>(1) (2) (3)
外包项目确实是趋势, 中国人件费的廉价,导致如此多的项目发注到中国去。外包项目其实对双方都是有利的。日方可以用相对廉价的代价开发出项目来。中方获得相应的外汇收入,而且一般很少发生拖欠项目经费的事情。
这样的项目一般来说都是日方写出需求说明书,概要设计书,甚至很多项目要写出详细说明书。这个写说明书的工作一般叫做上游工程。项目流到中国去以后,由中国程序员作详细设计和codeing,这个工作叫做下游工程。
外包项目怎样能够保证成功呢?软件的质量怎么控制呢?看看上面那篇文章里成功和失败的对比就很清楚了。
1:交流。交流充分与否是一个项目能否成功的基本前提。
2:热情。一般来说作下游工程没什么激情可言。日方的说明书往往写的详细之极。有的甚至到变量的名称。能否调动出中方的积极性来作这种"体力劳动"呢?
3:跟踪。项目的每一个阶段,是否有明确的负责人,日方是否清楚项目的进度。中方是否及时反应了遇到的困难?
4:测试。中方一定要作充分的单体测试,否则交给日方以后,低级的错误往往导致合作不愉快,会对中方的开发能力产生怀疑。
5:理解。相互的尊重和理解是基本的做人前提。任何的居高临下,阿谀奉承或者种族歧视都是分裂的触发器。

日本也有作下游工程的公司。比如我现在作的这个SB项目就是作详细说明和coding。日本的开发者往往听话地听作苦力。作法是否愚蠢不管他们的事。中国开发者往往是想提出自己的见解,耽误了项目的schedule。任何过分的作法都是不对的。

Saturday, January 10

■PBC001カメラ 「INFに必要なセクションが見つかりませんでした」エラーについて
2003年4月、ヨドバシカメラで購入したPBC001WEBカメラは画像はよく映らないですから、12月ヨドバシカメラで保障期間内で修理してもらいました。結局、新品を交換した。新品のドライバは7月4日のものですから、古いドライバをアンインストールして、7月4日のドライバをなかなかインストールできない状態です。http://www.persol-jp.com/download/download.html#pbc001からDOWNLOADしたドライバと製品付属CDにあるドライバを両方ともインストールしてみました。だめでした。何度もpersol-jp社に質問のメールを出しましたけど、解決できなかった。
----------------
persol-jp社の対処方法
上記問題を解決する手段として下記方法を行って頂く以外に
対応方法がございません。

①Windowsファイルの上書きインストールを行う。

②OSのクリーンインストールを行う。
----------------
そんな無理な答えです。
7月4日のPBC001のドライバに絶対バグがありますと思いますから、私は少し直してみてもうインストールできました。(WindowsXPの場合)
C:\WINDOWS\inf\usbcam.infファイルの最後に
[ClassInstall32]
一行を追加してインストールを続きました。
完璧ではないですけど、万一、他の利用者に同じ問題があれば多少助けると思いますから、やり方をメールでpersol-jp社に出しました。。

実は手元のPBC001の画面品質は理想的ではないですが、ドライバの問題ですか本体の問題ですかよくわからない。
今後ぜひブランド商品(LogiTech?)を使ったほうがよいと思います。

Wednesday, January 7

白痴项目
定论:我现在做的这个项目是极端白痴的。
说明:这是一个从VB6升级到VB.Net的项目。一小部分程序直接使用VS.NET的转换结果。大部分程序都要重新写,主要是因为数据库(oracle)的设计有一些变更。
看看我们经客户定案的程序规约:
1,使用.net framework 1.0 (not 1.1)
2,使用Oracle In Process OLE Automation Server, 而不是ADO.Net的OleDB或者OracleClient。理由1,OleDB或者OracleClient是MS做的,MS不值得信赖。(反驳意见:VB.NET也是MS做的) 理由2:VS.NET的自动转换结果使用的就是Oracle In Process COM
3,每一个函数,类,模块都有一个变量,标明它的ID,输出出错信息和log的时候用
4,共通模块使用link文件的形式引入项目,不是用DLL参照或者项目参照。
5,所有的变量都要有前缀,3个字母, 而不是1个。因为3个字母更清楚。boolean->bln,integer->int,structure->typ
6,所有的函数和过程都有前缀,3个字母加一个下滑线,表明返回值的类型。例:bln_CheckInput()
7,不仅仅服务器上要安装oracle server,客户端也有一个oracle server,用来存储客户端的数据。
8,项目里的文件路径指定使用绝对路径。D:\MDB\XXX9,
9,不要使用TRY...CATCH...FINALLY,要用ON ERROR...


这个世界一定是哪里不对了,是哪里呢?

聪明的你能告诉我吗?