An additional reason appeared when I started researching the topic.
Apparently, Windows 10 no longer even creates the recovery partition during installation!
The entire WinRE is now stored on that same system reserved partition, which contains your window’s BCD!
The recovery partitions should only be present on Windows 10 installations which were either upgrades from a previous Windows version, or (as in my case) were installed within about 6 months after Windows 10 became available.

These instructions are also useful if you wish to increase the size of your system reserved partition – for example, if Windows 10 updates are failing because of that partition’s lack of free space.

WARNING: changing partition tables on your hard/solid-state disk may easily result in complete data loss!
Instructions below are provided as-is, to be used at your own risk. See full disclaimer on the About page.

WARNING: although it is also possible to merge the system reserved partition and windows 10 partition (so that the entire Windows 10 uses only 1 primary partition), I do not (and will not) offer instructions to do so. In fact, I recommend that you don’t merge the system reserved and windows 10 partitions.

Merging system reserved and recovery partitions, step by step.

1. First, we need a convenient partition manager; I have used a free MiniTool Partition Wizard, but other great free partition managers (like AOMEI Partition Assistant and I guess a few others) should be sufficient for us. Download and install one of those. It is impossible to use Window’s own Disk Manager for the steps below.
2. My starting state is this:

   [ 189MB free space ] [ system reserved, 100MB ] [ windows 10, 100GB ] [ recovery, 450MB ] [ free space ]

3. Your starting state may look a bit simpler, like this:

   [ system reserved, 100MB ] [ windows 10, 100GB ] [ recovery, 450MB ]

   Presence or absence of free space at the beginning or end of the disk should not make any difference (unless your windows partition has very little free space).

4. Our goal state is:

   [ system reserved, 900 MB ] [ windows, 100 GB ] [ free space ]

5. Create a full disk backup! Yes, I really did that. I can highly recommend booting into Clonezilla (or your Linux, if you dual-boot), and performing a full disk-to-image backup. If anything at all goes wrong – you should be able to completely restore your system to the previous functional state.
6. Verify that your full-disk backup can be restored (is readable/decompressible/whatever). Clonezilla has an option (enabled by default) to perform this check after disk imaging is complete – this was sufficient for me.
7. Verify that you have a functional WinRE: start Administrator CMD (or PowerShell), and run reagentc /info – it should tell you that WinRE is enabled, and also tell you that it’s using partition 3. I’d also strongly suggest that you create a separate bootable USB with WinRE – Windows 10 has its own tool to do so.
8. (optional) If you, like me, had some free space at the beginning of the disk, before the system reserved partition – then it makes sense to first extend the system reserved partition there. Use your partition manager to do so – either as a one-click Extend partition operation (and then select the free space upstream, all of it), or as a Resize partition to move the left edge of system reserved to disk’s beginning. Reboot. This worked flawlessly for me. If your Windows 10 does not boot anymore – try fixing boot using your bootable WinRE, or the WinRE on your disk. If that fails – restore your disk backup, and look for a different solution…
9. When merging system reserved and recovery partitions, one has to keep in mind the free space requirements of these two partitions (for UEFI, for MBR). They are a bit weird, so I picked 900 MB as the target size for system reserved; with this size, at least 320 MB have to be free on that partition after we are done. After merging the free space (189 MB) and the sysres partition (100 MB) I already had 289 MB, and needed to add (900-289=) 611 MB. Start your partition manager again, Extend system reserved partition using your Windows 10 partition, and reboot again. If there is no option to extend: first shrink the windows partition from the left edge by the calculated number of MB (611 in my case), then extended sysres partition into the freed space – and reboot. After this step, the disk should look like this:

   [ system reserved, 900 MB ] [ windows 10, ~100GB ] [ recovery, 450 MB ] [ free space]

10. Now we are going to move the WinRE from a dedicated partition to a sysres partition, in a few easy commands. Start Administrator CMD or PowerShell, check that your WinRE is still active: reagentc /info. Now disable it: reagentc /disable. Verify with another reagentc /info. If disabling failed, and you wish to have the WinRE functionality – do not proceed! I have no idea if proceeding after failure here would result in a functional WinRE. Do not reboot, keep the CMD/PowerShell open!
11. Delete the recovery partition, apply changes, do not reboot! (although it should actually be safe to…)
12. (possibly optional) Create an unformatted placeholder partition where your recovery partition used to be, to prevent Windows from creating it again when you re-enable WinRE. In my case, disk layout after this step is:

    [ system reserved, 900 MB ] [ windows 10, about 100 GB ] [ Unformatted primary partition ]

    Do not reboot.

13. Back to your elevated privileges CMD/PowerShell window: simply run reagentc /enable, and confirm with reagentc /info. As there is no other place to put WinRE now, reagentc should save it to the (now big enough) system reserved partition.
14. Delete the placeholder partition. Your final state should be similar to:

    [ system reserved, 900 MB ] [ Windows 10, ~100 GB ] [ free space ]

Congratulations, you have just successfully merged the system reserved and recovery partitions of Windows 10!

There are two major obstacles for a somewhat-dated Windows 7 when it sees modern hardware:

• USB 3.0
• SSDs and newer disk drives in general

Fortunately, both problems are easy to fix.
Just follow the steps below; skip steps 1 and 2 if you already have a bootable Win7 flash drive.

1. Obtain/buy/create the Windows 7 ISO image.
   On Linux, creating an ISO image is as easy as dd if=/dev/sr0 of=/path/to/image.iso – assuming that /dev/sr0 is your DVD reader.
2. Create a bootable Windows 7 installation flash drive.
   On Linux, WinUSB can handle this; on Windows, you can use Rufus, or Microsoft’s own tool for this.
3. To add USB 3.0 drivers to the Win7 on your flash drive, download and use this: Windows 7 USB 3.0 Creator Utility:
   1. Run the utility as Administrator.
   2. Depending on the speed of your USB stick, this may take up to 15 minutes.
   3. Wait for a message along the lines of Creation finished! or Upgrade finished.
4. The steps above fix the first obstacle: lack of USB 3.0 drivers in the Windows 7 installation image.
   Now we are going to preemptively fix the second obstacle: not recognizing modern HDDs/SSDs.
5. Go to your hardware manufacturer’s website and locate the (model-specific) SATA/storage driver.
   Using Dell’s hardware as an example:
   1. go to downloads.dell.com
   2. there, click Laptops (or Desktops), then find and click your hardware model
   3. you will see a list of drivers for that model; search for “serial-ata” or “storage”
   4. download the latest version of the driver that you have found (it would be intel storage technology in Dell’s example case)
6. Depending on the manufacturer, drivers may need to be extracted from the (self-extracting) archive. In the case of Dell’s drivers,
   1. launch the downloaded executable file
   2. it will usually present 2 options: Install and Extract; you should extract
7. In the downloaded (and, possibly, extracted) drivers folder locate Windows7-specific drivers folder, and simply copy that folder to the USB stick with your Win7 installation.
8. Be sure to remember what is the driver’s folder name – if Windows fails to see your SSD, you will need to manually browse for these drivers during installation.

That’s it!

Sources used:

• this video – or rather this one;
• Install Win7 to USB3.0 Computers Readme – also has information on other methods of injecting USB 3.0 drivers into windows USB stick.

1. From Windows itself: use Disk2vhd to create the .vhd image (e.g. NOVA.VHD).
2. (optional, requires VirtualBox) convert the VHD to VirtualBox-native VDI with VBoxManage clonehd NOVA.VHD nova.vdi --format VDI --variant Standard

There is an excellent, in-depth, well-argumented article by Geoff Chappell on the issue. Highly recommended in its entirety to those who want a complete understanding (additional side-reading and facts verification might be necessary).

A single citation to get you started:

There is already on the Internet and elsewhere an awful lot of rubbish to read about this question. Hardly any of it would be worth citing even if I didn’t want to spare the authors the embarrassment. A surprising number of people who claim some sort of attention as expert commentators would have you believe that using more than 4GB of memory is mathematically impossible for any 32-bit operating system because 2 to the power of 32 is 4G and a 32-bit register can’t form an address above 4GB. If nothing else, these experts don’t know enough history: 2 to the 16 is only 64K and yet the wealth of Microsoft is founded on a 16-bit operating system that from its very first version was designed to use 640KB of RAM plus other memory in a physical address space of 1MB. Some remember this history and add seemingly plausible qualifications that exceeding 4GB is possible only at the price of nasty hacks that require everyone—well, all programmers—to jump through hoops. Fortunately, Intel’s processors are a lot more advanced than the 8086 from all those years ago.

P.S. Unfortunately, patching the kernel won’t help make Windows XP see more than 4GB RAM: even though the kernel itself does support more RAM (with PAE), starting with SP2 the HAL was modified in a way prohibiting access to any RAM beyond 4GB. Patching may only be suggested to devoted geeks with Vista’s and 7′s.

Ideologically correct solution is offered by Panda software – a free Panda USB and AutoRun Vaccine. It can do two things for your Windows box:

1. with a single click disable auto-execution of programs from USB sticks and CDs/DVDs, and
2. with one more click – make the autorun.inf file on your pendrive inaccessible, so as to prevent infecting your USB stick with an “autorun.inf virus”.

Program does not require installation, but requires Administrator privileges. It supports FAT/FAT32 pendrives, but NTFS-enabled version is being tested and should be made available shortly.

Note, that if you perform step 2, re-enabling access to autorun.inf may require pendrive formatting. Also, after step 1 your favourite CDs and DVDs won’t start automatically anymore – but you will be able to start them manually.

And, of course, Linux users have nothing to worry about (yet).

running UNIX applications (via SUA, Subsystem for UNIX Applications) , which provides higher flexibility for Windows workstations.

Where is the world going?

And how soon will all the Windows users (not only Ultimate Users) benefit from the higher flexibility by running UNIX applications?

Warning: you proceed at your own risk. If you do not know what you are doing – please don’t

Download (original) French gpedit-pour-xp-home.zip.

Download English gpedit for windows xp home.zip (also in 7zip archive).

Here are instructions for manual MMC snap-in installation. Original French-version archive had a batch file which does installation automatically, which I also added to the English archive (gpedinst.bat). But you must manually verify that batch file fits your system before running it! It might be safer to follow the instructions manually.

• Put these files:
  

  appmgmts.dll
  appmgr.dll
  fde.dll
  fdeploy.dll
  gpedit.msc
  gpedit.dll
  gptext.dll

  into %SystemRoot%\system32 folder (most often it’s just c:\windows\system32)

• put these files:
  

  system.adm
  inetres.adm
  conf.adm

  into %SystemRoot%\system32\GroupPolicy\ADM\ (create if this folder doesn’t exist)

• finally, run these commands one by one in the CMD window:
  

  regsvr32 gpedit.dll
  regsvr32 fde.dll
  regsvr32 gptext.dll
  regsvr32 appmgr.dll
  regsvr32 fdeploy.dll

That should make gpedit.msc callable as Start -> Run -> gpedit.msc.

Other language versions of the necessary files can be retrieved from corresponding-language installations of WinXP Professional; English version can also be downloaded directly from Microsoft website ( e.g. here , or search for “Group Policy ADM Files” at microsoft.com). Also, you can extract necessary files from available Windows distributions: just don’t forget, that “filename.dl_” is a compressed version of “filename.dll”, and can be uncompressed by using XP-bundled extract command.

See also this comment for alternative gpedit installation (get the file from badongo first), and also this comment for one more explanation of manual installation.

Geeks corner:

1. a comprehensive list of the “Group Policy/User Configuration/Administrative Templates” settings in Windows XP Home Edition
2. an extremely comprehensive Excel sheet, which maps numerous *.adm-file options to their registry equivalents – Group Policy Settings Reference (PolicySettings.xls). This file is for Windows 2000, Windows XP, and Windows 2003

Disclaimer: I do not know if modifying (e.g. by adding gpedit) your WinXP HE is a violation of any EULAs. It’s your own responsibility to check this out and comply with any such regulations. Also, be advised that modifying any settings using gpedit.msc on WinXP HE may render some parts of the OS inoperable (in my opinion). You have been warned!

There’s also another one, but provides read-only support.

Topologilinux is a special linux flavour, which is especially fit for the newcomers to the *nix world. The motto of Topologilunux is ‘Running Linux inside Windows’ – and that is what it does. Even more – you can run it inside windows, or you can boot into it and work Linux-only – in both cases the system is the same.
Personally, I consider this kind of setup extremely useful for users who are strongly used to working in Windows (or just stuck with windows for too long), but at the same time are inclined to script a bit (be it bash, Perl, PHP or Python), to run server applications, write cross-platform programs, to test something or just play with software. With Topologilunux, it’s perfectly fine to work in DreamWeaver on your windows machine, and launch Topologilinux with apache+php+mysql to serve as a testing server – on that same machine. You can easily replicate the needed server config, and play with it the way you wouldn’t if that was the production server.

Or, in another scenario, you may launch Topologilinux to write the script you need for your data (for example, Bioconductor package for R statistics environment has many packages available only for *nix systems) without leaving your nearly perfectly set up windows environment; then, when you need to run that CPU-intensive you wrote, you can boot into real-mode Topologilunux, run your analysis, and get back to Windows

All of this is available without the need to re-partition your hard drive – Topologilinux fits into a single image file on your FAT32/NTFS drive of choice. Both installation and removal are very simple (common click-through), with a bit more effort in the networking part (sufficient documentation is available, if not with Topologilinux, then with coLinux).

The only problem I had with Topologilinux was BSOD (Blue Screen Of Death) every time I tried to launch Topologilinux from within Windows. The error was DRIVER_IRQL_NOT_LESS_OR_EQUAL. Searching for troubleshooting required some time and was not evident, so here is what fixed my problem.

The conflict seems to arise from the Data Execution Prevention (DEP) feature of the modern computers, which is intended to protect from the various ‘buffer overrun’-based exploits and hacks. By default, it is enabled for system files and services (equal to /noexecute=optin option in boot.ini). I tried setting it to ‘All files, except chosen below’, then adding colinux-daemon to exceptions, but that didn’t help either. The only option which helped was disabling DEP from boot.ini by adding ‘/noexecute=alwaysoff’ after the line identifying your Windows installation.

Here is a sample line from my boot.ini before modification:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”WinXP Pro” /fastdetect

and after modification:

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”WinXP Pro (DEP off)” /noexecute=alwaysoff /fastdetect

Hope this helps you.

Update: since I’ve moved to Debian, I’m no longer using Topologilinux.