Jump to content











Photo
- - - - -

Disappearing memory mapped ISO drive with winvblock - XP setup

xp memdisk grub for dos iso

  • Please log in to reply
49 replies to this topic

#26 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 28 May 2014 - 05:29 AM

To betrand: I'm sorry, but I do not understand what you mean in your 3 last posts.

I have one image xp.iso with integrated WinVBlock driver using nLite. I install the system in two ways:

 

1. From RAM-ISO to dummy.img on HDD

2. From RAM-ISO direct to HDD

 

I made a lot of tests. In both cases, the use of mapping RAM xp.iso like this:

map --mem /xp.iso (0xff)

In the first case (install to dummy.img) there are no problems during the installation.

In the second case (install direct to HDD) there is a problem for which this forum topic - Disappearing memory mapped ISO drive with winvblock - XP setup. After many test I found two solutions:

 

- turning off the optical drive in virtual machines, or/and the IDE controller in BIOS to which CD-ROM is connected

 

or

 

- map to RAM any floppy image in both Windows Setup phases

map --mem /fdd.img (fd0)


#27 betrand

betrand

    Frequent Member

  • Advanced user
  • 467 posts
  •  
    France

Posted 28 May 2014 - 02:11 PM

Hi Reboot12,

I understood you allright ;).

My main points were, why call an image (to install to) "dummy.img"

as it implies it is there instead of something.

Why not InstallHD.img...

Much clearer! ;)

 

I got your points about all the scenarii, good work.

My point (with the link in a post) was additional info about the working of WinVBlock,

in conjunction with Grub4Dos, in a really well explained post by the Master Himself -Shao :P.

 

Also, I enjoyed your map --mem /fdd.img trick.

 

Have you tried

 

#Set rd to 2048 bytes

map --rd-size=2048

#Copy rd to a new RAM disk with number 0x55

map --mem (rd)+4 (0x55)

map --hook

 

at both phases.

 

:cheers:



#28 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 28 May 2014 - 03:46 PM

Also, if OP is still using grub4dos 0.4.4 2008-12-29 :w00t: :
http://reboot.pro/to...-20#entry183805
using a "current" version of grub4dos usually helps, that would be at the time of this writing either:
http://code.google.c.../downloads/list
http://code.google.c...-03.7z&can=2&q=
(Featured) 0.4.5c-2013-03-03
or
http://code.google.c...-17.7z&can=2&q= Latest version of the 0.4.5c series 0.4.5c-2014-01-17

:duff:
Wonko

#29 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 29 May 2014 - 05:59 PM

map --rd-size=2048 and new GRUB4DOS version not help. I tried also like this:

map --rd-size=1474560
map --mem (rd)+1 (fd0)

but still not help :-(



#30 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 29 May 2014 - 07:28 PM

Well, with map --mem (rd)+1 (fd0) you map ONLY first sector to (fd0).
You might want to experiment with:

map --rd-size=1474560
map --mem (rd)0+2880 (fd0)
map --hook

And also test for older (smaller formats, like 1.2 Mb or 720 Kb).

Additionally - maybe - a requirement could be that the "floppy" is formatted, if this is the case you can format it on-the-fly with the "fat" grub4dos tool.
See the example Steve6375 provides here (for a 2.88 Mb floppy):
http://www.rmprepusb...ubutils#TOC-fat

:duff:
Wonko

#31 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 29 May 2014 - 09:15 PM

You might want to experiment with:
map --rd-size=1474560
map --mem (rd)0+2880 (fd0)
map --hook

I test this but still not help. Probably floppy image need be formatted. I think that it is easier to map a floppy image from a PXE server (TFTP) like this -> Link


Edited by reboot12, 29 May 2014 - 09:15 PM.


#32 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 30 May 2014 - 08:50 AM

I test this but still not help. Probably floppy image need be formatted. I think that it is easier to map a floppy image from a PXE server (TFTP) like this -> Link

Try using a non formatted floppy image (all 00's) from the PXE server (if it still works it could mean that the issue is not with the formatting). :unsure:

 

:duff:

Wonko



#33 betrand

betrand

    Frequent Member

  • Advanced user
  • 467 posts
  •  
    France

Posted 30 May 2014 - 09:21 AM

Please try

map --mem /menu.lst (fd0)

map --hook

 

or any other 'existing' file. Just to check if the file needs to exist, like in the description by Shao.



#34 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 31 May 2014 - 12:23 AM

Well, with map --mem (rd)+1 (fd0) you map ONLY first sector to (fd0)

 
In README_GRUB4DOS.txt i found this:

The notation (rd)+1 always represents the file which contains all the bytes stored in (rd).

 
I boot installed on HDD WinXP with WinVBlock driver like this:

title Boot WinXP (contains WinVBlock driver)
map --rd-size=1474560
map --mem (rd)+1 (fd1)
map --hook
root (hd0,0)
chainloader /ntldr

and in My Computer is FDD 5.25 (B:) on RAM_at_7FD1E000. Unfortunately for Windows Setup this map not help :-(
5632887m.png 5633911m.png 5622647m.png
 
I found also information (The mapping to (rd) does not act as a BIOS int13) in this thread:
 

Note that if you map a file to (rd), you cannot do "map --hook" for it. The mapping to (rd) does not act as a BIOS int13 disk emulation. If you want a disk emulation, you should map to (fd0), (fd1), (fd2), (fd3), (hd0), (hd1), (hd2), (hd3), (hd4), (hd5), (hd6), (hd7) or (hd), with or without the --mem switch.


Edited by reboot12, 31 May 2014 - 12:45 AM.


#35 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 May 2014 - 10:50 AM

I was somehow confusing (rd) with (md). :w00t: :ph34r:

 

The given example by Steve6375:

http://www.rmprepusb...ubutils#TOC-fat

 (that uses (md) and not (rd) )  does work here (though I have no idea if it can help in your situation).

 

 

:duff:

Wonko



#36 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 31 May 2014 - 03:33 PM

The given example by Steve6375:

Thx for help but I run GRUB4DOS by a network of PXELINUX (TFTP). If I have to use additional tools such as fat I might as well use a floppy image from TFTP server :-) I test also other fdd.ima maked in WinHex -> New file size 1474560 bytes. If use this image to map as (fd0) then Windows Setup hangs at black screen. This means that floppy image need be formated and must have BPB (BIOS Parameter Block). I test also map fdd.ima maked by Virtual Floppy Drive 2.1 by Ken Kato and Windows Setup is completed successfully :-).

5572289m.png

Because this image work i try write some HEX data (little endian) from first sector of this image to ram disk (rd). Unfortunately GRUB4DOS hangs random while write command:

title test
map --rd-size=1474560
write 0x0 0x56903ceb
write 0x4 0x2e324446
write 0x8 0x00202031
write 0xc 0x00010102
write 0x10 0x4000e002
write 0x14 0x0009f00b
write 0x18 0x00020012
write 0x1c 0x00000000
write 0x20 0x00000000
write 0x24 0xe2290000
write 0x28 0x4e0204ab
write 0x2c 0x414e204f
write 0x30 0x2020454d
write 0x34 0x41462020
write 0x38 0x20323154
write 0x3c 0x00002020
write 0x1fe 0xaa55
write 0x200 0x00fffff0
map --mem (rd)+1 (fd0)
map --hook
cat --hex (fd0)+1

Edited by reboot12, 31 May 2014 - 03:43 PM.


#37 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 May 2014 - 04:58 PM

Wait a minute.

 

There is something "wrong" in the way you use the "write" command.

 

JFYI, another good way to write hex values is using the cat --hex command.

 

See the approach used here:

http://reboot.pro/to...ite-hex-values/

 

What I would try (testing the first few lines on command line before assembling it in a batch or in a set of lines of menu.lst) would be something *like*

map --rd-size=1474560
map --mem (rd)+1 (fd0)
map --hook

cat --hex --skip=0 --length=16 (fd0)+1
write --offset=0 (fd0) \xEB\xFE\x90\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x01\x01\x00
cat --hex --skip=0 --length=16 (fd0)+1
cat --hex --skip=16 --length=16 (fd0)+1 
write --offset=16 (fd0) \x01\x00\x02\x40\x0B\xF0\x09\x00\x12\x00\x02\x00\x00\x00\x00\x00
cat --hex --skip=16 --length=16 (fd0)+1 
cat --hex --skip=32 --length=16 (fd0)+1 
write --offset=32 (fd0) \x00\x00\x00\x00\x80\x00\x29\x38\x94\xBF\x44\x4E\x4F\x20\x4E\x41
cat --hex --skip=32 --length=16 (fd0)+1
cat --hex --skip=48 --length=16 (fd0)+1
write --offset=48 (fd0) \x4D\x45\x20\x20\x20\x20\x46\x41\x54\x20\x20\x20\x20\x20\x00\x00
cat --hex --skip=48 --length=16 (fd0)+1
cat --hex --skip=496 --length=16 (fd0)+1
write --offset=510 (fd0) \x55\xAA
cat --hex --skip=0 --length=16 (fd0)1+1
write --offset=512 (fd0) \xF0\xFF\xFF\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
cat --hex --skip=0 --length=16 (fd0)1+1

:duff:

Wonko

 

 



#38 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 31 May 2014 - 06:21 PM

It seems to me that we are going the wrong way. Map any floppy image is more simple and readable :-)

title Install WinXP from RAM-ISO
# map floppy image to RAM over PXE
map --mem (pd)/images/fddwin95.ima (fd0)
# map ISO image to RAM from partition D:
kernel /memdisk raw iso
initrd (hd0,4)/xp.iso
boot

or

title Install WinXP from RAM-ISO
# map floppy image to RAM over PXE
map --mem (pd)/images/fddwin95.ima (fd0)
# map ISO image to RAM from partition D:
map --mem (hd0,4)/xp.iso (0xff)
map --hook
chainloader (0xff)

Edited by reboot12, 31 May 2014 - 06:28 PM.


#39 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 31 May 2014 - 07:21 PM

Sure :), but the idea was to explore strange new tools, to seek out new methods and new scripts, to boldly boot what no man has booted before. :w00t:

As another *random* idea, how big in size needs the floppy image be?

Remember that normally you have 16 sectors x 2048 bytes = 32,768 unused bytes at the beginning of your .iso.

 

:duff: Wonko



#40 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 01 June 2014 - 01:23 AM

write 0x0 0x56903ceb write 0x4 0x2e324446 write 0x8 0x00202031 write 0xc 0x00010102 write 0x10 0x4000e002 write 0x14 0x0009f00b write 0x18 0x00020012 write 0x1c 0x00000000 write 0x20 0x00000000 write 0x24 0xe2290000 write 0x28 0x4e0204ab write 0x2c 0x414e204f write 0x30 0x2020454d write 0x34 0x41462020 write 0x38 0x20323154 write 0x3c 0x00002020 write 0x1fe 0xaa55 write 0x200 0x00fffff0 as such, you used write to "direct memory address", and the address is reserved for the Interrupt Vector Table. It surely causes hang up.

#41 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 01 June 2014 - 11:48 PM

I have one image xp.iso with integrated WinVBlock driver using nLite

I'm sorry but it xp.iso is not built only with nLite - TXTSETUP.SIF file has also edited manually !!!

I decided to clean up my driver WinVBlock_0.0.1.8_Prefetch_1.zip I changed all the file names in lower case and removed unnecessary files. It was so:

[.]            [..]           aoe32.sys      AoE64.sys      CHANGES.log
gpl.txt        memdisk        ReadMe.txt     txtsetup.oem   winvblk.exe
WinVBlk.INF    wvblk32.sys    WVBlk64.sys

After clean:

[.]            [..]           readme.txt     txtsetup.oem   winvblk.exe
winvblk.inf    wvblk32.sys    wvblk64.sys

and integrated driver in the nLite to new xp.iso then tested WinXP installation. Unfortunately after boot GUI-phase setup displays window Please insert CD Service Pack 2 bla bla bla... :dubbio:
Fortunately, I also have the previous version xp.iso :thumbsup: I compare both ISO's and files TXTSETUP.SIF from images old_xp.iso and new_xp.iso. Both ISO's have nLite integrated WinVBlock but I found differences in sections [SCSI.Load] & [SCSI] in TXTSETUP.SIF files. Image old_xp.iso (which Windows Setup successfully install) have:

[SCSI.Load]
WinVBlock = wvblk32.sys,4
wvblk32 = wvblk32.sys,4

[SCSI]
WinVBlock = "WinVBlock Driver"
wvblk32 = "WinVBlock RAMdisk driver"

Image new_xp.iso (which Windows Setup loses access to the ISO image) have only:

[SCSI.Load]
WinVBlock = wvblk32.sys,4

[SCSI]
WinVBlock = "WinVBlock Driver"

This means that old_xp.iso is build with nLite + manually edit TXTSETUP.SIF like in this tutorial. Interesting that the entry wvblk32.sys = 1,,,,,, 4_, 4,1,,, 1,4 is in the [SourceDisksFiles.x86] instead of [SourceDisksFiles] section :dubbio:
But now test new xp.iso with nLite integrated WinVBlock + manually added two entiries in [SCSI.Load] & [SCSI] section of TXTSETUP.SIF - WinXP Setup successfully ends :jump: :yahoo:


Edited by reboot12, 01 June 2014 - 11:50 PM.


#42 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 02 June 2014 - 12:06 PM

Well, if you clean up, there is no real reason to have the 64 bit version of the driver on a 32 bit system.

 

:duff:

Wonko



#43 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 02 June 2014 - 03:51 PM

Image old_xp.iso (which Windows Setup successfully install) have:

[SCSI.Load]
WinVBlock = wvblk32.sys,4
wvblk32 = wvblk32.sys,4

This loads wvblk32.sys twice.

Which [HardwareIdsDatabase] entry relates to WinVBlock or wvblk32?
 

Image new_xp.iso (which Windows Setup loses access to the ISO image) have only:

[SCSI.Load]
WinVBlock = wvblk32.sys,4

[SCSI]
WinVBlock = "WinVBlock Driver"

Which [HardwareIdsDatabase] entry relates to WinVBlock?

 

Interesting that the entry wvblk32.sys = 1,,,,,, 4_, 4,1,,, 1,4 is in the [SourceDisksFiles.x86] instead of [SourceDisksFiles] section :dubbio:

I doubt SourceDisksFiles* makes a difference at given case.
[SourceDisksFiles] is processed always: x86 and amd64 OS.
[SourceDisksFiles.x86] is processed at x86 OS

http://reboot.pro/to...up/#entry141578
http://reboot.pro/to...dd/#entry184412

In general, adjust txtsetup.sif and winvblk.inf:
wvblk32.sys is referenced once at [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services]

#44 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 02 June 2014 - 05:39 PM

cdob - please help clean my driver WinVBlock_0.0.1.8_Prefetch_1_clean.zip



#45 Blackcrack

Blackcrack

    Frequent Member

  • Advanced user
  • 458 posts
  •  
    Germany

Posted 03 June 2014 - 04:45 AM

this driver it is interesting for Reactos.org also, like i think ..

because 100% driver compatibility  with XP and up .. :)

 

best regards

Blacky



#46 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 03 June 2014 - 03:27 PM

Idea, not tested: use WVBlk32 always

txtsetup.oem
[Disks]
disk = "WINVBLOCK DISK",\winvblk.inf,\

[Defaults]
scsi = WVBlk32

[scsi]
WVBlk32 = "WinVBlock Driver"

[Files.scsi.WVBlk32]
driver = disk,wvblk32.sys,WVBlk32
inf = disk,winvblk.inf
winvblk.inf
[Version]
Signature="$Windows NT$"
Class=SCSIAdapter
ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}
Provider=WinVBlock

;truncated: winvblock integrated in txtsetup.sif - x86 only
 
[Manufacturer]
WinVBlock=WinVBlockDriver

[WinVBlockDriver]
"WinVBlock Bus WVBlk32"=WVBlk32, DETECTEDInternal\WVBlk32, Detected\WVBlk32,Root\WinVBlock, Detected\WinVBlock

[WVBlk32]
AddReg=DisablePrefetcher

[DisablePrefetcher]
HKLM,"System\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters",EnablePrefetcher,0x00010001,0x1
;HKLM,"System\CurrentControlSet\Control\CrashControl",AutoReboot,0x00010001,0x0

[WVBlk32.Services]
AddService=WVBlk32,0x00000002,Service
 
[Service]
ServiceType=0x00000001
StartType=0x00000000
ErrorControl=0x00000001
ServiceBinary=%12%\wvblk32.sys
Does nlite support disable driver signing requirement? Then set this option.

#47 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 03 June 2014 - 05:49 PM

Idea, not tested: use WVBlk32 always

Very thx cdob :clap: Cleaned by you, the driver works well. Now to integrate WinVBlock just use only nLite :1st: :thumbsup:

WinVBlock_clean_x86.zip



#48 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 07 July 2014 - 06:05 PM

Now I want to test WinVBlock on WinXP x64, please help update txtsetup.oem and winvblk.inf for x64 driver

 

Thx.



#49 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 08 July 2014 - 04:58 PM

Now I want to test WinVBlock on WinXP x64, please help update txtsetup.oem and winvblk.inf for x64 driver

Idea:
however WinVBlock0.0.1.8 textmode setup loads drivers, next a blue screen.
No cursor, no message, just a plain blue screen, endless.
title XP64 first part
map /dummy.vhd (hd0)
map --mem /XP64.iso (0xff)
map --hook
chainloader (0xff)

The sample files, fails to load here:
[Disks]
disk = "WINVBLOCK DISK",\winvblk.inf,\

[Defaults]
scsi = wvblk32

[scsi]
wvblk32 = "WinVBlock Driver x86"
wvblk64 = "WinVBlock Driver amd64"

[Files.scsi.wvblk32]
driver = disk,wvblk32.sys,wvblk32
inf = disk,winvblk.inf

[Files.scsi.wvblk64]
driver = disk,wvblk64.sys,wvblk64
inf = disk,winvblk.inf


[Version]
Signature="$Windows NT$"
Class=SCSIAdapter
ClassGUID={4D36E97B-E325-11CE-BFC1-08002BE10318}
Provider=WinVBlock

;truncated: winvblock integrated in txtsetup.sif

[Manufacturer]
WinVBlock=WinVBlockDriver,,NTamd64

[WinVBlockDriver]
"WinVBlock Bus wvblk32"=wvblk32,DETECTEDInternal\wvblk32,Detected\wvblk32

[WinVBlockDriver.NTamd64]
"WinVBlock Driver wvblk64"=wvblk64,DETECTEDInternal\wvblk64,Detected\wvblk64

[wvblk32]
AddReg=DisablePrefetcher

[wvblk32.Services]
AddService=wvblk32,0x00000002,Service32

[Service32]
ServiceType=0x00000001
StartType=0x00000000
ErrorControl=0x00000001
ServiceBinary=%12%\wvblk32.sys

[wvblk64]
;required?
;AddReg=DisablePrefetcher

[wvblk64.Services]
AddService=wvblk64,0x00000002,Service64

[Service64]
ServiceType=0x00000001
StartType=0x00000000
ErrorControl=0x00000001
ServiceBinary=%12%\wvblk64.sys

[DisablePrefetcher]
HKLM,"System\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters",EnablePrefetcher,0x00010001,0x1
HKLM,"System\CurrentControlSet\Control\CrashControl",AutoReboot,0x00010001,0x0


#50 reboot12

reboot12

    Frequent Member

  • Advanced user
  • 287 posts
  • Interests:WinXP, Debian, OpenWrt, gPXE, iPXE, BIOS, UEFI, Coreboot, MS VirtualPC, VMware
  •  
    Poland

Posted 08 July 2014 - 06:46 PM

however WinVBlock0.0.1.8 textmode setup loads drivers, next a blue screen.
No cursor, no message, just a plain blue screen, endless.

Yes, I have exactly the same issue - plain blue screen if use winvblock.ima from RMPrepUSB but this is only if try install WinXP x64 to dummy.img.

However WinXP x64 install OK from RAM-ISO (WinVBlock) direct to HDD. I test both drivers:

  • winvblock.ima (RMPrepUSB) + F6 while install -> this working but after end install in Device Manager is Unknown Device
  • made new WinVBlock_x64_TXT driver and this work OK after integrate in nLite (WinVBlock appears in SCSI, RAID section of Device Manager and set Prefetch to 1 like driver version x86 :-)

5926949m.png







Also tagged with one or more of these keywords: xp, memdisk, grub for dos, iso

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users