You can do it without a manifest too, it involves calling "CreateActCtxA" and "ActivateActCtx" with the appropriate Activation Context object. Manifest file is much easier.
As well as information about side by side assemblies (ie: library versions), a Windows manifest file has various settings and a declaration of compatible versions of Windows that affect Windows' handling of the app, such as whether it can handle paths over MAX_PATH, if it is hi-dpi aware, or if it knows about themed controls.
If an EXE doesn't have a manifest file, Windows assumes that it's ancient, so it falls back to conservative defaults like ye olde USER controls to try and avoid breaking it.
While MSDN is a bit impractical to browse (there's simply so much stuff in there) it's usually the best place to go to for documentation when doing Windows dev.
The magic numbers (hashes and UUIDs) sort of make sense because there's a slightly adversarial interaction between developers and Microsoft. If you just had a compatibleWindowsMin and compatibleWindowsMax field with version numbers, people would just go ahead and put "9999" in the max field, and then OS upgrades break applications again. By using UUIDs instead, an application developer can't intentionally or unintentionally declare compatibility with unreleased Windows versions.