Lihui さんのプロフィール我的白日梦乐园フォトブログリスト ツール ヘルプ

Lei Lihui

好きなもの/好きなこと
大愚若智,自卖自夸。欢迎访问我做的网站:故乡民勤-共同努力网http://www.coeffort.com
我的专业blog:
http://www.leilife.cn

Possitive Attitude
12月25日

二十年间的失败软件和系统

  今天看到一篇文章,叫“回首前尘往事,七大没落软件排名”,里面写的是这十年来的七大没落软件,我想补充一下,将前二十年的胜利者和失败者也做一个总结,当然,里面说道的大部分名词,现在很多人可能都是闻所未闻的。

  DOS对C/PM

  结果:Bill Gates一旦从几位朋友那儿得到了DOS(磁盘操作系统)并转让给IBM后,Gary Kildall的C/PM(微机控制程序)就是小巫见大巫了。

  失败原因:Kildall一点不懂商业之道,当Digital Research最后研制出16位C/PM版本时,其收费竟然高到DOS的十倍。

  当时说法:“我们过去愿意使用C/PM,是因为有上万个现成程序可用。如果那时我们使用16位的C/PM,人民便会说‘程序究竟在哪儿呢?’” -kaypro创立者Andy Kay于1985。

  最后的话:不能打败对手,就加入对手。Kildall的Digital Research接着开发的DRDOS于1991年卖于Novell。

  Windows对OS/2

  结果:经过六年的修改增补,OS/2 2.1才得以问世,而期间Windows(即便也有某些缺陷)却已经成为了台式机的操作系统标准。

  失败原因:OS/2的失败归咎于它的显示管理程序,用OS/2的图形用户界面开发应用程序,简直是一场恶梦。

  当时说法:DOS操作系统在PC中领先的地位可以维持道1990年,OS/2会迅速成为新的领先者。

  最后的话:IBM并未认输,但在台式机上的争夺已经结束,Windows取得了胜利。

  ISA对Micro Channel

  结果:IBM曾在第一太PC的开发ISA体系结构创建一个怪物,并试图使之适应PS/2的专用总线,结果最后劳而无功。

  失败原因:IBM根深蒂固的独占傲慢态度是其微通道失败的原因,IBM曾试图阻止别人模仿它的微通道体系结构,而任何应用程序在此种体系结果上运行都比不上AT总线上快。

  当时说法:“如果有人指望IBM再引入IBM AT,那是可悲的误解。” - IBM高级官员于1988。

  最后的话:IBM于1993年否决了Micro Channel而未加声张。

  PC对Macintosh

  结果:Computer Intelligence InfoCorp估计,全球大于有5千万台PC,而Macintosh只有6百万台。

  失败原因:Apple公司曾经认为商人们宁愿为简便的界面而多付钱,但是具有讽刺意味的是,商人们虽需要简便,却不肯对花钱。

  当时说法:“不管实际数字将会怎样,趋势很明显,全美正以越来越大热情迎接Macintosh。”

  最后的话:没有Macintosh就没有备受敬重的图形专业业务,正如没有Betamax就没有视频的专业业务。

  附录:  七大没落软件排名

  没落软件排名第七 ICQ,输就输在软件单一的语言选择

  ICQ,作为IM软件领域的缔造者,不得不说它成就了一个辉煌。1996年7月成立的Mirabilis公司于同年11月推出了全世界第一款即时通讯软件ICQ(目前ICQ已经归AOL旗下所有),取意为"我在找你"--"I Seek You",简称ICQ。

  这款软件一经推出,即刻全球响应,贫借着前所未有的创意很快在全世界拥有了大批的用户,即使在当时互联网不太发达的亚洲,市场用户量也占到了70%,在国内更是占到了80%。但是到了现在,根据调查显示,国内如今的IM软件排名中ICQ只排到了第8位,差距竟如此之大。如此强大的反差,究竟是什么原因呢?

  一、同类软件的兴起

  ICQ一经上市,迅速取得了广阔的市场,由于前景一片光明,所以同类软件迅速的跟进。因为其本身的技术并不复杂,所以很快几乎每一个国家都推出本土的IM软件,抢夺了市场。

  以国内的腾讯QQ软件为例:腾讯QQ脱胎于腾讯OICQ,而OICQ就是国内最早出现的即时通信软件之一,软件最初的设计完全仿照ICQ,从内容、形式等方面完全照搬。出于国内首创,所以很快积累了大量的人气,用的人越来越多,最终占领了市场。

  二、ICQ版本语言单一

  在市场初期,ICQ并没有注意其他的国家的市场,所以在全球只推出了英文版。这就给其他各自本土的IM软件带来了机会,而国内OICQ的风行很大一部分原因都是由于ICQ没有中文版造成的。当时也没有汉化补丁,国内很多人苦于ICQ的英文界面,所以当OICQ一经上市,马上抛弃了ICQ。

  时至今日,ICQ也没有推出中文版,国内用户如果想要方便的使用,还必须安装一个中文补丁。

  还是单一的英文打完补丁

  三、ICQ自身的失误

  ICQ本身的发展走了冤枉路,随着版本的更新,ICQ太庞大了,庞大到太多的功能几乎没有用到过,这些集成的功能大多数时候看来都只是毫无内在联系的大杂烩。而对于普通用户,这些大而无当的功能除了增加使用难度之外,别无他用。尽管美国在线AOL的AIM和ICQ整合以后,注意到这一点,在过去的一段时间里做出了调整,没有再推出大肆的扩展功能,做出了一个功能精简版的ICQ Lite版,但为时已晚。

  如今的IM市场,形式大变,早已不是当年的模样。国内的市场上,腾讯QQ一人独占了半个市场,MSN抢夺剩下的1/4,紧剩的1/4,网易泡泡、朗玛UC、yahoo通等等还在拼个你死我活。虽然国外的市场上ICQ迄今为止还是占有了一定的份额,但微软处心积滤发布的MSN从XP版本开始,与操作系统进行了无缝的结合,社会的风气逐渐向微软倾斜,历史似乎再次重演。

  总评:虽说国内用户几乎绝迹,但在国外尚有一席之地,所以七大没落软件排名第七。

  没落软件排名第六 coolstreaming,命苦不能怨政府

  如果问两年前国内外最出名最有影响力的P2P流媒体播放软件是谁?则非Coolstreaming(中文译作酷流)莫属。Coolstreaming是在日本软银投资所的支持下,由北京酷流科技有限公司推出发行的P2P流媒体播放软件。

  当时的网上直播,面临着与常规下载同样的问题。如果使用人数达到一定的数量,数据就会中断,然后就是无穷的等待,或者画面静止、或者有音无画。网民们纷纷抱怨,什么时候才能让我们看到流畅的网络直播。

  这个时候Coolstreaming应运而生,基于P2P下载的理论,同时观看的人数越多,数据传送的速度就越快,画面也就越流畅,其下载的原理如同bt一样,况且它又是保存数据到内存,不会出现伤害硬盘的谣言,所以软件在几乎没做什么宣传的情况下一经上市就获得了满堂喝彩。网友在各大论坛争相转载,很快Coolstreaming就拥有了一大批的用户。

  然而好景不长,没多长时间Coolstreaming因为特殊的原因被禁一段时间。广大网民又无法流畅的观看比赛,正当苦恼的时候,同类软件PPLive及时出现,以其自身过硬的技术在很短的时间内全盘接受了Coolstreaming流失的用户,从而一跃成为网络第一P2P流媒体大户,声势一时无二。

  没办法,造化弄人,还不能怪别人,只怨自己命苦。

  尽管没过太长的时间Coolstreaming就再次恢复了运行,但已物是人非,市场上的同类软件除了PPLive之外,PPStream、VVSky、沸点、TVANTS等等将近10几款同类软件同时上市(在此不得不佩服国内的软件跟风的速度之快,一但发现哪类软件有市场,立码一哄而上)。用户的大量流失和同类软件的竞争,使得Coolstreaming在市场上已经没有太大的优势。

  反观PPLive和PPStream,作为目前P2P流媒体产业的领导者和后起之秀,在网络上各自积累了大批的人气和知名度,并且随着彼此规模的不断扩大,界面和功能也得到了不断的完善,其市场地位逐步走向稳定。

  Coolstreaming若想从新夺回P2P流媒体老大的位子,如果还想依靠简单的功能和那几个屈指可数的频道的话,无疑是痴人说梦。

  总评:市场丢失,时不再来,纵有财团支持,亦无可奈何,七大没落软件排名第六。

  没落软件排名第五 超级解霸,不思进取就意味着失败

  当小编我还在上学的时候,刚刚接触电脑,朋友教我怎么用电脑看电影,带我接触了超级解霸。

  至今我还记得朋友是这么说的:视频文件有好多中格式,以rm为后缀的,你装realplayer8.0就行;剩下的,你用超级解霸就行,比如说你看vcd就可以用它播放。其实当时我压根儿什么都没听懂,只是好面子,心虚的点了点头。可怜我当时连什么是文件都不明白,更别提播放软件了。不过那天我记住了一个名字--超级解霸。

  独特的安装界面以及嵌入在安装过程中的音乐,使人们在安装时都不觉的浪费时间,加上它华丽的界面、强大的播放及纠错功能,在当时的播放器市场上稳占半壁江山。但是不知道从什么时候起,人们卸载了它,而且没再用过它。

  为什么?

  一、软件设计的硬伤

  撇开功能不说,软件设计上超级解霸的播放界面和控制台是分开的,这给我们平常播放带来了及大的不便。而事实也证明了现在流行的播放软件几乎都是将控制台与播放界面整合在一起的。

  二、自身开发缓慢,市场定位不准

  2001年的时候,超级解霸与real 8.0几乎垄断了整个视频播放的市场。但在随后的几年中,超级解霸却放松了对产品的改进。当初超级解霸之所以流行,就是因为什么都能放,譬如一些盗版盘。但这几年下来,内容功能上没有什么更新,技术上也没有什么独到之处。在现如今播放器软件大都免费之际,竟然还是一款共享软件。谁还会去用它?它又有什么地方值得消费者花钱去购买。

  三、竞争伙伴的发展迅速,落后只能失败

  当年的市场上微软不甘心失败,终于在xp系统下,贫借捆绑的优势Media9.0以其完美的界面和格式支持重新杀回了播放器市场,而超级解霸的老对手realplayer在接下来的几年进步有目共睹,从real8到real9,再到realone以及现在的real10,从界面、功能、支持的插件组合来看,播放器“一哥”位置的确无可动摇。

  而在近两年里,一种新兴的视频DVDRIP格式悄然兴起,各种视频、音频解码器充斥了整个市场。这个时候一个开放源代码的播放器MPC应时而生,由于能够自由的加载各种解码器,这款播放器很快就在全世界流行开来,例如深受国人喜爱的暴风影音就属于此列。而在最近,由韩国人自主开发的一款播放器kmplayer也受到了大家的欢迎。

  四、流氓软件泛滥

  最让人不能忍受的是,小编在测试时安装了超级解霸英雄3000的最新版,随之而来的便是捆绑了这么多得流氓软件。

  这使我在失望之余,更感到出离的愤怒。所以超级解霸,让它永远消失在我们的生活之外吧。

  没落软件排名第四 南极星,南极星的天空终不再明亮

  win98的年代里,RPG的游戏风行,当时的很多游戏玩家应该记得这款软件南极星,出色的内码转换,简单的可操作性。很长一段时间它默默的支持着许从台湾发行过来的游戏,陪伴我们渡过了很长的时间。

  看看这副图,是不是又伤感又无耐。尽管它几乎什么都没有变化。但是现在,还记得它,还在用它的人少之又少。

  究竟是什么原因使的这款优秀的软件几乎已经离开了我们的记忆?

  我们先来看看它的说明:南极星全球通允许你查看并且输入中、日、韩文到任何桌面程序中,支持各种种32位版本的Windows(95/98/NT)和各种本地化版本的Windows(简体中文、繁体中文、日文、韩文),自动内码识别,可用各种输入方法(拼音、注音、双拼、仓颉等),自动按所查看文本的内码输入...

  看到这里,我们差不多明白是什么原因:

  首先,上面所述的功能大部分在如今的win xp系统上,利用系统自带的功能几乎都可以实现。

  其次,在竞争对手方面,当年的南极星在风行没多长时间之后,金山公司便发布了金山游侠,伴随着捆绑的金山内码转换器也抢夺了南极星不少的市场。

  最后,当年南极星的使用几乎都是伴随着台湾游戏的传播,如今台湾RPG游戏的没落以及大量汉化工作人员的辛苦工作、各种补丁的发放,我们已经不再需要这款软件。所以南极星真的象天空的星星一样,离我们越来越远。

  总评:功能废弃,市场失利,确实没有什么值得我们留恋的,七大没落软件排名第四。

  没落软件排名第三 蚂蚁NetAnts,蚂蚁搬家比不过车速

  蚂蚁软件估计在国人的心中印象最深,而且老资格的网民应该也都用过,因为它毕竟是国内的第一款专业多点下载工具。

  功能上蚂蚁利用了一切可以利用的技术手段,如多点连接、断点续传、计划下载等,使你在现有的条件下,大大地加快了下载的速度。而且这款软件的名字起的极其有创意:多点下载,蚂蚁搬家,生动形象的在用户脑海里刻画出一副下载的画面。而它多点下载功能确实达到了效果,速度提高了好几倍,所以很快国内下载蚂蚁一统江山。

  但是用了没多长时间网友们就发现,蚂蚁虽好,但是也有很大的缺陷。

  其一、没有很好的文件管理功能,下载下来的东西管理极其不方便。

  其二、同时下载多个文件时内存资源占用太多,那个时代的机器不比今天,所以开了下载之后网民几乎没有办法处理其他的事情。

  然而在当时,蚂蚁的开发团队却没有注意到这两个问题,所以很长的一段时间没有作出修改。你不注意,有人注意,观察到蚂蚁缺陷的就是后来大名鼎鼎的FlashGet。作为后起之秀FlashGet同样具有断点续传和多点连接的功能,但在下载的速度上更胜一筹,特别是在网络速度比较慢的时候能够显出比较大的优势,而且它操作简化,文件管理功能出色。

  所有的这些特性和功能,在当时给了蚂蚁致命的一击。蚂蚁的大批用户迅速流向了FlashGet,在当时几乎演变为一种潮流,挡都挡不住。蚂蚁这时候慌了,但大势已去,悔之晚已。而且确实在性能总体方面,当时的FlashGet居于同类软件中制作水平之首。

  虽然如今的软件下载市场也不再是FlashGet一人的天下,几年前突然崛起的影音传送带和现在如日当中的迅雷下载贫借着各自独到的技术和功能与FlashGet三分天下,但不管怎么分,都没有给NetAnts留下任何的机会。NetAnts在已经失去了它当初的地位和人气之后,如今也正一步步的走向没落。

  总评:功能缺陷,人气不在,不复当年之勇,七大没落软件排名第三。

  没落软件排名第二 Napster,被阉割的经济利益牺牲品

  可能国内很多的用户对这款软件并不熟悉,但是也应当听说过它的故事。现在每每人们讨论bt、电驴下载是否侵权,是否触犯了法律的同时,总会提及这款软件,因为它就是一个活生生的前例。

  Napster是一个软件,但更像一款搜索引擎,能够查找和下载MP3压缩音乐文件。它利用尖端技术克服了传统FTP传输中的问题,你可查找100多个服务器中当时最快的服务器,从而顺利下载MP3音乐文件。

  Napster的特点还在于它本身只提供MP3文件地址、目录和索引,所有的歌曲都实际保存在Napster用户个人电脑的硬盘上。所以,用户找到歌曲后是通过Napster为MP3发烧友提供的虚拟社区从他人的硬盘上下载音乐,这样就真正实现了每个Napster用户和其他使用Napster的人分享MP3音乐,而它所依赖的技术就是P2P下载。

  先进的技术和优秀的管理,使得Napster在市场上拥有大量的用户,然而正是因为大批的用户,给Napster带来盈利的同时也带来了灾难。

  1999年12月,包括华纳、BMG、百岱、索尼、环宇五大唱片公司在内的唱片公司起诉NapsterNapster侵犯著作权,他们指出,美国加利福尼亚州的雷德伍德城因特网公司开发出来的技术使得数以百万计的因特网用户可以自由地从Napster网站上下载免费的音乐文件,这是一种网上的侵犯著作权的行为。

  法庭随后判决Napster网站终止这种免费下载音乐文件的服务,在随后的几年里,围绕着这个案子反反复复。尽管Napster推出一种叫做“合法的Napster”的服务,尽管贝塔斯曼收购了Napster,并在经济上给予了支持,但是这款软件还是一蹶不振,逐渐的被人抛弃。

  不过正是因为Napster的事迹,网民们痛定思痛,才会有了bt下载技术的诞生。同时一大批准备取代Napster的软件面世,很快抢夺了Napster让出的市场,其中的佼佼者就是Morpheus。

  Morpheus和Napster有一个最大的区别,Napster需要一部中央服务器来储存用户的文件资料,因此当唱片公司告赢了Napster之后,Napster把服务器一关,大家就没办法通过它来交换音乐。而Morpheus不需要单独的服务器,所有的资料都存在用户自己的电脑上,所以唱片公司在随后的几年内对它无可奈何。

  现如今bt下载又面临着同样的问题,毕竟在最近的一段时间里,美国、香港因为bt下载而被判坐牢的已经不是一、两个人了。

  总结:法律制裁、强项不在,Napster的状态每况欲下,七大没落软件排名第二。

  没落软件排名第一 Netscape,成王败寇的商战经典案例

  2004年10月13日是Netscape-网景浏览器诞生10周年的日子。在这个特殊的纪念日里,Netscape只有一个几乎没有引起多少人关注的网上庆祝活动,胜者为王败者寇,这就是Netscape所面对的现实。自惨败给微软IE后,到现在几乎已经很少有人知道Netscape浏览器了,尽管Netscape曾经盛极一时,尽管Netscape现在还苟残延喘地活着。

  20世纪90年代中期,伴随着互联网热潮的兴起,Netscape公司的浏览器推出后,很快就以强大的功能、友好方便的用户界面获得了广大用户的好评,盛极一时。1995年Netscape公司的股票上市时,Netscape浏览器几乎拿下了整个浏览器市场,一统江湖,抢尽了风光。Netscape公司公然宣称,使用Netscape浏览器的用户会越来越多,Windows在操作系统领域的霸主地位会削弱,“最终变成一堆充满BUG(软件漏洞)的废品”。

  而当时总部设立在西雅图的微软公司,静悄悄地听着来自美国硅谷的喧嚣,默默地接受了Netscape公司的挑衅。后来的故事世人皆知:1998年6月25日,微软发布的新一代操作系统Windows 98,最终实现了与IE浏览器的完美融合,以免费这种无法抗拒的诱惑,挤垮了Netscape公司,最终这家自大的公司被美国在线-时代华纳并购。

  现在,随着Firefox、Safari、Opera等的悄然兴起,Netscape已经没落了,彻底地没落了。Netscape新版的发布,也是异常的低调,低调得甚至令人窒息,低调的让人绝望。从贵族到被遗忘,Netscape用了短短十年的时间。而一切,均源自于发生在Netscape与微软两家公司间的那场浏览器大战,成王败寇,竞争就是这么激烈。

  总评:面对策略的失败,遭遇市场的打击,Netscape毫无奋起的现象,七大没落软件排名第一。

本文链接地址:http://www.williamlong.info/archives/361.html

有力奔波,无心说话

这些天一直在忙房子的事,终于有了一个较为明了的结果了。
 
怕房子质量不好,怕房子地点太偏,怕JS爱上我。东奔西跑,想来算去,最后还是在一个小时之内决定了一套刚看到的房子。
 
“就这么定了”,我给卖方及自己以及老婆说。
 
于是乎,弄各种证明,四处借钱。那个开着大奔的卖主我总以为是一个精装修的骗子。
 
到目前为止,我突然发现我们的那个介绍房子给我们看的“朋友”才是最值得怀疑的对象,他总是留有一丝神秘感,总是在最后的关头给我一个"Supprise"。
 
等贷款下来就过户了,我想应该没什么问题了。毕竟房本是真的,那个卖方也还不错。
 
就等最后的消息了。。。
 
 
10月30日

北京香山二零零五年十月三十日全景图

呵呵,和小强,启盛一块去玩偶然用相机全拍的结果。下次一定会更好。
 
10月15日

为什么我想不到

每过几天,我就被一个想法所刺激,一个劲儿的说真是个好想法。但回头,我就问自己,为什么我想不到?
 
就说今天我碰到的两个网站吧,我觉得创意就非常棒,它们发展都到了如火如荼的时候,历经好多年了,而我今天才听说。
 
 一个是Shvoong-人类知识精华宝库,它的介绍里面这样说:

公元前47 年,希腊人民把著名的亚历山大大帝图书馆付诸火炬,那个时代所贮存著的人类思想果实,最重要的知识宝库, 永远地丢失了。七十万册被焚毁的书册当中包括《旧约圣经》希腊文译本,毕达哥拉斯的科学著作,诗人荷马,古希腊哲学家柏拉图,科学家亚里士多德的著作论述,以及其他古时代学者的重要作品, 都失而不复得了。 今天,用一根火柴烧毁全部书籍是不可能的了,人们再也不用担心因发生一宗不幸的意外而会丢掉整个宝贵的知识文化财产了。但是那种害怕被大火焚烧书籍的担心如今却被另一种不同的挫折感所代替-----那就是面对著有2052 年历史一直积累至今的文化知识,面对浩瀚的知识海洋,我们人类显得手足无措,有一种无能力驾驭的悲伤。我们的悲哀源于我们面对知识海洋, 没有能力没有时间去阅读所有那些许多人认为是重要的,而且又被研究过的,记载过的,出版发行过的知识。 换句话说,现代化的知识爆炸更加重了我们的无助感。

这样深入去探讨历史作为开场白不是没有道理的,这当然有其原因所在。Shvoong网站希望攀上一个历史性的顶峰,攀上一个“文化珠穆朗玛峰”。我们建议读者,把所有的人类文化精华摘要, 积累在本网站,不多也不少, 你们自己来写作, 来发表你读过的文章书籍摘要。 同时,我们希望给你一个写作为营生的机会。这与慈善事业, 利他主义无关。本网站经营者是想把它经营成一个盈利性的生意网站。

因此,Shvoong网站号召全世界的知识文人-----来吧, 加入我们的阅读行列,来享受阅读的乐趣。同时,----- 也来加入写作行列并以此赚钱谋生。我们欢迎所有的大学生, 高中生, 教授, 政府官员,办事员,律师,科学家, 家庭主妇,无论健康的还是卧病在床的人们, 所有的受时间和生活束缚的人们;全世界所有的公民, 被日常生活,工作压力困扰著的人们,那些不能随意支配业余时间的人们;那些需要相关知识信息又不得不自己收集的人们;在处理完工作,不得不从生活中挤出有限空闲时间的人们-----换言之,所有的人。 同时,我们网站也号召广告客户商的加入-----他们会对本网站没有流通限制的巨大网络空间留下深刻印象,告诉他们:来吧!

目前, 还没有任何现存工具能配合人们对摘要的需求。任何一个网络搜索引擎都可以把网上浏览者推向那波涛汹涌的,令人绝望窒息的,信息过度爆炸的互联网知识海洋里。 Shvoong网站存在的目的就是向那些快在知识海洋里溺死的人们抛下救生绳, 就是作为一种去芜存菁的工具,一种识别是“信号”还是“噪音”的用具。

Shvoong网站刊登的内容并不能替代原文。它的文摘,无论是任何书籍或研究成果,网站也不想将其伪装成原文的替代品。我们网站的目的是成为一粒浓缩的知识胶囊,为那些渴望知识但却没有时间阅读的人们吞服吸收。

关于Shvoong网站的文章内容。 我们的文摘不是由专家所写, 所有的文摘是由随意上网浏览的读者们主动用其母语写成组成的。为了鼓励网上读者们的写作, 本网站提供酬付费保证。我们知道不是所有的网上读者们都有写作天才的,其中一些人甚至会写一些无聊透顶的东西。如何评审, 过滤, 排名都将由网上的读者们自己完成。 这就是我们网站进化性的做法,成果均是由读者和作者共同合作创造,并没有来自任何编辑,校对人员和改写者的干预。

我们期望能招待来自全世界各地的, 使用任一语言(37种语言)的广大读者和作者。我们相信以我们的能力, 本网站会成为一个广大读者和作者们的精神家园和工作地点,为每人提供一个公平发展的机会,取之于人,用之于人。

 
另一个是 PayPal,维基百科这样说:

http://zh.wikipedia.org/wiki/PayPal) 

PayPal贝宝),是一个总部在美国加利福尼亚州圣荷西市的因特网服务商,允许在使用电子邮件来标识身份的用户之间转移资金,避免了传统的邮寄支票或者汇款的方法。PayPal也和一些电子商务网站合作,成为它们的货款支付方式之一;但是用这种支付方式转账时,PayPal收取一定数额的手续费。

PayPal于2000年起陆续扩充业务,包括于其他国家推出业务及加入美元以外的货币单位,计有英镑加元澳元日圆

2002年7月,全球最大拍卖网站eBay以15亿美元收购PayPal,PayPal便成为了eBay的主要付款途径之一。

2005年,Paypal的中文网站开通,中文名称是“贝宝”,但是Paypal和贝宝实际上是两个相互独立的账户。

8月26日

我去CA了

已经工作三周了,感觉还行。就是上班时候不能使用MSN,让我觉得有点郁闷。
 
这次的感觉是去了一个大公司,当然,路还得自己走。没什么说的了,就贴我一张比较傻气的照片来充数吧。
 
 
 
 
 
 
 
 
 
8月21日

不想去第二次的景点(我的坝上之行)

作者:Goooder(http://goooder.blogchina.com/)

题记:公元2005年8月13日,我和一帮同学共16人去位于河北省的坝上(某个小乡村)去游玩。为了纪念这次旅行,特写文字记录其中的感受。

狡猾的旅行团工作人员

早上6点多钟,经过几次的波折,旅游车终于出发了。一个矮个子旅行团工作人员清点出游人数,发现我们共有15人,与原先预定的18人少3人。于是吵着说要加旅行费,每人要多加20块才能去。组织活动的老师禁不住这个油嘴的人的游说,同意了他的要求。当我们大伙交完钱之后,突然发现我们随行的一个同学被拉在出发地。幸亏车走的不太远,最后车厢里面有16人了。多交的钱最终没有退回。

此处又节外生枝,钱刚交完,这个旅行团工作人员又说,这些钱中不含有个人意外伤害险。原先所说的保险只是旅行团的责任险,与旅游人员无关。大家需要自己重新买个人意外伤害险。他又强调(一本正经的面孔):这个保险只有5块钱,也可以不买。

大家于是恼了,对以前旅行团的说法表示怀疑。敦促这人给旅行团另一负责人打电话(第一次就是向此人联系的)。此人打电话时非常有技巧,先告诉那人:“这些去坝上的学生人数不够”,然后再问:“原先所说的钱中不含有个人意外伤害险吧?”。没想到大家清清楚楚的听到了电话中所说的“含有”的回答。

大家一阵欢呼。此人不再狡辩。

教训:想想此人的说话的次序,就知道他想法要让电话中的人承认他的意见。不过因为以前明确的谈过,所以逃过此难。其他的就让大家自己去想吧。

骑马

经过漫长的路途(中间有好几个小时的堵车等待),在下午4点多钟我们到达了目的地。在接近村庄之前,天空下起了瓢泼大雨,汽车在泥水的巷道之间穿行。最后停到一个大概是个个体所承办的“山庄”大院里。

还行,当我们在苍蝇飞舞的餐厅中吃着那些粗糙的农家饭时候,我们依然对这个旅行充满了期待。我从一个西部乡村长大,吃过很多的乡村饭,但从来没有见识过如此口味的农家饭。不过因为肚子饿,也就不说什么了,只能对他们的生活水平表示遗憾了。

饭毕,雨过天晴。大家都出门骑马,去呼吸草原的清新。我挑了一匹毛色锃亮,看似剽悍的黑马,心想驰骋于草原之上,是多么的美好哦。没想到这匹马不给我面子,最多来个小跑,大概骑了四十分钟,到达了目的地。呵呵,这边游人很多,已经西斜的太阳慵懒的照在这片绿色的草地和山坡上,让人突然觉得其实地球上还是有些比较天然的地方的。

我们在这里照了很多照片,简直就是一个数码相机的展示会。我请他们给我用各种不同牌子的相机记下了我的兴奋。

我和马的情感

大家觉得差不多该回去吃晚饭了。我骑着那匹不会奔腾的懒马冲在队伍的前面——差是差点儿,但我还是胆子稍微大些的人(毕竟我也是西部过来的人),敢大声的呵斥马,让马儿觉得不能懈怠。

小的时候,我曾经骑过一次驴。嘿,那次可是够爽。我和我堂弟两人骑在他家的那匹黑驴上,他用缰绳猛抽驴,那匹驴飞快的跑着,简直比汽车还稳。呵呵,那时候我们可一点儿恐惧感都没有。这件事情深深的记在我的脑海中。因为我觉得骑驴不太专业,骑马才够专业。我到每个景点上只要有看着精神的马,都会试一下,但至今未果。

尽管向导告诉我回家的途中马儿会跑得比较快,但我仍然没有感到驰骋的感觉。真遗憾,我比那匹“骏马”还累,大声的尝试着各种口令:“驾!”“求!”,不过马儿依然我行我素,用它那四腿小跑,告诉我它已经是老江湖不吃我这一套了。最后还是有效果的,等我回去,我觉得肚子肠子腰都不是我自己的了。

我何时才能真正享受到纵马驰骋的感觉?只能等下一次了。

一个懒惰而自私的村庄

这匹破马还不太傻,带我又到了那个村庄。进村子的时候,路又变成了泥泞的世界。长途汽车,卡丁车,马,人在稀泥中游弋。

似乎这个村子的旅游业比较发达,但没人想到去修一下路。马蹄子带起来的泥浆早就让每个游客变成了泥人。在路上,我还发现当地人大多穿长筒雨靴。一个人家正用抽水机将自家院子中的积水抽到马路上。还有一个人抱怨一辆汽车把他砌起来的土埂砸开,让雨水回流到自家的院子。

尽管村庄附近便是碧绿的草原,山坡上有一坨一坨的树木。后来看到有些地方也有树林。但我却发现这些人家的屋前屋后都没有种树,种花。凌乱的村庄布局让人感觉这儿的人不太团结,不懂生活。

想起故乡民勤来,突然有了一种骄傲。那儿的村庄总有一条直向的马路,从村子一头通向另一头。每家前面都有树槽,尽管现在因为现在缺水树木不能存活,但故乡人从来就没有忘记排水的重要性。我真希望看到的大雨能够下到故乡民勤,以免辜负那些为承接雨水而修的树槽。

大概是下雨的日子,几乎没有看到小孩。这里除了游人,就是当地做生意的人。这些生意人也很懂讨价还价,一小时伴游他们要25块,加上他们自己提供的马匹,他们每小时可以挣50块。如果满打满算8小时工作,他们每个月可以拿一万二(税后),呵呵,一个地道的金领!

继日又游附近的另一景区,在途中停车查看了他们的庄稼地。那儿的麦穗已经发黄了。但麦穗很短,只有我见过的民勤的麦穗一半长。中间杂草很多。看样子这自从播种之后就无人看护。这儿的土地黑黝黝的,很肥沃,那甜菜的叶子长得非常粗壮和肥厚。当然,这个甜菜地是另一个村庄所有,这个村庄旅游业不太发达。

什么景点,你还想去第二次?

我玩过的景点也不算少了,但最终真想去第二次的景点至今还没有。当然原因很多,如因为本身距离太远,没有特别的时间和机会等等。

但我想说的是,一个好的景点必须考虑所有的因素:地理环境+旅游设施+好的人文环境。其中地理环境和人文环境非常重要。一个好地方但里面都是些烂人,就像我上文所说的这个村庄,那我是不想去第二次的。


(2005-8-16)

腾讯QQ马化腾看过来(对QQ界面的一点提高建议)

TagQQ,    MSN,人机界面,缺点                                          

QQ为什么受到一个坏的名声,不能被工作人员当作即时通讯的工具?而MSN的境况却要相对好得多?

这几天交互使用这两个工具,我发现它们两的界面有所差异:

 QQ界面中使用“聊天”作为标题

腾讯QQ使用“聊天”作为窗口标题及按钮标题。

 MSN使用“对话”作为窗口标题

相反的,  MSN使用“对话”作为窗口标题

所以,老板看见有些员工使用QQ“聊天”,而有些员工使用MSN“对话”。老板当然不喜欢员工在工作的时候“聊天”,尽管他们都在工作,但影响自然就会相应不同。

马化腾,知道我说的意思了吧!?

腾讯Messenger2005Beta1比MSN7.0的可取之处

作者:Goooder(http://goooder.blogchina.com

Tencent Messager 可以说是跟着MSN Messager成长起来的。最开始就是觉得完全在跟MSN的样子做。但现在却加入了自己的一点创新,非常的有意思。

具体现象就是每当点击一个联系人(或者当前焦点在某个联系人上时),程序会将这个条目放大几倍。这个效果就如Mac OS X中的那个眩目的任务栏一样,给人留下一种深刻的印像。而且,这种做法非常符合人际界面设计中的Fits定律。

那个小秘书也有点意思。感觉婆婆妈妈的,今天第一次看见,还是有新鲜感的。

MSN7.0没有升级版本。是不是下一个版本MSN要跟着Tencent Messager学了?(噫,这个博客中国网站上的笑脸图标怎么看着不太友善,是不是看芙蓉姐姐的照片看多了???)。

具体界面如下图:

  

上图:Tencent Messager 2005 Beta1 界面截图

上图:MSN Messager截面截图

生活的艺术(Art of living)

我突发心情,试着翻译的。
 
Art of living
生活的艺术

I would be true, for there are those who trust me;
我求真,只因信任我的人;
I would be pure, for there are those who care;
我求纯,只因在乎我的人;
I would be strong, for there is much to suffer;
我求健,只因这些受难的人;
I would be brave, for there is much to dare.
我求勇,只因这些胆小的人。
               - Walter

Love is patient, love is kind.
爱是平静的,也是和蔼的;
It does not envy, it does not boast, it is not proud.
它不含嫉妒,不含自夸,不含傲慢;
It is not rude, it is not self-seeking, it is not easily angered, it keeps no record of wrongs
它不粗鲁,它不自私,它不会易怒,它从来不会有错;
Love does not delight in evil but rejoice with the truth.
它从不为罪恶欣喜但总是为真理雀跃;
It always protects, always preserves.
它天性爱保护,天性爱蕴藏;
Love never fails.
真爱无敌。
             - I Corinthians
 

Salutation to the Dawn
早安,黎明


Look to this day!
看这日子吧!
For it is life, the very life of life.
在生命里,每个生命的生命里,
In its brief course
在这简短的历程里
lie all the verities and realities of your existence;
           the bliss of growth,
               the glory of action,
                  the splendor of beauty,
包含了所有的真理和我们存在的意义:
     成长的幸福,
         行动的荣光,
             美的激励,
For yesterday is but a dream,
昨天只是一个梦,
And tomorrow is only a vision,
明天也只是一个幻觉,
But today well lived makes every yesterday
             a dream of happiness,
但今天的努力将让昨天的梦变成喜悦,
And every tomorrow a vision of hope.
让明天变成希望,
Look well, therefore, to this day!
所以,就让我们倾注于今天吧!
Such is the salutation to the dawn.
这就是我向黎明致敬的理由。

- Kalidasa, Indian dramatist
6月9日

Windows CE 编程的十点忠告

出处: 作者: 『时代PDA』掌上电脑资讯==智能手机 2003-8-28 11:14:43 最近两周我们花了大部分时间将已有的应用程序移植到Microsoft Windows CE中。一般说来,这个计划不是太难。我们起步于Microsoft Win32代码,当然 Windows CE是基于Win32应用程序接口(API)的。有利的是,我们的应用程序(即Raima 数据管理器)有方便的使用接口,并包含一个大约由150个子函数组成的库,这些函数都是由C语言写成,可以用来创建、管理和访问数据库。

  按建立应用程序的方式来说,我们原以为将它移植到Windows CE中是一项相对简单的C语言编程练习。然而,我们不久便遇到好些困难。从粗心大意的错误开始,比如在基于Windows NT 的Windows CE仿真器上使用Microsoft Windows NT库,接着又违背Windows CE的编程戒律,如"千万不要给Unicode(国际标准组织10646标准)字符分配奇数内存地址"。

  大约有百分之九十的问题或多或少地与Unicode有关。尽管Unicode编程不难,但是,当给单字节字符编写代码时,很容易出错(我有过许多次错误)。

  下面这些忠告是根据我们在Windows CE上编写Raima 数据管理器的经验总结出来的,但我相信,在做任何其它Windows CE程序之前,它们都值得借鉴。毕竟大多数Windows开发者,当他们创建第一个Windows CE应用程序时,真正运用的是已掌握的Win32知识。

1. 不要在仿真器上使用Windows NT库

  这里所讨论的第一个错误实在太愚蠢了,但我还是陷了进去,也许你也会。当用Microsoft VC++(5.0版)创建一个Windows CE程序时,你会发现,包含路径(include)、 库路径(library)、及可执行程序路径被自动调整以匹配反应目标环境的选择。因此,比如说为Windows CE模拟器建立应用程序时,你会发现,include路径没有指向Win32的包含文件(在VC目录下),而是指向Windows CE包含文件(在WCE目录下)。千万别去修改。

  由于Windows CE在Windows NT下运行,所以仿真器上运行的程序能够调用任一Windows NT动态链接库(DLL)中的函数,即使这个DLL不是模拟器的成员也一样。显然,这不是很好的事,因为相同的函数也许在手持PC(H/PC)或Windows CE设备上不可用,而你的软件最终要能在这些设备上运行。

  第一次将非Unicode应用程序装入Windows CE仿真器时,你会发现,许多正在使用的函数它都不支持,例如美国国家标准协会(ANSI)定义的字符函数strcpy()。这也许引诱你去链接Windows NT 运行时间库,以便能解决所有问题。

  如果你是刚开始用Windows CE编程,可能你能用的包含文件和库文件是明显的。答案就是,你不要采用那些在写普通Win32或非Windows CE程序时使用的包含文件和库文件。

2. 不要混淆TCHARs和bytes

  如果你正在Windows CE上写非Unicode应用程序,你或许要将所有的字符串从单个字符(chars)转换为宽字符(widechars)(例如,C变量类型whcar_t)。几乎所有Windows CE支持的Win32和运行时间库函数都要求宽字符变量。Windows 95不支持Unicode,然而,为了使程序代码具有可移植性,你要尽可能采用tchar.h中定义的TCHAR类型,不要直接使用wchar_t。

  TCHAR是定义为wchar_t还是char,取决于预处理器的符号UNICODE是否定义。同样,所有有关字符串处理函数的宏,如_tcsncpy宏,它是定义为Unicode函数wcsncpy还是定义为ANSI函数strncpy,取决于UNICODE是否定义。

  在现存的Windows应用程序中,有些代码也许暗示字符长为单字节。这在给字符串分配内存时经常用到,例如:

int myfunc(char *p)
{
char *pszFileName;

pszFileName = malloc(MAXFILELEN);
if(pszFileName)
strncpy(pszFileName, p, MAXFILELEN);
/*etc*/

  在这段代码中,分配的内存块应该写作(MAXFILELEN * sizeof(char)),但是大多数程序员喜欢将它简化为MAXFILELEN,因为对于所有的平台来说sizeof(char)的值等于1。然而,当你用TCHARS代替多个字符时,很容易忘记这种固有的概念,于是将代码编写成下面的形式:

int myfunc(TCHAR *p)
{
TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);
If (pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/

  这是不行的。它马上会导致出错。这里的错误在于malloc函数中指定变量大小为bytes,然而_tcsncpy函数中使用的第三个变量却指定为TCHARs而不是bytes。当UNICODE被定义时,一个TCHAR等于两个字节数(bytes)。

上述代码段应该改写为:

int myfunc(TCHAR *p)
{
TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN * sizeof(TCHAR));
if(pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/

3. 不要将Unicode 字符串放入奇数内存地址

  在Intel系列处理器上,你可以在一奇数内存地址储存任何变量或数组,不会导致任何致命的错误影响。但在H/PC上,这一点不一定能行 ? 你必须对大于一个字节的数据类型小心谨慎,包括定义为无符号短型(unsigned short) 的wchar_t。当你设法访问它们的时候,将它们置于奇地址会导致溢出。

  编辑器经常在这些问题上提醒你。你无法管理堆栈变量地址,并且编辑器会检查确定这些地址与变量类型是否相匹配。同样,运行时间库必须保证从堆中分配的内存总是满足一个word边界 ,所以你一般不必担心那两点。但是,如果应用程序含有用memcpy()函数拷贝内存区域的代码,或者使用了某种类型的指针算术以确定内存地址,问题也许就出现了。考虑下面的例子:

int send_name (TCHAR * pszName)
{
char *p, *q;
int nLen=(_tcslen(pszName) + 1) * sizeof(TCHAR);

p=maloc(HEADER_SIZE + nLen);
if(p)
{
q = p + HEADER_SIZE;
_tcscpy((TCHAR*)q, pszName);
}
/* etc */

  这段代码是从堆中分配内存并复制一个字符串,在字符串的开头留一个HEADER_SIZE的大小。假设UNICODE定义了,那么该字符串就是一个widechar字符串。如果HEADER_SIZE是一个偶数,这段代码就会正常工作,但如果HEADER_SIZE为奇数,这段代码就会出错,因为q指向的地址也将为奇数。

  注意,当你在Intel系列处理器中的Windows CE仿真器上测试这段代码时,这个问题是不会发生的。

  在这个例子中,只要确保HEADER_SIZE为偶数,你就可以避免问题的发生。然而,在某些情况下你也许不能这么做。例如,如果程序是从一台式PC输入数据,你也许不得不采用事先定义过的二进制格式,尽管它对H/PC不适合。在这种情况下,你必须采用函数,这些函数用字符指针控制字符串而不是TCHAR指针。如果你知道字符串的长度,就可以用memcpy()复制字符串。因此,采用逐个字节分析Unicode字符串的函数也许足以确定字符串在widechars中的长度。

4. 在ANSI和Unicode字符串之间进行翻译

  如果你的Windows CE应用程序接口于台式PC,也许你必须操作PC机中的ANSI字符串数据(例如,char字符串)。即使你在程序中只用到Unicode字符串,这都是事实。

  你不能在Windows CE上处理一个ANSI字符串,因为没有操纵它们的库函数。最好的解决办法是将ANSI字符串转换成Unicode字符串用到H/PC上,然后再将Unicode字符串转换回ANSI字符串用到PC上。为了完成这些转换,可采用MultiByteToWideChar()和WideCharToMultiByte () Win32 API 函数。

5. 对于Windows CE 1.0的字符串转换,劈开(hack)

  在Windows CE 1.0 版本中,这些Win32API函数还没有完成。所以如果你想既要支持CE 1.0又能支持CE 2.0,就必须采用其它函数。将ANSI字符串转换成Unicode字符串可以用wsprintf(),其中第一个参数采用一widechar字符串,并且认识"%S"(大写),意思是一个字符串。由于没有wsscanf() 和 wsprintfA(),你必须想别的办法将Unicode字符串转换回ANSI字符串。由于Windows CE 1.0不在国家语言支持(NLS)中,你也许得求助于hack,如下所示:

/*
Definition / prototypes of conversion functions
Multi-Byte (ANSI) to WideChar (Unicode)

atow() converts from ANSI to widechar
wtoa() converts from widechar to ANSI
*/
#if ( _WIN32_WCE >= 101)

#define atow(strA, strW, lenW) \
MultiByteToWidechar (CP_ACP, 0, strA, -1, strW, lenW)

#define wtoa(strW, strA, lenA) \
WideCharToMutiByte (CP_ACP, 0, strW, -1, strA, lenA, NULL, NULL)

#else /* _WIN32_WCE >= 101)*/

/*
MultiByteToWideChar () and WideCharToMultiByte() not supported on Windows CE 1.0
*/
int atow(char *strA, wchar_t *strW, int lenW);
int wtoa(wchar_t *strW, char *strA, int lenA);

endif /* _WIN32_WCE >= 101*/

#if (_WIN32_WCE <101)

int atow(char *strA, wchar_t *strW, int lenW)
{
int len;
char *pA;
wchar_t *pW;

/*
Start with len=1, not len=0, as string length returned
must include null terminator, as in MultiByteToWideChar()
*/
for(pA=strA, pW=strW, len=1; lenW; pA++, pW++, lenW--, len++)
{
*pW = (lenW = =1) ? 0 : (wchar_t)( *pA);
if( ! (*pW))
break;
}
return len;
}

int wtoa(wxhar_t *strW, char *strA, int lenA)
{
int len;
char *pA;
wchar_t *pW;
/*
Start with len=1,not len=0, as string length returned
Must include null terminator, as in WideCharToMultiByte()
*/
for(pA=strA, pW=strW, len=1; lenA; pa++, pW++, lenA--, len++)
{
pA = (len==1)? 0 : (char)(pW);
if(!(*pA))
break;
}
return len;
}

#endif /*_WIN32_WCE<101*/

  这种适合于Windows CE 1.0的实现办法比使用wsprintf()函数要容易,因为使用wsprintf()函数更难以限制目标指针所指向的字符串的长度。

6. 选择正确的字符串比较函数

  如果你要分类Unicode标准字符串,你会有以下几个函数可供选择:

wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()

wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()

CompareString()

  第一类函数可用来对字符串进行比较,不参考当地(Locale)或外文字符。如果你永远不想支持外文,或者你仅仅想测试一下两个字符串的内容是否相同,这类函数非常好用。

  第二类函数使用现有的当地设置(current locale settings)(系统设置,除非你在字符串比较函数之前调用了wsetlocale()函数)来比较两个字符串。这些函数也能正确分类外文字符。如果当地的字符"C"("C" locale)被选定,这些函数与第一类函数就具有了相同的功能。

  第三类函数是Win32函数CompareString()。这个函数类似于第二类函数,但是它允许你指定当地设置(the locale)作为一个参数,而不是使用现有的当地设置(current locale settings)。CompareString()函数允许你选择性地指定两个字符串的长度。你可以将第二个参数设置为NORM_IGNORECASE,从而使函数比较字符串时不比较大小写。

  通常,即使不将第二个参数设置为NORM_IGNORECASE,CompareString()函数也不用来区分大小写。我们经常用wcsncoll()函数来区分大小写,除非使用当地的字符"C"("C" locale)。所以,在我们的代码中,不使用CompareString()函数来区分大小写,而用wcsncoll()函数来区分大小写

7. 不要使用相对路径

  与Windows NT不一样,Windows CE没有当前目录这个概念,因此,任何路径只是相对于根目录而言的。如果你的软件给文件或目录使用相对路径,那么你很可能把它们移到别的地方了。例如,路径".\abc"在Windows CE中被当作"\abc"看待。

8.移走了对calloc()和 time()函数的调用

  C运行库中的calloc()函数不能使用,但是malloc()函数可以代替calloc()函数。并且不要忘记,calloc()函数初始化时分配的内存为零,而malloc()函数不一样。同样,time()函数也不能使用,但你可以使用Win32函数GetSystemTime()函数代替time()函数。

  经过以上的警告后,你会高兴地学习最后令你惊讶的两点忠告。

9. 不需要改变Win32 输入/输出(I/O)文件的调用

  Win32的输入输出函数,Windows CE也支持。允许你象访问Win32文件系统那样访问对象。CreateFile()函数在Windows CE中不能辩认标志FILE_FLAG_RANDOM_ACCESS,但是这个标志仅用作可选的磁盘访问,并且不影响函数调用的功能。

10. 不要担心字节的状态

  当我们把应用程序写入Windows CE时,有了一个美好的发现,那就是Windows CE的数字数据类型的字节状态与Intel结构的字节状态一样,在所有的处理器上,Windows CE均支持。

  几乎象所有的数据库引擎一样,Raima数据库管理器在数据库文件中以二进制形式保存数字数据。这就意味一个记录无论何时写入数据库或从数据库读出,均被当作一系列的字节来处理,不管它域的内容。只要数据库文件不要传给别的任何系统,数字数据的字节状态问题就解决了。如果数据库文件被一个来自原始系统且带有不同字节状态的处理器访问,数字数据将被误解。

  无论何时,当你在拥有不同处理器的机器上传输文件时,就会出现这个问题。在这个问题上,值得高兴的是所有类型的处理器都使用相同的字节状态。

  在使用Windows CE时,这10点忠告应该引起你足够的重视,避免学习时走弯路。

 
全 3 枚中 1 枚目