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?

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

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

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

[Matt_H]

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

[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

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

[Matt_H]

Thanks! It seems to be working as expected, but I'll let you know if any issues come up as I continue working with it. Managed to shave a few seconds off startup, too, since I don't have to fuss with all those extra scripts and manual program execution.

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

[Matt_H]

Have you put this up on Aminet? I think it's worth distributing more widely.

[Matt_H]

Little bump to say that I've just sent alu up to Aminet. Great little utility - deserves more widespread use.

[Matt_H]

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

Hey, thanks for writing it!