我正在将windows7库移植到嵌入式平台。为了做到这一点，我的雇主问我系统在移植后需要多少内存（和CPU，但现在让我们专注于内存），这样他就可以根据我的需求调整电路板的大小。
我在互联网上看了一眼，似乎没有太多关于这个问题的信息，因此我提出了一些问题：
-
为了大致了解代码在闪存中的内存占用情况（只有没有数据内存的代码），我在互联网上读到，我应该将我使用的所有dll的大小相加。似乎所有的编译器和平台都为代码占用提供了不同的大小，但总的来说，代码的大小（没有数据）通常非常接近。你确认了吗？
-
为了只处理数据所需的内存（堆+堆栈，但没有代码），我查看了任务管理器（和进程资源管理器）。我使用的数据总量似乎是在"峰值工作集"中指定的。不过，我有几个问题：
2.a."工作集"是否包括堆+堆栈内存，还是仅对应于堆？
2.b."工作集"是否也包括代码的大小？（因为我在windows 7上，代码也存储在RAM中，而不是像在嵌入式系统上那样存储在闪存中），还是它只与数据相对应？
2.c."峰值工作集"似乎反映了从程序启动时起RAM中实际存在的最大物理内存量，但它并没有反映程序之后可能占用的大小（如果我碰巧在运行时分配内存，那将很糟糕；）-峰值将继续增加）。你确认了吗？
2.d.因此，您是否也确认，如果我在运行时不分配内存，"峰值工作集"应该大致是我的嵌入式系统所需的RAM的最大大小？由于系统技术的差异，尺寸差异很大。。。
谢谢，
安托万。
除非您打算在Windows Embedded上运行应用程序，否则查看Windows中的代码和数据使用情况并不能说明什么有用的！
1） DLL是库，并不是其中的所有代码都会被您的代码使用。大多数嵌入式系统都是静态链接的，链接器只链接代码实际引用的模块。因此，取DLL依赖项的总和很容易导致内存需求的严重高估。
2） Windows内存管理浪费了内存使用，因为它可以而且这样做通常会提高典型桌面系统的性能。例如，Windows中的线程堆栈通常在2Mb左右——你可能很少使用那么多，但Windows在任何情况下都会给你它，因为它可以而且这样做是出于安全考虑。嵌入式系统中的线程堆栈通常从几十字节到几十KB不等，这取决于您的应用程序。
Windows任务管理器显示Windows为您的进程分配的内容，这些内容可能与您的进程需要的内容无关。此外，您的应用程序正在使用Windows服务-用于内核和设备服务的所有内存都不会显示为进程的一部分，但您的嵌入式系统可能仍然需要这些内存。
如果您确实使用Windows原型代码来评估嵌入式系统需求，那么您最好的起点是让链接器生成一个映射文件，该文件将根据静态分配的数据和代码大小详细描述内存使用情况。
代码大小不仅取决于编译器的性能，还取决于指令集的效率。一些体系结构实现了比其他体系结构更高的代码密度。Windows应用程序代码大小从来都不是嵌入式代码大小的好指标，因为它的执行环境可能会有很大的不同。例如，32位ARM上的抢占式多任务RTOS内核可以在不到10Kb的代码中实现，一个文件系统可能还有10个，网络堆栈从10到30K，USB还有10个。正如您所看到的，这是一个与桌面代码不同的世界。
数据内存的使用可能更容易确定；但你可以通过分析你的应用程序而不是观察Windows的功能来做到这一点。有一些数据是你的应用程序直接实例化的，还有一些数据是由你可能调用的库和设备驱动程序实例化的——在Windows中，后者可能相对较大，超出了你的控制范围。典型的嵌入式系统库，如网络堆栈、USB、文件系统等，在性能和大小方面都更小、更具确定性。
您最好根据应用程序的一般用途、性能要求、实时限制及其硬件要求（显示、网络、I/O、大容量存储等）来描述应用程序，然后查看可比较的解决方案或实施解决方案所需的库；大多数嵌入式系统都是"裸板"，除非你编写或使用第三方解决方案，否则没有Windows中的服务——Windows很少是嵌入式系统的可比解决方案。
如果它只是一个库而不是一个应用程序，那么使用Windows托管的GCC交叉编译器为likley目标构建它，看看它最终有多大。你不需要硬件，甚至不需要花钱。