将使用者从实现细节中解放出来

事情的起因

     去年一时兴起，利用windows的系统API写了一个简单的俄罗斯方块游戏。今年重读去年编写的代码时，发现了如下的代码。

SS_VOID SS_PrintErrorMsg(void)
{
	DWORD errorCode = GetLastError();
	LPVOID pOutputBuffer = SS_NULL;
	LPVOID pDisplayBuffer = SS_NULL;
	SS_INT32_T MsgLen = 0;
	
	FormatMessage(
		FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
		SS_NULL, 
		errorCode, 
		0,
		(LPTSTR)&pOutputBuffer,
		0,
		SS_NULL
		);
	
	MsgLen = (SS_INT32_T)((_tcsclen((LPCTSTR)pOutputBuffer)+40)*sizeof(TCHAR));
	pDisplayBuffer = (LPVOID)LocalAlloc(LMEM_ZEROINIT, MsgLen);
	_vstprintf_s(pDisplayBuffer, MsgLen/sizeof(TCHAR), TEXT("errCode:%d, ErrorMsg:%s\n"), errorCode, pOutputBuffer);
	SS_PutMsg(pDisplayBuffer, SS_FALSE);
	LocalFree(pOutputBuffer);
	LocalFree(pDisplayBuffer);
}

        当初使用LocalAlloc、LocalFree的原因很简单：使用windows的系统api，这两个系统函数式windows系统的api。重读时则有了疑问：malloc，LocalAlloc，GlobalAlloc, new这四种申请内存的方法有什么区别吗？为了解决这个问题，我决定重读《windows核心编程》内存管理相关的章节。如今，原本想要解决的问题没有进展，却想通了另一件事情。

新问题 -- windows系统为什么要将内存申请过程分为了保留虚拟地址空间、提交物理内存两个子过程呢？

        首先，从应用编写的角度来看这个问题。作为一个应用程序的开发者，会怎样理解内存、会怎样申请内存、使用内存呢？在编写一个应用程序之前，我会确认计算机的内存容量。假设内存容量是4G内存，开机之后系统剩余内存2.5G。此时，我会认为可使用的最大内存是2.5GB，也会想当然的认为 (0,2.5GB] 这个区间的值是一个合法的值，这个区间外的值是一个非法的值。这是很自然的想法。 然后，从系统实现的角度来看这个问题。现在只有有限的资源4G内存，有多个应用同时运行。需要保证：存在空闲内存时，应用申请内存的请求都会被满足。用比较概括的语言来叙述实现方案的话，很简单。即，记录已经分配出去内存，记录还未分配出去的内存。每当应用申请内存时，从未分配内存区域拿一块内存给应用使用。一个矛盾出来了，实际分配的内存是不连续的、期望的内存是连续的。 如何解决这个矛盾呢？映射！！系统分配的物理内存地址不要直接传给应用，而是将这个地址转换为另一个地址，将转换后的地址发送给应用。只要保证转换后的地址是在一个连续的空间就可以了。保留虚拟地址空间目的就是确定连续地址区间，提交物理内存就是申请真实的内存，并将真实的内存地址转换到一个连续区间内。

引申 -- 应用开发者不应该直接使用LocalAlloc, GlobalAlloc这样的系统API

        一个应用开发者是不应该讲精力放在底层实现细节上的，而应该将精力放在提升用户体验上。我猜测C/C++运行时库提供了内存管理器，这个内存管理器的目的就是将使用内存的方法简单化。应用开发者只需要申请、使用、释放就可以了，而不需要接触保留、提交这样的概念。也许malloc, new就是运行时库提供的接口。