LabVIEW
Random Nugget 1 : Post-build EXE customisation
@Intaris wrote:
Felix,
now THAT's an interesting idea. But what are the intricacies of such an approach?
The splash screen would have to call all of the VIs dynamically since hard-wiring them would prevent LV from closing them. The it would call the top-level VI (again dynamically)?
So basically the splash VI needs a list of all VIs int he finished application to be able to do it's thing....
Begs the question.... what happens if we override the splash VI?
Shane.
Why so complicated? The splash screen only needs to know of its own dependencies (or could enumerate them at runtime) and abort and close any others. Then it starts up the top level application VI - yes dynamically - and finishes itself and there you go.
And if you overwrite the spalsh VI this overwrite is all that is started. No way to get the rest started up anymore unless the overwrite knows how to find and startup the top level VI, but hey if someone got that far already, he has some other means to get at your information than going through this venue. (Disgruntled employee, password access to internal resources through social hacking, or such)
Well because if we don't open up (and subsequently close again) all of the VIs associated with the top-level VI then a VI loaded as I have shown will remain in memory when the top-level VI is executed via the splash screen. The only way around this is to load ALL VIs, then close them and re-load. This way the smuggled or piggy-backed VI is disposed of and we really start with a clean plate (nice analogy Ben!).
Shane.
PS: Ah, I think I now understand your point. Any smuggled VIs will be outside the splash-screen's own call-chain but will be in memory and can thus be identified as an invader and thus dealth with.... So the splash screen is like a bouncer. 
@Intaris wrote:
Well because if we don't open up (and subsequently close again) all of the VIs associated with the top-level VI then a VI loaded as I have shown will remain in memory when the top-level VI is executed via the splash screen. The only way around this is to load ALL VIs, then close them and re-load. This way the smuggled or piggy-backed VI is disposed of and we really start with a clean plate (nice analogy Ben!).
Shane.
Can't follow you here. As far as the overwrite VI is concerned, the Splash VI and its very lean dependency is all the application exists of. And it gets then consequently shutdown and disposed of before starting the actual top level Vi, and yes of course doing so dynamically through VI Server. But that is how I have done Splash screens all the time already otherwise you have to wait for the entire application to load before the splash screen shows.
Intaris wrote:PS: Ah, I think I now understand your point. Any smuggled VIs will be outside the splash-screen's own call-chain but will be in memory and can thus be identified as an invader and thus dealth with.... So the splash screen is like a bouncer.
Exactly, just one caveat. To detect any possible intruder you have to use the special List VI method that includes also system flagged VIs. Otherwise it would be easy to hide the "preloaded" VI by setting this flag.
