Úgy látom, ti is nagyon "szeretitek" a MikorSzopsz WinFos biztonságtechnikai intézkedéseinek a hiányát.
Én a programjaim kezelésére KillProgsot használok, szerintem az egyik legjobb. Nulla procit eszik, röhejesen kevés memóriát és még kevesebb lemezterületet foglal, és minden ismeretlen programot két kattintással VÉGLEGESEN le tud törölni, vagy automatikus tisztításra állítva tetszőlegesen rövid időn belül kipusztít mindent, amit nem ismersz.
Találtam benne baró reigstry szerkesztőt is speckósan az induló programok listájára állítva.
Nekem nagyon bejött, a maguktól letöltődő trójai marhaságokat még azelőtt letörli hogy teljes egészében le tudna töltődni. Ajánlom nektek is.
A killprogs.on.hu -n van egy freeware próbaverziója, de elég jó az is. Mióta ez megvan, bármilyen weblapra fel merek menni, és nem is kaptam még be azóta semmit.
Ez csak egy kényszerû segédmegoldás a hülye programozók ellen, nem alapvetô koncepció. Még valamikor Amerika felfedezése elôtt, a Win 3.1 idején terjedt el, hogy minden hülye a DLL-jeit a System könyvtárba akarta elhelyezni. Akkor mgé ráadásul nem volt a fájlokban beépített verzióinformáció, és nem volt olyan, a rendszer részét képezô automatikus telepítôrendszer, amely ezeket figyelembe vette volna, tehát egy program simán felülírhatta a frisebb DLL-t egy régebbivel, azzal ô jól elvolt, de egy másik program, akinek a frissebb kellett, rögtön elhalálozott.
A megoldás egyébként rendkívül egyszerû, az ember tartsa ott a fájljait saját magánál, az alkalmazása mellett, ahol neki van rá szüksége, és ne kotorásszon a rendszer fájljai között.
Egyébként volt erre valamiféle satnya magyarázat is, ugyanis sokan használják azokat az ostoba fejlesztôrendszereket (közöttük elsô helyen a Visual Basicet, nem tudom, ma is ilyen-e, de régebben így volt), amely nem fordít be mindent a saját alkalmazásodba, hanem a futásidejû könyvtárát egy DLL-ben magával kell vinnie. És az volt a gondolat, hogy ha a gépeden (és akkoriban nem száz gigákban mérték a lemezeket) van öt VB-ben írt program, akkor miért legyen öt másolat ugyanarról a DLL-rôl. Csak éppen ott is voltak a különféle verziók, és így tovább.
Magának a Windowsnak is van egy ilyenje (mint ahogy a Linuxon is libc és libc++), az rendben van, arra a programozó mindig számíthatott, mert a rendszer része. Erre a Visual Basic vacakra és társaira viszont nem, ezért telepítgette mindenki agyon vele a System könyvtárat.
Amúgy arra is megvan a lehetôség, hogy ha egy gyártónak több programja használ közösen egy programrészletet (pl. helyesírásellenôrzést vagy ilyesmit), akkor a Program FilesCommon Files alatt nyithat magának egy könyvtárat, és oda pakolhatja, aztán bármelyik programja ott megtalálja. Természetesen a telepítô kötelessége ezt kitakarítani, ha a felhasználó eltávolítja a programot.
Végeredményben ugyanott vagyunk, mit egy körrel elôbb: a Windowsban (a profi vonalon, az NT-én, a 95/98/ME nem számít, az játékra és otthoni felhasználásra volt csak jó) már évek óta valójában ugyanúgy megvan a lehetôség, de a szigorúság sokat késett, és ezalatt a fegyelmezetlen programozók sok bajt okoztak, amit már nem lehetett egykönnyen kijavítani: a késôn jövô szigorúság már nem tudja meg nem történné tenni a dolgokat.
Ezt egy picit lassabban és részletesebben, hogy én is megértsem! :) Egyébként ha ez megoldott dolog, miért nem használják? A fejlesztőeszközök miért nem ezeket az elnevezéseket kínálják fel default? Az ember - ide értve a programozót is - alapvetően lusta lény. Nem véletlen, hogy Linuxon a megfelelő helyre kerülnek a dolgok, a default prefix a /usr/local, tehát azért kell plusz paramétert megadni, ha a rendszer dolgai közé vagy a disztribúcióhoz csomagban adott alkalmazások közé pl. a /usr-be szeretnél valamit telepíteni.
Ha lenne egy valamiféle emulált windows könyvtár, ami alá a Microsoft által alá nem írt kacatok kerülnek és ami mindenestől kitörölhető lenne, anélkül, hogy az outlook-ot vagy az excel-t baj érné, na az lenne a gányolásbiztos windows :)
A könyvtárstruktúra régi és bevált, és a Windowsban is mûködik. Még talán azt is el lehetne érni, hogy az alapbeállítások megfelelôek legyenek. A legfôbb akadály a programok maguk: valamék Windowsos topikban épp most panaszkodott valaki, hogy egy program a System könyvtárba akarja a konfigurációs fájlját elhelyezni, és a rendszer fügét mutatott neki, egyébként nagyon helyesen. De ilyenkor mit lehet tenni? Ha a felhasználónak kell az a program a munkájához, akkor fel fogja lazítani a szigorú szabályokat, és be fogja engedni, mert mi a fenét tegyen?
Valahol a dolog két forrásból táplálkozik (leszámítva most azt az alapvetô tényt, hogy a Unix alapfelépítése jobb, ez közhely). Linuxra, mivel nehezebben adja magát, alapvetôen profik írnak programot, gcc, Makefile, config szkriptek, satöbbi, és ôk betartják a szabályokat. Windowsra meg írhat bárki, nesztek Visual Basic, Delphi és társai. A szabályok ugyanúgy le vannak fektetve, hogy hol kell egy programnak tárolni az adatait és úgy egyáltalán hogyan kell viselkednie, tíz éve pontosan le van írva az MSDN-ben. Aki ért hozzá, be is tartja, de a többség még csak nem is hallott róla, a nagyok, akiknek meg kell a MS-tól a plecsni, még akkor is rákényszerülnek, ha ôk sem tudnák jobban.
A Microsoft pedig, szerintem is ostoba módon, lassan szigorít csak a feltételeken, mert valóban köti a visszafele kompatibilitás. Nem olyan ostoba módon értve, mint ahogy szóba került, hogy DOS futna a Windows alatt ma is, hanem hogy kompatibilis kell maradni a rosszul viselkedô programokkal. Nem feltétlenül a kód, hanem a viselkedés szintjén.
Én biztos gyorsabb lennék, és a rosszul viselkedô programokra tiltással válaszolnék, szép piros hátterû üzenettel, hogy "Kedves felhasználónk, kérjük, jelezze a program készítôjének, hogy tanulmányozza át a Windows alá történô programfejlesztés dokumentumait, Önnek meg barátságosan javasoljuk, hogy ne tegye számítógépe épségét kockára egy ilyen megbízhatatlan, inkorrekt program használatával!"... :-)
"Igazság szerint nem tudom, hogyan lehetne megoldani."
Hát, szerintem, baromi egyszerűen. Kell egy rejtett Windows könyvtár, amibe csak a "system" nevű folyamat írhat, meg kell egy virtuális Windows könyvtár, amibe mindenki azt gányol, amit akar és akár mindenestől le lehet törölni. Ilyenkor a rencer létrehozza ismét. Üresen.
Szerintem nem lenne egy nagy kaland. A "biztonságos" programok a rejtett Windows alá települnek, a nem biztonságosak meg a virtuális alá. Így egy törlés után nem veszne el az excel + outlook (levelek) csak a gagyinyomtató drivere és az extramega codec csomag.
Az már nem hangzik olyan rosszul. Linuxon a Gnome is ezt az irányt követi. Amúgy nem tudom megmondani miért, de - s ez szubjektív - az XML-nél is jobban tetszenek az ad-hoc text konfigurációs állományok.
Az egy másik dolog, hogy az ASCII formátum, bár terjengős, de érthető, javítható, debugolható. Nem erre gondoltam ugyan, de ebben is van igazság.
Nem vagyok meggyőzve a registry előnyéről, hiszen ha a sebesség a fontos, a program az ini file alapján RAM-ban feltölthet egy struktúrát, amit aztán gyorsan elérhet bármikor.
Szerintem egy másik gépről kinézni a config file megfelelő bejegyzéseit, majd beleírni az újba némileg egyszerűbb, és kevésbé kockázatos, mint ugyanezt a registry-ben tenni. Pl. xorg.conf-ot mentem, szanaszét hack-elhetem, ha valami nem sikerül, visszamásolom az eredetit, s nem kell attól tartanom, hogy esetleg mellényúlok, s más is sérül.
Persze, ha nem tudod, hol keressél. A teljes registry-ben persze hogy lassú. De a progi a saját részét mondjuk a HKCU\Software\gyártó\Progi részből villámgyorsan ki tudja olvasni.
Nos, nagyon sok okból. A registry az a ketyere, amit a win cache-el (legalábbis részben), ezért a beállítások (főleg a rendszer beállítások) egyrészt gyorsan elérhetők, másrészt egy helyen vannak összegyűjtve. Egy (nem fogod elhinni:) ráadásul jól szervezett, struktúrált, könnyen elérhető (API-kkal) adatbázisban. Struktúrált, szépen le van ez is bontva felhasználói, gép, szoftver, rendszer adatokra-részekre. Alapvetőleg nincs ezzel baj.
Én azt hiszem, hogy Téged valószínűleg a nem könnyen olvasható ASCII szöveg file formátum zavar. Azok az infók, hogy itt mit mi tárol, (mármint a Win magáról stb.) egyébként ugyanúgy nyilvánosak, csak amatőr felhasználó jobb, ha nem piszkálja (ezért is kezdődik minden MS ajánlás azzal, hogy mentsd el mielőtt hozzányúlsz). Sőt, a leggyakrabban érhetőek a kulcsok is, tehát nincsen kódolva...
Ja, nem részleteztem. A "Documents and Settings\Felhasználónév" könyvtár (tudod, ami helyett a C:\Pisitikét használják, mert az jó) megfelel a $HOME -nak, csak itt úgy hivják, hogy %USERPROFILE%. Az alkalmazás tehet ide is adatokat (itt is van egy rejett - mintha ponttal kezdődne - Application Data alkönyvtár), sőt a registry felhasználói tulajdonú része is itt található. Ezen belül van a My Documents is, illetve lehet átirányítva, és itt van egy Local Settings is, ami meg pl. nem megy fel a hálóra, ha a vándor profilt (Roaming Profile) használják. Tehát a programírók nyugodtan kitalálhatnák, hogy mit hová tegyenek, ha nem elég nekik a Program Files\Programnév alatt kapott (rendszerint csak olvasható, mert itt az exe-k vannak, tudod mint a bin-ben) könyvtár.
A baj az, hogy a registryvel legalább annyi az elôny, mint a baj. Sok gondot tud okozni, de nem lehet kismillió önálló .ini vagy .config fájllal helyettesíteni, mert az csak egy része az egésznek.
A mai Linuxot nem ismerem annyira. Van benne bármi olyan, mint a Windowsban a COM? (egymástól teljesen független programok dinamikus interfészt kínálnak egymásnak, és az egyik mûködtetheti a másikat; nem két konkrét, erre a célra megírt programpárosra gondolok, hanem általánosságban). Ez nem megy valami központi adatbázis nélkül.
Ha ez így megy tovább, előbb-utóbb sikerül az MS-nek is eljutnia a $HOME/.alkalmazás könyvtárban vagy file-ban tárolt beállításokhoz. Az a gyanúm, éppen feltalálódik a langyos víz... :)
Miért jó: nem biztos, hogy olyan könnyű megszabadulni tőle. Tehát nyilván nem azért tartják meg mert jó, hanem mert jelen pilanatban nehéz találni valamit, ami helyettesíthetné.
Minek emulálni: egy progi (akár egy vírus is) csak a "saját" registry-jét piszkálhatja ilyenkor. Mondjuk úgy emulálni, mint a Windows mappa dll-jeit a program saját könyvtárában. Kap egy User meg System meg egyéb lokális registry file-t, amit csak ő használ, aztán hadd garázdálkodjon... Át van verve. A Vista simán becsukásnál a nagy kínkeservesen betett Run bejegyzéseket, meg hasonlókat pedig fapofával kitörli. Az ötlet szerintem kiváló.
Való igaz, nem írtam le mindent, amire gondoltam. Tehát arra, hogy a fejekben is rendetlenség van. Amíg a C:\-ben hoz létre magának valaki egy alkönyvtárat a fényképeinek, addig ne nagyon várjunk csodákat.
Ha a registry marad, akkor minek emulálni? És miért jó, hogy marad?
Ez azóta egyszerűsödött, amóta nem a Win9x sorozat van. Ez már nem akar csak úgy kompatibilis lenni, hanem EMULÁLJA a dolgokat, a DOS-t is.
Éppen ezért ilyenből már nem lehet probléma. Ne legyél azért ennyire elmaradva. Az NTVDM az az NT Virtual Dos Machine, a cmd.exe a command.com utódja, stb.
Ez már az NT4 óta így van. Nincs itt semmiféle örökség, amitől ne lehetne megszabadulni.
Még a System könyvtárral (és a Win3.1 alkalmazásokkal) se kellene legyen túl sok baj, meg az .INI file-okkal sem, mert a valami.exe.local file alkalmazásával a programok az oprendszer által átverhetők (a program saját könyvtárából vett DLL-ek úgy futnak, mintha a Windows vagy System könyvtárakban lennének). Ez Win2K óta van így. Hányan tudják? Ki a hibás? Sőt, XP óta a .manifest még az eredetileg nem XP alá tervezett kinézetű programokat is képes egységes kinézetűvé hozni.
De most éppen a Windwos guru topicon éppen olyat kérdezett valaki, hogy most akar DOS ablakos programot írni, mit csináljon hogy a karakterek (volnalrajzoló kvázigrafikus) egyformán nézzenek ki full screen-ben, meg kis ablakban? Szerintem úgy, hogy ne írjon DOS-os programot a XXI. században. De nyilván én vagyok a bunkó.
A registry-vel kapcsolatban el kell keserítselek, marad. De a Vista még majd azt is valami az előzőekhez hasonlóan fogja tudni "emulálni" a prgramok számára.
Az MS oprendszerek egyik gyötrelme a visszafelé való kompatibilitás. Mivel a Windows az elején a DOS grafikus frontend-je volt, ebből származik egy csomó probléma. Mert lettek windows-os alkalmazások, az új operációs rendszeren pedig azoknak is futniuk kellett. Ettől az örökségtől nem nagyon tud szabadulni az MS. Nem tudom, hogy a registry-től meg akar-e válni, szerintem nagy előrelépés lenne az is.
A szigorú könyvtárstruktúra sokat segít. Ha utánagondolsz, tulajdonképpen a Windowson is kialakult mára egy ilyesmi, csak az otthoni rendszereken (9x/ME, és sajnos, XP Home) nem lehet betartatni, csak XP Protól kezdve. Ott meg egyrészt a rendszergazdán múlik (még akkor is, ha egyetlen, saját géprôl van szó), meg, persze, a programokon is. Nagyobb programoknál, amelyek Designed for XP címkét kapnak az MS-tôl, sok minden között éppen ezeket ellenôrzik: a program a helyére (akárcsak a bin), saját könyvtárba, Systembe semmit nem pakolhat, többfelhasználós rendesen használja a többfelhasználós lehetôségeket (akárcsak az usr/home), és így tovább. De a sok kis ilyen-olyan programokkal nem tud mit kezdeni, mert ha igazán szigorúan venné, akkor azok többet nem futnának.
Igazság szerint nem tudom, hogyan lehetne megoldani. Valami technikai trükk kellene, hogy Setup.exe-stílusú telepítôk ne futhassanak (például lezárni elôlük a rendszerkönyvtárakat), mindenki köteles legyen a Windows Installert használni, és ott pedig meg lehet fogni a hibás dolgokat.
Józan ésszel nem is lehet érteni, de itt arról van szó, hogy a hozzá nem értônek egy film valamiért nem indul el, és az osztálytársa (vagy a fia osztálytársa) azt mondta, hogy ilyenkor tegye fel a Giga Mega Super Ace Acme Code Packet, mert abban minden benne van, ami valaha is csak kellhet (jó eséllyel, persze, a harminc codec mellett negyven trójai is), és felteszi. De legalább van egy kis pénzkeresetük azoknak, akikhez ilyenkor elviszik megjavítani a gépet, ne sajnáld tôlük... :-)))
