Newsgroup: it.comp.programmare.win32
Titolo: Perché registrare le DLL

Ho notato che i programmi di istallazione sono soliti registrare le
dll che istallano. Perché? Non è forse necessario buttarle in
WINDOWS\SYSTEM per farle funzionare?
Eppure IN ALCUNI CASI, che non ho ancora capito bene quali (ad esempio
mi sembra nel caso degli OCX) se non si registrano con regsvr32, non
funzionano.
Qualcuno mi sa spiegare a che serve registrare i componenti tipo DLL,
OCX, ecc. e soprattutto che significa? verranno inserite delle chiavi
nel registro di configurazione? che informazioni apportano al sistema
queste chiavi?
MadMage

queste chiavi?
I componenti OCX che risiedono in DLL sono server COM in-process.
Vengono registrati nel sistema i loro GUID, perche' possano essere
richiamati i loro metodi.

 dll che istallano.
forse sono delle DLL ActiveX
--
ciao
xAERO

WINDOWS\SYSTEM per farle funzionare?
Si, buttiamo tutta la me**a in windows\system....
Le DLL 'personalizzate' di un programma se ne devono stare assieme ad
esso!
Luc.

esso!
Perche' ?



Perchč, per esempio, se mi voglio installare un programma sulla
partizione D:\ perchč C:\ č quasi piena e questo programma ha grosse
DLL 'personali' voglio che non mi vadano ad intasare C:\
Sono cosi anche sicuro che non ci siano problemi di dll con lo stesso
nome...
Il concetto penso sia semplice, ed č un punto fermo nella nostra
software house.
Luc.

software house.
Mah, io non credo che sia cosi' importante, onestamente.
D'altronde, basta confrontare le cose con un sistema coerente come
Unix, in cui le librerie sono centralizzate.
La possibile collisione dei nomi mi sembra cosi' improbabile da non
prenderla neanche in considerazione.
Secondo me, avere un punto di riferimento in cui installare le DLL e'
comunque piu' utile. Tra l'altro, parlare di DLL 'personali' e' una
contraddizione in termini. La "dinamicita'" di queste librerie
consiste proprio nel consentire a piu' programmi (nonche' al sistema)
di farne uso e quindi e' piu' utile posizionarle in una "terra
franca", come la directory di sistema. E' il mio punto di vista,
chiaramente ;)

 chiaramente ;)
si, ma guarda che anche se la DLL è già caricata in memoria, e tu cel'hai
nella dir del prog (e win cerca di usare per prima quella), vengono
confrontate, e se uguali viene usata quella già caricata in memoria
--
ciao
xAERO

confrontate, e se uguali viene usata quella già caricata in memoria
Sto dicendo che le DLL sono, per principio, qualcosa di "comune" ed e'
quindi piu' corretto che siano poste in un luogo "comune".

quindi piu' corretto che siano poste in un luogo "comune".
Non le DLL con le risorse localizzate, ad esempio... Oppure le DLL che
risultano comuni soltanto a vari pacchetti software della stessa casa
e che non saranno *MAI* utilizzate da programmi di terzi...
Luc.

e che non saranno *MAI* utilizzate da programmi di terzi...
A mio avviso non e' cosi', ma ripeto, e' una questione di gusti
personali, quindi non discutiamone oltre. Secondo me e' giusto avere
un criterio di uniformita'.

 writes:
AL> Mah, io non credo che sia cosi' importante, onestamente.
AL> D'altronde, basta confrontare le cose con un sistema coerente come
AL> Unix, in cui le librerie sono centralizzate.
Beh, gli Unix con supporto  per le shared library le hanno raggruppate
in  alcune  directory  (poche,  i.e.   /lib,  /usr/lib,  /usr/x11/lib,
/usr/local/lib) e non in un solo calderone.
AL> Secondo me, avere un punto di riferimento in cui installare le DLL e'
AL> comunque piu' utile. Tra l'altro, parlare di DLL 'personali' e' una
AL> contraddizione in termini.
Ni. E' vero che lo scopo  delle shared libray e' riparmiare spazio (in
memoria  centrale ma  anche su  disco), ma  è anche  vero  che possono
essere utilizzate per un caricamento del tipo "mi carico il codice che
mi serve, quando mi serve e se mi serve".
\begin{avviso}
 
Attenzione: Leggersi lo header riguardo al mio e-mail!
Warning: read header for infos about my e-mail.
\end{avviso}
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+

 e che non saranno *MAI* utilizzate da programmi di terzi...
giusto.
nella dir system (system32 x nt) ci dovrebbero essere solo quelle poche dll
tipo:
msvbvm60.dll, comctl32.dll, zip32.dll, ecc...
ma vallo a raccontare a billgates e tutto il resto di programmatori... ;-P
--
ciao
xAERO

 Mah, io non credo che sia cosi' importante, onestamente.
E` per colpa di gente come te che la mia directory SYSTEM32 consta di
1674 file per un totale di 236 MB. :-)
Diciamocelo: la directory SYSTEM e` una cosa del tutto obsoleta,
retaggio di un passato in cui soltanto la Microsoft scriveva vere
applicazioni per Windows. Ormai io riserverei SYSTEM solo per i file di
sistema (ma va? :-)), mentre per i programmi normali farei (anzi,
faccio) cosi`:
-Se la DLL la usa un solo programma (esistono diversi casi in cui e`
necessario e/o utile scrivere una DLL anziche` mettere il codice
direttamente nell'EXE), e` giusto metterla nella directory del
programma. Questa prassi e` migliore anche in tantissimi altri casi: a
chi non e` mai capitata un'applicazione maleducata che sovrascrive delle
DLL in SYSTEM con delle versioni piu` vecchie? Sarebbe bastato che la
vecchia DLL fosse stata copiata nella directory del programma, e Windows
l'avrebbe automaticamente usata solo ed esclusivamente per quel
determinato programma;
-Se la DLL viene usata da un gruppo di programmi, si puo` sempre usare
un path comune al difuori della directory di sistema. Le software house
serie lo fanno gia` da anni formando una specie di "standard de-facto",
vedi la directory program files\common files.
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

Stiamo poi dimenticando un altro dei motivi fondamentali per cui, in
windows, bisogna mettere le dll che sono shared in un gruppo di
programmi e non per TUTTI i programmi, in un'apposita dir: la
disistallazione!!!! Perché mi trovo ancora dll di programmi
disistallati? Perché installshield non funziona bene? ma quel
poveraccio che ne sa se una dll è utilizzata o meno?
se la si mette in una sola dir di un pacchetto, quando voglio
disistallare completamente il pacchetto di programmi, alla fine
elimino la dir e sono certo di aver eliminato anche TUTTE le dll che
non servono a nessun altro.
MadMage


ma vallo a raccontare a billgates e tutto il resto di programmatori... ;-P
Non tutti i programmatori sono bravi programmatori... 8)
Luc.

 queste chiavi?
Con la tecnologia .net non ci sarà più bisogno di registrare i componenti in
quanto nei componenti stessi sono presenti i metadati che ne descrivono
l'interfaccia.
Per installare i programmi si ritornerà al mitico "copy *.*".

...


 quello che gli serve, vedi "DllSelfRegisterServer
Non era ancora stato citato.

Secondo me l'ideale sarebbe che il programma di installazione facesse
scegliere all'utente se condividere o meno le dll.
Mi è capitato che un programma all'installazione mi abbia
chiesto se copiare i file nella system o mantenerli nella
directory del programma!
Comunque per me avete ragione entrambi (LL=Lorenzo Lutti e AL=Andrea La
Forgia)
LL= La directory system diventa enorme
AL=Il principio della DLL è proprio la condivisione e il riutilizzo del
codice
                                                                    danilo
 
minerv...@inwind.it
Lorenzo Lutti <lorenz...@DOHtiscalinet.it> wrote in message
news:WMnL5.59349$3K3.1...@news.infostrada.it...


> Non tutti i programmatori sono bravi programmatori... 8)
non tutti i "programmatori" sono programmatori :-D