摘要： 工作职责：负责后台server开发工作，网络传输及分布式部署，接入方案等；负责一定的后台server软件架构和框架设计；负责提出海量服务的解决方案，寻找高并发高负载服务应对策略。工作要求：计本科及以上学历,计算机相关专业;4年以上Linux实际开发经验,有一定架构设计能力;C/C++基础扎实,有丰富的 TCP/IP、高性能大并发、Node.js等编程经验，有音视频流媒体后台开发经验优先;工作地点在北京，产品最近上线，验证模式中。有兴趣的话，欢迎与我联系。 阅读全文

摘要： 最近，Chromebook来了，Android头子鲁宾调走了，接管的人正是Chrome浏览器主管。Chromebook沉寂了有2、3年，上一次推出的ChromeOS是以Webkit为Shell，事实证明疗效不好。而这2、3年中，听到的更多的声音是ChromeOS会被放弃掉，更应该扶正Android一统所有。从我对chromium源码了解，谷歌的开发支持有增无减，其中最吸引我的是新的桌面UI技术，代号为Aura。经过这些时间的开发，新的桌面shell搭载到Chromebook推出，是否成功拭目以待。有趣的是惠普的WebOS很尴尬，但FireFox又吵吵着要干WebOS。至于LinusTorval 阅读全文

摘要： 最近工作上比较忙，加之编码任务较多，没来得及继续之前的讲解。抽出时间把这最重要的一部分东西做个阐述。行文以基本的编程思维及个人思考过程为线索。众所周知，RichEdir强大在于其图文混排（在这里不跟Word、HTML比），其中的图替换为动态图的核心问题就归结于如何高效刷新。我们知道GDI操作是最消耗CPU的，所以刷新整个RichEdit窗口是不可取的，其副作用会导致更严重的闪烁问题。解决问题的思路很简单：类似于拖拽时候在屏幕绘制异或线，我们的动画重绘时不请求RichEdit，而直接在其窗口的DC上绘制当前动画帧，此时缺少是如何确定该OLE的位置，这个是所有问题的关键。先看下面这幅图：假定1-5 阅读全文

摘要： 最近忙里偷闲对之前的设计做了大量重构，其间转辗反侧体会到过度设计之苦。然而这个产品是我第二用心持续之作，第一的当然是自己商业化盈利产品，实乃无心插柳，感觉这2年自己设计能力进步神速，打算重新架构。前面的x-framework界面框架停止维护许久，深感自责，但是我绝没有放弃信念，卷土重来之日是必须的。先谈下richedit我做的工作，主要是参照QQ的功能进行设计，分为2个部分：texthost和richole，前者实现无窗口的richedit，后者实现动画控件。这些东西可以说网上可见的鲜有正确的方法论，很多都是饮鸩止渴之手段，我确信自己的手法是非常科学的。目前的实现：1.动画控件2.拷贝粘贴：支 阅读全文

摘要： 花了四天时间，再次对QQ的剪切板格式做了深入研究，对im_richedit做了一次重构使得richframe作为抽象的支持动画功能占位块，派生出richpicture。从基本功能上来讲，可以实现qq消息框的功能。我支持的剪贴板格式如下：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->enumFETCINDEX{kFETCINDEXUnicode,//Unicode文本kFETCINDEXAnsi,//ANSI文本kFETCINDEXDIB,/ 阅读全文

摘要： 很近没有更新了，闲话少说，直奔主题。微软做任何技术的思路：在实现一个标准的时候，往往预留出一个通用的扩展机制。呃，貌似很多大公司都是如此，通过扩展把开发者跟自己捆绑。举例：微软的ie可以嵌入ActiveX控件、可以用BHO扩展；richedit中支持OLE扩展。这种扩展机制主要是基于其OLE框架，这也是微软操作系统框架的基石。开发层面目前的趋势是，淡化OLE强调.NET，有一种无奈叫骑虎难下，有一种错误叫脱离群众，在开发平台、技术百花齐放，开发资源极大丰富的今天，开发者对微软的依赖已经不那么强烈，以至于现在的Windows开发者有点小苦逼，尤其是C++开发者有一种被抛弃的感觉，扯远了。谈谈OL 阅读全文

摘要： 男人，每个月总有那么几天心情不爽。在此期间遇到不顺心的事情，往往表现会更加强烈。随着年龄的增长，逐渐减少了码字的习惯。今天不同，喝了半斤牛二，决定堆点文字。三十而立，作为没有成功事业而有自命不凡的屌丝（今天朋友给我新解释觉得很合理，屌==JIBA，丝==毛）而言，常常会被人一句话噎死，这是最悲剧的事情。之前公司负责人今天跟我沟通，希望我能回归，很感激这是好事，只是很多事情种种情况，双方表达也有歧义，最终不欢而散，结果不重要，过程中提及最重要的是性格以及成长。顺着这个问题喝酒后发散一下，瞎扯点神马。做人、做事？大公司做人，小公司做事？一切事情道理相通，任何地方都是做人第一做事第二。前者保证你能呆 阅读全文

摘要： 实际的richedit研究过程中，遇到了各种疑难杂症，真是不容易。比如：// RichEdit使用注意:// 1.设置CFE_LINK后立即调用AutoURLDetect会导致RichEdit解析当前Word是否为链接.// 如果想避免这种情况, 必须在这CFE_LINK后插入空格以便把Word区分出来.// 2.想要对ITextServices发送EM_SCROLLCARET消息, 必须设置ES_NOHIDESEL风格, 或者// 发送EM_HIDESELECTION消息改变设置(自动滚动到底部功能).同样在实现Windowless的richedit的时候，仅仅实现ITextHo... 阅读全文

摘要： 上一次，我们可以获取到图片动画帧之间的时间间隔，如果想让动画转起来，就必须有时钟。插入的图片动画数量可能会比较多，因此要想不影响性能，时钟必须很轻量级而且要很高效。Windows平台上实现时钟的方式五花八门，你可以使用窗口相关的SetTimer来设置一个时钟，也可以自己开辟线程来做等待触发模拟时钟，而Chromium封装的要更加C++对象化一些：依托Windows窗口消息，抽象出延迟任务的概念。这种手法几年前我也曾经考虑过，只是对其中下次最短触发时间计算以及更新的算法和设计都有力不从心，最终得出的是误差很大的精简版：选择固定的最小时间片为最小触发单位，对很小的时间间隔误差很明显。Windows 阅读全文

摘要： 这里提及高效稍许有些夸张，仅为应景，因为本身就没有太多高科技，权且作为一种有效的实现。首先是图片解码器的选择。一般来讲有几种选择：1、组装各种开源库，如libpng, libjpg, giflib等，支持什么格式就得添加对应的解码器；2、开源解码包，如freeimage，没用过但听说也很不错；3、GDI+，支持图片格式广泛，接口简单，性能一般。当然还有其它方式，大抵差不多。我选择的是GDI+，图简便好用，且目前微软支持的OS上都是自带的，无需发布？!。对QQ的程序集DLL进行分析，发现其中贯穿了各种解码技术，有直接采用开源库的，也有依赖GDI+的，不知道是历史遗留问题，还是各个部门之间技术偏好 阅读全文