How about hierarchical structure of saved info?

Automatical Extensibility compatibility is right feature and need
of update programs,
that is advice of "named" ini strings over old MFC "just effective" serialize() (not stable for possible errors also), now not very need over better structure(! -that's it.) and reliability(!) -(how about it in your code?),(not makes you kicked 'after')
but if you want to save hierarchical structure into file
what is the solution except XML?
- features need To make it universal saving solution.

Use a very large MMF

Hi Zhefu,
It is my understanding that you can allocate a very large MMF without it taking up any more disk space of memory than is actually being used at any point in time. Simple tests I've done indicate this is correct. This means you can say allocate a 1G MMF and not worry about having to resize it.

You can also resize an MMF on the fly, however depending on the version of Windows you are using and possibly other things the base address can and will change. If the MMF stores pointers then you would need to adjust them if this resizing technique is used.

About 0xFEFF(A BOM of Unicode)

The character 0xFEFF is the Byte Order Mask(BOM) of Unicode which serves to indicate the endianness of a sequence of bytes,its byte-swapped BOM(BSBOM) 0xFFFE is defined to never be a valid Unicode character.

When you convert some Unicode characters in memory into a sequence of bytes for storage (or transmission),it is a good idea to put an BOM(0xFEFF) as the first two bytes of the file.

In the little endian(LE) machine architectures(such as Intel x86 CPU),it will be saved as:
"FF FE 41 00 42 00 43 00"
But in the big endian(BE) platforms(Sun Solaris,MAC PowerPC CPU),it will be saved as:
"FE FF 00 41 00 42 00 43"
So you can check the first two bytes of an unicode(UTF-16) file to establish its endianness.

You can use your NotePad open a text file,save it as "Unicode"(LE) and "Unicode Big endian",you will find the difference by comparing them with UltraEdit or other HexEditor.