Jump to content











Photo
- - - - -

Modifying Windows Product/License policies using Grub4Dos


  • Please log in to reply
21 replies to this topic

#1 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 08 January 2017 - 01:17 PM

Windows product policy contains a lot of useful settings.

 

By modifying the Kernel-NativeVHDBoot native VHD boot can be enabled on all unsupported versions of Windows 7.

 Native VHD Boot on unsupported versions of Windows 7

 

By modifying Kernel-WindowsMaxMemAllowedx86 and Kernel-MaxPhysicalPage to 16384 (from a lower value), 32-bit versions of Windows 7 can potentially access more than 4GB of RAM.

http://reboot.pro/to...iewer/?p=201389

http://reboot.pro/to...e-4#entry201388

 

Erwan built an excellent tool called ProductPolicy Viewer to view and Edit the Product Policy Settings. The discussion was first started here - http://reboot.pro/to...4dos/?p=193727 

 

A few facts about the Windows Product and License Policy

  1. The settings are stored in the registry at SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy
  2. The structure of these settings is not straightforward and is described at http://reboot.pro/to...dows-licensing/
  3. The product policy registry key cannot be modified on an online registry hive. The kernel protects it from modification. 
  4. Erwan's tool - modifies the product policy on an offline registry hive. The modified values have effect only on the first boot after the modification. On subsequent reboots, the modified settings are lost as the software protection policy restores them from Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\ SoftwareProtectionPlatform\tokens.dat .

One option to overcome this problem is to disable the Software Protection Service(sppsvc). However, this causes problems with Windows Activation, installation/uninstallation of Windows Updates etc

 

Other options include running Windows 7 in RAM, so the changes are not persisted. However not everybody runs Windows from RAM, so it's not feasible - http://reboot.pro/to...e-4#entry201388

 

Since Grub4dos can edit files using cat, I started investigating and did hex diff between an unmodified system hive and a system hive modified with ProductPolicy Viewer. I found the corresponding hex entries for Kernel-WindowsMaxMemAllowedx86, Kernel-MaxPhysicalPage and Kernel-NativeVHDBoot.

 

Using my rudimentary grub4dos skills I came up with the below working Grub4Dos entries

 

PAE Patch for Windows 7 Starter - Alternative to patching the kernel

title Windows 7 32 Bit Starter with PAE Patch
find --set-root --ignore-floppies --ignore-cd /Windows/System32/config/system
cat --locate=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x08 --number=1 --replace=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x40 /Windows/System32/config/system
echo Patched Kernel-WindowsMaxMemAllowedx86
cat --locate=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x10 --number=1 --replace=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x40 /Windows/System32/config/system
echo Patched Kernel-MaxPhysicalPage
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr
pause Press any key....

Find string will be different for other versions of Windows, the last hex value will change from \x08 to \x10.

\x08 corresponds to 2GB (0x0800 -> 16*16*8 )  while \x10 corresponds to 4GB (0x1000-> 16*16*16)

 

Win7Starter8GB.png

 

Native VHD Patch for WIndows 7 Starter in a VHD

title Windows 7 Starter with NativeVHD Patch
find --set-root --ignore-floppies /Win7Starter.vhd
map /Win7Starter.vhd (hd0)
map --hook
cat --locate=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x00 --number=1 --replace=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x01 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-NativeVHDBoot
map --unhook
map --unmap=0:0xff
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr

 

Native VHD and PAE patch Windows 7 Starter 32 bit in a VHD

 

title Windows 7 Starter 32-bit with NativeVHD and PAEPatch
find --set-root --ignore-floppies /Win7Starter.vhd
map /Win7Starter.vhd (hd0)
map --hook
cat --locate=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x00 --number=1 --replace=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x01 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-NativeVHDBoot
cat --locate=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x08 --number=1 --replace=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x40 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-WindowsMaxMemAllowedx86
cat --locate=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x10 --number=1 --replace=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x40 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-MaxPhysicalPage
map --unhook
map --unmap=0:0xff
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr

The menu entries are not entirely bug-free. Since the cat command is restricted to 16 chars, I cannot be very specific about the entries I am finding and replacing.

 

The entries patching the files inside VHD are very slow and don't work if the files are already patched - the menu just gets stuck. I am not sure why this is happening.

 

Let me know your thoughts, feedbacks, suggestions etc.



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 January 2017 - 01:29 PM

What is the meaning of "map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)"? :dubbio:

 

As a generic rule, unlike what a lot of people seems to believe, it is IMNSHO much easier (and less prone to issues) to write grub4dos commands in a .g4b batch file, that is then invoked in the menu.lst.

This way the menu.lst is kept "simple" and "human readable". 

 

As well in a batch file, since you can use loops and variables, you can - if needed - workaround the length limit of cat, as you can look for the address (locate without replace) of a given string, then "probe" the following 16 bytes, etc. using skip.

 

As a side note, why don't you use the bootmgr inside the vhd (i.e. (hd0,0)/bootmgr instead of the find --set-root )?

 

 

:duff:

Wonko



#3 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 08 January 2017 - 02:57 PM

What is the meaning of "map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)"? :dubbio:

 

 

Removed it. I had copied it by mistake from Wimb's menu.lst for booting Firadisk based vhd

 

 

 

As a side note, why don't you use the bootmgr inside the vhd (i.e. (hd0,0)/bootmgr instead of the find --set-root )?

 

 

:duff:

Wonko

 

I am not sure if that will work with native VHD boot.

 

The BCD inside the VHD looks like this

BCDInsideVHD.png

 

The BCD on the main hardisk, which contains the entry to load the VHD looks like this

BCDonDisk.png

 

So I invoke the bootmgr on the harddisk rather than the bootmgr inside the VHD.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 January 2017 - 04:02 PM

Yep, it has to be tested, but it should be possible to have the one inside the vhd to work just fine.  of course it needs to be modified with a .vhd entry similar to the one on hard disk.

Of course you will need to actually map the vhd in grub4dos, but since you have to map it anyway to patch it, you would avoid the unmapping.

 

Since you are using the "native" booting the grub4dos map will simply vanish as soon as the HAL kicks in, the "switch" should however happen right when the booting OS already can access the .vhd through its native driver.

 

:duff:

Wonko



#5 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 08 January 2017 - 05:57 PM

Hi,

 

This is a very interesting approach.

 

Thus, a few question :

-how confident are you that you will systematically find the same pattern in the hive file on other systems?

-how confident are you that you will not modify other parts of the hive file?

-is not the software protection service kicking in anyway a few mns after you have booted since the reg key will not match tokens.dat anymore? question remains, does the service monitor for change introduced by the user in the session or does it regurlarly compare hive vs tokens.dat?

 

Modifying the registry early in the boot process is definitely an interesting concept.

 

Regards,

Erwan



#6 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 08 January 2017 - 06:26 PM

I am pretty confident about the pattern. however if the same pattern appears multiple times in the hive,then the code replaces the first occurence. So we need a better way to make sure we are modifying the right part of the hive.

This is no different from modifying the hive when it's offline. So everytime it has to be booted using the grub4dos menu. The software protection service is a delayed start service,so once it's starts,I assume it will immediately restore it.

#7 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 08 January 2017 - 06:38 PM

Ok I get it :

 

So the idea is modify the registry early in the booting process,

boot & and benefit from extra features (vhdboot, memory, ...), 

let the software protection do its job (restore registry) while still enjoying extra features (since we have booted with these features).

 

As a side note, for sometimes, I have been willing to develop a native command line registry editor (similar to reg.exe).

 

By native I mean using native ntdll.dll functions only and therefore launched before the win32 subsystem kicks in (i.e during the kernel initialization).

A bit similar to autochk.exe checking the filesystem.

 

There a few nativent "hello world" out there and the native api's are rather well documented so "in theory", it should be possible to develop a native reg.exe allowing one to modify the registry in a safe and friendly enough way (as opposed to patching bytes in the system hive).

 

The native binaries are called from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\bootexecute and cannot be executed in a win32 environement (but only in native world).



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 January 2017 - 06:54 PM

Ok I get it :

 

So the idea is modify the registry early in the booting process,

boot & and benefit from extra features (vhdboot, memory, ...), 

let the software protection do its job (restore registry) while still enjoying extra features (since we have booted with these features).

 

As a side note, for sometimes, I have been willing to develop a native command line registry editor (similar to reg.exe).

 

By native I mean using native ntdll.dll functions only and therefore launched before the win32 subsystem kicks in (i.e during the kernel initialization).

A bit similar to autochk.exe checking the filesystem.

 

There a few nativent "hello world" out there and the native api's are rather well documented so "in theory", it should be possible to develop a native reg.exe allowing one to modify the registry in a safe and friendly enough way (as opposed to patching bytes in the system hive).

 

The native binaries are called from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\bootexecute and cannot be executed in a win32 environement (but only in native world).

Actually there is also already a "native" Registry tool, see:

http://reboot.pro/to...egistry-editor/
https://www.codeproj...registry-editor

 

You could take from where Dan Madden left.

 

BUT - long before that - it would make more sense (to me at least) see if hivexsh or libreg can be made to run as a grub4dos program, or - even better - add the Registry as a filesystem to grub4dos, as was hinted here:
http://reboot.pro/to...ch-using-linux/

 

:duff:

Wonko:



#9 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 08 January 2017 - 06:57 PM

Yes, that will definitely be useful. I would interested in such a native reg tool that can be used to modify the registry.
Let us know if you can develop such a tool. I am willing to contribute as well.

#10 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 08 January 2017 - 07:29 PM

Actually there is also already a "native" Registry tool, see:

http://reboot.pro/to...egistry-editor/
https://www.codeproj...registry-editor

 

You could take from where Dan Madden left.

 

BUT - long before that - it would make more sense (to me at least) see if hivexsh or libreg can be made to run as a grub4dos program, or - even better - add the Registry as a filesystem to grub4dos, as was hinted here:
http://reboot.pro/to...ch-using-linux/

 

:duff:

Wonko:

 

The Dan Maden example was definitely on my radar.

Thus it is meant for a win32 environement, i need to adapt it to a kernel environement.

 

Registry as a filesystem is a bit of the "graal" and has been mentionned a few times already on this forum :)



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 January 2017 - 11:21 AM

Registry as a filesystem is a bit of the "graal" and has been mentionned a few times already on this forum :)

Also:
https://github.com/jbruchon/winregfs

:duff:
Wonko

#12 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 15 January 2017 - 05:31 PM

Yes, that will definitely be useful. I would interested in such a native reg tool that can be used to modify the registry.
Let us know if you can develop such a tool. I am willing to contribute as well.

 

See here.



#13 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 27 January 2017 - 07:26 PM

Ok I get it :

 

So the idea is modify the registry early in the booting process,

boot & and benefit from extra features (vhdboot, memory, ...), 

let the software protection do its job (restore registry) while still enjoying extra features (since we have booted with these features).

 

As a side note, for sometimes, I have been willing to develop a native command line registry editor (similar to reg.exe).

 

By native I mean using native ntdll.dll functions only and therefore launched before the win32 subsystem kicks in (i.e during the kernel initialization).

A bit similar to autochk.exe checking the filesystem.

 

There a few nativent "hello world" out there and the native api's are rather well documented so "in theory", it should be possible to develop a native reg.exe allowing one to modify the registry in a safe and friendly enough way (as opposed to patching bytes in the system hive).

 

The native binaries are called from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\bootexecute and cannot be executed in a win32 environement (but only in native world).

 

Looks like its not possible to modify SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy from the native world (i.e bootexecute)

I wrote a NativeProgram ( see attached zip for source and binary) to modify the productpolicy to enable VHD boot, but it does not work. Just to confirm that the tool actually is able to write the correct entries into the registry, the code also makes a copy into a new value called  ProductPolite.

 

I mounted the VHD and modified the registry to bootexecute my NativeApp . Upon restarting into the VHD, the bootexecute runs my native app, but I still get the "Booting from a VHD is not supported" error. Then when I load the system hive offline, I notice that the changes written to ProductPolicy have not been persisted, i.e, NativeVHDBoot is still 0. The copy which I made into ProductPolite has the modified value for NativeVHDBoot( which I can confirm by visually inspecting the hex data in regedit )

 

As per this post  https://forum.xda-de...28&postcount=14 the protection on that key is removed only in setup mode.(which required multiple reboots)

 

The code is based on Joakim's NativeRegMod, my c skills are a bit rusty and code can be improved.

Attached Files



#14 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 28 January 2017 - 10:51 AM

Looks like its not possible to modify SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy from the native world (i.e bootexecute)

I wrote a NativeProgram ( see attached zip for source and binary) to modify the productpolicy to enable VHD boot, but it does not work. Just to confirm that the tool actually is able to write the correct entries into the registry, the code also makes a copy into a new value called  ProductPolite.

 

I mounted the VHD and modified the registry to bootexecute my NativeApp . Upon restarting into the VHD, the bootexecute runs my native app, but I still get the "Booting from a VHD is not supported" error. Then when I load the system hive offline, I notice that the changes written to ProductPolicy have not been persisted, i.e, NativeVHDBoot is still 0. The copy which I made into ProductPolite has the modified value for NativeVHDBoot( which I can confirm by visually inspecting the hex data in regedit )

 

As per this post  https://forum.xda-de...28&postcount=14 the protection on that key is removed only in setup mode.(which required multiple reboots)

 

The code is based on Joakim's NativeRegMod, my c skills are a bit rusty and code can be improved.

 

I have another possible analysis of this situation as I dont aggree with "not possible to modify SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy from the native world".

 

The sppsvc is already loaded at this point (when nativereg kicks in) and doing its job i.e immediately revert back changes on this key.

 

Remember that "native world" is actually user mode which means you can modify the system registry but a whole bunch of services and drivers are already loaded.

 

As for vhdboot, it could very well be that the driver is loaded way before nativereg kicks in and therefore uses the default vhdboot setting (i.e disabled).



#15 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 28 January 2017 - 01:28 PM

The sppsvc service is a delayed start service. It is not loaded at the point of time.

That particular registry key is protected by something else. Even after disabling the sppsvc service, the modifications to that registry are reverted. Thats the reason I had asked the question here - http://reboot.pro/to...wer/?p=201350. 

There is something special about sppsvc that allows it bypass the protection and make changes to that key. 

 

The folks over at MDL - https://forums.mydig...t-Policy-Editorhave discovered that the protection is disabled if you reboot in SetupMode = 1;

 

 

If you decided to modify ProductPolicy I suggest :

1) Disable sppsvc
2) Reboot in SetupMode
3) Change needed values
4) Save your changed policy to a file
5) Reboot in normal mode


#16 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 28 January 2017 - 06:10 PM

The sppsvc service is a delayed start service. It is not loaded at the point of time.

That particular registry key is protected by something else. Even after disabling the sppsvc service, the modifications to that registry are reverted. Thats the reason I had asked the question here - http://reboot.pro/to...wer/?p=201350. 

There is something special about sppsvc that allows it bypass the protection and make changes to that key. 

 

The folks over at MDL - https://forums.mydig...t-Policy-Editorhave discovered that the protection is disabled if you reboot in SetupMode = 1;

 

ok got it.

 

So it is either modify the key offline (thru winpe and product policy viewer for instance) OR reboot in setup mode and use regedit (or product policy viewer with mode online when available).

 

I guess MS has protected this key in kernel mode in a (failed) attemp to block windows activation proggies out there.

 

In user mode, I guess sppsvc sole function is to monitor the key and revert it back to its default value.

 

Still if you modify this key offline (or in setup mode), you can "fool" windows in enabling extra features even if sppsvc will revert back the key later on.

 

The function is NtQueryLicenseValue which, being part of ntdll, can be called either in kernel mode or user mode.

 

This ntdll function is also called by SLGetWindowsInformation which is part of sfc.dll (a dll part of the software protection mechanism).



#17 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 29 January 2017 - 01:16 PM

The other observation I made is that it is possible to modify the controlset002 ( if its not the current control set ) using the native app i built. It might be possible to do some switching every reboot, so that the modified values are picked up.( although I am not sure of the consequences as the controlset002 is used in last known good configuration mode )

 

Currently, Grub4Dos (as outlined in the first post) can be used to modify the product policy on MBR based Windows systems to enable certain features. 

I am not sure if a similar approach can be used in UEFI based Windows. Maybe Grub2 with grub4dos combo ?



#18 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 29 January 2017 - 01:22 PM

Another approach might be to perform this task from a driver and therefore from kernel mode.

 

NativeReg (or any binary called thru bootexecute) comes late in the boot process (already in user mode).

 

A code built for "native" uage is more or less ready to be compiled as a driver for kernel mode.



#19 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 29 January 2017 - 01:48 PM

Interesting. I am newbie when it comes to Windows coding.

Any good tutorials that I can read and get started with porting my code to a driver ?

 

Would this tutorial be a good starting point ? https://www.codeproj...river-Tutorial 

 

 

 

BTW is Wonko on a holiday? I was hoping he would have some ideas too.



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 February 2017 - 10:45 AM

BTW is Wonko on a holiday? I was hoping he would have some ideas too.

Yes. (he was on holiday).

And Yes, lot of them ideas, very few kids willing to play with me, though :(.

 

Something that I always thought about (but found noone willing to experiment with) is/was that of using (extensively) the hardlinks (and the symbolic links where applicable) capabilities of NTFS to create a "Parasite PE" or mini-system of some kind.

 

:duff:

Wonko



#21 agni

agni

    Frequent Member

  • Tutorial Writer
  • 270 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted 03 February 2017 - 02:13 PM

Welcome back. Hope you had a good holiday.

 

Can you give some more details as to how hardlinks or sym links can be used to create a parasite PE or mini system ?

 

BTW in the meantime I have started tinkering with drivers( based on Erwan;s idea ). I got hold of firadisk source code and modified it do some stuff and it crashed with BSOD - page fault in nonpaged area. I'll post here if I make any progress.



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 03 February 2017 - 04:28 PM

Welcome back. Hope you had a good holiday.

 

Can you give some more details as to how hardlinks or sym links can be used to create a parasite PE or mini system ?

 

BTW in the meantime I have started tinkering with drivers( based on Erwan;s idea ). I got hold of firadisk source code and modified it do some stuff and it crashed with BSOD - page fault in nonpaged area. I'll post here if I make any progress.

Think of this (I am talking here of PE 1.x or WinNT 5.x only because I am more familiar with them, but the matter is possibly even simplified in later OS :unsure:).

The typical installed XP is:

C:\Windows\...

 

But with a few tweaks it is perfectly possible to install it in (say) C:\mini_XP\... <- the Mini_XP name has been chosen only because it is 7 letters like "windows")

 

As a matter of fact if you install two times a Windows XP on the same disk, but in two different directories you will have two separate "main" folders (C:\Windows and C:\mini_XP\) and a handful of "common directories":

"Documents and Settings", "program files", "Recycled" and possibly "temp" and "System Volume Information".

 

but it is also possible (at least it was possible up to 2K, as I did it at the time) move the "Documents and settings" to a subfolder of C:\mini_XP (in that experiment the folders were \Win2K and \NT911 but the essence remains the same, at the time I had a Win2K downsized to around 80 Mb, and a normally (heavily nlited) XP would be something like 125 Mb, while a not-so-minimal miniXP or XPCLI  could be around 50-70 Mb or so.

 

Now what happens if you install a minimal XP, let's say the XPCLI (please read as the MiniXP by Misty, but with the "normal" Winlogon) to \mini_XP\ ?

 

You will have any number of duplicated files in C:\mini_XP that are already present in the "normal" C:\Windows\ + a small number of files that are actually different (like the Registry and other similar configuration files).

 

And you can normally boot the one (or the other) set of files choosing in BOOT.INI.

 

Nothing prevents you from replacing each and every file in C:\mini_XP\ that is identical\unchanged with a hardlink to the corresponding one in C:\Windows\ as the hardlink mechanism is "embedded" in the NTFS filesystem, while possibly (I presume, and this needs to be verified) some entire sub-folders in C:\Mini_XP that "enter the game late enough" may even be softlinked to the corresponding ones in C:\Windows\.

 

Now, what prevents from:

1) copying the Registry backing files from C:\Windows\system32\config to C:\mini_XP\system32\config

2) replace unconditionally all occurrences of C:\Windows to C:\mini_XP

3) further replace (if needed or simply wanted for safety) the Documents and Settings path to a subpath of C:\mini_XP

4) further modify (if needed) another few Registry hives/key to reflect the path change

5) further modify (trimming the unneeded parts) the Registry to compact it

6) create a hardlink (or where applicable a softlink for subdirectories) to the needed files

 

In theory *nothing*, what has to be seen is the exact list of the needed hardlinks and the small changes needed in the Registry (as an example changing the shell from explorer to cmd.exe).

 

How long will it take to create this (the first time)?

 

I would guess a few minutes (not much more than the time needed to boot a BartPE from external media).

 

How fast will it be when booting?

My (educated) guess is that It will be almost instant, as the XPCLI or MiniXP are normally, i.e. much, much faster than loading Explorer and all the related crap, even when using the "normal" Winlogon)

 

How much space will it take on disk?

Almost nothing, actually only the space of a (optionally trimmed down/compacted) Registry + that of a few configuration files.

 

Same considerations go for a PE, after all a PE 1.x is nothing but a modification of the setup/install (hence most of the files are the same) and I believe starting with PE 2.x, the similarities between the setup/install and the installed system are even more, and hardlinks are already extensively used (in the WinSXS madness).

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users