Show splash screen before .net loads
- Thread starter Xancholy
- Start date
Stonkie
Well-known member
- Joined
- Sep 12, 2007
- Messages
- 279
- Programming Experience
- 1-3
That simply cannot be in VB.NET... Obviously if you don't want the .NET Framework loaded, you cannot use it to show anything! You'd have to do a wrapper script and stuff...
I doubt that is what you really wish... If you want a splash screen before you application loads, override the OnLoad() method from your main form to show the splash screen, add your initialization code (maybe load a database or something), put every initialization from the constructor after the splash screen shows and hide the splash screen in the OnShow() method.
I doubt that is what you really wish... If you want a splash screen before you application loads, override the OnLoad() method from your main form to show the splash screen, add your initialization code (maybe load a database or something), put every initialization from the constructor after the splash screen shows and hide the splash screen in the OnShow() method.
As Stonkie says, this isn't possible. How could it be? It's the Framework that loads your app and runs it so how could your app do anything before the Framework is loaded?
If you want your app to display a splash screen then simply select the form you want displayed from the drop-down list in the project properties.
If you want your app to display a splash screen then simply select the form you want displayed from the drop-down list in the project properties.
This is how they explain it:
So you run an unmanaged start.exe app first that will run the .Net app, which when started deletes a file and this notifies the first app (the splash) to close.
Unless you are doing a LOT on startup before your form is displayed, this really isn't necessary. Using the splash screen from .NET would suffice as you could then do any set up your application needs while the splash screen is up. I have yet to see a .NET application that takes so long to show anything that the user would think that nothing is happening. If that is the case, you could always ngen the application.
My concern would be how to package and deploy this unmanaged start.exe when using clickonce ?? Clickonce would create it's own .exe and all program shortcuts would point to this, right ?
Is there any way we can get clickonce (and app shortcuts) to point to the unmanaged start.exe ??
Why do you want to do this in the first place? Really, what IS the point? Have you measured exactly how long the delay is between starting an app and a standard splash screen appearing? Do you really believe that the delay is unacceptable or does this just seem like a cool idea?
At this point I am just asking - questions and concerns. I have had problems in the past with deployment on less-than-ideal end user machines where .net takes it's time to load and the eventual general mindset is that the 'app is slow' etc.
If all the experts believe that standard splash forms are adequate, so be it.
I'd still like to know how to ngen an app though.
If all the experts believe that standard splash forms are adequate, so be it.
I'd still like to know how to ngen an app though.
Stonkie
Well-known member
- Joined
- Sep 12, 2007
- Messages
- 279
- Programming Experience
- 1-3
If you really want a wrapper app, you should just write a script, be it plain VB, Python (I've done a 3D interface for a space game in Python back in school! 
) or possibly Lua (I haven't tried displaying anything with that one but it has the smallest load time for sure)... Your decision should also take into account if you want to show a movie or a simple picture, maybe a progress bar with status reports?
Whichever has the lightest execution evironement is the best. There's always the worry that a C++ exe won't work in that special case you didn't think of (Vista's new security stuff, 64 bits machines, an old Win98 box...).
As for NGEN, I'm pretty sure it has to load the framework, the app and the referenced dlls. The speed boost should be only during execution, not during loading*. I don't see how they would make it faster to load in this fashion anyway. It simply removes the process of jitting your methods just before they are called. Unless it has to jit lots of stuff before the app loads, this step is probably insignificant.
) or possibly Lua (I haven't tried displaying anything with that one but it has the smallest load time for sure)... Your decision should also take into account if you want to show a movie or a simple picture, maybe a progress bar with status reports?Whichever has the lightest execution evironement is the best. There's always the worry that a C++ exe won't work in that special case you didn't think of (Vista's new security stuff, 64 bits machines, an old Win98 box...).
As for NGEN, I'm pretty sure it has to load the framework, the app and the referenced dlls. The speed boost should be only during execution, not during loading*. I don't see how they would make it faster to load in this fashion anyway. It simply removes the process of jitting your methods just before they are called. Unless it has to jit lots of stuff before the app loads, this step is probably insignificant.
Last edited:
NGEN pre-JIT's everything, which when you are starting the app can save quite a bit of time since the framework no longer has to load everything associated with your application. When the app starts up it has to JIT all references your application makes as well as JIT everything in the app itself. If your app changes often, this isn't a good option, however, since you would have to re-NGEN it every time it changed. NGEN can provide a vast improvement for application load time, but only on a warm startup (app has been started before).
Stonkie
Well-known member
- Joined
- Sep 12, 2007
- Messages
- 279
- Programming Experience
- 1-3
Possibly, but jitting is not the most time consuming operation. It is to load all those System.Something references, your app's dlls and exes and loading the framework's virtual machine itself.
On the opposite, if the application was started before, the application's jitted files are already in the global cache and there is no need to jit them again, so NGEN does not boost anything. during cold starts however, the application will load prejitted files instead of the intermediate code. It won't have the extra step of jitting everything.
However, since jit is "Just-in-Time", it just compiles the methods as it needs them, so the loss of CPU cycles is distributed on all of the application's lifetime. This leads me to think the gain provided by NGEN is low (compared to loading the framework from the disk) and has effects during the whole lifetime of the application (with a definite concentration during the beginning).
Most of the time, saving CPU cycles is a pointless optimization. It is to minimize disk or memory access that really affects the responsiveness of the application. And sometimes threading...
On the opposite, if the application was started before, the application's jitted files are already in the global cache and there is no need to jit them again, so NGEN does not boost anything. during cold starts however, the application will load prejitted files instead of the intermediate code. It won't have the extra step of jitting everything.
However, since jit is "Just-in-Time", it just compiles the methods as it needs them, so the loss of CPU cycles is distributed on all of the application's lifetime. This leads me to think the gain provided by NGEN is low (compared to loading the framework from the disk) and has effects during the whole lifetime of the application (with a definite concentration during the beginning).
Most of the time, saving CPU cycles is a pointless optimization. It is to minimize disk or memory access that really affects the responsiveness of the application. And sometimes threading...
Similar threads
- Solved
