Archive: Rename Registry Key
Rename Registry Key
Is there a way of renaming a registry key?
[EDIT]I could create a function which exports a key, renames it in the .reg file and reimports it again, but i found that in Win2000 registry files exported from command line are NOT in the standard .reg format, they seem to be compressed or something. Any ideas?[/EDIT]
Vytautas
Actually the information in the last edit is wrong. Win2000 seems to add a bit of binary info after every character and my editor was getting confused by that. Also I tried using the ReplaceInFile Function but it also does not seem to work properly, e.g. on first run it seems to make the file readable be stripping out most of the binary info then if run again it works fine, except for the first 3 chars in the file are still binary and will not allow the file to be merged into the registry. Is there a way to remove all of this binary info from the file or is there a better way to rename a key in the registry.
Vytautas
Attach the exported file and I'll have a look.
But why would you want to do that? Why don't you use what's used in the NSIS installer script? It's so much more efficient! (relating to this thread).
If W2k exports same way as WinXP this is not easy. And i dont know the switch to export in old format (W9x) [REGEDIT4]
I have attached a registry export from Windows XP for the "HCR\NSHFile". If Windows XP notepad opens the file it appears as it should however if any other editor, e.g. HM NIS Edit, it only displays 3 characters and is trimed at first binary bit.
As for the second sugestion it only restores the ".nsi" entry and it should also restore the associated "NSISFile" key in the uninstall.
Vytautas
Yes Brummelchen, W2k seems to export in the same format as WinXP. From futher study of the file format I think it might have something to do with the use of 'wide', multi-byte, characters.
Vytautas
WinXp and Win2K are using Unicode which uses two bytes per character. So instead of seeing, for example, "Windows" you'll see "W i n d o w s" (those gaps are hex 00).
If you look at nsh.reg.txt with a hex editor you can see this quite clearly:
Here are the first few bytes in hex:
FF FE 57 00 69 00 6E 00 64 00 6F 00 77 00 73 00
and here they are in ASCII:
__W_i_n_d_o_w_s_
(using '_' to represent the non-ASCII hex chars)
I don't know much about Unicode, so I cannot add much to this explanation.
Thanks, I gathered as much what I would like to find out is there a way to convert that into NON unicode file, e.g. remove to hex 00 from the file.
Vytautas
As I said earlier I don't know much about Unicode.
You could try making a byte-by-byte copy of the .reg file -- ignoring the first two bytes and stripping out all of the hex 00 bytes so you end up with a simple ASCII file... but that might be too simple-minded a solution to actually work.
It might be worth looking for a utility to convert from Unicode (probably UTF-8 flavour?) to plain ASCII.
The first thing Google turned up was http://www.unicode.org/
Brian
Here is a sample script which turns your nsh.reg.txt file into a readable one using the simple-minded approach I mentioned earlier. The ZIP file also includes the EXE file and sample output file.
Perhaps this will help you develop a solution to your problem?
I found this via google:
Convert Unicode to ASCII.
In Windows 2000 and XP, TYPE offers a simple method to convert Unicode files to ASCII:
TYPE MyUnicode.txt > MyASCII.txt
http://www.robvanderwoude.com/index.html
>> Batchfiles >> TYPE
It works so far - for W9x you have to replace
"Windows Registry Editor Version 5.00"
with
"REGEDIT4"
Thanks pengyou your script worked really well but i would like to suggest one alteration. I think it might be better if you only needed to push only one filename and when converted use the following code to overwrite the file. I would also suggest that you post this function on the NSIS Archive page.
SetDetailsPrint none
delete ${UNICODE_FILENAME}
CopyFiles /SILENT ${ASCII_FILENAME} ${UNICODE_FILENAME}
delete ${ASCII_FILENAME}
SetDetailsPrint both
Glad I was able to help out.
My script was written quickly just to show one way to implement the suggestion I made in an earlier message. The reason it uses two parameters is that I wanted to keep things simple - I was more interested in the loop that does the processing so I did not spend much time thinking about the parameters.
Thanks for suggesting I put the script in the archive - that had not occurred to me. If you want to put your improved version in the archive instead, I don't mind (you can take the credit).
Brian
Originally posted by BrummelchenI tried your suggestion but I could not achieve a reliable way to run the type command, could you post a sample script. The only way I could get to even run the command was in a batch file which I had to modify or create at run-time, however ExecWait did not wait until the batch file finished running so on big files the installer continued before the conversion was finished.
Convert Unicode to ASCII.
In Windows 2000 and XP, TYPE offers a simple method to convert Unicode files to ASCII:
TYPE MyUnicode.txt > MyASCII.txt
sorry - i thought that TYPE is an program - it is only implemented as a command in the commnd line interpreter (command.com or cmd.com)
Yes and there for if you want to use command.com or cmd.com you first have to which OS the installer ir running in and thus your script quickly becomes too complicated. Unless there is another way of achieving this.
Vytautas
First of all, you don't need to restore the NSISFile key, it's useless. The key belongs to NSIS and if someone else uses it it's his problem. The only real value that needs to be restored is the value already restored by the original script.
Now, as for the Unicode. Pengyou, your script only works on some Unicode characters. Not all Unicode characters use just the first byte, that would be a waste of space.
To get the path to command.com/cmd.exe read the %COMSPEC% environment variable. Use:
ReadEnvStr $0 COMSPEC
My script was not intended as a general purpose Unicode conversion utility -it was merely created to handle the sample nsh.reg.txt file from an earler message.
In an earler message I said:
You could try making a byte-by-byte copy of the .reg file -- ignoring the first two bytes and stripping out all of the hex 00 bytes so you end up with a simple ASCII file... but that might be too simple-minded a solution to actually work.as I knew that this approach only works in some cases. However, it seemed that this was a suitable case, so I created the script as a starting point for further development.
The possibility of putting the script in the archive occurred. I just wanted to make sure you understand this script doesn't work in most cases where Unicode is really needed so you'll put an appropriate warning.
Originally posted by kichikI was thinking in more general case, i.e. you have a program that indexes .txt files so you want to add an extra option in the .txt file association and thus you modify the 'txtfile' key. However when uninstalling you program you should also restore the 'txtfile' key to the previous state. Just a thought although it looks like the script might become too cumbersome and complex and it probably won't affect the registry condition too much.
First of all, you don't need to restore the NSISFile key, it's useless. The key belongs to NSIS and if someone else uses it it's his problem. The only real value that needs to be restored is the value already restored by the original script.
If you add something to txtfile you can just delete it when uninstalling. I can't think of a situation where you'd need to restore the original key which doesn't belong to your program. I would be glad to know if you have thought of something else I couldn't see...
Yes, I guess that as long as care is taken when associating files to create a key that is descriptive of not only the file type but also the program that it is associated with it this problem should not occur. As for an example if a text editor associates '.txt' files to 'txtfile' key and then deletes the 'txtfile' key on uninstall, then '.txt' files will no longer be associated with notepad even though the value in '.txt' was restored.
Vytautas
The developer should know not to take over keys that do not belong to him. txtfile belongs to Notepad and should stay that way. I'm afraid only Microsoft can afford to take that kind of a name for their own program.
I have modified my archive page relating to this subject and added information about the pitfalls of using 'common' descriptions for file types.
Thanks for all your help,
Vytautas