grub4dos commandline questions...

[Siginet]

jaclaz had mentioned something in the past about the 'dd' command being used for copying files.

I'm curious exactly how this works.

dd: dd if=IF of=OF [bs=BS] [count=C] [skip=IN] [seek=OUT] [buf=ADDR] [buflen=SI
ZE] 
    Copy file IF to OF. BS is blocksize, default to 512. C is blocks to 
    copy, default is total blocks in IF. IN specifies number of blocks to 
    skip when read, default is 0. OUT specifies number of blocks to skip 
    when write, default is 0. Skipped blocks are not touched. Both IF and 
    OF must exist. dd can neither enlarge nor reduce the size OF, the 
    leftover tail of IF will be discarded. OF cannot be a gzipped file. If 
    IF is a gzipped file, it will be decompressed automatically when 
    copying. dd is dangerous, use at your own risk. To be on the safe side, 
    you should only use dd to write a file in memory. ADDR and SIZE are 
    used for user-defined buffer.

What is IF and OF?

Is this copy from and copy to?

Lets say I wanted to copy CONVERT\XOPO\I386\winnt.sif To $WIN_NT$.~LS\I386\winnt.sif

Is the correct command something like this?:

dd if=(hd0,0)/CONVERT/XOPO/I386/winnt.sif of=(hd0,0)/$WIN_NT$.~LS/I386/winnt.sif

I know this is a new feature... and maybe I am totally misunderstanding its purpose.

Or is there any way possible to run a cmd or bat file from GRUB4DOS? That way I could make simple batch file to copy files for me.

Can someone give me some examples on how this would work?

[Siginet]

ok I actually went into the GRUB4DOS commandline and think my syntax is correct. But I don't think it functions quite how I was hoping.

I kept getting an error that the file did not exist.

So I think the "of" (copy to) file needs to exist. Which is rather odd to me. When the "of" exists then I got an error about it being too small. So does that mean that the file sizes have to match?

[jaclaz]

Yes, this is a limit of the grub4dos command.

dd: dd if=IF of=OF [bs=BS] [count=C] [skip=IN] [seek=OUT] [buf=ADDR] [buflen=SI

ZE]

Copy file IF to OF. BS is blocksize, default to 512. C is blocks to

copy, default is total blocks in IF. IN specifies number of blocks to

skip when read, default is 0. OUT specifies number of blocks to skip

when write, default is 0. Skipped blocks are not touched. Both IF and

OF must exist. dd can neither enlarge nor reduce the size OF, the

leftover tail of IF will be discarded. OF cannot be a gzipped file. If

IF is a gzipped file, it will be decompressed automatically when

copying. dd is dangerous, use at your own risk. To be on the safe side,

you should only use dd to write a file in memory. ADDR and SIZE are

used for user-defined buffer.

Read here:

http://www.boot-land.net/forums/index.php?...=6119&st=35

You must think of dd in grub4dos more like as a command line hex editor than as a copy utility.

It has it's uses, but not for what you wanted to do:

http://www.boot-land.net/forums/index.php?...ic=7138&hl=

jaclaz

Edited August 20, 2009 by jaclaz

[Siginet]

****.

I also tried playing around with NTFS4DOS... but I couldn't seem to have access to any of the files on the usb drive when I booted into ntfs4dos.

Could you maybe give me an idea how to utalize DOS or some sort of commandline utility which would allow me to copy/move files then go back to the grub4dos menu or launch another grub4dos entry?

Thanks

[jaclaz]

Sure, you need BOTH NTFS4DOS AND a USB DOS driver, unless you booted from the stick (NON NTFS) and the USB support is given by BIOS.

Otherwise you could use an image (containing DOS and NTFS4DOS) booted from grub4dos.

Or a Recovery Console image:

http://www.boot-land.net/forums/index.php?showtopic=5316

jaclaz

[Siginet]

Hmm the recovery console sounds like a nice idea. I'll start playing with that and see if I can come up with an automated script to do what I need. Thx!

[Siginet]

Sure, you need BOTH NTFS4DOS AND a USB DOS driver, unless you booted from the stick (NON NTFS) and the USB support is given by BIOS.

Otherwise you could use an image (containing DOS and NTFS4DOS) booted from grub4dos.

Or a Recovery Console image:

http://www.boot-land.net/forums/index.php?showtopic=5316

jaclaz

I have been trying to figure out how to do this but I have had no luck.

Is there any way to use NTFS4DOS without having to type "YES"? I tried to find the pay version... but could not find where to buy it.

So basically if I boot regular dos first then launch ntfs4dos with a usb dos driver I should be able to see my usb drive (Formated with NTFS) and somehow have it autolaunch a batch script to copy the needed files to the correct place.

If someone can at least make me a dos bootable img file that is completely automated to see my ntfs usb stick and point me in the right direction for automatically making it launch a batch file that would be great. Then I will create a batch file that will copy the needed files for converting between different Windows XP OSes.

Thanks,

Chris

[jaclaz]

If someone can at least make me a dos bootable img file that is completely automated to see my ntfs usb stick and point me in the right direction for automatically making it launch a batch file that would be great. Then I will create a batch file that will copy the needed files for converting between different Windows XP OSes.

This might be the right occasion for an old dinosaur to become useful, so, how much are you gonna pay for this?

Seriously, I am perplexed about the actual "fairness" of this.

I mean wouldn't it be a way to "workaround" the only limit they put into the app for personal use?

Since, besides peing picky, grumpy and cheap , I am also paricularly catty , I will tell you that it is possible (with a little limitation that I won't specify)

jaclaz

[Siginet]

I am willing to pay for it if I can find it. I actually was looking for it but could not find anywhere to buy it. I think it only costs like $25 bucks or something like that.

But it would be best if there is some kind of free alternative so this method can be put into the WinSetupFromUSB GUI.

Basically my idea is that WinSetupFromUSB would be able to place an XP OS on the usb stick using the mini ISO method.

Win_Setup

Then if they wished to add another simular OS they would have an option to add only file differences.

It would then make a folder according to that OS Type inside the OS folder (Like Conv\XPPR).

Win_Setup\Conv\XPPR

It would place only the files that are different in that folder.

In the boot menu.lst it would have each different OS listed. If you selected XP Pro OEM it would launch some sort of dos script that would first copy the files from Win_Setup\Conv\XPPO and overwrite the files in \Win_Setup.

Then it would launch the setupldr.bin file inside Win_Setup\I386.

This would save so much space on our usb sicks and allow us to fit so much more on it. Plus it would make creating multi-os usb sticks much easier.

I was hoping something like this would work through presetup... but I could not get it to work no matter what I tried to do. But if it is done before textmode setup it would work perfectly. Or even if we could figure out a way to load the entire install directory into ram and overwrite with the correct Conv files it would be cool. Then this same method could be accomplished from cd/dvds as well. Which would mean quicker installs from cd/dvds too.

[ilko_t]

Siginet, can you list what files are different? Can't find the topic you mentioned them.

I believe this could be easily done via txtsetup.sif, using different source location or source file names for those files.

[Siginet]

dpcdll.dll

EULA.TXT (Not actually needed for install)

OEMBIOS.BIN

OEMBIOS.CAT

OEMBIOS.DAT

OEMBIOS.SIG

PIDGEN.DLL

SETUPP.INI

TXTSETUP.SIF (This can be the same on different OSes)

WINNT.SIF (If one is used)

That should do it.

Let me know if you have any other questions.

I think if we can get the dos portion working before launching textmode setup it will work perfectly.

I can easily help with WinSetupFromUSB GUI by adding some code frome my SetupSourceChanger.exe (Which is made in autoit as well).

[ilko_t]

Is any of them, apart from txtsetup.sif and winnt.sif, loaded and used during text mode?

A couple of ideas:

1) Put the second set of files, renamed, alongside the original set. Use txtsetup directives to rename them while being copied, e.g.:

[SourceDisksFiles]
...
oembi01.bin = 1,,,,,,,2,0,0,oembios.bin
oembi01.cat = 1,,,,,,,,3,3,oembios.cat
...

etc. etc.

2) Copy them in another directory, and use it instead the original one:

[SourceDisksNames.x86]
....
990 = %cdname%,%cdtagfilei%,,\corp
991 = %cdname%,%cdtagfilei%,,\home
992 = %cdname%,%cdtagfilei%,,\oem

Then

[SourceDisksFiles]
...
oembios.bin = 990,,,,,,,2,0,0
oembios.cat = 990,,,,,,,,3,3
...

Since txtsetup.sif is loaded into memory use grub4dos search&replace and change values on the fly.

About winnt.sif- can't recall exactly, but I think it's used if present in the small ISO file loaded. More tests are needed.

Are those files protected by other means, e.g. layout.sif, checksum check or something similar?

[Siginet]

txtsetup.sif:

dpcdll.dll = 100,,,,,,,2,0,0
eula.txt	 = 100,,,,,,_x,2,0,0
oembios.bin = 1,,,,,,,2,0,0
oembios.cat = 1,,,,,,,,3,3
oembios.dat = 1,,,,,,,2,0,0
oembios.sig = 1,,,,,,,2,0,0
pidgen.dll   = 100,,,,,,_x,2,0,0
setupp.ini   = 1,,,,,,_x,,3,3
txtsetup.sif = 100,,,,,,_x,,3

layout.sif:

dpcdll.dll = 100,,102912,,,,,2,0,0
eula.txt	 = 100,,12793,,,,_x,2,0,0
oembios.bin = 1,,13107200,,,,,2,0,0	 
oembios.cat = 1,,7382,,,,,,3,3	 
oembios.dat = 1,,4461,,,,,2,0,0	 
oembios.sig = 1,,6761,,,,,2,0,0
pidgen.dll   = 100,,24064,,,,_x,2,0,0
setupp.ini   = 1,,63,,,,_x,,3,3
txtsetup.sif = 100,,480434,,,,_x,,3

I don't think layout.sif matters in this case though. At least when I create my multiboot DVDs... I create one OS on my disk... then duplicate that layout and overwrite only the different files. I never modify layout.inf and each os still seems to work perfectly.

[Siginet]

Is any of them, apart from txtsetup.sif and winnt.sif, loaded and used during text mode?

A couple of ideas:

1) Put the second set of files, renamed, alongside the original set. Use txtsetup directives to rename them while being copied, e.g.:

[SourceDisksFiles]
...
oembi01.bin = 1,,,,,,,2,0,0,oembios.bin
oembi01.cat = 1,,,,,,,,3,3,oembios.cat
...

etc. etc.

2) Copy them in another directory, and use it instead the original one:

[SourceDisksNames.x86]
....
990 = %cdname%,%cdtagfilei%,,\corp
991 = %cdname%,%cdtagfilei%,,\home
992 = %cdname%,%cdtagfilei%,,\oem

Then

[SourceDisksFiles]
...
oembios.bin = 990,,,,,,,2,0,0
oembios.cat = 990,,,,,,,,3,3
...

Since txtsetup.sif is loaded into memory use grub4dos search&replace and change values on the fly.

About winnt.sif- can't recall exactly, but I think it's used if present in the small ISO file loaded. More tests are needed.

Are those files protected by other means, e.g. layout.sif, checksum check or something similar?

It's been a long time since I have messed with editing SourceDiskFiles and so on.

So from what you are saying bove is we still keep the original info in txtsteup.sif... plus add info to also use the conversion files for each os type... plus have them copied to their own folders.

So something like this based on your example:

[SourceDisksFiles]
oembios.bin = 1,,,,,,,2,0,0
oembios.cat = 1,,,,,,,,3,3
oembi01.bin = 1,,,,,,,2,0,0,oembios.bin
oembi01.cat = 1,,,,,,,,3,3,oembios.cat
oembios.bin = 990,,,,,,,2,0,0
oembios.cat = 990,,,,,,,,3,3

[SourceDisksNames.x86]
990 = %cdname%,%cdtagfilei%,,\corp

Or would this work the same...

[SourceDisksFiles]
oembios.bin = 990,,,,,,,2,0,0
oembios.cat = 990,,,,,,,,3,3

[SourceDisksNames.x86]
990 = %cdname%,%cdtagfilei%,,\corp

From what I understand... the sourcedisksnames.x86 section is specifying a new folder on our disk named "corp" next to i386. Which is represented by the code 990.

So let's say we do this... in our txtsetup.sif file we modify it so that instead of representing the code it has "***" instead.

When txtsetup.sif is loaded into ram it automatically changes all instances of *** to 990 (or the code which represents the OS we are installing).

If this would work it would be great.

I'll do a quick test by manually editing my files on my txtsetup.sif to look into a different folder on the disk for the files and see if the os completely installs correctlly.

[Siginet]

OK... heres what I did to test.

I had a successful usb stick made from the test version of this wisetupfromusb gui in this thread. It is Win XP OEM.

I created a folder "WIN_SETUP\XP\conv\vlk".

Inside the vlk folder I placed all of the files that are different from oem to vlk:

dpcdll.dll
EULA.TXT
OEMBIOS.BIN
OEMBIOS.CAT
OEMBIOS.DAT
OEMBIOS.SIG
PIDGEN.DLL
SETUPP.INI

I also removed those files from the "WIN_SETUP\XP\I386" directory so that setup would not look for them in I386 at all.

Inside the mini XP.iso I edited the txtsetup.sif file:

Added this:

[SourceDisksNames.x86]
990 = %cdname%,%cdtagfilei%,,\conv\vlk

Plus I edited every instance of the above files I placed in the vlk directory to use the code 990.

Windows setup suprisingly went very well!!!

I did have 2 files that it could not find in the guimode portion of setup. One I don't remember the extention but it was an oembios.??? file. The other was the oembios.cat file.

All I had to do was tell setup to look in the vlk folder I created and then setup was fully successful.

So all we have to do is figure out why I got those 2 file errors and we will be able to do this without the need for any dos diskettes! This is a much better method then using dos images.

My next test will be to leave all of the oem files in I386 and see what happens. I am pretty sure I won't get those file copy errors anymore... but I don't know if it will cause a problem because setup may grab the 2 files from I386 instead of the vlk directory. But... since they are oembios files I am pretty certain it will be easy for us to fix this issue.

So basically there will possibly be 2 methods we can use to successfully do this. Either we have multiple mini iso files. Like vlk.iso, oem.iso, rtl.iso... or xppc.iso, xppo.iso, xppr.iso, xpho.iso, xphr.iso... and so on.

Or we can have one iso for pro and one for home which will automatically edit txtsetup.sif in memory.

This is very cool! I also think it will work on a cd/dvd as well! Which means we have completely simplified multiboot disks!

I wonder if we can specify different names for txtsetup.sif file by simply editing the setupldr.bin file. Any instance of txtsetup.sif changed to prosetup.sif or homsetup.sif? I know this is possible with changeing instances of winnt.sif to different names. This way we could have 1 mini iso with 2 different setupldr.bin files and 2 different txtsetup.sif files. (setuppro.bin prosetup.sif) (setuphom.bin homsetup.sif).

Edited December 10, 2009 by Siginet