my2001

Ive tried what you are suggesting, i couldnt get it too work, i even compared the help.xpi to other extensions and edited them, still couldnt get it too work. All this was on the PR release, havent tried it now, but im certain its the same. Oh well! Thanks for your info on that. It's really a pity it doesn't work out as supposed. It would be a really nice and als somewhat clean way of installing what extensions ever by the usual setup routine. I hardly dare to say it must be possible to get this "method" to work anyway but I guess one would have to have deep knowledge of FireFox's own installation process to get there.

Apart from all things already said, I've got a general question: Looking at the unpacked Firefox installer directory there you can also see some .xpi files. And software extensions of Mozilla and Firefox respectively have this xpi ending, too. Soooo ... wouldn't it be possible to edit the config.ini file suitably to let the setup routine install one's own extensions as well in one step? To make it clearer: help.xpi which is one of the default components seems to get installed by the following paragraph in config.ini [Component Help] Description Short=Firefox Hilfe Description Long=Firefox Hilfe Archive=help.xpi Install Size=449 Install Size System=0 Attributes=SELECTED|INVISIBLE|FORCE_UPGRADE Force Upgrade File0=[SETUP PATH]\chrome\help.jar FileCount= 1 Couldn't this be adapted for any xpi extension which should be installed along with the default ones?

Well, as long as you want to use the Firefox installer you most likely won't succeed in integrating those moox builds into the installer based routine. So your presumption to install silently first and then unpack the moox files over your earlier installation is certainly right. And about that 6mb issue ... no comment! By the way: I myself prefer http://firefox.dbltree.com/ -method for a silent installation if you want to include certain extensions, etc. since nobody could explain me what would be the advantages of Simon's method compared to that. And if you just want to have a clean (and silent) install I'd suggest to simply change the config.ini directive "Run Mode=" to "Silent" or "Auto" as described in this file.

Ah, okay, I see! So thanks for ya answer! Most important is that in the case shown above Mozilla as well as its sub entries don't get installed. And you approved this. So I'd say this is less a bug than a cosmetic issue.

Hhm, ja, ich glaub da liegt Pudels Kern begraben. Meine fast, daß wir wir nicht unbedingt vom vom ganz selben geredet ham. *lach* Nun, etwas schon, natürlich. Ich ändere durch mein eigenes Skript ausschließlich die Standardbenutzereinstellungen, die dann später natürlich _ohne Ausnahme_ durch _jedes_ Profil mit der tatsächlichen Erstanmeldung verwendet werden. Sprich: Wenn ich festsetze, daß doch bitte alle Anwendungsdaten im Verzeichnis "D:\xyz" landen sollen, dann gilt das schlicht für jedes kommende Profil. Ich glaub, wenn ich die Sache hier richtig verstehe, dreht sich das Problem WIHUs nun darum, daß Du es ja v.a. wg. der %ThisUser%-Variablen erlauben mußt, u.U. auch für jedes Benutzerkonto voneinander abweichende Verzeichnisse für ein- und denselben Benutzerordner (meinetwegen "Anwendungsdaten") anzugeben? Liege ich da richtig mit meiner Vermutung? Oder red' ich hier am Brei vorbei? *lach*

Hi! Maybe I found a bug, at least it strikes me as one. *hehe* I enclosed an attachement ... let me explain it using the picture: 1.) I click on "Mozilla 1.7.3" --> everything else below gets selected, too. Great! 2.) Then I click on "FireFox 1.0" --> "Mozilla 1.7.3" gets deselected what is fine, too! But ... what doesn't get deselected are the sub entries of "Mozilla 1.7.3" (this is shown in the screen shot) although they should get deselected, right?!?

@SiMoNsAyS that means would not work on a german/spanish localized system. Yes, but I guess with his "****CHANGETHISSTRING****" thingy he means: paths are no longer hard-coded, instead they'll get adjusted. @toe_cutter Aah, i tried it just now, it worked as i guess it should work, tho ill still wait for FUN and simons thingy, one has to try every program Sure, you're absolutely right! Simon's proggy is a great tool as well as FUN will certainly be, both of the developers have spent much time on these tools and supposedly will continue doing so! There's nothing wrong with that.

Hhm, I guess I have to re-read your reply to bring it in connection with my question ... but isn't this what you meant: It's a quotation from http://firefox.dbltree.com/.

Great! Yeah, this is, of course, right, but not an answer to my question (sorry), which still is: WHY use the method described in this thread tho there is this already existing tool available? Is there any advantage of this thread's method compared to that tool (or any future tool still in development)??? btw: here it works fine. Hhm.

I create user accounts during T-12 using net command. There's absolutely no problem doing that because creating user accounts doesn't at the same time mean that their profile data (i.e. files'n'directories) is created on HDD. This only happens as soon as you _really_ log onto the user account, e.g. using Windows logon screen. As I wrote somewhere else here in this sub-forum I use a self-made batch file to create my own registry settings for my user shell folders, i.e. not using WIHU-functions for this purpose due to several reasons not important to be mentioned here. Anyway this batch file is called while in T-12 and works flawlessly. As usual (i.e. I use no special way!) I just change the HKCU-keys and later on every user account inherits these settings made in T-12 - no problem occurs. So, as long as WIHU doesn't need to really log on to another profile as I've described some lines earlier I don't see why you would have to refer to "%SystemRoot%\System32\Config\default" as you have mentioned. I don't have the problem of an empty ntuser.dat; maybe it is empty sometimes, but that's no problem. And as you already know, too: During T-12 you can't log on to another user account because the needed service isn't started yet by Windows. That's I think the biggest limitation of T-12, I guess most users won't even be affected by this. And the same here: I don't need to log on to another user account for creating my user shell folders. It works just by modifying HKCU-keys. So ... what's WIHU's problem with user shell folders?

FUN.EXE! Nice acronym! Hopefully it's also fun for you to write that tool! But the same question here again: why not use the already existing tool I mentioned in my posting above? Just wondering because I somehow don't get why you develop a new tool when another one is already there. Why not try first before you re-invent the wheel? Just saves you some of your spare time.

@chimborazo WOW! This is imho doubtlessly the best and most elegant solution fot this stupid problem! By the way I found out that shmgrate seems to do the same as: rundll32.exe shell32.dll,OCInstall HideOE ... just in case somebody is interested.

@SiMoNsAyS (and others who know): Great thread and thanks for your big effort! I've read it all, but there's still a question: what's this/your method's advantage compared to Bob Templeton's method? Why not use his little tool?

Okay, sure. I'm curious about what those incompatabilities could be.

I never said WIHU can't be run on T-12. As many users here verified WIHU can be started from within cmdlines.txt. if /UseCurrent switch is used, everything works. Hi! Just to clarify: WIHU can definately be run at T-12 as well as batch files and arbitrary applications! By the way this isn't dependend on WIHU, WIHU is just an application among others which can be run flawlessly during T-12. I run it then on my own and it works like a charm for me - I don't even need any command line switch to start WIHU from there. And something about this "SYSTEM"-user: this doesn't matter for WIHU's operation.

WIHU like those other tools is used for automatization since this this its main purpose. And here it's more flexible than batch files, moreover it offers nice features under one skin, not necessarily all of them available in batch files. And don't forget the /autoinstall=0 switch. And about colors: I guess many of the people in here lost their original objective and now end up in doing cosmetic surgery. But this is life. *hehe*

Geez, it's really amazing what the people are longing for. As far as I know up 2 now there is no way to change the font attributes of that countdown message ... and 2 be honest: i don't know why such a so-called "feature" should be implemented. It has nothing 2 do with unattended installations, remeber: usually no1 is sitting in front of the PC.

1.) why??? not necessary, there are system functions already available. Either use "command.x=cmd /c @xcopy ..." or "command.x=cmd /c @batchfile.cmd" and include "cmdow @ /HID" somewhere at the top of the called batch. 2.) Run your app using an AutoIt-script and this little tool gives you control over windows.

Yeah, just what I've said before. There's no real connection any more. HKEY_USERS\.DEFAULT key is only used for pre-logon phase after installation. I didn't manage to change settings in this key which later should show up in default user profile. :/ Well, my message hasn't been intended to be a failure report. *hehe* WIHU is doing its job for me quite well, I use it only while in T-12. And if I come across a problem which bothers me, I'll let u no!

No thats not true. HKEY_USERS\.DEFAULT is always pointing to "%Userprofile%Default User\ntusers.dat" Hhm, strange. I once created some test keys within HKEY_USERS\.DEFAULT and they weren't present in afterwards created user acounts.

just 2 be more precise (& little summary): registry settings during T-12 phase are imported into HKCU hive which at this point equals/points to HKEY_USERS\.DEFAULT since there is no other user account created yet So: just continue to use HKCU. Even if you create other user accounts/groups during T-12 (for example by using the net command & yes, it IS possible) this won't have (negative) effects. Registry stuff will keep being written into default user's profile during T-12. Profile data/files are copied into "%SystemDrive%\{profile dir}\default user" folder whose name and place by the way is also stored in %UserProfile% environment variable; %UserName% doesn't exist at T-12 unless you define it on your own, of course. Later when XP GUI is running in its usual way HKEY_USERS\.DEFAULT settings are loaded and executed when you see the logon screen, i.e. _before_ any user logs on! This means: from then on HKEY_USERS\.DEFAULT hive is no longer connected to the default user's profile! The latter one stores its data now in the accordant folder called "default user" in the profile directory and whenever you create a new user account later on this particular data will be used to create it. And, of course, it'll have all the settings included which you imported to registry/copied to this folder during T-12. So ... changing user shell folders for all user accounts can be done by changing just the appropiate default user profile's registry settings during T-12, preferably by altering HKCU hive. And primary key for that is: "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders"

Hmm, does it mean that you are logged in as SYSTEM but %USERPROFILE%\Default User profile is used at this stage? You're logged in as "SYSTEM" (this user has got admin privs) and at the same time there's no env. var named "UserName" defined. The only thing you can refer to is the existing variable "UserProfile" ... or you just set "UserName" to "default user", but that makes no difference. I just needed it for my script. Generally all registry settings during T-12 are aplied to default user's profile so they'll be present in any user account being created _and_ logged on respectively later on, no matter when. So, yes ... for copying files and stuff %UserProfile% is used, which at T-12 refers to "%SystemDrive%\{ProfilePath}\default user"

Hhm it is possible to change these settings during T-12 but admittedly I don't do this with WIHU due to several difficulties. I wrote an own batch file script for my purposes to achieve what I want, it's more or less complicated. While in T-12 there aren't all environment variables present yet, e.g. %UserName% isn't defined. Here's a list of available env. vars at T-12: In my batch I definied UserName on my own: IF NOT DEFINED UserName FOR /F "tokens=3 delims=\" %%d IN ("%UserProfile%") DO SET UserName=%%d This sets UserName equal "default user" if it's not yet definied during T-12. Maybe u'll need this.

FOR %%d in (xxx yyy zzz) DO ( echo %%d ) That's my basic structure which, of course, works fine. But unfortunately one of my arguments (i.e. xxx, yyy and zzz) contains spaces, e.g. "x xx" and FOR-command recognizes this as two separate argruments then. Isn't there a possibility except /F switch to tell FOR to that one argument contains spaces? I tried to use quotes like 'xxx' etc. but this didn't help. I can't take the spaces out of the arguments b/c my arguments represent registry keys which woulnd't be valid any longer w/o the spaces.

Ah, ic! So both folders could be used by any application in any case, only depends on the developer of the software, right? question #1: if I want to move the appdata folder(s) to another partition should I move both of them?!? question #2: would it be problematic to let both registry entries point at the same folder?