Jump to content











Photo
- - - - -

Booting win Xp in RAM and disabling cpu cores


  • Please log in to reply
10 replies to this topic

#1 Twenty trees

Twenty trees
  • Members
  • 3 posts
  •  
    Germany

Posted 13 November 2019 - 10:12 PM

Hi guys

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 dickfitzwell

dickfitzwell

    Member

  • Members
  • 33 posts

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 Twenty trees

Twenty trees
  • Members
  • 3 posts
  •  
    Germany

Posted 14 November 2019 - 08:12 PM

Thank you for the answer. But dong it by the boot. Ini was not my question. I know that you can do it this way.
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 RoyM

RoyM

    Frequent Member

  • .script developer
  • 420 posts
  • Interests:"Booting and Owning".
  •  
    United States

Posted 15 November 2019 - 02:02 AM

Attached File  multiprocessor.script   31.03KB   280 downloads

If you can read .script.
You may find some answers from attached .script published by Galapo
 
From: LiveXP Project\Finish\1 Optimizations\multiprocessor.script
Look down around line 230:
%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 Wonko the Sane

Wonko the Sane

    The Finder

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

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

 

:duff:

Wonko



#6 Twenty trees

Twenty trees
  • Members
  • 3 posts
  •  
    Germany

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 Wonko the Sane

Wonko the Sane

    The Finder

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

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/

 

:duff:

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 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

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

.
@Twenty trees
 
Add a default numproc to boot.ini, e.g.
/numproc=4
.
Add a dummy section to boot.ini, create a file size greater 1 KiB.
Small NTFS files are stored at MFT, grub4dos read real files only.
[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
.
Try --top at a current grub4dos version
map --mem --top /XP32USP1.vhd (hd0)


#9 Wonko the Sane

Wonko the Sane

    The Finder

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

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? :dubbio:

 

:duff:

Wonko



#10 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

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 Wonko the Sane

Wonko the Sane

    The Finder

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

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

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users