Mikä juju app-tiedostoissa?

[Tron]

Siirsin yhden kansion muistitikulle. Tiedon siirto näytti jämähtävän paikoilleen. Jäljellä oleva aika sen kuin vain kasvoi ja kasvoi ja lopulta pysähtyi n 14 minuuttiin. Välillä se oli kyllä paljon isompikin, mutta tuo 14 minuuttia oli se lukema johon aika pysähtyi eikä muuttunut tästä enää yli puoleen tuntiin.

Syylliseksi paljastui kansiossa ollut QuickTime Player.app jonka koko on 36,9 Mt, siis ei mikään mahdottoman iso. Jos sen zippaa, niin koko on 15,2 Mt.

Zippauksen jälkeen tiedot saa kirjoitettua muistitikulle salaman nopeasti.

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on? Esim. QuikTime.app:ssa näyttää olevan 4801 tiedostoa 2915:ssä alikansiossa!!!! Onko tässä mitään järkeä? Sehän tukkii muistitikun tiedostojärjestelmän! Samoin näköjään käy CD-levyille, joista tulee äärimmäisen hitaita, jos niissä on paljon *.app tiedostoja ja sitä kautta epäsuorasti tuhansia tai kymmeniä tuhansia muita tiedostoja.

[Maza]

Nämä "app-tiedostot" ovat siis ohjelmia, application. Minä en tiedä juuri mitään ohjelmoinnista, mutta uskoisin ohjelman vaativan jokusen alikansionkin. Käyttöjärjestelmä kutsuu näitä appeja itse asiassa pakkauksiksi, onhan se itsessään ajettava ohjelma.

[matteus/2]

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on

Siinä on se järki, että toisin kuin esim. Windowsissa, OS X:ssä ohjelmat ovat siististi yhden ikonin (application bundle) takana. Winukassahan ohjelmat ovat kansioissa, jotka ovat täynnä pikkusälää.

Ongelmaasi en kyllä osaa ottaa kantaa kun en QuickTimeä ole koskaan yrittänyt muistitikulle tai CD:lle siirtää, mutta monia muita ohjelmia kylläkin ja ne ovat toimineet ongelmitta ja näkyneet ihan vain yhtenä .app-bundlena.

[AppleFarmer]

Mitä ihmeellistä tässä nyt taas on?

[Jamac]

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on?

Se idea että ohjelman kaikki "oheistiedostot" on aina yhdessä ja samassa paikassa, ja käyttäjän täytyy erityisesti osata rikkoa ohjelma ennen kuin siinä onnistuu. Tosin se on helppoa, valitsee ohjelman ja hiiren napilla "Show Package Contents". Sieltä sitten löytyy ohjelman kieliversiotiedostot ja muut sellaiset. Juuri tämä ohjelmapaketti mahdollistaa sen että ohjelmaa ei tarvitse erityisesti asentaa, vaan että ohjelman voi siirtää ja se toimii silti.

[Jamac]

Mitä ihmeellistä tässä nyt taas on?

Juu nou se ikkunasysteemi..

[BlueTide]

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on? Esim. QuikTime.app:ssa näyttää olevan 4801 tiedostoa 2915:ssä alikansiossa!!!! Onko tässä mitään järkeä?

Ei tuossa ensinnäkään ole mitään sen ihmeellisempää, ja loppupeleissä se ei toimi niin hirveästi eri tavalla kuin vaikka Windows. Molemmissa ohjelmat asentuvat kansioihin, ja kuten Jamac jo sanoi, asentavat tarvitsemiaan tilpehöörejä tuonne pääkansion alle (ja joskus muuallekin). OS X nyt näyttää nämä kansiot käyttäjälle pakettina eikä hakemistona.

No miksei ne sitten voi olla paketti? Noh, se nyt vaan on suht näppärää, ettei meidän tarvitse kikkailla minkään wrappereiden kanssa turhaan ja kuluttaa aikaa ja vaivaa tuon paketoinnin hanskaamiseen.

Haittapuolena mm se, että noita bundleja ei hirveästi suoraan downloadailla interwebistä.

[Tron]

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on

Siinä on se järki, että toisin kuin esim. Windowsissa, OS X:ssä ohjelmat ovat siististi yhden ikonin (application bundle) takana. Winukassahan ohjelmat ovat kansioissa, jotka ovat täynnä pikkusälää.

Lamppu syttyi päässä apinan!
Asia on aivan selvä nyt. Olin vain ällikällä päähän lyöty, kun oletin että app.tiedosto on yksi ainoa tiedosto, johon kaikki ohjelman tarvitsema sälä on käännetty sisään. Siis kuten esim. dos-ohjelmat, jotka ovat vain yksi exe-tiedosto. Jos koodaat vaikka C-kielellä ja käännät siitä suoritettavan Windows-ohjelman, niin saat vain yhden ainoan exe-tiedoston, joskin tiedosto saattaa käyttää hyväkseen valmiiksi järjestelmässä olevia dll-tiedostoja. (Tässä se kompastuskivi onkin. Yksi exe käyttää yhtä dll-tiedostoa ja toinen toista versiota täsmälleen samasta dll-tiedostosta.)

Eihän se app edes näyttänyt kansiolta, joten oletin sen olevan exeä vastaava suoritettava tiedosto. Siis app onkin yllättäen kansio jossa on suoritettava tiedosto, ja Windowsin dll-tiedotoja vastaavat lisäosat. Karvat meinasi vaan lähteä päänahasta hämmästyksestä, kun huomasin että noita lisäosia on USEITA TUHANSIA! Siitä heräsi kysymys että mitä järkeä on pilkkoa ohjelma niin moneen osaan!

Rupesin tsekkaamaan näitä app-kansioita. Herää kysymys että onkohan koodaajat unohtaneet näihin kansioihin tarpeetonta tavaraa? Mitä esim Quick Time Palyerin kansiossa tekee lähdekodin headerit??? (Siis *.h tiedostot joissa on mm funktioiden prototyypit kääntäjää varten.)

(Olen vääntänyt joskus koodia sulautettuihin järjestelmiin. Yhdessä projektissa jota jouduin parsimaan, niin siinä noin 80 prosenttia lähdekooditiedostoista oli sellaisia, joita ei koskaan käytetty. Roikkuivat vain tyhjän panttina mukana hämäämässä koodaria, joka etsi grepillä koodista erilaisia asioita.)

Ongelmaasi en kyllä osaa ottaa kantaa kun en QuickTimeä ole koskaan yrittänyt muistitikulle tai CD:lle siirtää, mutta monia muita ohjelmia kylläkin ja ne ovat toimineet ongelmitta ja näkyneet ihan vain yhtenä .app-bundlena.

Tuo Quick Time oli vain esimerkki ohjelmasta yleensä. Eikä se ole ongelma jos on tietoinen että siinä voi olla järkyttävän suuri määrä pieniä tiedostoja. Ongelman voi ohittaa zippaamalla koko applikaation. Sen jälkeen se on vain yksi tiedosto. Noiden tiedostojen ja hakemistojen allokaatiotaulukot voivat viedä ehkäpä jopa enemmän tilaa kuin se data joka kyseisissä tiedostoissa on. Aivan älytön tilanne. Ja kun tiedostoja luetaan esim CD:tä, niin lukupää hakkaa todella tiuhaan tahtiin hakemiston ja tiedostojen välillä, jos hakemistot ovat isompia kuin mitä koneen puskureihin mahtuu. -> Luenta muuttuu todella hitaaksi.

[Timoz]

Yllätyksekseni *.app tiedostot ovatkin kansiota! Mikä idea tässä on? Esim. QuikTime.app:ssa näyttää olevan 4801 tiedostoa 2915:ssä alikansiossa!!!! Onko tässä mitään järkeä? Sehän tukkii muistitikun tiedostojärjestelmän! Samoin näköjään käy CD-levyille, joista tulee äärimmäisen hitaita, jos niissä on paljon *.app tiedostoja ja sitä kautta epäsuorasti tuhansia tai kymmeniä tuhansia muita tiedostoja.

Pääset hakemisto.app/Ohjelma.app -ongelmasta eroon, kun alustat tikkusi HFS tai HFS+ formaattiin. Nyt tikku on luultavasti FAT16/32 FS. Tai onko se edes ongelma?

[Tron]

Pääset hakemisto.app/Ohjelma.app -ongelmasta eroon, kun alustat tikkusi HFS tai HFS+ formaattiin. Nyt tikku on luultavasti FAT16/32 FS. Tai onko se edes ongelma?

Ei se ole ongelma, kuten jo sanoin. Zippaamalla siitä pääsee eroon. Eikä tiedonsiirto edes ollut kysymykseni pääasia, vaan aivan muu.

[teroyk]

Rupesin tsekkaamaan näitä app-kansioita. Herää kysymys että onkohan koodaajat unohtaneet näihin kansioihin tarpeetonta tavaraa? Mitä esim Quick Time Palyerin kansiossa tekee lähdekodin headerit??? (Siis *.h tiedostot joissa on mm funktioiden prototyypit kääntäjää varten.)

Tätä minäkin olen ihmetellyt. Ja muutenkin ihmetellyt sitä tiedostojen määrää.
Mutta ehkä Atari aikoihini totuin liiankin hyvin, että ohjelman voi todella tehdä pelkkään yhteen tiedostoon. Tai voi tehdä jopa koko ikkunakäyttöjärjestelmän, kuten TOS 4.92:n, joka oli yksi 512kt tiedosto. Sehän on vain ohjelman viitseliäisyydestä kiinni.

[Thoth]

Rupesin tsekkaamaan näitä app-kansioita. Herää kysymys että onkohan koodaajat unohtaneet näihin kansioihin tarpeetonta tavaraa? Mitä esim Quick Time Palyerin kansiossa tekee lähdekodin headerit??? (Siis *.h tiedostot joissa on mm funktioiden prototyypit kääntäjää varten.)

Tätä minäkin olen ihmetellyt. Ja muutenkin ihmetellyt sitä tiedostojen määrää.
Mutta ehkä Atari aikoihini totuin liiankin hyvin, että ohjelman voi todella tehdä pelkkään yhteen tiedostoon. Tai voi tehdä jopa koko ikkunakäyttöjärjestelmän, kuten TOS 4.92:n, joka oli yksi 512kt tiedosto. Sehän on vain ohjelman viitseliäisyydestä kiinni.

Nuo tiedostothan usein esimerkiksi kielitiedostoja tai kuvia, joita ohjelma tarvitsee. Onko tuosta tavasta paketoida ohjelman tarvitsemia tiedostoja jotain haittaa? Ainakin ohjelmien "puukotus" tuntuu tuolla tavalla helpommalta, eli jos jossain ohjelmassa tulee vaikka turhaa roinaa, niin sen siivoaminen voi olla helpompaa kuin jos se olisi jossain binääripaketissa.

Jos menet vaikka Mail.app:iin katsomaan, niin siellä on (kai?) hakemistossa Contents/MacOS yksi viiden megan käännetty ja ajettava binääritiedosto nimeltään "Mail". Muista hakemistoista sitten löytyy Mailin käyttämiä kuvia, plugineita, yms... Pitäisi Applen esim. kääntää aina uusi binääripaketti, kun jotain kuvaa muutetaan?

En ole Quicktimen sisältöön tutustunut, mutta ehkä niitä käytetään esimerkiksi silloin, kun kehitetään Quicktime-plugineja.

[teroyk]

Nuo tiedostothan usein esimerkiksi kielitiedostoja tai kuvia, joita ohjelma tarvitsee. Onko tuosta tavasta paketoida ohjelman tarvitsemia tiedostoja jotain haittaa? Ainakin ohjelmien "puukotus" tuntuu tuolla tavalla helpommalta, eli jos jossain ohjelmassa tulee vaikka turhaa roinaa, niin sen siivoaminen voi olla helpompaa kuin jos se olisi jossain binääripaketissa.

Ei tuosta paketointi tavasta ole muuta haittaa, että joskus niitä tiedostoja haetaan levyltä vähän väliä. Mutta toki siinä on hyvätkin puolensa. Jotkut PPC-käyttäjät poistavat Intel-roinat ja ylimääräiset kielitiedostot. Ja onhan se joskus kiva tehdä omia modauksia grafiikoista ja äänistä.

[Thoth]

Nuo tiedostothan usein esimerkiksi kielitiedostoja tai kuvia, joita ohjelma tarvitsee. Onko tuosta tavasta paketoida ohjelman tarvitsemia tiedostoja jotain haittaa? Ainakin ohjelmien "puukotus" tuntuu tuolla tavalla helpommalta, eli jos jossain ohjelmassa tulee vaikka turhaa roinaa, niin sen siivoaminen voi olla helpompaa kuin jos se olisi jossain binääripaketissa.

Ei tuosta paketointi tavasta ole muuta haittaa, että joskus niitä tiedostoja haetaan levyltä vähän väliä. Mutta toki siinä on hyvätkin puolensa. Jotkut PPC-käyttäjät poistavat Intel-roinat ja ylimääräiset kielitiedostot. Ja onhan se joskus kiva tehdä omia modauksia grafiikoista ja äänistä.

Jos ne kuvat, kielitiedostot ja vastaavat olisivat yhdessä paketissa, pitäisi ne silti ladata levyltä (tosin paketin sisältä, mikä olisi todennäköisesti hitaampaa), tai sitten ne pitäisi ladata ajonaikaisesti RAM/levyn swap-muistiin, jolloin venäläiset ja kiinalaiset kielitiedot voisivat viedä arvokasta RAM-muistia, tms. Se on ohjelmoijan käsissä, että ladataanko esimerkiksi ne kuvat kerran vai monta kertaa käytön aikana, eli mielestäni tuollaiset ongelmat eivät ole ainakaan kovin suoraa seurausta tuosta paketointitavasta.

[Elsewhere]

Eipä sitä ole mitään järkeä ohjelmoijan yhdistää noita tsiljoonia tiedostoja yhteen.. onnistuuhan se toki, mutta sen jälkeen yksittäisen tiedoston muuttaminen on kovin hankalaa, koska paketti täytyy tehdä uudelleen, eikä pakkaamisesta ole edes mitään oikeaa käytännön hyötyä paitsi ehkä ihan marginaalisissa tapauksissa. Ohjelmakoodissakin datan käsittelystä tulee hankalampaa jos täytyy alkaa availla kaikenmaailman pakattuja tiedostoja.

Teoriassa levynkäsittelyn hitaudesta johtuen on nopeampaa ladata levyltä muistiin yksi iso tiedosto kuin monta pientä, mutta hyöty tulee käytännössä ilmi vasta jos tiedostoja on oikeasti tosi paljon, ja harvassa ohjelmassa on.

Lisää ohjelmien käyttämiä komponentteja löytyy muuten hakemistosta /System/Library, sinne vaan tutkailemaan millaisia kirjastoja yms. omenakoneen mukana tulee :)