2

The aim is to create a single file offline (No internet is required) installer. For this reason, the following things are done.

  1. Created a C++ installer executable which will perform the installation (Basically extract the archived binaries to the specified location)
  2. Created an archive of all the required binary components which should be extracted/installed.
  3. Embedded the archive as a binary resource file within the executable

The installer satisfied the purpose and is able to the perform installation, however since the embedded resource is large (100 MB) the starting of the application is taking a lot of time.

Is there any way to specify to the image loader to delay the loading of this embedded resource so that the application startup will be instantaneous? And the resource will be loaded on demand when appropriate UI is setup (like progress bar)?

The created installer is win32 application compiled using Microsoft build toolchains.

Any help is appreciated, thanks in advance.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
Prasanna
  • 93
  • 10
  • 1
    no, embedded resource can not be delay-loaded. you need use external file as resource for this, or append resource to your PE file already after build (so it will be not part of pe (not inside any section )) – RbMm Jan 02 '18 at 13:17
  • 1
    Surely it makes sense to keep the install program and the data separate. Will make maintenance simpler. – David Heffernan Jan 02 '18 at 13:33
  • 1
    You can keep the installer and payload separate, e.g. in different source repositories. The build system then pulls the respective versions, compiles or otherwise processes them, and - as a final step - 'links' them (one way or another) into a single file. That final step doesn't have any immediately obvious repercussions on maintenance, as far as I can see. – IInspectable Jan 02 '18 at 14:32
  • "starting of the application is taking a lot of time" sounds like a job of antivirus software. – user7860670 Jan 02 '18 at 14:33
  • A big, code-signed setup executable will always take a noticable hit on loading time, no matter how the payload is integrated in the final file. The reason for that is that Windows has to calculate a hash of the entire file to verify it with the one stored in the signature. – zett42 Jan 02 '18 at 15:07
  • @RbMm Thank you, looks like an option to explore. Can you please point me to some reading materials? – Prasanna Jan 03 '18 at 04:44
  • @zett42 Thank you. Agree with you about the calculation of the hash part. But as per my understanding, the signature check will be performed only if we sign the application and ask for the signature check to be part of the linker options or as part of the build process. – Prasanna Jan 03 '18 at 04:49

0 Answers0