VI Security and Windows API functions - ShGetFolder

[rolfk]

---

battler. wrote:

I'm reading/writing to LOCAL MACHINE\Software in Vista.  It seems to be working but I can't find the entry when I use VI registry functions.  When I make registry entries as part of installer it works ok.

You say that I cannot write to the Programs folder.  What about the applications folder, isn't that in the Programs folder?  I suppose writing to the apps folder is a safer option.

---

Vista does something like shadowing. This means any write access (and consequently read access later on) to protected parts (file system but also registry) will be instead directed to a shadow area for the current user in his local profile. The only way to write really to those protected areas is by explicitedly running the application with administrator rights even when logged in as administrator already.

This is what one gets when designing security into a system after the fact.

Rolf Kalbermatter

[battler.]

Thanks but I'm using LabVIEW 8.0.

[dan_u]

Here it is in 8.0

[battler.]

Thanks,

What is this telling me again?

Can I use this .dll to call other Windows functions?

[rolfk]

---

battler. wrote:

Thanks,

What is this telling me again?

Can I use this .dll to call other Windows functions?

---

Please!!! Try to make some effort.

1) This is a VI not a DLL!

2) You can not simply use this VI to call other Windows API functions, but you can use the Call Library Node that is used inside to call other Windows API functions and create according VIs.

And most importatnely:

3) Don't ask how do I interface other Windows API functions!!!

Instead:

- Read the documentation about the Call Library Node

- search on here, on LAVA and anywhere on the net about tutorials for interfacing DLL

- be prepared to learn quite a bit about C programming, C datatypes and such before you get such other DLL calls working

- and please don't ask us to implement Windows API xyz and zyx and, and, and for you

Rolf Kalbermatter

[dan_u]

---

rolfk wrote:

Vista does something like shadowing. This means any write access (and consequently read access later on) to protected parts (file system but also registry) will be instead directed to a shadow area for the current user in his local profile. The only way to write really to those protected areas is by explicitedly running the application with administrator rights even when logged in as administrator already.

---

Be careful, don't rely on that. For instance the config file VIs don't do that. They seem to bypass the virtualization or shadowing or however you call it. For instance if you want to modify the application ini file (which is always at the same location as the application, i.e. in the program files folder) you'll need to set the permissions on the ini file or the write will fail.

[rolfk]

---

dan_u wrote:

---

rolfk wrote:

Vista does something like shadowing. This means any write access (and consequently read access later on) to protected parts (file system but also registry) will be instead directed to a shadow area for the current user in his local profile. The only way to write really to those protected areas is by explicitedly running the application with administrator rights even when logged in as administrator already.

---

Be careful, don't rely on that. For instance the config file VIs don't do that. They seem to bypass the virtualization or shadowing or however you call it. For instance if you want to modify the application ini file (which is always at the same location as the application, i.e. in the program files folder) you'll need to set the permissions on the ini file or the write will fail.

---

Yes because the config file VIs are built on the normal LabVIEW File IO functions which call directly the Windows File IO API. To get the virtualization for INI files you have to call the Get/SetPrivateProfile() Windows APIs.

Rolf Kalbermatter

[dan_u]

---

rolfk wrote:

---

dan_u wrote:

---

rolfk wrote:

Vista does something like shadowing. This means any write access (and consequently read access later on) to protected parts (file system but also registry) will be instead directed to a shadow area for the current user in his local profile. The only way to write really to those protected areas is by explicitedly running the application with administrator rights even when logged in as administrator already.

---

Be careful, don't rely on that. For instance the config file VIs don't do that. They seem to bypass the virtualization or shadowing or however you call it. For instance if you want to modify the application ini file (which is always at the same location as the application, i.e. in the program files folder) you'll need to set the permissions on the ini file or the write will fail.

---

Yes because the config file VIs are built on the normal LabVIEW File IO functions which call directly the Windows File IO API. To get the virtualization for INI files you have to call the Get/SetPrivateProfile() Windows APIs.

Rolf Kalbermatter

---

Good to know, thank you.

For now I'll stick to the solution of granting the group "Authenticated Users" full access to the ini file, though.

Daniel

[smercurio_fc]

For anyone else who desires to answer questions posted by battler, you should read this thread, especially this response.

[battler.]

Now I know what you're talking about.  Thanks a lot for the VIs.

Battler.