Djé

Yzöwl, - That's not fair: You're the batch-guru, you can allow yourself the batch-guru-powered-FOR blablabla. But I fail to understand the purpose of the 1st Findstr with line numbers. (And BTW, you inversed the 2 reg keys so the 2nd Findstr doesn't find anything). - One day you'll have to tell me where you find those switches. I tried <-|/><?|h[elp]> on Regedit, to no avail. I suppose this /A is for ANSI? - I have no bickering to quell; except maybe with myself taking your writings for the holy 'batch for dummies' without checking the result: your xcopy command in restore mode is missing the /I switch to fix the "QL folder doesn't exist yet at first RunOnceEx" bug, as is now mentionned on the 1st page. But who would know that before stomping on it? -Now, I must agree, the Unicode is not needed for those 2 reg keys. But if this script is to serve as an example for other registry export (who knows), non English systems users may be happy to find it as it is. Especially as Unicode is used at no expense since the last version of the script. And thanks again for all the fish your other ideas that I re-used in this script.

That's interesting! What system is that? win2k? Did you test it on Unicode files? Are your registry exports (reg or regedit) in unicode format? Do they really have 'V5.00' instead of 'Version 5.00' in the header? Can your CMD.EXE read/write unicode without the /U switch? Oh I see: You like simple things. Your system must be MacOS!

Actually, what I miss the most with the code tag is the syntaxical coloration. this would be so much better and faster to catch the the aim and mechanism of a piece of code. For example, I know pretty well Visual Basic (for application but hey...) but I could never read any Visual Basic code posted on the forum. Especially those with a lot of comments to explain the code!!!! - AutoIt forum has an [AutoIt] tag, although not so much used. - PHP has a buit-in syntaxical coloration function. - modules for other languages (js, sql, etc.) do exists in php. I used to use them in a wiki (wikini). Why not implementing a few of them?

Well, you have to distinguish between favorable statistics, which are made on the spot at (grossly) 82.56% from unfavorable statistics for which I don't have the figures right now.

First post updated with new version. Enjoy!

New version (1.0) released in the 1st post: - corrected a bug introduced with the previous version. - **tested in real situation**

Do you mean that you get an error with the following command?: REG IMPORT mytweaks.reg What does it says when you do?: REGEDIT mytweaks.reg(You can add an optional /S switch to import it silently) If this command fails as well, It may be you file format. The file has to start with the following line: Windows Registry Editor Version 5.00???followed by a blank one??? If you file has this header but you still get the error, attach it so we can have a look.

See? Everybody can use FINDSTR on a unicode file! Well, it may sound better, but what about looking better? And I'm not talking about mixing FINDSTR & FIND, nor about the useless information displayed by FINDSTR in the middle of the screen output... ...Did you check the result ? Nice Chinese characters, aren't they? やっぱり。! Now you're probably true: this FOR instruction may not be necessary. But you'll have to finish what you've started! [EDIT] After toying a bit with your proposition, it appears that you may not even be true: Only the magic of the FOR (may it be with youce!) seems powerful enough to make FINDSTR work on Unicode streams. [EDIT2] I apologize. After toying much more with your proposition, it appears that you may well be true: First post is updated with a new version exempt of any FOR loop ... and even improved, thanks to Yzöwl's advices. Now, sorry but I'm not sure it is a 'reduced' version, nor that it is less 'batch-guru-powered'.

2- Done now! 4- Well, not directly, but yes, you can use FINDSTR on the unicode export... 3- Sorry, I've edited my previous post while your were writing yours.

@Delprat: 1- Here (XP home sp2), %~dp0 HAVE the trailing \ even at the drive's root. 2- Now they are warned (I'll update the 1st post) 3 & 4- I think you did not get the mechanism because these are the exact 'features' that I use (or overcome): I export 2 different files and then append one to the end of the other, avoiding to repeat the header. BTW, .reg files are Unicode (at least on non US sytems), that is the other (hidden) trick. [EDIT]: I apologize: there are some remains of a previous version in the file which which may have lead you to your 3rd point. . The above description of the process still holds. @muiz: Next version will be improved to take care of spaces in path (that may have been the cause of your problems) @Everybody: I love you There may be also a problem with a value exported from STREAMS\Desktop, making the other values not sticking. This value will be removed in next version. And BTW: Restoring ONLY work before Explorer starts (RunOnceEx is OK): after this it will be too late, Explorer will use its own values, overwriting yours on logoff.

WHAT says this ? The script??? I think not: the script has no error message. Only a cute final message in bachup mode. So could you please be more specific and tell me -when this error occurs? -what program causes it? -if you have specific things in your taskbar? You may want to attach a screenshot (of both your taskbar & the error msg), your taskbar.reg or anything relevant. Help me to help you.

Stuff it with your applications. Run it. Backup done. Have it called with the "-r" or "/r" option (RunOnceEx or whatever). Restoration done. Basta. * >>> Version 1.0: NEW **TESTED @RunOnceEx**: - Bug fixed (introduced in the previous version only): the restore would hang @1st RunOnceEx because the Quick Launch folder doesn't exist yet!!! * Features added in the previous version: - Reg files merging: simpler & much faster. Special dedicace to Delprat. - Now also works on Win2K. ©redit to Delprat & Yzöwl (use REGEDIT /E instead of REG EXPORT). - Better command line option handling. ©redit to Yzöwl. - Should be quite waterproof now. - Submited for Yzöwl9001 certification! * Features added in the 'almost original' version: - Spaces-in-paths-proof, prettier & cleaner! ©redit to muiz. - Filters out the "Upgrade" value of the ...\Streams\Desktop key to avoid possible problems. WARNINGS: -Of course, in backup mode, it has to be in a writable location. -Restoring only works BEFORE Explorer starts (RunOnceEx is OK). >> After, it will be too late: Explorer will create/use its own values, overwriting yours on logoff. taskbar1.0.cmd

Yep, as mentionned here: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist Maybe you can't load it because it is already loaded...

Well No need to wait for 1.6. firefox 1.5.0.4 is out and implements the -silent switch. So attached should be the definitive -setDefaultBrowser.cmd It is designed to work in a very broad variety of situations. If you find it non working in yours, I'd be curious to know about... Firefox_setDefaultBrowser.cmd

Delprat, fly is right: HKU\.DEFAULT is NOT the default user's NTUSER.DAT, it's system32\config\default (used when no user is loged in). @T12 HKCU maps to HKU\.DEFAULT Right after that, the default user's NTUSER.DAT is created from by copying config\default. That is why your tweaks imported to HKCU are still working. You can check all these by using the method you gave (loading the default user's NTUSER.DAT). The outcome of this is: you never need to import to both HKCU & HKU\.DEFAULT: - @T12 they are the same, - right after T12 nothing from HKU\.DEFAULT will go anymore to the default user. Loading stuff to the default user's NTUSER.DAT is still the best and cleaner way to import setting for all users (before they're created of course) because it doesn't leave any dirt in HKU\.DEFAULT.

@The Black Cloud First I apologize if I have offended you. I must admit my words may have seemed a bit hard. Then I have to agree with you. What was common practice at that time may no more be good practice now. As you suggest, things have evolved. AutoIt is now well spread and babylon uses different ways. Anyway, I take the opportunity to thank you for your original idea, and also for the specific part of the Speech engine, which I would never have though off without you. It remains unchanged in the following versions!

Oh that's you, The Black Cloud? You've changed your login? How do you do? Out of joke, it completely failed for me. Besides it is a very dirty way of doing. Much more dirty than using additional programs. At least because the useless -if not harmfull- stuff it loads in the registry will stay there, while addition progs don't. Anyway, good luck. Maybe someone -or yourself- will find a way similar to the 1st post.

Kel, in your %OEM% archive in the 1st post, you may be missing the "Theme" folder in between the "Resources" & "Royale" ones. At least to match the "DllName" value of the included "Theme.reg".

May I ask why you would need/want to avoid an AutoIt script? Edit: this is in no way an inquisitorial question. It's just out of curiosity and to see if I can help in any way. So don't feel any obligation to answer it. The *way* in the first post may have only worked for its author (see all those useless reg keys, see the big binary ones...). I'm not saying that such a method cannot work ever, but at the very least you would need to know a bit better about the registry.

I'm also still running WPI through the WPI.cmd, but not for the same reason (actually, I want windows to wait for RunOnceEx to finish! so please, leave it as an option, one way or another). My reason is that I want to be able to run WPI with different config.js files, depending on the computer, the user, or Shiva knows what. AFAIK, unlike other post-installers, WPI cannot accept a Programs List (config.js) path as an argument on the command line. So I have it as an argument to WPI.cmd, which copy the file to the WPIScripts folder before running WPI.hta (see attachment). The command in RunOnceEx is then similar to: "Z:\Post-Installers\WPI_5x\WPI.cmd" "D:\install\Applications\Djé-config.js" Now if WPI.hta could accept this kind of argument and do the job itself... that would be cool. PS: since those different config.js files may require different matching useroptions.js, I found a trick which dispense me of copying this other file as well: I reassign the necessary options' variables at the top of config.js. It works great! So don't change anything WPI.cmd

Ok, I understand what you mean. For the guessing, I think this would fail at some point or another in some weird situations. Anyway as far as I am concerned, you're first proposition is enough: I don't write manually the config.js but use an Excel application to do it automatically from custom program lists maintained in Excel. So I can have this FileExists condition written very easily (my lists have separate fields for path, filename and arguments). I was just waiting for the new (and stable!) WPI 5.0 syntax before releasing the next version with new features like (for WPI) User options, direct config.js file writing (not just clipboard) & command generation.

So if I understand well, the user would have to decide if (s)he wants to check for the existence of the file, and this for each command ... and which would fail on commands not starting with a valid path like regedit or rundll32 commands anyway. And how does this work when there are arguments in the command? What does FileExists() say? * Or maybe I'm mistaken and you specifically feed the file path/name to FileExists(), not just tick a checkbox to validate the command. What about tweaking the FileExists() function so it would only check the existence of the whole command if the command starts with a valid path: if FileExists(left(cmdLine,3)) then ...

@Denney Great! that's what I was looking for. But what about if Shell.Run cannot find the command? Won't we get a javascript error messing up everything? I'll make some tests right now! @mritter Sorry for hijacking you work . Thank you very much anyway.

Oups, You're right. My bad. I don't know where I had my head when I looked at this. My 'command runner' lines now looks like: CheckInstaller(); if ((programs[i].cmd1 != null) && (path(programs[i].cmd1) != '')) { cmdLine=substituteCommand(programs[i].cmd1); WriteLogLine("Cmd1 Success: '"+cmdLine+"'"); InstallShell.Run(cmdLine,1,true); programs[i].success=true; }And it works perfectly on RunDLL32 The thing is now: how to deal with buggy cmdLine(s) to make use of the loging feature?

[EDIT]: This is no bug. It was my fault, as Denney pointed it out below. Forget this post. Oh I see. Sorry for 'moving the knife back and forth in the wound' (almost a literal translation of a French idiom, but I think you'll get the meaning). It seems that this FileExists(cmdLine) was there for a good purpose: Shell.Run itself is not able to handle all commands correctly: If I hack the file and remove the FileExists(cmdLine) tests, I get a Javascript error: *removed* So it looks like the solution will not be as easy... @Denney I was not talking about the return code of the program itself, but of the Shell.Run function, which -I imagine- could be something like 1 - command run successfully 0 - command failed But usually things are more complicated in real life