I notice that most portable app launchers use a fairly sizeable chunk of memory, relatively speaking. 10 MB seems to be the average.
I'm wondering why this is - and why a Windows API call to say 'EmptyWorkingSet' isn't made upon main program launch?
Thanks for any info,
J
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
For your first question, I was going to say it was due to UPX taking up more memory for decompression, but the Wikipedia entry for UPX says that no extra memory is needed ("usually")
http://en.wikipedia.org/wiki/Upx
For the second question, portable launchers are coded in NSIS which can call WinAPI functions (AFAIK). Why we don't call that function, I don't know. Maybe becuse we want to keep the launcher simple, or another reason is we have no clue what it does. Talk me into why we'd want to implement it since you know what it does and I don't do any programming that uses the Windows API. (I did Google it and skim some gobbly-gook on MSDN that made zero sense to me)
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
The 'EmptyWorkingSet' function basically throws unused application memory to the page file and frees up system memory.
I haven't really looked into NSIS or the portable-apps format, but I'd be interested if while the launcher is resident if it's actually doing anything other than waiting for a program to complete (before doing 'cleanup' work on exit). Like, if it establishes any hooks for registry or file system read/writes, or if it just sits waiting for the program to exit.
The portable launcher stays resident in memory for registry/file cleanup & to backup settings when the main .exe is closed.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
BuddhaChu,
So as I understand it then, the launcher is just polling the program until it exits, and then does cleanup. It could totally benefit from 'EmptyWorkingSet' then. (if it can make API calls like that)
digitxp, I'm fairly certain registry hooks are possible - in C/C++ (and even AutoIT possibly), but have no clue what capabilities NSIS has. I was hoping to not have to delve into learning yet another language ;-). However, since NSIS was meant to install apps, I'd guess that hooks wouldn't be part of the package. The concept of hooking would probably require rewriting the code in C/C++ - which would be great, but this project is already well developed, and to start from scratch in another language seems like more work than anyone would want to get into.
AFAIK, NSIS is capable of variables, boolean logic, API calls, and file/registry editing. Not really sure of much more than that.
Insert original signature here with Greasemonkey Script.
EmptyWorkingSet is quite possible, it's just it needs to be worked out exactly how to do it. I might have a look at it back in Australia at the start of next year.
As far as registry hooking goes, it's just a matter of some work with RegNotifyChangeKeyValue. It's possible in C[++] or NSIS (though it's not at all a typical NSIS workflow it is possible). If only MadCHook were open source...
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
You will be heralded as a God if you find a reliable way to implement registry hooks into NSIS B-).
Insert original signature here with Greasemonkey Script.