Blogul lui GunSmoker (traduceri) Povestea lungă și tristă a tastei Shell Folders
. când schimbarea minții devine la fel de ușor ca programarea unui computer, ce înseamnă să fii om.
Povestea lungă și tristă a cheii Shell Folders
Când proiectați o arhitectură a unui sistem de operare, compatibilitatea inversă este unul dintre acele lucruri pe care trebuie doar să le acceptați. Dar cândnoileprogrameîncep să depindă de hack-urilecreate pentru programe vechi, veți dori să vă smulgeți părul. Cu mult timp în urmă, în ceea ce pare a fi o galaxie foarte, departe (vorbesc despre versiunea beta a Windows 95 numită „M3”), am documentat o cheie de registry numită „Foldere Shell” care ar putea fi folosit de programe pentru a obține foldere speciale, cum ar fi folderul „Fonturi” sau „Documentele mele”.
Dezvoltatorii care au primit Windows 95 M3 Beta au urmat documentația și au folosit această cheie.
Apoi, pe măsură ce am continuat să lucrăm pe Windows 95, am realizat că cheia de registry nu era locul potrivit pentru aceste informații. În special, deoarece multe lucruri (de exemplu, Panoul de control) nu sunt foldere reale de pe disc, astfel încât calea către ele nu poate fi scrisă în registry. Și, de asemenea, pentru că am uitat să luăm în considerare o caracteristică a Windows NT numită profiluri de utilizator în roaming - acesta este momentul în care un profil de utilizator se poate muta dintr-un loc în altul, așa că o cale codificată în registry nu va funcționa deloc aici.
De aceea, am creat funcția SHGetSpecialFolderLocation și am actualizat documentația pentru a indica dezvoltatorii să folosească noua funcție pentru a obține foldere speciale. Documentația pentru vechea cheie „Shell Folders” a fost complet eliminată.
Dar pentru a face tranziția de la M3 la RTM mai ușoară, am lăsat vechea cheie „Shell Folders” în registru, darnu mai era un depozit de date reale. Era doar o copie a datelor reale stocate într-un loc complet diferit.
Am lansat Windows 95 RTM cu această cheie „temporară”, deoarece există încă un număr mic de programe (să zicem patru) care nu au fost convertite pentru a utiliza noua caracteristică SHGetSpecialFolderLocation. Dar funcționalitatea acestei chei a fost serios limitată și a fost suficient pentru ca aceste patru programe să funcționeze. La urma urmei, a fost doar un hack pentru compatibilitatea inversă. Toate programele noi au fost necesare pentru a utiliza SHGetSpecialFolderLocation.
Cu alte cuvinte,cheia de registry „Shell Folders” există doar pentru ca patru programe scrise în 1994să poată rula pe versiunea RTM a Windows 95.
Puteți ghici ce s-a întâmplat în continuare.
Și acum avem sute, mii de programe care nu folosesc SHGetSpecialFolderLocation; au citit direct informațiile din „Dosarele Shell”. Ceea ce nu își dau seama este că acest suport cheie „Folders Shell” a fost conceput doar pentru a menține aceste patru programe în funcțiune.
De exemplu, știați că, dacă nu deschideți niciodată folderul Fonturi și niciun program nu apelează vreodată SHGetSpecialFolderLocation(CSIDL_FONTS), atunci nu va exista nicio intrare „Fonts” în tasta „Shell Folders”? Acest lucru se datorează faptului că înregistrările sunt create numai atunci când cineva le solicită. Dacă nimeni nu are nevoie de ele, atunci nu sunt create. Nu are sens să activezi un hack pentru o aplicație până când este necesar.
Desigur, atunci când testați programul, nu vă formatați discul sau nu faceți o instalare curată a Windows 95 și apoi rulați programul. Pur și simplu copiați programul pe o mașină Windows 95 care rulează de câteva luni șiverificați ce se întâmplă cu programul dvs. Ce se întâmplă este că, din moment ce pe o mașină care rulează de câteva luni, cineva trebuie să fi deschis folderul „Fonts” în acest timp, valoarea „Fonts” există și toată lumea este fericită.
În același timp, în laboratoarele noastre de testare a compatibilității cu versiunea inversă, programul tău primește un semn de „eșuat”, deoarece în laboratoarele noastre formatăm computerul înainte de a instala fiecare program pentru a ne asigura că nimic din programele anterioare nu va afecta munca.noul program.
Și apoi echipa de dezvoltare a nucleului este chemată pentru a afla de ce acest program primește un semn de „eșuat” și constatăm că, de fapt, acest program, când este instalat pe o mașină zero,nu a funcționat niciodată.
Întrebare filosofică: dacă programul nu a funcționat inițial, este un bug că nu funcționează astăzi?
Acum, pentru aceia dintre voi care acum vă linge buzele și spun: „wow, există o cheie „User Shell Folders” aici, care este chiar mai tare decât „Shell Folders”, lasă-mă să o simt acum”. Vă îndemn să vă rețineți și să nu vă bazați pe această nouă cheie. Utilizați doar funcția SHGetFolderPath, care returnează calea către orice folder doriți. Fie ca tasta „User Shell Folders” să se odihnească în pace. Pentru că în Longhorn vom face și mai multe chestii cu profilurile de utilizator și, personal, aș fi destul de supărat dacă ar trebui să renunțăm la cheia „User Shell Folders” ca victimă a compatibilității cu versiunea inversă și să mergem la noul „Real”. Folderele utilizatorului”.
Bănuiesc cu tărie că niciunul dintre cele patru programe pentru care a fost creată inițial cheia „Shell Folders” nu mai este utilizat astăzi.