物联网与 Windows – 需要什么，过去的教训

令人兴奋的物联网是程序员的下一个前沿领域。最有趣的是 Windows 运行这些设备的可能性。但是，要实现这一点需要什么？是否需要改变思维方式才能实现这一点？

过去的教训

那些在 20 世纪 70 年代和 80 年代开始职业生涯的程序员还记得在原始计算能力非常有限的计算机上编写软件是什么样的。令我惊讶的是，像树莓派这样的当前微型设备，以及 Windows 世界中现有的 x86 微型 PC 设备，似乎都显得性能不足，而且它们没有更好的表现令人费解。考虑到这一点，一位老程序员可能会得出一些结论。

在过去，计算机性能的关键在于软件，甚至是操作系统（过去一些家用计算机不像今天这样拥有完整的操作系统，而是通过直接硬件访问支持基本的输入和输出）。让我们来看一个例子，它演示了即使是有限的硬件，只要有合适的软件，也能有多么强大。

今天，任何一台 CPU（或 SoC，片上系统）运行速度达到或超过 1 吉赫的计算机设备在性能上出现问题，这真是令人费解。回想一下过去的家用计算机，Commodore 64（C64）。C64 当时是一台功能强大的小型计算机。它的 CPU 运行速度高达 1 兆赫（是兆赫，不是吉赫）。好吧，我这里有点幽默。按照今天的标准，1 兆赫不应该被称为“飞快”（快）。然而，在过去，一些程序员认为这样的计算机比大多数人想象的要强大得多。C64 用户可能还记得这些机器上解释型 BASIC 的运行速度有多慢。准确地说，它“慢如蜗牛”。但是，当时的程序员发现，当他们学会使用真正的原生代码编译器，甚至通过使用机器语言来编写软件时，他们就能让这台慢如蜗牛的计算机做一些惊人的事情。我个人开始使用 Abacus BASIC 64 编译器，这是一个巨大的进步。人们实际上可以编写出具有相当不错性能的软件。使用那个编译器，我然后编写了我自己的微型编译器，它有一个有限的命令集，这样我就可以编写性能接近汇编语言速度的代码。我的微型 BASIC 编译器直接生成机器码（中间没有汇编器）。我很快就发现，编写软件的方式有很大的不同。使用我的微型编译器，我编写了一个适合家庭的电子游戏，并将其出售给 Compute Gazette 杂志，在短短几周的工作中赚取了 1500 美元，对于一个在 20 世纪 80 年代末自学成才的业余程序员来说，这可不是一笔小数目。

一些杰出的程序员，可能使用汇编语言编程，为 Commodore 64 构建了一个名为 Geos 的操作系统。Geos 将 Commodore 64 变成了一台 Macintosh（苹果）般的计算机（它的价格是 C64 的四倍，速度却是 C64 的八倍）。创建 Geos 的 Berkeley Softworks 将 C64 的潜力发挥到了甚至连其制造商（Commodore）从未设想过的程度。这一切都发生在一台拥有 1 兆赫 CPU、64 千字节内存和外部软盘驱动器（只有 170 千字节的磁盘空间）的计算机上。

学到的教训是什么？使用原生代码编译器编写的、更接近硬件的软件可以达到惊人的速度。编写软件的方式很重要。

Windows 世界

在 32 位 Windows（Windows 95）的早期，一台典型的 PC 可能只使用运行速度为 100 兆赫或更快的 CPU，内存可能不到 24 兆字节。与今天的 PC（例如 1.5 吉赫 CPU，2 千兆内存）相比，这简直微不足道。当前大多数 Windows 软件可能无法在如此低配置的硬件上运行。现在考虑一下现在出现的许多基于 x86 的微型 PC、爱好原型设备。在 ARM 世界中，树莓派在业余爱好者中取得了巨大的成功。在 x86 世界中，出现了 Intel Galileo、MinnowBoard 和 SharksCove 等设备，但价格仍然对普通业余爱好者来说有点太高了。虽然我认为他们需要将这类设备的价格降至 50 美元左右，并纳入现在提供给 OEM 厂商制造平板电脑的免费版 Windows 8.1，以构成一个完整的软件包，但真正的挑战将是为这些设备编写能够充分发挥其潜力的软件。

作为一名程序员，我一直在兴奋地关注着这些设备，但仍然存在两个我认为需要解决的障碍。首先，正如之前提到的，是价格。为了与树莓派相媲美，并且价格实惠，能够成为未来“物联网”设备的基础，价格需要大幅下降，即使这意味着硬件的原始性能（CPU、内存等）有所降低。这类设备的制造商仍然沿用 Windows PC 的思维方式，因此硬件规格可能太高，这或许可以解释为什么价格高于 ARM 设备。随着下一代 7 英寸的 Windows 小型平板电脑的上市，价格为 100 美元，那么原型设计、业余爱好微型计算机设备肯定可以以更低的成本制造出来。其次，Windows 需要进行一定的精简，使其更适合小型设备使用，同时仍保留完整的用户界面功能。现在有些人可能会认为这很难。如今典型的 Windows PC 已经非常强大，但大多数人没有意识到这一点。为什么？因为如今软件的编写方式。那么，Windows 如何才能进行精简，使其更适合即将到来的物联网呢？

移除操作系统中所有托管语言引擎。移除 .NET。移除 WINRT。只保留核心的 WIN32 API。这将减少硬件方面的开销。这将使 Windows 更适合用于“微型、微型”设备。针对较小的屏幕尺寸，分辨率低至 1024 x 600（即使像东芝微型平板电脑那样需要伪装，让 Windows 认为显示器比实际尺寸更大）。Windows API 是一个非常、非常精简且快速的 API。核心 API 所需的内存和 CPU 速度可能远少于如今的完整操作系统。

乍一看，人们可能会认为这会严重限制 Windows 的开发，但我更倾向于认为，就像 Commodore 64 和 Geos 一样，开发人员将学会如何利用 Windows 的原始功能，并且他们将找到方法来突破即使是最小硬件的限制。如果微软希望 Windows 无处不在（意味着生活中的所有领域的设备），那么就需要改变对 Windows 的思维方式。

有些人会说，这不可能

有些人可能会说，想法很好，但根本不可能，也不切实际。但我恰恰相反，而且我有充分的理由。与今天大多数通过 Visual Studio 使用托管语言的 Windows 开发人员不同，在过去的 15 年里，我的公司主要使用简单的原生代码编译器和原始的 WIN32 API。可能因为我过去在计算的“老时代”的经历，早在 20 世纪 80 年代，我特意在旧的、遗留的计算机上进行实际的日常软件开发，以强迫自己习惯最小化的硬件。例如，当 Windows XP 是当前 Windows 时，我大部分开发工作都是在一台运行 Windows 95 的 233 兆赫计算机上完成的，而不是 Windows XP。我确实用 256 兆内存（对 Win95 来说已经很多了）对其进行了升级，但它仍然只有 233 兆赫的 CPU。我会在这台 PC 上开发我的软件，然后在更现代的 PC 上进行测试。通过强迫自己习惯较少的硬件资源，它帮助我学会了如何编写无论硬件如何都能良好运行的软件。令人惊讶的是，原始的 WIN32 API 非常适合这一点，而且它是为原始性能设计的。

此外，我发现使用 WIN32 API 开发的软件内存占用很少，可执行文件也非常小，令人惊讶。感觉就像回到了过去，编写可以装在软盘（小于 1.4 兆字节）上的软件。现在有人可能会认为，有了 WIN32 API，程序员将无法使用像 .NET 这样的更高级的 GUI 框架。虽然起初是真的，但我相信随着时间的推移，具有正确心态的开发人员将开始构建（只需要 WIN32 API 的）GUI 框架，这些框架将像 Commodore 64 的 Geos 一样，体积小且速度快。你可能会说不可能！嗯，实际上是可以的，在过去的 15 年里，我的公司一直追随 Geos 开发人员的脚步，构建了一个为最小化硬件设计的 GUI 框架。我知道这是可能的，因为它已经在发生了。如果其他公司想为基于 Windows 的物联网设备构建下一代软件，也应该考虑这种方法。我仍然对 WIN32 API 的强大功能以及可以实现什么感到惊讶。我构建了一个拥有近 1000 个命令的GUI 框架，它仍然可以装在软盘上（绰绰有余，只有大约 1 兆字节），这表明微型物联网（Internet of Thing）设备应该不成问题。

WIN32 编程，一项失传的技艺

WIN32 编程似乎已成为一项失传的技艺，但并非如此。对于有兴趣将其纳入软件开发方法的公司来说，有大量的资源可供选择。你仍然可以使用托管语言为 PC 和一些 Windows 平板电脑开发软件，但对于即将到来的物联网，为什么不考虑添加 WIN32 编程呢？你可能在想，大多数编程网站都面向托管语言，那么我在哪里可以找到关于 WIN32 编程的信息呢？在 Amazon.com 上快速搜索可以帮助你找到大量的关于 WIN32 编程的旧书（可惜据我所知，目前没有新的）。一些最好的资源可以在制造原生代码 Windows 编译器的公司提供的支持论坛上找到。微软的网站虽然不教授 WIN32 编程，但确实有关于WIN32 扁平 API 的详尽文档。虽然有些人可能称它们为遗留 API，但它们实际上是 Windows 的核心。你认为 .NET 在什么之上运行？你可以跳过“中间人”，直接进入操作系统的核心。

不信？

让我举一个利用 WIN32 API 的公司的例子，这样你就能更好地欣赏它的功能（*注意：这家公司与我的公司无关*）。重点在于展示当程序员使用核心 WIN32 API 而非托管语言为 Windows 编写软件时，可以实现什么。这家公司是我近年来遇到的最优秀的图形引擎开发商之一。他们编写的一个工具叫做 GDImage，它是一个图形引擎，可以利用多个低级图形 API 并将它们合并，包括 GDI、GDIplus 和 OpenGL。最初的版本是使用 PowerBasic 32 位原生代码编译器编写的，但开发人员已将其移植到 Microsoft C，以获得 64 位编译的优势。开发人员还在多个编程论坛上分享了他们对 WIN32 编程的知识。关键在于，这个图形库（DLL）功能丰富，性能非常好（速度快），设计上只使用了核心的 WIN32 API，并且整个运行时库只有 315 KB（千字节）大小。这就是开发者希望为即将到来的物联网设备达到的尺寸。这相当于一张老式软盘的 1/5 大小。下载该开发者的演示，以便更好地体会这一点。该开发者甚至避免使用 GDIplus 的 C++ 类，而是使用了 Windows 中提供的扁平 GDIplus API。有一些开发者目前正在利用原始的 WIN32 API（以及 OpenGL 等）。仍然有一些资源可供程序员学习 WIN32 编程。