• 系统中真的就只能呈现两个串口吗？当然不是。条码识读器是可以模拟成串口数据源的，基于 USB 的双向数据通道，也是可以被模拟成一个串口的。

  Is the system only limited to two serial ports? Of course not. The barcode scanner can work like a serial port, because it is actually a data source. USB-based bi-directional data channel can also be considered as a serial-port.
• Flash 方面的动态性就更强了。一片 Flash 上只能安放一份文件系统吗？当然也不是。想想一台 Windows PC 上的硬盘，里头可是有 C: D: E: 这好些个分区的，每个分区都被 Windows 认为是一个设备。

  Does the single Flash chip accommodate only a single file system? Sure not. Think of a Windows PC, a harddisk supports many partitions that is named C: D: E: etc, each of which is considered a device.

这说的是什么意思？

What does it mean?

• 我们开发的一个软件分为基础版和专业版，不应该为基础版编译一个 EXE 文件，为专业版再编译一个 EXE 文件；相反，应该只编译一个 EXE 文件，根据用户填入的序列号来呈现基础版和专业版的不同功能。

  If our software is marketed as Basic version and Pro version, we should NOT compile and EXE file for Basic, and another for Pro; instead, we should compile a single EXE, and it presents different features according to serial number provided by the end-user.
• 如果我们的软件同时支持 Windows XP 和 Windows 10，那么，不要为这两个 OS 各自编译一份 EXE，而是用同一份 EXE 。在古老的 WinXP 上，我们仅仅调用老式的 API 来完成工作；而在新版 的 Win10 上，我们才去调用新版的 API 来达成新系统上的新功能。事实上，UFCOM 就是这么做的，它从 WinXP 一直支持到 Win10，而且设法做到了只提供一份二进制文件。

  If our software supports Windows XP through Windows 10, we should NOT build two EXE files for each of the OS version; instead, build only one. On the older WinXP, we call only old system APIs; on the newer Win10, we call new APIs to achieve new features by the OS. Actually, UFCOM takes the very approach; it support WinXP through Win10, by a single set of binary files, with a bit effort from me.
• 对于像 PT-850 这样的产品，单一二进制的原则依然适用。PT-850 其实是一个产品系列，包含很多种子型号。不同的子型号在硬件配置上有所差别，它们可能有不同型号的条码识读头，不同的无线通信模块，甚至不同的主板版本号（主板上有一些细微的硬件差别）。我的同事曾经有生成多份二进制的倾向，比如，给不带无线通信模块的编译一个内核，给带 GPRS 模块的编译一个内核，再给带 Wifi 模块的编译一个内核。好在我介入该项目后及时阻止了这种做法，并且将单一二进制原则一直保持到产品生命周期结束。

  For a product like PT-850, this principle still applies. PT-850 actually has a series of sub-models. Different sub-models may have different scanner hardware, different wireless module(GPRS or Wifi), and even different mainboard versions with subtle hardware discrepancies. There had been trends from my co-workers to build its kernel into different variants, for example, one kernel for non-wireless model, one for GPRS model, and yet another for Wifi model. That bad trend was stopped by me as I got involved in this project, and I never allowed it to stray away until end of the product life.

好处是什么？

What's the benefit?

1. 减少用户的选择负担。用户很可能不是 IT 专家，选择应该使用哪一份二进制（或软件安装包）对它可能有困难。比如，用户可能不清楚自己用的 Windows 版本是 XP 还是 7/8/10，不清楚自己的系统是 32 位的还是 64 位的。即使用户清楚，更多的选择意味着更多犯错的可能性，用户也许不小心用了不匹配的版本，结果表现出软件故障让他一头雾水。

   Relief the user from the burden of selection. Our users may not be IT experts, so picking an appropriate binary(or installer) may be difficult for them. For instance, some user may not know what operating system version he is using, Windows XP or 7/8/10, or not knowing whether his system is 32-bit or 64-bit. Even if he is clear all about these, making selection means possibility of making errors. User may accidentally pick an inappropriate version and see weird behavior appear, frustrated.
2. 降低用户的认知负担。用户可以简单地通过一个软件名加一个版本号来清晰地辨识出我们的软件。由于实施了单一二进制策略，我们的软件安装包名称就可以很短，短却没有歧义，这样的软件用户第一眼就会觉得清爽。

   Reduce the cost of cognition. User can identify our software with a simple software name and a version number, no other hassles. Thanks to the single binary strategy, we can name the installer in very short words, what a relax to the user.

1. 让版本号变简洁。实施单一二进制策略，我们的版本号命名只需要由数字构成即可，没有奇奇怪怪的各种后缀。比如 UFCOM，它的最新版本就是 1.7.12，由三个数字构成，就是如此简洁无歧义。

   Concise versioning. With single binary, our version number will consist only of numbers, no arcane suffixes. For example, the latest version of UFCOM is 1.7.12, consisting of three numbers, concise and unambiguous.
2. 减轻测试人员的测试负担。在测试人员眼中，他的测试对象就是唯一的一样东西，而不是好几样不同的变体。当然，如果你将测试人员也想象成是用户的话，用户端得到的好处他们都能得到。

   Reduce the burden of software tester(the QA team). From the perspective of the QA team, they test only a single object, not a bunch of variant. Of course, if you think of the QA team as your user, all user benefits apply to them.
3. 抑制源代码分支泛滥。

   Inhibit source code forking contagion.
   让我们看看不实施单一二进制会导致什么样的后果。许多缺乏经验的开发团队在决定开发一个新功能时，会倾向于将它们的代码进行一次永久分叉，然后在新分叉上加入新功能。这么做短期貌似会带来一点好处，新功能引入的 bug 不会影响到老代码。然而，长期来看这会变成灾难。他们的代码仓库中将会出现越来越多的无法自动同步改进的重复代码。为其中一份老代码的 bug 修正无法自动同步到其他的老代码副本中。开发者只能靠人力逐个去找出应该修正的副本并手工同步那个修正。更糟糕的是，没有人能够知道到底有多少个副本需要同步修正。是否它们已经全部被修正了，只能靠运气。当然，我知道如果团队能够坚持单一的代码源头，而仅仅是编译过程才生成不同的二进制文件，那么这个灾难并不会出现。我只是强调，坚持单一二进制是最彻底的解决方案。

   Let's see the dark side of not going single binary. Many unorganized team tends to permanently fork their code base and add new features on that new fork. The short-term benefit is that bugs in new feature code does not cause harm to the old code base. However, that is a long-term disaster. There will be so many duplicated and unsyncable code in devteam's code repository. Fixing a bug in one of those old code copies DOES NOT automatically have it auto-fixed for other copies. Developers have to fix them manually, one by one. Even worse, no one knows exactly how many other copies need such fix. Whether all of them get fixed is determined by luck. Sure, I know that if the team can keep a single source base and compile into multiple binary variants, this disaster can be avoided. I just want to emphasize that going single binary is the most thorough approach.

实施单一二进制有代价吗？

Any cost of sticking to single binary?

1. 我们需要额外的工作来探测出我们所在的软硬件环境，因为我们已经主动要求将这个探测工作的负担从用户身上转移到我们自己的身上。

   We need extra work to detect the hardware/software environment in which we are running, because we offer to transfer the burden of env-detection from our user to ourselves.
2. 我们需要经常重构我们的代码，以便让较少的代码能够完成较多场景下的工作。较少的代码，意味着较少的潜在 bug 以及较小的维护代价。重构，并不是简简单单地拷贝一份现有代码块后做出一点参数调整，相反，这是一项需要对原有架构进行优化甚至重新设计的工作，需要对于整个项目的全局视角才能做好。

   We have to refactor our code often, so that we can use less code for more scenes. Less code implies less potential bugs and less maintenance cost in the future. Refactoring is not easy as well. it needs deep understanding of our environment and the issues we need to solve. Refactoring is NOT simply copying a chunk of code tuning some running parameters, instead, it is about architectural optimization or even redesign, and that requires global insight into the whole project.
3. 单一二进制会让用户拿到的文件稍稍有点臃肿，因为里头的很多代码是多合一的，某些代码在具体用户的环境中可能一直会是休眠的状态。但我想这应该算是个次要问题，因为当今的计算机系统的存储容量一直在扩大。

   Single binary would ship with a little bloated files to the user, because it is all-in-one code， and some code may stay dormant in a specific user environment. Anyway, I don't think it a big problem, because computer system storage capacity is expanding fast nowadays.

让代码跨平台的各种好处

Benefits of going cross-platform

• 我的代码能够被多个编译器验证。比如，有些代码写法的缺陷在 Visual C++ 眼中被忽略了，但却可以被 GNU gcc 检查出来。

  My code gets checked in multiple compilers, for example, some coding flaw shrouded by Visual C++ may be uncovered by GNU gcc.
• 32 位编译的代码，编译为 64 位后运行崩溃。这说明代码写法上很可能有错误，常见的如将一个指针值存储在一个 int 变量中。

  Code runs well as 32-bit binary but fails when runs as 64-bit. This probably signifies a coding error, such as storing a pointer inside a int variable.
• 在强功能的平台上轻松调试与验证，在弱功能平台上放心地运行。想象一下，我需要为一台弱功能的嵌入式系统编写代码（比如 PT-850），它的 CPU, RAM, 和硬盘都很弱小，我应该怎么做最好呢？假定我要写的代码不是直接硬件相关的，那么，我一定会在 Windows 上先将代码的功能先实现，途中用 Visual C++ IDE 来调试它，写大把的测试案例在 Windows 上即时运行。当所有能在 Windows 上进行的事都完成后，我将代码编译到真正目标平台上运行。我非常自信我的代码在目标平台上将会顺利运行，毕竟 C/C++ 是跨平台的语言嘛。

  Debug and verify my program on more powerful platform with ease, and run them on less powerful platform with confidence. Consider, I'm coding for an embedded platform that has constrained CPU, RAM and disk with weak debugging facility(PT-850 is one case). What should I do then? Assuming that code is not hardware-dependent, I will definitely code the same feature on Windows first, so, I can debug my code with powerful Visual C++ IDE, write test cases to run from Windows instantly. When everything can be done on Windows is done, I compile my code for that real target system. With great confidence, it will run there without problem as well -- C/C++ is a cross-platform language after all.

还是老问题，这么做有代价吗？

Still the question, any cost?

• 我需要费心去了解各种目标平台的编译器，至少要知道用什么样的编译开关才能生成各种文件类型，EXE/LIB/DLL 等。我还需要留意不同厂商的编译器、以及同厂商编译器不同版本之间行为的差异，遵循它们共有的特性，以便我的源代码能够适应所有这些编译器，比如，Visual C++ 和 gcc 处理 C++ 模版的行为就有一些区别。对于无法回避的差别，得设计一些预处理宏来区分不同的编译器、或是将无法调和的代码拆散到不同的源文件中。

  Quite some effort is required to get acquainted with various compilers involved. At least, I should know what compiler switches are responsible for generating EXE/LIB/DLL etc. I also need to know subtle difference between compilers from different vendors(or different versions of the same vendor), stick to common parts of them, so that my source code is compilable by all of them，e.g. Visual C++ and gcc exhibit some different behaviors when coping with C++ templates. For differences that I cannot bypass, I need to design some preprocessor macros to distinguish them, or, dissect unsharable parts into different source files.
• 最具挑战性的工作是如何管理工程文件。我们知道，为了将 .c/.cpp 编译成可执行文件，我们还需要工程文件。一个工程文件用于告知需要编译和链接哪些源文件，用什么选项来编译和链接，甚至还含有依赖性信息（需要先编译哪些“库”）。问题在于，不同编译器、甚至同一编译器的不同版本使用的工程文件千差万别。Visual C++ 6 用的 .dsp, Visual C++ 2005/2008 用的 .vcproj, Visual C++ 2010 及后续版本用的 .vcxproj, Linux 工程一般用 makefiles, 基于 ARM 的商业编译器有它们各自的专有格式。如果我要为五个目标平台编译代码，难道我得维护五份工程文件吗？这简直就是苦力。

  The most challenging work turns out to be project-file management. As we all know, to compile .c/.cpp files into executables, we need project files. A project file tells what source files to compile and link, what options to use for compiling and linking, and even its dependencies(what libraries to build first etc). The problem is, project files from different compilers or different compiler versions are heterogenous. Visual C++ 6 uses .dsp, Visual C++ 2005/2008 uses .vcproj, Visual C++ 2010 and later uses .vcxproj, Linux projects use makefiles, ARM-based commercial compilers use their proprietary formats. If I want to compile for five target platforms, do I need to maintain five project files? What a burden.
  因此我决定使用自己的工程文件格式，基于 GMU 的 makefiles 。我的典型工程管理模式是这样的：使用两组工程文件，一组是 Visual C++ 的工程文件，这让我在开发阶段便于编辑代码和可视化调试；另一组是 GMU makefiles，负责所有平台上的命令行编译。本文后头有对 GMU 的更详细介绍。虽然不算完美，但还算是总体能够接受的解决方案。

  So I decided to employ my own project file, that is, makefiles based on GMU. My typical project management pattern is: Use two sets of project files, one is Visual C++ project file that ease code editing and visual debugging on Windows; the other is GMU makefiles that is responsible for command-line building for all platforms. I'll talk about GMU in more detail later. Although not perfect, it reaches a state of overall acceptance.