340 replies to this topic

[misty]

Hi Erwan,

I like the new syntax (I think) and am happy to update the guide. I'm also really happy that work on offlinereg has been restarted

Very quick note on the new version and syntax -

D:\offlinereg_2018.01.24.v2>offlinereg tempreg2.dat classes\A\B\C\D createkey nobackup

It works to create the required key structure, however a nobackup key is also created (i.e. "HKLM\MYHIVE\classes\A\B\C\D\nobackup" key is created).

That's it for me tonight due to a computer ban at home!

More tomorrow.



Misty

[erwan.l]

Hi Erwan,

I like the new syntax (I think) and am happy to update the guide. I'm also really happy that work on offlinereg has been restarted

Very quick note on the new version and syntax -

D:\offlinereg_2018.01.24.v2>offlinereg tempreg2.dat classes\A\B\C\D createkey nobackup

It works to create the required key structure, however a nobackup key is also created (i.e. "HKLM\MYHIVE\classes\A\B\C\D\nobackup" key is created).

That's it for me tonight due to a computer ban at home!

More tomorrow.



Misty

 

 

About the nobackup key created, see this post.

 

It should be

D:\offlinereg_2018.01.24.v2>offlinereg tempreg2.dat classes\A\B\C\D createkey " " nobackup

As a whole, this "nobackup" is not a nice one to do.

I need to consider [options] as pointed out by Wonko.

[erwan.l]

P.s. Should I wait a few days until development calms down? It's hard for me to hit a moving target!!!!

 

Actually I will halt developpement there for a while (like a few days...) and focus now on the 64 bits version which will take me until the week end I guess.

 

-import has been improved (a bit)

-createkey and deletekey have been improved as well

-multi level path is now handled

 

Once I am done with the 64 bits, i will come back on the command line syntax.

[Atari800XL]

Thanks again for the continued development!

 

Just an example of how I would use this tool: (1) Download a new Windows 10 preview (using mkuba50's excellent UUP dump, in fact just the php scripts), new 17083 preview out today, as luck would have it (2) Direct apply of the UUP files (cab, esd) with imagex 15063 (using "/ref uupfolder\*.*"), (3) Drivers, bcd, bootsect etc (4) Offlinereg would be perfect to do some "pre-reboot/ pre-setup" settings (disable setup animation, disable Edge/ SystemRestore/ UAC/ Defender etc) - reboot

 

Using Offlinereg would be so much cooler than using reg files!

Of course I see lots of other uses as well... Thanks again for this great tool!

Edited by Atari800XL, 24 January 2018 - 08:47 PM.

[erwan.l]

Thanks again for the continued development!

 

Just an example of how I would use this tool: (1) Download a new Windows 10 preview (using mkuba50's excellent UUP dump, in fact just the php scripts), new 17083 preview out today, as luck would have it (2) Direct apply of the UUP files (cab, esd) with imagex 15063 (using "/ref uupfolder\*.*"), (3) Drivers, bcd, bootsect etc (4) Offlinereg would be perfect to do some "pre-reboot/ pre-setup" settings (disable setup animation, disable Edge/ SystemRestore/ UAC/ Defender etc) - reboot

 

Using Offlinereg would be so much cooler than using reg files!

Of course I see lots of other uses as well... Thanks again for this great tool!

 

Happy you like it.

Interested to see real life examples.

[erwan.l]

Surprisingly, it must be a lucky day : I was able to load my offlinereg code in my x64 environement and faced only a very few errors.

 

In a matter of minutes, I was able to compile a 64 bits version

 

Exe and dll are now in the zip file.

 

I was not able able to test all commands but the half dozen I tried worked smoothly.

[misty]

Guide updated for use with the latest release of OfflineReg (Date modified: 24/1/2018 18:01).

I have not checked it for spelling errors or typos and have not used the updated (and work in progress) command syntax.

Also, I've not had time to test the new 64-bit build - sorry Erwan.

Misty

[misty]

Not sure I'll have to bother testing the 64-bit release after all. They both have the same checksum

Name: offlinereg64.exe
Size: 119296 bytes (0 MB)

SHA1: 45F33876D7085907FB4A2D394602744B609B0885

Name: offlinereg.exe
Size: 119296 bytes (0 MB)

SHA1: 45F33876D7085907FB4A2D394602744B609B0885

[Atari800XL]

No, you don't have to test it, leave that to me :-)
(have my 64bit-only PE always at the ready).

It don't work, I guess (as you noticed) something went wrong and Erwan forgot to include the correct .exe

[erwan.l]

Not sure I'll have to bother testing the 64-bit release after all. They both have the same checksum
 

Name: offlinereg64.exe
Size: 119296 bytes (0 MB)

SHA1: 45F33876D7085907FB4A2D394602744B609B0885

Name: offlinereg.exe
Size: 119296 bytes (0 MB)

SHA1: 45F33876D7085907FB4A2D394602744B609B0885

 

My bad, my zip update went wrong.

Fix in progress.

[Wonko the Sane]

My bad, my zip update went wrong.

Which one?
The automagical process that is convenient and foolproof and prevents you from naming files with their version?



On second thought, regarding the "nobackup" issue, another possible - alternate - solution could be to set an environment variable, similar to what findpart:
http://www.partition...m/utilities.htm
does.
The tool is read only until you set the findpart variable to "edit", i.e.:

SET findpart=edit

If the "nobackup" is the only option *needed* this would allow to leave the parsing mechanism the same, and adding only a check *like*:

IF DEFINED offlinereg IF %offlinereg%==nobackup ....

Wonko

[misty]

@Erwan.l
I agree with Wonko that the nobackup option would benefit from some changes and have decided to add my two cents to this discussion.

Where it fits in the OfflineReg syntax is up for debate. My concern is that in its current implementation it is very misleading as nobackup does actually make a backup. Current process, using an example of TEMPHIVE as the target registry hive -

save changes to new file TEMPHIVE.new > save existing TEMPHIVE as TEMPHIVE.old > rename TEMPHIVE.new to TEMPHIVE

To my mind this is not a nobackup scenario and results in three different operations being carried out for each command executed.

As Erwan currently uses a fixed position for different parameters, and ALL supported commands (with the exception of import?) MUST have at least the following parameters (with <key> being replaceable with empty quotes " ")....

OfflineReg.exe <hive> <key> <command> etc

...my proposal would be to use the following new syntax -

[*]OfflineReg.exe <hive> <key> <option> <command>[/*]

Where <option> is mandatory and is either -

• read (for use with the non-writable operations getvalue, enumvalues, enumallvalues and enumkeys)
• write (for use with all operations that add or remove data, including delete*, create*, import)

And the write option in my opinion should write directly to the hive if this is possible, without any backup operations at all.

And for those rare occasions where someone might want to make a backup, add a new command that the user can run if/when they actually need it. Maybe something like -

OfflineReg.exe <hive> <new_hive> backup

A manual backup operation makes more sense, as in it's current implementation if multiple operations are carried out the backups (e.g. TEMPHIVE.old) are replaced with each successive operation anyway.

Hope this makes sense.



Misty

EDIT - the advantage of this approach is a) move nobackup from the end parameter position and b ) it will allow in most cases a fixed position with the only exceptions being the new/proposed backup command and the existing import command.

[darren rose]

I also agree something needs to change in relation to the "nobackup" switch - as Misty says it is misleading as it does still create a backup and I personally would rather it just wrote straight to file and didn't do any backups - unless I specifically ask it to do - so perhaps a "backup" switch instead

 

Keep up the great work - I hadn't heard about this tool until Misty recommended it to me recently, and it has already proved extremely useful to me

[Atari800XL]

I really like Misty's ideas. Skipping the (repeated) backups also would make it faster, I guess.

For the case I mentioned earlier, I would use a single "backup" operation (in the testing stage), followed by a couple of registry writes. After my reg writes are tested and working, I would remove the backup step completely.

 

I don't plan on doing tons of reg settings after apply [before setup starts] (most can be done after setup, in my "PostInstall" tool), but some (the ones I mentioned) just have to be done *before* setup runs.

After all, this is how JFX does it in WinNTSetup (he also uses offreg.dll, I believe).

Edited by Atari800XL, 25 January 2018 - 05:59 PM.

[Wonko the Sane]

@Misty

Where does "value" and "type" go?

At the end and only when the command "needs" it?

 

The current behaviour of nobackup is actually confusing, you are right .

 

Still the use of the option /R and /W at the beginning would allow the parsing just fine, as said, and IMHO it makes little sense to need to specify "read" for "getvalue", a program normally defaults to either  "read" or "write" mode, in the case of offlinereg, due to the possible damages it can be done, it should default to "read" mode always, unless the /W (or "write") option is explicited.

 

For all that matters yet another proposal, let's remove the whole "nobackup" stuff, and go for manual backup  , and let us remove also the "read" or "write" option completely

 

On command line a "write" operation will need a "Y" confirmation.

 

For batches, either the environment variable or a:

ECHO Y | offlinereg.exe ...

 

Could be used.

 

[erwan.l]

Which one?
The automagical process that is convenient and foolproof and prevents you from naming files with their version?

 

I'll pretend (again) I did not get it

Reviewing my release "model" (...) is on my todo list but closer to the bottom rather than the top.

[erwan.l]

zip re uploaded

 

X64 should be fine now.

 

Tests welcome.

[misty]

Still the use of the option /R and /W at the beginning would allow the parsing just fine, as said, and IMHO it makes little sense to need to specify "read" for "getvalue", a program normally defaults to either "read" or "write" mode, in the case of offlinereg, due to the possible damages it can be done, it should default to "read" mode always, unless the /W (or "write") option is explicited.

Good points. However in my opinion the default (only?) option should be write for all commands that modify the target hive and read for all commands that read values. And ignore my previous suggestions as it would indeed be simpler to just get rid of the need for the read or write option I suggested. Any need for a backup of the target hive to be completed manually using a backup option that should be relatively easy for Erwan.l to implement?

I would theorise that any current backups are rarely used, if at all? If I want one, I can take one using a copy command at the moment. The suggested manual backup option to OfflineReg would however make life easier.

In what scenario is anyone likely to execute a series of commands without the nobackup option? Lets say for example that we run the following -

OfflineReg D:\PATH\System ControlSet001\A\B\C\D createkey
OfflineReg D:\PATH\System ControlSet001\Control setvalue "New Value" "New Value Data" 1

The first command will add the new key(s) to one hive, and the second will add the new key+value+data to a different hive. If we want to execute both commands on the same hive we would have to manually carry out similar steps to those automated by using the nobackup option.

I would argue that it is far more likely that someone would be running the following instead, in order to write both commands to the same registry hive -

OfflineReg D:\PATH\System ControlSet001\A\B\C\D createkey " " nobackup
OfflineReg D:\PATH\System ControlSet001\Control setvalue "New Value" "New Value Data" 1 nobackup

Which at the moment would carry out six different operation. And that's not including the adding of the keys and data - its due to the create and renaming currently in use.

I personally only use the nobackup option for all modifcation type commands as it saves me the hassle of manually deleting the old hive and replacing it with the new hive. The proposed writing directly to a hive and not automating the backup could now take the following form, directly writing to the target hive without any backups -

OfflineReg D:\PATH\System ControlSet001\A\B\C\D createkey 
OfflineReg D:\PATH\System ControlSet001\Control setvalue "New Value" "New Value Data" 1 

Much cleaner syntax in my opinion, with fixed positions of parameters still maintained if this makes it easier for Erwan to code.

And if for some reason a backup is required, then using the proposed new commands -

OfflineReg D:\PATH\System D:\PATH\System.bak backup
OfflineReg D:\PATH\System ControlSet001\A\B\C\D createkey 
OfflineReg D:\PATH\System ControlSet001\Control setvalue "New Value" "New Value Data" 1 

And in what cases would a recursive switch be required? In regards to the deleting of keys with subkeys, the exisiting deletekeys command completes this function just as easily as the following example might, without the need for any code changes -

OfflineReg /R D:\PATH\System ControlSet001\Control\MyKey deletekey

And a recursive parsing of keys would be a bloody nightmare in a large hive! I'm really not sure when this would be needed?

Anyway - lots for erwan to think about. Good luck!



Misty

[erwan.l]

On second thought, regarding the "nobackup" issue, another possible - alternate - solution could be to set an environment variable, similar to what findpart:
http://www.partition...m/utilities.htm
does.
The tool is read only until you set the findpart variable to "edit", i.e.:

SET findpart=edit

If the "nobackup" is the only option *needed* this would allow to leave the parsing mechanism the same, and adding only a check *like*:

IF DEFINED offlinereg IF %offlinereg%==nobackup ....

Wonko

 

if popular, it would take me one line of code to check a dos env variable for nobackup.

a simple set %offlinereg%=nobackup before calling offlinereg could do.

[misty]

zip re uploaded
 
X64 should be fine now.
 
Tests welcome.

Will do. As if I needed an invitation. The magic words zip re uploaded were enough

[misty]

Quick test with the 64-bit release running the following batch (used in the updated guide with the 32-bit version) -
 

offlinereg64.exe D:\PATH\System " " create
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue NewValue NewValueData 1 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue "New Value" "New Value Data" 1 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue ThreadingModel Both 1 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue " " %%SystemRoot%%\System32\actxprxy.dll 2 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue "Reg Binary Test" 80,00,00,00,00,00,00,00 3 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue BootDriverFlags2 28 4 nobackup
offlinereg64.exe D:\PATH\System A\B\C\D\E\Test setvalue PreshutdownOrder "wuauserv gpsvc trustedinstaller" 7 nobackup

There are a lot of operations competed though

win64
saved to D:\PATH\System ok
win64
setvalue NewValue ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue New Value ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue ThreadingModel ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue   ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue Reg Binary Test ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue BootDriverFlags2 ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System
win64
setvalue PreshutdownOrder ok
saved to D:\PATH\System.new ok
renamed D:\PATH\System to D:\PATH\System.old
renamed D:\PATH\System.new to D:\PATH\System

EDIT - forgot to mention that the above commands all appear to have worked fine and all keys were present and correct when the new hive was mounted and viewed in the Registry Editor.



Misty

EDIT 2 - screenshot

[erwan.l]

Hi Gents,

 

About the (in)famous nobackup, I am conscious that it is not very practical.

 

But one thing to keep in mind : by nature, the offline registry function orsavehive can only save to a new file.

It cannot save to current file.

Early offlinereg version was always saving to a new file.

 

I introduced the nobackup to "ease" batching so one did not have to perform the copy/delete/etc by batch for each operation.

This is offlinereg performing this task.

 

Now what I can do is perform this task by default and leave it up to the "batcher" to eventually backup the file before any operation.

 

Regards,

Erwan

[Atari800XL]

Thank you very much for the 64bit version!

[Wonko the Sane]

@Misty
Imagine the hypothetical /R (Recursive, not /R as Read) switch as something similar to the /S switch in DIR (to be used when reading an existing hive), as said:
 

Example : OfflineReg "c:\temp\system" a_key_path enumkeys <- here a /R (recursive) option may be added (or a /S for analogy with DIR)
 
These may possibly be merged into one by using an option
Example : OfflineReg "c:\temp\system" a_key_path enumvalues
Example : OfflineReg "c:\temp\system" a_key_path enumallvalues

 
(you probably missed it, distracted by a squirrel )
 
@erwan.l
 

a simple set %offlinereg%=nobackup before calling offlinereg could do.

No. it won't.
 
SET offlinereg=nobackup sets the environment variable "offlinereg" to value "nobackup"
SET %offlinereg%=nobackup sets the environment variable represented by the current value of "offlinereg" (if any) to value nobackup or silently fails if the variable offlinereg is not defined

D:\>set offlinereg
Variabile di ambiente offlinereg non definita

D:\>set %offlinereg%
Variabile di ambiente %offlinereg% non definita

D:\>set offlinereg=nobackup

D:\>set %offlinereg%=nobackup

D:\>set %offlinereg%
nobackup=nobackup

D:\>set offlinereg=

D:\>set offlinereg
Variabile di ambiente offlinereg non definita

D:\>set %offlinereg%=nobackup

D:\>set offlinereg
Variabile di ambiente offlinereg non definita

Sorry gotta go, it's squirrel dinner time:

 

Wonko

[misty]

...But one thing to keep in mind : by nature, the offline registry function orsavehive can only save to a new file.
It cannot save to current file....

bullocks!

 

...I introduced the nobackup to "ease" batching so one did not have to perform the copy/delete/etc by batch for each operation.
This is offlinereg performing this task...

Now that you have explained the limitations of the orsavehive command this is a very welcome addition.
 

...Now what I can do is perform this task by default and leave it up to the "batcher" to eventually backup the file before any operation....

That gets my vote

And for any stupid enough not to manually take a backup when messing with the feared registry - that's your lookout!

Misty

P.s. BTW - I haven't bothered with any backups!

P.p.s. I promise not to come crying if I hose my system!!!!