But the flip side of that is that optimizations that were made when resources were tight may bite you in the ass when resources become available. For example, the declaration for the WinMain entry point that still persists to this very day in Win32 and Win64 applications looks like this:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow);
Note the hInstance and hPrevInstance bits. Back in the day Windows loaded the code for a Windows application's .EXE once into memory and then maintain several pointers to a separate data section for each running instance of the application. The hInstance and hPrevInstance are actually pointers to such datasections. One of the reasons for this was so that the program needed to only do certain kinds of initialization once; if future instances needed that data, they could copy it into themselves from the previous instance (remember, no protected memory!) with the GetInstanceData function. In addition, it was a simple way of telling if you were already running; window classes, for instance, were registered once per program, not once per instance.
Of course in Win32, instances of a program are their own processes with their own address spaces, so you can't do the kinds of clever tricks you could in Win16 to save time and memory. And hPrevInstance is always NULL. Win16 programming is full of hacks like this that made sense in their day, but are counterproductive now, though their vestiges remain on in Win32.