[Fixed] FirefoxPortable.exe higher disk access in recent builds

I can't reproduce this on 64-bit or 32-bit Windows. After Firefox is up and running, FirefoxPortable.exe sits there doing nothing with 0 I/O Reads/Writes/Other and 0 I/O Read/Write/Other Bytes, just as always. The only change in the 43.0 launcher was to detect whether the OS was running 64-bit before launch and then launch the correct version of Firefox. The code while running is the exact same 6 lines as it's been for years.

For completeness, do you have any custom settings in FirefoxPortable.ini? What app are you using to map the the disk use? Are you running any extensions that could cause Firefox to restart itself?

The only thing I can think of is if you somehow triggered something that would escape the ExecWait (firefox.exe restarting itself) and cause it to fall back to firefox.exe check for running every 2 seconds. But there's nothing I can think of that would work one way with the pre-64-bit launcher and one way post.

Please answer the questions in the above post.

Additionally, it's almost no burden if it needs to do the fallback check every 2 seconds. It's a single load of a single 4K DLL from the local hard drive's TEMP directory. And it's almost definitely cached in memory.

Once again, please answer ALL the above questions before posting again.

Ah ok, that helps. In Task Manager, it made almost no difference between them. In Process Hacker, it shows a clearer difference.

It seems that the FindProcDLL included in NSIS Portable 2.46 Rev 2 is different compared to the one in the NSIS Portable 2.46 Rev 3 release. That's what changed between Firefox 42 and Firefox 43. Nothing in our code changed, which is what made this make no sense. I believe the newer one works with 64-bit processes while the older does not. I'm investigating further.

Ok, it seems that the newer version of the FindProcDLL plugin has a higher cost to doing a process check in terms of disk use. We can't revert to the old version used in NSIS 2.46 Rev 2 because that one only works with 32-bit processes and won't work with dual mode apps like Firefox Portable on 64-bit machines (the majority of users). But, this new FindProcDLL plugin does introduce a new method allowing for a low cost wait for a process to finish that won't consume CPU or disk. So, I've updated the Firefox Portable launcher to make use of that. Each time firefox.exe restarts there will be a single check on the process and then a wait, so you won't see the spike every 2 seconds. firefox.exe restarts rarely so this will reduce the overall cost of the launcher in terms of CPU and disk compared to the old one.

This change is included in Firefox Portable 47.0.1 which is building now.