Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: Matt_H on May 19, 2020, 12:35:20 AM
-
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?
-
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
-
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:
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.
-
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.
-
@ 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
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
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 (https://xkcd.com/1319/). ;)
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 (http://aminet.net/package/misc/fish/fish-0043) and this (http://aminet.net/package/misc/fish/fish-0179) 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
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. :-)
-
Alright then, I'm available to test whenever you have something ready. Thanks for taking this on!
-
@ 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 (http://amimedic.de/private/alu.lha)
-
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
-
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.
-
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 (http://amimedic.de/private/alu.lha)
-
New version online which now can start scripts, CLI commands and Workbench application programs.
Text file enclosed explains it a bit.
-
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.
-
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:
http://thomas-rapp.homepage.t-online.de/amiga/wbdock.html
Update 01-Jun-2020:
added WBStartup feature: run all programs from a directory or listed in a text file at startup
-
@ 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
It wasn't my intention to undermine your efforts, please continue. :)
But WBdock is indeed a nice addition to a classic Workbench 1.3.
-
@ 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.
-
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
-
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
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!
-
Have you put this up on Aminet? I think it's worth distributing more widely.
-
Man, that is really cool.
8)
-
@ 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... :(
-
Little bump to say that I've just sent alu up to Aminet. Great little utility - deserves more widespread use. :)
-
Just saw that you've uploaded 'alu' to Aminet - thanks for that! :)
-
Just saw that you've uploaded 'alu' to Aminet - thanks for that! :)
Hey, thanks for writing it!
-
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! :D
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!