使用m3u文件连续播放音乐

1. 最简易的连续播放视频/音频的代码

<ASX version =”3.0″>

<Entry>
    <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址1″/>
</Entry>

<Entry>
    <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址2″/>
</Entry>

<Entry>
    <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址3″/>
</Entry>


以下同样添加你想要的视频音频个数

</ASX>


 

 

 

 


2. 可以显示歌曲名称/演员名称的连续播放视频/音频的代码


<ASX version =”3.0″>

<Entry>
  <Title>这里添加标题1 视频/音乐名称等等</Title>
  <Author>演员/歌手名1</Author>
  <Copyright>版权归属1</Copyright>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址1″/>
</Entry>


<Entry>
  <Title>这里添加标题2 视频/音乐名称等等</Title>
  <Author>演员/歌手名2</Author>
  <Copyright>版权归属2</Copyright>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址2″/>
</Entry>


<Entry>
  <Title>这里添加标题3 视频/音乐名称等等</Title>
  <Author>演员/歌手名3</Author>
  <Copyright>版权归属3</Copyright>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址3″/>
</Entry>


以下同样添加你想要的视频音频个数

</ASX>


3. 可以显示自己的logo或广告以及歌曲名称/演员名称的连续播放视频/音频的代码


<ASX version =”3.0″>


<Entry>
  <Title>这里添加标题1 视频/音乐名称等等</Title>
  <Author>演员/歌手名1</Author>
  <Copyright>版权归属1</Copyright>
    <Banner href = “你的个性图片在网络中的地址1”>
    </Banner>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址1″/>
</Entry>


<Entry>
  <Title>这里添加标题2 视频/音乐名称等等</Title>
  <Author>演员/歌手名2</Author>
  <Copyright>版权归属2</Copyright>
    <Banner href = “你的个性图片在网络中的地址2”>
    </Banner>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址2″/>
</Entry>


<Entry>
  <Title>这里添加标题 视频/音乐名称等等</Title>
  <Author>演员/歌手名</Author>
  <Copyright>版权归属</Copyright>
    <Banner href = “你的个性图片在网络中的地址3”>
    </Banner>
  <Ref href = “以http或mms开头以mp3/wma/wmv/wav/midi/mpg/mpeg/avi结尾的视频音频地址3″/>
</Entry>


以下同样添加你想要的视频音频个数

</ASX>




将以上文件取名为”任意名.m3u”。

调用方式形如:


<embed src=”test.m3u” type=”application/x-mplayer2″ autostart=”true” loop=”-1″ controls=”ControlPanel” width=”600″ height=”500″ >

软件版本Beta,RC,Demo,Build等含义总结

版本号:
V(Version):即版本,通常用数字表示版本号。(如:EVEREST Ultimate v4.20.1188 Beta )
Build:用数字或日期标示版本号的一种方式。(如:VeryCD eMule v0.48a Build 071112)
SP:Service Pack,升级包。(如:Windows XP SP 2/Vista SP 1)

授权和功能划分:
Trial:试用版,通常都有时间限制,有些试用版软件还在功能上做了一定的限制。可注册或购买成为正式版
Unregistered:未注册版,通常没有时间限制,在功能上相对于正式版做了一定的限制。可注册或购买成为正式版。
Demo:演示版,仅仅集成了正式版中的几个功能,不能升级成正式版。
Lite:精简版。
Full version:完整版,属于正式版。

语言划分:
SC:Simplified Chinese简体中文版。
CN : 简体中文版
GBK:简体中文汉字内码扩展规范版。
TC:Traditional Chinese繁体中文版。
CHT : 繁体中文版
BIG5:繁体中文大五码版。
EN : 英文版
Multilanguage : 多语言版
UTF8:Unicode Transformation Format 8 bit,对现有的中文系统不是好的解决方案。



开发阶段划分:
α(Alpha)版:内测版,内部交流或者专业测试人员测试用。Bug较多,普通用户最好不要安装。
β(Beta)版:公测版,专业爱好者大规模测试用,存在一些缺陷,该版本也不适合一般用户安装。
γ(Gamma)版:相当成熟的测试版,与即将发行的正式版相差无几。
RC版:Release Candidate。
RC 版。是 Release Candidate 的缩写,意思是发布倒计时,候选版本,处于Gamma阶段,该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG,不会对软件做任何大的更改。从Alpha到Beta再到Gamma是改进的先后关系,但RC1、RC2往往是取舍关系。
Final:正式版。

其他版本
Enhance :增强版或者加强版 属于正式版1
Free :自由版
Release :发行版 有时间限制
Upgrade :升级版
Retail  :零售版
Cardware :属共享软件的一种,只要给作者回复一封电邮或明信片即可。(有的作者并由此提供注册码等),目前这种形式已不多见。/ S
Plus :属增强版,不过这种大部分是在程序界面及多媒体功能上增强。
Preview :预览版
Corporation & Enterprise :企业版
Standard :标准版
Mini :迷你版也叫精简版只有最基本的功能
Premium : 贵价版
Professional : 专业版
Express : 特别版
Deluxe : 豪华版
Regged : 已注册版

Rip :是指从原版文件(一般是指光盘或光盘镜像文件)直接将有用的内容(核心内容)分离出来,剔除无用的文档,例如PDF说明文件啊,视频演示啊之类的东西,也可以算做是精简版吧…但主要内容功能是一点也不能缺少的!另:DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。



RTM 版 :这基本就是最终的版本,英文是 Release To Manufactur,意思是发布到生产商。
Original Equipment Manufacturer (OEM) 
You may license products through an Original Equipment Manufacturer (OEM). These products, such as Windows operating systems, come installed when you purchase a new computer. 
OEM软件是给电脑生产厂的版本,无需多说。 

Full Packaged Product (FPP)/Retail 
Physical, shrink-wrapped boxes of licensed product that can be purchased in a local retail store or any local software retailer. 
FPP就是零售版(盒装软件),这种产品的光盘的卷标都带有”FPP”字样,比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN,其中WX表示是Windows XP,P是Professional(H是Home),FPP表明是零售版本,EN是表明是英语。获得途径除了在商店购买之外,某些MSDN用户也可以得到。
Volume Licensing for Organizations (VLO) 
You may enjoy potentially significant savings by acquiring multiple product licenses. Depending on the size and type of your organization. 
团体批量许可证(大量采购授权合约),这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有”VOL”字样,取”Volume”前3个字母,以表明是批量,比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN,其中WX表示是Windows XP,P是Professional(VOL没有Home版本),VOL表明是团体批量许可证版本,EN是表明是英语。获得途径主要是集团购买,某些MSDN用户也可以得到。

十年MFC经历认识的Microsoft技术

 
自从2005年3月8日下午16时“十年MFC经历认识的Microsoft技术”以帖子的方式发表于CSDN论坛后,引起了许多网友得好评,使得笔者诚惶诚恐,考虑到该贴过长(人气指数为5000),因此转移到Blog上,许多网友对此帖的评语只好省略,在此鄙人谢过了!为感谢网友的支持,本人希望今后能发出新的帖子以回报网友对我的鼓励,再一次谢谢!
 
 
 
初识MFC 
       我最初知道MFC大概是在1993年,那个时候Visual  C++还没面世,当时Microsoft的C++编译器还很弱,官方的名字是Microsoft  C/C++  7.0,MFC的版本是1.0,几乎没有引起什么反响,那个时期最好的C++开发环境是Borland  C++  3.1,其实,大概是1992年11月份,一个偶然的机会,我领略到Borland公司的厉害,记不得在什么地方,我看到一个绝妙的集成开发环境,即Turbo  C++  3.0  for  Windows,这是我记忆中第一个真正的Windows环境下的C++集成开发环境,那种激动的感觉至今仍记忆犹新,不客气的说,当时至少在C++方面,Microsoft与Borland不是一个水平的,Borland明显的要高于Microsoft  ,Borland的产品在技术上给我留下深刻的印象。那个时候Microsoft最好的开发平台是Visual  Basic  3.0,而Borland的Delphi正处于开发阶段(Delphi  的代码名称是:“VB  Killer”)……,想起这些十几年前的往事,我不禁感慨万千。 
十几年来,我用过许多开发环境,关于Visual  Basic,我用过最早的DOS版本,Windows版的Visual  Basic我基本上全都用过,至今我还记得每个版本的VB安装盘磁盘的盘数。同样,我用过各个版本的Delphi,特别是Delphi  2.0,给我留下极好的印象。Delphi提供真正编译的可视化开发环境,那个时候(1994年左右),Delphi就可以开发带有GUI的动态链接库,你可以想象,在Microsoft  Access  2.0的应用程序中可以加载一个Delphi  Form并进行程序交互,那种感觉真是棒极了。 
    Borland  C++是我心中无法抹掉的遗憾,从Turbo  C到C++  Builder,我深刻的体验到Borland的辉煌和无奈,Delphi从VB  Killer走到为VB护航(你可以想象Delphi一步到位的ActiveX  控件开发技术有多牛,早期的VB有多土,早期的VB不能开发动态链接库,因此无法开发ActiveX  控件,想起来真令人嘘唏不已),Borland  C++的命运也是不济。Borland  C++  3.1的辉煌永远不再了,十几年的开发工作中,我在C++上投入了大量的精力,Borland  C++曾经给我带来无数的激动,然而这个经典的名字却在与Microsoft的竞争中渐渐的流逝了……。 
MFC4.0的出现,使得人们感觉Microsoft在C++方面赶上来了,这一版的MFC是Win95推出后出现在Visual  C++  4中(Microsoft没有VC  3,VC4以前的版本是2.2、2.1、2.0、1.51、1.5、1.0)。也许是对Borland  C++的潜意识的失望,我不知不觉的接受了MFC,VC  4.2推出时,我通过正常渠道购买了这个编译器的企业版。
 
 
 
 关于Microsoft 
       关于Microsoft,有无数的人要对这个名字叙说感觉,这个令人讨厌的名字!不知道是喜欢还是憎恶,你是程序员,你的心思可能就要因Microsoft的存在而动,即使你用Linux,你可能也是因为Microsoft技术因素。多少年来,这个名字每天都出现在你、我、他的面前,因为你不得不面对Windows的存在,可是你憎恨这个名字吗?你讨厌这个名字吗?我不知道是否已经对这个名字麻木了。1998年我个人订了Microsoft  MSDN  Universal  版,我开始比较全面接触这个公司的开发技术,你可以想象,1998年当你面对上百张技术光盘的时候,你就知道什么叫做“厚度”,当我们有时说出“赶上”或  “达到”Microsoft某些产品的水平的时候,可能我们缺乏对这个公司“厚度”的真实了解。进入MSDN,我感觉Microsoft简直不是一个“公司”,而是(或者正在形成)一个“社会”。当时著名的技术网站http://www.codeguru.com全部的技术资料是可下载的(那个时候http://www.codeguru.com提供整个网站内容下载服务,大约3M左右),大名鼎鼎的www.codeproject.com还不存在。一开始,我始终潜意识在技术上对比Microsoft与Borland,应当说技术上Borland不比Microsoft弱,即使现在也有人持有这个看法,可是为什么Borland走到今天这个地步?而Microsoft却如日中天?若干年前,这两个公司竞争何等激烈,而现在却是另一番“合作”的景象?可能很多人想过,如果Borland不存在,对Microsoft不是更有力吗?其实Microsoft可能精通中国历史,读过《三国》、十分了解战国时期的中国,其实Borland形式上的存在,对Microsoft是十分有利的,至少形式上还有竞争对手,而事实上Borland已经受控于Microsoft(Microsoft是Borland的大股东)。你可以看到一些微妙的现象:Borland为Microsoft提供了大量的人才,其中包括Delphi总设计师以及Borland  C++编译器的核心成员;同时也为Microsoft  .NET提供强有力的护航服务(看看C#  Builder、Delphi  .NET)。1998年Microsoft  的COM技术基本已经成熟,这个技术使人感到震撼,当时Microsoft的对手们提出“OpenDoc”用于对抗“COM”,你看看“OpenDoc”阵营的几个成员:IBM、Apple、Borland、Novell,你会感到这个阵营十分豪华、强大。但结果却差强人意,“OpenDoc”无疾而终,而“COM”依然生机勃勃。 
    有人说“COM”没落了,那么就太不了解Microsoft了。在与“OpenDoc”的竞争中,“COM”是个彻底的胜利者,在与“Java”的竞争中,“COM”成功的进化了,在这个过程中Microsoft体现了强大的吸收能力、以及无法想象的韧劲。.NET只不过是COM的“别名”而已。对于一个经验丰富的C++程序员而言,.NET就是COM的进化,而Microsoft内部.NET就是“COM  3.0”(OLE2就是COM  2.0),而“CLR”就是一个不择不扣的COM对象。曾经有人问我,既然牛顿时代就奠定了基础(想想著名的牛顿-莱布尼茨公式),几百年后的今天,数学还研究“微积分”吗?回答当然是依然在研究!“微积分”早期是针对函数的,现代“微积分”是针对“流形(Manifold)、纤维丛(Fiber  Bundle)”的,概念深奥了,可是基本思想不变,只是“微积分”的思想得到合理的延拓与进化,你了解Microsoft吗?Microsoft  Research有一批超一流的数学家在为Microsoft工作,其中一些是斐尔兹奖的得主,Microsoft正在实现如同“微积分”进化到“微分流形”一样将“COM”进化到“.NET”。从科学概念角度上分析COM与Java,可能COM更全面、精确,从实现的成熟度上Java可能更成熟,可是你看到,Microsoft正在不紧不慢的追赶。Microsoft令人联想起战国时期的强秦。   
战国时期的秦国,采取“远交近攻”“抚弱掠强”等措施傲视六国,今天的Microsoft也是这样,VB1.0时,Microsoft推出“VBX”控件技术,众多的小公司得以生存,Microsoft自己不开发“VBX”组件,同样“VBX”进化为“OCX”时,Microsoft并不十分强大,可是这种试探得到众多小公司的响应。1997年Microsoft  Office  97、1998年Microsoft推出Visual  Studio  6.0,给众多中、小公司提供了生存、发展的机会,例如Microsoft  Office  97中集成了Visual  Basic  for  Application  5.0,这项技术使得几百家软件开发商与Microsoft签署了VBA技术许可协议,即使AutoDesk这样的公司都与Microsoft签署了这个协议,这个协议使得每个集成VBA的产品的给个用户许可为Microsoft付40$的许可费,如果你了解VSIP(Visual  Studio  Integration  Protocol)协议,以及有多少公司签订了VSIP协议,你就真正感觉到Microsoft的可怕;Microsoft  Office  97、Visual  Studio  6.0的用户界面十分漂亮,为什么Microsoft自己的开发工具不提供类似的软件组件?你看到众多第三方的Microsoft盟友纷纷推出自己的界面库以模仿Microsoft,他们不会反对Microsoft,因为他们已经形成了使得Microsoft以及这些公司得以生存的生态圈。 
    Microsoft的技术储备有多少,Microsoft之外的人很难说清楚,Microsoft中国公司也未必了解多少,1999年WTL类库刚刚出现的时候,人们就希望WTL能得到官方的支持,或授权给一个Microsoft之外的一个公司(你能想象出Borland  C++  5.0内置的ActiveX开发机制是基于Microsoft  ATL类库吗?),直到今天,WTL依然如故,我们完全相信,如果Microsoft强力推广WTL,WTL完全可以流行,可是Microsoft不缺类似的技术,类似的类库还有BCL(Base  Control  Library,一个用于开发轻量级ActiveX控件的类库),Microsoft还有一个基于ATL的类库,这个类库用于开发ActiveX  Designer,ActiveX  Designer是绝大多数程序员不了解得一类对象,如果你熟悉Office开发,你知道Office  VBA  中有一类对象,即Form2,此外VB6.0  中的报表设计器(以及著名的Active  Reporter),都属于此类对象,用这个类库,你可以为VB6.0以及集成VBA的系统提供定制化的可视化设计机制等等,如今ActiveX  Designer已经演化为集成于Visual  Studio  .NET中的设计器。
 
 
 
向Microsoft学习 
       无论从什么角度评价Microsoft,我觉得Microsoft是值得我们学习的,如果说生活在这个时代有Microsoft存在是一场灾难,你就应该痛恨这个家伙,但你首先要向这个家伙学习!我无意为Microsoft歌功颂德,我只是想说出十几年我对Microsoft技术的感受。 
       Microsoft在研究式的开发中受益极大,如果你有兴趣,你可以访问http://research.microsoft.com/,虽然部分中国公司也有研究院,但与Microsoft相比,真有“米粒之珠,也放光华?”的感觉。2003年,我在北京的一个地方现场体验了Microsoft亚洲研究院的招聘会,我看到中国的精英们进入Microsoft的渴望,事实上,在中国大陆,Microsoft亚洲研究院的人力资源已经延伸到各著名高校的相关专业的核心层,我感到,Microsoft几乎不需要“求贤”,因为,只要Microsoft需要,精英们会“蜂拥而至”,每个人都有“可以理解”的理由而向往那个地方,如果为搞数学研究蜂拥到加州大学,我觉得可以理解,因为那里有数学土壤,出了成果国人也会感到自豪,因为“科学无国界”。技术是否有国界?不知道是否有定论?!想想DVD等技术专利给国内业界带来的灾难,不知道应不应该痛定思痛,在Microsoft校园招聘现场的气氛中,我似乎明白了为什么国人“原创技术”少得可怜。我读过几本Microsoft亚洲研究院的高手写的书,明显可以看出,Bill  gate  是他们的精神领袖以及他们对Microsoft的虔诚,国内的研究机构应当研究一下Microsoft的用人之道,Microsoft好像是三国里的人物,不知是刘备还是曹操,或者二者的混合物。我经常路过西格玛大厦,第一次西格玛大厦进入真有“朝圣”的感觉,也与Microsoft中国的几个层次的人打过交道,各中滋味实在一言难尽。 
       在Office大战中,国产软件的确在一些方面与Microsoft进行较量,其实给人的感觉很勉强,界面上的似是而非,或用户习惯方面的接近并不能解决根本的问题,一个好的软件开发人员必须是一个软件使用的高手,很难想象一个软件操作水平很拙劣的开发人员能开发出高水平的软件,我最早使用的软件之一就是Microsoft  Word,当时的版本是2.0,大概是1992年的事情,给我留下深刻印象的是集成于Word中的Word  Basic,后来,我接触到Excel  3.0,不出所料,Excel中集成的是Excel  Basic,后来使用的Access中自然内置Access  Basic  1.0,在这些软件集成捆绑成Office之前,我就感觉这些产品的构思十分了不起,很具有Microsoft的风格,因为你知道,即使是一个DOS,Microsoft都要提供一个内置的QBasic或GW  Basic。虽然关于Microsoft的产品评论很多,作为一个技术人员,我认为Microsoft的产品构思绝对是第一流的,从1994年早期的Office系列到1997年形成的Office  4.2,我认为,技术构思上均领先于我国2002年以后的Office产品,你听说过如下说法吗?“Dos  作为操作系统的时代,Windows是应用软件;Windows是操作系统时,Office成为Dos时代的Windows;那么如果按此规律,Office会不会替代Windows而成为操作系统?”,现在在开发领域Visual  Studio(  .NET)正在成为另一个Office,你注意到了吗?控制Visual  Studio(  .NET)集成开发环境的仍然是一个Basic语言引擎(Visual  Basic  .NET)。 
       与许多公司不同的是,在技术体系上,Microsoft几乎所有的产品是息息相关的,Windows、Office、Visual  Studio  .NET虽然各不相同,但公共的核心即将形成,我们已经看到,核心组件方面,Office与Visual  Studio  .NET日渐趋于一致,例如Microsoft正在将Office  2003的核心组件VBA  6.X逐步用新的Visual  Studio  Tools  for  Office替代,而我们依然在一些似是而非的现象上与Microsoft的产品比较差距,国家采购或政府采购支持的公司,不去钻研核心技术,只是急功近利的采用短期行为急于与Microsoft相争,不知是否有蚍蜉撼树的感觉,个人的体验是,先学习Microsoft,踏踏实实的学,了解Microsoft,深入的了解,然后再喊口号。
 
 
 
为什么用MFC?             
       经过若干年的竞争,Borland  的OWL几乎消失了,这个OWL是个非常漂亮的C++类库,在Borland  C++  3.1风光无限的年代,OWL真正的做到了独领风骚。然而,Borland  C++  4.0错过了进入32位程序的最佳时机,BC  4.0推出后不久,迎来了Win95,Borland仓促上阵,以一个小的“Pack”使得BC4可以编译基于Win4的程序,当时的Visual  C++是2.0版,支持Window16的版本为Visual  C++1.51,有意思的是Borland可以用同一个编译器同时支持Win16、Win32,而Microsoft却不得不为Win16、Win32提供不同的编译器。然而,非正式版本的Visual  C++  2.1与Visual  C++  2.2却悄悄地支持了Win95的最新特征,即Win95新提供的一组公共控件,在我的印象中,Borland对Win95新特征的支持不利使得MFC与OWL的距离极大的缩短了。稍后到来的Borland  C++  4.5没有改变这个状况,尽管Borland  C++  5.0同时支持OWL与MFC,可是败象已经显露,Borland  C++非常遗憾的只走到了5.5版。C++  Builder虽然形式上引入了Delphi的VCL库,可是许多C++程序员并不买账,因为许多以C++为乐的人更喜欢以编辑的模式进行编码。Visual  C++  4.0的出现,在C++这个战场上,Borland开始落败了。 
       MFC发展到今天,已经十多年了,尽管褒贬不一,但可以肯定,十几年的技术积累已经奠定了MFC的生存基础,即使Microsoft的长角发布,MFC也不能推出Windows的舞台,事实上,长角(Longhorn)之后的Visual  Studio  .NET仍将MFC作为一个重要的组成部分,在今年的Visual  Studio  .NET  2005中,MFC在C++中的位置依然如故。MFC的未来,应该不必担心,只要你深入考察.NET类库,你会发现,MFC的许多思想机制正悄然进入.NET,与此同时,Microsoft的第三方盟友十多年来已为MFC开发了大量的扩展库,如果Microsoft是船,第三方盟友就是载舟之水。许多人认为MFC不发展了,其实是一种错觉,Visual  C++  6的界面十分经典,特别是其中的Docking控制条机制,其实Visual  C++  6的IDE完全就是MFC写的,可是MFC类库中控制条相关的类功能很弱,为什么?你会看到许多与Microsoft友好的公司,他们很快的在MFC基础上实现了Visual  C++  6  的Docking机制,这就是Microsoft的高明之处,Microsoft很会给盟友提供机会,其一贯的做法就是在自己的商品化产品中预先提供一些有趣的特征,使得其他一些公司进行模仿以带动用户群体。Borland不具备这样的储备。MFC第三方市场的繁荣,得益于Microsoft的策略与明智。MFC可否跨平台?理论上完全可以,Microsoft不做,也是策略,但是有许多重要的产品Microsoft却默许MFC移植到其他平台,事实上,Microsoft的合作伙伴之一Mainsoft公司(Windows源码就是从这家公司流失的),几年来就是负责移植MFC程序移植到UINIX、Linux、AIX等操作系统之上。 
       新版的Visual  C++中MFC已经支持.NET开发了,MFC与ATL的协作更好了。根据我的经验,MFC、ATL与.NET库三者完全可以融合在一起综合应用到实际的开发工作中去,如果你是MFC行家,我希望ATL与.NET库能成为你的忠实的左右手。那么有没有同时支持MFC、ATL与.NET库的程序?当然有,Visual  Studio  .NET  IDE就是!而且Visual  Studio  .NET  IDE还支持用ATL与.NET库扩展的Addin。
 
 
 
认识Application对象 
       如果你熟悉Microsoft  Office,你应该进一步的剖析这个大型软件,Microsoft  Office中几乎每个程序都是可二次开发的,这一点得益于Microsoft  Office内置的二次开发机制,一个是基于COM机制的VBA模型,另一个是基于.NET框架的托管模型:Visual  Studio  Tools  for  Office。作为一名程序员,你应当在技术角度解析Office的技术结构。Microsoft的大多数软件的对象结构可以通过Visual  Studio提供的工具OLE/COM  Object  Viewer考察其类型库得到,通过引用类型库,你甚至可以得到描述对象信息的C++头文件。这样做真是好处多多。一个典型的Office通常都有一个Application对象(或其他一个与之相当的对象),这个对象相当于软件枢纽,在这里,我们不讨论Office,借此话题说说Application对象。大多数支持扩展(Addin、Plugin)的软件都存在类似的构造。通常,一个系统得Application对象或者是一个COM对象,或者是一个.NET对象,如果你的系统存在这类对象,你的系统就基本具备支持Addin、Plugin的机制了。一个理想的做法就是在一个MFC系统中,内置一个ATL对象或.NET对象,稍后我们给出方案如何做到这一点。设计Application对象的关键是如何规划这个对象的属性、方法、事件。如果你希望系统具备良好的扩展性,Application对象是十分关键的,这也是构架艺术的体现。所谓Addin(Plugin),是系统运行时根据需要加载的对象库,Addin(Plugin)之所以可以扩展系统,关键的因素就是系统加载Addin(Plugin)时,将Application对象传递给Addin(Plugin)库,设想一下,如果Application恰到好处的触发了系统事件,而Addin(Plugin)库如愿的解释了事件,一个Addin(Plugin)库的任务不就OK了吗!因此Application对象是系统设计的关键。 
       如果你精通ATL对象,在你的MFC系统中添加一个ATL对象,这个任务可以用VC  Wizard完成。你已经接受了一个事实,就是MFC程序中存在一个CXXXApp对象(CWinApp的派生类),现在你要做的是增加一个对应得ATL对象。这个对象可以在CXXXApp::InitInstance()中创建,如果ATL对象的类是CXXXAppObject,建议你在CXXXApp对象对象中增加一个成员变量,例如:CComObject  <CXXXAppObject  >*  m_pAppObj,然后可以入下初始化m_pAppObj: 
                                 m_pAppObj  =  new  CComObject  <CXXXAppObject  >; 
注意程序结束时在CXXXApp::ExitInstance()中释放m_pAppObj,语句如下: 
                                 delete  m_pAppObj; 
你可以将系统得关键属性设置成CXXXAppObject的属性,例如系统得标题、是否为多文档等等。系统希望外部调用的功能可以实现为CXXXAppObject的方法,这一点取决于你的需要。系统需要外部扩展的功能,表现为CXXXAppObject的事件,关键是在恰当的位置触发事件以及提供的事件参数。例如,你可以在CXXXApp::InitInstance()触发应用程序开始的事件OnStartUp,Plugin捕获事件后,可以进行特定的初始化(身份确认、初始信息查询等等); 
你可以在CXXXApp::ExitInstance()触发应用程序结束事件,Plugin捕获事件后,处理用户需要的系统退出工作。所有的设计取决于具体设计。 
       如何加载Plugin,是一个有趣的问题,如果Plugin实现为一个COM范畴(Category),可以运用COM技术枚举这个Category;可以将Plugin安装到一个特定目录,也可以通过注册表。Plugin的实现可以用COM技术、也可以用.NET框架。适当的机会我会提供例子……
 
 
 
一些感想
 
 
 
一时心血来潮,就发了这个帖子,很难说是有心,还是无意。几天前我在新浪网上看应氏杯围棋决赛,我觉得该赢了吧,作为一个围棋迷,我们等了十几年,等到了属于国人的应氏杯。记得7、8年前在还在大学工作的时候,有一次,一位同事兴致冲冲的走道我面前对我说:“嗨,昨天马XX赢了李昌镐!”,当时我在系办公室正在看报纸,那位仁兄见我头都没抬,非常不满的抢下报纸,对我吼道:“喂!马XX赢了李昌镐!!你听到没有!!!”,我对他说:“你大惊小怪个啥?!马XX输了李昌镐多少盘,你知道吗?”,马XX几乎一直在输给李昌镐,人们已经不奇怪了,偶尔赢一次,国人就把他捧得北都找不到了,李昌镐弱冠17的时候就傲视这个世界了,可至今面孔不变,几天前的农心杯,中日联军5个人,被他打个落花流水,李昌镐是公认的世界第一,以至于有的高手知道下一个对手如果是他,就会去订回程机票。这次应氏杯,国人竟然感谢崔哲瀚,何也?因为这个弱冠19的小子,挡住了他的大哥李昌镐才使得应氏杯有了悬念。当国人媒体在说韩国仅李昌镐一人厉害的时候,不知道是出何居心还是自欺欺人,李昌镐年方30,不知道要力压中、日多少年!面对这个名字,真有点麻木了,这个太极虎!软件界又来了我们一向不齿的印度虎,2001年我们的软件出口额仅是印度的四十分之一,我们震惊了,怎么可能呢?这个四十分之一水分很大,很可能更可怜!当时我在大连参加一个关于“大连软件出口国内第一”的官方会议,那位大人在会上说:“据说,我们大连软件出口国内排名第一,市有关领导希望今天的会议给出这个第一的数字依据,希望你们把数据报上来,去年的数据也可申报,注意,我们要的只是数据,你们仔细体会,我们根据数据,有奖励,机会难得呀!”……。某一天,几个朋友在我家看央视的对话节目,对话一方为国内的软件大鳄们(用友、阿尔派等公司的老总们),另一方为印度软件的一个代表团。当问及中、印软件差距的时候,我们的刘老总(代表阿尔派)不以为然的说,据他的看法,我们已经快赶上(印度)了,……,言下之意颇有印度的水平不过如此的感觉,印度方的话我至今记忆犹新:“是否赶上,国际市场说的算!在中国看来,印度程序员的个性不足,技术也不怎么样,其实是个错觉,印度软件首先注重个性,许多重要的美国商品化软件都是在印度本土开发的……”,我们的舆论总是将印度程序员的水平描述的平庸至极,可是差距日渐拉开,……,围棋、足球(不好意思谈,谈不出口!)、软件,我们被近邻严酷的封锁了,乐坏了记者们、给媒体带来了生机…… 
       日本江户时代的围棋,如果一个人要想世袭一个称号(例如:本因坊),他必须战胜所有的师兄弟,然后,住进师父家的内室,你知道以后的事情吗?以后,这个棋手,就得为师父一家做饭、带孩子、搞卫生……,其余的门人则一心一意的下棋,这样的人、方式,造就了一代一代的本因坊,他们的棋谱大多数都流芳至今,这就是早期日本围棋的悟道模式。软件总共有多少语句?我最早接触的计算机软件教材是一本英文版的(影印的D版),不同于我们,那本书的作者构造了“X-语言”,他们不讲什么C、Pascal、Basic,一旦缺了什么机制,就给“X-语言”添加些成分。什么C、Pascal、Basic,你感觉差不多,但现在却分出了等级!我们驾驭语言的能力弱得很,可是我们在语言的细微之处却很讲究,不知道对不对,许多程序员也许是出于虚荣而用C++,事实上,地球人都知道,做数据库,Delphi、VB远比C++胜任,铺天盖地的C++的书,写的东西几乎雷同,因为,有用的或者作者不写、或者作者不懂。有时我在想,如果国内没有内需,会怎样?也许软件内需的存在,造就了中国软件的特色,我认为国内业界并没有充分利用中国软件内需的存在,也许中国软件内需的存在是软件落后的硬伤。 
       我记得一部电影《神辫》,那个英雄的大辫子被洋人炸掉了,最终他成了神枪手,战胜洋人用大刀、秘籍是不行的,用洋的东西战胜洋的技术才是正道。我觉得,一个好的程序员必须了解软件的历史,学习历史,你知道你为什么弱,别人是如何强大的。我们正在另一个战场上抗美(可笑的是我们却要赶超印度!),无论Microsoft、Borland如何争斗,无论他们谁统治谁,他们不影响美国的强大,朋友们,学习Microsoft,开发出让国人感到牛的软件! 
       这个帖子出乎本人的意料,愿意与大家共勉,希望这个帖子常在,与大家敞开心扉的交流!
 
 
 
FireFox与Microsoft 
       FireFox在一片赞扬、欢呼声中激情登场了,也许人们真的期待已久,平静的水面终于被扔进一块石头。我是IE的最早期的用户了,1996年首次Microsoft的TED(技术教育大会),IE4还没有发布时候,我们有机会目睹了内部版本的IE4(当时内部名称是:纳什维尔,英文名称忘记了),那真是一次令人激动的预览,当时IE3与Navigator  3激战正酣。当你第一次看到想象中的“Active  Desktop”,如果你没有身临其境,你不会激动。IE4本质上是一个Shell,其SDK是免费的,Navigator是基于Mozilla的浏览器,虽然是开源的,由于要照顾更大的共性(与操作系统无关),因此Mozilla不能充分的利用Windows的优势,Mozilla不能为广大的程序员带来所谓开发人员的“快感”,顶尖程序员可以驾驭Mozilla,以实现技术深度带来的乐趣,最早的Navigator同时提供17个版本(注意:不是17种自然语言,而是17种操作系统),从数学角度分析,Mozilla就像一组公理,你可以以此为基础开发不同操作系统上的浏览器,Navigator就是基于Mozilla的一个漂亮的结果,你能欣赏到代码结构的优美,然而失去的却是功能强大的个性(要知道,Windows用户在数量上远大于其他操作系统用户的总和)。普通用户不可能读懂Mozilla的代码,即使懂了也不能很好的运用,这也许是Mozilla(以及大多数开源代码)失败的致命原因之一。IE内核聪明的抓住了开发者,你想想:对数以万计的中、初级开发者而言,容易驾驭是首选的选择,也是明智的。我读过Mozilla,但我不会在开发过程中为一个具体的项目应用它。只要是浏览器,就不可能绝对的安全,无论是Mozilla,还是IE。当我了解到FireFox是基于Mozilla的一个新的浏览器,我基本上对其失去了信心,我有一个奇怪的观点:FireFox的推出,最大的受益者绝对是Microsoft,即使Microsoft失去20%的份额,但是会导致Microsoft强化IE,Microsoft正不知道如何促使IE进化的时候,FireFox的出现无疑为Microsoft提供了机会,物种进化的原则就是竞争,FireFox就是促进IE进一步强大的催化剂。FireFox的扩展机制的确十分灵活,如果对手不是Microsoft,就很难掀起波澜,而且当高级的开发者逐渐了解FireFox的时候,FireFox的漏洞就会渐渐暴露,试想想,如果某种Linux取代了Windows,那么,它的漏洞也会与Windows一样多,因为那个时候,会有与研究Windows漏洞一样多的人去研究对应得Linux的漏洞!从个人的角度上看,Microsoft也许有点“冤”,因为窥视Microsoft弱点的人实在太多了。从理论上看,计算机安全性是个永远的话题,就像任何社会都需要警察一样,没有了小偷、贼、犯罪,警察也就消失了,你想想,文明是什么?野蛮能消失吗?野蛮消失了,文明也就不存在了,高度文明就是更不存在了。人类克服了癌症,下一个疾病会比癌症更致命,但这并不意味着不必克服了癌症,进步真是一种挑战…… 
       IE的技术构思肯定是个卓越的构思,IE可扩展的机制,会给Windows开发者带来许许多多的益处。我正在计划一片文章,介绍如何将你的对象模型与MSHTML库实现对接,这样,在HTML文件中可以将你的指令系统与HTML对象模型融合在一起。 
 
 
 
话说“Hook” 
       在CSDN上时常看到关于“hook”,的问题,令我想起另一个话题,那就是游戏“外挂”。Hook提供一种改变一个Windows窗口消息处理的一种手段,通常的开发根本用不到,因此,谈不上“常用”,早期的Windows,由于不能很好的支持远东(当然包含汉字)地区的文字,因此出现了许多外挂的软件补充Windows的不足,中文之星是一个典型的、令国人自豪的软件,监控软件也许要运用hook技术,此外,很难想象什么软件会用到hook。有人问我,能不能改变一个进程的数据处理行为,我曾经告诉他:能,也不能!感觉告诉我,hook绝大多数场合下是一种“不礼貌”的行为。曾有一段时间,我的服务器,经常有人悄悄地近来,给我增加许多超级用户,肆意修改我的管理权限,我找到托管商,解决了这个问题,那时,我也买了几本服务器监听、安全方面的书,看了几天,我就放弃了,为什么?担心学坏(正、邪仅在一念之差),其实,每个服务器都很脆弱,对有经验的系统程序员而言,安全性与道德准则是联系在一起的,软件技术上走邪路很容易,有时我会想,如果我去设计病毒或者当黑客,会怎样?基础数学出身的我,数论、组合学、密码理论统统不是问题,Windows虚拟驱动程序开发,也不是问题!为什么那么多的人关心hook?国人的正道软件寥寥无几,可破解术却出神入化,可惜,可惜!hook是一种底层的编成机制,能理解好hook的人,完全具备掌握一流技术的底蕴,真希望回头…… 
 
 
 
MFC的批判 
       记得梁羽生先生笔下有一位正邪兼修的高手,名曰“乔北溟”(好像是这个名字),一次此人与大侠张丹枫在一个庙中相遇,乔北溟随手操起香案上的香炉,张丹枫问他:“你的家伙称手吗?”  ,乔北溟笑答:“以吾辈之见识,还在意手中之物是否为剑?”,张丹枫一愣,心中暗念,此人果然不同凡响…… 
       说起MFC,许多人都会撇撇嘴,高手们会对其提出许多尖锐的批评,例如,刻板的Document-View机制,繁复的框架结构,怪异的COM实现以及令人莫名其妙的宏,等等。MFC的大而全,不仅捆住了MFC开发组的手脚,也为全面掌握MFC的愿望设置了障碍。高手们批评之余,可能忽略了一个基本的事实,这个事实就是,你的批评来自于你对MFC的深入理解,当许多人指出MFC的种种弱点时,他们或许不愿意承认:他们的技高一筹、见识超人一等是MFC带来的,不止一次有人与我谈及:“MFC的COM实现,实在差劲,看看ATL(不容否认,ATL至今仍然是开发COM的最佳C++类库),你就会感觉MFC的臃肿……”,我们中的许多人潜意识里不知不觉的在作一件事:“当我们借助一部梯子登上一层楼的时候,我们会评价这个梯子是如何如何之糟糕。”1999年,我的一个项目中需要一个描述引擎,VBS(Visual  Basic  Script),是个免费的语言引擎,但功能局限极大,我联系了美国的Summit公司,他们很快寄来了Microsoft的Visual  Basic  for  Application  SDK  6.0,当时我的团队可谓很强,其中的几位研究生C++修养很好,拿到VBA  SDK时,他们对我说:“应当没问题,我们很快就会搞定VBA  SDK”,可是几天过去了,连个例子都没出来,原来,虽然VBA  SDK提供了MFC扩展类库(基于模版机制的MFC/ATL合成类库),可实现得极其别扭,我接手后的当天晚上,VBA  的IDE就集成到系统中,第二天可编程对象顺利出现在VBA  的IDE中,其余人觉得很奇怪,一看代码,原来我绕过Microsoft的例子,完全是另外的实现途径,那个时候,我感觉到,Microsoft这个家伙真的可恶,本来清晰的集成途径,却人为的让你绕来绕去增加技术难度,过后想想,也可以理解,不这样,第三方的Summit何以作技术支持?我经常想,如果没有商业利益,许多技术应当十分简洁、高效,这一点,Microsoft以及其他大公司都十分明白,如果一切都是最佳的实现模式,可能就另外一种局面了,复变函数论中有一个著名的定理:“复平面上处处解析的函数一定是常值函数。”,  学生们很难理解,当时我说,如果把一个省几十个县的最好学生组成一个班会怎样?结果是一定有一个较差的学生(除非这个班只有一个学生!),这是个无法抗拒的定则,你想想,用天下最好的20个菜形成的酒席是什么味道?那一定是最差的! 
       Microsoft的MFC是值得你学习和使用的,如果你讨厌这个东西或者你认为这是个邪恶的东西,你学学乔北溟,实现正邪归一…… 
 
 
 
有感于“鸡兔同笼” 
       小女初到北京时,对北京的教育颇为不适,铺天盖地的数学奥赛培训班向她压过来,孩子真是辛苦。她四年级时,就的对初等数论的基本内容进行强迫性的熟悉,还好,经过一段时间的努力,掌握了“鸡兔同笼”、“韩信点兵”等中国经典,马马虎虎的能证明费马小定理,有一天,她问我:“爸爸,大学数学什么样?还有‘鸡兔同笼’吗?”,我说,有,我特意找了本老外写的《Basic  Algebra》,找到其中的“中国剩余定理”,小孩子接着问道:“这本书中还有中国人的数学内容吗?”,我在习题中给她找到华罗庚老先生的“反同构定理”,小孩子又接着问:“还有吗?”,我感到很没面子,因为真的找不到了…… 
       曾经的一个梦,就是当一个数学家!为此,研究生时期买了大量的数学书,当时我们系的资料室是联合国教科文组织的藏书室,可以说,里面就是一个装满武功秘籍的宝库。有一天我们打扫资料室的一个仓库,仓库里全是鼓鼓囊囊的麻袋包,上面落满灰尘,手触摸一下,能粘出几毫米厚的灰尘,可以想象有几年没有打扫了。同学无意中揭开一个麻袋,我们惊呆了,里面是美国60年代各大学的数学杂志,每个杂志的名字都是响当当的,那真叫浩如烟海!当时我们就想,我们的论文能发表到其中吗?如果侥幸发了几篇,可想而知,我们就可以当博导了,这些比国内所谓核心期刊有分量得多的杂志,就像CSDN上的帖子一样,很快就会被淹没了,也许很久都不会有人参考、访问……,有一天,我也当了老师,面临着种种考核,于是,我们就成了论文机器,不论是否有价值,只要是核心的,你就高人一等。那个时候,我经常想起那些麻袋里的文献…… 
       我们整体水平的落后,导致整体的浮躁,数量上上去了,质量却下来了。若干年后,也许我成熟了,我们这些曾经站在大学讲坛上的人,没什么好的东西讲(谈不上  ‘教’)给年轻的学生,记得当年我校的计算中心计划招个培训班,几天过去,仅有7人报名,第8人来时,前7人就退了3人,主任感到奇怪,问学生,学生不语,其中原委并不复杂。我发此帖并没有精心策划,的确如某些网友所言是随感而发,“鸡兔同笼”、“勾股定理”已经有了历史地位,如果仅仅够用,我们住草房子一样保暖,为何建大厦呢?为什么放弃传统的长袍、马褂而去穿西装革履?病毒软件大战几乎是自杀性的内战,没有撼动国外产品的分毫,我们许多人喜欢对自己人说三道四,是不是很少想一致对外?人家卖我们打折的产品,条件是附加一份“忏悔书”,而执行者却是我们国人,为什么?因为我们的东西匮乏!当年别人用钢铁武器掠夺了我们的财富,他们强大了,地痞无赖换上了绅士面孔,讲起了法律,当你用D版时,人家文明的指责你,你的人力、财力、物力统统为人所用,取之于你用之于你,而我们却依然陶醉在“鸡兔同笼”、“勾股定理”的历史成就之中,我们依然喜欢争论“勾股定理”谁发现得更早,π是谁最先精确计算的,就像谈论C++谁的水平更高一样。
想起西太后……
    据说,西太后垂帘时期,洋人曾送给她一量火车,慈禧看过后,大骇,以为妖魔……。火车进入中国,最初可能也是引起争议的,大多数百姓都对此怀有惧怕的心理,时间长了,也就自然而然的接受了。
    想想Windows,最早也就是1983-1984年间出生的,到现在充其量也就20几岁,Linux大概比Windows小十岁。Windows来自一个贵族家庭,家长是Microsoft;Linux来自一个单身“母亲”,成长环境是一个社会,正可谓一个是贵族娇儿、一个是山野村夫。在洋人的世界里,Windows与Linux正如火如荼的争斗着,就跟人类历史上贵族与平民之间的争斗一样。我们很看不惯许多贵族娇儿,往往拿平民子弟的良好习惯与之比较,这一点都不奇怪。然而,我们平民阶层却有培养贵族的愿望,Linux社会也是如此,Linux社会已经分化出许多贵族了,为了各自的利益,面和心不和的联盟不知结了多少回,历史告诉我们,如果Windows死了而且如果Linux社会繁荣了,Linux社会就会出现一个贵族来接替Windows(叫不叫Windows无所谓,改朝换代吗)。某次,与国内一著名软件研究所的几个朋友一起进餐,谈到了Linux,话题自然很多,话题之一就是中国的Linux,朋友们笑曰:“……,自主知识产权的操作系统,也就是对开源代码内核的汉化,……”。人们可以列举许多关于Linux的强大之处,比如著名的电影《泰坦尼克》的特技制作,高性能计算Linux操作系统占据绝对主动等等……,其实对了解Linux的人而言,这一点并不奇怪:为某一特定的任务定制的Linux很容易剔除许多不必要的服务,这就好比轻装上阵,事实上,如果可以将许许多多的不必要的“虚拟”服务卸掉,Windows的性能并不差(Windows要加载许多虚拟服务),其实,即使Linux专家也承认,如果Windows允许向Linux一样可以按要求订制,许多弱点也许就不存在了,但市场也就是另一回事了。
    回到我们国人的立场,本人以为,没必要太多的对比Windows、Linux,如果我们Linux领域很强或者我们创造了Linux(毕竟这些都是洋玩意儿),倒也罢了,事实上,我们在Linux领域也不比Windows领域光彩多少,我们的许多人愿意用Linux说话,可是我们在Linux上拿出让我们立足的工作了吗?看看Linux社区就知道了!我们为什么不能把Windows、Linux都当作进入中国的两种新型火车而客观对待呢?在外交礼仪、航海公约以及种种标准等方面,我们已经潜移默化的接受了,为什么?因为我们弱势。Linux也是别人的,与Windows没什么区别。我们真正应该做的,是接受并使自己强大,许多网友给我回信,认为我的观点偏激或奉Microsoft为神,其实不对!只有认识一个强大的令你敬佩的敌人,你才有激情去强大自己。谈论Microsoft越多,其实客观上是对其承认越深,如果Microsoft不够强,就没必要拿它说话或对比,Microsoft给世界带来太多的负担,任何一个操作系统想战胜它,前提是必须兼容它给这个世界已经带来的积累,因此Microsoft很可能是无疾而终,铁木真的王国,是巨大无比的(据说他要讨伐一个对象,路上要在他的疆土内走上一年的时间),可并没有谁灭了这个王国,是自己灭的。我们认为铁木真是中国历史上的人物,可是有些国家认为是他们历史上的人物。其实只要客观对待Windows、Linux,能够正确定位他们的应用环节,Windows、Linux就都是好的东西!
    我们应当更多的看到,IBM、Microsoft等的崛起,是公司行为,这些公司为美国创造的不仅仅是辉煌,而是国力!我们的软件,依赖国家行为的投资(我们的软件研究所拿出什么来了?),靠国家的资助,却抱怨别人在垄断,多可笑!我们应当搞清楚我们在食物链中的层次,然后再指责别人。你不强大,你就受人欺负,拳头是硬道理。看看我们的北大青鸟,如果你看了他们的组件工厂的论述,你会觉得这是世界上最好的东西,可是你看到市场上北大青鸟在干嘛?我们有太多的自欺欺人的东西,有太多的世界领先、国内首创的鉴定,可是回头来,我们不得不清醒了……
 
 
后记:
 
为感谢CSDN网友的支持,本人拟定陆续增加几个新的帖子: 
一、十年MFC经历认识的Microsoft开发技术-多文档界面开发技术:此贴讨论一类多文档界面,主窗口是一个单文档界面,如果你愿意,你可以将多文档窗口作为主窗口的一个视图(CView)显示,这类多文档界面支持无限多个文档类型(即可以加载任意多个文档模板),支持(基于COM、.NET)二次开发技术以及VBA集成; 
二、十年MFC经历认识的Microsoft开发技术-可视化文档界面设计技术:此贴讨论MFC  Document/View  机制的可视化实现,将给出一种所见即所得的Document/View  设计机制;其中包含如何集成ActiveX  Ctrl、.NET  User  Control、MFC  CView类对象以形成一个MFC窗体; 
三、在MFC程序中如何有效的使用HTML、flash,例如,可以实现flash动画作为一个程序的Splash以增强程序的感染力,使用HTML、flash动画作为MDI程序的MDI用户区的背景等等……; 
四、十年MFC经历认识的Microsoft开发技术-MFC  .NET组件开发技术:介绍如何使用MFC类库开发.NET组件,例如可以用MFC开发WinForm对象,然后用于VB.NET、C#等等。 
 
如果大家有好的建议,请与我联系(sunhui@mail.apptemplate.com、sunhuizlz@yeah.net),如果有北京的朋友肯帮忙协助,在下不胜感激,希望得到大家的支持!
 

让Win32程序员更轻松的10个Perl模块

Windows特有Perl 模块的Perl档案库网络(CPAN)内容能够让很多人觉得满意。Windows用户喜欢它,因为它允许用户在Windows开发环境下高效而快速地开展相当复杂的工作。开源程序员喜欢它,因为相对于其他操作系统,Perl具有超强的兼容性。简言之,人人都喜欢。

 

这就是不管你站在那边,都有理由阅读它的原因。在文档中,我编制Perl模块目录,以便于在Win32 Perl编程中快速查阅。(见表A)如果你是个希望操纵Windows世界的Perl程序员,则应该将它们添加到工具箱中。

注意:可以直接从网络上安装CPAN模块。

 

 

表A

 





































包名

描述

Win32API::Registry

这个模块提供与Windows注册相关的Win32 API调用接口,允许读写注册值,创建删除注册键值、查询键值和从磁盘加载注册信息。

 

在需要读写Windows注册信息时使用此模块。

Win32::OLE

此模块允许通过使用OLE(对象连接和嵌入)的Perl脚本控制Win32应用程序。OLE对象参考与目标OLE类相关,并且可以通过Perl访问OLE类的方法。

 

在需要适应的OLE应用程序的界面时,例如Microsoft Office,使用此模块。

Win32::Internet

此模块提供访问WININET.DLL中库函数功能,在Windows中管理HTTP和FTP连接尤其实用。

 

当Perl程序需要与网络连接、URLs和FTP,HTTP发生作用时使用此模块。

Win32::Process::Info

此模块使得访问Windows进程信息变得容易。它提供了找回进程和子进程标记部分和获得详细进程信息的函数,注意它不允许杀死已有的进程。

 

在需要找回或监视当前进程表的时候使用此模块

Win32::Clipboard

此模块提供了Windows剪切板的优美接口。允许读剪切板中的内容,向剪切板上添加新信息或“等待”操作。

 

当需要使用剪切板在Windows和Perl应用程序之间转换数据或者显示当前剪切板内容时,使用此模块。

Win32::Service

此模块提供了与Windows服务管理器相互作用的函数,可以开始或停止Windows服务。

 

当需要开始或停止Windows服务时(例如,安装程序),使用此模块。

Win32::FileOp

此模块为许多Windows特有的文件操作提供API,这些文件操作包括:向Recycle Bin中移动文件,与Recent Documents作用,编辑INI文件,打开和关闭对话框和使用ShellExecute方法执行默认文件操作。

 

当需要快速执行不同的Windows特有的操作时使用此模块。

Win32::Pipe

此模块允许向Win32Perl程序中添加已命名的pipes.

 

当需要在应用程序和Perl服务后台程序中建立客户机-服务器连接时,使用此模块。

Win32::DriveInfo

此模块可以获得驱动器、文件系统、已用磁盘空间和Windows驱动器字符的广泛信息

 

在需要与Windows文件系统相互作用:得到可用驱动器字符、计算可用和已用磁盘空间或显示驱动器属性时,使用此模块。

Log::Dispatch::Win32EventLog

此模块提供与Windows事件日志相互作用的API。它允许注册事件和应用程序,将它们与特有日志联系和向日志中添加新信息。

 

使用此模块记录错误信息和使用Windows事件跟踪




Modified At 2008-06-04 13:35:58

Assembly Manifest 通俗简易手册[转]

 
[现象]
对这个问题的研究是起源于这么一个现象:当你用VC++2005(或者其它.NET)写程序后,在自己的计算机上能毫无问题地运行,但是当把此exe文件拷贝到别人电脑上时,便不能运行了,大致的错误提示如下:应用程序配置不正确,请重新安装程序……或者是MSVCR80D.dll 没有找到什么的(我记得不是很清楚,不过大致是这样的)
 
 
[分析]
看到这样的提示,当然不会傻到重装咯。第一反应应该是什么配置有问题、或者是缺少了什么依赖的库文件;于是我就根据以前Windows缺少库文件的经验,把所有库文件(××.DLL)统统一股脑地复制到当前文件夹下来,满心欢喜以为可以运行了,以运行……@#¥@#%¥……还是挂了。
 
 
[探索]
于是开始网上搜索,我Google,我摆渡;渐渐我发现,这一切都和一个叫做***.manifest 类型的文件发生关系,那么到底什么是 .manifest 文件呢?他有什么用,以前为什么没有?
后来,经过艰苦努力,终于得知,原来这一切都是Windows 的Assembly Manifest搞的鬼。这个东东的作用就是为了解决 以前windows上的“Dll 地狱” 问题才产生的新的DLL管理解决方案。大家知道,Dll是动态加载共享库,同一个Dll可能被多个程序所使用,而所谓“Dll 地狱”就是当不通程序依赖的Dll相同,但版本不同时,由于系统不能分辨到底哪个是哪个,所以加载错了Dll版本,然后就挂了。于是盖茨就吸取了教训,搞了一个程序集清单的东东,每个程序都要有一个清单,这个清单存再和自己应用程序同名的.manifest文件中,里面列出其所需要的所有依赖,这儿所列出的依赖可不是简单地靠文件明来区分的,而是根据一种叫做“强文件名”的东西区分的,那么什么是强文件明呢?我们来看一下这个.manifest文件便知道了。
 
<?xml version=’1.0′ encoding=’UTF-8′ standalone=’yes’?>
<assembly xmlns=’urn:schemas-microsoft-com:asm.v1′ manifestVersion=’1.0′>
<dependency>
<dependentAssembly>
<assemblyIdentity type=’win32′ name=’Microsoft.VC80.CRT’ version=’8.0.50608.0′ processorArchitecture=’x86′ publicKeyToken=’1fc8b3b9a1e18e3b’ />
</dependentAssembly>
</dependency>
</assembly>
 
我们发现原来这是一个XML格式的文件,其中<dependency>这一部分指明了其依赖于一个名字叫做Microsoft.VC80.CRT的库。但是我们发现,<assemblyIdentity>属性里面还有其它的东东,分别是
type系统类型,version版本号,processorArchitecture平台环境,publicKeyToken公匙(一般用来标示一个公司)……把他们加在一起便成了“强文件名”了,有了这种“强文件名”,我们就可以根据其区分不同的版本、不同的平台……总之,有了这种强文件名,系统中可以有多个不同版本的相同的库共存而不会发生冲突。
 
 
[深入]
恩,那么现在,我们就来具体了解一下这一套机制。
首先是强弱文件名的问题。正如上面提到的那样,为了区分不同版本或不同厂商生成的相同的程序集,必须用一个Assembly Manifest程序清单来列出我这个程序集的强文件名--慢着,到这里你可能会问:刚才不是说Assembly Manifest程序清单是列出其所依赖的程序集的强文件名呢,怎么这里变成了当前文件的强文件明了呢?其实,Assembly Manifest程序清单有两部分功能,上面这个实例之所以标注了其所依赖的文件的强文件名是因为其是客户端的Assembly Manifest,在服务端有另外一个Manifest 来标注。
 
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″>
<noInheritable></noInheritable>
<assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” version=”8.0.50727.42″ processorArchitecture=”x86″ publicKeyToken=”1fc8b3b9a1e18e3b”></assemblyIdentity>
<file name=”msvcr80.dll” hash=”2a0d797a8c5eac76e54e98db9682e0938c614b45″ hashalg=”SHA1″><asmv2:hash xmlns:asmv2=”urn:schemas-microsoft-com:asm.v2″ xmlns:dsig=”http://www.w3.org/2000/09/xmldsig#”><dsig:Transforms><dsig:Transform Algorithm=”urn:schemas-microsoft-com:HashTransforms.Identity”></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″></dsig:DigestMethod><dsig:DigestValue>phRUExlAeZ8BwmlD8VlO5udAnRE=</dsig:DigestValue></asmv2:hash></file>
<file name=”msvcp80.dll” hash=”cc4ca55fb6aa6b7bb8577ab4b649ab77e42f8f91″ hashalg=”SHA1″><asmv2:hash xmlns:asmv2=”urn:schemas-microsoft-com:asm.v2″ xmlns:dsig=”http://www.w3.org/2000/09/xmldsig#”><dsig:Transforms><dsig:Transform Algorithm=”urn:schemas-microsoft-com:HashTransforms.Identity”></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″></dsig:DigestMethod><dsig:DigestValue>7AY1JqoUvK3u/6bYWbOagGgAFbc=</dsig:DigestValue></asmv2:hash></file>
<file name=”msvcm80.dll” hash=”55e8e87bbde00d1d96cc119ccd94e0c02c9a2768″ hashalg=”SHA1″><asmv2:hash xmlns:asmv2=”urn:schemas-microsoft-com:asm.v2″ xmlns:dsig=”http://www.w3.org/2000/09/xmldsig#”><dsig:Transforms><dsig:Transform Algorithm=”urn:schemas-microsoft-com:HashTransforms.Identity”></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″></dsig:DigestMethod><dsig:DigestValue>hWq8zazTsMeKVxWFBa6bnv4hEOw=</dsig:DigestValue></asmv2:hash></file>
</assembly>
这个便是从WINDOWS\WinSxS\Manifests目录下取出来的一个manifest文件,再这个文件夹下有一陀子这种XML格式的manifest文件,其是服务端的程序清单。WinSxs是windows XP以上版本提供的[blue]非托管并行缓存(side-by-side catche)[/blue]里面安装了各种版本的经过强文件名签名的系统库,而上面这个文件<assemblyIdentity>正是标注了系统中Microsoft.VC80.CRT的一个版本的强文件名签名,如果其和客户端。.manifest 清单里面<dependentAssembly>所列出的依赖项对上的话,就会被加载。刚才说的side-by-side 是指各种不同的版本并行运行。
上面这个服务端manifest文件中<file>标签具体指明了当前强文件名签名的到底是哪一个文件,其中还有这个文件的Hash签名,以确保文件的完整性。
 
好了,有了这一套机制,就可以非常非常安全地进行库文件关联了,但是、但是貌似还有一个一直困扰我们的问题:这套机制安全是安全了,但是却失去了以前良好的前后版本兼容性,即如果你的系统库发生了升级,那么服务端的版本号发生了变化,那岂不是所有服务端程序都不能使用了吗?其实,windows还使用一个policy的策略文件来确认映射关系。
 
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<!– Copyright ? 1981-2001 Microsoft Corporation –>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″>
<assemblyIdentity type=”win32-policy” name=”policy.8.0.Microsoft.VC80.CRT” version=”8.0.50727.42″ processorArchitecture=”x86″ publicKeyToken=”1fc8b3b9a1e18e3b”/>
<dependency>
<dependentAssembly>
<assemblyIdentity type=”win32″ name=”Microsoft.VC80.CRT” processorArchitecture=”x86″ publicKeyToken=”1fc8b3b9a1e18e3b”/>
<bindingRedirect oldVersion=”8.0.41204.256-8.0.50608.0″ newVersion=”8.0.50727.42″/>
</dependentAssembly>
</dependency>
</assembly>
 
这便是在WINDOWS\WinSxS\Policies目录下的一个Policy文件,其中<bindingRedirect>标签便指定了所有8.0.41204.256-8.0.50608.0变本的客户需求映射到8.0.50727.42这个我现在系统中安装的比较新的版本的库。当然我们也能对别的字段进行映射,这样便能很好解决系统升级带来的问题。
 
[应用]
经过以上的讲解,大家对整个依赖查找过程都有了一个整体的认识,那么在实际中问题就好解决了。
让我们回到实际问题中,我之前说了,把一个程序编译连接成可执行程序后,在别人的电脑上发现找不到其所依赖的库了,那么怎么办呢?聪明的你自然想到把其所依赖的库相应的版本拷贝到目标计算机上面,可是……当你在拼命寻找那个可执行文件的assembly manifests文件的时候,却突然发现找不到了,在执行目录下面明明只有一个exe文件嘛。是不是没有生成呢?显然不会,原来是资源连接器把那个assembly manifests文件连接到了可执行文件里面了;不信,你可以用你的vc++打开一个可执行文件看看,在其资源项里面就有一个叫做RT_MANIFEST的项目。这个里面就是二进制标示的manifests文件。那么根据这里面提供的要求,将相应版本的依赖文件(一般就是CRT运行库)拷贝到系统目录Windows\WinSxS\,记住一般会是连带着一个特殊命名的目录一起拷贝到那个文件夹下,比如CRT的运行库就是WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50608.0_x-ww_b7acac55有这样一个目录,其标注了此库的版本号以及签名等信息,以防止多个版本重名时不能复制到同一WinSxS目录下。
 
这样就搞定了么?如果是以前,那么一切都解决了,系统会在这个目录下面找到这个运行库,可是现在单单这样可不行,系统可是要找到这个运行库的assembly manifests文件,并且对比强文件名之后才能加载,所以所以千万别忘了把相应的manifests文件拷贝到\WinSxS\Manifests目录下面。
 
当然,这样在目标的系统文件夹下面打动干戈,自然有些过于暴动了,还好,Windows还为我们提供了一种私有查找方式。这种方式会在前面的位置找不到合适库的时候在本地文件夹下面找。所以你只要把之前的库以及那个manifests文件一起拷贝到你的应用程序的路径下面,就可以使用啦。
 
根据MSDN的说明,在本地查找并加载遵循一下规则:
 
在应用程序本地文件夹中查找名为 <assemblyName>.manifest 的清单文件。在此示例中,加载程序试图在 appl.exe 所在的文件夹中查找 Microsoft.VC80.CRT.manifest。如果找到该清单,加载程序将从应用程序文件夹中加载 CRT DLL。如果未找到 CRT DLL,加载将失败。
 
尝试在 appl.exe 本地文件夹中打开文件夹 <assemblyName>,如果存在此文件夹,则从中加载清单文件 <assemblyName>.manifest。如果找到该清单,加载程序将从 <assemblyName> 文件夹中加载 CRT DLL。如果未找到 CRT DLL,加载将失败。
最后,我想补充的一点是,在你的VC++安装目录下面的“Microsoft Visual Studio 8\VC\redist”目录下,有着所有的提供发布的已经配备相应.manifest的库文件。所以你想要发布一个程序最简单最安全的做法(不用担心用户电脑是否包含你所需要的库)就是把这个目录下面的相应的库的文件夹和你的可执行文件放在一起发布。
比如在X86平台下如果你的可执行文件用到了CRT库(废话么),那么就拷贝Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT这个文件夹到你的程序所在的目录,一起发布,就万事大吉啦!

RSS详解

(Really Simple Syndication)是一种描述和同步网站内容的格式,是目前使用最广泛的XML应用。

RSS是一种起源于网景的推技术,将订户订阅的内容传送给他们的通讯协同格式(Protocol)。RSS可以是以下三个解释的其中一个:
Really Simple Syndication
RDF (Resource Description Framework) Site Summary
Rich Site Summary
但其实这三个解释都是指同一种Syndication的技术。 RSS目前广泛用于网上新闻频道,blog和wiki,主要的版本有0.91, 1.0, 2.0。

Continue reading “RSS详解”