Komponentų karas

Komponentai dabar madingas žodelis ir juos kuria visi, kas tik netingi. Jų "pasigauti" galima visur, - pradedant "Internet" tinklu ir jame klaidžiojančiais "ActiveX" bei "Java" komponentais, baigiant taikomąja programine įranga su bendro naudojimo DLL. Bet ar visada jie dera su kitais savo "genties" atstovais bei sistemine terpe?

Dabar "Windows" komponentų kūrimo naujausias vėjas yra bendro naudojimo DLL. Tai neturėtų stebinti, nes programuotojai visada troško vieną kartą parašyti reikalingą funkciją, o po to ją naudoti. Ir šią galimybę "Windows" terpę atnešė jau savo gimimo akimirką. Tačiau gana greitai pasirodė ir "ragiukai".

Pirmiausia, DLL tvanas "System" kataloge - ten jų kiekvienas rasite jau po kelis šimtus ir jas visas sužiūrėti jau nemaža problema. Geriausias patarimas - nekišti ten nosies ir nebandyti pačiam daryti tvarkos. Bet yra ir kitų nemalonių širdžiai akimirkų, kurias pasistengsime peržvelgti greitai bėgdami.

  1. Senesnės DLL kartais pakeičia naujesnes versijas.
    Taip atsitinka, kai programuotojai niekad nežino, ar kliento kompiuteryje ("System" kataloge) jau yra reikalingos DLL bylos ir Bet kartais klientas gali jau turėti naujesnę DLL versiją, gautą su kita programine įranga. Tvarkinga diegimo programa turėtų patikrinti kompiuteryje esančių DLL versijas, bet ne visos elgiasi "sąžiningai". Žinoma, naujai diegiama programa šiuo atveju veiks, bet gali nustoti veikti kai kurios anksčiau įdiegtos programas.

  2. Naujesnės versijos pakeičia senesnes.
    Mūsų begalinis optizizmas yra manyti, kad naujoji versija yra visad geresnė. Tačiau naujosios versijos atsineša naujas klaidas arba naudoja šiek tiek kitą sąsają. Tad vartotojas, neįkeldamas tos senesnės versijos, kurią gavo kartu su iškviečiama programa, gali pradėti sapnuoti nakties košmarus.

    Pavyzdžiui, bandant diegti "Microsoft" firmos "Publisher 97" versiją, dieegimo programa "mirs" iškart, jei kompiuteryje jau yra įdiegta naujesnė MSVCRT40.DLL byla.

  3. Šalinimo programa gali panaikinti bendro naudojimo DLL.
    Programa, šalindama save, šalina ir visas su ja susijusias bylas. Tačiau ji, nežino, ar kurios nors DLL nenaudoja kita programa. "Microsoft" firmos šalinimo programas tikrina skaitliuką, pagal kurį nustato, kiek programų naudoja tą ar kitą DLL. Ji šalinama tik tada, jei sistema nusprendžia, kad kompiuteryje neliko programų, galinčių nudoti šalinsimą DLL.

  4. "Windows" terpė priversta saugoti svarbias bylas.
    Kai kurios svarbios DLL bibliotekos yra perrašomos į "SysBckup" katalogą. "Windows" įkėlimo metu yra šios kopijos patikrinamos su bylomis "System" kataloge. Ir jei randama skirtumų, "System" kataloge atstatomos ankstesnės DLL versijos. Pvz., galiye į "System" katalogą įrašyti naują WINSOCK.DLL bylą, bet kitą kartą įkėlus "Windows" terpę, ankstesnė byla atgis, kaip feniksas iš pelenų.

  5. DLL gali nesutarti tarpusavyje.
    Yra nekokybiškų DLL, - toks jau gyvenimas. Reikia stengtis vienu metu nedirbti su programomis, naudojančiomis konfliktuojančias DLL.

  6. DLL vardai gali sutapti.
    Programuotojai stengiasi visas DLL talpinti į "System" katalogą, nors "Microsoft" reikalauja, kad į ten būtų įrašomos tik bendro naudojimo bibliotekos. Nors naujosios "Windows" 32-ių bitų terpės ir leidžia naudoti "ilgus" vardus, juos naudoti vis dar vengiama, nes norima palaikyti suderinamumą su 16-os bitų programų versijomis. Be to, programų bylos gali būti saugomos tinkluose, kurie leidžia tik 8.3 bylų vardų formatą. Bet tada nėra daug variantų geriems vardams sukurti ir skirtingi programuotojai gali byloms duoti tuos pačius vardus, pvz., SERVER.DLL.

  7. DLL gali būti įkeliamos ne pagal tas taisykles, kurias aprašo "Microsoft".
    "Microsoft" tvirtina, kad 32-ių bitų DLL įkeliamos pagal jų visą kelią, o ne pagal jų vardą ir kad nėra problemų, jei turime dvi DLL bylas tuo pačiu vardu, bet skirtinguose kataloguose.

    Tai teorija, o ji juk - "sausa šaka". Gyvenimas rodo kitokius dygliukus. Egzistuoja du DLL įkėlimo būdai. Įprastiniu atveju yra naudojama "stub" funkcijų ryšių biblioteka ir DLL įkeliama pagal "trumpąjį" vardą. Prieš įkeldama naują DLL, "Windows" terpė patikrina, ar atmintyje nėra DLL su tokiu pat vardu. Galima DLL funkcijas kviesti pagal visą jos kelią, jei ta "stub" biblioteka įjungta kompiliavimo metu.

  8. DLL, turinčios tą pačią versiją, gali skirtis.
    Nėra bendrų taisyklių DLL versijos numerio keitimui. Ir net "Microsoft" firma "išleido" gerą tuziną skirtingų DLL kompiliacijų ("builds"), turinčių tą patį versijos numerį. Tad ne visad pagal versijos numerį galima nustatyti, ar jau ištaisytos kai kurios klaidos, ar ne.

"Microsoft" neneigia, kad čia nėra problemos, bet niekas nepagerės net ir atėjus "Windows 98" erai. Ši firma labiau rūpinasi, kad galėtų kitų firmų gaminians suteikti teisę prisiklijuoti lipduką "skirta "Windows" terpei", bet programų diegimo srityje teparuoštos tik rekomendacijos, bet juk ne visi jas gerai supranta ar jų aklai laikosi. Pagak šias rekomendacijas kitų, o ne "Microsoft" firmos DLL talpinimas "System" kataloge bus šių rekomendacijų pažeidimas. Komponentai, skirti naudotis bendrai, turi būti susegti į "Common Files" aplanką. DLL, kurias naudoja tik pati programa, turi būti saugoma jos kataloge.

"Windows 98" turės "System Files Checker" programą, kuri tikrins sistemos ir tas bylas, kurias jai nurodys vartotojas, bylas ir saugos, kad jos nebūtų pažeistos.

NT 5.0 pažengs toliau į priekį. Programuotojui nereiks daugiau bandyti laimės ir likimo diegiant naujas programas. "Tvarką padarys" sisteminė diegimo valdymo programa, dabar turinti darbinį "Darwin" vardą. "Darvinui" į rankas įdėsime tik bylą su diegimo instrukcijomis.

Kitas pakeitimas susijęs su DLL grupavimu. Dabar, platinantt programą, su ja reikia pateikti ir megabaitus sistemos duomenų. Pradėjus pardavinėti NT 5.0, kad ketvirtį bus pateikiamas komponenčių paketas su naujausiomis sistemos komponentų versijomis. O "Darwin" yra "nulinio administravimo" plano, įvesto prieš metus, viena iš sudedamųjų dalių. Tinklo administratoriai galės "užrakinti" vartotojo kompiuterio "System" katalogą, kad jie ten nieko negalėtų pakeisti.

DLL susipjovimai, iš kitos pusės, buvo neišvengiama dabartinio modulinio programavimo pasekmė. Dabartinis "Microsoft" skatinimas migruoti nuo "grynų" DLL į COM modelį, kai kurių specialistų nuomone, galės tik sumažinti situacijos valdymo galimybes, nes COM modelis nenumato jokios versijų kontrolės. Jame kiekviena sąsaja yra griežtai specifikuojama, jai priskiriamas unikalus GUID ("Globally Unique ID") numeriukas ir po to ši sąsaja jau nėra keičiama. Tačiau niekas neapgina skirtingų sąsajos realizacijų.

Dabar "Microsoft" sukūrė daugelį plačiai naudojamų COM sąsajų. Vėliau jos, pataisius išryškėjusias klaidus, bus platinamos su naujais GUID'ais. Tad šiokie tokie žingsniai daromi, kad apsaugoti vartotojus nuo DLL pragaro juodųjų gelmių. Gal ateis ta šviesi ateitis, kai komponentams galėsime drąsiai žvelgti į akis.

Truputis sekso?
Pagrindinis Vartiklio puslapis