多年来我一直在用 C、C++ 和 C# 设计和开发 Windows Mobile 和 Windows CE 软件。此外，我一直在 Honeywell（以前称为手持产品，2007 年被 Honeywell 收购）从事此工作，在那里我从事设备的几乎所有方面的工作，从驱动程序和服务到业务线 GUI 和实用程序。
首先，我won't告诉你一种语言比另一种更好......我可能在每种语言上花费了 50/50 的时间，并且每个平台在移动开发中肯定都有自己的位置。
不过，我建议您远离任何运行 WinCE 4.2 等旧操作系统的设备，特别是如果您正在考虑 .NET 开发。这样做的原因是 4.2 最多只在 ROM 中嵌入了 .NET CF 1.0（操作系统 ROM 映像的一部分），这意味着您需要 ~5MB CAB 文件来安装至少 .NET CF 2.0 是的，您可以使用 CF 1.0 进行开发，但实际上，不值得使用如此旧的框架。现在大多数 WinCE 5.0 设备都在 ROM 中安装了 CF（Compact Framework）2.0，所以我至少会寻找它。
同样，您甚至可能需要考虑使用运行 Windows Mobile 6.0 或 6.1 的设备，因为它们易于编程，并且始终预装 CF 2.0。如果您想知道为什么我没有提到 CF 3.0 或 CF 3.5，那只是因为与这些版本一起发布的第一个移动平台将是 Windows Mobile 6.5，而该版本尚未发布。不过，如果您愿意，您始终可以安装该框架（~8MB CAB）。
诚然，与 Windows Mobile 相比，WinCE 的 GUI 无疑为您提供了更加“Windows”的外观和感觉，因此这完全取决于您的编程偏好以及最终用户的需求。
关于吉安纳卡基斯的关于 SDK 只是一个事物层的评论，这是不正确的。如果您有合适的 SDK，您应该可以像在 C++ 中一样访问任何设备或驱动程序，但可以轻松使用 C#。例如，霍尼韦尔以 C++、VB 和 C# 形式为我们的所有设备提供了广泛的 SDK，并且 SDK 的 C# 部分实际上具有more功能优于 C++ 部分。你会never必须使用我们的 C# 代码执行 P/Invoke。
如果你想看看我正在谈论的 SDK，它可以免费下载here并且有一些很好的例子。
恕我直言，在很多情况下，我实际上认为提供的 SDK 比硬件更重要，因为大多数时候，设备的硬件几乎是相同的。它们都有 ARM CPU、WiFi、蓝牙、激光或基于图像的扫描仪等。
不过，我查看了您发布的 Intermec 链接，看起来该设备实际上并没有内置扫描仪......您是否使用连接到设备的外部扫描仪？
如果您愿意，请查看霍尼韦尔的产品here。我们的设备可能是业内最好的基于成像仪的条形码扫描仪，内置于我们的所有设备中。我们有一个坚如磐石的 SDK（我应该知道，我写了很多）。 SDK 提供对设备上所有硬件的 .NET 极端访问。好吧……我现在就停止推销。
至于一种语言优于另一种语言……这实际上完全取决于您到底想做什么。
司机和服务cannot不能用 Native (Win32) C 或 C++ 以外的任何语言编写。所以.NET 不适合这样的事情。
在保持轻量级方面，C 和 C++ 绝对可以成为移动设备上的朋友，因为您不需要整个 .NET 框架来运行该添加。请记住，任何进程的最大内存为 32MB（不包括 DLL...那是另一讲），因此如果您的应用程序要处理a ton对于数据来说，C++ 可能是最佳选择。
然而，我发现 C 和 C++ 在移动系统上的主要缺点之一是制作 GUIway比 .NET 更难 实际上，我编写的大多数 C++ 应用程序都是完全无头的，根本没有 GUI....NET CFdoes not（还）有 WPF，并且一直使用 WinForms，但它确实很容易上手。在设计器中几乎可以进行拖放操作。还要记住，正如我之前提到的，WinCE 具有与 Windows Mobile 完全不同的 GUI 范例。然而，有时 Windows Mobile 方式还是不错的，因为它迫使您保持 GUI 简单明了。
内存消耗can使用 .NET 时会更高，但并非总是如此。其一，如果设备的 ROM 中存储有您要使用的 CF 版本，则意味着 .NET 应用程序与等效的 C++ 应用程序相比，通常不会使用更多的内存。在某些情况下，.NET 甚至会使用less记忆。例如，.NET 应用程序与使用 MFC 的 C++ 应用程序相比，通常可以使用更少的内存，因为 C++ 应用程序必须加载 MFC 框架（因为操作系统尚未加载它......）。
此外，由于 C# 是托管的，因此您通常会减少内存使用量，因为垃圾收集器正在释放您可能忘记在 C++ 应用程序中执行的内存操作。
在更现代的设备上，两者的执行速度通常没有什么不同。诚然，每种语言总会有一小部分比另一种更快，但 .NET 在这一点上已经足够成熟，速度并不是真正的问题。我编写了具有高度交互性、动画 GUI 的极快应用程序，这些应用程序在具有 128MB RAM 和 420MHz ARM CPU 的设备上运行良好。我什至写了一个我必须做的应用程序减速因为它通过 P/Invoke 调用本机 DLL，而 .NET 部分基本上变得“不耐烦”。
我从未见过一种语言与另一种语言的电池寿命有任何问题。但我也从未专门测试过它。
我真的认为，最终，它仍然取决于您选择的设备附带的 SDK。如果它的 .NET 支持很差，那么你会发现自己做了很多额外的工作才能让一切正常工作，在这种情况下我会选择 C++。但是，如果它具有出色的 .NET 支持（就像我所从事的那样），您会发现自己的工作量减少了很多，并且可能会更快地完成工作。
另外，请记住，您需要考虑的不仅仅是硬件供应商的 SDK。虽然您需要特定的 SDK，因为每个设备都不同（即我之前链接到的 SDKwill not在 Intermec 设备上工作）所有非硬件相关的操作系统内容几乎都是全面标准的，这就是 Microsoft 的 Windows Mobile 或 Windows CE SDK 的用武之地。他们的 C++ 支持非常好，但他们确实在推动现在所有的东西都是.NET，所以随着操作系统的更新，C++ SDK 的更新越来越少，多得多现在的功能依赖于使用 .NET 不是你couldn't用 C++ 来做，只是他们没有为你做很多工作did在 .NET SDK 中执行。
好吧……那很长，但我试图将我多年经验的精华部分转化为一件事。我希望这是有道理的。
