Harriet666 | OurJS

by Harriet666 keys 分享 1506650334597

9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。

brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。

Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？

戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。

brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。

Q：为什么百度当时要研发brpc？

戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。

我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。

Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？

戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。

RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？

可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。

Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？

戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。

Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？

戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:

对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。

无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。

Q：谈谈brpc的整体架构？

戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。

Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。

名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。

Q：brpc的性能如何？这么高的性能是怎么做到的？

戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：

百度地图API入口
联盟DSP
ELF学习框架
云平台代理服务

Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？

戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>

未发布【示例教程】使用Leadtools对身份证进行识别和表单模板创建

by Harriet666 keys 分享 1511426850168

使用Leadtools的表单识别功能可以对固定格式的表单很方便的进行批量识别，生活中常见的身份证、驾驶证、发票等都可以识别出准确的结果。另外通过表单匹配的功能同时也能实现对表单进行自动分类。本篇教程以身份证识别为例，介绍整个识别和创建的流程。

Leadtools 19总套包下载>>>

1、模板创建

1.1制作空白表单
通过photoshop对拍摄到的身份证进行处理，仅保留公共部分的内容和字段，对于身份证照片和个人具体信息都进行清除，结果如下图

1.2使用leadtools表单编辑器编辑模板
打开leadtools开发包安装目录：C:\LEADTOOLS 19\Shortcuts\Forms Recognition & Processing\.NET Class Libraries\Forms (Structured & Unstructured)\Forms Recognition & Processing\Master Forms Editor

运行其中的可执行程序，点击NEXT.,选择载入主表单数据集，载入默认路径，选择professional引擎，进入主界面

添加中文语言支持

添加身份证主表单

向身份证表单添加图像，选择刚才已经制作好的空白图片

添加完成后，可以在主界面的右侧对模板进行编辑

下图是可以在模板中添加的识别类型，本例中，我们主要使用文本和图片两个类型

点击相应的识别类型，在模板上拖动为需要识别的区域，如下图，然后保存即可。

添加后可以看到左下角的信息栏里面有添加的字段的详细信息，可以对字段的名称，位置等，进行进一步的修改，最后点击保存按钮，这样我们就完成了表单的创建。

创建表单过程：

2、识别表单

直接在该演示程序的菜单中点击如下按钮即可打开识别程序

单独打开识别程序的目录为：C:\LEADTOOLS 19\Shortcuts\Forms Recognition & Processing\.NET Class Libraries\Forms (Structured & Unstructured)\Forms Recognition & Processing

打开后的节目如下，同样先附加中文语言包

点击菜单按钮，选择一个身份证图片进行识别

识别完成后会弹出识别结果界面，可以看到身份证上所有的信息都已经被准确的识别出来了，

以下为识别过程

未发布 GLG工具包Visualization and HMI Toolkit更新至v3.6，支持Java Script

by Harriet666 keys 分享 1490344507662

Visualization and HMI Toolkit的为开发高级图形的动态界面而设计的艺术化的框架：它不仅仅是简单的按键与菜单，它是全动态的能显示动态数据以及能反映用户互动的图片对象。它不仅仅是能制作“漂亮图片”绘制工具（它还具有很多其他功能），而是能使开发人员定义图片对象以及与程序中的对象互动的图形引擎。它的使用对象主要针对应用程序开发人员，能将乏味的低级别图片代码编译工作转化成高级的互动设计行为。

GLG工具包Visualization and HMI Toolkit更新至v3.6，点击下载>>>

支持Java Script：

对Java Script的增加的支持使得用户可以定义自定义函数，将多个输入值转换为驱动动画的输出值。通过可以添加到对象属性的新Java Script转换来使用Java Script。例如，一个新的“LED Value Display”部件可以通过使用Java Script转换来实现部件的逻辑。

转换的Java Script属性包含用于生成输出值的Java Script代码。转换的Arg List属性通过$ N符号提供脚本中使用的可变的参数，其中N是基于1的参数索引（即 $ 1是第一个参数）。参数可以是双（D）、字符串（S）或XYZ（G）类型。Java Script转换的输出值也可以是D、S或G类型，与其所附属性的类型相匹配。

例如，可以使用以下Java Script将D属性的值设置成以度为单位的第一个参数的sin函数：Math.sin （$ 1 / 180. * Math.PI）

下面的Java Script可用于根据第一个参数的值和由第二个、第三个参数定义的阈值来在“NORMAL” 和“ALARM”之间切换的文本字符串：$ 1 <$ 2 || $ 1> $ 3？“ALARM”：“NORMAL”

对于复杂的Java Script来说，可以通过Java Script文件提供Java Script函数和方法库。加载此文件时，可以在图形中使用该文件中定义的Java Script函数。

应用程序可以使用包含Java Script方法集合的全局Java脚本文件并在应用程序的图纸中使用。该文件将被预加载并用作Java Script库。Viewport的JavaScriptFile属性也可定义为该viewport预加载的Java Script文件。所有加载的Java脚本都是全局的，可以在应用程序的任何位置访问。从Java Script文件加载的函数将覆盖任何以前具有相同名称的Java Script函数。

GLGeditors和所有GLG API都支持Java Script：C / C ++、Java、C＃和Windows上的ActiveX。C / C ++和ActiveX中的Java Script支持由Duktape JavaScript Engine提供，对于C＃来说可以使用Jurassic JavaScript引擎（由Jurassic.dll提供）。在Java中可以使用Java的JavaScript引擎。

所有Java Scripts都在绘图设置时先行编译，以实现更快的运行。这些脚本也可以进行缓存。

GlgJavaScriptFile全局配置资源或GLG_JAVA_SCRIPT_FILE环境变量可用于指定全局Java Script文件。对于GLG Builder和GLG HMI配置器，还可以通过-glg-java-script-file命令行选项或GLG配置文件中的GlgJavaScriptFile资源（即glg_config或glg_hmi_config）提供全局Java Script文件。

【本文作者慧都Elyn，转载注明出处】

未发布 .Net文档图像处理工具包GdPicture.NET发布v14，提供最先进的PDF和文档成像技术

by Harriet666 keys 分享 1500539281166

GdPicture.NET 14.0是2017年初的第一个主要版本。像过去13年一样，GdPicture.NET团队力求提供最先进的PDF和文档成像技术。

此版本所有主要功能都得到了改进：PDF、TWAIN采集、压缩、文档渲染、文档转换、条形码识别、字符识别和文档清理。此外还包括其他流行的文档文件格式新功能或改进功能，包括Office Open Xml相关功能和使用Wang注释的TIFF。现在也支持RTF文档格式。

DocuVieware是HTML5文档管理的主要扩展，还包括一个新的注释评论管理单元，支持所有浏览器中的HTTPS TWAIN扫描，并大大地提升了性能。现在提供了通过任何流行的Web技术（如Angular、ASP.NET Core、ASP.NET、Java、JavaScript、Node.js和PHP）使用DocuVieware的所有必需资源和功能。

【GdPicture.NET 14.0点击下载>>>】

新的功能和改进

新的文档查看器引擎

新版本附带了一个全新的渲染引擎，可以非常快速地展示大尺寸位图，并以多页视图模式显示多页文档。对于所有支持的框架，它已经被加入到了WinForms版本的GdViewer控件中。

新文件转换器类

处理快速文档转换的新类已添加到工具包中。它允许通过处理转换的每个方面（颜色、元数据、注释、图像、文本...），将任何支持的文档格式（通过GdPicture）快速转换为流行格式，如PDF和TIFF。（需要GdPicture Ultimate版本）。

支持新的文档格式

现在支持RTF查看和转换。渲染和显示、获取缩略图、浏览、搜索、转换为PDF或位图。使用多视图模式、文本搜索、文本选择和提取等查看GdViewer和DocuVieware中的rtf文档。

字符识别和可搜索PDF（PDF-OCR）

该OCR引擎已经改进，以减少内存的使用，提高稳定性和准确度（尤其是低分辨率的位图）。

GdPicture.NET 14.0可搜索PDF（PDF-OCR）已经改进。创建更快，生成的文件更小。

字符识别引擎已经优化，使用较少的内存，并且PDF页面识别方法得到了改进。

长期归档（PDF/A）

PDF/A是长期存档电子文件的ISO标准。感谢GdPicture.NET PDF/A功能，可以创建标准化的电子文档，可以在任何系统上随时随地地展示，同时可以使用兼容的查看器打开。

GdPicture.NET 14.0能够生成PDF/A的任何格式：PDF/A-1a、PDF/A-1b、PDF/A-2a、PDF/A-2b、PDF/A-2u、PDF/A-3a、PDF/A-3b和PDF/A-3u。

附加PDF支持功能

增强了PDF的最重要部分，以改善解析、写入、渲染、内存使用和速度。当使用Unicode内容编写PDF时，GdPicture.NET 14.0附带了一种新的字体生成引擎，支持TrueType字体的子集。该软件现在支持用于Unicode文本绘图的OpenType字体。新的文本提取算法构建更接近自然阅读顺序的文本。

GdPicture.NET现在读取复杂的PDF最多可以提高5倍速度，并且更快地编写pdf文本。

其他新功能和增强功能包括：

支持传递函数到PDF光栅化器。
新的CCITT滤波器解码器。
支持将JPEG图像添加到PDF中，无需对图像进行解码/重新编码。
改进了具有链接文档的PDF包。
改进页面规范化支持。
提高大文件的处理速度（和内存使用量）。
打印：减小了一些复杂文档生成的卷轴大小。
打印：提高生成页面的质量，特别是虚拟打印机。

Office打开Xml Word处理文档

GdPicture.NET 14.0包含了很多改进的渲染引擎，并提供对表格内容和图片的支持。渲染引擎快了80％。

条形码引擎

GdPicture.NET条形码读取引擎使用错误校正机制。在GdPicture.NET 14.0中引入了改进的纠错机制，以提高引擎的速度和精度。条形码引擎使用查找器模式来定位文档中的代码。

当将GdPicture.NET 14.0引擎与GdPicture.NET 12.0引擎进行比较时，可以获得以下数据：

1D条码阅读引擎
提高10％的条形码识别
提高44％的补丁代码识别
快14％
数据矩阵条码阅读引擎
提高15％的条形码识别
PDF 417阅读引擎
提高14％的条形码识别
快40％
QR码阅读引擎
快18％
提高24％的条形码识别

文件成像过滤器

GdPicture.NET页面自动校正精度有所改进。
空白页检测引擎的准确性大大提高，更好地排序空页。
引入了一个新的颜色压缩过滤器，将特定颜色放入多个上下文中：退出表单等。

注释评论

GdPicture.NET 14.0新的评论功能可以帮助集成商解决文档审查的难题。

基于GdPicture.NET的应用程序可以存储由GdPicture.NET（超过100个）支持的所有格式的注释，包括PDF和TIFF。有了这个新功能，这些应用程序可以提供协作文档审阅，参与者可以在审阅过程中共享信息。

支持Wang注释

Wang注释是一种老旧的注释格式。ORPALIS开发了将这些旧式文件转换为最先进的注释PDF或TIFF的工具。

该工具可用作github上的开源项目。请参阅：https：//github.com/Orpalis/WangTagReading

改进图像编码解码器

GdPicture.NET图像压缩速度得到提高：
JPEG2000解码速度高达25％
在64位系统上压缩JPEG图像的速度大约10-15％
使用预测变量压缩PNG图像的速度提高了30％，达到50％
改进RAW图像加载速度，并增加了对80多个新相机的支持
支持在BMP文件中读取和写入alpha通道

杂项

通过Twain扫描时，使用存储器传输模式增加了对压缩位图的支持
提高了Twain内存传输速度
改进1D条码刻录机编码
参考指南大大改进，并将不断更新

DocuVieware全球改进

受益于GdPicture.NET 14.0的最新改进，DocuVieware 3.0提高了性能、内存占用以及用户体验。

格式支持也得到了改进，现在可以将Microsoft Office OpenXML文档导出到向量PDF。

未发布 Edraw Max（亿图图示）：新手如何快速美化思维导图？

by Harriet666 keys 分享 1500001938383

如今思维导图无处不在，大到产品设计、活动策划，小到整理读书笔记等等。用思维导图都可以很方便的帮助我们发散思维、整理思绪，而一个精致美观的思维导图也能够更加的吸引眼球和注意力。那么，对于新手来说，应该如何用Edraw Max（亿图图示）绘制出精美的思维导图呢？

首先用Edraw Max（亿图图示）创建思维导图时，可以通过模板和例子快速创建，亿图内置大量的思维导图实例，以及更多的免费在线模板都非常的时尚、美观。

其次，在绘制思维导图的过程中，我们也可以通过修改思维导图的样式和主题风格来进行美化。

目前Edraw Max（亿图图示）在线订购享75折优惠活动正在进行中，欢迎您下载、购买进行运用！

Edraw Max（亿图图示）V8.7中文版点击下载>>>

【样式】

一键修改整个思维导图布局样式：

选中主题形状。
在思维导图菜单中选择布局风格。
点击思维导图菜单栏下的“间距”，即可快速增加、减少水平、垂直间距，甚至可以一键重新设置。

一键修改整个连接线样式：

全选(Ctrl + A)所有图形。
点击“思维导图”菜单栏下的“连接线样式”。
选择所需的样式即可。

修改局部连接线样式：

选中需要改变连接线样式的上一级主标题。
点击“连接线样式”。
选择所需样式。选中的主标题和下一级副标题之间的连接线将会被修改。

改变某个形状的位置：

在目标形状附近移动光标。
选择需要调整位置的形状，长按鼠标左键并开始拖拽该形状。
当拖动某一形状使其靠近另一形状时，就会自动吸附到另一形状，放开鼠标即可完成吸附。

【主题】

Edraw Max（亿图图示）默认思维导图的符号中，“主题”形状是蓝色的，“主标题”的形状是绿色的，“连接线”则自动生成的是直线。但是亿图提供了多种主题风格可供任意选择，而且可以一键修改整个思维导图的主题风格。具体操作步骤如下：

点击“思维导图”菜单栏;
选择“思维导图主题”，然后根据思维导图主题缩略图选择所需的主题风格即可。

未发布 ReactOS：基于Windows的开源操作系统

by Harriet666 keys 分享 1505209149271

ReactOS是一个免费开源的全新操作系统，其设计基于Windows，就像Linux基于Unix一样。ReactOS的外观和Windows类似，可以运行Windows软件和驱动，不过，该项目正在进行当中，可能尚无法完美兼容，最好的方法是在虚拟机上安装ReactOS，检查兼容性。

ReactOS使用X.Y.Z版本命名方案：X表示项目是否达到预期目标，Y表示大版本（关键特性和增强），Z表示小版本（Bug修复和一般开发）。第一个有文档记录的版本是0.0.7，发布于1998年7月。

作为开源项目，由于社区开发人员的数量不固定，所以ReactOS没有一个固定的路线图。不过，他们会尽量在二到六个月发布一个版本。0.4.0、0.5.0和1.0.0是当前设置的里程碑版本。0.4系列版本是最后的Alpha版本，从0.5系列版本开始，项目将进入Beta测试阶段，1.0及以上版本表明该项目已经可供日常使用了。

ReactOS 0.4.6已于近日发布。该版本向真正的硬件支持迈出了重要的一步。若干双启动问题得到了解决，分区管理的安全性得到了提高，可以避免分区列表结构的冲突。ReactOS Loader现在可以加载自定义内核和HAL了。

在0.4.6中，打印子系统尚不成熟，但Colin Finck已经实现了大量新的API，并修复了一些自动化测试中暴露出的Bug。

在驱动方面，Pierre Schweitzer为其增加了NFS驱动程序，并开始实现RDBSS和RXCE，将来还会支持SMB。Sylvain Petreolle为其引入了数字电视调谐器驱动。UDFS、CDFS、SCSI和HDAUDBUS中的若干Bug也得到了修复。

在兼容性方面，0.4.6引入了一个shim引擎，作为新应用程序兼容框架的一部分。在这个版本中，该引擎默认关闭，可以通过ReactOS注册表启用。该版本还包含一个专门的NTDLL库，可以为比较新的软件提供一些它们需要的NTDLL Vista+函数。

ReactOS 0.4.6还改进了用户体验，并修复了多个内存管理、ntoskrnl和文件系统的Bug，变得更加稳定。

未发布 GIS软件开发工具包TatukGIS Developer Kernel更新至v11.7丨附下载

by Harriet666 keys 分享 1504171491009

GIS定制开发首选控件，帮您轻松搞定高效、优质、实惠的GIS解决方案

TatukGIS Developer Kernel（DK）是一个用于开发自定义地理信息系统（GIS）应用程序以及解决方案的综合性软件开发工具包（SDK）。众所周知，构建一个庞大的地理信息系统需要花费大量的金钱和人力，而TatukGIS却是同类产品中性价比最高的控件，TatukGIS Developer Kernel DK因其功能强大，价格适中，已被超过 50个国家的个人、公司、以及政府等客户用来实现其地理信息系统解决方案。根据不同地首选开发环境，本产品分别以五个独立产品的形式提供（即VCL、.NET/WPF、ActiveX、Compact Framework和ASP.NET），各个产品使用相同的框架、应用程序编程接口（API）技术。

TatukGIS Developer Kernel v11.7最新版点击下载>>>

TatukGIS Developer Kernel v11.7更新内容

更新内容：

DK for Java（Beta）发布。（DK-9623）
一些.NET样本在除96之外的DPI上不能正常打开。（DK-9488）
SimplEdit得到了一个更容易测试编辑的数据集。（DK-9501）
插值方法在速度和CS支持方面大大改善。（DK-9502）
改进TGIS_IsochroneMap类。
插值样本出现错误。（DK-9493）
修正了WinForms在非标准DPI上放大矩形问题。（DK-9510）
插值样本重做。（DK-9493）
修复了打印预览组件的各种问题。（DK-9510）
示例源代码现在可用于在线浏览。参考Isochrone样品。
改进示例文档。
审查样品。

未发布界面控件包Essential Studio for Windows Forms 2017 v3发布丨附下载

by Harriet666 keys 分享 1503046651124

Essential Studio for Windows Forms界面控件包含了高性能的Windows应用程序开发中所需的所有控件，如Grids、Charts、Gauges、Menus、Calendars、Editors等等。到目前为止，我们开发Windows Forms 控件包已达十几年，所以该控件包是功能最齐全的控件集。除此之外，Essential Studio for WinForms还包含了一些特有控件，使您可以为应用程序添加Excel、Word和PDF格式文件的浏览和创建功能。

Essential Studio for Windows Forms 2017 v3下载>>>

Essential Studio for Windows Forms 2017 v3让开发人员创建更好的应用程序，并增加了DocIO的内容控件，支持消息框的定制以及标记PDF的功能。