WBStartup for OS1.3

[Joloo]

@ Matt_H

Interesting idea.

If you're still after a better solution, I could give you a helping hand.

I've released 'dosgv' and 'AltWBench' and they can be found on Aminet, which are OS1.x application programs that are using the BCPL interface. They can be held as starting point for your idea (especially 'example.c' within 'dosgv' for argument parsing and listing directories, and 'AltRun.c' within 'AltWBench' that shows how to provide paths to the new created processes).
Moreover, 'additem' (also on Aminet) that I've programmed around 25 years ago, shows that even with the primitives of OS1.x, application programs can be launched as if they would have been started by Workbench.

My guess is that such a launcher (listing directory contents and running the application programs therein, either as CLI command or as a (faked) Workbench sub-task) would take less disk space than ARP. ;-) Unfortunately, when launching application programs as if they were launched by Workbench, does require a process to stay alive until the last launched application program has been terminated, what means that either the launcher has to stay alive all the time or that this one creates a sub-task that fetches the returning messages while the launcher itself quits.

I would speculate that such a launcher can be written in a day or two by any programmer (in C, assembler takes longer), even one is unfamiliar with the BCPL interface offered by the AmigaDOS of version 1.x.
So, if you aren't in a hurry, I could write the basics at the weekend and then you can check if it suits your requirement or if you need to update it.

Are you interested?

[Joloo]

@ Matt_H

I like your idea so I will implement it, though, I need your assistance in regard of testing, and maybe for features, because I often losing myself in details that an end user never uses.

But in all my years of computing I've never been able to figure out coding

That's fine with me. Maybe there are others who want to modify the source codes, once a basic implementation has been built.

Isn't that how the "real" WBStartup works on 2.x+? i.e., all those messages when you try to quit Workbench: "Cannot quit yet, there are x WB launched program(s)." And since no one ever really quits Workbench that doesn't strike me as a significant problem.

Yes, you are right. That's the reason why a Workbench cannot be shut down. The other one is due to opened windows shown on the Workbench.

As reference, this and this contain the aforementioned WBRun and WBLaunch.

To my shame, I haven't used them nor did I read their documents. If I face an issue (challenge!), I try my own solution first, and only if that fails or a much better solution exist, I use that instead. :-)

I'm sure you're a better judge than I as to how well those solutions are implemented at a coding/system level for CLI-based Workbench application launching.

If things work and they don't tend to cause any instability issue, then they must have been carefully implemented. :-)
My best guess is that those two programs are well designed. :-)

[Joloo]

@ Matt_H

I've taken the first steps. The fundamental functions are all implemented but require combining them. Currently, the application program is just a simple DIR command but much too fat for that purpose. :-)
I only had this morning to spend some time on it; due to that sunny weather here, I left home around noon and I don't think that I'm going to code more code lines today. Tomorrow is a new day. :-)

Nonetheless the result can be found here; http://amimedic.de/private/alu.lha

[Joloo]

Curious to see what the commandline arguments will ultimately do.

PATH=FILENAME/A,CLI/S,LAUNCH=WB/S,STACK=STACKSIZE/N,WAITWB/S,OUTPUT=OUT/K,DEBUG/S,EXECUTE=RUN/K,,,,,,,,,,,,,,,,

PATH or FILENAME
Provided as path, the entire application programs therein will be executed.
Provided as filename, a single command is executed or launched. If EXECUTE or RUN is specified, too, up to 16 arguments can be delivered to the command in question (CLI or WB start).
If a 'PATH' was chosen, ^*EXECUTE or ^*RUN is completely ignored, as no application commands have got the same argument lists.

^*I should replace EXECUTE=RUN/K with ARGS/K, than it is much clearer, I guess.

CLI - just execute the the command(s) as if started through CLI - see PATH or FILENAME, ignoring auto file type detection.
WB - launch command(s) as if started through Workbench, ignoring auto file type detection.
STACK - stack size set to number of bytes for commands launched as if started through Workbench.
WAITWB - wait for Workbench being up and ready before running or launching any command.
OUTPUT - in case commands are started as if started through CLI, you may enter an output stream, for example "NIL:", "*", or "CON:0/0/640/200/CLI". The default currently used is "*" - current console.
DEBUG - only in case this switch is turned on, some output from the side of alu will be made, otherwise no output at all. But that one only gets supported for version leaving alpha state. Currently, alu is not at all alpha!

My aim is starting any application program without any assistance from the user side in the first instance: if a command without an icon file has been encountered, do start it as CLI command. If the icon file does exist, launch it as if started by Workbench.
If the 'S' protection bit is set, handle it as script that has to be executed. If the 'E' protection bit is not set, ignore this command/file.
If no HUNK_HEADER (first long word of a file, $000003F3) is set, ignore the command/file. If that fails, one can choose out of the options alu offers.

I have had only a few hours to work on it again, but it now allows entering single files and detects file types (hopefully).
Please, can you test the functionality to recognise file types and send me some test files in case my file type detection fails?
Still, it doesn't start or launch any application program nor a script yet.


@ TribbleSmasher

Right, and that's how I made it. In addition, I check also for the corresponding protection bit, if the "E" protection bit is missing, the file is treated as nonexecutable.


New version on same place, http://amimedic.de/private/alu.lha

[Joloo]

New version online which now can start scripts, CLI commands and Workbench application programs.
Text file enclosed explains it a bit.

[Joloo]

@ 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.

[Joloo]

@ TribbleSmasher

Don't worry.
My English isn't the best so I am trying to use short sentences, which might be misconceived by any native reader.
What I really wanted to state is that a dock app (with a GUI) and a CLI command like ALU cannot be comparable. Both suit different needs.
Beside that, the complexity of ALU tends against zero and as I wrote before, it is basing partly on source codes I've already written decades ago.

[Joloo]

I've got reviewed and completed 'alu'. I call it now the final version.
Enclosed is also a short description how to handle it.

Regards

[Joloo]

@ Matt_H

Really appreciate your lead on this--thank you again.

It was my pleasure! 
Now I've myself a tool that I should have written already years ago, so thank you for encouraging!

By the way, version 1.3 is now online (since two weeks ready but I've forgotten to upload it).
It is now independent of the 'vbcc' compiler and can be compiled using GNU-C or MaxonC++/HiSoftC++, so anybody with a C-compiler and spotting a fault should be able to fix it himself, but please, if you do so, make the source codes publicly available again. Thanks!

[Joloo]

@ Matt_H

Well, anyone is allowed to upload it where ever he/she likes. Of course I can do an Aminet-upload, but at the moment it has got a very low priority on my side.
I still have some more programs awaiting an Aminet-upload, some for years.
Shame on me... 

[Joloo]

Just saw that you've uploaded 'alu' to Aminet - thanks for that! 

[Joloo]

Who has got laid out the foundation? Was it you or me? 
Let's honour the one with the idea, not the one who just pieced it together! 

In the end, I do profit myself a lot from this tiny tool as I can now fire up test environments for projects I've written without the need to create and maintain scripts, which were used in the past to start these test environments. Just "alu testcase/" does the trick now.

So, thanks a lot for coming up with the idea!