Program Launcher utility

[voidstar]

So - is anyone working on a Program Launcher type utility already?

As I'm preparing some content for the SD-card - Yeah, it would be nice to have such a thing.

I wouldn't want it to be loaded on startup by default. But it would be a nice option for end users to be able to LOAD and RUN (and then they could add to their autoboot.x16 if it was something they wanted to make started by default)


A Program Launcher is a utility to scan the current directory, and use up/down arrow to select files in that directory. ENTER on a DIR navigates to that directory, and ENTER on a .PRG "launches" that program. That's straight forward, a lot of systems have this kind of stuff (like CoCoSDC has a nice one, TFW8b provides one for MiniPET, etc). But there are a few other features I was thinking:

(1) It could verify the PRG is suitable. Just scan the first couple bytes and make sure it is a valid address range (for the X16). If not, then beep and report it as an invalid title. There are a few address areas "forbidden" for end user runtime - it might not be foolproof, but it could help cut down trying to load/run invalid programs. But when a "valid" program is found, the launch has to replicate that work of actually loading the file into RAM and handing off execution to that PRG (a little tricky when the launcher itself is using RAM.... so this would be better as a ROM utility, eventually)


(2) Launch Counter. Somewhere store how many times a given title has been launched. This way people can see what titles they haven't yet tried, or which ones are their favorites and have tried many times. And the counter could cap at 255 and just stay at that (yes it could roll higher, but why bother, and once you get to 255, you obviously like that program!)


(3) Maintain a description of the programs. This gets into boring-database territory - but as you're browsing these files/folders, you can push a button to add a description of that title (so the same program has to be an editor front end to this database). I'd want this all in one file, to avoid having multiple files for each PRG. The format is basically:
path/filename.prg
<title>
<version/date>
<description>

The immediate problem is, obviously, as users select new files - how can this program possibly look up that info in reasonable time? (i.e. once you get past just a few titles) One compromise might be using a different DB file for each folder - which is better than multiple files for each PRG (i.e. like .PRG + .NFO or .DIZ), but still clutters up by adding an extra file into every folder. Another compromise might be that it's "on demand" - users have to press "Q" to query for this info, instead of being applied as you scroll past every file.


So, that'd be my "dream" X16 File Launcher - a folder/file selector at the top, then a "description window" at the bottom or side. And the description can have how-to, tips, or website/contact information. Then also the "number of times launched" counter, since now and then it's nice to explore stuff you haven't tried before.


I think this was discussed back in January, or at least a concept of programs "installing" themselves - or "registering" themselves to this database. But I think that got side-railed trying to formalize it a bit too much - or it also had a premise of obtaining software across the NIC and having it install in some standard fashion (with the mindset of the SD-card being a hard drive rather than a disk drive). Nice ideas, but hard to get all s/w developers to comply (i.e. manifest files and all that).

BTW - as another thought on how the launch could kind of cheat: when a title is selected, it could auto-generate the appropriate AUTOBOOT.X16, write that, then "JMP" itself to the KERNAL BOOT function.

Anyway, just wondering if anyone has already started on such a thing, or is motivated to give it a shot over the next month for the SD-card?? Just that first step of collecting the list of file sin the current directory is a hassle - how are they sorted? can we search the names? what we have way more than can fit on the screen, now we have to scroll, etc.

[ahenry3068]

I wish I could volunteer. But my time is better used finishing Hangman I think...

I would suggest the following logic. Think of a group of small programs as subroutines. Do the autoboot.x16 and boot route.

Before the new autoboot loads the program make it restore the main autoboot then call itself again.

[AndyMt]

So - is anyone working on a Program Launcher type utility already?

Actually I started something like that. On a very basic level, so I can chose which PRG in subfolders to start for debugging. Typing DOS"CD:XYZ LOAD, RUN etc. got just so anoying and AUTOEXEC wasn't always what I wanted... resulting in copying stuff back and forth...
I would very much like to extend this into a proper launcher, showing a screenshot + description if present etc. But as you already noted: I think something like this is/was in the works. I have to search the forums to see if this would be a redundant effort. Or I could join and drive it further?

[mortarm]

(2) Launch Counter. Somewhere store how many times a given title has been launched. This way people can see what titles they haven't yet tried, or which ones are their favorites and have tried many times. And the counter could cap at 255 and just stay at that (yes it could roll higher, but why bother, and once you get to 255, you obviously like that program!)

My two bits: "...titles they haven't yet tried..."; If you installed a program, wouldn't you want to run it right away? "...which ones are their favorites and have tried many times."; I doubt most people would need to be told which programs are their favorites, besides, you may have a program that you run many times--e.g., a utility--but isn't necessarily a favorite.

All that aside, a counter, in this context, is meaningless without a frame of reference. Namely, when the program was last used, so you would want to show the date that happened as well. In fact, just showing the last run date would be more beneficial in terms of weeding out the dead weight. This could be viewed in either ascending or descending order. This info would, of course, come from the RTC, assuming it was set.

[voidstar]

ahenry3068: restoring the autoboot.x16 is a nice idea. But may only work for BASIC programs, and assumes the user will "properly" exit the program. Once you hand off to another ML program, very likely you're never coming back to BASIC/CMDR-DOS and so the autoboot.x16 probably won't get a chance to resume anyway (i.e. the ML program can do whatever and "corrupt" BASIC's runtime).

AndyMt: I was hoping the X Commander project would be along these lines. Seems it would need some sort of "file management" capability, so then it's just deciding on how to manage the descriptions.

mortarm: Fair points. I guess I'm selfishly thinking from the perspective of the SD-card SAMPLE disk with the system that will be pre-loaded with a bunch of stuff. The counter can also be used to remind on .PRGs that actually do work (versus "support PRGs" that just contain ML routines). I bounce across a lot of systems and lose track of "favorites". I guess just calling it favorites, instead maybe just press spacebar or something to "mark" the files (or press 1-9 to just categorize them however they'd like), and an option to filter on those (or list them first). The "last ran" could be good info to - but sure, until those NIC cards become more available (to sync with internet time), yea most ppl's RTC will probably be who-knows-what.


In the case of the SD-card "sampler" - we'll only have about a month to get something put together. Maybe I can do something that is pre-configured and tailored to the eventual selected titles. As others have mentioned "first impressions are important" so if you only have a few seconds to showoff the system, you want to quickly be able to get to the interesting titles, not fumbling through commands.

[BruceRMcF]

I had Vernon DeBorg's LIST in my DOS AUTOEXEC.BAT, if there is a launcher utility, I will have it in my AUTOEXEC.X16.

Some random thoughts.

It's perfectly reasonable for LAUNCHER to have its own folder in the root directory. So store the .INF databases for each folder in that LAUNCHER folder. There may be multiple folders with the same name in the hierarchy, so name the duplicates <foldername>_1 and etc. and the first line in the info file is the path to the folder, so if that is the wrong path for <foldername>, LAUNCHER looks in <foldername>_1, <foldername>_2, etc. The time saved in having distinct info files per folder versus one mammoth info database will more than pay off the time to sometimes check through two or three .INF files because of duplicate names.

LAUNCHER doesn't have to contain all of it's capabilities in the program that runs. Like LIST could launch your favorite text editor on a file if you wanted, the contents of the LAUNCHER folder will include programs that can be run on selected files. LAUNCHER can put the file name in one text variable, the path to the file in another, and it's included utility programs will use that ... in many cases by being short helper programs that act as a bridge to use that information in the way that some other program needs it set up, and then running that other program.

Using helper programs (most of my LIST helper programs were AUTOEXEC.BAT scripts) means that the abilities of LAUNCHER can continue to evolve without modification to the program itself, which is a handy thing when making last minute additions of, eg, an image file viewer or sprite editor capabilities into the LAUNCHER system.

LIST was a text file viewer first, and gained program launcher, file manager and edit launcher along the way. Starting from a program launcher, you can easily hit much the same ground ... for instance, to "launch" a text file, you run the X16 editor in read-only mode. Now if someone distributes "How To" files along with their program, LAUNCHER on the How To files is automatically a help system.

LAUNCHER should include a time and date set function, even if that is redundant, because for many people LAUNCHER be their de-facto operating system.

[ahenry3068]

Thats a very good approach. It also means that developers can include their own launcher helpers. This takes a lot of slack off the initial Menu maintainers

[BruceRMcF]

On thing about mimicking basic in setting up variables is that they are then available on the command line, so one helper program may just be a Basic program that loads and then quits, so that people can experiment with what to do to get a program started correctly.

Another idea is to have a "helper" mode. which stores a string variable with the name of the program being helped, and a string variable with the ending of the type of file that the program is looking for. So the program loads LAUNCHER and executes it, so LAUNCHER takes over, and the files that end in the way the program wants are highlighted, and if the user picks a highlighted file, the program is launched and handed the name and path of the file that was picked.

Then programs that would in the old days just ask you to type in a file name can have a file picker system, without doing more than including standard boilerplate following some example programs on how to set up the variables and then load and run LAUNCHER.

There is absolutely no way to avoid variable name clashes with two letter variable names, but if the Launcher variable names don't work for an existing program, the LAUNCHER helper program can help massage away the conflict. I would recommend naming the Launcher variables (I have specified four already, but I don't think many more are required) with a first letter of Z: ZF$ ZP$ ZM$ ZT$ for Launcher Filename, Pathname, Helper Mode, and File Type.

[DragWx]

I don't have time to test this, but I had a thought. If the launcher were machine code, then the BASIC program would look like this:

Code: Select all

1 SYS 2345

Internally, that SYS call executes as a simple JSR, and when the launcher code finishes and RTS's, the BASIC program continues.

When a game is selected in the launcher, the launcher could directly modify the currently-running BASIC program at $801 to add a line 2 with the DOS command to switch directories, and a line 3 to LOAD the desired program file:

Code: Select all

1 SYS 2345
2 DOS"CD:MYGAME/"
3 LOAD"GAME.PRG",8,1

Then, when the launcher code RTS's, the selected program automatically chain-loads and runs. BASIC wouldn't realize the program changed while running, and would just proceed to lines 2 and 3 like they were always there. The menu could also allow you to quit out to BASIC by simply not adding lines 2 and 3.


To create a list of games to choose from, I think it'd be easiest to have a human-readable/editable file that the launcher reads, which is just a CSV:

Code: Select all

DISBRK/,DB.PRG,THE AMAZING DISAPPEARING BRICKS
BMSIM/,BMSIM.PRG,BLUEBERRY MUFFIN SIMULATOR
SQUIRCLE/,SQUIRCLE.PRG,MR.SQUARE'S ADVENTURES IN CIRCLELAND

If the user's already in the SD card adding another folder and files to it, then I think it's reasonable for them to be able to open this index file too and add a new line to it, or to customize it however they want.

[BruceRMcF]

I don't have time to test this, but I had a thought. If the launcher were machine code, then the BASIC program would look like this:

Code: Select all

1 SYS 2345

Internally, that SYS call executes as a simple JSR, and when the launcher code finishes and RTS's, the BASIC program continues.

When a game is selected in the launcher, the launcher could directly modify the currently-running BASIC program at $801 to add a line 2 with the DOS command to switch directories, and a line 3 to LOAD the desired program file:

Code: Select all

1 SYS 2345
2 DOS"CD:MYGAME/"
3 LOAD"GAME.PRG",8,1

Then, when the launcher code RTS's, the selected program automatically chain-loads and runs. BASIC wouldn't realize the program changed while running, and would just proceed to lines 2 and 3 like they were always there. The menu could also allow you to quit out to BASIC by simply not adding lines 2 and 3.

Maybe it doesn't have to modify it. IIRC about string concatenation (I do not have the emulator open right now), it can be built as:

Code: Select all

1 SYS 2345
2 DOS "CD:"+ZP$
3 LOAD ZF$,8,1

... so that what it is doing is the directory browsing and display and setting up the Z variables for the chosen file, and letting Basic launch the program, since Basic already knows how to launch programs.

To create a list of games to choose from, I think it'd be easiest to have a human-readable/editable file that the launcher reads, which is just a CSV:

Code: Select all

DISBRK/,DB.PRG,THE AMAZING DISAPPEARING BRICKS
BMSIM/,BMSIM.PRG,BLUEBERRY MUFFIN SIMULATOR
SQUIRCLE/,SQUIRCLE.PRG,MR.SQUARE'S ADVENTURES IN CIRCLELAND 

If the user's already in the SD card adding another folder and files to it, then I think it's reasonable for them to be able to open this index file too and add a new line to it, or to customize it however they want.

Advantages of a more traditional .inf file format is (1) parsing is easier ... scan for :, if you hit carriage return first, their is no path, it is in this folder ... then the following line verbatim is the display text ... and (2) there is no worries about how to escape punctuation characters in the printable names of games if the display name in the status line is just the contents of the line following the file name. And all of the paths here can be relative, because the name of the .inf file is the name of the folder that the files were extracted into, and the first line is the full path to that folder from the root directory.

Code: Select all

...
DISBRK/:DB.PRG
THE AMAZING DISAPPEARING BRICKS

BMSIM/:BMSIM.PRG
BLUEBERRY MUFFIN SIMULATOR
...