macOS-like application packages

[osdever]

What do you think about implementation of something on top of simple executable formats? It can be for GUI only, maybe there can be an command-line executor. It can be a renamed .tar with special structure, e.g. configuration, icons, wanted libraries, the binary itself (or path to it), etc. So what do you think about it? I think that it'll be a good choice when my OS will get more advanced.

[max]

Hey,

I'm working on something similar for my OS and think it's a good idea. But, I'm planning to do it like Mac OS: simply a folder that is treated as an application. This folder will then contain a main executable, and can also contain the icon & some files that describe the application. Putting it in one file isn't really necessary, you can as well make it look to the user as if it was one application.

I don't like how Windows does this - they put resources into the executable. I think that the main executable of the application should be a plain executable, and all resources rather be packed into a wrapper, just like in .app folders.

[Techel]

As Max suggested, the best option in my opinion is separating resources and executables, either within in a directory or directly packed into an archive, like a simple zip file but with another file extension or even file header in case your operating system doesn't use the concept of file extensions or descriptors out of the file's content in general. To simplify access to these resources, I'd go a bit further and enable services to register own handlers for particular types of files, so one can access any archive or said packages via the usual filesystem mechanism.

[osdever]

Hey,

I'm working on something similar for my OS and think it's a good idea. But, I'm planning to do it like Mac OS: simply a folder that is treated as an application. This folder will then contain a main executable, and can also contain the icon & some files that describe the application. Putting it in one file isn't really necessary, you can as well make it look to the user as if it was one application.

I don't like how Windows does this - they put resources into the executable. I think that the main executable of the application should be a plain executable, and all resources rather be packed into a wrapper, just like in .app folders.

OK. Advantage of my way is that we can just send applications by web just like other files.

[MajickTek]

*bump*

I've thought of a simple solution to send the file(s) over the web. You have two formats. One is the folder (.app, contains resources/executables), and one is the bundle (.apk, much like .zip but containing contents of .app). Users could simply download the .apk and the OS would automatically extract it to .app.

EDIT:
.apk is created through a bundler program, much like the .exe bundler on Windows(I forget what it's called) that packs resources into a single exe. Although mine would be a renamed .zip.

[onlyonemac]

I personally discourage interfaces that make things look different to the way they actually are. If something's stored as a directory on disk, I want to see it as a directory, even if it's a "special" directory that makes up an application. (The same applies to files. I hate file managers that "transparently" display archives as if they were directories.) At the very least, I should be able to override this behaviour without having to resort to renaming the directory.

[osdever]

I personally discourage interfaces that make things look different to the way they actually are. If something's stored as a directory on disk, I want to see it as a directory, even if it's a "special" directory that makes up an application. (The same applies to files. I hate file managers that "transparently" display archives as if they were directories.) At the very least, I should be able to override this behaviour without having to resort to renaming the directory.

In my future file manager there would be:
1) "ShowValidAppArchivesAsPackages" setting;
2) Invalid application packages will be shown as regular archive, just with small "corrupted package" icon in corner.

[Roman]

In macOS you can right-click an .app bundle and then click the corresponding option to view the contents. This is, in my opinion, the best behaviour.

[osdever]

In macOS you can right-click an .app bundle and then click the corresponding option to view the contents. This is, in my opinion, the best behaviour.

Thanks for the idea. My OS is really, really far from file manager and FS at all, but when I'll implement it I'll use that too.

[onlyonemac]

In macOS you can right-click an .app bundle and then click the corresponding option to view the contents. This is, in my opinion, the best behaviour.

Personally I find that that still makes the user (especially if they're non-technical) think that they're working with a file rather than a directory. So now they'll get confused when they try to email it, or copy it to another storage device, or view the properties of the parent directory and the child directory count is greater than they expect it to be, or whatever. As soon as you try to hide details like that from the user, you're adding room for confusion. (The same applies to the "libraries" in Microsoft Windows, for example - I've had plenty of users get confused when they put a file in a library and now they can't find it in a directory when it's actually in another directory, or why sometimes a file is there and sometimes it isn't when they're sometimes looking at a library and sometimes looking at a directory without realising it.)

[osdever]

In macOS you can right-click an .app bundle and then click the corresponding option to view the contents. This is, in my opinion, the best behaviour.

Personally I find that that still makes the user (especially if they're non-technical) think that they're working with a file rather than a directory. So now they'll get confused when they try to email it, or copy it to another storage device, or view the properties of the parent directory and the child directory count is greater than they expect it to be, or whatever. As soon as you try to hide details like that from the user, you're adding room for confusion. (The same applies to the "libraries" in Microsoft Windows, for example - I've had plenty of users get confused when they put a file in a library and now they can't find it in a directory when it's actually in another directory, or why sometimes a file is there and sometimes it isn't when they're sometimes looking at a library and sometimes looking at a directory without realising it.)

This is why they will be .tar's in my OS.

[onlyonemac]

This is why they will be .tar's in my OS.

What about when there's a .tar that gets misinterpreted as an "application package"?

[bzt]

Hi,

Just for the record, MacOSX does not use .app directories, it uses .dmg files for distribution. But at the end, it doesn't really matter, as all (either directory, dmg, zip, tar, cpio, apk, pkg, deb, rpm) serve only one purpose: group files together.

If you think it that way, things became simple. One big difference is how the files are extracted:
1. into one directory (as in Mac's .app)
2. into separate directories (see FHS)

Both has advantages and disadvantages. One directory is easier to handle, but it can't use shared libraries (as all application have to include it's own version of the library, so we can't call them shared). On the other hand placing files into different directories solves that problem, and with proper dependency handling you don't have to boundle libraries with your application (meaning smaller distribution files). Extracting files into several directories is only problematic on Windows, where you don't have a standard location for your files. On Linux, using the aforementioned File Hierarchy Standard, it's quite straightforward.

About sending a directory over email: this should be implemented as an application feature. So user sees it exactly as if it were a single file (just like in MacOSX), and file grouping is done with mime parts in this case. In other words it's solved at a higher level: the user clicks on a file/folder to send it via email, and it's the MUA's job to create the proper attachment(s) (either one mime part, or more related parts). On Linux, you can use munpack or mimedecode to extract those from an attachment into files.

Finally referring to @onlyonemac: you're right, that's why they use a different extension, although apk, deb, rpm etc. are simple archives nothing more. When I had to develop a packaging system, I've used a different approach than renaming: for your application you'll need meta information (like license, dependencies, version etc.). You can check (as I did) the existence of a file containing those meta information to distinguish normal archives from "application packages" (I mean the archive should have metainf.xml or meta.json or whatever as the first file in the archive. Or even a directory as in deb).

[onlyonemac]

About sending a directory over email: this should be implemented as an application feature. So user sees it exactly as if it were a single file (just like in MacOSX), and file grouping is done with mime parts in this case. In other words it's solved at a higher level: the user clicks on a file/folder to send it via email, and it's the MUA's job to create the proper attachment(s) (either one mime part, or more related parts). On Linux, you can use munpack or mimedecode to extract those from an attachment into files.

That sounds clumsy and likely to cause compatibility issues, again with users who don't understand what's actually going on. Users of other operating systems or email clients are going to see a bunch of attachments and think "what on earth is going on here???". Personally I prefer the single-file version (i.e. tarball with a different extension).

[dozniak]

This is why they will be .tar's in my OS.

It's done as a directory for very simple reason: it's easy to read files inside an .app using standard filesystem. You don't need to do anything, to unix tools .app looks like a directory, Finder just adds a special interpretation on top (e.g. reading the icon file from the Info.plist). Inside the executable of the app (which is in MacOS/Contents/appbinaryname by the way) all the libraries and resources are addressed relative, so still use normal unix filesystem calls to load and run.

With tar you will have to emulate those and if somebody needs to update resources in the app they'd have to 1) unpack the tar somewhere, 2) replace necessary files, 3) compress back to tar.

macOS avoids that while maintaining full backwards compatibility with the UNIX way (i.e. you can wrap a normal unix app to be an .app bundle by providing a shell script that sets up paths and then calls original unix application).