macOS-like application packages

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
osdever
Member
Member
Posts: 492
Joined: Fri Apr 03, 2015 9:41 am
Contact:

macOS-like application packages

Post by 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.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing

OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
User avatar
max
Member
Member
Posts: 616
Joined: Mon Mar 05, 2012 11:23 am
Libera.chat IRC: maxdev
Location: Germany
Contact:

Re: macOS-like application packages

Post by 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
Member
Member
Posts: 215
Joined: Fri Jan 30, 2015 4:57 pm
Location: Germany
Contact:

Re: macOS-like application packages

Post by 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.
User avatar
osdever
Member
Member
Posts: 492
Joined: Fri Apr 03, 2015 9:41 am
Contact:

Re: macOS-like application packages

Post by osdever »

max wrote: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.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing

OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
User avatar
MajickTek
Member
Member
Posts: 101
Joined: Sat Dec 17, 2016 6:58 am
Libera.chat IRC: MajickTek
Location: The Internet
Contact:

Re: macOS-like application packages

Post by 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.
Everyone should know how to program a computer, because it teaches you how to think! -Steve Jobs

Code: Select all

while ( ! ( succeed = try() ) ); 
onlyonemac
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: macOS-like application packages

Post by 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.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
User avatar
osdever
Member
Member
Posts: 492
Joined: Fri Apr 03, 2015 9:41 am
Contact:

Re: macOS-like application packages

Post by osdever »

onlyonemac wrote: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.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing

OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
User avatar
Roman
Member
Member
Posts: 568
Joined: Thu Mar 27, 2014 3:57 am
Location: Moscow, Russia
Contact:

Re: macOS-like application packages

Post by 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.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
- Alan Kay
User avatar
osdever
Member
Member
Posts: 492
Joined: Fri Apr 03, 2015 9:41 am
Contact:

Re: macOS-like application packages

Post by osdever »

Roman wrote: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. :)
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing

OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
onlyonemac
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: macOS-like application packages

Post by onlyonemac »

Roman wrote: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.)
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
User avatar
osdever
Member
Member
Posts: 492
Joined: Fri Apr 03, 2015 9:41 am
Contact:

Re: macOS-like application packages

Post by osdever »

onlyonemac wrote:
Roman wrote: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.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing

OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
onlyonemac
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: macOS-like application packages

Post by onlyonemac »

osdeverr wrote: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"?
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
User avatar
bzt
Member
Member
Posts: 1584
Joined: Thu Oct 13, 2016 4:55 pm
Contact:

Re: macOS-like application packages

Post by 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
Member
Member
Posts: 1146
Joined: Sat Mar 01, 2014 2:59 pm

Re: macOS-like application packages

Post by onlyonemac »

bzt wrote: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).
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
User avatar
dozniak
Member
Member
Posts: 723
Joined: Thu Jul 12, 2012 7:29 am
Location: Tallinn, Estonia

Re: macOS-like application packages

Post by dozniak »

osdeverr wrote: 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).
Learn to read.
Post Reply