my2001

Hhm, well, dunno what exactly your aim is but mine is an unattended installation. In best and hopefully usual case I won't be sitting at my computer and watch what's going on. Moreover I'll switch off my screen. And regarding the numerical system of WIHU: yes, indeed, this can be annoying sometimes. But I grouped my ini entries so there aren't really many which I would have to re-number. And in most cases order of installation is more or less unimportant, so I just add new programs to the list's end. *hehe* And now that my ini is somehow complete there won't be many changes in future I guess.

There are two user shell folders dealing with application data: 1.) AppData 2.) Local AppData What's the difference? Which applications will store their data where and why?

German here ... it is this funny language many people complain about. *hehe* Hhm, and especially Bavarian ... which many Germans complain about. *lol*

Yeah, you're so **** right! And unfortunately you might be right with what you've said about the total amount of RAM. But doesn't anyone know a little freeware tool?

Good question, I've also tried it with no success. And at the end of the installation there is this stupid reboot which I can't suppress till today.

yeah, I knew that already. But mem tells me only how much conventional ram (640 k) is there, not the total amount of RAM in system.

Hi! I'm searching for a preferably internal command in DOS box which tells me how much RAM there is at all in the system. Is there anything like this? Or will I have to use an external tool? thx

Hhm, finde ich auch nicht so nötig. Aber was generelles: WIHU eigent sich vorzüglich, um auch _während_ der Windowsinstallation seine Proggis aufs System zu bringen! Ich führ es z.B. via cmdlines.txt zum Zeitpukt T-12 aus und es klappt wunnerbar! Warum sollte es das da auch nicht tun?

Hhm ... cancel button is shown but greyed out, can't click on it!

Hi! First of all thank's a lot for your good explanation! It has been really useful for me! Here's just a link to an external site with similar explanations for those who might need it: http://www.indigorose.com/forums/showthread.php?t=5012

Browse the links above I provided and you'll get your information. What I like at T-12 stage is that all kinds of changes are imported into "default user"'s profile because at this time it's the only existing one. So all your HKCU-registry tweaks, etc. apply to _all_ later on created users by default. And this is fine! Moreover at T-12 the OS is quite fully loaded so there's almost no restriction in installing applications then. This also means the user won't really dare to cancel installation process here because Windows isn't yet installed completely. All you have to do is to call WIHU in cmdlines.txt. So it'll be executed at T-12 and that's it.

Okay! 1 minute should be enough for most processes.

thx. and sth about time: I asked about _cmdlines.txt_ which is run during windows installation as u certainly know. And I doubt testing this will last only 10 seconds. *hehe* I know how batch files work but didn't know for how long environment in cmdlines.txt in particular is saved. I was unsure about if cmdlines.txt is like a container/master batch file and everything in it is available everywhere in it. So unfortunately u obviously performed a test under normal circumstances for me whose result I already knew and didn't help answer my question. But don't worry ... I've found the desired answer already.

Unfortunately I don't have the time to test it so I dare to ask: Assume my cmdlines.txt is as follows: [COMMANDS] "batch1.cmd" "batch2.cmd" Will propietary variables (i.e. set command) definied in batch1.cmd for the first time still be available when batch2.cmd is run? thx!

Mhh, freut mich, danke Dir!

Auch hier recht netten Dank, ich brauch' des wirklich, des hilft mir Probleme mal kurz ausm Weg zu räumen und dennoch den Rest der Installation zu erleben. *hihi* Ähm ... just a further proposal, of course, it's up 2 u 2 implement it: maybe not activate the cancel button immediately, maybe after a timeout period of perhaps 5 minutes per each installation step to avoid misuse. I think this isn't unimportant because many use WIHU to perform a completely unattended installation and don't want to offer the user any possibilities to interfere. So a timeout could help here. And maybe you could even add an ini setting like Timeout=<Sek> or timeout.x=<Sek> ... but as I said: up 2 u!

Ah, wunderbaren Dank, sehr nett!

T-12 is the short way to say: 12 minutes left to end of installation. Time is displayed in the left pane while installation is running, u certainly know it. For more information look here: http://www.windows-unattended.de/schritt12...?&func=Schritt3 and http://greenmachine.msfnhosting.com/READING/cmdlines.htm T-13/T-12 has its own advantages. My problem is that while Reader tries to install it suddendly opens a dialog box and wants me to put in the installation disk. Of course, clicking "OK" doesn't help. I don't know where this comes from, but I'm sure I'll find a solution.

I don't think your problems are related to WIHU. As long as WIHU starts your desired application all paths seem to work and WIHU's task is for this reason done. I face many problems, too, with my unattended installations, but they originate from other things. Here with me I don't seem to be able to install Acrobat Reader while at T-12 stage of Windows installation. Don't know why but it's just as it is. So I had to find another solution.

Thanks for your answer, still strange cuz here it doesn't work. It only adds everything _behind_ the colon. But if you tell me it's generally working it has to be sth different. ic

Hi! I use the following code to add a registry key to RunOnceEx. But because of the colon (":") after the letter "K" this is condemned to fail. Why? In this case reg add only adds the stuff after the colon, everything in front of it is utterly ignored. Is there any way to make this work regardless of the colon? thx a lot!

Sometimes a program called by command.x directive doesn't end itself properly. Instead it waits endlessly for something to happen which isn't going to happen. Conclusion: WIHU won't continue its work because the sub-process isn't finished yet ... and never will be. Only way to continue with Windows installation is to abort WIHU and leave out the remaining installations. Is there a possibility to give the user in WIHU the chance to abort the processing of a crashed installation program and let WIHU continue with the remaining installations? Another off-topic question: what about your changelog? is it still kept update?

When I press the cancel button in WIHU a question box is displayed wheter the user wants to abort WIHU or not, that's fine! But ... WIHU doesn't pause its work as long as the question box is shown! I really favour changing this behaviour. As long as the message box is displayed WIHU should pause its work in the background and not go on processing ini directives - except the current one already running, of course. And after the user decides not to abort WIHU it can continue the work.

Maybe this is a bug or a function not yet implemented: Sometimes I misspell the path to some programs I want to install with WIHU, e.g.: command.x=wrong_path\test.exe But WIHU doesn't add a failure entry in its log when a command.x-program can't be executed cuz it isn't found at the given path. Instead WIHU continues immediately with the following command directives in the ini file. So my request would be: if a program can't be found at its given path ... 1.) plz add a log file entry describing this problem 2.) don't let WIHU execute subordinate command-directives, i.e. if command.5 can't be found, command.5.0, command.5.1, etc. shouldn't be executed as well.

Sorry ... should have asked Benjamin first: it's already possible to do what I requested! Use ini directive "status.x=0x800000" to achieve it. This marks the respective password as expired, so the user will have to type in a new one at next login attempt. example: user.5=Administrator status.5=0x800000