kevinrmartinez / RetroLinker

A GUI application to create desktop links of games running on RetroArch. For Windows and Linux.
GNU General Public License v3.0
2 stars 0 forks source link

Replace the .lnk file handling to remove Windows specific requierments #26

Open kevinrmartinez opened 2 months ago

kevinrmartinez commented 2 months ago

To handle (read & write) .lnk shortcut files on Windows, the app uses the Windows Script Hosting runtime, available only on Windows systems. This (and another) dependency force me to create a library that can only be compiled on Windows. Now I'm looking to fix this.

A good hint: https://github.com/securifybv/ShellLink

kevinrmartinez commented 2 months ago

https://github.com/securifybv/ShellLink is a library that still requires Windows dependencies. Creating a windows shortcut is deeply embeded on the Windows API, so I have to options:

  1. Build the shortcut file byte to byte like a maniac
  2. Use a javascript or visual basic script (vbs) to generate the shortcut.

I decided to use the vbs, the program will create it and store it on temp files before executing it with cscript. cscript comes preinstalled with windows since Win98, so it's expected to be on the system, just like I expect a linux machine to have chmod. The source of the scripts can be found here

kevinrmartinez commented 2 months ago

It turns out that VBscript is being deprecated. So I decided to change it to Powershell script (.ps1). Powershell comes preinstalled since Win7, but .NET 6~8 claims it only supports Win10 1607 onwards so...

Now, there is a security policy in Windows that prevents Powershell from executing untrusted scripts, this could prevent RetroLinker from creating shortcuts. I could add -ExecutionPolicy Bypass but that feels really shady for me to do. So if there are users experiencing that, I could add the option to bypass in the settings, or an option to run VBscript version with cscript.

kevinrmartinez commented 1 month ago

So by default, Powershell execution policies are to not run unsigned scripts, or not run them at all. So I stepped back to VBscript, but this time running it with the NuGet ClearScript. So I don't have to fear that cscript stops running vbs or something like that (I hope...).