Why Make OS X Apps End with ".app?"

[Bunny]

Is there a good reason to do that?

[Doug Brown]

In article <a8696178.0307241254.2149c67a@posting.google.com >,
[email]bbunny@myrealbox.com[/email] (Bunny) wrote:

> Is there a good reason to do that?

Why would anyone care? The Finder hides it anyway.

Doug

--
Doug Brown - La Grande, OR
Idiot's Guide to Mac Cases - [url]http://www.ircandy.com/maccases/[/url]
If you want to reply by email, remove "pleasenospam." and ".invalid"

[Paul Mitchum]

Bunny <bbunny@myrealbox.com> wrote:

> Is there a good reason to do that?

It's inherited from NeXT. It tells the Finder (and anyone else, for that
matter) that the folder so named is an application bundle.

[Bunny]

[email]usenet@mile23.com[/email] (Paul Mitchum) wrote in message news:<1fylyja.xmoy5u1pwkjz3N%usenet@mile23.com>...

> Bunny <bbunny@myrealbox.com> wrote:
>

> > Is there a good reason to do that?

>
> It's inherited from NeXT. It tells the Finder (and anyone else, for that
> matter) that the folder so named is an application bundle.

But the app launches anyway.

I made a program in Metal BASIC, and compiled it. It apparently runs
in both OS 8.6 and OS X (I didn't know that was possible). If I share
it, I am wondering if I need to append .app to the name or not. It
runs without .app, but most commerical apps have .app appended.

[Tom Harrington]

In article <a8696178.0307250959.3d01e7f@posting.google.com> ,
[email]bbunny@myrealbox.com[/email] (Bunny) wrote:

> [email]usenet@mile23.com[/email] (Paul Mitchum) wrote in message
> news:<1fylyja.xmoy5u1pwkjz3N%usenet@mile23.com>...

> > Bunny <bbunny@myrealbox.com> wrote:
> >

> > > Is there a good reason to do that?

> >
> > It's inherited from NeXT. It tells the Finder (and anyone else, for that
> > matter) that the folder so named is an application bundle.

>
> But the app launches anyway.
>
> I made a program in Metal BASIC, and compiled it. It apparently runs
> in both OS 8.6 and OS X (I didn't know that was possible). If I share
> it, I am wondering if I need to append .app to the name or not. It
> runs without .app, but most commerical apps have .app appended.

Is your application a bundle, i.e. a directory with a name ending with
..app, with a bunch of stuff in specific sub-directories? It's not
necessary to do this, but it's usually the way things are done. Mainly
because it provides the same kind of advantages that used to be provided
by resource forks, but without actually requiring two-fork files.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.4: Best cleanup yet, gets files other tools miss.
See [url]http://www.atomicbird.com/[/url]

[Simon Slavin]

In article <a8696178.0307241254.2149c67a@posting.google.com >,
[email]bbunny@myrealbox.com[/email] (Bunny) wrote:

>Is there a good reason to do that?

Under Unix it's convenient for every file to have an
extension so the applications can tell what type of file
it is. It does make good sense for OS X to have an
extension of some kind to make it easy for the OS to
identify all the applications.

[Mike]

Simon Slavin wrote:

>Under Unix it's convenient for every file to have an
>extension so the applications can tell what type of file
>it is.

Yes!

> It does make good sense for OS X to have an
>extension of some kind to make it easy for the OS to
>identify all the applications.

But the whole point of UNIX is that the OS doesn't know or care
how the files are named -- much unlike other OS's from years gone by.

It's all left up to the applications. In this case, it's Finder that does
special things with *.app directories, not UNIX.

[Greg Weston]

In article <BB48C3269668114F8E@10.0.1.3>, Simon Slavin
<slavins@hearsay.demon.co.uk@localhost> wrote:

> In article <a8696178.0307241254.2149c67a@posting.google.com >,
> [email]bbunny@myrealbox.com[/email] (Bunny) wrote:
>

> >Is there a good reason to do that?

>
> Under Unix it's convenient for every file to have an
> extension so the applications can tell what type of file
> it is.

Actually, aside from plain text, most common file formats in use today
have signature strings at a known location near the beginning of the
file. Also, several systems in use include meta-data to serve that
purpose, such as Apple's 4-byte codes or even MIME strings.
Applications should emphatically not rely on something as transient as
the name to determine type for those cases when an alternative exists.

G

[Patryk 'Silver Dream !' £ogiewa]

Simon Slavin wrote:

> In article <a8696178.0307241254.2149c67a@posting.google.com >,
> [email]bbunny@myrealbox.com[/email] (Bunny) wrote:
>
>

>>Is there a good reason to do that?

>
>
> Under Unix it's convenient for every file to have an
> extension so the applications can tell what type of file
> it is. It does make good sense for OS X to have an
> extension of some kind to make it easy for the OS to
> identify all the applications.
>
>

No. Exactly under UNIX it was never necessary nor useful! UNIX can
perform "magic" and identify the file type by what consitutes the type
(content) for ages!

Try the magic for yourself:

shanghai:~$ file SD_IDE64_main.c
SD_IDE64_main.c: C program text

shanghai:~$ file README
README: Rich Text Format data, version 1, Apple Macintosh


This filename extension is a damn stupid msdos heritage, which now
prevails even in the most modern MacOS, because otherwise the
msdos/windows wouldn't be able to do anything with the received files... :-(

Apple had (slightly) better approach in their previous OSes but now they
seem to have adopted the completely ill, msdos-like style :-(

Read more on:

[url]http://arstechnica.com/reviews/01q3/metadata/metadata-1.html[/url]
[url]http://homepage.mac.com/jcs/.Public/metadata.html[/url]

Even if I don't completely agree with the suggested solution (Unix does
it better for a very long time), it can give more light to the situation.

[Raleigh Ledet]

> > In article <a8696178.0307241254.2149c67a@posting.google.com >,
> > [email]bbunny@myrealbox.com[/email] (Bunny) wrote:
> >
> >

> >>Is there a good reason to do that?

> >
> >

Ignoring the argument over which meta-data scheme is the best. On MacOS X,
not all applications have to have .app on the end of them.

The applications that do have to have the .app added to them are those
applications that are "Bundled" or "Packaged." What you have here is a
folder that contains a structured hierarchy for the actual executable file
and all of its resources. This folder strucutre is hidden from the user by
the OS treating the folder as the application itself and presenting to the
user one file.

Normally, when you double-click on a folder in the Finder, that folder
opens. The Finder needed a way to know to treat these application bundled
folders as the application itself. The way it does that is with the .app
extension.

Are there other ways this could have been done? Yes.
Are there other ways that would be better? Probably.
Are there other ways that would survive moving this application across the
net and/or disk formats other than HSF+? Maybe.

I guess the above question is tainted a little bit by asking if there was
a "good" reason. Regardless of why the way Apple did it is "good" or not,
if your application is bundled, be sure to put .app on the end of the
enclosing folder name or it wont work (among the other things you need to
do).

However, if your application is not bundled (some CFM apps) and has the
proper resource fork info, then it does not need the .app extension.

Then you have some unix executables. These executables don't have .app on
the end of them. However, you can not launch them from the Finder. These
apps generally don't have a GUI and should be run from a terminal, or some
controlling application anyway.

I don't know about any of the X-11 stuff Apple released or how those
executables are laid out. So my apologies if the X-11 stuff conflicts with
any above statements.

-raleigh


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
[url]http://www.newsfeeds.com[/url] - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

[Eric Pepke]

"Patryk 'Silver Dream !' ?ogiewa" <silverdr@inet.remove.it.pl> wrote in message news:<3f2d4f32$1@news.inet.com.pl>...

> Try the magic for yourself:
>
> shanghai:~$ file SD_IDE64_main.c
> SD_IDE64_main.c: C program text
>
> shanghai:~$ file README
> README: Rich Text Format data, version 1, Apple Macintosh

Except it doesn't work so hot.

file sym.pl
sym.pl: perl commands text

OK, yeah, it's a perl file. However

file t.pl
t.pl: ASCII text

Also a perl file, but it thinks it's just ASCII text

file main.m
main.m: C program text

OK, I guess objective C is close enough to C with such a short file, But

file MyDocument.m
MyDocument.m: C++ program text

What the...?

file T55.xml
T55.xml: ASCII text

Can't even look for <?xml as a magic string?

[Patryk 'Silver Dream !' £ogiewa]

Eric Pepke wrote:

>>Try the magic for yourself:
>>
>>shanghai:~$ file SD_IDE64_main.c
>>SD_IDE64_main.c: C program text
>>
>>shanghai:~$ file README
>>README: Rich Text Format data, version 1, Apple Macintosh

>
>
> Except it doesn't work so hot.
>

[...]

> file T55.xml
> T55.xml: ASCII text
>
> Can't even look for <?xml as a magic string?

The mechanism is there. The database quality might differ (your mileage
may vary :-). You may feel free to update your global magic database or
create local. If you do it good enough you might probably submit your
patches to improve the quality of this service in the future realeases.
The difference, however is that this way you MIGHT get poor results if
you don't have a good database. It is then easy to improve its content
with every mistake you notice. Depending on filename to determine
filetype WILL give poor results if the filename (for any reason) doesn't
reflect the _expected_ (vs. real) file type.

Anyway, this is probably slightly OT now.

[Mike Kluev]

In Article [email]blackgold-0408031501230001@rledet.wacom.com[/email], Raleigh Ledet wrote:

> Ignoring the argument over which meta-data scheme is the best. On MacOS X,
> not all applications have to have .app on the end of them.
>
> The applications that do have to have the .app added to them are those
> applications that are "Bundled" or "Packaged." What you have here is a
> folder that contains a structured hierarchy for the actual executable file
> and all of its resources. This folder strucutre is hidden from the user by
> the OS treating the folder as the application itself and presenting to the
> user one file.
>
> Normally, when you double-click on a folder in the Finder, that folder
> opens. The Finder needed a way to know to treat these application bundled
> folders as the application itself. The way it does that is with the .app
> extension.

It is not required to have ".app" extension even for bundled apps!
Finder launches them anyway. Try it. I believe this is because both
".app" extension and "bundle" bits are checked. Maybe Finder goes
even further and look for "Contents/MacOS..." folders inside.

--
Mike Kluev

PS. Remove "-DELETE-." part of my e-mail address to reply.