I am trying to launch ChromePortable with a lot of command line arguments and after the recent addition of an argument I noticed, that this parameter is not used in chrome(i was using the ignore-certificate-errors switch).
A colleague of mine then played around and noticed that the amount of command line arguments is no problem if you run the chrome.exe that is bundled in ChromePortable.
He also tried to create a GoogleChromePortable.ini as suggested in another post in this forum, but it also did not work.
The limit seems to be 1065 characters. Is there any reason for that, or can this be circumvented somehow? Is this something that needs to be fixed in the GoogleChromePortable.exe file?
Any help is appreciated!
kamtschatka
P.S: Yes, I really need a commandline that is THAT long.
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
NSIS has a max string length of 1024. If you need longer, you'll need to manually launch chrome.exe yourself from something else.
Sometimes, the impossible can become possible, if you're awesome!
You could use a special NSIS build which has a maximum string length of 8192 bytes instead of the default of 1024 bytes.
http://nsis.sourceforge.net/Special_Builds
You need to recompile the GoogleChromePortable.exe.
These seem like official builds for niche situations, so they should be fine. You can drop the files included in the ZIP into the NSISPortable\App\NSIS directory and replace what's there and then compile the Google Chrome Portable launcher and it should work.
As an aside, I was thinking about switching over to this build of NSIS but I'm unsure if it's maintained in a timely fashion alongside the standard one. This is the first time in 13 years we've run into someone trying to configure a super-long string in an INI.
Sometimes, the impossible can become possible, if you're awesome!
It appears both builds are maintained alongside the default build: https://sourceforge.net/projects/nsis/files/NSIS%203/3.02.1/
I have to wonder why the default builds aren't made with
NSIS_MAX_STRLEN=8192? Is it "experimental"? less stable? or perhaps it makes bigger binaries?We should consider what their reason for releasing the version with a shorter maximum string length as the default is before we decide to switch.
~3D1T0R
Special builds: strlen-8182 & log vs regular builds says:
I checked and it looks like a clean compile of the Google Chrome launcher unsigned goes from 2.4MB of RAM while running to 3.0MB of RAM while running with the 8192 string length build. Not a huge penalty, but one that would hit all launchers.
On related note, I wonder if this would affect any plugins when using them with the 8K string length build or not. It's possible some plugins only suport 1K strings internally and lop off the end.
Sometimes, the impossible can become possible, if you're awesome!
"25% more RAM usage" sounds like a big jump; on the other hand, if 2.4MB of RAM usage isn't an issue, I don't think 3.0MB is, and when you factor in how much RAM Chrome itself uses, you pretty much have to have enough RAM to be able to effectively use Chrome that having 3 MB of RAM used by a background process, which Windows can shove into virtual memory if necessary isn't really going to make a difference.
However, we must consider everything. Chrome is an app that actually gets a benefit from this change, whereas I don't really think many (if any) of the other PA.c releases do, so while my opinion is that we should 'greenlight' this change for Chrome, I don't think we should do this 'site-wide'. On the other hand, I'm not sure what the feasibility of generating Chrome launchers with a different build of NSIS from other apps is. I'll take a more detailed look at it and get back to you tomorrow.
~3D1T0R
What do you think of adding something to the
App\AppInfo\AppNamePortable.inifile that would trigger PAL to use one of the "Special Builds" of NSIS?The special builds are distributed as a zip containing only the files that are different from the default build and if we were to include the Large Strings build, it would add less than 1 MB to the (uncompressed) install size. The Advanced Logging build would also add approximately 1 MB, but I'm unsure how much use including it would be. I'm leaning toward adding a launcher.ini section to called
[Advanced], which would contain anNSISBuild(orSpecialBuild, or something) key which can be set to whatever we want, and we can include the "Special Builds" in their own directories, each with the files that would need to replace the default build's files in a folder named after the[Advanced]:NSISBuildvalue we plan to use (e.g. LargeStrings), and copy them into place similar to how Miranda's language switching works.I'm interested in input, but unless John says it's unwanted, I'll take a stab at implementing it.
Edit: Please let me know whether you think the "Advanced Logging" build should be included or not.
~3D1T0R