Windows folders

[ShaunR]

So that means that an operator can simply navigate to the built application and delete the EXE. Now I realize if an operator does this that it would probably be considered malicious behavior. In my opinion giving a user, who likely doesn't fully understand the system, the ability to break a test system so easily is a very big deal. But then again I don't know the type of environment that the system is in, and this may be a fine setup.

My favourite trick is booting into the LV program as the shell and disabling CTRL+ALT+DEL .

[MikaelH]

My favourite trick is booting into the LV program as the shell and disabling CTRL+ALT+DEL .

What do you mean with "booting into", and how do you disable CTRL+ALT+DEL?

[Rolf Kalbermatter]

What do you mean with "booting into", and how do you disable CTRL+ALT+DEL?

Basically your Windows desktop is simply an application that is started up by Windows after the user logged in (or it logs in automatically). You can change the registry entry for this to any program you like, including a LabVIEW app. Needs some careful planning ahead, because once you do that, you mostly only can do things in Windows that your application provides an interface for. So if you don't plan some way to startup for instance the file manager, you might have locked out yourself for that account pretty effectively.

One exception is Ctrl-Alt-Del which still works, but with some Windows API magic, this is quite easily remedied too. A computer that is tied down like this is pretty hard to get into in other ways than your Shell replacement app, but again watch out, this applies for you too, not just the operator noob.

[ShaunR]

What do you mean with "booting into", and how do you disable CTRL+ALT+DEL?

Nicely explained by Rolf (including the caveats). The way I "protect" myself from getting pushed into the corner is to have a few choice buttons or a keyboard combination that brings up a password protected interface (can either be an "Admin" area or just completely hidden until a certain key combination is pressed). Once in, I usually give the options to return to the windows shell (requires reboot), start an explorer window (only way to look at files) and re-enable CTRL+ALT+DLT (last two don't require rebooting)..

Just booting into LabVIEW as the shell will usually flummox most operators/users. Disabling CTRL+ALT+DEL means that you can't get to task manager, from which, you can use the run command.

[hooovahh]

Just booting into LabVIEW as the shell will usually flummox most operators/users. Disabling CTRL+ALT+DEL means that you can't get to task manager, from which, you can use the run command.

One thing I noticed is that when running LabVIEW as the shell, the Aero theme doesn't load (I'm guessing that is a service started by Explorer). So if you develop with Aero turned on, then deploy where it is off, many fonts will be wrong. And it is likely your controls in the windows won't line up right.

My fix was to let Explorer start (starting Aero) then kill it with my LabVIEW application. This also will kill any shortcuts like Win + E, Win + D. I never tried but it is likely you could just start the right theme service and have it work properly but I never tried that.

EDIT:

I also found that command to allow operators in the Users group, access to write files.

Icacls "<File Path>" /grant Users:(GA)