As part of the installation process I want the source disc to be copied to the destination drive and then change whatever has to be changed in the registry so that Windows will never ask for the installation disc after it has been installed but know to use the copy stored on the drive instead.

My original idea was that this would happen close to the end of the installation process, but then I started to wonder if it would be possible to copy the disc at a much earlier stage, perhaps soon after the formatting has taken place, and, if possible, get the installer to use the files from the drive instead (which should be much quicker to access from a hard-drive rather than from a CD/DVD (ignoring the additional overhead of the actual copy process)). (Perhaps even ejecting the source disc to signal that it was no longer needed.)

I don't think the initial concept would be too complex to achieve, but I would be happy for any suggestions as to how people would go about doing this.

About my other idea, please let me know if I'm dreaming or if it is really possible, and, if it is, how one would go about achieving this.

Copy the following script, and use it at RunOnceEx or GuiRunOnce. This will do what you want at the end of the build.

Includes x64 script as well (AMD64) which you can remove if only doing a x32 build.

Not sure about coping at the start of the build.

Hope this helps. Cheers

Thanks for this. I will try this when I have some time later in the week.

You could achieve this just as easily by copying your source folder into the $OEM$ directories EG: $OEM$\$$\Source

Then use CDImage to create your disc and it will only save the files once in the ISO but during textmode setup it will copy the files to the Hard drive

Then post install have a script write:



You will have to doublecheck the reg add commands as I use AutoIT Scripts to do that stuff.

I use this method myself, makes for a more streamlined install in my opinion.

I'm not sure I understand but then my understanding of $OEM$ is limited. Basically I though that whatever one places in $OEM$ will be copied, as you say, to the destination during textmode, but wouldn't that mean one has to duplicate the i386 folder within $OEM$ or perhaps the trick is in using CDImage (does it create hardlinks for duplicate files (are hardlinks even supported by the ISO format)))?

--
Update
====

I've now researched this and I've found that CDImage and mkisofs both support a feature whereby they can optimize an ISO so that TOC entries for duplicate files point to a single instance of that file.

Hi,

Sorry I didn't get back to you sooner on this, been busy, but yes as you have found out yourself, cdimage basically optimizes the output iso so that duplicate files are only written to the disc once but the TOC for the disc image shows the file in multiple locations, which makes for a fun size check when you select all the files on a CD and do properties and then sit and wonder how a 700mb CD has got nearly 2Gig's of data!

Have a good one.

Yes, I realized this so I have been checking the size of the ISO files instead. However, they have all doubled in size as part of doing the $OEM$ trick and it was only 5 minutes ago that I realized why this was happening. You see, I have written an HFLISP wrapper that does a bit of trickery but there was a typo in my code which I have just fixed. Now I just have to test my changes and keep you posted on how it went.

For those using mkisofs instead of CDImage. Please note that mkisofs also has support for the duplicate-files feature; however, mkisofs's support is not as comprehensive as CDImage's many options.

For anyone interested, I'm currently using the following options for CDImage and mkisofs respectively in my HFANSWER.ini file (which one will be used depends on command-availability as well as the value of FORCECDIMAGE).

CDIMGSW=-h -j1 -x -ocis -w3 -m
MKISSW=-relaxed-filenames -d -D -N -J -no-emul-boot -no-iso-translate -boot-load-size 4 -duplicates-once

I'm not sure about the -x and -w3 options for CDIMGSW but they seemed good at the time. If anyone knows why I shouldn't use either of these then please let me know.


-A

UPDATE: I am using the above switches with CDImage and achieving 52% compression and the generated ISO works perfectly! (I'm not sure why I'm getting more than 50% but perhaps the source itself has duplicates?)

I have been thinking about how one could go about my original idea of creating an installation disc that would copy the files across and then continue the installation from the drive. My latest incarnation of this idea is that it would probably require a wrapper-installer, probably based on Linux, which would boot to provide the required disk management (i.e., partitioning and formatting of drive(s)) prior to copying across the Windows files from disc to the destination drive and then kickstart the installation from the drive.

How one would go about actually doing this is still beyond me. If anyone has any ideas, please let me know.


-A

I was just about to make a post on a similar topic. I am looking to basically get the i386 folder that is copied over to stay there or to move it to a new location instead of the setup removing all the files.

Have you tried 7yler code above? I was thinking about trying it out using RunOnceEx at the t - 13 stage. At this stage, is SourcePath on the HD so the script is essentially copying from a folder on the HD back to the HD? If so I think this may still be faster than from the CD and is worth a shot. I currently copy from the CD using cmdlines.txt after all the updates are done and it is slooooow.

I have only tried p388l3s's suggestion because I like the way it integrates with the already built-in copy progress that is part of the textmode phase. If this was done any other way then one would need to write something similar to the progress bar provided by DriverPack's KTD option (if I'm not mistaken), but this still looks out of place with the standard installation process. Optionally one could do it silently, but then the installation will appear to have hung while the files are being copied across (something that already is an issue with the many silent installers that I have).

To answer your question about the source path. No, my source is the installation disc, i.e., the CD (or DVD in this case) and yes, it is slow, but at least the textmode option gives you the extra advantage of seeing something happening at a stage when you expect to see files being copied across.

You ought to try p388l3s's suggestion and let me know if you think it improves the user experience of the copy process...

<edit>
CLARIFICATION: The textmode copy process does not provide a progress bar. What it does provide, in terms of feedback, is a simple please-wait-while-copying-files message with the status bar showing the current action taking place.
</edit>

By the way, I use 7yler's "add reg" code instead of p388l3s's code because I like the way he uses environment variables instead of static text, i.e., I use the following code.



What I would like to use though is REG_EXPAND_SZ instead of REG_SZ because then these strings would remain dynamic (currently they become static as soon as they are written to the registry). I just don't know if the two types are interchangeable in this case.

P.S. Is it normal to have the forum's post-editor detach itself from its location when it is double-clicked or is it simply one of my Firefox extensions that is playing up?

I just had a thought about pointing the ServicePackSourcePath key at the source. It doesn't seem right to me. Can anyone justify this please?

Thanks for the info. I think I will try both and see what works well. Shouldn't there be a variable for the files that are located on the drive that are copied by the textmode install? Seems like this would save a lot of time.

I haven't been around for a good long time, but I've been doing pretty much what you want for over 2 years now (earlier posts here by me should show that). What I do is 1. give HSLIP my path as if doing a multiboot CD (SOURCE\) 2. boot from a CD that runs a script that a. gets info from tech (serial #, location, etc) b. attaches to a network share and copies the I386 folder local BEFORE running setup c. run winnt32.exe as follows:




Sorry, just noticed this wasn't in the HFSLIP forum.

Sorry, I don't know enough about textmode to answer this, but I agree, it would save some time, especially since one would not have to scan for duplicates.

Thanks, this is starting to look interesting but I'm not following some things such as...

a) Why do you need to create a multiboot CD when it sounds like you boot from some other sort of boot CD in the first place?

b) What is this boot CD of yours running, some sort of DOS-derivative or what?

I have just come across the Install XP from USB forum here on MSFN. It is well worth considering as an option to this topic.

Is this directed towards me? If so,

a ) I don't create a multiboot CD. I am only creating the source that contains all hotfixes (slipstreamed), so that I do not have to go to Windows Update on each machine that I build.
b ) I created a WINPE (Windoes Pre-Installation Environment) based CD that launches a script that sets up the parameters I would need during setup (such as comp name, OS [xp, tablet, 2003]), copies source files and any additional files I want on each system, then performs setup from network/local source.

If you boot your PC using a WinPE CD, and then format the target drive as a system drive using "format c: /s", are you then able to boot your PC on that drive to a command prompt?

If so, can't you just format the drive from WinPE using format c: /s, then copy the i386 folder, reboot from the target drive, and at the command prompt just do a \i386\winnt.exe?