New installer

[dandaman32]

I noticed how Paint.NET is installed...you wrote an MSI package that contains the data, your own UI, and an NSIS-based wrapper, I'm guessing for the compresson.

The installation works, but why do you have, like, three different stub loaders before the users actually see the installer window? Perhaps you don't see what you're missing in NSIS... :?

I have written a new installer entirely in NSIS. It was tested on a computer that had never seen the light of Paint.NET, and it worked seamlessly. It was originally developed for Beta 3, but at the last minute I updated it for 2.5b4.

The full NSIS source code for the installer itself is included, but it was developed using a currently unreleased version of the ExperienceUI and you will need the ExperienceUI version 1.1M2 (currently release pending, but I made it so I can do what I want with it) in order to rebuild the installer.

Download this cool new installer: http://www.freewebtown.com/dandaman32/pdn/PDNSetup-2.5b4.exe

EDIT: This installer is experimental. DO NOT try to just use it if you are new to Paint.NET for now, and by downloading and running this file you are doing so at your own risk!

Until further notice, all updates to this installer will be posted on this thread if needed.

-dandaman32

[dandaman32]

Screenshot:

-dandaman32

[Rick Brewster]

Looks neat, but, um ...

Please don't try to distribute a different installer, as it is very easy to break things (and then people will ask us why things aren't working). Our setup process is not simple because we have many requirements and intricacies that are not apparent from the outside, nor are they publicly documented (source code will be released, but that is different).

There is some complicated logic in our installer that is very important for dependency checking, keeping track of settings, and updating. There are also other requirements it fulfills, such as providing text that is localized in the appropriate language (English or German for v2.5) while also keeping translation maintenance as simple as possible for our translator.

Here's what the different stubs and packages are for:

PaintDotNet_2_5_*.exe -- Simple NSIS-based wrapper that extracts its contents to %TEMP%\PdnSetup and then executes SetupShim.exe. We use NSIS because it gives us an easy way to make a self-extracting EXE with a minimal amount of scripting tossed on top ("1. extract files, 2. run that exe over there, 3. delete the files").

SetupShim.exe -- Very light-weight dependency checker / enforcer that is written in C. It makes sure that .NET is installed, and if not it tells the user they must install it and directs them to the appropriate webpage. For our full installer (not available for v2.5 yet) it will also install .NET if it is part of the package. If everything checks out, it simply executes SetupFrontEnd.exe.

SetupFrontEnd.exe -- This is our setup wizard, written in C#. We can't do .NET dependency checking here because you have to have .NET installed in order to run a C# application. This wizard gathers options in a very specific order of precedence and manages uninstallation of previous versions and installation of new versions. It makes sure that the MSI's are always in a predictable, accessible location. There is some important logic in here that governs what gets done when installing fresh, or installing a new version (uninstall old version + install new version), or updating (entails uninstalling + installation while carefully preserving certain settings).

PaintDotNet.msi -- This is the MSI. This handles copying and registering a lot of stuff that we'd rather not have to worry about. Windows Installer technology (MSI) is very good at doing certain things, and so we let it do its job.

It's not about "[we] don't see what [we're] missing in NSIS". We have a lot that we're trying to do, and it's very advantageous to have complete engineering control and knowledge over the entire setup pipeline.

[dandaman32]

NSIS has a function that can check for .NET framework. This way you can at least drop "SetupShim.exe"

 Function IsDotNETInstalled
  Push $0
  Push $1
  Push $2
  Push $3
  Push $4

  ReadRegStr $4 HKEY_LOCAL_MACHINE \
    "Software\Microsoft\.NETFramework" "InstallRoot"
  # remove trailing back slash
  Push $4
  Exch $EXEDIR
  Exch $EXEDIR
  Pop $4
  # if the root directory doesn't exist .NET is not installed
  IfFileExists $4 0 noDotNET

  StrCpy $0 0

  EnumStart:

    EnumRegKey $2 HKEY_LOCAL_MACHINE \
      "Software\Microsoft\.NETFramework\Policy"  $0
    IntOp $0 $0 + 1
    StrCmp $2 "" noDotNET

    StrCpy $1 0

    EnumPolicy:

      EnumRegValue $3 HKEY_LOCAL_MACHINE \
        "Software\Microsoft\.NETFramework\Policy\$2" $1
      IntOp $1 $1 + 1
       StrCmp $3 "" EnumStart
        IfFileExists "$4\$2.$3" foundDotNET EnumPolicy

  noDotNET:
    StrCpy $0 0
    Goto done

  foundDotNET:
    StrCpy $0 1

  done:
    Pop $4
    Pop $3
    Pop $2
    Pop $1
    Exch $0
FunctionEnd

And directly out of my installer's source:

Call IsDotNETInstalled
Pop $0
StrCmp $0 1 +4
MessageBox MB_OK|MB_ICONINFORMATION "The installer was unable to detect the Microsoft .NET Framework.  $(^Name) requires the .NET Framework in order to run.$\n$\nPlease click OK to exit Setup."
ExecShell open "http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en"
Quit

You can see that this works better than having a whole separate program do nothing but check for .NET framework!

As for your translation problem, the ExperienceUI has a German translation creation in progress.

Also your installer network is over 1 MB, mine is <800kb, this can make a difference for dialup users.

-dandaman32

[Rick Brewster]

Who's to say our dependency checking won't get more complicated in the future? What if we run into a wall where NSIS can't do something we need it to do? With our solution we have complete flexibility. There's no reason to use NSIS just for the sake of using NSIS, and it does not "work better" for our needs.

Also, there is no "translation problem." It is simply part of the process.

[dandaman32]

Who's to say our dependency checking won't get more complicated in the future? What if we run into a wall where NSIS can't do something we need it to do? With our solution we have complete flexibility. There's no reason to use NSIS just for the sake of using NSIS, and it does not "work better" for our needs.

NSIS allows you to write plugins in C/C++/Delphi. So that means that if you can do it in C, you can do it with NSIS.

-dandaman32

[Rick Brewster]

Or I could just write it in C to begin with (which I have), which has the benefit of being ultimately flexible and yet also understandable and maintainable. We would gain absolutely nothing by expanding our use of NSIS.