RFC: Application Package Format

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

RFC: Application Package Format

Mensaje por aowen » 11 Mar 2017, 12:42

If you think LFN support on esxDOS is a good idea, stop reading now. I'm working on an application package format for UnoDOS. This would hopefully encourage people to stop trying to write apps in 7K as external commands. Right now I'm looking at something based on GNUstep. That is to say, applications existing within their own folders. Applications stored in this format would be launched with a .RUN command and would be able to take parameters (passed from the .RUN command). Given the 8.3 file format, I'm thinking apps should live inside a PROGRAMS folder and the folder would be the name of the application (up to 11 characters). So for example ".run jetsetwilly" would load the binary "/programs/jetsetwi.lly/jetsetwi.app" at 32000, set the stack to grow down from 32000, page the BASIC ROM in and call the code at 32000. Any config files and resources used by the app would live in the "/programs/applicat.ion/" folder (where applicat.ion is the name of the app). This system would be backwards compatible with esxDOS 0.8.5 (so you could use the .RUN command and this hierarchy with divIDE and divMMC devices). Any thoughts?

Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: RFC: Application Package Format

Mensaje por Uto » 11 Mar 2017, 23:00

That is more or less what ZXUC does when called without parameters, except for the auto-contained folder. I think it's a good idea to have a folder for an application, with all files needed inside.

On the other hand I think having to use .RUN to load those applications adds unnecessery typing and forces users to remember a new syntax, so...

Why not instead of

Código: Seleccionar todo

.RUN jetsetwy


you just let user write

Código: Seleccionar todo

.jetsetwy
and run application at /PROGRAMS/JETSETWY just when dot command with that name does not exist?

That way you can use same syntax dot command uses and everything is easier for users already used to dot commands.

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

Re: RFC: Application Package Format

Mensaje por aowen » 12 Mar 2017, 13:28

Uto escribió:Why not instead of

Código: Seleccionar todo

.RUN jetsetwy

you just let user write

Código: Seleccionar todo

.jetsetwy
and run application at /PROGRAMS/JETSETWY just when dot command with that name does not exist?
That way you can use same syntax dot command uses and everything is easier for users already used to dot commands.
Some reasons:
* I'm planning to support this functionality in SE Basic 4.2 via the RUN command. On the Chloe there is no requirement for the DOS folder.
* Using a launcher command lets you use longer filenames (11 characters as opposed to 8).
* As with MS-DOS, the name you type as a parameter can be longer than the character limit. This would not work as a dot command.
* You lose the benefit of the application bundle if you have to install something separately from the app.
* Without the .RUN command, the app author has to deal with parsing the syntax instead of it being done for them.
* Without the .RUN command, the app author has to deal with returning cleanly to BASIC instead of it being done for them.
* The DOS folder isn't the place for applications.

Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: RFC: Application Package Format

Mensaje por Uto » 12 Mar 2017, 14:09

I think I didn't explain it well: I meant keeping the applications in their folder with all data inside as you said, but not needing to use the .run command.

That is: if user types .xyz UnoDos searchs for a command in DOS folder named xyz, if missing the it looks for a folder in the /programs folder named xyz , and if it exists then it automatically runs :

.run xyz

If user typed

.xyz param1 param2

the when unodos realizes xyz dot command is missing, it runs

.run xyz param1 param2

In the end is saving user from learning new syntax, and even knowing if a specific application is a dot command or an app bundle. For Chloe, users can still use .run command although it would be nice for them being able to use shortcut version too.



I suggested something like that in the past for esxdos: having a /bin/tap folder and when someone types .xyz and xyz command is missing the try to load /bin/taps/xyz.tap

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

Re: RFC: Application Package Format

Mensaje por aowen » 12 Mar 2017, 20:26

Uto escribió:I think I didn't explain it well...
Ah well now you're talking about making it UnoDOS specific, whereas I'd like to keep this interoperable with esxDOS.

Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: RFC: Application Package Format

Mensaje por Uto » 13 Mar 2017, 00:13

aowen escribió:
Uto escribió:I think I didn't explain it well...
Ah well now you're talking about making it UnoDOS specific, whereas I'd like to keep this interoperable with esxDOS.
Not exactly, the .RUN dot commant will exist, I just saying UnoDOS may save users from extra typing, extra syntax, and extra understanding. Users of ESXDOS would have to explicitly use .RUN though, so UnoDOS would be more user friendly.

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

Re: RFC: Application Package Format

Mensaje por aowen » 13 Mar 2017, 10:07

Uto escribió:
aowen escribió:
Uto escribió:I think I didn't explain it well...
Ah well now you're talking about making it UnoDOS specific, whereas I'd like to keep this interoperable with esxDOS.
Not exactly, the .RUN dot commant will exist, I just saying UnoDOS may save users from extra typing, extra syntax, and extra understanding. Users of ESXDOS would have to explicitly use .RUN though, so UnoDOS would be more user friendly.
Well if I figure out how to do it then I'll certainly consider it. Right now I'm still ironing out the kinks from the .RUN command. Things that should work are not working. More testing required. But I have managed to build an app version of Manic Miner. I can manually launch it, so I just need to get the .RUN command to do it.


Alcoholics Anonymous
Mensajes: 10
Registrado: 14 Nov 2016, 04:53

Re: RFC: Application Package Format

Mensaje por Alcoholics Anonymous » 11 Ago 2017, 07:18

Nice Andrew.

I am thinking of doing something similar but with more variety in exe types. Some people want to use sna snapshots as their initial exe, some a loader binary (as you are doing) and I'm also looking at a self-contained file for z88dk's output (one that contains everything in a single file).

So ".run name" might do this:

1. Look for name in /programs (or wherever).
--> If name is a file, it is a self-contained file and should be loaded in a way to be determined. Probably exactly as in 2a using header at front.
2. If name is a directory, look inside /programs/name for:
a. file "name". This will be a binary loaded to an address indicated in a header at the front of the binary. This address may be inside the lower 7k that .run is sitting in. The header may demand that ramtop be a certain minimum value else exit "M RAMTOP no good (nnnnn)" where n=required ramtop value (I do this already for dot commands generated by z88dk so that dot commands can optionally use main memory).
b. file "name.sna". Load this snapshot and run.
c. file "name.tap". Load this tap as if from basic.
Set the current working directory to programs/name

Avatar de Usuario
aowen
Mensajes: 178
Registrado: 07 Oct 2015, 13:32

Re: RFC: Application Package Format

Mensaje por aowen » 11 Ago 2017, 17:03

Alcoholics Anonymous escribió:I am thinking of doing something similar but with more variety in exe types. Some people want to use sna snapshots as their initial exe, some a loader binary (as you are doing) and I'm also looking at a self-contained file for z88dk's output (one that contains everything in a single file).
There's really no limit on what you can do with the UnoDOS app package format. I'm already in the process writing an SZX handler for converting snapshots into apps. I personally prefer separate resource files, but you could always extend SZX as a single file container. It's basically a RIFF file anyway.
So ".run name" might do this:

1. Look for name in /programs (or wherever).
--> If name is a file, it is a self-contained file and should be loaded in a way to be determined. Probably exactly as in 2a using header at front.
2. If name is a directory, look inside /programs/name for:
a. file "name". This will be a binary loaded to an address indicated in a header at the front of the binary. This address may be inside the lower 7k that .run is sitting in. The header may demand that ramtop be a certain minimum value else exit "M RAMTOP no good (nnnnn)" where n=required ramtop value (I do this already for dot commands generated by z88dk so that dot commands can optionally use main memory).
b. file "name.sna". Load this snapshot and run.
c. file "name.tap". Load this tap as if from basic.
Set the current working directory to programs/name
1. I guess the file_exists check would serve to determine this. For now I'm looking to do the simplest thing that works.
2. I'm using a common program name so all the .run command has to do is resolve the program name into a folder.
a. Ideally I think the app should be able to simply set the RAMTOP it needs. However, I haven't managed to get this working yet. The .RUN command pages out the MMC pages when it calls the app so you're running in normal RAM and you can access files using the normal method. This is important if you want to load snapshot data into the lower 16K. The downside is the snapshot launch code has to live in the screen area.
b. .SNAPLOAD already supports SNA and Z80 files. SZX is a much more useful format though.
c. I can't see the point of tape emulation in apps except if required to support multi-load games. In which case I'd expect the app code to handle mounting the relevant TAP file which would live inside the app folder.
I already set the working directory to the app directory.

Responder