Newsgroup: it.comp.programmare.win32
Titolo: Sequenza di ricerca DLL

Perché tutti ci riescono e io no?
Vabbè, mi spiegherò meglio :-)
Ho creato un tale mainexe.exe che richiede, per funzionare, una tale
support.dll. La dll non viene acceduta tramite LoadLibrary, ma in mainexe.exe
viene linkato il .lib che si occupa del collegamento con essa. E preferirei
che questo fatto fosse una costante, non una variabile :-)
Non ho problemi se il file exe e la dll sono nella stessa directory. Se sposto
uno dei due, l'exe non si avvia più (e mi sembra anche giusto). Ora, dato che
la DLL dovrebbe essere condivisa fra molti miei programmi, la vorrei mettere
in C:\Programmi\File Comuni\MieiProgrammi\System (o SharedDll o qualcosa di
simile).
Il problema è che non ci riesco! La dll non viene trovata, e va bene, ma non
so nemmeno come dirgli di trovarla!
Dall'SDK sono venuto a sapere che le dll vengono ricercate nella directory
dell'exe che le vuole, nella system (o system32), nella dir di windows, e
nelle dir del path. Non volendo, io, metterle in nessuna di esse, non so come
specificare a windows di andare a cercare anche in File Comuni. O meglio, non
so come farlo senza modificare il path nell'autoexec.bat (orrore!).
Ho in realtà trovato un sistema, che però mi sembra molto precario. Windows
permette di aggiungere "temporaneamente" al PATH alcune directory
automaticamente, in base al file exe che viene eseguito. Se in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths
aggiungo la chiave "mainexe.exe" (perché così si chiama il mio file exe),
nella quale aggiungo la stringa "Path" con valore "C:\Programmi\File
Comuni\MieiProgrammi\System", ogni volta che io avvio mainexe.exe viene
aggiunta questa cartella al PATH che il file exe vede, permettendogli di
trovare la dll e risolvendo il mio problema.
Però lo vedo molto precario! Inoltre, se più exe vogliono la stessa dll,
dovrei comunque registrare ogni exe in quella chiave del registro. Se dovesse
perdersi una voce o dimenticarmi io di registrarla, addio, la dll viene persa
nei meandri dell'hard disk.
Non esiste una chiave che funziona "al contrario", ovvero io scrivo il nome
della dll e dove si trova, invece del nome del file exe, così windows, quando
qualche programma non conosciuto a priori la richiede, sa dove trovarla?
O un meccanismo simile?
PS.
Immagino che, via COM, il problema si risolverebbe. Onestamente non so bene
come viene funziona a livello di file e directory, ma immagino che "registro"
la dll che mi fornisce determinate interfacce, io poi chiamo quelle e windows
si preoccupa di andare a vedere in quale exe o dll sono implementate. Lo so
che non funziona così semplicemente, ma, usando COM, sarebbe la strada
teoricamente più pulita?
--
Stefano Pettini
Risposte solo sul newsgroup, please.

 teoricamente più pulita?
Si` che funziona cosi` semplicemente, ed e` in effetti la strada piu`
semplice, direi anzi l'unica:-).  Per ogni coclass contenuta nella DLL,
nel registry sotto HKCR\CLSID, alla chiave corrispondente alla GUID
di quella coclass, sottochiave "InProcServer32", c'e` tutta la path
della DLL.  Il codice cliente fa una CoCreateInstance specificando
la GUID della coclass (e quella dell'interfaccia desiderata), e il COM
trova la DLL, la carica, fa GetProcAddress per trovare la funzione
DllGetClassObject, la chiama per ottenere un class-object, ne
richiede l'interfaccia IClassFactory, e ne chiama il metodo
CreateInstance, il che finalmente ti da` il tuo ptr-a-interfaccia.
Dal punto di vista del tuo programma e` UNA funzione, quindi e`
sia semplice, sia pulita (immagino che questo faccia digrignare i
denti a chi ritiene che chiamare una API sia di per se "complesso"
perche`, internamente, quella API puo` fare tanto lavoro...:-).
Alex

 Immagino che, via COM, il problema si risolverebbe.
Direi di si`. Li` la risoluzione e` sempre dinamica.
--
Bye! Lorenzo Lutti (
http://www.geocities.com/SiliconValley/Peaks/6258/
)

 hard-wired. :-)
Ops, ero un po' distratto, ovviamente quell'opzione non c'entra nulla con
quello che serve a te. :)
--
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

Ciao Stefano,
sicuramente l'utilizzo delle specifiche COM risolverebbe il tuo problema,
ma non capisco perche' non puoi semplicemente copiare la tua DLL
nella directory di sistema. Neanche a me piace questa soluzione, preferirei
avere il s.o. separato dalle applicazioni, ma tanto le decine di programmi
che installi sul PC, comprese quelle della MS, non si creano questo
problema,
e le directory del s.o. sono sempre pieno di schifezze.
La soluzione piu' rapida rimane quella di copiare le DLL condivise nella
directory di sistema.
ciao, Franco.
--
Posted from [194.184.225.66] by way of 
law2-oe9.hotmail.com
 [216.32.180.113]
via Mailgate.ORG Server - 
http://www.mailgate.org

 semplice, direi anzi l'unica:-).
Non sono esperto di COM, ma mi piacerebbe impararlo. Vorrei creare programmi
un pò "grossi", a questo punto, correggimi se sbaglio, faccio prima ad
imparare le ultime tecnologie che mi migliorano la vita e l'efficienza del
programma, che gli danno la possibilità di "dividersi" in componenti
accessibili da eventuali altri miei programmi, invece di scrivere tutto come
una dannatissima rete di stupidi oggetti MFC, che alla fin fine dovrei
imparare anche loro da quasi 0?


Stefano Pettini <em...@no.grazie> wrote in message
82194d$q9c$1...@aquila.tiscalinet.it...

Domanda un poco lunga, ma secondo me la risposta e` che: si`,
investire su capire e usare COM e` un _ottimo_ investimento; fare
il tuo programma in componenti separabili e` un'_ottima_
architettura, e COM e` uno strumento molto adatto a fare questo.
ATL non ti facilita la vita in termini di realizzazione della GUI del
tuo programma, ahime`; e` sostanzialmente uno "strato sottile"
sopra le API di Windows.  Pur avendo in corso di scrittura un
tutorial sul tema "API di Windows" (l'inizio del draft e` in linea
ad 
http://aleax.supereva.it/
), penso che non siano l'argomento
piu` "urgente" da studiare, da parte di chi deve creare programmi
"un po' grossi".
Piuttosto, ti consiglierei di usare altri approcci all'interfaccia
utente; ad esempio, puoi farla in HTML dinamico (con eventuali
Active/X in supporto), ospitato in una finestra di browser, e
"scriptato" (pilotato) con Python o Perl.  Sempre con Python,
o Perl, puoi anche scegliere di usare il simpaticissimo toolkit
Tk (ne ho usati tanti, ma TANTI, di toolkit e API di GUI, da
XLib via via sino a Java/Swing, ma uno piu` divertente da
usare e programmare non l'ho ancora trovato).  Oppure,
potresti scegliere anche Delphi, o Visual Basic, o Java (con
Swing, o con Microsoft WFC)... grazie al COM che permette
di "ritagliare" i componenti, puoi usare quasi qualsiasi
linguaggio.
Python si presta anche molto a fare da "colla" fra questi
componenti (anche Perl, ma un po' meno; il supporto per
COM di Python e` quasi impeccabile, quello di Perl meno).
E l'ATL, benche` non facilissima da usare, e` un eccellente
modo di mettere assieme componenti COM di elevate
prestazioni.  Ti serve assolutamente un libro, almeno
introduttivo... suggerisco Grimes et al, "Beginning ATL
COM Programming", Wrox Press, come ottima introduzione
all'ATL con un'infarinatura di COM -- con quel che impari
li`, avrai l'infrastruttura per fare tutto quel che ti serve
(piu` un tot di cose, come lo sviluppo di controlli A/X,
che, se non sbaglio, non ti servono) -- gli argomenti
piu` avanzati dell'ATL e del COM, coperti da altri libri
di testo, penso tu possa serenamente risparmiarteli per
ora (ad esempio non hai nessuna necessita` di far altro
che DLL, cioe` serventi in-process, quindi non hai
bisogno di occuparti delle problematiche di security
dell'elaborazione distribuita, ne`, se come penso per
ora non ti serve multithreading "spinto", dei vari
discorsi di "apartment" COM, eccetera eccetera...).
Alex

 directory di sistema.
Può darsi, ma penso che o le metterò li o le metterò in File Comuni e
aggiungerò il path per ogni file exe che le chiama.
PS.
Mi sono dimenticato una cosa! Se dovesse essere una DLL a chiamare un'altra
DLL in un'altra directory, come modificherei il path per questa?


 DLL in un'altra directory, come modificherei il path per questa?
Dipende se la prima DLL la carichi normalmente, oppure
col flag LOAD_WITH_ALTERED_SEARCH_PATH dell'API
LoadLibraryEx (il tuo linker puo` essere o meno in grado
di inserire l'equivalente di questo flag nelle istruzioni di
caricamento presenti nell'exe o dll che carica la prima
dll automaticamente...).  Nel primo caso la DLL usa gli
stessi directory del modulo che la sta caricando, nel
secondo sostituisce "il proprio" -- ma solo se sta venendo
caricata a sua volta con una path esplicita (in pratica,
questo fa comodo al Service Control Manager del COM,
ma non mi pare che aiuti te, nel caso in cui ti trovi).
Cominci a capire perche` un po' tutti, o usano il COM, o
sbattono le proprie DLL nei directory di sistema...?-)
Alex