I've no idea what you have came up with so far, but if you are still using WinSetupFromUSB, it would be possible with a bit of cheating to avoid most manual work, if not all.

Latest WinSetupFromUSB versions have an advanced option to launch Q-Dir before start of Setup.

You could rename your script to WinPreSetup.exe, use the same switches as WinPreSetup.exe in it, do your stuff to unhide and mount partitions and launch WinPreSetup.exe (Q-Dir.exe) when needed, passing the same parameters.

Next replace Q-Dir.exe with WinPreSetup.exe, the appropriate architecture and use the advanced option to add Q-Dir.

All files are in <WinSetupFromUSB>\files\winsetup\

Let me know if you are going this way and need details.

I think I know what you mean, thanks. Will test when I'm done with WinNTSetup.

So, guys, what would be the best way to create a tutorial here? Create a new thread an link from Tutorials section?

I've no idea what you have came up with so far, but if you are still using WinSetupFromUSB, it would be possible with a bit of cheating to avoid most manual work, if not all.

Latest WinSetupFromUSB versions have an advanced option to launch Q-Dir before start of Setup.

You could rename your script to WinPreSetup.exe, use the same switches as WinPreSetup.exe in it, do your stuff to unhide and mount partitions and launch WinPreSetup.exe (Q-Dir.exe) when needed, passing the same parameters.

Next replace Q-Dir.exe with WinPreSetup.exe, the appropriate architecture and use the advanced option to add Q-Dir.

All files are in <WinSetupFromUSB>\files\winsetup\

Let me know if you are going this way and need details.

I didn't quite get the part where you want me to convert my script (which is cmd script) to an .exe file somehow. It seems that this has to be done with some sort of compiler like this: http://sourceforge.n...ojects/bat2exe/

I've no idea what you have came up with so far, but if you are still using WinSetupFromUSB, it would be possible with a bit of cheating to avoid most manual work, if not all.

Latest WinSetupFromUSB versions have an advanced option to launch Q-Dir before start of Setup.

You could rename your script to WinPreSetup.exe, use the same switches as WinPreSetup.exe in it, do your stuff to unhide and mount partitions and launch WinPreSetup.exe (Q-Dir.exe) when needed, passing the same parameters.

Next replace Q-Dir.exe with WinPreSetup.exe, the appropriate architecture and use the advanced option to add Q-Dir.

Both Q-Dir versions were replaced with WinPreSetup.exe files. Above script was compiled (vmount and sleep were included) for both architectures and it replaced WinPreSetup.exe files. Q-Dir option was used when working with WinPreSetup.

At the stage of Launching Windows Setup which is the last line in Winpeshl.ini it throws a message box with error could not read virtual disk location. Not sure what to make of it since no other errors are displayed in any other places before.

Googling for this error seems to give no results. Do you know if this error is thrown by WinSetupFromUSB? If so, what does it mean?

The only virtual disk we have here is boot.wim file but it is surely accessible since the script was run from it in the first place.

You'd need to run WinPreSetup.exe with /mountiso="directory/file.iso" parameter first. This will search for this ISO on all available mounted volumes and set location of the imdisk virtual disk created.On next run of WinPreSetup.exe with /startsetup parameter, this location is read and used.

Are you still going to use an ISO as source or flat file structure? When do you mount the ISO if the former?

You'd need to run WinPreSetup.exe with /mountiso="directory/file.iso" parameter first. This will search for this ISO on all available mounted volumes and set location of the imdisk virtual disk created.
On next run of WinPreSetup.exe with /startsetup parameter, this location is read and used.

Are you still going to use an ISO as source or flat file structure? When do you mount the ISO if the former?

Ooooh, I forgot that, sorry. Will test ASAP.

I am not sure to understand this.
Just for the record, the %ERRORLEVEL% varaible is set in NT OS.

Also:
There is no need to use the tmp file, you can use a FOR /F loop to set the drives variable.

Wonko

I do not quite understand concept behind errorlevel and %ERRORLEVEL% but those two seem to be different from the reports on the net. And since it did not fail so far, I do not intend to change it.

Regarding double ifs - this is to ensure our number is in range between 9009 and 9010 (or maybe even 9009 and 9009 ) as far as I'm aware.

You'd need to run WinPreSetup.exe with /mountiso="directory/file.iso" parameter first. This will search for this ISO on all available mounted volumes and set location of the imdisk virtual disk created.
On next run of WinPreSetup.exe with /startsetup parameter, this location is read and used.

Are you still going to use an ISO as source or flat file structure? When do you mount the ISO if the former?

By the way, I don't mind using source files but it does not seem to be possible.

Windows installer wants to see it all on the root partition doesn't it?

You'd need to run WinPreSetup.exe with /mountiso="directory/file.iso" parameter first. This will search for this ISO on all available mounted volumes and set location of the imdisk virtual disk created.
On next run of WinPreSetup.exe with /startsetup parameter, this location is read and used.

Are you still going to use an ISO as source or flat file structure? When do you mount the ISO if the former?

Did that, Works fine.

The only issue seems to be that there's a black window of CMD now displayed behind setup.exe. Only option seems to be to make my bat invisible when compiling..

Well FOR isn't really FOR this kind of thing, is it? Neither is it for splitting strings (unless you're in Assembly ). Looks pretty same to me, even more so considering we are in RAM disk I'll change that, thank you for posting it.

@ilko:

As expected, it went all reboot-sky without /wait.

Regarding your awesome program, I have feedback:

Option for installing on ANY available volume (be it primary partition or not) would be nice.

BCD editing should happen (imho) at the end of copying all files (since if copying wont succeed - you wont be able to use the already-created menu entry anyway), not at the start. As a design suggestion

Option for installing on ANY available volume (be it primary partition or not) would be nice.

I could easily change the advanced option "show all disks regardless interface" or add a new one to show all volumes, on logical partitions as well.

Just have to figure out what to do with the main boot files, where to place them, rather than dumping everything on the selected volume leave it to the user how that will be started, something I don't quite like. On the question "how and why do I use that" I have no answer yet, maybe you could help. Ditto for installing from a hidden partition, WinPreSetup could be easily modified to mount all partitions before searching for the ISO file, but I still don't understand what could be the practical use of that in order to spend time on implementing it.

BCD editing should happen (imho) at the end of copying all files (since if copying wont succeed - you wont be able to use the already-created menu entry anyway), not at the start.

Copying files is the trivial part of the whole process, problems are not expected there, nor ever had any, but are when preparing the source, and editing menu files is at the very end of that preparation.

I could easily change the advanced option "show all disks regardless interface" or add a new one to show all volumes, on logical partitions as well.
Just have to figure out what to do with the main boot files, where to place them, rather than dumping everything on the selected volume leave it to the user how that will be started, something I don't quite like. On the question "how and why do I use that" I have no answer yet, maybe you could help. Ditto for installing from a hidden partition, WinPreSetup could be easily modified to mount all partitions before searching for the ISO file, but I still don't understand what could be the practical use of that in order to spend time on implementing it.

Copying files is the trivial part of the whole process, problems are not expected there, nor ever had any, but are when preparing the source, and editing menu files is at the very end of that preparation.

Glad you got it going.

Well regarding the first option it would be useful in a situation like mine: when people want to integrate what your utility has to offer (windows installation from .iso) into an existing boot environment (SYSLINUX with YUMI in my case) but do not want to mess with ImDisk and such stuff.

Regarding the second - this is purely a safeguard. So that anyone who gets passed this flash drive would not blindly copy trash files onto the boot partition (it will simply be not there) but rather do that with first Storage partition. Also, if this partition gets virus infection or anything like that, boot partition will still work.

Boot volume serves only 1 purpose - booting. It should not be used anywhere else (yes I do realize that under Linux nobody will probably give a daym about the hidden flag and it will still show up)

Hope that helps

@Wonko

I got rid of any kind of variables for disks altogether. Just stuffed in all inside the loop you posted.