Windows startup - vbs, bat, or exec?

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.

previous mailing list discussion:

“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.”

JWE asked if it could just be done with a separate ‘launcher’ exe, and JohnD provided one here:
https://lists.gnu.org/archive/html/octave-maintainers/2020-08/msg00034.html

Don’t think these were ever captured in a bug report. probably should be. I’d have to hunt some more to see if one was created that i missed.


a sampling of previous vbs startup/installation issues:

1 Like

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 pushed a patch to MXE Octave that no longer deletes the wrapper executables when packaging for Windows:
mxe-octave: 90a4202652e7

They won’t set any environment variables. But after recent changes, they should be usable to start Octave with version 7.x (from an environment that already has set “good” variables).

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.

mxe-octave-diffs.txt (10.1 KB)

1 Like

That sounds very reasonable to me.

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…

1 Like

If you also think that the current patch is a good enough starting point, could you please push it to the repository? I could try and work on some of the remaining points maybe during the weekend.

I made some additional changes and pushed a changeset to the mxe-octave repo.

Maybe the octave.bat and octave.vbs scripts should also be named octave-launch.{bat,vbs}?

The argument against keeping the vbs and bat files is that we now have to remember to modify all three. I would rather have just one file to change.

I pushed an patch to use Unicode-aware, safe Windows API functions:
mxe-octave: b8e9589b7794

Added a first-time launcher following @jwe’s suggestion here:
mxe-octave: 9cd5425b033b

Pushed another patch that modifies the installer to package and use the new launcher executables:
mxe-octave: ea224bb389e3

It might be nice if these executables would show the Octave icon. That would probably make it pretty clear to any Windows user venturing into the installation folder that these are the executables that are meant to run Octave.
For an example: windows - How do I add an icon to a mingw-gcc compiled executable? - Stack Overflow

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.

1 Like