You have at your disposal a large virtual address space and probably more physical memory than in the old days, too. With 32 bits of address space, you can address 4 gigabytes. Each application program on Windows NT has the lower 2 gigabytes of linear virtual address space at its disposal. You don't get quite all of it, of course. If you have a console application, the system will use 5.5 MB of that lower 2 gigabytes to permit you to view portions of the system that reside elsewhere. If you have a Windows application, that number rises to 9 MB. But these are small potatoes compared to 2 gigabytes, so think of yourself as owning it all.
If your application is being ported from another operating system or from an earlier version of Windows, you might have developed a special virtual memory scheme for your own private use. Get rid of it. Otherwise you will be paying the price of having two virtual memory systems operating at one time, and believe me, one is enough.
You should consider using memory mapped files under certain conditions. Do this if you are going to randomly access the file read-only or read-share write-exclusive. Shared writing to memory-mapped files from multiple processes requires quite a bit of internal system structure and does not work well if the file is remote, because you will have to manage your own remote synchronization. There are better ways to spend your time, because this problem is automatically solved by facilities in each of the various file systems.
For sequential file access, memory-mapped access is a bit faster but uses more memory than does access through the file system cache. And if you are going to access a file sequentially, be certain to tell that to the file system in the CreateFile call by setting FILE_FLAG_SEQUENTIAL_SCAN. (In general, use CreateFile instead of the obsolete OpenFile call.) This increases the size of the read-ahead by the cache manager. If, however, you are going to access the file randomly and sparsely, you definitely should use file mapping. You do this by first calling CreateFile to open the file, and then CreateFileMapping to place it directly into your address space. This is what Performance Monitor does when reading in log files, because sparse random access to a log file is common.
You should also get rid of your temporary files if you know their maximum size. You can map a large temporary space which is backed by the system paging files instead of by a pre-existing file. Simply pass 0xffffffff as the file handle to CreateFileMapping, and specify the size you need.
You can also create large tracts of space to play in with the VirtualAlloc call. This is space backed by the paging file(s), but because it has no name it is not sharable with another process, so it's a little different from CreateFileMapping. You can form some really large private data spaces backed by the paging file with this much address space, but it may not be wise to reserve disk space for all that area. You may need your application to run on machines that are short on disk space. There's no point in taking more than you need.
What you can do is tell the system how much you might need in the worst case, and have it reserve that amount of linear address space. Then you can commit only those pages which you actually need to use as you go along. The reserved virtual space will be contiguous, but disk space will only be obtained in the paging file for the committed bytes. To reserve memory, call VirtualAlloc specifying the MEM_RESERVE flag, and later you can commit the memory with another call to VirtualAlloc, specifying MEM_COMMIT.
One useful thing about the CreateFileMapping call that we alluded to above is you can share the memory section you create or map with other processes on the same computer. All they need to do is a CreateFileMapping on the same filename. This is a much faster way to share information between multiple processes than named pipes, RPC, or shared file access. For example, it is how Performance Monitor would prefer to get its data from extended objects. You might need a mutex to protect access to the shared section, but hey, we got those too, and they're priced at a bargain.