memory leak detection in MSVC

Keep losing that link - here it is.

Windows backup and MediaID.bin

Whoever thought it would be a good idea to make Windows backup dependent on a small MediaId.bin file residing on the backup target, outside of the actual backup directory, oughta get fired.

So, let's say you're using a samba drive as your backup destination, where there already exists a bunch of directories. Windows will create its own WindowsImageBackup directory in there, and that's fine.

Then, a few month later, you're cleaning up the root of your backup directory, and seeing this small MediaID.bin, which doesn't seem to serve any purpose (if it's that small, it can't be that important - plus all it really contains is a 16 bytes payload).

Bad move: now NONE of your backup archives will work.

If you need a unique ID to identify that a backup file is legitimate, how about you add it to the backup file itself instead of creating an extra MediaID.bin, outside of the backup directory, that screams "delete me"?

Virtual Store, Windows 7 and HyperTerminal

Let's do things in order then.

1. In Windows 7 (I think it started with Vista), Microsoft locked down the ability for executables to write into system directories like C:\Windows, C:\Program Files, etc., unless they run as admin. This is probably a good thing.
   
2. However, backward compatibility tells us that there are plenty of programs that want to store settings or write files into their installation directory, which is most likely located in C:\Program Files (x86)
   
3. To avert this issue, Microsoft created the Virtual Store directory, which is located in C:\Users\myuser\AppData\Local\VirtualStore\ which the system uses for write access to restricted directories by overlaying it into system calls. For instance, let's say a copy of XP's HyperTerminal is installed on Windows 7 x64 into C:\Program Files (x86)\HyperTerminal\ with an HT session file called mysession.ht residing in the same directory, with this session file having been previously created and installed into C:\Program Files (x86)\HyperTerminal\ as admin. Having been developed up to XP (and yanked on later versions - more about this later), HyperTerminal saw no qualms about updating session files that reside in C:\Program Files (x86)\HyperTerminal\. And HyperTerminal needs to update your session file, whenever you exit the program, to update the terminal buffer log and other things, so it needs to write the session file every time it is used. What transparently happens the first time HT tries to update the session file is:
   
   1. An exact duplicate of mysession.ht is created as C:\Users\myuser\AppData\Local\VirtualStore\Program Files (x86)\HyperTerminal\mysession.ht, to which "myuser" has R/W access.
   2. On subsequent access from HT, this is the file that is being read and written, the original file from C:\Program Files (x86)\HyperTerminal\mysession.ht being left completely untouched from how it was when first copied there.
   In essence this means that there exists differing duplicates of the same file on your system, which, if you are using programs that have not been updated for Win7/Vista, is something you want to be aware of. For instance, in case you spent a lot of time creating conf/settings files in an application, and thought that a backup of the C:\Program Files (x86)\Some App\ would be enough, you might want to reconsider. This can be quite important if you want to back up application settings (IDA Pro comes to mind) as any app that was designed to store data in C:\Program Files\ will effectively store it in the Virtual Store, and simply backing up the app dir won't be enough.
   
4. What does the above has to do with HyperTerminal then? Well, HyperTerminal was yanked from Vista and Win7, which is bad news if you're working with embedded devices, and say, want to transfer data using a serial console through X/Y/Zmodem... The thing is, the HyperTerminal files from XP work just fine on Win7 (even on Win7 64 bit), but they have a few limitations:
   • if you place your HT session file into a different directory than the one where HT is installed, you will have trouble opening it through a shortcut, and will get prompted about creating or opening a session file every time you run HT. Of course, this constant nagging about creating session files gets old really fast.
   • you cannot change the default startup directory to something you have R/W access to without HT getting into other issues.
   • if you receive data through X\Y\Zmodem and didn't change the directory, it'll end up in the Virtual Store by default, which is why you might want to know where exactly that directory is located.

As a bonus, if you have an XP machine available, here are the files you want to copy to reinstate HyperTerminal in Windows Vista/7:

• C:\Program Files\Windows NT\hypertrm.exe
• C:\Program Files\Windows NT\htrn_jis.dll
• C:\Windows\System32\hypertrm.dll
• C:\Windows\System32\hticons.dll

Copy all those into  C:\Program Files (x86)\HyperTerminal\ and you should be good. And yes, one could solve the Virtual Store problem by installing all these files somewhere other than Program Files, but some people might want to keep their system organized.