Creating a Full-Blown Compatibility Layer.

[TrevMUN]

What other modifications did you make to your XP install, Dibya? Maybe the results can be replicated if there's some prerequisite tweaks to be made.

[Dibya]

8 hours ago, TrevMUN said:

What other modifications did you make to your XP install, Dibya? Maybe the results can be replicated if there's some prerequisite tweaks to be made.

Well Replacing lots of function in hal/kernel 

[NT Five]

On 04/05/2017 at 7:08 AM, Dibya said:

I want to know what more can be modded to make XP more lightning fast ! (System core changes ) . Itself XP is lightning fast but nothing wrong in having more .

Running XP (the whole C drive) in RAM makes it much faster. RAM disks are volatile/non-persistent so all changes to the C drive are "forgotten" after reboot, and the system stays "freshly installed" virtually forever.

My machine boots a 700 MB image file that contains a heavily customised nlited XP SP3 system in RAM disk mode using the free WinVBlock driver. Some profile folders like the desktop are residing on other partitions, but basicly the whole C drive lives in RAM.

When I need to install apps or modify system settings I boot up in File disk (persistent) mode in order to save the changes I make to the system. (changes are written directly to the image file in this mode)

Using RAM disk my ultra slow underpowered 2010 netbook feels a lot snappier and malware can not set up camp because a simple reboot flushes all changes made to the C drive.

I'm always running as admin, always months behind on security updates and never had problems with malware infections since I use this system (for 8 years now!). No antivirus installed, but using anti-executables and sandboxie for enhanced security. Sandboxie's sandbox folder contents; Pale Moon browser and The Bat email client (all running sandboxed in RAM)

No need to use a third party RAM disk driver when using image sizes <470 MB. XP's ramdisk.sys driver works just fine. Only needs a registry entry modification to make the driver start at boot time. There is a check in ntldr that stops bigger images from loading. If someone patches ntldr 2GB+ images will be no problem at all.

I think RAM disks and image files are the way to go if one wants enhanced performance, stability and security. Personally I will never go back to a conventional Windows installation...

Edited April 11, 2017 by NT Five

[jaclaz]

Well, just for the record a related thread with some actual info for the Registry needed modification and the  patch to NTLDR (reboot.pro is half down right now) via Wayback Machine:

https://web.archive.org/web/20170324081949/http://reboot.pro/topic/9474-busting-the-myth-about-ramdisksys-xp2003/

but WinvBlock is still a "better" solution IMHO.

To have a "tamper proof" system is also possible to use the ETBOOT project, and run XP from CD (JFYI):

https://web.archive.org/web/20170224121218/http://reboot.pro/topic/3890-project-etboot/
 

https://web.archive.org/web/20150401052002/http://erwan.labalec.fr/ETBoot/
 

jaclaz

[NT Five]

On 04/12/2017 at 10:15 AM, jaclaz said:

[...] but WinvBlock is still a "better" solution IMHO.

To have a "tamper proof" system is also possible to use the ETBOOT project, and run XP from CD (JFYI):

https://web.archive.org/web/20170224121218/http://reboot.pro/topic/3890-project-etboot/
 

https://web.archive.org/web/20150401052002/http://erwan.labalec.fr/ETBoot/

WinvBlock has a severe limitation that makes it impossible to create a "tamper proof" system with TrueCrypt/VeraCrypt. It doesn't want to play nice with TrueCrypt's pre-boot authentication in RAM disk mode, and just hangs on boot...

ETBoot is a nice idea but my machines don't have CD/DVD drives and I've found a better option to "tamper proof" my system.

At the moment my bootable images are stored on a seperate partition that is unmounted when XP reaches the desktop. In theory malware could find a way to break out of the sandbox and also bypass my anti-executable software (very unlikely, but you never know...), and mount the partition behind my back to infect my bootable images...

I found a rather elegant solution to prevent this but this method only works with the combo ramdisk.sys and ntldr.

Here is the trick (mini tutorial) ;

Slim down your XP installation to 470 MB or less. Make a bootable image file of your system with IMG_XP or a similar program. Apply the registry patch for ramdisk.sys and install the TrueCrypt driver. Test the image on your PC and make sure it boots fine using ramdisk.sys.

Now you can install an nLited Windows XP in Microsoft Virtual PC on a 2GB virtual hard drive. (Be sure you create a flat vhd image or you will be in trouble later)

Install TrueCrypt and encrypt the whole system drive using a strong password. TrueCrypt will demand we create a rescue disk ISO image. Your virtual machine needs a secondary hard drive to store the ISO file TrueCrypt will generate. You will also need it to store a copy of the bootable image file you crafted.

When TrueCrypt is finished encrypting you reboot the virtual machine and you enter your password. When you get back to the desktop you copy the bootable image file to the root of the virtual C drive and also add a second entry in its boot.ini that instructs ntldr to boot this image using ramdisk.sys.

So now you've got two Windows installations on your encrypted virtual disk. One regular system, bootable in Virtual PC, and another one in the image file, bootable on your real PC in RAM disk mode.

Switch off Virtual PC and copy it's virtual disk (the now encrypted VHD container) and the TrueCrypt rescue disk ISO file to the boot partition of your PC.

Use Grub4DOS to map the images and to boot from the TC rescue disk. Enter your password and your machine will decrypt the outer container and load the inner image file into RAM.

Now here is the magic;

Once you get to the desktop you open XP's disk management and you will see that there is no C partition there. The whole drive is missing but it is still accessible in explorer and XP runs just fine. So what the hell has happened here ?

During boot the contents of the bootable image file that was sitting in the encrypted VHD container loaded into RAM, but somewhere in this process the mapping of the outer VHD file got lost !

This is not a bug, it's a feature !

It means that once booted, no one can access, touch, delete, corrupt or infect the RAM disk source file without mounting it with TrueCrypt and entering the password... and you can't mount image files directly with TrueCrypt (it can only mount "real" disks), so there is absolutely no way malware or even you can access the source file when the system is running.

The only "normal" way to modify the contents of the inner image file is to fire up Virtual PC, attach the VHD file, and boot into Windows in the virtual machine in order to decrypt the VHD container, and if you are really paranoid you can even get rid of this "back door". The only thing you have to do to close that door forever is to delete the first entry in boot.ini, to save the file and to switch off the virtual machine.

Now we can only modify the contents of the VHD container if we attach it as a secondary drive in VPC and select the "Decryption without pre-boot authentication" in the TrueCrypt menu, but we still have to enter the password before we can get access.

That's pretty good security, huh ?

Using this method we can delete the "WINDOWS", the "Documents and Settings" and the "Program Files" folders, and use the space for something else like a second disk image.

This trick is only feasible with ntldr and ramdisk.sys and that is why I would like to patch ntldr in order to be able to break the 470 MB limit...

Third party drivers are nice but they won't be able to pull this trick off, and don't you folks think it would be sexier if someone patches ntldr so the native Microsoft RAM disk driver will be capable of loading 2 or 3 gig images ?

Edited April 14, 2017 by NT Five
Added some more information and made corrections

[NT Five]

On 02/16/2017 at 4:15 PM, Dibya said:

You can use gpt in xp by replacing disk.sys from srv2k3 . Need some proper supporting files to ensure stability.

That sounds very interesting!

Would you mind explaining how to do this ?

Maybe it's a good idea to add this to your Extended XP project together with the 128 GB RAM patch...

[NT Five]

Does anyone know how to patch XP's disk management so it creates NT6 style partitions ?

Probably quite easy to patch....

[jaclaz]

16 hours ago, NT Five said:

 

This trick is only feasible with ntldr and ramdisk.sys and that is why I would like to patch ntldr in order to be able to break the 470 MB limit...

Third party drivers are nice but they won't be able to pull this trick off, and don't you folks think it would be sexier if someone patches ntldr so the native Microsoft RAM disk driver will be capable of loading 2 or 3 gig images ?

I don't get it. This is what I just posted a link to, it has already been done some 8 years ago.

Still, it remains an unsupported, not entirely "stable" or particularly "tested" on many machines.

jaclaz

 

[98SE]

On Wednesday, April 05, 2017 at 6:36 AM, Dibya said:

Sub System ver to 5.1

Os ver to 5.1

Test in VM no guarantee

Dibya have you tried incorporating files from Windows 2K Server 32bit into Windows XP SP3?

I believe it can do 64GB max instead of 3.2GB.

This would be more useful as we are at 64GB max on consumer motherboards.

Also when running Firefox there seems to be a 1.5GB limit when the program starts to freeze/stall and crash.  Any ideas of how this can be fixed?  I think it has something to do with an XP limit.

[Dibya]

17 hours ago, 98SE said:

Dibya have you tried incorporating files from Windows 2K Server 32bit into Windows XP SP3?

I believe it can do 64GB max instead of 3.2GB.

This would be more useful as we are at 64GB max on consumer motherboards.

Also when running Firefox there seems to be a 1.5GB limit when the program starts to freeze/stall and crash.  Any ideas of how this can be fixed?  I think it has something to do with an XP limit.

I have ram patch upto 128Gb

My games use ram beyond 3gigs 

[98SE]

21 hours ago, Dibya said:

I have ram patch upto 128Gb

My games use ram beyond 3gigs 

Dibya, Where can I get this patch you did?  How much RAM can the game or software use in Windows XP SP3?  I thought the limit was 64GB in Windows 2003 Server 32-bit?  Will a 32-bit CPU access the 128GB or only 64-bit CPU?

Edited April 20, 2017 by 98SE

[Dibya]

15 hours ago, 98SE said:

Dibya, Where can I get this patch you did?  How much RAM can the game or software use in Windows XP SP3?  I thought the limit was 64GB in Windows 2003 Server 32-bit?  Will a 32-bit CPU access the 128GB or only 64-bit CPU?

you need cpu with 37bit PAE addressing capability .

https://ryanvm.net/forum/viewtopic.php?f=7&t=10547

Edited April 21, 2017 by Dibya

[98SE]

On Friday, April 21, 2017 at 5:46 AM, Dibya said:

you need cpu with 37bit PAE addressing capability .

https://ryanvm.net/forum/viewtopic.php?f=7&t=10547

Thanks Dibya lots of good stuff there reading now.

Can you limit how much memory set aside for OS so XP doesn't hog all the memory?  Say you want only 16GB for the Windows OS and reserve the rest as memory to be used by a Ramdrive.

Can you tweak the memory limit patch to go up to 192GB to match Windows 7 or 2TB to match Windows 10 yet?

Do you have a write up of how you modified the files and which files are XP original, W2K3S original, and which modified by you?

Edited April 28, 2017 by 98SE

[jaclaz]

2 minutes ago, 98SE said:

Can you tweak the memory limit patch to go up to 192GB to match Windows 7 or 2TB to match Windows 10 yet?

As a side note, if you ever have a 2TB machine and Windows 10 makes a full memory dump (crashdump) I want to see its examination ....

jaclaz
 

[98SE]

On Friday, April 21, 2017 at 11:47 AM, jaclaz said:

As a side note, if you ever have a 2TB machine and Windows 10 makes a full memory dump (crashdump) I want to see its examination ....

jaclaz
 

Ahh, just reread the message.  Tried W10 not a huge fan of it but I will say I will also disable the memory dump on that.  I think that was a peeve of mine if XP crashed you had to wait for a long dump.

I disable memory dump on XP all the time during installs and not even the mini dump is enabled.  I also disable auto reboot in case I need to snap a photo of the BSOD screen for troubleshooting.  I also disable system restore, hibernation, and set the pagefile to a 28GB Ramdrive.  Maybe with Dibya's patch may or may not conflict with my Ramdrive software that uses the > 3.2GB memory range.  We shall see.  But if Dibya's limit patch increases the OS usable memory than I can use a standard Ramdrive.

Currently W7 has a 192TB limit and W10 has a 2TB limit on both their high end line up.  I would like Dibya if he already knows how to future proof the memory limit beyond 128GB.  I know 192GB is attainable on server class, 2TB might also be as well on some really high end Amazon servers.   I'm only dealing with consumer class which is limited to 64GB at the moment which is disappointing.  Reminds me of the early 386 / 486 days when we had 1MB, 4MB, 8MB, 16MB, 32MB, 64MB ---> now 64GB.  We will get there in the same manner in GB/TB just 30 years later.  I would say within 5 years we should be at 256GB on consumer class motherboards and maybe 2TB in 10 years and 10TB for servers.

Edited April 28, 2017 by 98SE