Newsgroup: it.comp.lang.visual-basic
Titolo: compatibilita' su sistemi MS.. hp bisogno di aiuto

Salve...
in questi giorni mi sono imbattuto in un problema che forse esula dalla
mera programmazione di software ma che penso possa essere trattato su
questo NG...
dopo aver creato la mia applicazione, funzionante sul mio sistema con XP,
ho pensato di testarlo su altri PC...
ingenuamente la prima volta mi sono limitato a portare in giro il mio .exe
e i file del dataabase.... ma ovviamente questo non poteva essere
sufficiente... fondamentalmente perche' non su tutti i PC sono presenti
tutte le librerie che utilizzo..
per cui, ravvedutomi di cio', sono tornato a casa e mi sono crato un
setup.exe grazie all'utility "creazione guidata di pacchetti di
installazione" contenuta nel pacchetto di VB.
in questo modo ho creato il mio .cab contenete i file da me creati piu'
tutta una serie di librerie inserite automaticamente dall'utility (che si
e' presa carico di controllare i file necessari  al corretto utilizzo del
progetto).
Purtoppo pero' mi sono accorto che cio' non basta....
provando ad installare l'applicazione su di un win98,
dopo aver riavviato il pc come richiesto dal software, con rammarico ho
constatato che il file OLEAUT32.DLL era stato modificato e reso
inutilizzabile...
questo non solo mi impediva di usare la mia applicazione, ma mi proibiva
l'uso di moltissimi altri software tra cui explorer...
ora mi chiedo ... come posso io, dopo aver creato un software tuttosommato
banale, avere la certezza che funzioni non dico ovunque, ma almeno sui
principali SO microsoft?
tanto piu' che ho usato applicativi Microsoft studiati appositamente..
sapete aiutarmi o consigliarmi sul da farsi?
grazie a tutti 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 ha scritto nel messaggio
news:dam0ka$1k0$1...@news.newsland.it...

Questo è quello che facciamo noi:
1) Evitare il package & deployment wizard di VB, in quanto è un po' limitato, ed
affidarsi invece ad un prodotto professionale come ad esempio InstallShield.
2) Installare un ambiente tipo VirtualPC o VMware Workstation su cui predisporre
un set di "PC virtuali" con i sistemi operativi che la tua applicazione dovrebbe
supportare.
3) Ad ogni release effettuare un'installazione di test su tutti gli ambienti
virtuali e provarla a fondo.
Bye
Raf

 Questo č quello che facciamo noi:
Ok, ma questa č la soluzione professionale; penso che Gman abbia bisogno di
qualcosa che funzioni ma che sia meno complicato e ... lungo ;)
--
Greg

 qualcosa che funzioni ma che sia meno complicato e ... lungo ;)
IMHO e` invece la piu` semplice e rapida, visto che ogni volta
ti permette di provare con una macchina pulita anche disponendo
fisicamente di un solo pc. In piu` e` possibile anche salvarsi
macchine preinstallate a scopo dimostrativo con la certezza che
funzioneranno.
-- 
ciao, hal

Grazie a tutti per la partecipazione...
si in effetti speravo in qualcosa di + veloce, ma provero' questa
soluzione... :)
appena riesco scarichero' i 130 MB della demo di installshield, con il mio
56k sarebbe un suicidio.
L'idea e' valida...
cercero' qualcosa in rete riguardo VirtualPC o VMware Workstation non li
conosco, spero siano semplici da usare..
...ma la MS non da' almeno una base di certezze sulla compatibilità?
capisco che esistano software tanto complessi e specifici da rendere molto
difficoltosa una completa compatibilità, ma 1 database ( IN access!!) con
una banale interfaccia in VB(!!!) (che non obblighi l'utente a prendersi
una licenza di Office con Access) che permette di inserire records e di
fare qualche query con 1 chiamata alla commondialog per una LOAD dave dare
garanzie (IMO) se utilizzate su piattaforme microsoft... oppure no?
Tralaltro la cosa che mi ha lasciato perplesso e che la oleaut32.dll
aggiunta al progetto dall'utility, ha mandato in tilt un intero
sistema(!!!)
non so da cosa venga usata quella libreria ma una volta
corrotta/sostituita non andava + nulla, nemmeno il processo che gestisce
le immagini del desktop...
Ok questo forse centra poco ma dato che VB e nato solo per coloro che non
vogliono perdere troppo tempo nell'arte della programmazione, o meglio
dato che molti lo usano perche' non hanno basi tali da poter usare
linguaggi + complicati non dovrebbe essere a prova di citrullo??
ciao ciao


 non dovrebbe essere a prova di citrullo??
questo e` quello che dicono i markettari microsoft: in realta`
per usare bene visual basic non basta dare una scorsa veloce
su qualche sito.
-- 
ciao, hal

 gestisce le immagini del desktop...
Fai una cosa: lancia una ricerca per  *.dll e *.exe che contengano
"oleaut32". Non è il sistema giusto, per individuare le dipendenze,
ma un'idea approssimativa te la dà. A me escono, su W98, 510 file :-).
Quello che non capisco è come abbia potuto venir sovrapposta,
almeno a me non è mai successo.
Bye, G.

 ha scritto nel messaggio
news:dam0ka$1k0$1...@news.newsland.it...


 soluzione... :)
Quello *è* il sistema più veloce.
Sempre che tu dia un valore al tuo tempo, naturalmente...
GMan, benvenuto nel mondo "Io ce l'ho profumato" di MS.
Purtroppo, come hai sperimentato sulla tua pelle, una cosa sono le
belle parole(e mi sto trattenendo...) un'altra la realtà.
Belle parole:
"Visual Basic è lo strumento che ti consente in assoluto più
produttivo per la programmazione in Windows".
Realtà:
Quando hai acquisito un pò di esperienza nel suo uso, ti
accorgi che per molte cose è limitato senza componenti
esterni, l'installazione può essere un inferno e se non ti stai
attento, rischi di avere un programma che funziona su un numero
estremamente limitato di PC.
Belle parole:
"Visual Basic è orientato agli oggetti".
Realtà:
Visual Basic è orientato ai *compoenenti*, vale a dire che non puoi
creare "classi" in stile OOP(a meno di trucchi, infatti, non esiste
neanche l'ereditarietà!) ma soltanto oggetti COM che usano interfacce
derivate da IDispatch(quindi non puoi nemmeno accedere a quelle
derivate da IUnknown, che sono una notevole quantità).
Belle parole:
"Visual Basic genera eseguibili molto piccoli".
Realtà:
Chissà com'è si scordano di dire che però - accanto agli "eseguibili
molto piccoli" - ci vanno tutti i componenti OCX utilizzati, oltre alle
librerie di runtime di VB, quindi diciamo sicuramente 1,5 MB di fisso,
oltre agli OCX - i quali sono necessari per quasi tutto.
Ultimamente però MS "bara" includendo le librerie di runtime di VB
direttamente col sistema operativo. Questo significa essenzialmente che
puoi evitare di includerle nel setup per gli SO più nuovi(da 2000 in su,
credo) e se non fai uso di altro che non sia JET, gli eseguibili sono
*davvero* piccoli perché tutto è già sul PC di destinazione, dando una
falsissima percezione di piccolezza.
Queste sono le prime che mi vengono in mente, ce ne sono altre.
Non fraintendermi, ci sono tante cose belle che si possono fare con VB,
però dopo un pò che hai a che fare con MS ti rendi conto che hanno un
ottimo reparto di marketing, il quale non sempre "dice tutto" quello che
dovresti sapere.
Ciao,
Andrea

 virtuali e provarla a fondo.
Assolutamente si.
Aggiungerei però un punto all'inizio:
0) Prima di inserire qualunque riferimento o componente nel progetto, 
informarsi su problematiche di distribuzione, compatibilità, licenza.
Ciao
Alberto
-- 
I have a dream that my four little children
will one day live in a nation where they
will not be judged by the color of their skin
but by the content of their character.

 Ciao
Ciao
Raf

 Windows.
Già.
Non ci pensavo perchè lo davo per scontato.
Da 'noi' (nella stessa accezione in cui lo hai usato tu...) le Api sono 
'il demonio'.
Si tenta di tutto, a qualunque costo, prima di farne uso.


 Alberto
Ciao