@ Matt_H
but it reports back "insufficient free store"
That fault surfaced due to a very low stack size for the sub process.
Initially, that stack size was set to 1200 bytes, now it is set to 3200 bytes. I didn't notice it for some time, because I mainly ran my tests under OS3.
The BCPL based DOS requires some more stack space than I thought...
"**Unfreed signals 40000000!"
ALU has got no such message built-in. My guess is that you have got some inspection software running in the background that reports this, as ALU's sub process doesn't free its allocated signal when it quits (it doesn't need to!). I can, of course, work around this, if you still encounter this message.
Am I correct that it defaults to executing via WB?
No, there is no default, unless you explicitly instructed ALU with the keywords WB or CLI how it should handle application programs, regardless of its auto file type detection result.
If an application program has got an attached icon, it is executed as if it was run from the Workbench. If there is no icon file for the object file, it gets executed as ordinary CLI command or script.
Semi-related, it occurred to me the other day that if it would be handy if it could parse a "CLI" tooltype in icons. I'm discovering that some 1.3-era stuff behaves differently if launched from CLI (i.e., quiet) compared to WB (i.e., pop up a requester).
That's not difficult to implement but it really slows down everything.
Loading icons into memory is a time consuming process because they will be scattered loaded in.
In my opinion it would be better, if you really encounter issues, to separate those two file types; make a sub drawer for executing application programs as if they would be launched by Workbench and another sub drawer for executing ordinary CLI commands or scripts.
But then no icon must be placed in the drawer for executing CLI commands or scripts, or it fails again due to ALU's auto file type detection, unless you specify the keyword CLI:
SYS:WBStartup/
SYS:WBStartup/WB/
SYS:WBStartup/CLI/
then:
C:alu SYS:WBStartup/WB stack 8000 waitwb
C:alu SYS:WBStartup/CLI
If you wish to state explicitly how they should be started, regardless of the auto file detection use:
C:alu SYS:WBStartup/WB stack 8000 waitwb wb
C:alu SYS:WBStartup/CLI cli
Note the appended keywords.
If a hypothetical 1.3 WBStartup drawer contained a mix of CLI- and WB-based programs
For this purpose ALU was written. :-)
It really distinguishes between file types, be it now a script (ASCII), a CLI command or Workbench application program.
I've to write ALU's manual otherwise no one than me can handle ALU. :-(
Please, try the new version, though, as this is the first version that has got all stuff built-in and which is fully functional. All earlier versions were just skeletons of my idea with no really functionality.
@ TribbleSmasher
You can add a nice little toolbar/dock to WB1.3 as well, and, as it turns out, it now has the WBStartup feature as well:
While it's a nice to have feature when the Workbench is up and running, such docks cannot start all programs and scripts residing in one drawer short after boot without user assistance - and for that purpose ALU was made.