ActiveX on yksi hyödyllisimpiä ohjelmointiin liittyviä teknologioita windowsissa.
Tähän asti ole virheellisesti kuvitellut, ettei linuxissa ole mitään vastaavaa.
Mutta hetkinen...
Mikä on esim. Adoben Flash -playerin linux -versio?
Teknisesti se on .so -dynaaminen linkkikirjasto, mutta niinhän windowsissakin ActiveX:t ovat teknisesti dynaamisia linkkikirjastoja, windowsissa ne vain nimetään .ocx tavanomaisemman .dll:n sijasta.
Kuitenkin Adoben Flash -player toimii yhtähyvin niin Operassa, Firewfoxissa kuin IceWeaselissakin, Konquerorissa en ole kokeillut, mutta ehkä toimii siinäkin (?)
No, dynaamisiet linkkikirjastot sinänsä yleensä suunnitellaankin niin, että niitä voi käyttää eri ohjelmissa.
Mutta: siinä, missä monet dynaamiset linkkikirjastot yleensä tekecät laskentaa, niin Adoben Flash -player pystyy jollain tavalla näyttämään (myös liikkuvaa) kuvaa suoraan selaimen ikkunassa !
Lisäksi Adoben Flash -player pystyy käyttämään linuxin äänilaitetta, ja ilmeisesti vielä riippumatta, onko käytössä:
a) suoraan OSS
b) suoraan ALSA
c) arts
d) Jack
e) kilpailevan työpöytäympäristön vastine arts:lle.
Jotta tämäntyyppinen toiminnallisuus on yleensä mahdollista, jossain täytyy olla tekninen kuvaus siitä, miten
a) sovellusohjelma (em. esimerkissä selain)
b) .so -dynaaminen linkkikirjasto (esimerkissä Adoben Flash -player)
pitää kirjoittaa, jotta ne osaavat pelata yhteen edelläkuvatulla tavalla.
Tätä teknistä kuvausta voisi sii pitää ActiveX:n vastineena linux -ympäristössä.
MISTÄ kyseisen kuvauksen löytää?
Eli jos oikein ymmärrän, niin kun kyseisen kuvauksen löytäisi ja lukisi, niin se mahdollistaisi:
a) omien .so kirjastojen tekemisen sellaisiksi, että ne voi asentaa selaimeen samoin kuin Adoben Flash -playerinkin ja tämän jälkeen omalla .so -kirjastolla on kaikki samat toimintamahdollisuudet selaimen kanssa kuin tuolla Adoben playerillakin on.
b) omien sellaisten ohjelmien tekemisen, jotka toteuttavat tuon dokumentin sovellusohjelmapuolen tuosta em. rajapinnasta, ja jotka osaavat ladata esim. Adoben playerin omatekoiseen ohjelmaan, vaikka tuo oma ohjelma ei mikään selain olisikaan.
MISTÄ ko. teknisen kuvauksen siis löytää, sillä sitä voidaan pitää "ActiveX:n linux -version" teknisenä kuvauksena.
Tähän asti ole virheellisesti kuvitellut, ettei linuxissa ole mitään vastaavaa.
Mutta hetkinen...
Mikä on esim. Adoben Flash -playerin linux -versio?
Teknisesti se on .so -dynaaminen linkkikirjasto, mutta niinhän windowsissakin ActiveX:t ovat teknisesti dynaamisia linkkikirjastoja, windowsissa ne vain nimetään .ocx tavanomaisemman .dll:n sijasta.
Kuitenkin Adoben Flash -player toimii yhtähyvin niin Operassa, Firewfoxissa kuin IceWeaselissakin, Konquerorissa en ole kokeillut, mutta ehkä toimii siinäkin (?)
No, dynaamisiet linkkikirjastot sinänsä yleensä suunnitellaankin niin, että niitä voi käyttää eri ohjelmissa.
Mutta: siinä, missä monet dynaamiset linkkikirjastot yleensä tekecät laskentaa, niin Adoben Flash -player pystyy jollain tavalla näyttämään (myös liikkuvaa) kuvaa suoraan selaimen ikkunassa !
Lisäksi Adoben Flash -player pystyy käyttämään linuxin äänilaitetta, ja ilmeisesti vielä riippumatta, onko käytössä:
a) suoraan OSS
b) suoraan ALSA
c) arts
d) Jack
e) kilpailevan työpöytäympäristön vastine arts:lle.
Jotta tämäntyyppinen toiminnallisuus on yleensä mahdollista, jossain täytyy olla tekninen kuvaus siitä, miten
a) sovellusohjelma (em. esimerkissä selain)
b) .so -dynaaminen linkkikirjasto (esimerkissä Adoben Flash -player)
pitää kirjoittaa, jotta ne osaavat pelata yhteen edelläkuvatulla tavalla.
Tätä teknistä kuvausta voisi sii pitää ActiveX:n vastineena linux -ympäristössä.
MISTÄ kyseisen kuvauksen löytää?
Eli jos oikein ymmärrän, niin kun kyseisen kuvauksen löytäisi ja lukisi, niin se mahdollistaisi:
a) omien .so kirjastojen tekemisen sellaisiksi, että ne voi asentaa selaimeen samoin kuin Adoben Flash -playerinkin ja tämän jälkeen omalla .so -kirjastolla on kaikki samat toimintamahdollisuudet selaimen kanssa kuin tuolla Adoben playerillakin on.
b) omien sellaisten ohjelmien tekemisen, jotka toteuttavat tuon dokumentin sovellusohjelmapuolen tuosta em. rajapinnasta, ja jotka osaavat ladata esim. Adoben playerin omatekoiseen ohjelmaan, vaikka tuo oma ohjelma ei mikään selain olisikaan.
MISTÄ ko. teknisen kuvauksen siis löytää, sillä sitä voidaan pitää "ActiveX:n linux -version" teknisenä kuvauksena.
Vastaukset 6
Vanhimmat
ActiveX on pahimpia vitsauksia mitä kukaan on koskaan saanut aikaan. Älä hemmetissä vertaa sitä yhtään mihinkään!
Ei tuosta jutusta muutenkaan oikein saanut tolkkua, mutta yritän nyt kuitenkin. Laitan tuohon kassan linkkejä joista on hyvä aloittaa. Siellä on varmasti kaikenlaista aiheeseen liittyvää.
http://www.gnashdev.org/?q=node/26
http://plugindoc.mozdev.org/linux.html
https://developer.mozilla.org/En/Developer_Guide
https://developer.mozilla.org/En
ActiveX sinänsä ei ole turvallisuusriski.
Sensijaan turvallisuusriskinä voi pitää MS Internet Explorerin joidenkin versioiden tapaa ladata ja suorittaa ActiveX -komponentteja miltä tahansa Web -sivustolta, johon käyttäjä sattuu surfaamaan.
Tosin: itsellänikään ei ole täyttä tietoutta siitä, mikä versio MS-IE:stä suorittaa ActiveX:iä
a) jos ActiveX -komponenttia ei ole allekirtjoitettu
b) jos ActiveX -komponentti on allekirtjoitettu
Valitettavasti yllämainitun, kokonaan MS-IE:n turvallisuussuunnittelun puutteesta johtuvan ongelman väärinymmärtäminen on joidenkin linux -käyttäjien silmissä ActiveX -komponenttiteknologian vika, mikä ei siis pidä paikkaansa.
Yhtä järjetöntä, kuin haukkua ActiveX -teknologiaa sinänsä riskiksi, olisi esim. kutusa linuxin .so -kirjastoja riskiksi.
Kyse on periaatteessa samasta asiasta!
ActiveX:t ovat periaatteessa normaaleja Windows DLL:iä (vastaavat siis linuxin .so -kirjastoja), mutta erona on se, että kun missä tahansa .so tai .DLL -kirjastossa voi olla minkä tahansa nimisiä funktioita, joiden argumentit voivat olla mitä tahansa, niin siksi perinteisiä kirjastoja käytettäessä
JOKO:
a) kirjasto on suunniteltava niiden vaatimusten mukaan, jotka sovelluksen kirjoittaja on määritellyt
TAI
b) sovellus on suunniteltava niiden vaatimusten mukaan, jotka kirjaston kirjoittaja on määritellyt
ActiveX on sinänsä muuten ihan normaali windows DLL, mutta siinä on oltava määrättyjä vakionimisiä funktioita, joiden parametrit on tarkasti määritelty.
Siksi jos tehdään ActiveX -komponentti, niin komponentin tekijän ei tarvitse tietää, missä sovelluksessa sitä tullaan käyttämään.
Vastaavasti, jos tehdään sovellus, siihen voidaan rakentaa yleinen ActiveX -tuki, jolloin esim windowsissa .ini -tiedostossa sovellukselle voidaan kertoa, mitä ActiveX -komponentteja sovelluksen halutaan lataavan.
Esimerkkejä ActiveX -teknologian hyödyllisestä, ja riskittömästä (*) käytöstä:
Esim. Delphi on sovelluskehitin, joka osaa hyödyntää ActiveX -komponentteja , mutta toisaalta Delphillä koodaajan EI ole pakko käyttää yhtään ActiveX -komponenttia jos ei halua.
Tämän ansiosta esim.
1. Delphiin voi importoida windows -koneelle asennetun MS Media playerin ActiveX -komponenttina. Tämän ansiosta Delphi -ohjelma osaa toistaa Audio- ja videotiedostoja, mutta Delphi -ohjelmoijan ei siti tarvitse tuntea kaikkia audion ja videon käsittelyyn liittyviä yksityiskohtia. Delphin käyttäjä voi esim. laittaa formille panelin (joka on Delphi -komponentti; ei siis ole ActiveX- komponentti) ja laittaa tälle panelille vaikkapa TMsMediaPlayer -nimellä importoidun MS Media Playerin ActiveX -version ja voi halutessaan määritellä, että jos panelin koko muuttuu, niin tuo TMsMediaPlayer muuttaa kokoaan vastaavasti.
2. Delphiin voi importoida windows -koneelle asennetun Adobe PDF Readerin ActiveX -komponenttina. Tämän ansiosta Delphi -ohjelma osaa näyttää PDF -tiedostoja, mutta Delphi -koodaajan ei silti tarvitse tietää esim. PDF -tiedostojen sisäistä rakennetta.
3. Delphiin voi importoida windows -koneelle asennetun MS Internet Explorerin ActiveX -komponenttina. Tämän ansiosta Delphi -ohjelma osaa näyttää HTM(L) -tiedostoja ja ladata webistä sivuja, mutta Delphi -koodaajan ei silti tarvitse tietää HTML -tiedostojen tai niihin ladattujen kuvatiedostojen tms. sisäistä rakennetta. Toisaalta, Delphi -ohjelma saa tällöin hyödykseen web -sivun sisällön DOM (Document Object Model) -mallina ja voi viitata näihin elementteihin. Esim Delphi -ohjelma voisi vaikka automaattisesti täyttää web -sivulla olevan lomakkeen ja lähettää sen. Saman tekeminen suoraan TCP/IP:llä ilman web -komponenttia on toki mahdollista, mutta erittäin typerää jos se palvelin, jolla tuo täytettävä web -lomake sijaitsee, ei ole omassa hallinnassa ! Syy: Jos palvelimen omistaja/haltija tekee muutoksia web -lomakkeeseen tai sen URLiin, niin suoraan TCP/IP:llä tehdyssä automatiikassa muutoksiin reagoiminen on huomattavan suuri työmäärä mutta Delphi MS-IE -yhdistelmän hyödyntäjälle muutoksiin vastaamiseen vaadittava työmäärä on paljon pienempi.
4. Delphillä voi paitsi käyttää muiden (esim: Microsoft, Adobe tai kuka hyvänsä, joka osaa ActiveX -komponentteja tehdä) tekemiä komponentteja, myös itse luoda ActiveX -komponenttteja ja laittaa niitä esim Web -sivulle. Jos näin tehdään yrityskäytössä, niin komponentit voi myös digitalisesti allekirjoittaa.
MS:n filosofiana onkin ollut se, että julkisesta internetistä ei ole syytä suorittaa sellaisia ActiveX -komponentteja, joiden tekijään ei luoteta.
em. Digitaalisen allekirjoituksen ansiosta on siis mahdollista tarkistaa, että ActiveX -komponentin Z tekijä on Oy Yritys Ab.
Jos tällainen komponentti tekee jotakin vahingollista, tällöin voi kohdistaa vahingonkorvausvaatimukset Oy Yritys Ab:hen.
Ainoa tilanne missä ActiveX:stä voisi olla jotakin vahinkoa, onki se, että joku tekisi tahallisesti vahingollisen ActiveX -komponentin ja laittaisi sen web -sivulle. Jos komponentti on allekirjoittamaton eikä sen tekijää muutenkaan voida pitää luotettavana, niin tällöin tietenkin järkevä selain estää ko. komponentin suorittamisen ja näin ehkäisee tietoturvariskin.
Mutta jos jätetään pois laskuista tahallinen vahingollisen ActiveX:n teko ja levitys, niin mitä haittaa muka on siinä, että esim. omassa ohjelmassaan voi aliohjelman tapaan käyttää vaikkapa MS:n tai Adoben kehittämää toiminnallisuutta?
Jos oikein muistan, niin on olemassa esim. ActiveX -komponentti, jonka avulla yritys voi palvelusopimuksen tehtyään lähettää ja vastaanottaa 17xxx ja 16xxx -numeroilla toimivia tekstiviestejä.
Kun siis laitat textarin vaikkapa maikkarin deittiin, niin on hyvin mahdollista, että mtv:n studiolla pyörii joku mtv3:n tai sen palkkaaman koodarin tekemä ohjelma, joka ei itse ymmärrä noista maksullisiista tekstiviesteistä ja niiden tietoliikenteestä mitään, vaan käyttää hyväkseen esim. TeliaSoneran tekemää ja mtv3:lle toimittamaa ActiveX -komponenttia.
ActiveX -komponentteja voi Delphin lisäksi tehdä myös esim. C/C -kielillä ja varmaanC#:llakin.
Niitä voi käyttää edellämainittujen lisäksi myös Visual Basicilla. Käsittääkseni VB on kuitenkin siinä suhteessa rajoittunut väline, että toisin kuin esim. Delphillä, sillä EI voi itse tehdä ActiveX -komponentteja, vaan ainoastaan käyttää muiden tekemiä komponentteja.
Linux -puolella juuri standardoinnin puute aiheuttaa sen, että esim. FreePascal Lazarus -yhdistelmässä ei ole e tuke vastaavalle teknologialle kuin Delphissä on ActiveX -tuki sekä komponenttien tekemiseen että muiden tekemien komponenttien käyttämiseen.
ActiveX -komponentit ovat myös ohjelmointikieliriippumattomia ja koska ne ovat binäärikoodia, niin kielen A koodaajan ei tarvitse ymmärtää kieltä B voidakseen käyttää B:llä tehtyjä komponenttejä.
Mutta ketjun aloitusviestissä mainitsemani esimerkki Adoben Flash -playerista ja selaimista osoittaa, että linuxissa on kuin onkin jotain vastaavaa, valitettavasti vain huonosti dokumentoitua.
Vai onko niin, että Mozillaan lisäpalikoita voi kirjoittaa vain jollain määrätyllä ohjelmointikielellä?
Olen joskus yrittänyt lukea Firefoxin ko. dokumentteja. Valitettavasti ainakin silloin lukemieni dokumenttien perusteella näytti siltä, etten voi laittaa mitä tahansa .so -tiedostoa latautumaan Firefoxin mukana, vaan ko. dokumentin mukaan olisi ollut pakko käyttää jotain Firefoxin omaa määrittelykieltä.
Käsittääkseni Adobe on kuitenkin koodannut Flash Playerinsa C:llä eivätä käytä Firefoxin omaa määrittelykieltä.
Ja heillä olisi ollut vapaus tehdä se vaikkapa FreePascalilla jos olisivat halunneet niin tehdä.
Voisiko XEmbed olla ActiveX:n linuxvastine ?
http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#overview
Tätä et maininnut, mutta kyseltyäni muualla, miten linuxissa esim, Adobe flash palyer voi näyttää sisältöä selaimen ikkunassa vaikka itse on .so -kirjasto, niin suon sain vastaukseksi.
En ole asiaan ehtinyt paljon tutustua mutta jos tuo on ratkaisu niin lopultakin löytyi vastine linuxiin windowsin ActiveX -teknologialle !
Vaikka kuinka yrität puolustaa sitä niin totuus on se että ActiveX on alkeellisin viritys mitä verkottunut tietotekniikka tuntee.
Koko peruslähtökohta on niin pielessä kuin vain voi olla. Ajetaan käyttiksen natiivikoodia selaimella. Jäljet pelottavat. Hrrr!
Voit olla satavarma siitä että sitä ei ikinä tule Linuxiin. Eikä mihinkään oikeaan käyttöjärjestelmään.
En ota kantaa MS:n virityksiin ja tunnustan etten jaksanut edes lukea selostustasi loppuun. Se meni liikaa Microsoft sitä ja Microsoft tätä jutuksi.
1. Minä en halua tietää Windows hömpästä yhtään mitään. Enkä enää koskaan halua tullakaan tietämään.
2. Kukaan järkevä ei koskaan ala perustelemaan activex:ää mitenkään hyväksi tai miksikään muuksikaan.
3. ActiveX-mörköä ei voi verrata mihinkään. Se on sen verran 'verraton'.
4. ActiveX on rikos tietotekniikkaa vastaan.
5. keskustelu ActiveX:stä on osaltani päättynyt.
ActiveX, yksi Microsoftin suurimmista virheistä koskaan. Kiitämme herraa, ettei moista tietiturvan vaarantajaa linuxissa ole.