Ho trovato diverse soluzioni apparentemente valide per rendere portable un
software, ma in effetti nessuna funziona per il VB6, almeno sembra, forse
anche per colpa della mia scarsa preparazione in materia.
Ma qualcuno ne ha trovata una veramente valida e collaudata per software VB6
?
Potete aiutarmi ??
Grazie dell'aiuto e saluti a tutti.
giap
Partiamo da una spiegazione teorica di base.
Primo punto: Il VB6 non crea programmi autonomi. Ha sempre
bisogno *almeno* del runtime, che non è detto che sia sempre
installato, a meno che tu non limiti il tuo target a determinate
versioni di SO. E' vero d'altrondeche su SO recenti dovrebbe
già esserci, parlo di XP, Vista e W7.
In secondo luogo, dipende da eventuali componenti esterni
utilizzati: la maggior parte degli OCX deve essere installata e
registrata prima di lanciare il programma, quindi sarebbero
da evitare.
Questo è ancora più vero se usi programmi di terze parti.
Il problema è che senza usare ocx, database eccetera, non
è che si possa fare roba particolarmente utile e innovativa :-)
In teoria potresti usare un launcher (non scritto in VB :-) ) che
verificasse la presenza del runtime e degli eventuali componenti
e in caso di mancanza li installasse e registrasse autonomamente
prima di lanciare il programma principale, oppure che scrivesse
direttamente nel registro le info necessarie.
Poi, all'uscita, andrebbe eseguito il processo inverso per lasciare
il sistema pulito.
Per quanto riguarda la pratica, passo: non ne ho mai avuto la
necessità, quindi non ho mai approfondito.
Ho visto un po' di info con uno step by step qui, vedi se ti aiutano:
http://portableapps.com/node/14868
Bye, G.
Conosci molebox?
http://www.molebox.com/
Impacca exe, ocx, dll, dati.
Crea un singolo exe.
Ha qualche limite (non puoi inserirci driver, ad esempio) ma funziona.
Mi però domando che senso abbia inserire in ogni exe una montagna di dll
che -probabilmente- sono già nel SO...
--
-> GbC|
www.gbcweb.com
www.chiappori.com
Me lo ferma l'antivirus... non so se mi spiego :-/.
> Impacca exe, ocx, dll, dati. Crea un singolo exe.
Ne conoscevo altre, *se* si parla di quel tipo di roba che rende
un'applicazione, diciamo, autoinstallante.
Altrimenti spiegami, o aspetta che controllo domani da casa :-)
> Ha qualche limite (non puoi inserirci driver, ad esempio) ma funziona.
> Mi però domando che senso abbia inserire in ogni exe una montagna di dll
> che -probabilmente- sono già nel SO...
Sempre *se* ho capito bene, eh... rendere un'applicazione
autoinstallante, nel senso che basta lanciare un singolo exe,
non mi pare proprio la stessa cosa che renderla portabile.
Me lo ferma l'antivirus, e prima ancora il FW content filter di rete...
non so se mi spiego :-/. Probabilmente, magari in passato, � stato
usato per "roba brutta assai�". Ce n'era un altro, Fusion o qualcosa
del genere, cha ha fatto la stessa fine.
> Impacca exe, ocx, dll, dati. Crea un singolo exe.
Ne conoscevo altre, *se* si parla di quel tipo di roba che rende
un'applicazione, diciamo, autoinstallante.
Altrimenti spiegami, o anche no, che controllo domani da casa :-)
> Ha qualche limite (non puoi inserirci driver, ad esempio) ma funziona.
> Mi per� domando che senso abbia inserire in ogni exe una montagna di dll
> che -probabilmente- sono gi� nel SO...
Gi�. E poi, sempre *se* ho capito bene, eh... rendere un'applicazione
autoinstallante, nel senso che basta lanciare un singolo exe per
installarla e usarla, non mi pare proprio la stessa cosa che renderla
portabile. Oh, se dopo la disinstalla magari va anche bene, ma il
succo del concetto di "portable app" � proprio nel fatto che il
programma non installa niente, non occupa spazio e non sporca
il registro della macchina su cui deve girare.
Sempre SE&O :-).
Bye, G.
Non fa programmi autoinstallanti.
L'exe contiene tutto ciò che serve al prg per funzionare.
Lanci l'exe e il programma funziona.
Detto così pare un miracolo...
Viene creata una machina virtuale in cui sono espansi tutti i pezzi; il
programma viene eseguito nella sandbox ed ivi si cerca dll, ocx e
quant'altro. Alla fine la VM viene chiusa e tutto scompare; non resta
che l'exe di partenza. Ovviamente se il prog elabora dei dati li salvi
come sempre e li ritrovi dopo essere uscito. Simpatico il fatto che puoi
buttarci dentro DB, file dati e qualsiasi dato che non richieda
aggiornamento, magari per non renderlo semplicemente accessibile agli
utilizzatori.
Ultimamente ho dovuto creare un exe con un mio programma, i runtimes
vb6, common controls, common dialogs e varie amenità del DBMS, più 600
mb di database di sola consultazione. Parte lentamente ma funziona alla
grande. Non potevamo installare nulla in quella macchina, ma potevamo
copiarci dentro ed eseguire un programma (misteri dei CED).
Riguardo agli AV è strano che tu abbia quel comportamento. Qui ho Avira
(ma ho un certo numero di persone che usano robe fatte con MoleBox) e
non ha mai dato particolari fastidi.
Se vuoi un esmpio dimmelo che te ne faccio uno per vedere se l'AV
sclera.
Mo vado a dormire che si è fatto tardi...
Ciao cia'
Per il runtime (MSVBVM60.DLL) non occorre registrazione, basta che sia
presente nella stessa folder dell'applicazione.
Per il problema dei componenti ActiveX da registrare, se il sistema target è
da XPSP2 in su e si ha voglia di cipollare un po' con i manifest, si può
usare la tecnica di reg-free activation, descritta in questi articoli:
http://msdn.microsoft.com/en-us/library/ms973913.aspx
http://www.devx.com/vb/Article/32888/1954
In teoria così non ci sarebbe bisogno di registrare nulla, però non l'ho mai
sperimentata... se avessi tempo sarei curioso di vedere se funziona anche
con componenti "delicati" come quelli di MDAC (ADO, etc. etc.).
Bye
Raf
[cut]
> Per il runtime (MSVBVM60.DLL) non occorre registrazione, basta che sia
> presente nella stessa folder dell'applicazione.
> Per il problema dei componenti ActiveX da registrare, se il sistema target
> è da XPSP2 in su e si ha voglia di cipollare un po' con i manifest, si può
> usare la tecnica di reg-free activation, descritta in questi articoli:
> http://msdn.microsoft.com/en-us/library/ms973913.aspx
> http://www.devx.com/vb/Article/32888/1954
> In teoria così non ci sarebbe bisogno di registrare nulla, però non l'ho
> mai sperimentata... se avessi tempo sarei curioso di vedere se funziona
> anche con componenti "delicati" come quelli di MDAC (ADO, etc. etc.).
Una discussione dallo stesso identico argomento spiega bene cosa si può e
cosa non si può fare:
http://www.vbforums.com/showthread.php?t=548585
Bye
Raf
Non necessariamente, con vb6.
> installato, a meno che tu non limiti il tuo target a determinate
> versioni di SO. E' vero d'altrondeche su SO recenti dovrebbe
> già esserci, parlo di XP, Vista e W7.
Non c'è in quei s.o. (e in nessun altro credo)
> In secondo luogo, dipende da eventuali componenti esterni
> utilizzati: la maggior parte degli OCX deve essere installata e
> registrata prima di lanciare il programma, quindi sarebbero
> da evitare.
Non necessariamente..
> manifest, si può usare la tecnica di reg-free activation, descritta in
> questi articoli:
> http://msdn.microsoft.com/en-us/library/ms973913.aspx
> http://www.devx.com/vb/Article/32888/1954
> In teoria così non ci sarebbe bisogno di registrare nulla, però non l'ho
In pratica non funziona sempre, perchè ad esempio il tuo componente può
aver bisogno di chiavi di registro particolari, file speciali etc che
devono essere installati.. però funziona in un gran numero di casi.
> mai sperimentata... se avessi tempo sarei curioso di vedere se funziona
> anche con componenti "delicati" come quelli di MDAC (ADO, etc. etc.).
MDAC non è un problema, nel senso che dove sarebbe da
installare/aggiornare la sxs non funziona comunque. Il side by side
comunque è utilissimo per le vecchie applicazioni vb6, mi ha già salvato
molti grattacapi e costi potenzialmente enormi diversi volte.
Fammi vedere come fai girare un programma in VB6 *senza*
il runtime e ci crederò. Per senza, non intendo che puoi
fonderli in un unico eseguibile o roba del genere, eh. Intendo
*senza*.
Nel frattempo resterò della mia opinione, se non ti spiace :-).
>> installato, a meno che tu non limiti il tuo target a determinate
>> versioni di SO. E' vero d'altrondeche su SO recenti dovrebbe
>> già esserci, parlo di XP, Vista e W7.
> Non c'è in quei s.o. (e in nessun altro credo)
C'è. Fonte Microsoft:
http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
"Support Statement for Visual Basic 6.0 on Windows Vista,
Windows Server 2008 and Windows 7
Update: March 2010"
I runtime di VB6 risultano come
VB6 Supported Runtime - Files Shipping in Windows
In tutte le versioni da Windows 2000 a Windows 7.
>> In secondo luogo, dipende da eventuali componenti esterni
>> utilizzati: la maggior parte degli OCX deve essere installata e
>> registrata prima di lanciare il programma, quindi sarebbero
>> da evitare.
> Non necessariamente..
E' quello che ho detto anch'io: "la maggior parte" e "sarebbero".
Non ho detto "tutti" e "sono".
Bye, G.
In pratica da W2000 e successivi, la MSVBM60.DLL è già fornita col so,
quindi all'atto pratico per semplici utility basta l'exe..
>> Non c'è in quei s.o. (e in nessun altro credo)
>
> C'è. Fonte Microsoft:
> http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
> "Support Statement for Visual Basic 6.0 on Windows Vista,
> Windows Server 2008 and Windows 7
> Update: March 2010"
> I runtime di VB6 risultano come
> VB6 Supported Runtime - Files Shipping in Windows
> In tutte le versioni da Windows 2000 a Windows 7.
Si, ma a parte la MSVBM60 in pratica i file coincidono con gli MDAC/jet/sql
ole db, mancano i vari ocx per i componenti un po' più complessi necessari
per applicazioni più vaste..
Ma mi stai trollando ?
> >> Non c'è in quei s.o. (e in nessun altro credo)
> > C'è. Fonte Microsoft:
> > http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
> > "Support Statement for Visual Basic 6.0 on Windows Vista,
> > Windows Server 2008 and Windows 7
> > Update: March 2010"
> > I runtime di VB6 risultano come
> > VB6 Supported Runtime - Files Shipping in Windows
> > In tutte le versioni da Windows 2000 a Windows 7.
> Si, ma a parte la MSVBM60 in pratica i file coincidono con gli MDAC/jet/sql
> ole db, mancano i vari ocx per i componenti un po' più complessi necessari
> per applicazioni più vaste..
Allora è per questo che non ci si capiva... la MSVBM60.DLL
è *il* runtime di VB. Il resto sono appunto OCX esterni,
file di supporto database eccetera, ma non fanno parte
del runtime. Che è strettamente necessario per far girare
anche il programma VB più striminzito.
Il problema era di definizione :-)
Bye, G.
ghghghghgh :)
Ho sempre cercato una cosa: se nella dll di 1.4M come msvbvm60.dll al mio
programma servono soltanto 4 funzioni rispetto alle 200presenti(ovviamente
sono numeri a caso), non esiste un modo per estrarre soltanto le funzioni
che mi interessano e fondere tutto in un unico eseguibile?
Questo a mio avviso ha un senso, il resto invece......ma mi sa che non
esiste una cosa fatta cosi...
Photoshop 4 senza installazione puo essere creato tramite vmware e thinyapps
ma ovviamnete bisogna rispettare le licenze e condizioni di uso ;)
Avendo il codice della DLL *forse* si potrebbe fare.
Ma non in VB, ovviamente, la DLL è scritta in C++.
> Questo a mio avviso ha un senso, il resto invece......ma mi sa che non
> esiste una cosa fatta cosi...
Non è la stessa cosa, purtroppo, ma in .NET hanno reso disponibili
i sorgenti dello strato di emulazione del runtime di VB:
http://blogs.msdn.com/vbteam/archive/2008/01/19/source-code-of-visual-basic-runtime-has-been-released-to-public.aspx
Bye, G.