Application Bundles for distribution

[daschewie]

Proposal

To simplify the distribution of applications, I recommend treating directories with the .app extension as an executable.

The content of the directory would contain the following:

• MyProgram.app
  • start.pgx, start.pgz, or start.elf
  • help.txt
  • resource files

The the loader would run the start.* executable. The HELP MyProgram.app command in the shell can display the help.txt file. All resource files like graphic assets can be bundled with the app.

This would allow us to distribute zip files on the web, and simply unpack them onto an sd card without overwriting files from other apps.

What does the community think?

[pweingar]

It's an interesting idea. We might need some way in the kernel for an executable to get its directory so it can find its files. I've always liked the old Mac OS approach of files having a resource fork for things and have been thinking idly about ways to implement a sort of rich file format. But I hadn't really given it much thought for Foenix/MCP specifically.

I'd like to see how the EmuTOS port is going to work out... if it's a layer on top of MCP or if it borrows source code/definition files. If it ends up sitting on top, I'd like to make sure anything like this doesn't impact that effort negatively.

[daschewie]

I agree about the new syscall. We would have the CWD for the path it was launched from and an APP directory for accessing resources. I think EmuTOS uses .tos and .prg app extensions, and would have its own binary loaders. We could add the two extensions to the start.* files, but would have to check if emutos is running prior to launching them. I guess we will know more, once it is further along.

[vinz6751]

EmuTOS wants to locate itself and system variables at the beginning of memory so competes with the FoenixMCP. So at the moment it can't sit on top, unfortunately.

This said, there is plenty of nice things we can think of for KernelMCP but we should wonder where to stop before we hit any anti-goal. Beginning to think about conventions makes me wonder about the "the system is yours, truely". Maybe the kernel should be a library, something lean like a BIOS with basic file I/O and hardware drivers. The CLI with nice standards, bells and whistles would be another layer built on top of that.

The kernel being a library/relocatable would help it being a component of EmuTOS or the CLI, or any other OS.

Sorry I'm a bit off-track but I think we should not loose sight of the goals and anti-goals of the KernelMCP.

[daschewie]

I don't think we are loosing sight of the goals. I am just suggesting an additional loader to simplify distribution of apps. In my opinion, the core of MCP is providing IO services and launching applications. :-)

[pweingar]

Concerning the anti-goals... one of the key reasons I have those in there (and one of the main reasons I didn't put in multi-tasking), is that Stefany really looks to the kernel as a simple layer to port to early boards to use for testing. That's also the reason that the kernel now has the TEST command. So, where I would really start having objections to a feature is something where it might make the kernel too big or complex to port to a new machine quickly... or where it maybe made it unstable or more complicated for her to use when testing out a new board. I get the feeling from Stefany that she is now happy with the kernel as it is (or will be once the floppy is working on the K). That said, she also does not want to stifle users.

I guess my feeling with this is that it doesn't really violate the anti-goals, and I could see it being useful... BUT I want to be careful about adding things to the kernel just in general.

Perhaps an approach here would be to make sure that the kernel had a way to support terminate-stay-resident type code (relocatable, able to be placed in an allocated block of memory, and able to install new drivers/loaders etc.). Then, something like this could be part of a more sophisticated outer layer. Right now the kernel is very monolithic (I had to write it quickly and wanted to keep it small), but the CLI in particular should maybe be pulled out into a separate layer as Vinz is suggesting.

[Ooops... ninja edit] To be clear, however, I don't have any objections really to this loader being part of the stock kernel. I don't think it would add significant complexity to the kernel and it could be useful. But I find Vinz's suggestions interesting and they kind of fit with something Stefany and I were talking about a few days ago where maybe there is a fork of the kernel that Foenix users make their own, so to speak, but then the two of us have the stripped down core for testing and initial installation... but maybe there wouldn't need to be a fork. I think I'll start a separate discussion about what it would mean for the kernel to be more of a library. I'm not sure how to picture that.