At the time I created v2.2 build 199 I wasn't able to read the INFs from the WinPE directory because the files were in Unicode format. I have since found a way to convert the Unicode into ANSI from which I can read/modify during the build process. This will be included in the next version.
I'll take a look at that Copy Muppy you posted. I was planning on using the same method as before (xcopy) but with a visual progress bar on the AutoInstall screen.
As for changing the shell, this isn't a feature I will be including, mostly because I've developed my to do a specific task (automate the windows installation process). Adding the option to change the shell changes the goals I have set for the program, as well as adding more complexity (and possible confusion) for the end user.
Also, changing the shell just wouldn't work. My AI.EXE shell takes care of bootup password protection, the formatting of the hard drive, windows installation etc, as well as working with the encrypted WINNT.SIF (setup answer file).
By changing the shell you open a security hole; your encrypted answer file would no longer be as secure. A user could potentially use the alternate shell to obtain access to your admin passwords in the WINNT.SIF.
AutoInstall CD-ROM Builder
#42
Posted 31 July 2005 - 07:16 AM
Justin-Credible, on Jul 30 2005, 10:38 PM, said:
At the time I created v2.2 build 199 I wasn't able to read the INFs from the WinPE directory because the files were in Unicode format. I have since found a way to convert the Unicode into ANSI from which I can read/modify during the build process. This will be included in the next version.
I'll take a look at that Copy Muppy you posted. I was planning on using the same method as before (xcopy) but with a visual progress bar on the AutoInstall screen.
As for changing the shell, this isn't a feature I will be including, mostly because I've developed my to do a specific task (automate the windows installation process). Adding the option to change the shell changes the goals I have set for the program, as well as adding more complexity (and possible confusion) for the end user.
Also, changing the shell just wouldn't work. My AI.EXE shell takes care of bootup password protection, the formatting of the hard drive, windows installation etc, as well as working with the encrypted WINNT.SIF (setup answer file).
By changing the shell you open a security hole; your encrypted answer file would no longer be as secure. A user could potentially use the alternate shell to obtain access to your admin passwords in the WINNT.SIF.
<{POST_SNAPBACK}>
I'll take a look at that Copy Muppy you posted. I was planning on using the same method as before (xcopy) but with a visual progress bar on the AutoInstall screen.
As for changing the shell, this isn't a feature I will be including, mostly because I've developed my to do a specific task (automate the windows installation process). Adding the option to change the shell changes the goals I have set for the program, as well as adding more complexity (and possible confusion) for the end user.
Also, changing the shell just wouldn't work. My AI.EXE shell takes care of bootup password protection, the formatting of the hard drive, windows installation etc, as well as working with the encrypted WINNT.SIF (setup answer file).
By changing the shell you open a security hole; your encrypted answer file would no longer be as secure. A user could potentially use the alternate shell to obtain access to your admin passwords in the WINNT.SIF.
<{POST_SNAPBACK}>
I have not checked the encryption / password protection feature yet.
That's why i have made some tests by changing to alternate shell by injecting some files / modifying some hives keys in the ISO before burning it.
The Copy Muppy don't works as expected to be used in your project.
When we select \AI\SOURCE\I386 as source and C:\I386 as destination, the files are copied to destination C:\I386\AI\SOURCE\I386
and the "listing" used in command line use hardcoded paths with drive letter.
Good new if in the next version you are going to use the infs from the original WinPE and read/modify to your needs during the build process.
I will wait patiently for next release.
#43
Posted 31 July 2005 - 11:59 AM
Runtime error '13'
Type mismatch.
same here..
Windows XP SP 2
Nvidia Forceware etc.
Type mismatch.
same here..
Windows XP SP 2
Nvidia Forceware etc.
#44
Posted 01 August 2005 - 09:30 AM
Justin-Credible, on Jul 30 2005, 10:38 PM, said:
I'll take a look at that Copy Muppy you posted. I was planning on using the same method as before (xcopy) but with a visual progress bar on the AutoInstall screen.
Why not try to use an AutoIT script:
Copy with progress dialog... by ezzetabi
call the function with these parameters:
_CopyDirWithProgress("X:\AI\SOURCE\I386\", "C:\I386\")
This post has been edited by Bilou_Gateux: 01 August 2005 - 09:37 AM
#45
Posted 07 August 2005 - 02:08 PM
Still not sure about the runtime error '13' I'm working on two other projects which have a higher priority at the moment, so I haven't had time to check on this.
I used the attached script you suggested compiled into an EXE, but when run from the command line I get the following error message:
I used the attached script you suggested compiled into an EXE, but when run from the command line I get the following error message:
Quote
Line 0 (File "C:\CopyWithProgress.exe"):
Func_FileSearch($sIstr, $bSF=1)
Error: Badly formatted "Func" statement.
Func_FileSearch($sIstr, $bSF=1)
Error: Badly formatted "Func" statement.
Attached File(s)
-
CopyWithProgress.au3 (7.18K)
Number of downloads: 15
#46
Posted 21 August 2005 - 12:08 AM
Will this work with an nLited xp disk. I have tried it but it says Incorrect path to Windows Installation CD when I click on build.
I have also goten the Run-time error '9':Subscript out of range error when I built a quick test disk.
I have also goten the Run-time error '9':Subscript out of range error when I built a quick test disk.
#47
Posted 24 August 2005 - 11:34 PM
Not sure about the subscript error.
You are most likely getting the "Incorrect path to Windows Installation CD" because the i386\winn32.exe can't be found in the path you specified. I haven't used nLite before so I can't say if it will work or not.
You are most likely getting the "Incorrect path to Windows Installation CD" because the i386\winn32.exe can't be found in the path you specified. I haven't used nLite before so I can't say if it will work or not.



Help

Back to top









