Booting win Xp in RAM and disabling cpu cores
#1
Posted 13 November 2019 - 10:12 PM
Last year I had a project of running windows xp in the ram.
after about 50 hours of work and a lot of reading and trying I finally made it.
Know I wonder if you can run xp in the ram and additionally control the amount of cpu cores that are active, via grub4dos.
As example:
In some cases I only need 1 core instead of 4 cores but still need the windows running in the ram. Sometimes I need 2 cores.
The background is, that I overclock at hwbot. org and I would have a good opportunity in having better scores.
could somebody please help me in coding grub4dos for this experiment?
Thanos
#2
Posted 14 November 2019 - 12:58 AM
not saying it cannot be done with xp, but surely it is not a function of grub4dos. lastly, "we" have already utilitzed xp in so many ways it was not intended. how much more can we ask of this aged os?
Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files
/numproc=number
This switch sets the number of processors that Windows will run at startup. With this switch, you can force a multiprocessor system to use only the quantity of processors (number) that you specify. This switch can help you troubleshoot performance problems and defective CPUs.
#3
Posted 14 November 2019 - 08:12 PM
The question was how I can code grub4dos to do so.
I know there is a way, I already have seen it, but do not know if I can run both. Ramdisk and core disabling.
#4
Posted 15 November 2019 - 02:02 AM
multiprocessor.script 31.03KB 282 downloads
%MenuAdd_GRUB%,"title Uniprocessor %ProjectTitle%#$xfind --set-root /I386/SETUPLDR.BIN#$xchainloader /I386/SETUPLDR.BIN",RemoveDefault
%MenuAdd_GRUB%,"title Multiprocessor %ProjectTitle%"
%MenuAdd_GRUB%,"find --set-root /I386/MULTICPU.BIN"
%MenuAdd_GRUB%,"chainloader /I386/MULTICPU.BIN"
Regards
RoyM
#5
Posted 15 November 2019 - 12:30 PM
@Twenty trees
Is it an XP or a PE (liveXP is actually a PE).
IF it is a XP (and not a PE), on which filesystem is the NTLDR and BOOT.INI?
What is (EXACTLY) your current menu.lst AND your current BOOT.INI?
Basically (again IF it is aan XP and not a PE) there are three possible approaches:
1) if the filesystem is FAT, replace - on the fly - the file BOOT.INI with a copy with the suitable multiprocessor option
2) otherwise use grub4dos commands to edit (cat --replace) the existing boot.ini
3) otherwise have another copy of NTLDR (with a different name, let's say N4LDR) hex-edited to load instead of boot.ini another file (let's say coot.ini) and then load via grub4dos either NTLDR or N4LDR
Wonko
#6
Posted 16 November 2019 - 05:19 PM
Hi, thanks for all the posts.
I forgot to mention the most important STUFF, Sorry
I am loading xp out of a vhd.
The file that's loading is ntldr.
I can post the code for grub4dos as soon as I am at home.
The code would just need an extention so it starts with 1 or 2 cores.
edit:
I just copied the code from here.
I am running the system via firadesk, but as I can see there should be no difference.
title Portable XP32USP1.vhd - WinVBlock FILEDISK - 1.2 GB
# Sector-mapped disk
find --set-root --ignore-floppies /XP32USP1.vhd
map /XP32USP1.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr
title Portable XP32USP1.vhd - WinVBlock RAMDISK - 1.2 GB
# Sector-mapped disk
find --set-root --ignore-floppies /XP32USP1.vhd
map --mem /XP32USP1.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr
Edited by Twenty trees, 16 November 2019 - 05:25 PM.
#7
Posted 16 November 2019 - 06:01 PM
Good
From your last line in menu.lst entries (and the following implied "boot" directive):
chainloader /ntldr
Control is passed entirely from grub4dos to ntldr.
NTLDR reads BOOT.INI and uses what parameters it finds there to boot the XP.
So, what you can do is use one of the 3 (three) methods I suggested earlier.
Of those, the "safer" (since it doesn't modify anything on the fly, but least elegant) is #3, the best one (IMHO) is #1 (but is limited to FAT filesystems) and the #2 is the one that is (IMHO) easier and overall "better" to implement.
Post your current BOOT.INI and we'll see the details of the various possible implementations (of #2 but if for any reason you prefer one of the other ones, we can talk about it).
For the record there is a fourth (easiest) method which is simply that of adding various entries in BOOT.INI with various / options, but I excluded it since you asked for a grub4dos solution.
And BTW if you go for this latter solution, you can have coloured entries in BOOT.INI:
http://reboot.pro/to...ode-in-bootini/
Wonko
P.S.: Side note if any of the kids wants to play with me, the parser in NTLDR should ignore any line in BOOT.INI before the [boot loader] tag, so it should be possible to have the BOOT.INI be also a grub4dos batch.
#8
Posted 18 November 2019 - 05:13 PM
The question was how I can code grub4dos to do so.
I know there is a way, I already have seen it, but do not know if I can run both. Ramdisk and core disabling.
2) otherwise use grub4dos commands to edit (cat --replace) the existing boot.ini
/numproc=4
[SPACE] ####################################################################################################### ####################################################################################################### #######################################################################################################
title Portable XP32USP1.vhd - numproc 2 - 1.2 GB # Sector-mapped disk find --set-root --ignore-floppies /XP32USP1.vhd map --mem /XP32USP1.vhd (hd0) map --hook root (hd0,0) cat --locate=numproc\=4 --replace=numproc\=2 /boot.ini chainloader /ntldr
#9
Posted 18 November 2019 - 06:06 PM
@cdob
JFYI, the need for padding so that the boot.ini is not embedded in the $MFT depends on the version of grub4dos, starting from *some* release of 0.4.6a (I just tested 0.4.6.a 2017-08-30) a file in the $MFT record is listed (and parsed edited/etc. just fine)
I believe this is the change (translated from ChangeLog_chenall.txt) where it was introduced:
2015-05-14(yaya)
Improve the NTFS file system:
For resident property files (small files), you can write or blocklist to display information.
For non-resident attribute lists, the length limit is removed.
Or has there been some bug in some later version?
Wonko
#10
Posted 19 November 2019 - 11:10 PM
JFYI, the need for padding so that the boot.ini is not embedded in the $MFT depends on the version of grub4dos
2015-05-14(yaya)
Improve the NTFS file system:
For resident property files (small files), you can write or blocklist to display information.
.
Thanks for the head up. I wasn't aware of this feature.
No, I don't know a current bug.
As for myself, I would use the "fourth (easiest) method which is simply that of adding various entries in BOOT.INI with various / options". It's a boot chain, select boot mode twice in a chain, not nice. But keep it simple and stupid.
What did I configure about 12 years before? At localhost there is a XP RAM file based on 2003 SP2 ramdisk. How did I build this? https://web.archive....opic=19056&st=0After 12 years, I remember the general approach, but no details anymore.
Today I would use svbus driver instead of firadisk.
Challenge; given a 8 GiB physical RAM hardware, get most RAM to runnning XP 32 Bit at RAM disk?
Load the XP RAM disk above 4 GiB address space and boot from it? I've no idea, what's possible noadays.
Editing boot.ini in RAM disk is a simple approach too. Because this can be verified easily.
At grub4dos add a cat boot.ini and a pause to read the boot.ini file.
Or boot XP. open boot.ini at notepad and verify the file.
I've no idea about numproc=1.
Windows uses a unicore kernel and hal at a single core CPU.
There are kernel and hal options at boot.ini too.
Changing numproc, kernel and hal may be required at boot.ini.
#11
Posted 20 November 2019 - 11:11 AM
Yes, I concur that the simplest is always the easiest/foolproof, etc. but adding entries to the BOOT.INI wouldn't fulfill the "grub4dos" part of the original question.
About numproc = 1 I believe you are correct , so we are back to a good ol' multichoice BOOT.INI, like the one (once) used in Sysprep:
http://www.vernalex....sprep/hal.shtml
Wonko
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users