OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Mar 18, 2024 9:33 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: macOS-like application packages
PostPosted: Thu Nov 17, 2016 4:12 am 
Offline
Member
Member
User avatar

Joined: Fri Apr 03, 2015 9:41 am
Posts: 492
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.


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Nov 17, 2016 5:21 am 
Offline
Member
Member
User avatar

Joined: Mon Mar 05, 2012 11:23 am
Posts: 616
Location: Germany
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.

_________________
Ghost OS - GitHub


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Nov 17, 2016 7:14 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Nov 17, 2016 11:08 am 
Offline
Member
Member
User avatar

Joined: Fri Apr 03, 2015 9:41 am
Posts: 492
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.


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Jan 19, 2017 6:13 am 
Offline
Member
Member
User avatar

Joined: Sat Dec 17, 2016 6:58 am
Posts: 101
Location: The Internet
*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:
while ( ! ( succeed = try() ) );


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Jan 19, 2017 10:15 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Jan 19, 2017 12:13 pm 
Offline
Member
Member
User avatar

Joined: Fri Apr 03, 2015 9:41 am
Posts: 492
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.


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Jan 19, 2017 12:16 pm 
Offline
Member
Member
User avatar

Joined: Thu Mar 27, 2014 3:57 am
Posts: 568
Location: Moscow, Russia
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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Thu Jan 19, 2017 12:53 pm 
Offline
Member
Member
User avatar

Joined: Fri Apr 03, 2015 9:41 am
Posts: 492
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.


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 6:18 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 9:30 am 
Offline
Member
Member
User avatar

Joined: Fri Apr 03, 2015 9:41 am
Posts: 492
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.


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 9:48 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 10:48 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
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).


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 1:26 pm 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: macOS-like application packages
PostPosted: Fri Jan 20, 2017 3:24 pm 
Offline
Member
Member
User avatar

Joined: Thu Jul 12, 2012 7:29 am
Posts: 723
Location: Tallinn, Estonia
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group