[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.

Quote

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

This post has been edited by jaclaz: 20 August 2009 - 01:56 AM

[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...?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]

jaclaz, on Aug 23 2009, 04:14 PM, said:

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...?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]

Siginet, on Dec 6 2009, 10:17 PM, said:

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]

ilko_t, on Dec 9 2009, 04:45 PM, said:

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).

This post has been edited by Siginet: 09 December 2009 - 10:15 PM

[Siginet]

@ilko_t I placed a winnt.sif file inside the mini iso... but it doesn't seem to recognize it. Any ideas?

[ilko_t]

Nice progress, much closer now

Quote

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

Not keeping the original info, amend it just as you did.

Have you tried the first approach? They are two different, not completing each other. Seems easier to me, plus GUI may find them right away.

As for the missing files at GUI- have a look at setup log files in \windows, there could be something interesting.

About winnt.sif- I must be wrong then, as I wrote, don't quite recall if it was applied or not, apparently not.

For hexediting setupldr.bin for winnt.sif- would work just fine, for 2003 versions checksum check patch is needed:
http://unattended.ms...xp/view/web/16/
Need modifype.exe

Quote

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

This may help:
http://gosh.msfn.org/txtsetup.htm

[Siginet]

Quote

Have you tried the first approach? They are two different, not completing each other. Seems easier to me, plus GUI may find them right away.

I'm not sure how that would work. Because then we would be overwriting the files. How would we be able to differentiate which files would be the ones copied over in the end? Maybe I misunderstand the idea?

Actually everything works perfectly now. Except for winnt.sif not working in the mini iso. Is there a way to make that possible?


Actually... maybe it's better to just edit the setupldr.bin to use a different winnt.sif file for each os.
So we can have multiple setupldr.bin and txtsetup.sif files on the mini iso and multiple winnt.sif files in the XP\I386 dir.

for instance...
Rename setupldr.bin to setupldr.vlk (not sure if changing the extension will be an issue)
Rename all instances of txtsetup.sif and winnt.sif to txtsetup.vlk and winnt.vlk in the setupldr.vlk file.
Rename the winnt.sif file in the XP\I386 directory to winnt.vlk

And do the same steps for oem and rtl files as well...
setupldr.oem, txtsetup.oem, winnt.oem
setupldr.rtl, txtsetup.rtl, winnt.rtl

This post has been edited by Siginet: 10 December 2009 - 04:29 AM

[ilko_t]

Quote

I'm not sure how that would work. Because then we would be overwriting the files. How would we be able to differentiate which files would be the ones copied over in the end? Maybe I misunderstand the idea?

oembi01.bin = 1,,,,,,,2,0,0,oembios.bin

tells setup to rename oembi01.bin to oembios.bin while being copied.
So alongside the original oembios.bin, you out oembi01.bin for corp, oembi02.bin for vlk and so on and replace in txtsetup.sif oembi01.bin with the desired one. It will be copied to the destination as oembios.bin. No need to create extra folders and 990 directives for the different files.

As for winnt.sif- it also could be put on a virtual floppy, mounted by grub4dos. Have a set of floppies gziped and mount whichever you need. Or have a blank floppy image and dd the desired winnt.sif to it.

Quote

Actually everything works perfectly now.

What was wrong with the missing files during GUI part?

Quote

And do the same steps for oem and rtl files as well...
setupldr.oem, txtsetup.oem, winnt.oem

Using txtsetup.oem as a file name wouldn't be a good idea, it's already hardcoded and read for other purposes, use txtsetup.oen or something similar.

[Siginet]

ilko_t, on Dec 10 2009, 11:33 AM, said:

oembi01.bin = 1,,,,,,,2,0,0,oembios.bin

tells setup to rename oembi01.bin to oembios.bin while being copied.
So alongside the original oembios.bin, you out oembi01.bin for corp, oembi02.bin for vlk and so on and replace in txtsetup.sif oembi01.bin with the desired one. It will be copied to the destination as oembios.bin. No need to create extra folders and 990 directives for the different files.

Oh ok I understand now. Yeah that does sound easier in a way. But... if we used the other method then we would only have to change the folder name that the files are going to. Since all of the txtsetup.sif files will be pretty much the same. The 990 code would allready be changed to represent the folder where to get the files.

Quote

As for winnt.sif- it also could be put on a virtual floppy, mounted by grub4dos. Have a set of floppies gziped and mount whichever you need. Or have a blank floppy image and dd the desired winnt.sif to it.

Yeah I think we need to play with different methods to figure out which one will work the best.

Quote

Quote

Actually everything works perfectly now.

What was wrong with the missing files during GUI part?

In my next test I left the oem files in I386 (In my first test I deleted the files from I386). When I did this Windows Gui setup went perfect without any problems. In the end I had a fully operational Windows XP Pro Corp. Then I did 2 other tests with mini ISOs for OEM and RTL which also worked perfectly.

Quote

Quote

And do the same steps for oem and rtl files as well...
setupldr.oem, txtsetup.oem, winnt.oem

Using txtsetup.oem as a file name wouldn't be a good idea, it's already hardcoded and read for other purposes, use txtsetup.oen or something similar.

Yeah I was thinking that when I wrote it. Guess we'll have to come up with a different schema for renaming the files.

-------

I also think we need to add svcpack.inf to the list of different files as well. Because if someone integrated different programs into the svcpack method. For instance when integrating some oemscan addons for pre activating oem installs.