Windows XP in RAM -another attempt, Using "unmanaged" memory Options

[SEAKZ]

There is one more attempt to utilize Windows “unmanaged memory". Or at least to start RAM-based Windows with a little bit better condition then it is allowed by standard Microsoft ramdisk driver
You will need:
1. RAM more then 2 Gb, minimum 4 Gb, better more, which is quite acceptable for the up to date computers and prices for memory chips.. My test machine has 6 Gb
2. The program, and only one I know to handle Windows unmanaged memory, RamDiskPlus. Last version 9.0.4.3. I am very aware that RamdiskPlus is a commercial utility, so the usage of it I will describe at the last point
3. The RAM based Windows on “boot.img”. The smaller, the better. Mine is 300 MB. Could it be less ? That would be your Windows ‘Load’ manager
4. This boot image would be able to “launch”, or better to say “utilize” ANY (almost ?) Windows based on:
• HD
• Virtual disk
• RAM drive
• RAM drive in Windows unmanaged memory
For the last option computer should be able to run RAM-windows with /PAE parameter in BOOT.INI
For example:
ramdisk(0)\WINDOWS="RAM CopyBooot XP" /rdpath=multi(0)disk(0)rdisk(0)partition(1)\boot.img /fastdetect /noexecute=optin /PAE
My motherboard: MSI P35 Neo2-FIR can handle it with XP SP 2 and XP SP3

Actually only ImDisk needed to mount “FULL” image on "boot" image, nothing else.

How this could be possible:
Windows Disk Manager and Microsoft Diskpart would not let you assign anything to C:\.

But 3-rd party utility will do

I found two of them

1. Paragon Hard Drive Manager will work with physical drives or anything seen as physical drives because
• Windows Disk Manager can not see RAM-drive
• Letter C: is not assigned to any drive according to Disk Manager
For example Microsoft SDI or RamDiskPlus

2. ImDisk. This utility will mount images to any letter, including system drives, C: for windows and X: for PE. C: and X: could be physical drives or RAM drives

Any drive: HD, Virtual or RAM assigned as C:\ will replace content and volume of Drive C:\.
So, instead of truncated windows with 50 Mb of free space out of 480 Mb disk C:\, you will immediately see full windows, with free space according to the size of the new connected drive or image.
Only registry hives, would be from boot image. Registry hives on C:\ now are useless and could be removed. Or better replaced with command “reg export”. “Reg save” also works, but “reg restore” returns “access denied” . Could any one help why?

So there is the simplest description how to start second "full" image of Windows
• Install new windows on HD or Virtual disk
• Install ImDisk
• Install RamDiskPlus if you have it
• Make a copy of this installation
• Truncate the copy to 600 Mb or less,
• Make it bootable from RAM-drive accordin to description on 4-th page of this fread. No files from W2003 needed
• Put the small RAM-bootable windows on “boot.img”, NTFS compressed, maximum 480 Mb
• Put full windows on “windows.img”, 1 Gb, NTFS compressed, for test in RAM. Or bigger for test as virtual disk. Or on usb drive.Or leave it on the HD drive there it has been installed, if it separate drive
• Booted from RAM windows, start ImDisk and choose full "wndows.img"
• mount it as letter C:
• Or start Paragon Hard Drive Manager
• Choose any drive visible and assign it as C:.
Content and Size of C: would be immediately changed. Now only registry have to be updated to use software installed on full windows image
• Hit F5 to refresh desktop and programs in start menu

RamDiskPlus creates RAM-Disk in windows unmanaged memory. This RAM-disk could be saved and loaded during boot with all information on it intact. Put the fill windows image on it and then mount image as disk C:

If you do not have RamDiskPlus or have 4 Gb, or less, of RAM then it is possible to create Ramdisk with ImDisk and mount you new sys drive from it. I tested that on Winbuilder's LiveXP. The only difference is that folder "windows" should be renamed to i386. That is really funny:
RAM drive B: created by ImDisk at startup, size 1.3 Gb
1Gb image "windows.img" copied to B:
"windows.img" is mounted as drive X:,
new bigger size and programs availabe
In the last WIMboot progect WIM mount on X is possible

ImDisk also allows to dismount mounted image (force dismount) and you will return to initial sys drive. Image file would be locked, but "Unlocker" can handle it. Then it is possible to mount this image or any other, with different software

Programs could be installed on "new" disk C: and all files would be automatically saved during shuttdown. Only registry have to be saved manually.
The best program that will do it automatically is "Image Creator" from Nikzzz, available in Winbuilder's LiveXP project. For full RAM- windows it does more then for PE projects: it saves all registry to boot image. The program is absolutely mandatory for creating and changing boot image. The usage would be :
dismount "full" windows image
close all programs if any open
choose boot.img and save
but here could be problems: if new program installed, during boot, will need files located on a full image
I would prefer to save registry on full image to keep registry from boot image unchanged, and possibly hardware and software independent
Of course this is very experimental and need more tests. And I hope that people with better experience could make boot and shutdown processes fully automatic

PS. image to system disk shuffle also possible in VISTA

[jaclaz]

SEAKZ,
Sorry, but I cannot really make head or tail of your post.

Is it a Tutorial?
If yes, I cannot understand it.

Is it a request for help of some kind?
If yes I seem not to be able to find the details of your setup and what the problem is.

Is it a derivative or however connected with euhenio's method?

Maybe I should move it to a new thread where you could expand on it?

Some semi-random question and/or comments:

If a Commercial app is needed, why not using Diskless Angel and avoid all the mess?

Gavotte's RRamdisk has been reported to be able to access the "over the boundary" RAM, why not using it instead of RamDiskPlus?

Did you test the MS VSS drivers?
http://www.boot-land.net/forums/index.php?...ic=6492&hl=

Maybe the solution at least partial to the problems (assigning a drive letter) is in there.



jaclaz

[SEAKZ]

I wouldn’t call my post as a tutorial because it gives more questions then answers
But I will clarify some of them
1 this is description of method allowing to replace “on the fly” you system drive
2 first utility, I found, able to replace physical disk was Paragon HDM started from Windows in RAM. I guess it is related with EUHENIO method. But hi nether bothered to explain how his MobileOS works
3 second utility, and that is what really counts, is ImDisk. It replaces system disk with any image located on HD or RAM disk.
4 If the image will contain a copy of full installed windows then you will see all new files installed on it
5 this image could be unmounted and any other image could be mounted instead
6 It means you can easily overcome limitation in 500 Mb that comes from Microsoft’s ramdysk.sys
7 This method of replacing of system disk work both on Windows in RAM and PE based LiveXP
8 If you have program that can utilize unmanaged memory, then system disk would be located there
9 Gavotty rramdisk installed in Windows in RAM always gives BSOD 07b at boot. Thou it could be manually started in Windows in RAM. And even able to load image from HD, but can not directly mount it as a system drive. Any way ImDisk required. Two other programs I don’t know and will test them
From all of this following next:
Make Windows in RAM as small as possible, only ImDisk required to run
Boot in RAM and mount any image with full system as system drive with help of ImDisk
Update registry to be able to utilize new accrued software

Now my questions
1 What would be the smallest size of boot part of Windows in RAM. List of required files from MobileOS doesn’t help. I guess because it switches disks at early stage
2 Why Reg Restore gives Access Denied message, could not find tangible workarounds in GOOGLE.
So still cannot test what is better Reg Import or Reg Restore.
3 Determine the programs that will require to be in registry at boot time (guess the latest are those that have Txtsetup.sif lines in BartPE plugins)
4 Is it possible to make a single script that will load image and update registry, unmount image and restore registry of Windows in RAM
5 Since programs could be installed in Memory, what would be the best way to save changes? Here actually I am not waiting for direct answers, but suggestions and tests

[jaclaz]

Maybe I am starting to see.

You are proposing a "splitted" system, a "core" + an additional "filesystem" driver (not necessarily Ramdisk, and not necessarily IMDISK).

There are some previous experiences on the specific matter, you should search on 911CD for posts by users Sanbarrow and pavel.

Search also on boot-land for posts by Sanbarrow.

You may find, besides the already given thread, these interesting:
http://www.boot-land.net/forums/?showtopic=1507
http://www.boot-land.net/forums/index.php?showtopic=4064

Seemingly unrelated, but not much :
http://www.911cd.net/forums//index.php?showtopic=20870

jaclaz

[SEAKZ]

Finally managed to run Gavotte RRamdrive as second ramdrive. Now it gives me 3 Gb "ramdisk+pae". From it I can mount secondary image as my system disk.
In my case the reason of fault was :
*Microsoft "Windows RAM Disk Driver" was installet as Class UNKNOWN
*Gavotte installs its own class SAMPLE
*But if class UNKNOWN already exists, gavotte will overwrite it content with copy of class SAMPLE
So just saved and later restored hive [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\UNKNOWN]
allowed to save the state of Windows in RAM and restart it without BSOD

[SEAKZ]

There are some updates for the project.

Description of the project goal:
Windows in RAM, the file system fully in "windows unattended memory", available with 4 Gb or more RAM installed.
Compatibility: minimum 1 Gb RAM required. All secondary images could be mounted from hard drives
Bonus: Mounting technique described there is fully compatible with ANY "Live Windows XP CD" project

Following the links kindly submitted by Jaclaz found certain answers for some of my questions
Link to "VSS" driver revealed info about DOSDEV.EXE. This program allowing mounting almost anything to everything
Link to "Diskless Angel"- good info about images creation

Now how it is:

1 Minimal size and content of a "boot image
The "Diskless Angel" or rather part of it, a "Little angel", could build "minimal" or "optimized" images. Or much better: for you own needs built image according to "LA" manual.
1 Boot Windows
2 Run programs minimally required for your purposes
3 Make a list of files being accessed after last boot. Total Commander is able to create required filter.
4 Add to the image files required for TXT part of windows boot process
5 "Diskless Angel" and its commercial driver are not needed at all

2 The alternative way to mount one partition on another
It is combination of dreamed WimMount and DOSDEV.EXE: mounts not only virtual disks but directly hard drive partitions. With DOSDEV.EXE much more interesting mounting technique, compare to ImDisk, available:
1 "full" windows image compressed with imagex or Gimagex to "windows.wim"
2 TEMP variables of boot and full images has to be redirected to ramdrive i.e. “r:\temp” (default for Gavotte's rramdrive)
3 on drive r:\ any empty folder needed. i.e. “r:\wim”
4 wim image will be mounted with mount_path "r:\wim" from boot device
5 alternatively, if boot device (USB flash) planned to be removed, "windows.wim" copied to ramdrive and mounted from there. i.e. "imagex /mountrw r:\windows.wim 1 r:\wim"
6 command "dosdev.exe c: r:\wim" will mount content of wim image to C:\.
7 As result disk c:\ is wim-mounted image with all operating system files and free space equal to the free space on ramdrive. A big advantage is: size of disk C:\ is always equal to the size of secondary ramdrive
8 every file copied to c:\ would be actually copied to the cache of wim image at r:\temp
9 Since this method is 90% equivalent of WimMount method of Program Files mounting from Winbuilder's Live Xp project, Image Creator could be used to save state of "boot.img" and "windows.wim" with only small modification of WimMount.cmd. This WimMount cmd also used for automatic image mounting
10 command "DOSDEV -r -d c:" is used to unmount current image before saving its parts, img and wim
11 User Settings could be loaded by user re-logging. To do it automatically WinMount.cmd started by RunOnceEx. The last command in it is “shutdown –l”, needed for auto re-logging without entering desktop. WinMount.cmd should be available on both images, because any command issued after “dosdev c: r:\wim” would be run from secondary image.

3 Convenient ways to choose how to automatically mount secondary image.
Create some different Hardware profiles i.e.
1 Mount from RAM ;choose suitable ramdrive and image
2 Mount from HD ;convenient for programs installation and small ram
3 Debug ;do not mount anything
WimMount by “Reg Query“ checks, which profile chosen and mount image accordingly
To find what is "Current Hardware profile", in every profile I created parameter "marker"
with value according to profile number i.e.

CODE

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Hardware Profiles\0003]
"marker"="03"

There are problems left:

1.Clear, minimal, software and hardware independent boot linage. Guess, after all, it should be a different project.
2. The files needed to be on a boot image.
All drivers will work only if "*.sys" part of the driver would be located only on the boot image.
Example, "Realtek High Definition Audio" (RtkHDAud.sys, 4.7 Mb)
*Boot image: no info about HDAudio... After full image mounted, audio driver could be installed, or found. Then error: drive not loaded, reboot required.
*Boot image: only RtkHDAud.sys available... After the full image mounted, audio driver could be installed, no reboot required 1
*Boot Image: RtkHDAud.sys and "reg" info are available. Driver loaded, audio available from the "boot" image. After "full" image is mounted, control panel (40 Mb), would take control for driver properties
Driver could be copied to the boot image before the "full" mage mounted. But after, device should to be re-installed. Couldn't get it be found and installed automatically. HWPnP and StartPnp from Live XP are not working: Access denied
Video driver for NVIDIA card, except NV4_mini.sys in \drivers, requires NV_disp.dll in \system32 folder.
So need a simple way to find files and update boot image
3. The way to get info from registry of any image or system partition to be mounted.
Found very interesting utility "RegSaveRestore" at CodepProject.com. For USERPROFILE it can get info in a fraction of second. Unfortunately restoring HKLM\Software very unstable, could hangs the machine. Reg Import much more reliable and quick, thou requires reg file to be prepared, with RunScanner, for example

[jaclaz]

And again , if you could expand the report of your achievements, detail the methods you used and the actual questions/doubts you have still remaining, it would maybe possible to help you further.

I am completely failing to see the "overall plot" behind your approach, as well as detailed reports of what you have done and HOW you have done it and detailed list of remaining issues/problems.

Don't take it the wrong way , what you posted is very, very interesting , but mostly ununderstandable , even by someone (yours truly ) that has a certain experience with these kind of apps/methods.

As I see it:
it does not make sense to have all this trouble for 1 Gb of memory, if the goal is using "unmanaged memory" beyond the normal accessible space, as you initially stated:

1. RAM more then 2 Gb, minimum 4 Gb, better more, which is quite acceptable for the up to date computers and prices for memory chips.. My test machine has 6 Gb

Your entire:

Now how it is:

1., 2. and 3. points seem a "mix" between "theory behind" and "methods to achieve wanted results", in my view completely failing to deliver ANY of the two in a clear way.

Consequently, without the possibility of understanding WHAT you managed to put together and HOW you did it, it is difficult if not impossible to try helping you on your "problems left".

You should present something "basic" as a reproduceable example, so that other members (if willing to do so) may explore your approach and possibly find the right way/app/method to work around the remaining problems.

jaclaz

[SEAKZ]

There is an example of what could be done win WimMount and Dosdev
1 demonstration of DOSDEV
You will need two windows installations with same user name available in both of them. Preferably, but not necessary, with same service pack. One big with a lot of programs installed, let say it is your regular windows on HD. This is "full" part
Second installation small, 200-500 Mb. It could be launched from HD, USB-HD or from RAM. this is "boot" part
Lets load from "boot" part, as you are logged-in check what is a drive letter of "full" part. Forexample d:\
be sure that dosdev.exe available on both systems, or better on 3-rd independent partition
from command console issue command DOSDEV C: D:
Size and content of disk c: would be immediately changed to content of disk d:. now you can run some windows program that was not available on the "boot" image. But user installed programs will not run and even worse: windows could give errors about writing in ROM memory.
User re-logging will prevent errors and load user settings. Now all programs that keep their data in NTUSER.DAT are working. Only data from HKLM\Software has to be imported manually.
For automatic re-logging I use command "shutdown -l"
If service packs or user licenses of two windows are different, then only RegSaveRestore could help. But it is not stable and therefore not interesting for now
To quit from mounted (guess correct word is "Mapped") image I use batch:

CODE

dosdev -d c:
shutdown -l

2 demonstration of WimMount
"Wim" format has a good compression but could not be mounted on system drive. So lets make a "wim" image of our "full" windows and mount it on any drive\folder where it is allowed. Most interesting destination would be ramdrive, "r:\wim" in my case
You can mount wim image directly from HD or copy it to ramdrive first, and mount from there. Thats why it is not so important how much memory you have for tests
So let start boot image
be sure that all TEMP variables redirected to r:\temp
mount "wim" image on r:\wim
then dosdev will map content of r:\wim on system drive "dosdev c: r:\wim".
size and free space of disk c: would be equivalent to disk r:
Re-log user

[jaclaz]

For the record, dosdev can be found inside:

Microsoft Product Support Reports
Brief Description
Download the scripted system configuration gathering tools. The Microsoft Product Support Reports utility facilitates the gathering of critical system and logging information used in troubleshooting support issues.

http://www.microsoft.com/downloads/details...;DisplayLang=en

Open the downloaded selfextracting mpsreports_x86.exe with 7-zip: "File14" is "dosdev.exe"
(check the contents of "Setup.cmd" to discover "real names" of archived files )

There is another dosdev.exe Freeware/Open Source here:
http://www.ltr-data.se/opencode.html
http://www.ltr-data.se/files/dosdev.zip

Winmount is a Commercial/Shareware app:
http://www.winmount.com/

jaclaz

[joakim]

I am not sure if I understood correctly here.

Are you trying to swap the systemdrive to something different (replacing driveletter of X:\) without rebooting? Are you actually talking about PE-mode?

If so, have you successfully done that? And possibly also make a detailed/understandable guide on how to reproduce this..

If not, what do you consider to be the barriers?

Joakim

[SEAKZ]

Been waiting for some more response or tests results about method of swapping file system of any running windows. Guess it is not clear. So will try one more time to explain advantages and problems of this method. Meanwhile found some answers for my own questions
There is a picture of a system state after “boot” image was swapped to “full” image by “dosdev.exe” or “imdisk.exe”. Or say it as: the “full” image was mapped on the “boot” system.
The arrows are showing read-write process after new file system was mapped on the top of boot system

Advantage is clear: more files are available
The problem is: drivers and some dll’s could be read only from “boot” system. Obviously they are the files needed to run windows core. The worst thing is then you are trying to install new diver, all files saved to “full” image and cannot be read by core. So drivers installed are giving error: code 39, “driver could not be loaded”
The tested workaround is:
1. Temporary, without user relogging, unmap (unmount) the “full” image from drive C:
2. Copy all new files from “drivers” directory of the “full” image to “drivers” directory of the “boot” image. Robocopy.exe is very convenient because it will copy only extra files and can show report on the screen.
3. Map (mount) the “full” image on drive C: again

Sync.cmd

CODE

dosdev -r -d c:
robocopy r:\windows\system32\drivers c:\windows\system32\drivers
dosdev c: r:
pause

4. Run device manager and look for new, problematic, devices. Error code 39
5. Disable and immediately enable them
6. For such devices as bluetooth, printer or modem windows will install drivers in two steps. For the beginning its own, then will find new hardware again. If so, repeat steps 1-5
Actually installation of the printer took 1 minute longer then installation on a common system
Device disabling and enabling could be down automatically with the help of “devcon.exe” from windows server 2003 support.cab

CODE

::check devcon report for devices with "problem 39" and activate them
devcon.exe status * >%tmp%\devrep.txt
gsar.exe -s:x0d:x0a:x20:x20:x20 -r:x20 -o %tmp%\devrep.txt
For /f "delims=&" %%a in ('findstr /c:"problem: 39" %tmp%\devrep.txt') do devcon disable @%%a* & devcon enable @%%a*

Gsar is needed to transform devcon report to a form convenient for devices ID’s search
The problem of this method is: full device ID’s contain some “&”, and “&” is natural windows delimiter. Therefore only first part of ID could be transferred to command devcon enable and disable as a parameter. For some chipsets, like VIA, installation of VIA audio driver will take a lot of time because a lot of devices disabled and enabled. Believe here could be some improvement.
Please keep in mind that “c:\windows” could be substituted by “x:\i386”. Its even ease for PE systems there are no problems with“driver” issue or user re-logging. With one click you can turn your Micro or Piko windows loaded in memory to normal windows if machine has enough RAM

[jaclaz]

Been waiting for some more response or tests results about method of swapping file system of any running windows. Guess it is not clear.

I can confirm, it is NOT clear.

So will try one more time to explain advantages and problems of this method.

And I am sorry to report that you completely failed to explain any further.

In the meantime, and JFYI, firadisk was developed:
http://www.boot-land.net/forums/index.php?showforum=94
and with it one has boot directlry and fully in RAM, with no size limits (the 512 Mb of the MS RAMDISK.SYS)

Robocopy is a MS tool, that not everyone can use/have available.

I would suggest you to "shift" to strarc, that has the same capabilities and is Freeware:
http://www.ltr-data.se/opencode.html
http://www.ltr-data.se/files/strarc.txt
http://www.ltr-data.se/files/strarc.zip

I guess that somehow your research may have connections points with this approach to "Universal" XP:
http://www.boot-land.net/forums/index.php?showtopic=9227

jaclaz

[JFX]

Hi SEAKZ,

this is very interesting idea, I hope I understood in right

- Loading a RamDisk Image (with minimal count of files needed to boot)
- Load a second Image (optional a WIM Image with better compression)
- Use dosdev to reassign the driveletter of the systempartion with the one of second image
- All open handles will stay by bootimage and all new operations will use second image (which now is the systempartition)

Bad thing is I don't have enough RAM to make use of this. But how small is your Boot image currently?

In the meantime, and JFYI, firadisk was developed:
http://www.boot-land.net/forums/index.php?showforum=94
and with it one has boot directly and fully in RAM, with no size limits (the 512 Mb of the MS RAMDISK.SYS)

Now your the one who taking a myth for real.
The limit of Ramdisk.sys is definitely beyond 512 MB, SETUPLDR and NTLDR are the one with this limit.

This post has been edited by JFX: Oct 14 2009, 04:13 PM

[joakim]

Now your the one who taking a myth for real.
The limit of Ramdisk.sys is definitely beyond 512 MB, SETUPLDR and NTLDR are the one with this limit.

It was confirmed over 4 years ago by an MS guy; http://www.ureader.com/message/1273186.aspx

Joakim

[jaclaz]

I will re-phrase, if you like it better.

With a different driver (not ramdisk.sys), such as the (never released) ramdisk driver by Dietmar Stoelting:
http://www.911cd.net/forums//index.php?sho...181&st=2044
http://www.911cd.net/forums//index.php?sho...181&st=2046
http://www.911cd.net/forums//index.php?sho...20450&st=44

the Commercial (limited to 640 Mb in the freely available version) Diskless Angel:
http://www.disklessangel.com/

or with the Freeware and virtually unlimited Firadisk driver:
http://www.boot-land.net/forums/index.php?showtopic=8804

and possibly with the WinVblock driver:
http://www.boot-land.net/forums/index.php?showtopic=8168

it is possible to load images bigger than 512 Mb, using the same NTLDR and SETUPLDR.BIN that are supposedly limited to 512 Mb.

So, the limit appears to be in the driver, though it is very possible that it is somewhere else, but the same loaders do work with bigger images, so I need a more detailed explanation to be able to contribute in NOT spreading this myth, let's say that the loaders, in conjunction with MS RAMDISK.SYS have a size limit.

Not in the specific case, mind you, but the MS guys were the ones that said (among other things ):

• that Internet Explorer is an essential part of Windows OS
• that USB booting NT based systems is impossible

so I tend to don't trust blindly their words, and, now in this specific case, after having got that answer Dietmar wrote his ramdisk.sys driver (leaving untouched NTLDR) that was reported as working, so maybe that info is not entirely accurate.

JFYI:
http://www.boot-land.net/forums/index.php?...c=5512&st=7

Then, let's say that, in practice:

• SETUPLDR.BIN+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes
• NTLDR+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes

and that:

• SETUPLDR.BIN+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)
• NTLDR+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)

jaclaz

[JFX]

SETUPLDR.BIN+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)
NTLDR+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)




jaclaz

Did you ever have tried this your self , usually NTLDR and SETUPLDR will not even load an Image if it's bigger than 512MB!
There is only one modded NTLDR that can load bigger files and also works fine with ramdisk.sys.

[joakim]

Well Yes and No. It all depends on what you use setupldr.bin for...

it is possible to load images bigger than 512 Mb, using the same NTLDR and SETUPLDR.BIN that are supposedly limited to 512 Mb.

Depends on usage.

So, the limit appears to be in the driver, though it is very possible that it is somewhere else, but the same loaders do work with bigger images, so I need a more detailed explanation to be able to contribute in NOT spreading this myth, let's say that the loaders, in conjunction with MS RAMDISK.SYS have a size limit.

The 512 limit in setupldr.bin is there in the function that allocate space to and map your image to ram! Go test it and verify with an empty image at 513. If grub4dos is used to handle the memory allocation then setupldr.bin will be happy with a ramloaded image at say 2Gb because setupldr.bin is not loading the image to ram (but then ramdisk.sys will not be able to understand what to do with the memory allocation, so you will need one of the already mentioned drivers that understand so). That is probably what the MS guy meant. Too bad we (or I) currently don't have any way of testing wheather ramdisk.sys could handle sizes bigger than 512 if loaded the setupldr.bin-way. So my guess is it will forever stay as a secret, since no one longer needs to be restricted by the limit, and thus have no interest in digger deeper into it as it soon belongs in the museum.

Then, let's say that, in practice:

• SETUPLDR.BIN+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes
• NTLDR+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes

and that:

• SETUPLDR.BIN+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)
• NTLDR+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)

jaclaz

Sounds ok, but you forgot to mention that it highly depends on who is the memory allocator (setupldr.bin or grldr).

If grldr is loading to ram, then

SETUPLDR.BIN+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes

is not true (7B).

If setupldr.bin is loading to ram, then

SETUPLDR.BIN+NTDETECT.COM+RAMDISK.SYS top at 512 Mbytes

is true.

If grldr is loading to ram, then

SETUPLDR.BIN+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)

is true.

If setupldr.bin is loading to ram, then

SETUPLDR.BIN+NTDETECT.COM+<another driver> have no size limits for the image (if not the actual driver one or the total amount of RAM on the PC)

is not true.

Joakim

This post has been edited by joakim: Oct 15 2009, 11:02 AM

[dog]

Yup, plenty of us have tried it.
The difference with firadisk or winvblock is that setupldr is not loading the image, but taking over one loaded by grub4dos or memdisk.
They also avoid the need for modding files, and for server 2k3 files, which may or may not be important to you.

[jaclaz]

Very good.

That is exactly the reason why I wrote in practice, and bolded it.

That would also explain how Dietmar's Ram Disk supposedly worked, the ntbootdd.sys way most probably doesn't follow the same "hooking" mechanism.

Would this be acceptable? (just trying to find a good enough short formula):

let's say that SETUPLDR.BIN and NTLDR, in conjunction with MS RAMDISK.SYS have a size limit or BSOD with 0x0000007b and that to avoid the limit a different RAM loader (grub4dos or memdisk) and another ramdisk driver is needed

But the above won't probably be absolutely true when Dietmar will (if ever) release his driver or someone else will start again where he and FreddyV left.

jaclaz

[SEAKZ]

JFX

You are absolutely correct in your description
My current “boot” image is 250 Mb, 50 Mb of it a free space
The size of “wim” file is 750 Mb, it gives 1.3 Mb of “full” windows. Multimedia codecs, MS Office and some other software installed. Full functionality with DirectX 3D applications
To test it you do not need too much RAM, 2 Gb is enough. 1 Gb for Windows and 1 Gb for ramdrive. Ramdrive should be bigger then your wim file if you want to run diskless machine. Otherwise you can mount “wim” file to a small ramdrive directly from boot media.
My first intention was to utilize windows unmanaged memory; therefore my choice is gavotte’s ramdrive. It can configure size of ramdrive automatically depending of the amount of RAM available. Install it as 1 Gb, FAT32 by default. With PAE parameter in boot.ini ramdrive size would be
3.8 Gb for 6 Gb of RAM
1 Gb for 4 Gb, taking only 200 Mb from windows managed memory
1 Gb for 2 Gb
This allowing running same image on different machines
By the way. Gavotte’s ramdrive should be installed before installation of windows ramdrive. Otherwise you will have to manually correct registry not to get BSOD 07