search

cpbotha / xdg-open-wsl

xdg-open replacement for WSL that opens files and links using Windows apps.
BSD 3-Clause "New" or "Revised" License
159 stars 12 forks source link

Launch folders in the default "Folder" handler, rather than explicitly explorer.exe #6

Open b- opened 2 years ago

b- commented 2 years ago

If the default "Folder" "open" command is not explorer.exe, (for example if the lovely Files file browser is set as the default file manager) xdg-open should open whatever the default file handler actually is. Of course it's hardcoded to explorer.exe right now for folders, so this doesn't happen. I can see why that is (if you run a UNC path through cmd.exe /c start, it complains that this is a UNC path and instead opens the Windows folder or something...). However, this is technically not properly implementing xdg-open in regards to directories, then, and I'm sure there are other legitimate reasons to have Folder not mapped to explorer.exe. I've thought of a few ways around this, and made branches in my personal fork to try this.

b- commented 2 years ago

One possibility is simply using Powershell's equivalent, powershell.exe /c start-process, and this seems to work great. However, I've noticed over the years that PowerShell always takes a little while to start (even on a fast machine with an SSD), so I don't think introducing a multi-second delay to fix a corner case is ideal.

Another possibility is to use a simple program to call Win32 ShellExecuteEx() on a UNC path to the folder, which is what is happening under the hood when launching it via cmd.exe or PowerShell, anyway.

The latter of the two methods requires a helper application. I'm no C wizard, but we don't need to reinvent the wheel here anyway: Wine includes an implementation of cmd.exe /c start by way of a standalone start.exe application. The only issue I can see now is that because we're including a compiled binary executable, what happens if someone wants to use xdg-open-wsl on Windows for Arm CPUs? I'm pretty sure WSL does work there.

Fortunately, there may be a simple solution to the above: the built-in WoW emulation/virtualization layer included with Windows. On Windows Arm, there's a simple x86 compatibility layer which can natively launch x86 .exe files. This means that as long as the feature is enabled (which it is by default) it should just work. I haven't tested this, but as far as I understand it should work. See https://en.wikipedia.org/wiki/Fat_binary#Windows for an example of something more complex taking advantage of this.

One minor issue to mention, though, is that this requires an x86 binary which technically isn't native to x86-64 systems either. The WoW x86 layer is technically an optional feature on x86-64 Windows as well, but as far as I'm aware it's only ever disabled by default on server editions, so I'm making the assumption it's there.