Feature - Implemented Bare Bones Browser Launch

Catch-22

Active member
Any help in this matter would be greatly appreciated.

I'm currently looking at the code for this. I think there's a bit too much guesswork being done by KoLmafia for people who specify their web brower manually. I'd like to offer some improvements.

Do you have your preferred browser set to "chrome" or do you have it set to the full path, ie.
C:\Users\balkin\AppData\Local\Google\Chrome\Application\chrome.exe

If you haven't set it to the full path, try that first.
 

Catch-22

Active member
Some suggested improvements to the brute forcing method used for Windows (ie. use less brute force).

Reposted here.
 
Last edited:

Catch-22

Active member
But I specifically want the 64-bit version of IE, not the default 'handled' 32-bit...

You can either change what Microsoft registers as the app path for internet explorer or just specify "C:\Program Files\Internet Explorer\iexplore.exe"

By default, Microsoft registers both the iexplore app path and the Wow6432Node app path at the 32-bit location.

Edit: We could write some code that will expand environment variables if they appear in the string, but it seems like a pretty edged case that could be avoided by specifying the absolute path manually, I guess it comes down to how much we want KoLmafia to actually do before throwing it's hands up in the air and returning the best it could figure out.
 
Last edited:

Theraze

Active member
True... I need the default to stay 32-bit for other plugins which aren't available in 64-bit, but I can temporarily break all my other Dropbox-ed computers which don't use C: as their primary program drive... hopefully this will be fixed before I need to use mafia on them again. Or I'll just be using my own partially-reverted copy of mafia. Either way. :)
 

Catch-22

Active member
True... I need the default to stay 32-bit for other plugins which aren't available in 64-bit, but I can temporarily break all my other Dropbox-ed computers which don't use C: as their primary program drive... hopefully this will be fixed before I need to use mafia on them again. Or I'll just be using my own partially-reverted copy of mafia. Either way. :)

Changing what is in app path won't actually change your default browser to the 64-bit one, it just changes what typing "iexplore" into the run dialog will be interpreted as. Perhaps that would be a simple solution?
 

holatuwol

Developer
Some suggested improvements to the brute forcing method used for Windows (ie. use less brute force).
I'm not a huge fan of parsing through registry data, but using environment variables makes sense over iterating over all folders on a computer. As such, I'm going to try committing something that uses dir /s against the appropriate environment variables (which should allow Theraze to use iexplore).
 

Catch-22

Active member
As such, I'm going to try committing something that uses dir /s against the appropriate environment variables.

Sorry Hola, but that's not a very good idea. process.waitFor() is a blocking operation and dir /s has the potential to cause several seconds of delay.

What do you have against querying the registry? It's literally how Windows would do it if you typed "iexplore" into the run dialog.

Edit: For example, I just ran dir /s %LocalAppData% > NUL which is where my Chrome resides, it took about 30 seconds.
 
Last edited:

holatuwol

Developer
How long does it take to run dir /b /s %LocalAppData% chrome.exe?

Edit: I'm avoiding the registry because I'm not sure reg will actually work when people are running as non-administrators on a wonky group policy. If your testing reveals that adding a filename doesn't help the search time at all, I'll probably wind up doing both, but if specifying the filename you're looking for reduces your dir /s time substantially as it does for me (my tests were on the C drive, but admittedly I've got nothing on this Windows VM so it was two seconds vs. fractions of a second), I don't really want to add in that complexity if I don't have to.

Edit 2: reg query doesn't return any data for Chrome or Firefox for me on my Windows XP VM, so the fact that the Run dialog works is probably Microsoft's fallback logic that searches the Start Menu. I'll see if I can't find a way to do search against the lnk files in the Start Menu instead of doing this registry search.

Edit 3: Turns out that all along, the start command works just like the run dialog, so if you provide it with something other than a file name, it'll load up the executable that corresponds to that command in either the start menu or the registry, so I've switched to using that instead. Let me know if this works out.
 
Last edited:

Catch-22

Active member
How long does it take to run dir /b /s %LocalAppData% chrome.exe?

Sorry, I'm on a different computer again, I use Firefox here on a fairly fresh install of Windows 8, and it's an SSD, so it's a lot quicker, but I did try what you said earlier for chrome.exe on the other computer earlier and it took about 5 seconds, but Windows will cache the results of dir if you've ran it recently, so if I restarted my PC it probably would've taken longer.

Edit: I'm also avoiding the registry because I'm not sure reg will actually work when people are running as non-administrators on a wonky group policy. If your testing reveals that adding a filename doesn't help the search time at all, I'll probably wind up doing both, but if specifying the filename you're looking for reduces your dir /s time substantially as it does for me (my tests were on the C drive, but admittedly I've got nothing on this Windows VM so it was two seconds vs. fractions of a second), I don't really want to add in that complexity if I don't have to.

reg will exit gracefully if it doesn't have the correct permissions, but most users will at least have access to those hives or they'd have a lot of trouble even logging in (and HKEY_CURRENT_USER by default belongs to the current user).

Edit 2: reg query doesn't return any data for Chrome or Firefox for me on my Windows XP VM, so the fact that the Run dialog works is probably Microsoft's fallback logic that searches the Start Menu. I'll see if I can't find a way to do search against the lnk files in the Start Menu instead of doing this registry search.

The reg query method won't work for Chrome unless you set it as the default browser at installation time, in the suggestion I posted the search for Google Chrome should work quite nicely though. I'm a little surprised it doesn't work for Firefox, but perhaps there is a better registry key to be reading from. Your idea about searching through the start menu is also not a bad one, this is how Windows 8 determines what to applications to add to the home screen.

A problem which I had thought of but couldn't confirm until now is that dir will traverse symbolic links in NTFS. If you have a looping directory tree (as exists in WinSxS systems) due to symbolic links, dir will loop continuously and eventually stop producing output because every path becomes too long to even print, but dir will never actually return unless you manually terminate the operation.

Here's an example of what happened on my machine when traversing ProgramData.

Code:
The directory name F:\ProgramData\Application Data\Application Data\Application
Data\Application Data\Application Data\Application Data\Application Data\Applica
tion Data\Microsoft\Windows\WER\ReportArchive\NonCritical_7.8.9200.16384_7c7469d
2abbd78725d0bec58da07bcd9c4fb9a_0a104a73 is too long.
 

Theraze

Active member
Sorry to be the returner of bad news... still doesn't run for me, because of the space in the name. Using dir without providing quotes on a directory with a space in the name causes failure. If we don't move on to parsing shortcuts or the registry, enclosing the target of the dir /s into quotes should fix this issue. Thanks.

Edit: Forgot to mention, this is with 11603.
 
Last edited:

Catch-22

Active member
reg query doesn't return any data for Chrome or Firefox for me on my Windows XP VM.

I just tested this out, the reg query works, the problem is just that the stdout of reg query in Windows XP is slightly different to the output of the same query in Windows Vista+

This ammendment to my earlier patch should detect if it's running the older version of reg query and adjust the output accordingly.
 

Attachments

  • BrowserLaunchSuggestions.patch
    4.7 KB · Views: 71

holatuwol

Developer
No, I actually checked the key itself in regedit. There is no key there for Chrome and no key there for Firefox. I'll try adding quotes around the browser if it detects a space or % signs.

Update: Preliminary testing with setting the value to %programfiles%\Mozilla Firefox\firefox.exe looks like it worked just fine with the changes. If it doesn't work for you (even though it worked for me), we should probably open a new thread since the conversion over to BareBonesBrowserLaunch is complete, just not working quite right in conjunction with an existing KoLmafia feature which loads something other than the default.
 
Last edited:
Top