Automaattinen lomakkeen täyttö Lazarus 1.6

Yleensä käyttöjärjestelmässä valmiina.

"Asian taustaa:

1. TWebBrowser -komponentti ei ole eikä ole koskaan ollut mikään yleiskäyttöinen web -selainkomponentti. Se on aina perustunut Microsoftin Internet Explorerin ActiveX -komponenttiin."

Niin kyllähän tuosta aloituksesta näki sekunnissa että on valittu väärä työkalu. En nyt viitsinyt sanoa mitään kun pyydettiin että ei joten annoin sitten kysyjän hakata päätä seinään.

"32 -bittinen Delphi: TWebBrowser -komponentti on käytettävissä
ja se perustuu Microsoftin Internet Explorerin ActiveX -komponenttiin, joka on 32 -bittinen."

Tuo on niinikään häviö myös, koska Microsoft lopetti jo vuoden vaihteessa vanhat IE:t lähes täysin, että on enää suunnilleen IE11 mutta sekin on poistumassa täysin jollain aikavälillä. Veikkaan, että viimeistään 2021, joskin voi tarvita silloinkin jotain kalliimpaa versiota Windowsista. Periaatteessa saattaa poistua jo kuukauden sisällä kun tulee päivitystä en oikein usko, että näin aikaisin.

"Syy: Käsittääkseni ActiveX -komponenttiteknologiaa Microsoft ei ole portannut 64 -bittiseen windowsiin. Eli ei ole olemassa 64 -bittisiä versioita ActiveX -komponenteista tai ActiveX -teknologiasta."

Höpöhöpö. ActiveX perustuu olennaisesti COM:n ja toimii kyllä 64-bittisesti.

Se tässä nyt pitää huomioida, että ei toimi ristiin sekaisin 32-bit ja 64-bit natiivikoodi. Kaikki 32-bit tai kaikki 64-bit. ActiveX komponentit ovat kyllä jo lopetettu ja niitä ei siksi pitäisi käyttää. Korvaava komponenttiarkkitehtuuri tuli .NET:ssä ja siinä ei sitten ole enää merkitystä millään bittisyyksillä.

"Firefoxin koodin pohjalta on ainakin yritetty tehdä vähän vastaavaa kuin Delphin TWebBrowser -komponentti. Mutta ainakaan Delphi7:n kanssa en saanut sitä toimimaan."

Delphi 7 on obsoleetti. Sitä kun katsoo Delphin tukimallia niin joka julkaisua tuetaan jotain 18kk, eli käytännössä pitää olla uusin käytössä ja siinä on sitten 6kk pelivaraa päivitellä ja siirtää projekteja.

"Mutta valitettavasti: tällöin pitäisi tuosta omasta DLL:stä käsin päästä käsiksi ladattuun web -sivuun ja sen DOM -malliin (Document Object Model)."

Niin saahan sitä joo viriteltyä vaikka mitä mutta tässä nyt on kyllä selvästikin väärä työkalu käytössä.

"Jos saataisiin tiimiin mukaan joku GCC:tä ja sen kääntöympäristöä (eli loputon määrä erilaisia skriptejä, jotka kutsuvat GCC -komentorivikääntäjää) tunteva, niin tällaisen komponentin kasaaminen voisi tulla mahdolliseksi."

En nyt tiedä mistä loputtomista skripteistä puhut. Standardi buildiympäristö on Make. Siihen konfigurointiin riittää perustasolla yksi makefile ja aliprojekteja voi laittaa alitason makefileihin.

Mozillalla voi olla kyllä ihan buildiympäristö jossa voi olla hyvinkin raskaita juttuja eikä se nyt liity siihen kääntäjään enää mitenkään tai voi käyttää jotain muita buildiympäristö, esim. GNU Build System.

...

Helpompaa kyllä on ottaa oikea työkalu oikeaan hommaan. Uuden työkalun omaksuu kuitenkin niin nopeasti mutta nysväämiseen voi kuluttaa aikaa loputtomasti.

Entäpä jos ketjun aloittaja nimenomaan haluaa koodata ohjelmansa ObjectPascalilla. Siis EI c:llä, EI C :lla, eikä C#:lla.

M-Kar: et esittänyt mitään sellaista ratkaisua, jossa FreePascal Lazarus -ympäristön käyttäjä voisi lisätä vastaavan toiminnallisuuden ohjelmaansa kuin mitä TWebBrowser -komponentti tarjoaa Delphi käyttäjille.

MS:n .net ei ole edes mainitsemisen arvoinen.

Syy: ei ole helposti liitettävissä muulla työvälineellä tehtyyn projektiin.

ActiveX oli aikanaan hyvin suunniteltu, juuri siksi, ettei se pakota minkään määrätyn ohjelmointikielen tai -työvälineen käyttöön.

Eli ActiveX:n voit luoda esim: C:llä, C :lla, tai Delphillä.

ActiveX:ää voi käyttää esim: C:llä, C :lla, Delphillä ja esim. Visual Basicilla, riippumatta siitä, millä kielellä kyseinen ActiveX on tehty.

Sopii tosin kysyä: Miksi esim. MS Windows MediaPlayer ActiveX toimii aivan mainiosti Delphi:llä tehdystä ohjelmasta käsin; ei mitään ongelmia.

Sensijaan VLC:n ActiveX -versio Delphi -ohjelmsta käsin käytettynä aiheuttaa jatkuvia ja pahoja ongelmia.

Ilmeisesti VLC:n koodaajat, vaikka ovat osanneet tehdä aivan oikein itsenäisenä ohjelmana toimivan mediatoistinohjelman (VLC.EXE), niin saman ActiveX -versiossa ovat ilmeisesti mokanneet jotakin pahemman kerran.

Ja tuonkin korjaaminen taas edellyttäisi jotakuta, joka tuntee läpikotaisin gcc:n ja sen kanssa usein käytettävät käännöksenhallintatyökalut.

Minulle ainakin ObjectPascal -kielen käyttömahdollisuus on suuri arvo sinänsä.

Toki on mahdollista koodata sama asia vaikkapa C -kielellä.

Mutta jos C -kielellä tehdyltä toteutukselta halutaan sekä sama toiminnallisuus, sama luotettavuus ja sama turvallisuus kuin Delphillä koodatulta ohjelmalta, niin työmäärä on ainakin 100 -kertainen.

Tästä hyvänä todisteena se, että C:llä koodatuista ohjelmista löytyy jatkuvasti tietoturvareikiä.
Se, että reikä korjataan nopeasti, ei merkitse tässä yhtään mitään!

Jos olisi koodattu Delphillä, niin sitä tietoturvareikää ei olisi alunperinkään ollut, silloin ei tarvitse mitään korjata, kun mikään ei ole rikki.

Delphikoodaaja kirjoitti:

Entäpä jos ketjun aloittaja nimenomaan haluaa koodata ohjelmansa ObjectPascalilla. Siis EI c:llä, EI C :lla, eikä C#:lla.

M-Kar: et esittänyt mitään sellaista ratkaisua, jossa FreePascal Lazarus -ympäristön käyttäjä voisi lisätä vastaavan toiminnallisuuden ohjelmaansa kuin mitä TWebBrowser -komponentti tarjoaa Delphi käyttäjille.

MS:n .net ei ole edes mainitsemisen arvoinen.

Syy: ei ole helposti liitettävissä muulla työvälineellä tehtyyn projektiin.

ActiveX oli aikanaan hyvin suunniteltu, juuri siksi, ettei se pakota minkään määrätyn ohjelmointikielen tai -työvälineen käyttöön.

Eli ActiveX:n voit luoda esim: C:llä, C :lla, tai Delphillä.

ActiveX:ää voi käyttää esim: C:llä, C :lla, Delphillä ja esim. Visual Basicilla, riippumatta siitä, millä kielellä kyseinen ActiveX on tehty.

Sopii tosin kysyä: Miksi esim. MS Windows MediaPlayer ActiveX toimii aivan mainiosti Delphi:llä tehdystä ohjelmasta käsin; ei mitään ongelmia.

Sensijaan VLC:n ActiveX -versio Delphi -ohjelmsta käsin käytettynä aiheuttaa jatkuvia ja pahoja ongelmia.

Ilmeisesti VLC:n koodaajat, vaikka ovat osanneet tehdä aivan oikein itsenäisenä ohjelmana toimivan mediatoistinohjelman (VLC.EXE), niin saman ActiveX -versiossa ovat ilmeisesti mokanneet jotakin pahemman kerran.

Ja tuonkin korjaaminen taas edellyttäisi jotakuta, joka tuntee läpikotaisin gcc:n ja sen kanssa usein käytettävät käännöksenhallintatyökalut.

Minulle ainakin ObjectPascal -kielen käyttömahdollisuus on suuri arvo sinänsä.

Toki on mahdollista koodata sama asia vaikkapa C -kielellä.

Mutta jos C -kielellä tehdyltä toteutukselta halutaan sekä sama toiminnallisuus, sama luotettavuus ja sama turvallisuus kuin Delphillä koodatulta ohjelmalta, niin työmäärä on ainakin 100 -kertainen.

Tästä hyvänä todisteena se, että C:llä koodatuista ohjelmista löytyy jatkuvasti tietoturvareikiä.
Se, että reikä korjataan nopeasti, ei merkitse tässä yhtään mitään!

Jos olisi koodattu Delphillä, niin sitä tietoturvareikää ei olisi alunperinkään ollut, silloin ei tarvitse mitään korjata, kun mikään ei ole rikki.

Lue lisää

"Entäpä jos ketjun aloittaja nimenomaan haluaa koodata ohjelmansa ObjectPascalilla. Siis EI c:llä, EI C :lla, eikä C#:lla."

Kyseinen ongelma missä avataan verkkosivu kirjautumistiedoilla ratkeaa selaimella itsellään ilman mitään koodin kirjoitusta.

"MS:n .net ei ole edes mainitsemisen arvoinen."

On se jos höpötetään jostain ActiveX:stä. ActiveX on historiaa ja korvaava komponenttiarkkitehtuuri on tehty jotain 14v sitten. Se vanha ActiveX toimi siinä rinnalla kyllä pitkän aikaa ja se on ollut jo ainakin 5v täysin turha. Tekniikka kehittyy ja se on ihan normaalia.

"Syy: ei ole helposti liitettävissä muulla työvälineellä tehtyyn projektiin."

Vika on väärin valitussa työvälineessä tai komponenttiarkkitehtuurissa. .NET:llä tehtyihin komponentteihin on Visual Studio omiaan ja Lazarukselle sitten on LCL komponentit. Että mitähän tässä nyt mahdetaan haluta? Työkalu valitaan tarpeiden mukaan tietysti.

"Sensijaan VLC:n ActiveX -versio Delphi -ohjelmsta käsin käytettynä aiheuttaa jatkuvia ja pahoja ongelmia."

Ilmeisesti VLC:n koodaajat, vaikka ovat osanneet tehdä aivan oikein itsenäisenä ohjelmana toimivan mediatoistinohjelman (VLC.EXE), niin saman ActiveX -versiossa ovat ilmeisesti mokanneet jotakin pahemman kerran."

Ensiksikin:
1. ActiveX on historiaa, sillä ei ole enää mitään merkitystä.
2. VLC Player on portattu Windowsille eikä Windowsin omat komponenttitekniikat yksinkertaisesti kiinnosta eikä niillä ole väliä. Katsos kun maailma ei pyöri sen ympärillä mitä tekniikoita Microsoft tekee.
3. Oletko nyt varmistanut että käytät sitä ActiveX palikkaa oikein? Se bittisyysasia on aika olennaista.
4. VLC Playerin kehittäjät selittävät jotain sellaista, että koko palikka ollaan ilmeisesti siivoamassa pois.

"Mutta jos C -kielellä tehdyltä toteutukselta halutaan sekä sama toiminnallisuus, sama luotettavuus ja sama turvallisuus kuin Delphillä koodatulta ohjelmalta, niin työmäärä on ainakin 100 -kertainen."

Tuo on roskaa. C on harvoja kieliä mitkä soveltuvat äärimmäistä virheettömyyttä vaativiin kohteisiin. Muita on Ada ja riisuttu C .

"Tästä hyvänä todisteena se, että C:llä koodatuista ohjelmista löytyy jatkuvasti tietoturvareikiä."

Ei todista mitään koska turvareikiä löytyy kielestä riippumatta.

"Jos olisi koodattu Delphillä, niin sitä tietoturvareikää ei olisi alunperinkään ollut, silloin ei tarvitse mitään korjata, kun mikään ei ole rikki."

Valhe. Delphillä tehdyistä ohjelmista korjataan vähän väliä turvareikiä.

Et nähtävästi ymmärrä sitä, että turvareiät eivät liity niinkään ohjelmointivälineeseen vaan ohjelmointiprosessiin.

M-Kar kirjoitti:

"Entäpä jos ketjun aloittaja nimenomaan haluaa koodata ohjelmansa ObjectPascalilla. Siis EI c:llä, EI C :lla, eikä C#:lla."

Kyseinen ongelma missä avataan verkkosivu kirjautumistiedoilla ratkeaa selaimella itsellään ilman mitään koodin kirjoitusta.

"MS:n .net ei ole edes mainitsemisen arvoinen."

On se jos höpötetään jostain ActiveX:stä. ActiveX on historiaa ja korvaava komponenttiarkkitehtuuri on tehty jotain 14v sitten. Se vanha ActiveX toimi siinä rinnalla kyllä pitkän aikaa ja se on ollut jo ainakin 5v täysin turha. Tekniikka kehittyy ja se on ihan normaalia.

"Syy: ei ole helposti liitettävissä muulla työvälineellä tehtyyn projektiin."

Vika on väärin valitussa työvälineessä tai komponenttiarkkitehtuurissa. .NET:llä tehtyihin komponentteihin on Visual Studio omiaan ja Lazarukselle sitten on LCL komponentit. Että mitähän tässä nyt mahdetaan haluta? Työkalu valitaan tarpeiden mukaan tietysti.

"Sensijaan VLC:n ActiveX -versio Delphi -ohjelmsta käsin käytettynä aiheuttaa jatkuvia ja pahoja ongelmia."

Ilmeisesti VLC:n koodaajat, vaikka ovat osanneet tehdä aivan oikein itsenäisenä ohjelmana toimivan mediatoistinohjelman (VLC.EXE), niin saman ActiveX -versiossa ovat ilmeisesti mokanneet jotakin pahemman kerran."

Ensiksikin:
1. ActiveX on historiaa, sillä ei ole enää mitään merkitystä.
2. VLC Player on portattu Windowsille eikä Windowsin omat komponenttitekniikat yksinkertaisesti kiinnosta eikä niillä ole väliä. Katsos kun maailma ei pyöri sen ympärillä mitä tekniikoita Microsoft tekee.
3. Oletko nyt varmistanut että käytät sitä ActiveX palikkaa oikein? Se bittisyysasia on aika olennaista.
4. VLC Playerin kehittäjät selittävät jotain sellaista, että koko palikka ollaan ilmeisesti siivoamassa pois.

"Mutta jos C -kielellä tehdyltä toteutukselta halutaan sekä sama toiminnallisuus, sama luotettavuus ja sama turvallisuus kuin Delphillä koodatulta ohjelmalta, niin työmäärä on ainakin 100 -kertainen."

Tuo on roskaa. C on harvoja kieliä mitkä soveltuvat äärimmäistä virheettömyyttä vaativiin kohteisiin. Muita on Ada ja riisuttu C .

"Tästä hyvänä todisteena se, että C:llä koodatuista ohjelmista löytyy jatkuvasti tietoturvareikiä."

Ei todista mitään koska turvareikiä löytyy kielestä riippumatta.

"Jos olisi koodattu Delphillä, niin sitä tietoturvareikää ei olisi alunperinkään ollut, silloin ei tarvitse mitään korjata, kun mikään ei ole rikki."

Valhe. Delphillä tehdyistä ohjelmista korjataan vähän väliä turvareikiä.

Et nähtävästi ymmärrä sitä, että turvareiät eivät liity niinkään ohjelmointivälineeseen vaan ohjelmointiprosessiin.

Lue lisää

Haluaisin oikeastaan haastaa sinut M-Kar koodauskilpailuun:

toteutamme molemmat samaan bisnes -tarpeeseen ohjelman, omani koodaan Delphillä, sinä koodaat omasi C -kielellä.


Veikkaanpa, että 10 vuoden kuluttua ohjelmistojen käyttöönotosta C -kielellä tekemästäsi on löytynyt ainakin 10 sellaista tietoturvareikää, joiden avulla hyökkääjä voi luvattomasti ajaa omaa koodiaan tietojärjestelmässä, joka käyttää C:llä koodaamaasi ohjelmaa.

Sensijaan Delphillä koodaamastani vastaavasta ohjelmasta ei 10 vuodessa ole löytynyt yhtään sellaista sellaista tietoturvareikää, jonka avulla hyökkääjä voisi luvattomasti ajaa omaa koodiaan tietojärjestelmässä.

Ainoa keino, jolla voisit edes teoriassa estää sen, ettei myöskään C -ohjelmastasi löydy yhtään rikollisten mentävää vieraan koodin suorituksen mahdollistavaa tietoturvareikää, olisi se, että käytät ainakin 100 -kertaisesti sen työajan C -koodaukseen, mitä itse käytän Delphi -koodaukseen.

Ja siinäkin tapauksessa onnistumisesi vaatisi äärimmäistä huolellisuutta.

Itse koodaan Delphillä, koska se on osoittautunut erittäin laadukkaaksi sekä ohjelmointikieleksi että koodausympäristöksi.

delphikoodaaja kirjoitti:

Haluaisin oikeastaan haastaa sinut M-Kar koodauskilpailuun:

toteutamme molemmat samaan bisnes -tarpeeseen ohjelman, omani koodaan Delphillä, sinä koodaat omasi C -kielellä.


Veikkaanpa, että 10 vuoden kuluttua ohjelmistojen käyttöönotosta C -kielellä tekemästäsi on löytynyt ainakin 10 sellaista tietoturvareikää, joiden avulla hyökkääjä voi luvattomasti ajaa omaa koodiaan tietojärjestelmässä, joka käyttää C:llä koodaamaasi ohjelmaa.

Sensijaan Delphillä koodaamastani vastaavasta ohjelmasta ei 10 vuodessa ole löytynyt yhtään sellaista sellaista tietoturvareikää, jonka avulla hyökkääjä voisi luvattomasti ajaa omaa koodiaan tietojärjestelmässä.

Ainoa keino, jolla voisit edes teoriassa estää sen, ettei myöskään C -ohjelmastasi löydy yhtään rikollisten mentävää vieraan koodin suorituksen mahdollistavaa tietoturvareikää, olisi se, että käytät ainakin 100 -kertaisesti sen työajan C -koodaukseen, mitä itse käytän Delphi -koodaukseen.

Ja siinäkin tapauksessa onnistumisesi vaatisi äärimmäistä huolellisuutta.

Itse koodaan Delphillä, koska se on osoittautunut erittäin laadukkaaksi sekä ohjelmointikieleksi että koodausympäristöksi.

Lue lisää

"Haluaisin oikeastaan haastaa sinut M-Kar koodauskilpailuun:

toteutamme molemmat samaan bisnes -tarpeeseen ohjelman, omani koodaan Delphillä, sinä koodaat omasi C -kielellä."

Mutta kun edelleenkin jos ainoa työkalu on vasara, ongelmat näyttävät nauloilta.

Osaatko nyt keksiä edes sellaista "bisnestarvetta" missä C ja Delphi ovat molemmat kelvollisia ratkaisuja?

C on tunnetusti systeemiohjelmointiin. Sillä tehdään matalantason koodia, kuten järjestelmän kirjastoja mitä käytetään eri välineistä, kerneliä tai sitten palikoidaan komponenteiksi joita voidaan laittaa sinne putkeen. Muitakin kohteita on kuten vaikka se äärimmäistä virheettömyyttä vaativat ohjelmat joita käytetään vaikka lentokoneissa tai vastaavissa kohteissa missä virheet maksavat ihmishenkiä.

C käy tuollaiseen koska kieli on niin yksinkertainen ja löytyy varmistetut työkalut. Jotain Delphiä ei voi käyttää koska Delphissä olevat virheet voivat tappaa ihmishenkiä. Delphi ei edes toimi muualla kuin Windowsissa ja Windowsia ei voida käyttää lentokoneessa kun sitäkään ei ole varmistettu käytännössä virheettömäksi.

Siksi siellä lentokoneessa onkin joku viimeisen päälle testattu RTOS kerneli ja sen päälle tehdään koodia C:llä, Adalla, tai karsitulla C :lla ja koodiin käytetään aikaa jotta siinä ei ole virheitä.

"Itse koodaan Delphillä, koska se on osoittautunut erittäin laadukkaaksi sekä ohjelmointikieleksi että koodausympäristöksi."

Se on kelvoton moniin asioihin. Esim. ei voi tehdä lentokoneeseen softaa, pitää olla DO-178B kelvollista välinettä.

Ja jotta nyt oikeaasti ymmärrät sen, että pitää valita oikeaan hommaan oikea työkalu niin sitten voidaan ratkoa niitä bisnesongelmia vaikka kuten C:llä tehdään. Tässä vanhassa esimerkiksi havainnollistetaan miten C:llä tehtyjä komponentteja yhdistetään putkeen: https://youtu.be/tc4ROCJYbm0

Kelaa kohtaan 4:55 ja katso siitä muutama minuutti eteenpäin. C:llä on ihan näppärää tehdä niitä komponentteja sinne putkeen.

Saat toki tehtyä Delphillä tehtyä Windowsilla putkeen palikoita mutta kovin on kömpelöä. C:llä unix ympäristössä käyttö on yksinkertaista.

"Jos semmoinen olisi ollut, niin tuo lomakkeen täyttö ja painikkeen painaminen olisi minulle riittänyt siihen että olisin osanut omatoimisesti jatkaa."

Mitä jos kokelisit sitä ilmeistä ratkaisua, eli käyttäisit tähän selainta joka muistaa ne tiedot ja pikakuvakkeesta käynnistyy valmiiksi konffattuna siihen mihin haluaa?

"Uuta kieltä ja ympäristöä en ala opiskelemaan, koska menee monia vuosia ennen kuin se on omaksuttu tavalla että ei ole vain se yksi tapa tehdä jokin asia."

Jonkun selainkomponentin käyttöä tekee uudella kielellä ja ympäristöllä kahvikupillisen aikana, ei siihen vuosia mene.

Jos trvitse NYT ja HETI toimivan ratkaisun, ehdotukseni on tämä:

koodaa Delphillä TWebBrowser -komponenttia käyttäen ohjelma, joka hoitaa yhteistyön haluamasi web -sivuston kanssa.

Muun koodauksen voit tehdä Lazaruksella, jos niin haluat.

Delphi - ja Lazarus -ohjelma kyllä saadaan keskustelemaan keskenään, tavalla tai toisella.

JOS molemmat toimivat samassa Windows -koneessa, suositukseni on WM_COPYDATA -viestin käyttö.

JOS ajat Delphi -ohjelmaa koneella 1 windowsissa ja Lazarus -ohjelmaa koneella 2 linuxissa, silloin suosittelen joko TCP:n tai UDP:n käyttöä. (vrt. TCP/IP)

M-Kar yrittää puffata Microsoftin ".NET" -teknologiaa muka ratkaisuna.

Mutta miten tehdään ".NET":illä DLL, jota voisi
Delphillä tai Lazaruksella koodatusta EXEstä käsin kutsua?

Jos vastaus tähän on "ei mitenkään", niin pidän tätä todisteena siitä, että ".NET" on käyttökelvoton viritys, johon ei kannata sotkeentua.

Toki muuten joku on koodannut Google Chromen pohjalta vähän vastaavan kuin TWebBrowser.

Toimivuudesta ei ole tietoa, eikä siitä, kuinka pahasti tuo vakoilee käyttäjäänsä, vakoiluhan on Googlen ydinliiketoimintaa.

En ole yhtään yllättynyt, jos paljastuu, että jenkkien NSA maksaa Googelle rahaa siitä, että Google vakoilee ja toimittaa tiedot NSA:lle.

Luonnollisesti tuo perustuu NSA:n määräykseen, joka tyypillisesti sisältää vastapuolelle (= tässä Google) salassapitovelvoitteen, eli Google Inc:llä ei ole oikeutta kertoa kenellekään, että Google NSA:n määräyksesä vakoilee ja toimittaa tiedot NSA:lle.

TWebBrowser oli aikansa ylivoimainen keksintö, enkä ole mitään vastaavaa nähnyt missään muualla.

Hmmm...


Oliskiko ollut v. 10 vuotta sitten joku Basicin versio (Powerbasic ?) linuxissa, jossa saattoi olla jotain vastaavaa. Mutta JOS tuo kyseinen basic ei kuulunut tyypillisiin linuxjakeluihin niiden oman pakettihallinnan kautta ladattavana lisäosana (kuten Debian:in apt-get tai aptitude-get), niin tuon asennus linuxille on tyypillisesti jotain erittäin vaikean ja mahdottoman väliltä, poikkeuksena linuxasiantuntijat, joiden toki voi olettaa tuon osaavan.

Windowsissa maksat toki Microsoftille windows -lisenssistä, mutta muu onkin yleensä helppoa.

linuxissa itse käyttöjärjestelmä on usein ilmainen, mutta kun haluat asentaa jotakin, mitä ei käyttöjärjestelmän omasta paketinhallinnasta joko löydy lainkaan, tai löytyy joku liian vanha tai muuten vaan buginen versio, niin tällöin asennus on niin vaikeaa, ettei sitä normaalikäyttäjä osaa itse tehdä, vaan joudut maksamaan linux -asiantuntijalle asennustyöstä.

Kun näitä kustannuksia vertaa, niin jo yksi linuxasiantuntijalta ostettu asennustyö (useammasta puhumattakaan) maksaa enemmän kuin Windows -lisenssi.

Siksipä Windowsin vaihto linuxiin ei ole säästö, vaan lisäkustannus.

Säästö se on vain siinä tapauksessa, ettet ikinä tule tarvitsemaan mitään käytetyn linux -jakelun oman pakettihallinnan ulkopuolelta.
Ja jos tässä erehdyt, lisäkustannus on yleensä moninkertainen verrattuna windows -lisenssin hintaan.

Jos et itse tunne ketään C -kieltä ja siihen usein liittyviä komentorivityökaluja hallitsevaa mukaan projektiin, niin 1 vaihtoehto voisi olla palkata joku kiinalainen koodaaja kehittämään korvaaja TWebBrowserille edellä kuvaamaani tapaan.

Maksaa toki rahaa, mutta JOS olet kehittämässä kaupallista tuotetta, olle on budjetti, ja tuottojakin odotettavissa, kiinalaisen koodarin palkkaaminen voisi olla 1 ratkaisu.

M-Kar kirjoitti:

"Jos semmoinen olisi ollut, niin tuo lomakkeen täyttö ja painikkeen painaminen olisi minulle riittänyt siihen että olisin osanut omatoimisesti jatkaa."

Mitä jos kokelisit sitä ilmeistä ratkaisua, eli käyttäisit tähän selainta joka muistaa ne tiedot ja pikakuvakkeesta käynnistyy valmiiksi konffattuna siihen mihin haluaa?

"Uuta kieltä ja ympäristöä en ala opiskelemaan, koska menee monia vuosia ennen kuin se on omaksuttu tavalla että ei ole vain se yksi tapa tehdä jokin asia."

Jonkun selainkomponentin käyttöä tekee uudella kielellä ja ympäristöllä kahvikupillisen aikana, ei siihen vuosia mene.

Lue lisää

"Mitä jos kokelisit sitä ilmeistä ratkaisua, eli käyttäisit tähän selainta joka muistaa ne tiedot ja pikakuvakkeesta käynnistyy valmiiksi konffattuna siihen mihin haluaa?"

Vaikutat M-Kar näennäisasiantuntijalta.

Tai jos oikeasti väität, että pelkkä selain osaisi tuossa halutun asian (siis ilman varsinaista ohjelmointia millään ohjelmointikielellä), niin laitapa tänne julkisesti esimerkki:

Miten saisi selaimen lataamaan esim. dna prepaid -lataussivun

https://laturi.dna.fi/

mutta siten, että sivulla on jo esitäytettynä käyttäjän haluama puhelinnumero, esimerkiksi: 0441234567

dna on näköjään tässä vuosien varrella muuttanut prepaid -lataussivuaan, mutta jo vuosia sitten kokeilin silloista (ulkomuistista, linkki ei toimi enää):

http://lataus.prepaid.dna.fi/?phonenumber=0441234567

silloinkaan ko. linkin kautta sivulle meneminen EI aiheuttanut sitä, että puhelinnumero -kentässä olisi esitäytettynä tuo 0441234567.

Jollet pysty osoittamaan toimivaa keinoa ladata jonkun linkin kautta tuo dna:n sivu niin, että siellä olisi jo esitäytettynä linkissä oleva käyttäjän haluama puhelinnumero, niin silloin sinua on syytä pitää ns. näennäisosaajana.

En väitä, että dna prepaid -lataus suoraan olisi se, mitä alkuperäinen kysyjä haluaa.

Mutta jos väität, että pelkkä selain ilman ohjelmointia olisi kykenevä ratkaisemaan ongelman, ehkäpä esität väitteesi tueksi esimerkin,. miten saa ladattua tuon dna prepaid -lataussivun selaimeen siten, että haluttu puhelinnumero on siinä jo esitäytettynä.

Jos et esitä, pidän osoitettuna, että olet näennäisosaaja.

delphikoodaaja kirjoitti:

"Mitä jos kokelisit sitä ilmeistä ratkaisua, eli käyttäisit tähän selainta joka muistaa ne tiedot ja pikakuvakkeesta käynnistyy valmiiksi konffattuna siihen mihin haluaa?"

Vaikutat M-Kar näennäisasiantuntijalta.

Tai jos oikeasti väität, että pelkkä selain osaisi tuossa halutun asian (siis ilman varsinaista ohjelmointia millään ohjelmointikielellä), niin laitapa tänne julkisesti esimerkki:

Miten saisi selaimen lataamaan esim. dna prepaid -lataussivun

https://laturi.dna.fi/

mutta siten, että sivulla on jo esitäytettynä käyttäjän haluama puhelinnumero, esimerkiksi: 0441234567

dna on näköjään tässä vuosien varrella muuttanut prepaid -lataussivuaan, mutta jo vuosia sitten kokeilin silloista (ulkomuistista, linkki ei toimi enää):

http://lataus.prepaid.dna.fi/?phonenumber=0441234567

silloinkaan ko. linkin kautta sivulle meneminen EI aiheuttanut sitä, että puhelinnumero -kentässä olisi esitäytettynä tuo 0441234567.

Jollet pysty osoittamaan toimivaa keinoa ladata jonkun linkin kautta tuo dna:n sivu niin, että siellä olisi jo esitäytettynä linkissä oleva käyttäjän haluama puhelinnumero, niin silloin sinua on syytä pitää ns. näennäisosaajana.

En väitä, että dna prepaid -lataus suoraan olisi se, mitä alkuperäinen kysyjä haluaa.

Mutta jos väität, että pelkkä selain ilman ohjelmointia olisi kykenevä ratkaisemaan ongelman, ehkäpä esität väitteesi tueksi esimerkin,. miten saa ladattua tuon dna prepaid -lataussivun selaimeen siten, että haluttu puhelinnumero on siinä jo esitäytettynä.

Jos et esitä, pidän osoitettuna, että olet näennäisosaaja.

Lue lisää

"Miten saisi selaimen lataamaan esim. dna prepaid -lataussivun"

Selaimessa on valmiina käyttäjätunnuksen ja salasanan tallennus ja sellainen onnistuu ihan suoraan. Tuollainen tarvitsee jo nysväämistä ja voisi käyttää esimerkiksi tätä: https://chrome.google.com/webstore/detail/autofill/nlmmgnhgdeffjkdckmikfpnddkbbfkkk

Ja jos ei valmis palikka kelpaa niin sitä voi itse tehdä selaimeen laajennoksen joka täyttää jonkun sivun kentät. Se olisi oikea tapa ratkoa asia.

delphikoodaaja kirjoitti:

Jos trvitse NYT ja HETI toimivan ratkaisun, ehdotukseni on tämä:

koodaa Delphillä TWebBrowser -komponenttia käyttäen ohjelma, joka hoitaa yhteistyön haluamasi web -sivuston kanssa.

Muun koodauksen voit tehdä Lazaruksella, jos niin haluat.

Delphi - ja Lazarus -ohjelma kyllä saadaan keskustelemaan keskenään, tavalla tai toisella.

JOS molemmat toimivat samassa Windows -koneessa, suositukseni on WM_COPYDATA -viestin käyttö.

JOS ajat Delphi -ohjelmaa koneella 1 windowsissa ja Lazarus -ohjelmaa koneella 2 linuxissa, silloin suosittelen joko TCP:n tai UDP:n käyttöä. (vrt. TCP/IP)

M-Kar yrittää puffata Microsoftin ".NET" -teknologiaa muka ratkaisuna.

Mutta miten tehdään ".NET":illä DLL, jota voisi
Delphillä tai Lazaruksella koodatusta EXEstä käsin kutsua?

Jos vastaus tähän on "ei mitenkään", niin pidän tätä todisteena siitä, että ".NET" on käyttökelvoton viritys, johon ei kannata sotkeentua.

Toki muuten joku on koodannut Google Chromen pohjalta vähän vastaavan kuin TWebBrowser.

Toimivuudesta ei ole tietoa, eikä siitä, kuinka pahasti tuo vakoilee käyttäjäänsä, vakoiluhan on Googlen ydinliiketoimintaa.

En ole yhtään yllättynyt, jos paljastuu, että jenkkien NSA maksaa Googelle rahaa siitä, että Google vakoilee ja toimittaa tiedot NSA:lle.

Luonnollisesti tuo perustuu NSA:n määräykseen, joka tyypillisesti sisältää vastapuolelle (= tässä Google) salassapitovelvoitteen, eli Google Inc:llä ei ole oikeutta kertoa kenellekään, että Google NSA:n määräyksesä vakoilee ja toimittaa tiedot NSA:lle.

TWebBrowser oli aikansa ylivoimainen keksintö, enkä ole mitään vastaavaa nähnyt missään muualla.

Hmmm...


Oliskiko ollut v. 10 vuotta sitten joku Basicin versio (Powerbasic ?) linuxissa, jossa saattoi olla jotain vastaavaa. Mutta JOS tuo kyseinen basic ei kuulunut tyypillisiin linuxjakeluihin niiden oman pakettihallinnan kautta ladattavana lisäosana (kuten Debian:in apt-get tai aptitude-get), niin tuon asennus linuxille on tyypillisesti jotain erittäin vaikean ja mahdottoman väliltä, poikkeuksena linuxasiantuntijat, joiden toki voi olettaa tuon osaavan.

Windowsissa maksat toki Microsoftille windows -lisenssistä, mutta muu onkin yleensä helppoa.

linuxissa itse käyttöjärjestelmä on usein ilmainen, mutta kun haluat asentaa jotakin, mitä ei käyttöjärjestelmän omasta paketinhallinnasta joko löydy lainkaan, tai löytyy joku liian vanha tai muuten vaan buginen versio, niin tällöin asennus on niin vaikeaa, ettei sitä normaalikäyttäjä osaa itse tehdä, vaan joudut maksamaan linux -asiantuntijalle asennustyöstä.

Kun näitä kustannuksia vertaa, niin jo yksi linuxasiantuntijalta ostettu asennustyö (useammasta puhumattakaan) maksaa enemmän kuin Windows -lisenssi.

Siksipä Windowsin vaihto linuxiin ei ole säästö, vaan lisäkustannus.

Säästö se on vain siinä tapauksessa, ettet ikinä tule tarvitsemaan mitään käytetyn linux -jakelun oman pakettihallinnan ulkopuolelta.
Ja jos tässä erehdyt, lisäkustannus on yleensä moninkertainen verrattuna windows -lisenssin hintaan.

Jos et itse tunne ketään C -kieltä ja siihen usein liittyviä komentorivityökaluja hallitsevaa mukaan projektiin, niin 1 vaihtoehto voisi olla palkata joku kiinalainen koodaaja kehittämään korvaaja TWebBrowserille edellä kuvaamaani tapaan.

Maksaa toki rahaa, mutta JOS olet kehittämässä kaupallista tuotetta, olle on budjetti, ja tuottojakin odotettavissa, kiinalaisen koodarin palkkaaminen voisi olla 1 ratkaisu.

Lue lisää

"koodaa Delphillä TWebBrowser -komponenttia käyttäen ohjelma, joka hoitaa yhteistyön haluamasi web -sivuston kanssa."

No löl taas... Maksaa nyt tuosta riemusta Delphistä ja Windows tietokoneesta kun voi klikata maksutta selaimeen valmiin laajennoksen mikä tekee temput eikä tarvitse kirjoittaa koodia.

TÄMÄ on se asia, että jos ainoa työkalu on vasara, kaikki ongelmat alkavat näyttämään nauloilta.

1. Pitää katkaista lauta -> vasaralla
2. Pitää vaihtaa autoon öljyt -> vasaralla
3. Pitää maalata seinä -> vasaralla

Oikea työkalu oikeaan hommaan.

"M-Kar yrittää puffata Microsoftin ".NET" -teknologiaa muka ratkaisuna."

Siis se on Windows kehityksessä se mitä käytetään. Käytännössä WinRT päätelaitteissa ja ASP.NET palvelimissa.

"Mutta miten tehdään ".NET":illä DLL, jota voisi
Delphillä tai Lazaruksella koodatusta EXEstä käsin kutsua?"

Ei vaan Lazaruksella käytetään tämä komponentteja. Eli ohjelmoidaan itse vaikka LCL selainkomponentti. Mutta kyseesssä kun on väärä työkalu tähän ongelmaan niin eihän tuossa ole tietenkään mitään järkeä.

"TWebBrowser oli aikansa ylivoimainen keksintö, enkä ole mitään vastaavaa nähnyt missään muualla."

Ei kyllä ollut mikään Delphin keksintö. Kyseessähän oli Microsoftin komponentti. Microsoft oli tässä kyllä vissiin ensimmäinen kuka teki sen selaimen fiksusti komponentiksi mutta melkein saman tien tuli Webkit ja Gecko. Joka tapauksessa, 90-luvun keksintöjä.

"linuxissa itse käyttöjärjestelmä on usein ilmainen, mutta kun haluat asentaa jotakin, mitä ei käyttöjärjestelmän omasta paketinhallinnasta joko löydy lainkaan, tai löytyy joku liian vanha tai muuten vaan buginen versio, niin tällöin asennus on niin vaikeaa, ettei sitä normaalikäyttäjä osaa itse tehdä, vaan joudut maksamaan linux -asiantuntijalle asennustyöstä."

Niin missä käyttöjärjestelmässä?

"Siksipä Windowsin vaihto linuxiin ei ole säästö, vaan lisäkustannus."

Sellaista käyttöjärjestelmää ei ole olemassa kuin Linux.

Kyllä se on niin, että ihan itse ehdotit jotain kallista Windowsia ja kallista Delphiä, ja jotain järkyttävän työlästä nysväämistä, että saisi jonkun lomakkeen täytettyä vaikka se onnistuu maksutta selaimella parilla klikkauksella.

"Säästö se on vain siinä tapauksessa, ettet ikinä tule tarvitsemaan mitään käytetyn linux -jakelun oman pakettihallinnan ulkopuolelta."

Delphi ei muuten käytä Windowsin pakettihallintaa, eikä edes Lazarus ja siksi niiden hinta on moninkertainen ja ohjelmien asennus tarvitsee erikoisasiantuntijoita. Normaali ohjelmistokehittäjä ei kykene asentamaan ohjelmaa Windowsiin paketinhallinnan ulkopuolelta.

"Jos et itse tunne ketään C -kieltä ja siihen usein liittyviä komentorivityökaluja hallitsevaa mukaan projektiin, niin 1 vaihtoehto voisi olla palkata joku kiinalainen koodaaja kehittämään korvaaja TWebBrowserille edellä kuvaamaani tapaan.

Maksaa toki rahaa, mutta JOS olet kehittämässä kaupallista tuotetta, olle on budjetti, ja tuottojakin odotettavissa, kiinalaisen koodarin palkkaaminen voisi olla 1 ratkaisu."

Edelleenkin ei mitään järkeä. Jos tehdään omaa tuotetta niin miksi sitä tietoa ei pidä siellä palvelimen tietokannassa ja laita kenttiin valmiiksi kun sivu avataan? Ainoa työkalu kun on vasara, kaikki ongelmat näyttävät nauloilta...

"Delphi ei muuten käytä Windowsin pakettihallintaa, eikä edes Lazarus ja siksi niiden hinta on moninkertainen ja ohjelmien asennus tarvitsee erikoisasiantuntijoita. Normaali ohjelmistokehittäjä ei kykene asentamaan ohjelmaa Windowsiin paketinhallinnan ulkopuolelta."

No tämä on jo pohjanoteeraus.

Jos tekee Delphillä ohjelman, ja haluaa, että kuka tahansa osaa asentaa kyseisen ohjelman itse, niin koodaaja toimii näin:

1. tehdään sovellus .exe (Delphillä)

2. Tehdään asennusohjelma, vaikkapa asennasovellus.exe tai asennasovellus.msi Jos EXE, sen voi tehdä Delphilläkin, .msi -muotoisisa asennuspaketteja tekee aika moni työkaluohjelma, joka on nimenomaan tarkoitettu asennuspakettien tekoon. Yksi esimerkki on InnoSetup, mutta näitä on varmasti monta muutakin.

jos asennuspaketti on asennasovellus.exe niin se uploadataan web -palvelimelle, esim osoitteeseen:

http://www.esimerkki_oy.fi/binaries/asennasovellus.exe

Ja senjälkeen vaikkapa web -sivulle, URLiin:

http://www.esimerkki_oy.fi/asennasovellus.html

laitetaan linkki tuohon asennuspakettiin

http://www.esimerkki_oy.fi/binaries/asennasovellus.exe

ja asennusohjeeksi: lataa ko. asennuspaketti linkistä ja joko

1) valitse, että paketti ajetaan heti kun se on ladattu

tai

2) tallenna se omalle kiintolevyllesi ja käynnistä asennasovellus.exe tämän jälkeen omalta kiintolevyltäsi (katso tarkkaan, mihin tiedosto tallennetaan latauksen yhteydessä, jotkut selaimet kun oletuksena tallentavat johonkin latauskansioon, jota käyttäjä ei välttämätt tiedä, jos ei ole enne ladannut mitään ko. selaimella)

Useimmat loppukäyttäjätkin osaavat noudattaa näitä ohjeita, ja kun asennasovellus.exe käynnistyy, se huolehtii asennuksesta.

Tuohon asennasovellus.exe:en on liitetty sisäinen manifesti, joka kertoo sen tarvitsevan admin -oikeudet (tai muuten sitä ei voi asentaa Program Files -hakemistoon).

Tai sitten homma onnistuu ilman manifestiakin, mutta tällöin paketin nimi on vaikkapa:

minunsovellus_setup.exe

Tässä tapauksessa manifestia ei välttämättä tarvita, koska kun tiedostonimi sisältää merkkijonon "setup", niin windows kohtelee sitä automaattisesti asennusohjelmana.

Delphi -sovelluksen asennus on helppoa ja yksinkertaista, eikä siihen pakettimanagereita tarvita.

Windowsissa ei myöskään ole esim debianista tuttua "dependency hell" -ongelmaa, joka aiheuttaa debianissa juurikin sen, että jos yrität asentaa jotain debianin oman pakettihallinnan ulkopuolelta, ongelmia on yleensä aina tiedossa.

Delphillä tehty sovellus kun ei oletuksena tarvitse mitään sellaista koneelle, mitä sille koneelle ei olisi asentunut jo windowsin asennuksen yhteydessä.

Poikkeuksena ohjelmat, jotka nimenomaan tarvitsevat jotain lisätoiminnallisuutta (vaikkapa omat_lisafunktiot.dll, tämähän voi olla koodattu joko myös Delphillä tai sitten vaikkapa C:llä, mikä on järkevää, jos tarvitaan sellaista toiminnallisuutta, josta on jo olemassaoleva ja toimiva C -toteutus, muttei vastaavaa Delphi -toteutusta).

Mutta tässä tapauksessa tuo minunsovellus_setup.exe luonnollisesti asentaisi myös tuon omat_lisafunktiot.dll itse exe -tiedoston lisäksi.

Esimerkiksi Skype (ainakin sen monet vanhemmat versiot) on koodattu Delphillä, ja sen asennus on juuri niin helppoa kuin sen pitääkin olla: ajetaan www.skype.com -osoitteesta löytyvä Skype_setup.exe ja asennusohjelma huolehtii asennuksen yksityskohdista.

99% koneista tuo Skypen asennus toimii automaattisesti juuri oikein.

Ainoana poikkeuksena koneet, joissa on

1) useampi kuin 1 äänikortti

tai

2) muu sellainen laitteistoratkaisu, jossa ko. laitteisto aiheuttaa "haamumikrofonin" windowsiin, jolloin skypen oletus on "microphone1" mutta kyseinen "microphone1" on haamuikrofoni, jota ei ole oikeasti olemassa (jonkinlainen outo laitteistoon ja/tai sen ajureihin liittyvä ohjelmointivirhe, joka saa windowsin asentamaan ns. haamulaitteen, joka ei milloinkaan oikeasti toimi).

Tällaisessa tapauksessa: kun soitat puhelun Skypellä, niin vastapuoli ei kuule sinun ääntäsi lainkaan, mutta muuten kaikki toimii oikein ja normaalisti. Tämän vian korjaaminenkin on yksinkertaista: skypen ääniasetuksista (Sound settings) vaihdetaan käytettävä mikrofoni laitteeksi "microphone2". Tämän jälkeen Skype toimii oikein. (mutta ongelma saattaa palata järjestelmän buuttauksen jälkeen, korjaus sama uudelleen, eli taas äänen input -laitteeksi "microphone2".

Delphi on tunnettu juuri ns. "single exe" -periaatteesta, eli pelkkä exe -tiedosto yksinään riittää ohjelman suorittamiseen, mitään autiedostoja ei tarvita, koska kaikki tarvittava tieto on tuon EXE:n sisällä.

Tämäkin on Delphin etuja, valmiin ohjelmiston varma ja luotettava ja helppo asennus, ei ongelmia !

delphikoodaaja kirjoitti:

"Delphi ei muuten käytä Windowsin pakettihallintaa, eikä edes Lazarus ja siksi niiden hinta on moninkertainen ja ohjelmien asennus tarvitsee erikoisasiantuntijoita. Normaali ohjelmistokehittäjä ei kykene asentamaan ohjelmaa Windowsiin paketinhallinnan ulkopuolelta."

No tämä on jo pohjanoteeraus.

Jos tekee Delphillä ohjelman, ja haluaa, että kuka tahansa osaa asentaa kyseisen ohjelman itse, niin koodaaja toimii näin:

1. tehdään sovellus .exe (Delphillä)

2. Tehdään asennusohjelma, vaikkapa asennasovellus.exe tai asennasovellus.msi Jos EXE, sen voi tehdä Delphilläkin, .msi -muotoisisa asennuspaketteja tekee aika moni työkaluohjelma, joka on nimenomaan tarkoitettu asennuspakettien tekoon. Yksi esimerkki on InnoSetup, mutta näitä on varmasti monta muutakin.

jos asennuspaketti on asennasovellus.exe niin se uploadataan web -palvelimelle, esim osoitteeseen:

http://www.esimerkki_oy.fi/binaries/asennasovellus.exe

Ja senjälkeen vaikkapa web -sivulle, URLiin:

http://www.esimerkki_oy.fi/asennasovellus.html

laitetaan linkki tuohon asennuspakettiin

http://www.esimerkki_oy.fi/binaries/asennasovellus.exe

ja asennusohjeeksi: lataa ko. asennuspaketti linkistä ja joko

1) valitse, että paketti ajetaan heti kun se on ladattu

tai

2) tallenna se omalle kiintolevyllesi ja käynnistä asennasovellus.exe tämän jälkeen omalta kiintolevyltäsi (katso tarkkaan, mihin tiedosto tallennetaan latauksen yhteydessä, jotkut selaimet kun oletuksena tallentavat johonkin latauskansioon, jota käyttäjä ei välttämätt tiedä, jos ei ole enne ladannut mitään ko. selaimella)

Useimmat loppukäyttäjätkin osaavat noudattaa näitä ohjeita, ja kun asennasovellus.exe käynnistyy, se huolehtii asennuksesta.

Tuohon asennasovellus.exe:en on liitetty sisäinen manifesti, joka kertoo sen tarvitsevan admin -oikeudet (tai muuten sitä ei voi asentaa Program Files -hakemistoon).

Tai sitten homma onnistuu ilman manifestiakin, mutta tällöin paketin nimi on vaikkapa:

minunsovellus_setup.exe

Tässä tapauksessa manifestia ei välttämättä tarvita, koska kun tiedostonimi sisältää merkkijonon "setup", niin windows kohtelee sitä automaattisesti asennusohjelmana.

Delphi -sovelluksen asennus on helppoa ja yksinkertaista, eikä siihen pakettimanagereita tarvita.

Windowsissa ei myöskään ole esim debianista tuttua "dependency hell" -ongelmaa, joka aiheuttaa debianissa juurikin sen, että jos yrität asentaa jotain debianin oman pakettihallinnan ulkopuolelta, ongelmia on yleensä aina tiedossa.

Delphillä tehty sovellus kun ei oletuksena tarvitse mitään sellaista koneelle, mitä sille koneelle ei olisi asentunut jo windowsin asennuksen yhteydessä.

Poikkeuksena ohjelmat, jotka nimenomaan tarvitsevat jotain lisätoiminnallisuutta (vaikkapa omat_lisafunktiot.dll, tämähän voi olla koodattu joko myös Delphillä tai sitten vaikkapa C:llä, mikä on järkevää, jos tarvitaan sellaista toiminnallisuutta, josta on jo olemassaoleva ja toimiva C -toteutus, muttei vastaavaa Delphi -toteutusta).

Mutta tässä tapauksessa tuo minunsovellus_setup.exe luonnollisesti asentaisi myös tuon omat_lisafunktiot.dll itse exe -tiedoston lisäksi.

Esimerkiksi Skype (ainakin sen monet vanhemmat versiot) on koodattu Delphillä, ja sen asennus on juuri niin helppoa kuin sen pitääkin olla: ajetaan www.skype.com -osoitteesta löytyvä Skype_setup.exe ja asennusohjelma huolehtii asennuksen yksityskohdista.

99% koneista tuo Skypen asennus toimii automaattisesti juuri oikein.

Ainoana poikkeuksena koneet, joissa on

1) useampi kuin 1 äänikortti

tai

2) muu sellainen laitteistoratkaisu, jossa ko. laitteisto aiheuttaa "haamumikrofonin" windowsiin, jolloin skypen oletus on "microphone1" mutta kyseinen "microphone1" on haamuikrofoni, jota ei ole oikeasti olemassa (jonkinlainen outo laitteistoon ja/tai sen ajureihin liittyvä ohjelmointivirhe, joka saa windowsin asentamaan ns. haamulaitteen, joka ei milloinkaan oikeasti toimi).

Tällaisessa tapauksessa: kun soitat puhelun Skypellä, niin vastapuoli ei kuule sinun ääntäsi lainkaan, mutta muuten kaikki toimii oikein ja normaalisti. Tämän vian korjaaminenkin on yksinkertaista: skypen ääniasetuksista (Sound settings) vaihdetaan käytettävä mikrofoni laitteeksi "microphone2". Tämän jälkeen Skype toimii oikein. (mutta ongelma saattaa palata järjestelmän buuttauksen jälkeen, korjaus sama uudelleen, eli taas äänen input -laitteeksi "microphone2".

Delphi on tunnettu juuri ns. "single exe" -periaatteesta, eli pelkkä exe -tiedosto yksinään riittää ohjelman suorittamiseen, mitään autiedostoja ei tarvita, koska kaikki tarvittava tieto on tuon EXE:n sisällä.

Tämäkin on Delphin etuja, valmiin ohjelmiston varma ja luotettava ja helppo asennus, ei ongelmia !

Lue lisää

"No tämä on jo pohjanoteeraus."

Itsehän sinä sanoit, että jos ohjelma ei käytä järjestelmän paketinhallintaa niin sitä ei osaa asentaa.

"Jos tekee Delphillä ohjelman, ja haluaa, että kuka tahansa osaa asentaa"

Se ongelma tulee jo siinä jos pitää asentaa, sitä kun ei kaikki osaa vaan yleensä ohjelma käynnistetään linkistä suoraan.

Ja jos pitää jostain nettisivulta ladata jotain ja asentaa niin tuo mitä kerroit ei tietenkään riitä vaan nettisivun pitää tunnistaa käyttäjän käyttöjärjestelmä, versio ja laitearkkitehtuuri ja tarjota tälle yhteensopiva paketti.

Se ei tietenkään voi olla mikään .exe koska itse sanoit, että on vaikeata jos ei käytä paketinhallintaa.

"Delphi -sovelluksen asennus on helppoa ja yksinkertaista, eikä siihen pakettimanagereita tarvita."

Kyllä tarvitsee koska sanoit, että on muuten vaikeata. Eli sinne vaan .appx pakettiin niin on helppoa. Tai edes .msi jos menee oldschool meiningillä.

"Windowsissa ei myöskään ole esim debianista tuttua "dependency hell" -ongelmaa, joka aiheuttaa debianissa juurikin sen, että jos yrität asentaa jotain debianin oman pakettihallinnan ulkopuolelta, ongelmia on yleensä aina tiedossa."

Älä valehtele, Debianissa ei ole mitään "dependency hell" -ongelmaa. Ei ole mitään ongelmia asentaa Debianille tehtyä ohjelmaa Debianiin.

"Delphi on tunnettu juuri ns. "single exe" -periaatteesta, eli pelkkä exe -tiedosto yksinään riittää ohjelman suorittamiseen, mitään autiedostoja ei tarvita, koska kaikki tarvittava tieto on tuon EXE:n sisällä."

Mutta kun näin ei aina saa tehdä. Monien komponenttien lisenssi kieltää staattisen linkkaamisen.

"Tämäkin on Delphin etuja, valmiin ohjelmiston varma ja luotettava ja helppo asennus, ei ongelmia !"

Tuon saman tekee kaikki työkalut, ei mitään etua. Ennemminkin haitta parempiin nähden koska tarvitsee edelleen asentaa jotain.

"Mutta nyt sinulle "M-Kar" joka et selvästikään tunne ohjelmointia ollenkaan, selvennän kysymystä esimerkillä:"

Olen ohjelmoinut 25v. Tunnen oikein hyvin ohjelmointia.

"Ajatellaan että olet kinostunut oman senttihuutokaupan ylläpidosta, mutta sinun tulisi tietää onko se kannattavaa."

Tämä ei ole niinkään tekninen ongelma vaan liittyy liiketoimintaan ja onko se kannattavaa.

"En ole koskaan kuulut selaimesta jolla tuommoinen onnistuisi, joten se olisi tehtävä itse."

Selaimella ajetaan ohjelman käyttöliittymää. Se osa ohjelmaa mikä rouskii tiedon, tallentaa, hakee jne. on tietystikin palvelimessa, ei käyttöliittymäosassa.

Kai sinä nyt ymmärrät, että käyttöliittymä pidetään erillään ja että ohjelmia tehdään palvelimeen?

"Ja sitten ohjelmointi kielen valinta ja sen taitaminen ja kehityksessä mukana pysyminen on elämän valintoja, samaan tapaan kuin puolison valinta, lasten teko, asuin paikkakunnan valinta, koulutus. Näitä ei vaihdeta siitä syystä että joku naapuri tai tuttu muutti Lapualle. Näitä valintoja tulisi myös kunnioittaa, eri tapaan kuin auton, tietokoneen, kännykän ostoa, tai käyttöjärjestelmän valintaa."

Ammattitaitoinen ohjelmoija omaksuu tavallisesti uuden ohjelmointikielen vuosittain. Ei siksi että vanhakin toimisi vaan siksi, että kehitys on jatkuvaa, tulee uusia projekteja joihin uusi kieli sopii paremmin, aivot pysyvät paremmin vetreinä ja näkee asiat vähän laajemmin.

Sitä kun ainoa työkalu on vasara, kaikki ongelmat alkavat näyttämään nauloilta.

"Minulle ei tulisi mieleenkään haukkua edes pahimman vihollisen vaimoa huoraksi, sen enempää kuin kaverin opiskelemaan ohjelmointi kielen valintaa."

Niin siis kun puhutaan ohjelmointikielen opiskelusta niin tämähän on aloittelijoiden puuhaa, sellaiset jotka opettelevat ohjelmoimaan.

Katsos kun sitä ohjelmointiosaamista on kolmea noin suunnilleen kolmea tasoa:

1. Perustaso "koodari". Ohjelmoijalle annetaan speksi ja pyydetään tekemään se. Kieli voi olla määritelty että tee se tällä kielellä.
2. Ohjelmistoarkkitehti. Ohjelmoijalle annetaan konsepti millaista pitäisi olla ja se sitten määrittelee, suunnittelee arkkitehtuurin ja toteuttaa sen alusta loppuun tai vaikka ulkoistaa joitakin palikoita toisaalle. Tietysti myös tiedetään nämä työskentelytapojen perusasiat
3. Parhaimmalla tasolla ymmärretään myös se liiketoiminta ja autetaan sen kanssa että saadaan homma pelaamaan.

Siinä vaiheessa kun opetellaan ensimmäistä ohjelmointikieltä ollaan vasta aloittelijatasolla. Perustasolla jo voi työssä olla se ohjelmointikieli jotain muuta millä aloittanut opiskelun.

Ohjelmointikieli kun on vain TYÖKALU siihen että muotoillaan omat ajatukset toimivaksi ohjelmaksi. Yhdellä kielellä jos tekee asioita ei oikeastaan vielä osaa mitään koska eri kielissä on eri toimintoja ja toisiin kieliin toteutetaan perusasioita. Ei siis ymmärrä kaikkia käsitteitä edes jos ajatus rajoittuu jonkun ohjelmointikielen rajoitteisiin. Kuten sanoin, jos ainoa työkalu on vasara, kaikki ongelmat alkavat näyttämään nauloilta.

"Minä tein ensimmäisen ison ohjelman QBasic -ympäristössä (Levyn paloittelu) ja ensimmäinen pienempi Comader 64 konekielinen rektiotesti peli, ja nopea lämpömittari kuumeen mittaukseen. Nämä molemmat ympäristöt on suhkot vaatimattomia, mutta ei missään nimessä kahvikupillisen aikana omaksuttavissa, ja nyt siis puhuin ympäristön oppimisesta, en varsinaista käskykannasta omaksumisesta."

Niin toki kun kyse aloittelijasta niin siinä on silloin enemmän kynnystä kun enemmän tietoa omaksuttavana. Sitten kun sitä osaa nämä Java, C , tekee konekielellä, Javascript, Lisp, SQL kannat, shellskriptit, regexp jne. niin ei se uusi kieli ole mikään juttu enää ammattilaiselle. Sitä vaan katsellaan dokumentaatiosta että miten ne operaattorit menee, miten muotoillaan lambda lausekkeet, miten rakennetaan luokkia, miten tehdään säikeitä jne.

"Minulla on selvä käsitys siitä mitä tasoa kaverin osaaminen on silloin kun se sanoo osaavansa 12 eri ohjelmointi kieltä, tai jos kaveri sanoo osaavansa puhua 12 eri kieltä."

No olen varmaan ehtinyt kirjoittaa koodia vähintään 25 eri kielellä.

En nyt sanoisi että olisin erikoistunut tekemään 25 kielellä työtä vaan valitsen projektiin sopivimmat kielet, aina kun ei yhdellä pärjää jos vaikka controlleri ja backend on vaikka Typescriptiä niin tyylitiedostoissa on voitu käyttää Sassia.

Ne "suosikit" toki vaihtelee, että vaikka olen itsekin jollain QBasicilla tehnyt koodia niin en minä nyt sillä nyt tietenkään mitään tee. Se on sitä historiaa mutta ei toisaalta olisi mikään ongelma ylläpitää QBasicilla tehtyä ohjelmaa.

"Sinä tuskin olit vielä syntynyt kun yleisradio lähetti Comader 64 ohjelma esimerkkejä radio lähetyksenä, vai olitko, ne on merkittäviä virstan pylväitä kehityksen saatossa, ei ole mitenkään perusteltua puhua alentavasti näistäkään ympäristöistä."

Toki olin. Commorore 64:lle ohjelmoin Basicilla sekä 6510 prosessorin konekielellä.

Juu, en minäkään mistään ohjelmointikielistä selitä. Ei se nyt ole olennaista tietoa.

Sama kuin auton kuljettajan pitäisi käydä leuhkimaan kuinka monella eri merkkisellä autolla on ajanut vaikka se ei siihen kuljettamiseen vaikuta oikein mitenkään.

"Uskoisin tämän ratkaisun toimivan, ja on sekä helponpi että luotettavampi tapa kuin M-Karin ehdottama Google Chromeen perustuva lisäke."

Ei ainakaan helpompi.

Google Chrome pulikan luotettavuutta rajoittaa Google Chrome, joka päivittyy 1,5kk välein.

Joskus Chromen päivitys tekee muutoksia jolloin saattaa joutua noita pulikoita checkkaamaan.

Itse tässä hiljattain korjasin yhden tuollaisen ongelman kun pikakuvakkeesta käynnistyi Chrome sovellus ja Chromesta oli muuttaneet komentorivivalitsinta päivityksessä niin tuli yhden merkin muutos käynnistysparametriin että pikakuvake toimi.

Tuo TWebBrowser Gambas Qt5 webkit hässäkkä kyllä sellainen sekasotku, että näkemällä tarpeeksi vaivaa sen saa toimimaan mutta ainoa paikka missä se toimii helposti luotettavasti on varmaan joku Debian mistä nuo kaikki saa klikattua siihen tuetusti ja jota pidetään vuosia vakaana.

Mutta onko tuo nyt vaivan arvoista? Tuntimäärät mitä projektiin menisi seuraavan 6v aikana vaikka on varmaan 100x enemmän mitä Chrome pulikalla tehtäessä.

Mutta on onhan noita muitakin ratkaisuja toki olemassa. Käytännössä mikä tahansa hyvin tuettu ja dokumentoitu kehitysväline missä on selainkomponentti valmiina hoitaisi hommaa kun ei tarvitse pilkkoa sitä lukemattomiin osiin mikä tekee sen hauraaksi.

Qt5 olisi yksi vaihtoehto: https://www.qt.io/developers/
Toinen sopiva olisi Electron: http://electron.atom.io/

Applella toki voisi käyttää ihan Applen omaa kehitysympäristöä ja Windowsilla taas Visual Studiota C#:lla. Androidille Android API:n webview hoitaa homman ja Solarikselle voisi tehdä Java FX:llä.

M-Kar kirjoitti:

"Uskoisin tämän ratkaisun toimivan, ja on sekä helponpi että luotettavampi tapa kuin M-Karin ehdottama Google Chromeen perustuva lisäke."

Ei ainakaan helpompi.

Google Chrome pulikan luotettavuutta rajoittaa Google Chrome, joka päivittyy 1,5kk välein.

Joskus Chromen päivitys tekee muutoksia jolloin saattaa joutua noita pulikoita checkkaamaan.

Itse tässä hiljattain korjasin yhden tuollaisen ongelman kun pikakuvakkeesta käynnistyi Chrome sovellus ja Chromesta oli muuttaneet komentorivivalitsinta päivityksessä niin tuli yhden merkin muutos käynnistysparametriin että pikakuvake toimi.

Tuo TWebBrowser Gambas Qt5 webkit hässäkkä kyllä sellainen sekasotku, että näkemällä tarpeeksi vaivaa sen saa toimimaan mutta ainoa paikka missä se toimii helposti luotettavasti on varmaan joku Debian mistä nuo kaikki saa klikattua siihen tuetusti ja jota pidetään vuosia vakaana.

Mutta onko tuo nyt vaivan arvoista? Tuntimäärät mitä projektiin menisi seuraavan 6v aikana vaikka on varmaan 100x enemmän mitä Chrome pulikalla tehtäessä.

Mutta on onhan noita muitakin ratkaisuja toki olemassa. Käytännössä mikä tahansa hyvin tuettu ja dokumentoitu kehitysväline missä on selainkomponentti valmiina hoitaisi hommaa kun ei tarvitse pilkkoa sitä lukemattomiin osiin mikä tekee sen hauraaksi.

Qt5 olisi yksi vaihtoehto: https://www.qt.io/developers/
Toinen sopiva olisi Electron: http://electron.atom.io/

Applella toki voisi käyttää ihan Applen omaa kehitysympäristöä ja Windowsilla taas Visual Studiota C#:lla. Androidille Android API:n webview hoitaa homman ja Solarikselle voisi tehdä Java FX:llä.

Lue lisää

Turhaa löpinään asiaa ymmärttämättömältä

Et-ymmärrä-ydintä kirjoitti:

Turhaa löpinään asiaa ymmärttämättömältä

Minä ymmärrän ohjelmoinnin erittäin hyvin kun sitä työksenikin teen.

Katsos kun minun tekemät ohjelmistoprojektit onnistuu ja ohjelmat toimii.