LabVIEW
Can compiled app vi run without windows explorer?
I believe there is a way to make it a Windows service. Maybe this might help?
https://forums.ni.com/t5/LabVIEW/Running-a-LabVIEW-executable-as-a-Windows-service/td-p/3639009
@art_ wrote:
I might be able to get a service wrapper like nssm approved and installed. But it's not clear from the docs whether that will get around the problem of windows explorer not being there when the front end tries to come up. Do service wrappers run the GUI in some kind of virtual environment so the app thinks windows explorer is running?
Sorry, I only knew enough to point you in a general direction. I've never tried making a service from a VI before.
@art_ wrote:
We have a compiled vi on an automated test set that has to run at bootup without anyone logged in (like a windows service.) Autologin is not an option for security reasons. So windows explorer will not be running. Is it even possible to run labview without explorer running? Platform is labview 2018 on a windows 7 PC.
There are really two different issues here. One is to have your application up and running even if there is no user logged in. That requires your app to be a service there is no other way to it. Those service wrappers do NOT operate as shell. What they do is providing the necessary interaction with the Service Manager on behalf of the wrapped application. An executable wanting to run as a service has to follow a specific protocol to interact with the Service Manager, otherwise the executable will never really get started up since the Service Manager considers it not responding. There would be also the option to directly call Service Manager functions but that is not something that can be easily done in pure LabVIEW since the Service Manager requires at least two callbacks to be passed to. The Service Wrapper simply does this interaction and then starts up the wrapped executable and when Windows tells the wrapper that the service needs to be stopped, the wrapper sends it a WM_QUIT message and if it doesn't exit cleanly simply will have to kill it.
With interaction from your LabVIEW program with the Service Manager you could more cleanly handle that but that is a rather nasty job to program. I have done it in the past but can't post the code unfortunately.
The other option is to not have an explorer window open when a user logs in. That is also possible but also a bit cumbersome to test and once you did that you may have trouble to get back into the machine if you need to replace your executable. You need to change the registry key "Shell" under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon to point to the name (and path location if it is not in the <Windows> or <System> directory). This replaces the Shell application for all users. Alternatively you can also change the according key under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon to only change it for the currently logged in user.
There are a few caveats here. Once you changed that key, especially for all users, you don't have any Explorer Window active anymore. Your new exe is the Windows Shell and it will only show whatever it is programmed to show. If you don't have a (password protected) option somewhere to at least launch a command line window, Explorer.exe or the Registry Editor, you are in a bit of a bind to ever get out of this again.
Also since there is no Windows Explorer process anymore, certain Shell functionality that is really provided by the Explorer process may not work anymore. This could have even effects for certain file operations that your LabVIEW program may use, although most LabVIEW file functions work on the Win32 API level, not the Shell API level.
@art_ wrote:
How did you turn your app into a service? We dont want a UI but all labview code has a front panel. It can be hidden with a self-reference in the block diagram but it pops up before hiding so I assume it still expects explorer to be running. We tried adding the compiled vi to the windows task scheduler but it refused to run because explorer wasn't running on bootup (unless someone logs in.)
I used my own shared library to be called from LabVIEW to interact properly with the Windows Service Manager as well as provide support to install and uninstall my service program.
And a program window has absolutely nothing to do with Explorer. The window management is part of the Windows kernel and is present no matter if Explorer is running or not. The explorer simply is started up as main process when a user logs in, not before, and draws as first thing a window that covers the entire screen. This is your desktop. It also creates and handles the Taskbar, Start Menu, Balloon Message handler and a few dozen other things. It then allows to open additional windows that give you a view of the file system, the well known Explorer windows. But Explorer is really your entire desktop.
And this is what you can replace with my earlier mentioned second method.
A service runs in a special Windows session that has no user interaction. It can be a Windows command line app or a GUI app but its UI will never be visible to anyone. It doesn't matter if your LabVIEW program explicitly hides its front panel or not. It's simply never visible. Think of it running on a screen that is never connected to any monitor. In older versions you could install a service and let it have interaction with the desktop of a logged in user but that has been removed in Windows 10 as a security risk. The service runs usually in a high privileged user context similar to an administrator and any interaction with the user session gives a potential attacker extra leverage to try to break into the system and with this kind of privileges it is easy to take over a computer completely.
