Resurrecting an old discussion - we semi regularly get users that have issues starting Octave on Windows. On occasion, we find that due to security settings, permissions issues, etc., executing a vbs file to start octave or sometimes even installing a vbs file is an issue. This used to be done by a .bat script file. There was suggestion that it could all just be part of the exe file that actually starts octave… The previous discussion was scattered amongst mailing list and bug reports. thought I’d create a new discussion here to add to the noise.
“I came across bug #41074 that i think resulted in shifting from a .bat to .vbs file and seems to identify (1) no terminal window hanging around while the gui is up, (2) starting cli version in a way that still let you produce qt graphics, (3) producing the first time welcome dialog if needed.”
The general outline of @lostbard’s wrapper looks good to me.
It might be worth checking if it could be integrated into Octave’s existing wrapper executable (like @jwe suggested in the other thread).
Additionally, it might make sense to use Windows’ wide character API to avoid possible issues with non-ASCII characters.
IIUC, MXE Octave currently deletes Octave’s wrapper executable when packaging. That should probably be undone if we’d like to take this approach.
This sounds like a quite disruptive change to how we start Octave on Windows. I’m not sure if it is a good idea to touch that when a new major release is imminent.
Maybe better target Octave 8? If it turns out all of this is quite straight forward, we could still uplift to Octave 7.
I’m attaching a patch for mxe-octave that includes a modified version of @lostbard’s octave-launch.c program and an attempt at changing the mxe-octave build system to compile and include the octave-launch.exe program in the installer files.
While looking at this problem, I realized that merging octave-launch.c with Octave’s main.in.cc program is probably not the best thing to do. The octave-launch.c program is really specific to the way that the mxe-octave build of Octave works. I don’t think we want Octave itself to be concerned with setting things like MSYSTEM or MSYSPATH in the environment.
Some things that remain to be done are
Write a replacement for octave-firsttime.vbs. AFAICT, the first time script sets the current directory to %UserProfile% and then always executes Octave with the --gui option. It seems to me that we could do that job in octave-launch.c and just conditionally compile octave-launch-firsttime.exe and octave-launch.exe programs.
Remove the octave.vbs, octave-firsttime.vbs, and octave.bat files from mxe-octave.
Given the trouble we have seen with the .vbs files, I’d opt for making this change for version 7. I think we still have plenty of time for testing it out and fixing any remaining problems.
Looking at the patch, we should probably “Unicode-ify” it where it comes to file paths. I can do that after you pushed an initial change.
The octave wrapper executable should now be working also on Windows. Given that, it might make sense to remove the duplicated logic of which executable should be called from this new launcher. Instead, it could just call octave.exe unconditionally.
It might make sense to leave these files in place (at least octave.vbs and octave.bat). They could be helpful if people should have trouble using the new launcher. And leaving them there shouldn’t cause trouble I’d guess.
The links in the start menu should use the new launcher though…
The logic that was disabling the conversion to short file names for developers no longer works with this new approach. That should probably also be fixed. But isn’t a very high priority.
Also all .vbs and .bat launcher scripts are still contained in the overall package. Maybe we should keep those at least until we get feedback from testers.
Other than that I’d say this is ready for test now.
For anyone who’d like to test this: IIUC, the next mxe-default build on octave.space should be containing the new launchers.
Edit: Forgot one very important detail: While the mxe-default build will contain the new launcher, it won’t work because octave.space still builds Octave 6.x. Currently the start menu entries and file associations will be broken in that version. They should start working again when Octave 7 is on the default branch of the main Octave repository.
Edit 2: Pushed a patch adding the Octave icon and some file information to the launcher executables here: mxe-octave: bf9be5e7ab00
Edit 3: Pushed another patch that optionally de-activates the transformation to short paths: mxe-octave: 49b3f6c6d255
This should be using the same logic that we currently have for de-activating that transformation in the startup scripts. I.e., short paths aren’t used when building the “default-octave” target.
I.e., none of the builds from octave.space are currently de-activating that transformation.
Edit 4: Now that Octave 7 is on the stable branch, the mxe-default builds on octave.space should start working again. The next builds can be used to test the new launchers.