Conditionally writing or deleting a registry value?

[NewsArchive]

I've got an installer I'm building where one of the features is whether
or not one of the installed programs is started at system startup. I'm
putting a value in
HK_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run if this
feature is wanted.

This works fine when installing to a new PC. But what if the install is
a re-install or an upgrade, the previous install had this on, and the
user decides that they no longer want this? How do you set up to delete
the registry value when a feature is off?


Also, is it possible to prime features based on Registry values? I'm
actually also writing a 0 or 1 value to a registry key if a feature is
off or on. On the next install, can I prime the feature settings to the
value of the registry key so the install uses the same feature settings
the user had on the previous install?

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

Hi Ben,

> I've got an installer I'm building where one of the features is whether
> or not one of the installed programs is started at system startup. I'm
> putting a value in
> HK_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run if this
> feature is wanted.

I belive the HK_CURRENT_USER under Vista will not point to the correct user
account since the installer is running elevated. So you might want to
consider using HKLM for that.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

>> I've got an installer I'm building where one of the features is whether
>> or not one of the installed programs is started at system startup. I'm
>> putting a value in
>> HK_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run if this
>> feature is wanted.
>
> I belive the HK_CURRENT_USER under Vista will not point to the correct user
> account since the installer is running elevated. So you might want to
> consider using HKLM for that.

Well, so far on Vista with UAC on, it's working.

Note that for this particular application this is not solely settable
from the installer, so I want it somewhere it won't get virtualized from
non-elevated mode. I'm satisfied with the installer setting a default
(via HKDU, perhaps?), but I've still got the same issues of turning it
off on a reinstall, and of priming the feature from the registry.

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

Hi Ben,

>> I belive the HK_CURRENT_USER under Vista will not point to the correct user
>> account since the installer is running elevated. So you might want to
>> consider using HKLM for that.
>
> Well, so far on Vista with UAC on, it's working.

Have you checked it with a user account that does not have admin rights? If
you are testing this under an account that has admin rights, then that would
also be the HKCU, but if it's an account that doesn't have admin rights,
then I thought the HKCU would change to be the admin account.

> Note that for this particular application this is not solely settable
> from the installer, so I want it somewhere it won't get virtualized from
> non-elevated mode. I'm satisfied with the installer setting a default
> (via HKDU, perhaps?), but I've still got the same issues of turning it
> off on a reinstall, and of priming the feature from the registry.

You can use the "Get Registry Key Value" to read the registry and then "Edit
Registry" to change it. So you should be able to check the value in the
registry and act on it there.

As for the features, if you mean SB "Features" then see Friedrich's reply to
my question about it. Subject "Set Feature to install" posted by me on
"Date: 10 Nov 2008 14:58:55 -0500"

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Arnór,

>> Well, so far on Vista with UAC on, it's working.
>
> Have you checked it with a user account that does not have admin rights?
> If you are testing this under an account that has admin rights, then
> that would also be the HKCU, but if it's an account that doesn't have
> admin rights, then I thought the HKCU would change to be the admin
> account.

You are so completely right!!!!

Friedrich

[NewsArchive]

Ben,

> Well, so far on Vista with UAC on, it's working.
>
> Note that for this particular application this is not solely settable
> from the installer, so I want it somewhere it won't get virtualized from
> non-elevated mode. I'm satisfied with the installer setting a default
> (via HKDU, perhaps?), but I've still got the same issues of turning it
> off on a reinstall, and of priming the feature from the registry.

You should *never* ever do "per-user" configurations from your installer
(running with administrator execution level privileges) in the "modern"
Windows world (that is Vista, Windows 2008 and the upcoming Windows 7).
NEVER!!!!! Why? Because you'll always write to the Admins "current user"
profile! I think this isn't what you are trying to achieve. If you do it,
you'll have a support nightmare soon.

Hope this helps.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

> Ben,
>
>> Well, so far on Vista with UAC on, it's working.
>>
>> Note that for this particular application this is not solely settable
>> from the installer, so I want it somewhere it won't get virtualized from
>> non-elevated mode. I'm satisfied with the installer setting a default
>> (via HKDU, perhaps?), but I've still got the same issues of turning it
>> off on a reinstall, and of priming the feature from the registry.
>
> You should *never* ever do "per-user" configurations from your installer
> (running with administrator execution level privileges) in the "modern"
> Windows world (that is Vista, Windows 2008 and the upcoming Windows 7).
> NEVER!!!!! Why? Because you'll always write to the Admins "current user"
> profile! I think this isn't what you are trying to achieve.

OK, but shouldn't I be able to put these configurations in
HKEY_DEFAULT_USER and have the user-level) application take default
settings from there is they're not already set in HKEY_CURRENT_USER?

> If you do it, you'll have a support nightmare soon.

Happily, this is currently only an in-house application.

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

What OS has an HKEY_DEFAULT_USER ?

The "default" user profile has an ntuser.dat file that becomes the starting
point for the profile for any new user, but that's not a separate registry
hive.

Jane

>
> OK, but shouldn't I be able to put these configurations in
> HKEY_DEFAULT_USER and have the user-level) application take default
> settings from there is they're not already set in HKEY_CURRENT_USER?
>

[NewsArchive]

> What OS has an HKEY_DEFAULT_USER ?
>
> The "default" user profile has an ntuser.dat file that becomes the
> starting point for the profile for any new user, but that's not a
> separate registry hive.

Looked back, and that seems to have come from a misreading of RFL
(Registry Function Library) docs. RFL has it's own alias for
HKEY_USERS\.Default\Software, and I somehow morphed that into there
being a HKEY_DEFAULT_USER. Still, it looks like I should be able to
have the installer put default settings into
HKEY_USERS\.Default\Software\<my co>\<my app>\, and have the
(non-elevated) application use them for defaults in cases where the
application can't find them in HKEY_CURRENT_USER\Software\<my co>\<my
app>. And if the RFL docs have it right, a new user created after
installation will have those settings created automatically.

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

Not sure it works that way, Ben.

check these:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/69674.mspx?mfr=true
http://blogs.msdn.com/oldnewthing/archive/2007/03/02/1786493.aspx

Also sounds as if your docs are refering to the "default user" profile, not
to that part of the registry. As my last post said, that's ntuser.dat in a
different folder on the hard drive.

jf

[NewsArchive]

> Not sure it works that way, Ben.
>
> check these:
> http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/69674.mspx?mfr=true
>
> http://blogs.msdn.com/oldnewthing/archive/2007/03/02/1786493.aspx


So, if you want to store installer-specified defaults somewhere, you're
pretty well limited to using HKLM\Software or mis-using
HKU\.Default\Software?

Ben
- --
Ben Coleman
CTO, Accelerated Design, Inc.
http://www.accelerateddesign.com/

[NewsArchive]

Ben,

I don't claim to be an expert.
But yes, HKLM is for everybody. On Vista, it requires administrator
elevation to WRITE, but any user account can normally READ values. Your
setup program (running elevated) writes information to be used by all users.
If your application doesn't have a Vista-aware manifest, regular users will
APPEAR to be able to write to HKLM (no error messages), but each will
actually be writing to his own virtualized copy, so what one user writes
won't be available to any other user.

HKCU is where the current user's settings are stored.

That dot-Default thing is, AFAIK, what is used when nobody is logged on (as
described in those links I posted).

Jane

[NewsArchive]

Hi Jane,

> But yes, HKLM is for everybody. On Vista, it requires administrator
> elevation to WRITE, but any user account can normally READ values. Your

I just wanted to add to this that I tested the GetReg function in Clarion
and it does open the keys for READ access only, so it is safe to use on HKLM
to read values from unelevated programs:)

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

I said "_normally_ read" because it's possible that some keys or values may
have other permissions set. Registry permissions can be set similarly to
NTFS file permissions (screen shot).

Jane

[NewsArchive]

Hi Jane,

> I said "_normally_ read" because it's possible that some keys or values may
> have other permissions set. Registry permissions can be set similarly to
> NTFS file permissions (screen shot).

Correct. As I said, the GetReg opens the key with KEY_READ. That means
that you can "normally" read them.

Best regards,

--
Arnór Baldvinsson - Icetips Creative, Inc.
Port Angeles, Washington
www.icetips.com - www.buildautomator.com

Icetips product subscriptions at http://www.icetips.com/subscribe.php

[NewsArchive]

Hi Ben,

> So, if you want to store installer-specified defaults somewhere, you're
> pretty well limited to using HKLM\Software or mis-using
> HKU\.Default\Software?

What Jane and Arnór is completely correct.

If you are interested, please read this:
http://www.lindersoft.com/forums/showthread.php?p=25441#post25441

Don't do any per-USER action from an (elevated) installer.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

"What Jane and Arnór said is completely correct."

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder "point. click. ship"
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

You can say that over and over and over again <G>

Jane Fleming

[NewsArchive]

>
> You can say that over and over and over again <G>
>

<BG>.

LOOP
MESSAGE('What Jane and Arnór said is completely correct.')
END

Friedrich