[xpman]

I am trying to get the following path imported into RunOnceEx '%windir%\firstrun.bat'.

1. I found no way doing it with .reg files (version 4)

2. Using REG.EXE from the Win98 resource pack leads to a strange padding of the value

REG ADD HLKM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\001=%%windir%%\firstlog.bat REG_EXPAND_SZ
leads to
001 and "%windir%\firstlog.batat"
in the registry

Exporting this value leads to a binary string in the .reg file

3. Using regedit, I do not seem to be able to use REG_EXPAND_SZ, only binary values

4. Lastly, HLKM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\001 also leads to a Key named HKLM under HKEY_LOCAL_MACHINE

I accepted 1, but problem 2 keeps bugging me. How can I correctly use REG.EXE?

This post has been edited by xpman: 06 August 2010 - 09:06 AM

[Yzöwl]

Why do you feel that registry value data of type REG_EXPAND_SZ is necessary?

[pointertovoid]

At least the version 4 of Regedit looks like the right choice. I use such files on W95b as well.
In case you try to port reg files from Regedit5 to Regedit4, be careful that Regedit5 use the Unicode character set. You won't notice that in many text editors... But Regedit4 refuses these files.

[MDGx]

From what I know Win9x [95, 98 + ME] OSes do not support complex/expanded registry values, like REG_EXPAND_SZ, REG_LINK, REG_MULTI_SZ, REG_RESOURCE_LIST, REG_FULL_RESOURCE_DESCRIPTOR + REG_RESOURCE_REQUIREMENTS_LIST. Some of these values might be interpreted as binary [hex(3)] in 9x, but not correctly.
More info here + here.

Such values are properly understood, read from and written to only in WinNTx OSes: NT4, 2000, XP, 2003, Vista, 2008 + 7.
REG.EXE command line tool from Win98 Resource Kit (RK) may be able to read [even if erroneously] some of these values, but to my knowledge is not able to write or modify such values properly. If one tries, reg values beyond hex(5) will be written improperly or not at all. There are rare cases when the registry can be corrupted by trying to write such complex/expanded values into the registry under 9x OSes.
All REG.EXE versions from WinXP, Win2003 [%windir%\system32] + their respective RKs are fully aware of and support all these values 100%.
Unfortunately we can't use reg.exe from XP/2003 under Win9x OSes, and I don't think KernelEx can help in this case, unless some1 with registry programming knowledge is willing to rewrite the entire reg.exe tool for use with 9x OSes.

HTH

[jaclaz]

MDGx, on 10 August 2010 - 11:00 AM, said:

Unfortunately we can't use reg.exe form XP/2003 under Win9x OSes, and I don't think KernelEx can help in this case, unless some1 with registry programming knowledge is willing to rewrite the entire reg.exe tool for use with 9x OSes.

Have you checked this?
Russian:
http://paullee.ru/regstry.html

Google Translate:
http://translate.goo...en&hl=&ie=UTF-8

jaclaz

[MDGx]

jaclaz, on 10 August 2010 - 11:05 AM, said:

MDGx, on 10 August 2010 - 11:00 AM, said:

Unfortunately we can't use reg.exe form XP/2003 under Win9x OSes, and I don't think KernelEx can help in this case, unless some1 with registry programming knowledge is willing to rewrite the entire reg.exe tool for use with 9x OSes.

Have you checked this?
Russian:
http://paullee.ru/regstry.html

Google Translate:
http://translate.goo...en&hl=&ie=UTF-8

jaclaz

Wow, Unicode support in native DOS. That must be a first...

Thanks a lot for this great tool, did not know about it.

Although, I don't think it helps much with the lack of support for complex/expanded/extended registry hex values, which unfortunately were not implemented in 9x OSes.
Some expanded values can be written to the registry in 9x through INF or even REG files [will be seen as hex(7) eventually], but the actual information inside such values won't be read/interpreted properly. For example, values higher than hex(7) won't be "understood" at all.
I think this needs a registry API update for 9x OSes [brought up to XP/2003 level, for example], and an updated tool to take advantage of those APIs, similar to reg.exe from 2000/XP/2003, eventually an updated regview.exe.
Also, software that reads from/writes to the registry and might take advantage of complex reg values, needs to be made compatible with those reg APIs too.

Best wishes,
MDGx

[jaclaz]

MDGx, on 12 August 2010 - 11:40 AM, said:

Wow, Unicode support in native DOS. That must be a first...

Thanks a lot for this great tool, did not know about it.

Happy to have given you something new to chew on.

The idea is that most part of the needs is already coded and it is Open Source, so it's not needed to start from scratch (if anyone is willing to do something about this)

Would you be willing to try the newish MS way to manage Offline Registries ? :
http://www.boot-land...showtopic=11212
http://www.boot-land...showtopic=11312
maybe it could work on 9x (kernelEx or whatever)

OT but not much :
http://www.databack4...c/rtkf_eng.html
http://www.ctuser.net/
http://www.ctuser.ne.../reg2exe_en.htm

jaclaz

[xpman]

Thanks for all the hints.

There are of course limits to the support for REG_EXPAND_SZ as I already noticed when exporting such a value; however, there are tons of places where environment variables are used in the registry, so I would not believe that expansion strings are not supported at all. The reason why I would like to have this is to be able to use variables like %windir% - which seems impossible otherwise.

From all the postings, I could still not find an answer to my "padding problem"; looking at ways like reg2exe does not see promising. In this case, I could simply export the hex dump of any path from the registry; this is not exactly what I wanted, I wanted to have readable strings (even in in a cmd file for reg.exe and not in a .reg file).

Still, I got lots of new reading material, maybe something turns up. Again, thanks for the replies.

[Yzöwl]

I still don't get why it is a requirement!

After you've imported the reg settings, unless you actually change the location of %windir%, then having the data contain the variable serves no purpose, (especially since it is only for data to be read/executed once only at login.).

Another thing you may like to look into if you are still insistent upon this pointless exercise is to import the registry data including variable as REG_SZ and see if the variable is read appropriately when read/invoked within the system.

[5eraph]

It's been a very long time since I've meddled with Windows 98. The following empirical evidence may not apply.

In Windows XP/2003 some registry keys seem to require REG_EXPAND_SZ. One that comes to mind is "HKCU\Control Panel\Cursors\Schemes". If REG_SZ is used instead for a value and the environment variable %SystemRoot% is not used then the following error message is displayed when selecting the mouse pointer scheme defined at that value.

 Cursors.png (8.14K)
Number of downloads: 5

After the user selects Yes at the message, Windows will automatically change the data type to REG_EXPAND_SZ and replace the relevant portions with %SYSTEMROOT%.

It's not a fatal error, obviously, but it's annoying.

This post has been edited by 5eraph: 15 August 2010 - 10:57 AM