我正在将Windows 7库移植到嵌入式平台。为了做到这一点，我的雇主向我询问了我的系统在移植后需要的内存量（以及CPU，但让我们专注于内存） - 因此他可以根据我的需要调整板的大小。
我在互联网上看了一下，似乎没有太多关于这个问题的信息，因此我的问题是：
为了大致了解闪存中代码的内存占用情况（代码只有数据没有内存），我在互联网上读到我应该总结我使用的所有dll的大小。似乎所有编译器和平台都为代码占用空间提供了不同的大小，但总体而言代码的大小（没有数据）通常非常接近。你确认了吗？
为了处理数据所需的内存（堆+堆栈但没有代码），我看了一下任务管理器（和进程资源管理器）。似乎我使用的总数据量是在“峰值工作集”中指定的。我有几个问题：
2.A。 “工作集”是否包含堆+堆栈内存，还是仅与堆对应？
2.b中。 “工作集”是否也包含代码的大小？ （因为我在Windows 7上，代码也存储在RAM中，而不是像嵌入式系统那样存储在闪存中），还是只对应于数据？
2.C。似乎'峰值工作集'反映了从程序启动时实际存在于RAM中的最大物理内存量，但它并不反映程序之后可能采用的大小（如果我碰巧在运行时分配内存 - 这将是坏事;） - 峰值将继续增加）。你确认了吗？
2.D。因此，您是否还确认如果我不在运行时分配内存，“峰值工作集”应该大致是我的嵌入式系统需要的最大RAM大小？由于系统技术的不同，最大程度的差异......
谢谢，
安托。
答案 0 :(得分：1)
除非您打算在Windows Embedded上运行您的应用程序，否则查看Windows中的代码和数据使用情况并不是一个有用的指标！
1）DLL是库 - 并非代码中的所有代码都将被使用。大多数嵌入式系统是静态链接的，链接器将仅链接您的代码中实际引用的模块。因此，获取DLL依赖性的总和可能会导致对内存需求的过度估计。
2）Windows内存管理在内存使用方面挥霍无度 - 因为它可以并且这样做通常可以提高典型桌面系统的性能。例如，Windows中的线程堆栈通常大约为2Mb - 您可能很少使用那么多，但Windows在任何情况下都会将它提供给您，因为它可以并且在安全方面这样做是错误的。嵌入式系统中的线程堆栈通常从几十字节到几十千字节不等 - 这取决于您的应用程序。
Windows任务管理器显示Windows分配给您的流程的内容，这可能与您的流程需要的内容无关。您的应用程序也使用Windows服务 - 用于内核和设备服务的所有内存都不会显示为您的过程的一部分，但您的嵌入式系统可能仍然需要这些内存。
如果您确实使用Windows原型代码来评估嵌入式系统要求，那么最好的起点是让链接器生成一个映射文件，该文件将根据静态分配的数据详细描述内存使用情况和代码大小。
代码大小不仅取决于编译器的性能，还取决于指令集的效率。一些架构比其他架构实现更高的代码密度。 Windows应用程序代码大小永远不是嵌入式代码大小的良好指标，因为它的执行环境可能有很大不同。例如，32位ARM上的先发制人多任务RTOS内核可以在不到10Kb的代码中实现，文件系统可能是另外10个，网络堆栈可以是10到30K，USB是另外10个。你可以看到这是一个不同的世界到桌面代码。
数据存储器的使用可能更容易确定;但是你通过分析你的应用程序而不是观察Windows的功能来做到这一点。您的应用程序直接实例化了数据，然后存在您可能调用的库和设备驱动程序实例化的数据 - 在Windows中，后者可能相对较大而且无法控制。用于诸如网络堆栈，USB，文件系统等的典型嵌入式系统库在性能和尺寸方面都变得更小，更具确定性。
您最好的选择是根据其通用性，性能要求，实时约束条件及其硬件要求（显示，网络，I / O，大容量存储等）来描述您的应用程序，然后再看可比性解决方案或您需要实施解决方案的图书馆;除非您编写或使用第三方解决方案，否则大多数嵌入式系统都是“裸板”并且没有您在Windows中找到的服务 - Windows很少是与嵌入式系统类似的解决方案。
如果它只是一个库而不是一个应用程序，那么使用Windows托管的GCC交叉编译器为一个有目标的目标构建它，看看它有多大。你不需要硬件，甚至不需要花钱。