That is correct. This change was made in VS2012 and appears to be the behavior going forward. You can see the relevant code in the source code you have for the CRT, find it in the vc/crt/src/heapinit.c source code file:
int __cdecl _heap_init (void)
{
if ( (_crtheap = GetProcessHeap()) == NULL )
return 0;
return 1;
}
Previous versions used HeapCreate() here, also with VS5 and VS6 legacy hacks. This is not well publicized so the exact reasoning behind it is not that clear. One important detail of VS2012 is that it initially shipped without XP support. Which dropped the requirement to explicitly having to enable the low-fragmentation heap. LFH is automatically enabled on Vista and up so the default process heap is already good as-is.
A very major advantage of using the default process heap is that it solves the very nasty problems with DLLs having their own copy of the CRT and thus using their own allocators. This traditionally ended up very poorly when one DLL needed to release the memory allocated by another. No such problems anymore, as long as DLLs are rebuilt to target the later version of the CRT, they now automatically use the exact same heap so passing pointers across the module boundaries is safe.
Some concerns are valid as well. It is not clear to me what happened in Update 1, the one that brought back XP support. Assuming the CRT source is accurate (it looks like it is) then there are good odds that your program is running without the LFH enabled on XP.
And there's a possible security concern, the default process heap is also used by the winapi. So it is now technically possible for malware to hijack a buffer overflow bug in your code and reach winapi buffers. If you've previously subjected your code to a security analysis and/or fuzz testing then you should redo this. I assume that Microsoft is strongly relying on their secure CRT implementation to avoid the security issues but that's a blind guess. Hopefully James McNellis will be available to give deeper insight.
