WBStartup for OS1.3

[Matt_H]

Context: setting up a "high-end" 1.3 productivity system under UAE because... well, who knows. ;-)

Does anyone know of any old programs that offer WBStartup-like functionality under OS1.3? Basically, I want to stick a bunch of tools in a directory and run a command in the startup-sequence to execute them all.

I thought about setting up a script to do such a thing (modeled off the way the monitor drivers are loaded in OS3) but it chokes on the .info files and 1.3 doesn't seem to support exclusionary/"NOT" pattern-matching to filter them out.

Any ideas?

[TribbleSmasher]

Enhanced wildcards and patterns were introduced with 2.0, i think, with the inclusion of work done by "AmigaDOS Research Project", aka ARP.
You can add the arp.library and the commands to 1.3, but you have to be aware of some changes of course. Sko rtfm.
http://megaburken.net/~patrik/17bit-1/unpacked/466/Arp1.3/ArpReadMe

[Matt_H]

Thanks for the suggestion! ARP has 2.0+-style pattern matching, so I've got this working.

(Boring technical explanation follows)

The downside is that a full ARP installation (i.e., replacing all C: commands with ARP versions) somehow made the system very unstable. That was surprising. So I backtracked a bit. Maybe I could get away with running the default List command through ASH, the ARP Shell? Unfortunately not; I thought the enhanced pattern-matching features would be available simply by having arp.library and using ASH, but they're actually baked-in to the replacement C: commands. So I ended up just installing ARP's List command as C:List.ARP (along with arp.library).

The lines I added to my startup-sequence are:

Code: [Select]

C:List.ARP >NIL: SYS:WBStartup/~(#?.info) TO T:W LFORMAT "SYS:WBStartup/%s"
Execute T:W
C:Delete >NIL: T:W
Just like loading monitor drivers under OS3.

Technically this arrangement doesn't start the contents of my SYS:WBStartup "from Workbench" like the official implementation under OS2+. The contents of the drawer are being started from CLI, but that was a pretty normal thing to do with 1.3-era utility programs. There are tools on early Fish disks (WBRun, WBLaunch) that operate similarly to the OS3.5+ WBRun to launch Workbench programs from the CLI so I may give those a try, but for now I've accomplished what I intended to do.

[Jope]

What kind of instability did you find? I have replaced all commands with ARP in my 1.3 setup and haven't been that inconvenienced.

I never ended up trying the ASh, instead opted for WShell 2.0 with its console replacement.

[Matt_H]

@ Jope

It was the Version command, I think, that was disrupting things. I know Version and version strings work differently on 1.3 compared to newer versions of the OS, but whereas I'd get a simple error with the built-in Version command, ARP's Version would more often than not lead to a Guru. So I probably could have gotten away with using all the ARP commands *except* Version, but I opted to keep things as close to stock as possible and only installed List (under its new name).

I've also got WShell installed and I'd hoped that it would offer advanced pattern matching, but, alas, it did not. But I'll definitely keep it for its close gadget and scrollbar! I opted not to replace CON: since I couldn't get the close gadget to work in regular Shells.

And as a general note, since I'm not sure it's widely known, DOpus 4.11 works under 1.3. Makes life so much easier; I could not have accomplished any of this without it.

[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?

[Matt_H]

@ Joloo

Very generous of you to offer assistance, thanks. But in all my years of computing I've never been able to figure out coding, so I wouldn't be able to offer much help from my end other than saying "Oh, make it do this!" . Still, if you want to pursue a cleaner solution, by all means go for it, and I can help test it. Just watch out for a scenario like this.

Other thoughts:

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.

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.

As reference, this and this contain the aforementioned WBRun and WBLaunch. 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.

[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. :-)

[Matt_H]

Alright then, I'm available to test whenever you have something ready. Thanks for taking this on!

[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

[Matt_H]

Yup, I can confirm that this early version successfully parses the directory and skips the .info files.  
So that's the hard part done. If you can clean up the output so that it can be routed straight into a script file then it can replace the ARP workarounds I used. Curious to see what the commandline arguments will ultimately do.

A few stress tests to consider for use as a full-featured direct launcher:
1. What happens if a project (or other non-executable) icon is in the directory? e.g., foo.readme and foo.readme.info. Presumably the functionality should be as if double-clicking the icon, i.e., invoke the default tool and pass along any tooltypes. Or is there a way to skip/ignore non-executable files (maybe a commandline switch)?
2. What happens if there's a project file in the directory with no associated icon? e.g., foo.readme alone. Skip? Or let it quietly fail, as if you'd typed the name into a shell?

Much later on, I can also envision a different use-case where a user might want an external config file to pass along different arguments to different files in the directory. i.e., if the parser finds a file in the directory that matches a line in the config file, use the options specified in the config file.

Thanks again

[TribbleSmasher]

You really only have to check for the first longword of the file equals 0x03F3, which indicates an executable. If you find an icon too it is probably a Workbench app.

Edit: spelling.

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

[Matt_H]

Thanks. Getting a few errors with this one, I think. It seems to parse/execute directory contents correctly (and ignore non-executable binaries and text files, even with .info files) but it reports back "insufficient free store" and "**Unfreed signals 40000000!" Is that normal debug output or is something off? It hasn't crashed the system, although I haven't stress-tested it much.

Am I correct that it defaults to executing via WB? 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). If a hypothetical 1.3 WBStartup drawer contained a mix of CLI- and WB-based programs, being able to understand a "CLI" tooltype would be an easy way to differentiate them while still using only one ALU command. Later OS releases can parse "CLI" to launch CLI commands from Workbench, so this would be a way to kinda-sorta backport that feature for a particular use-case.