PDA

Visualizza la versione completa : [Delphi] Includere dll in eseguibile


fiffio
14-06-2004, 21:32
Domanda banale banale: esiste qualche metodo per includere librerie all'interno di un eseguibile?

Ad esempio librerie necessarie ad un exe compilato in Delphi...

Grazie.

FiFFiO

alka
15-06-2004, 10:02
Originariamente inviato da fiffio
esiste qualche metodo per includere librerie all'interno di un eseguibile?
Definisci meglio quali sono le tue intenzioni: le librerie (DLL, per intenderci) non posso essere "incluse", cioè compilate, all'interno di un file eseguibile, ma al più possono essere "linkate" come dice il nome stesso.

La Guida in linea presenta le istruzioni necessarie per importare funzioni esterne immagazzinate in DLL all'interno del proprio sorgente, sia in forma statica sia in forma dinamica (la libreria va collegata manualmente).

Con Delphi puoi inoltre creare DLL Win32 da utilizzare per le tue applicazioni o distribuire a terzi.

Ciao! :ciauz:

fiffio
26-06-2004, 16:02
Ciao Alka,
conosco il funzionamento delle dll (un tempo mi spiegasti appunto tu come farle funzionare in Delphi), e ora mi chedevo se esisteva un programma (esterno al Delphi) che prendesse il .exe e la dll e ne facesse un altro eseguibile comprendente i due.

Capisco che il discorso può essere un po' contorto, ma avrei l'esigenza di avere una directory con un solo file .exe e vorrei evitare di dover creare un installer per sistemare, ad esempio le dll all'interno di system32...

Grazie.

FiFFiO

alka
26-06-2004, 16:12
Non credo sia possibile una cosa del genere, poichè ciascun modulo eseguibile costituisce un'entità a parte, contenente riferimenti statici al proprio contenuto.

Tralasciando il fatto che il discorso possa essere contorto o meno, spiega l'esigenza che hai e magari è possibile trovare una soluzione alternativa.

Se la tua preoccupazione riguarda la creazione di un programma di installazione, ci sono ottimi e funzionali tool per realizzarlo, come Inno Setup (http://www.jrsoftware.org/isinfo.php).

Ciao! :ciauz:

fiffio
26-06-2004, 16:30
No, il problema non è la creazione di un installatore, bensì esigenze di natura diversa e delle quali al momento non ne vale la pena discuterne, visto che credo di poter sviluppare la mia idea pure in altre maniere.

Però ho un'altra domanda, sempre su dll:
le applicazioni sviluppate in Delphi necessitano di trovarsi determinate dll nel sistema (nella directory di sistema o nella directory stessa contenente il file eseguibile). Come faccio a conoscere quali dll devo includere? Ci sono maniere per ovviare questa necessità?

Grazie mille per la disponibilità, ciao! :ciauz:

alka
26-06-2004, 16:43
Originariamente inviato da fiffio
No, il problema non è la creazione di un installatore, bensì esigenze di natura diversa e delle quali al momento non ne vale la pena discuterne, visto che credo di poter sviluppare la mia idea pure in altre maniere.
In questo caso, capirai anche tu che risulta un po' difficile aiutarti. :)


Originariamente inviato da fiffio
Però ho un'altra domanda, sempre su dll:
le applicazioni sviluppate in Delphi necessitano di trovarsi determinate dll nel sistema (nella directory di sistema o nella directory stessa contenente il file eseguibile). Come faccio a conoscere quali dll devo includere? Ci sono maniere per ovviare questa necessità?
Generalmente, a meno che non fai uso di piattaforme per l'accesso ai dati (ADO, BDE, ecc.) oppure non utilizzi componenti particolari di terze parti, un eseguibile creato con Delphi è autosufficiente, pertanto non hai alcun bisogno di distribuire alcuna libreria assieme al tuo file eseguibile, tranne quando non fai esplicito riferimento a DLL esterne dichiarandone le funzioni...ma in questo caso, trovare le DLL è semplice poichè sei tu, esplicitamente, che ne fai uso, pertanto devi già sapere a priori quali sono le DLL che devi utilizzare.

fiffio
27-06-2004, 20:23
Ciao, in riguardo alla questione soprastante ho effettuato delle prove con diversi sistemi operativi. Il risultato è sempre stato poco felice. Nei sistemi ove non vi è installato il Borland si sono sempre verificati degli inconvenienti che ora descrivo.

Premetto che in questo caso ho compilato la mia applicazione con il Borland Visual c++ Builder 6.0.
Problemi in avvio applicazione:

"Impossibile avviare l'applicazione specificata. vcl60.bpl non è stato trovato. Un nuova installazione dell'applicazione potrebbe risolvere il problema."

Ma non è il solo! Mancano pure rtl60.bpl, bcbsmp60.bpl, vclx60.bpl, e inoltre pure una dll: CC3260MT.DLL. A questo punto mi chiedo come mai un semplicissimo eseguibile da 45KB debba richiedere svariati MB di librerie e rimpiango un poco il mio prediletto Dev-Cpp con il quale ho sempre avuto ben chiaro cosa il compilatore facesse ed eventualmente da quali files l'applicazione creata dipendesse.

Le piattaforme di sviluppo visuali sono molto comode e molto veloci si, una cosa certo da non sottovalutare, ma pagando a prezzo di memoria e di velocità di esecuzione dell'eseguibile tutta questa semplicità di sviluppo. Quando poi vedo i miei vecchi compilati in assembler (anche con interfaccia grafica), estremamente piccoli in dimensioni e di gran lunga più performanti in velocità, mi chiedo quando (e se) ne valga la pena salire ad un livello di programmazione così alto...

Ora forse è più chiaro come mai nel precedente post non ho ritenuto opportuno descrivere in dettaglio la mia idea, visto che in primo luogo non sono convinto io stesso della piattaforma utilizzata e quindi rendendomi conto di avere dubbi più generali.

Le comodità dell'alto livello comportano degli svantaggi e mi sembra che ciò accade sempre quando è la macchina che si adatta all'uomo. Le cose cambiano invece quando accade il viceversa: l'uomo che si adatta alla macchina (basso livello). In questo caso - e penso all'assembler - le difficoltà diventano enormi, superate le quali però si viene senza dubbio ben ripagati.
Certo che sarebbe pure stupido voler estremizzare tutto in questa maniera, e voler creare programmi tutti in assembler! Da buon ingegnere (quale sono prossimo a diventare) so che si ha il massimo quando si trova il giusto compromesso fra ciò che si vuole ottenere e quanto costa averlo.

La difficoltà che spesso ho è di trovare questo compromesso, causa forse anche del fatto che conosco sin troppi linguaggi di programmazione ma nessuno in tutta la sua completezza.

Per tornare al discorso principale, vorrei dire che al momento non ho esigenze di sviluppare un'applicazione troppo ottimizzata, e avendo scartato l'idea del .NET, ho reputato vantaggioso l'utilizzo del Borland C++ Builder: velocità di creazione delle interfacce grafiche, buona integrazione di componenti visuali e il mio personale gusto per il c++ mi hanno fatto prendere la scelta.

Concludendo, avrei solo da chiedere una cosa circa il dubbio che mi ha portato a scrivere questa (forse inopportuna) riflessione. Vorrei sapere come si possono conoscere le bpl e le dll da mettere nel sistema senza dover ogni volta prendere un altro pc come cavia dei files mancanti.

In questo modo potrò creare gli installer molto più velocemente e il pc-cavia dovrà soltanto confermarmi la corretta installazione e la corretta esecuzione del tutto.

FiFFiO

alka
27-06-2004, 20:45
Originariamente inviato da fiffio
Ciao, in riguardo alla questione soprastante ho effettuato delle prove con diversi sistemi operativi. Il risultato è sempre stato poco felice. Nei sistemi ove non vi è installato il Borland si sono sempre verificati degli inconvenienti che ora descrivo.
Chiaramente, non conoscendo alcun aspetto tecnico del tuo progetto, nonostante i problemi che denuncerai, sara ben difficile cercare di darti una mano a trovare le soluzioni.


Originariamente inviato da fiffio
Premetto che in questo caso ho compilato la mia applicazione con il Borland Visual c++ Builder 6.0.
Lavoro in Delphi, ma tutto funziona allo stesso modo, tranne il linguaggio utilizzato.


Originariamente inviato da fiffio
"Impossibile avviare l'applicazione specificata. vcl60.bpl non è stato trovato. Un nuova installazione dell'applicazione potrebbe risolvere il problema."
Ma non è il solo! Mancano pure rtl60.bpl, bcbsmp60.bpl, vclx60.bpl, e inoltre pure una dll: CC3260MT.DLL. A questo punto mi chiedo come mai un semplicissimo eseguibile da 45KB debba richiedere svariati MB di librerie e rimpiango un poco il mio prediletto Dev-Cpp con il quale ho sempre avuto ben chiaro cosa il compilatore facesse ed eventualmente da quali files l'applicazione creata dipendesse.
Tutto molto molto discutibile. Lavoro in Delphi da parecchi anni, comunque sufficienti per dire che, indipendente dall'ambiente di sviluppo utilizzato, c'è il perchè in ogni cosa. Pertanto, è possibile arrivare a soluzioni apparentemente inspiegabili anche con Dev-Cpp, se non si ha la padronanza dell'ambiente o del linguaggio, ma questo non è colpa del tool in se, quanto più del programmatore.


Originariamente inviato da fiffio
Le piattaforme di sviluppo visuali sono molto comode e molto veloci si, una cosa certo da non sottovalutare, ma pagando a prezzo di memoria e di velocità di esecuzione dell'eseguibile tutta questa semplicità di sviluppo. Quando poi vedo i miei vecchi compilati in assembler (anche con interfaccia grafica), estremamente piccoli in dimensioni e di gran lunga più performanti in velocità, mi chiedo quando (e se) ne valga la pena salire ad un livello di programmazione così alto...[/B]
Anche queste affermazioni sono molto discutibili.
Certo, nella maggior parte dei casi, qualsiasi astrazione ad alto livello aumenta l'intuitivà a discapito del pieno controllo, anche se non è una regola valevole in assoluto per qualsiasi ambienti di sviluppo, nè tantomeno per Delphi o C++Builder.
Le performance di Delphi e C++Builder sono del tutto paragonabili a quelle ottenute da un normale compilatore C++, con tutti i vantaggi offerti da un ambiente RAD.
Dovendo sviluppare un'applicazione concentrandomi sulla "business logic" della stessa, sono io che mi chiedo se sia proprio necessario scendere così a basso livello utilizzando un linguaggio come l'assembler; ad ogni linguaggio, la propria applicazione specifica.

Tra l'altro, se queste considerazioni nascono dall'impossibilità di trovare una spiegazione alle librerie richieste dal tuo programma, allora 1) devi documentarti di più, 2) devi fornire maggiori dettagli se vuoi essere aiutato da altri in questo.

Denunciare difetti che, personalmente, non noto all'interno dell'ambiente di sviluppo di certo non risolverà i problemi.


Originariamente inviato da fiffio
Ora forse è più chiaro come mai nel precedente post non ho ritenuto opportuno descrivere in dettaglio la mia idea, visto che in primo luogo non sono convinto io stesso della piattaforma utilizzata e quindi rendendomi conto di avere dubbi più generali.[/B]
Non capisco veramente quale strategia stai adottando (anche io ho molti dubbi, quindi).
Adotti un ambiente per sperimentarlo senza preoccuparti di capire i meccanismi che lo governano, poi chiedi aiuto senza specificare i problemi rimanendo vago per non si sa quale motivo, poi rispondi di nuovo lamentandoti dell'ambiente di sviluppo poichè non hai trovato la spiegazione giusta al tuo problema.

Perdonami ma, in tal caso, ho le mani legate.
Per esperienza vissuta proprio con gli ambienti in esame, posso dirti che sono tra i migliori compromessi esistenti e c'è il modo di ottenere ciò che si vuole; se non mi descrivi il tuo problema, di certo non potrò darti una mano...poi, se vuoi dare la colpa completamente all'ambiente di sviluppo, fa lo stesso, ma permettimi di dire che non è un atteggiamento costruttivo.



Originariamente inviato da fiffio
Le comodità dell'alto livello comportano degli svantaggi e mi sembra che ciò accade sempre quando è la macchina che si adatta all'uomo. Le cose cambiano invece quando accade il viceversa: l'uomo che si adatta alla macchina (basso livello). In questo caso - e penso all'assembler - le difficoltà diventano enormi, superate le quali però si viene senza dubbio ben ripagati.[/B]
Che vuoi che ti dica a riguardo? Fai i tuoi programmi in assembler allora... :-)


Originariamente inviato da fiffio
Certo che sarebbe pure stupido voler estremizzare tutto in questa maniera, e voler creare programmi tutti in assembler![/B]
Beh, meno male che alla fine sei arrivato al succo della questione, e su questo sono d'accordo con te.


Originariamente inviato da fiffio
Per tornare al discorso principale, vorrei dire che al momento non ho esigenze di sviluppare un'applicazione troppo ottimizzata, e avendo scartato l'idea del .NET, ho reputato vantaggioso l'utilizzo del Borland C++ Builder: velocità di creazione delle interfacce grafiche, buona integrazione di componenti visuali e il mio personale gusto per il c++ mi hanno fatto prendere la scelta.[/B]
Non so di che applicazione si tratta, non so quali siano i requisiti...come posso dirti se hai fatto una scelta giusta?


Originariamente inviato da fiffio
Concludendo, avrei solo da chiedere una cosa circa il dubbio che mi ha portato a scrivere questa (forse inopportuna) riflessione. Vorrei sapere come si possono conoscere le bpl e le dll da mettere nel sistema senza dover ogni volta prendere un altro pc come cavia dei files mancanti.[/B]
Secondo me, hai compilato la tua applicazione usando i runtime packages: controlla le opzioni di progetto [Project|Options] e assicurati che la casella di spunta "Build with runtime packages" non sia contrassegnata; C++Builder e Delphi provvederanno a creare un eseguibile monolitico contenente tutto ciò che serve.

Poi, approfondiremo l'argomento se sarà necessario o vorrai saperne di più a riguardo (c'è che devo andare a cena)...

Ciao! :ciauz:

fiffio
27-06-2004, 21:16
quote:
Originariamente inviato da fiffio
"Impossibile avviare l'applicazione specificata. vcl60.bpl non è stato trovato. Un nuova installazione dell'applicazione potrebbe risolvere il problema."
Ma non è il solo! Mancano pure rtl60.bpl, bcbsmp60.bpl, vclx60.bpl, e inoltre pure una dll: CC3260MT.DLL. A questo punto mi chiedo come mai un semplicissimo eseguibile da 45KB debba richiedere svariati MB di librerie e rimpiango un poco il mio prediletto Dev-Cpp con il quale ho sempre avuto ben chiaro cosa il compilatore facesse ed eventualmente da quali files l'applicazione creata dipendesse.

Tutto molto molto discutibile. Lavoro in Delphi da parecchi anni, comunque sufficienti per dire che, indipendente dall'ambiente di sviluppo utilizzato, c'è il perchè in ogni cosa. Pertanto, è possibile arrivare a soluzioni apparentemente inspiegabili anche con Dev-Cpp, se non si ha la padronanza dell'ambiente o del linguaggio, ma questo non è colpa del tool in se, quanto più del programmatore.

Hai ragione. E' causa mia: ho più padronanza col Dev-Cpp


Non so di che applicazione si tratta, non so quali siano i requisiti...come posso dirti se hai fatto una scelta giusta?

Il fatto è che dapprima mi riferivo ad un problema ad una particolare applicazione, poi ho esteso il discorso più in generale e, solo per questo motivo, mi è sembrato inutile discuterne.

Comunque l'applicazione in questione aveva la funzione di aprire email, in formato txt o outlook, visualizzarle in un richedit e poterne evidenziare frasi contenute in una listbox. Il programma servirebbe per controllare numerose email che contengano determinate parole chiave in modo automatizzato. Ho fatto uso della memorizzazione e lettura in un file ini, per il salvataggio del contenuto della listbox e anche per altre funzioni, ad esempio posizione e dimensioni form.


Non capisco veramente quale strategia stai adottando (anche io ho molti dubbi, quindi).
Adotti un ambiente per sperimentarlo senza preoccuparti di capire i meccanismi che lo governano, poi chiedi aiuto senza specificare i problemi rimanendo vago per non si sa quale motivo, poi rispondi di nuovo lamentandoti dell'ambiente di sviluppo poichè non hai trovato la spiegazione giusta al tuo problema.

Dopo la scelta dell'ambiente sono rimasto deluso per il fatto di dover essere costretto ad includere tutte quelle bpl.....ma, come tu mi hai consigliato, controllero' il segno di spunta nelle opzioni.

Grazie mille e buon appetito, ora vado a cena pure io!

Ciao ciao :ciauz:

alka
28-06-2004, 00:57
Originariamente inviato da fiffio
Comunque l'applicazione in questione aveva la funzione di aprire email, in formato txt o outlook, visualizzarle in un richedit e poterne evidenziare frasi contenute in una listbox. Il programma servirebbe per controllare numerose email che contengano determinate parole chiave in modo automatizzato. Ho fatto uso della memorizzazione e lettura in un file ini, per il salvataggio del contenuto della listbox e anche per altre funzioni, ad esempio posizione e dimensioni form.
Dalle caratteristiche che hai elencato, non mi sembra che ci sia bisogno di componenti aggiuntivi oltre a quelli standard inclusi in Delphi, pertanto puoi tranquillamente creare un'applicazione monolitica.


Originariamente inviato da fiffio
Dopo la scelta dell'ambiente sono rimasto deluso per il fatto di dover essere costretto ad includere tutte quelle bpl.....ma, come tu mi hai consigliato, controllero' il segno di spunta nelle opzioni.
Tutto ciò che si realizza (utilizzando i componenti standard) in Delphi è dotato di sorgente; questo significa che hai la possibilità di incorporare il codice scritto da Borland nel tuo eseguibile (che chiaramente arriverà ad una dimensione un poco superiore ai 200KB) ma si tratta di un eseguibile autonomo, monolitico; in alternativa, puoi scegliere di utilizzare i BPL, cioè file package in cui è compilato il codice Borland; in questo caso, la tua applicazione è più snella (pertanto più facilmente distribuibile) ma richiede che sul sistema siano presenti le librerie citate, che però vanno copiate una volta sola.

Ad ogni modo, la soluzione adatta ad ogni esigenza c'è e funziona come si deve.

Ciao :ciauz:

Loading