"X Error: BadWindow" - debuggaus
selvittäessäni oman ohjelmani vikaa debuggerilla (Kylix3:n IDE:n integroitu debuggeri), huomasin lopuksi komentorivi-ikkunassa (rxvt, bash) riveittäin allakuvatunlaisia virheilmoituksia.
Oman ohjelmani vika ei liittynyt käyttöliittymään mitenkään vaan säikeisiin. Oma ohjelmani ei kirjoittele säikeistä käsin käyttöliittymään (GUI) joten ainakaan tuon ei pitäisi olla vian syynä.
Jäin vain miettimään, ovatko nuo em. virheet oman ohjelmani vai Kylix3:n ja sen integroidun debuggerin aikaansaannoksia.
Kylix3 IDE perustuu ilmeisesti pitkälti Delphistä lainattuun koodiin, jota ajetaan Kylixiin tiukasti integroidun Borlandin räätälöimän WINEn alaisuudessda.
Sensijaan Kylixillä tehdyt ohjelmat ovat puhtaasti Linux -ohjelmia, eivätkä tarvitse WINEä toimiakseen. Kylixillä tehdyt GUI -ohjelmat perustuvat QT 2:een, ja siksi Kylix3 -ohjelmat (jos ovat GUI -ohjelmia, komentoriviohjelmat ja daemonit ovat poikkeus tästä) tarvitsevat libborqt-6.9.0-qt2.3.so -dynaamisen linkkikirjaston toimiakseen.
Tämä .so sisältää siis sekä QT2:n (joka voi olla olemassa samassa koneessa samanaikaisesti mahdollisen uudemman QT:n version kanssa; tämä ei ole ongelma), että yhteensopivuuskerroksen, jonka ansiosta QT2 on Kylixillä tehtyjen ohjelmien käytettävissä.
Tällainen yhteensopivuuskerros on tarpeen, jotta Delphi -kieliset ohjelmat voisivat käyttää QT:tä (joka on C :lla koodattu). Käsittääkseni vastaavanlainen yhteensopivuuskerros tarvittaisiin silloinkin, jos C :lla tehty ohjelma A pitäisi pystyä käyttämään C :lla tehtyä kirjastoa B, mutta ohjelman A tekijällä EI olisi käytössään kirjaston B lähdekoodeja, eikä edes samaa C -kääntäjää voi siis olla joko esim. eri versio gcc:stä, kuten linuxissa yleisesti, tai sitten kahden eri tekijän C kääntäjä).
Eikös C -luokkien yhteensopivuus binääritasolla (siis kun .so -kirjasto exportoi luokkia, joita ohjelma sitten importoi) ole kääntäjä -ja kääntäjäversiokohtainen asia, eli jotta tuollainen olisi mahdollista ilman erillistä yhteensopivuuskerrosta, niin silloin sekä .so -kirjasto että ohjelma on käännettävä saman C -kääntäjän samalla versiolla (siis yleisesti, poikkeuksena toki tilanne jossa esim. saman kääntäjän 2 peräkkäisen version välillä binäärirajapinta ei muutu; tähän ei kuitenkaan yleisetsi voi luottaa vaikka asia jossain yksittäistapauksessa näin olisikin).
Miksiköhän Linuxissa ei oteta käyttöön windows -puolella tuttuja interfaceja, jotka ovat ohjelmointikieli- kääntäjäversio- ja muista vastaavista yhteensopivuuspulmista vapaita?
Interfaceissahan sääntönä on, että kerran julkaistu interface pysyy aina. Uudemmissa versioissa sisäinen toteutus voi muuttua ja voi julkaista uudemman version interfacesta, mutta uudemmalle versiolle annetaa aina eri nimi, ja vanha on ja pysyy - yhteensopivuuden takaamiseksi.
Sinänsä nuo virheet ilmeisesti ovat aika tavanomaisia, ainakin itse saan noita usein ajaessani KDE -käyttöliittymän mukana tulleita apuohjelmia (esim: Konqueror, KWrite, Kate jne.) IceWm -ikkunamanagerin alaisuudessa.
----- VIRHELOKI: -------
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 18
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 25
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 18
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 25
------------------------
selvittäessäni oman ohjelmani vikaa debuggerilla (Kylix3:n IDE:n integroitu debuggeri), huomasin lopuksi komentorivi-ikkunassa (rxvt, bash) riveittäin allakuvatunlaisia virheilmoituksia.
Oman ohjelmani vika ei liittynyt käyttöliittymään mitenkään vaan säikeisiin. Oma ohjelmani ei kirjoittele säikeistä käsin käyttöliittymään (GUI) joten ainakaan tuon ei pitäisi olla vian syynä.
Jäin vain miettimään, ovatko nuo em. virheet oman ohjelmani vai Kylix3:n ja sen integroidun debuggerin aikaansaannoksia.
Kylix3 IDE perustuu ilmeisesti pitkälti Delphistä lainattuun koodiin, jota ajetaan Kylixiin tiukasti integroidun Borlandin räätälöimän WINEn alaisuudessda.
Sensijaan Kylixillä tehdyt ohjelmat ovat puhtaasti Linux -ohjelmia, eivätkä tarvitse WINEä toimiakseen. Kylixillä tehdyt GUI -ohjelmat perustuvat QT 2:een, ja siksi Kylix3 -ohjelmat (jos ovat GUI -ohjelmia, komentoriviohjelmat ja daemonit ovat poikkeus tästä) tarvitsevat libborqt-6.9.0-qt2.3.so -dynaamisen linkkikirjaston toimiakseen.
Tämä .so sisältää siis sekä QT2:n (joka voi olla olemassa samassa koneessa samanaikaisesti mahdollisen uudemman QT:n version kanssa; tämä ei ole ongelma), että yhteensopivuuskerroksen, jonka ansiosta QT2 on Kylixillä tehtyjen ohjelmien käytettävissä.
Tällainen yhteensopivuuskerros on tarpeen, jotta Delphi -kieliset ohjelmat voisivat käyttää QT:tä (joka on C :lla koodattu). Käsittääkseni vastaavanlainen yhteensopivuuskerros tarvittaisiin silloinkin, jos C :lla tehty ohjelma A pitäisi pystyä käyttämään C :lla tehtyä kirjastoa B, mutta ohjelman A tekijällä EI olisi käytössään kirjaston B lähdekoodeja, eikä edes samaa C -kääntäjää voi siis olla joko esim. eri versio gcc:stä, kuten linuxissa yleisesti, tai sitten kahden eri tekijän C kääntäjä).
Eikös C -luokkien yhteensopivuus binääritasolla (siis kun .so -kirjasto exportoi luokkia, joita ohjelma sitten importoi) ole kääntäjä -ja kääntäjäversiokohtainen asia, eli jotta tuollainen olisi mahdollista ilman erillistä yhteensopivuuskerrosta, niin silloin sekä .so -kirjasto että ohjelma on käännettävä saman C -kääntäjän samalla versiolla (siis yleisesti, poikkeuksena toki tilanne jossa esim. saman kääntäjän 2 peräkkäisen version välillä binäärirajapinta ei muutu; tähän ei kuitenkaan yleisetsi voi luottaa vaikka asia jossain yksittäistapauksessa näin olisikin).
Miksiköhän Linuxissa ei oteta käyttöön windows -puolella tuttuja interfaceja, jotka ovat ohjelmointikieli- kääntäjäversio- ja muista vastaavista yhteensopivuuspulmista vapaita?
Interfaceissahan sääntönä on, että kerran julkaistu interface pysyy aina. Uudemmissa versioissa sisäinen toteutus voi muuttua ja voi julkaista uudemman version interfacesta, mutta uudemmalle versiolle annetaa aina eri nimi, ja vanha on ja pysyy - yhteensopivuuden takaamiseksi.
Sinänsä nuo virheet ilmeisesti ovat aika tavanomaisia, ainakin itse saan noita usein ajaessani KDE -käyttöliittymän mukana tulleita apuohjelmia (esim: Konqueror, KWrite, Kate jne.) IceWm -ikkunamanagerin alaisuudessa.
----- VIRHELOKI: -------
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 18
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 25
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 18
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 25
------------------------
Vastaukset 1
Vanhimmat
"Miksiköhän Linuxissa ei oteta käyttöön windows -puolella tuttuja interfaceja, jotka ovat ohjelmointikieli- kääntäjäversio- ja muista vastaavista yhteensopivuuspulmista vapaita?"
Suosittelen tutustumaan GTK :aan! Sille on aktiivisesti kehittyvä "natiivi" IDE:kin. Miksi lisätä ylimääräistä kerrosta, jos toimiva on jo olemassa?
http://www.gtk.org/bindings.html
http://anjuta.sourceforge.net/
Ja miksi tuoda Windows 98:sta totuttuja käytäntöjä Linuxiin, jos tarkoitus on kehittää uutta ja parempaa?
Virheilmoitukset kumpuavat todennäköisesti sieltä Kylixin kirjastoista. Ainakin vanhempien Delphien kirjastoja tarvitsi aina välillä puukottaa, mikäli halusi hommat toimimaan. Oikeesti siellä oli välillä ihan uskomattomia bugeja...