You are here

Chrome Portable command line length limit

10 posts / 0 new
Last post
kamtschatka
Offline
Last seen: 4 years 3 months ago
Joined: 2014-03-05 06:07
Chrome Portable command line length limit

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.

John T. Haller
John T. Haller's picture
Offline
Last seen: 9 hours 43 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
1024 Max String Length

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!

Bart.S
Offline
Last seen: 4 months 1 week ago
Developer
Joined: 2008-07-23 07:56
Special NSIS build

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.

John T. Haller
John T. Haller's picture
Offline
Last seen: 9 hours 43 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Seems Official

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!

Gord Caswell
Gord Caswell's picture
Online
Last seen: 46 min 2 sec ago
DeveloperModerator
Joined: 2008-07-24 18:46
Appears maintained

It appears both builds are maintained alongside the default build: https://sourceforge.net/projects/nsis/files/NSIS%203/3.02.1/

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
I have to wonder why the

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

Gord Caswell
Gord Caswell's picture
Online
Last seen: 46 min 2 sec ago
DeveloperModerator
Joined: 2008-07-24 18:46
"Extra Overhead"

Special builds: strlen-8182 & log vs regular builds says:

What is the disadvantage of running NSIS-strlen-8192 or NSIS-log. Why are these compiled out by default?

Because they add extra overhead and the majority of users do not need to use these features.

Out of interest what's the overhead? 8K per Var instead of 1K?

Per variable, per section, per constant and per every internal buffer.

John T. Haller
John T. Haller's picture
Offline
Last seen: 9 hours 43 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
25% more RAM usage

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!

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
25% sounds like a lot; 3.0MB doesn't. Probably not for all apps…

"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

3D1T0R
3D1T0R's picture
Offline
Last seen: 3 years 2 months ago
Developer
Joined: 2006-12-29 23:48
Add [Advanced]:NSISBuild to launcher.ini

What do you think of adding something to the App\AppInfo\AppNamePortable.ini file 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 an NSISBuild (or SpecialBuild, 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]:NSISBuild value 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

Log in or register to post comments