`
阿尔萨斯
  • 浏览: 4107962 次
社区版块
存档分类
最新评论

关于金山办公套件的Linux版本的事实真

 
阅读更多
<style type="text/css"> <!-- @page {margin:2cm} h1 {margin-bottom:0.21cm} h1.western {font-family:"Liberation Serif",serif} h1.cjk {font-family:"文泉驿正黑"; font-size:24pt; font-style:normal; font-weight:bold} h1.ctl {font-family:"Lohit Hindi"; font-size:24pt; font-weight:bold} td p {margin-bottom:0cm} p {margin-bottom:0.21cm} a:link {} --> </style>

说明:你只要搜索关键字符串”WPSLinux移植流水帐(1999-2012)“,你一定会找到以下短文(帖子):

〖纪念贴〗WPSLinux移植流水账(1999-2012)

该帖子内的具体容附在本文的后面。在此,我想先说几句话。我认为,该帖子是比较真实的,符合金山的实际情况。因为,它写于2012428日,历史的流水帐没有必要造假。在此,我只想指出一个事实:Linux版本是用Qt移植过来的,要承认这是“移植”。那么,移植前的软件包里面的电子表格所包含的那些数学函数的程序实现(即函数的程序表达式)是从何而来的?这就是问题的关键之所在。

请看帖子的原文:



(本帖最后由xtaotao2012-4-2810:29 编辑)

作者:xtaotaoWPS的架构师之一,男,未婚,内部人称

rachel
提供作者信息,以下是全文-

1999
年传闻中的wpsforlinux搁浅

WPS
最早开发Linux版本的计划是始于1999年,并且在2002年都准备发布,至于为何搁浅就不得而知了。当然这些都是传闻。
2003
WPSFor Linux正式立项、再搁浅
  2003年,WPSV6项目立项之初,就明确了跨平台的目标,开发初期是Windows版本和Linux版本同时开发的。
  当时WPS的招聘广告大致是这样写的:WPSV6是要跨平台的,因此我们为每个员工准备了两台电脑,一台装Windows,一台装Linux,同时开发。又因为我们的办公空间非常的有限,所以我们给员工配备了液晶显示器。
  而事实上是:
  我2004年入职WPS大多数员工都是一台电脑,一台老式CRT显示器,当时的液晶显示器只有十几台,约1年半之后,我才终于换上了液晶显示器,约7年半之后,我才领到了两台电脑,一台装Windows,一台装Linux
  不过当时Linux确实是在做。后来随着市场和竞争对手的压力逐渐加大,Linux就被暂时搁浅。此后陆续用Wine模拟了两个Linux版本,不过未对外发布。

2010
年放弃DelphiQT重构开始
  2010年底,原Delphi的界面已经没有几个人能够维护了,在加上Linux的呼声也越来越高,于是下决心废掉Delphi的界面,用Qt重新来过。
  到20117月初,主界面的开发告一段落,我被从演示组抽出来,组建一支新的队伍,做两件事情:对话框的移植和Linux移植。
  同时演示组的同学赖平鄂、刘斌和区越坚也开始了用Qt替换GDIGDI+的工作。
  而WPS的元老、20年工龄、WPS第一个Windows版本——WPS97的负责人章立新老师,重新回到WPS,带队做EMF/WMF的移植。

第一个跑通的版本Meego
  我对Linux的热情是始于Meego,在此之前,我对Linux始终是心存畏惧的,从来没有想过我会在Linux下开发,更没有想过我会带头来做Linux的移植。偶尔和同事聊天聊到Linux开发,聊到最多的就是:如果VisualStudio能有Linux版本就好了。当然,以微软对Linux的敌视态度,这是不可能的。
  虽然后来Meego被微软的间谍给耍了一道,但我对Linux的热情却没有因此而减弱,而且在ubuntu上跑通之后,我就将WPS移植到了Meego上网本系统,整个过程非常顺利,只改了一处代码,就可以跑了,比我安装Meego的过程都简单。

十一之前Linux版本要能跑起来,这是死命令
  十一之前Linux版本要能跑起来,这是死命令。当时没有去想会有多大的难度和多少的工作量,仅凭着热情,就答应下来了。
  从7月初开始,有三个月的时间,时间还是相当充裕的,但后来因为主界面的遗留问题、对话框的一些准备工作以及年度旅游等事情,移植的工作拖到822号才开始。这时距离十一只有6周时间,算上周末共40天。
  822号:从主干上拉出一个新的linux分支。
  接下来要做的是工程文件的迁移,在Windows下,VC帮我们封装了这个操作,但是.vcproj的文件结构很复杂,一旦发生冲突,想看懂冲突双方各自的修改意图基本上是不可能的。正好趁这次移植Linux的机会,摆脱对.vcproj的依赖,而且这也是移植Linux必须要做的工作。
  当时有两个选择QMakeCMake,因为CMake的文档较丰富,并且被广泛应用,于是决定选用CMake。网上有一篇很好的教程:网友Cjacker写的《CMake实践》,非常适合作为CMake的入门教程。但当时压力非常大,根本没有心情看下去,一边看一边试,过了两天,没有什么进展,于是找了一个工具,folders4cmake,将.vcproj的文件列表提取出来,导出到.cmake文件,然后再一边改一边试。绕好大一圈,最终还是看回《CMake实践》。
  磨刀不误砍柴工,此话不假,但当时真的是没有心情慢慢悠悠的磨刀。终归是心理素质不够硬。
  约830号,CMake脚本在Windows下调通。具体的时间我不记得,这个时间是从svn的历史记录中查到的,不一定准,因为我提交代码会比较慎重,有时提交一次代码会拖延一到两天。后面的时间也都是大概的时间。
  在我迁CMake的这段时间,主干又合并了几个分支,代码发生了翻天覆地的变化,于是又将这部分修改合到Linux分支,更新CMake的文件列表,在Windows下编译通过入库。
  在之前两次迁移wine的过程中,修改了不少gcc的编译错误,这些修改一直没有合回主干。这次要把这些修改合到Linux分支,即为了避免重复劳动,也为了节约时间。
  由于wine分支从主干分出去的时间太长,因此合并产生了非常多的冲突。更有甚者,很多冲突文件都合并出了乱码。原本我们在windows下开发,没有考虑过编码的问题,所有代码都是VC默认的gb18030编码。在迁移wine的过程中,gcc不能正确识别gb18030编码的文件,导致有些文件编译不过,后来,这部分文件被存为了utf8编码,而在我们的新Linux分支上,依然保留着主干的gb18030编码。因此有些合并后的文件,混合了gb18030utf8两种编码。
  乱码要一个个改过来,冲突也要一个个确认。眼看着时间不够用,而冲突还有很多,就放弃了部分和演示无关的代码。
  95号,重点解决了演示相关模块的冲突之后,提交代码。

  WPS2012专业版定于927号发布,但因为进度拖延的关系,所有开发人员开始加班:从95号开始,连上7天班,休1天,力争27号发版本。从28号开始调休,到1012号上班,这个十一WPS连休了14天的。
  因此wpslinux版本的移植时间点也被提前到927号。

  这时,演示组的同学经过两个月的努力,已经成功用Qt替换了GDIGDI+,可以显示不太复杂的演示文档了。
  96号,赖平鄂同学将将这部分修改合到了Linux分支,GDIGDI+正式下岗了。

  终于可以切换到Linux平台工作了,取下Qt代码,编译不过,提示:找不到"emmintrin.h"文件。原因是我们修改了Qt,增加了用sse2指令集优化图片操作的代码。我也不知道应该到哪里去找"emmintrin.h"这个文件,大致看了一个,也没有什么头绪,就晾在一边。去Qt官网下载了未修改版的代码,编译通过。

  然后正式开始WPS演示代码的编译,freetypezlibhunspell原本就是跨平台的代码,因此编译过程非常顺利,第一个编译错误是kfc报出来的,kfc03年开始建设WPS基础库,试图封装对不同操作系统的api的调用,但到后来,由于进度的压力,就提交了很多赤裸裸的WindowsApi代码。
  有人说:人们对未知事物总是产生恐惧的心理。在没有接触CMake之前,我对CMake感到恐惧,因此静不下心来。但kfc的代码,再熟悉不过了,压力虽然很大,却可以静下来心来慢慢读懂相关代码,用Linuxapiqt重现实现。
  这样过了约一周,kfc还没有移植完,估算了一下时间,按这样的进度,龙年马月也移植不完。于是开始加速,遇到WindowsAPI的调用,整个函数就不要了,后来变成整个源码文件就不要了。甚至有几个工程对Windows的依赖比较大,就整个不要了。
  915号,提交了kfckso的代码。

  与此同时,黄叙鹏同学终于把手上乱七八糟的事情处理完了。仅用2天的时间就解决了编译Qt找不到"emmintrin.h"文件的问题。

本文作者的质疑是:向Linux移植的时间如此之短暂,电子表格数学函数的程序实现(不包括单纯形算法)从何谈起?又谈何移植?



分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics