Il PDW è veramente "pericoloso" come lo si dipinge?

[Marcus]

Riporto di seguito un estratto (spero sufficientemente ampio da far campire che non c'è stata manipolazione, né tagli) dell'aritcolo redatto da Sergio Pappalardo e pubblicato nell'area degli articoli tencici di VB T&T.

>>
non essendo stato modificato per essere perfettamente compatibile con le ultime versioni di Windows, il P&D non può conoscere le loro peculiarità e risulta quindi piuttosto pericoloso, poiché quasi sempre, nei pacchetti di installazione con esso creati, viene richiesto l'aggiornamento di file di sistema (come OLEAUT32.DLL) che in Win2000, XP e successivi, devono essere aggiornati unicamente tramite Service Pack per il sistema operativo stesso (secondo le specifiche della stessa Microsoft) e non da parte di un comune programma, men che meno da un installer. Se si sovrascrivessero tali file, perché il pacchetto viene creato da una macchina più aggiornata (es. WinXP) rispetto a quella dell'utente finale (es. una qualsiasi versione Win9x oppure anche WinNT o 2000), ecco che il sistema diverrebbe nel migliore dei casi completamente instabile, nel peggiore risulterebbe persino impossibile avviarlo.
<<
Quanto riportato è corretto: OLEAUT32.DLL è una parte fondamentale del sistema ma l'istallante di Visual Basic ne ha bisogno per lavorare e lo include nello startup Kit.
E' da notare che il file OLEAUT32.DLL utilizzato dallo startup kit dell'installante realizzato con il PDW proviene da un'apposita cartella da cui il PDW lo preleva (e quindi non lo va a prendere dalla cartella di sistema dove si trova la versione più recente, nativa del sistema operativo in cui si prepara l'installante).
Indichiamo una situazione relale (un po' estremizzata): ho un software che voglio distribuire con compatibilità completa da Win95 a WinXP.
Ammettiamo che io abbia sviluppato il software da distribuire sotto WinXP, che lo abbia testato in ambiente Win95 attraverso un apposito virtualizzatore, e che lo voglia distribuire per farlo girare anche sotto Win95.
Se il PDW prendesse OLEAUT32.DLL dalla cartella di sistema di WinXP esso avrebbe sicuramente una versione superiore a quella del medesimo file che si trova nella cartella di sistema di Win95. Ovviamente il motore di installazione di un installante relaizzato con il PDW controlla che il file che si sta installando sia di versione almeno superiore rispetto a quello che sta sul sistema. Poiché, in questo caso, la condizione viene verificata, OLEAUT32.DLL di WinXP viene sovrascrito a quello di Win95. Trattandosi di un file di sistema, alla fine dell'installazione viene anche richiesto il riavvio del sistema. Ma ormai il patatrack è fatto!
Fortunatamente, il PDW prende e porta con sé un OLEAUT32.DLL che di versione compatibile fin da Win95. Quando il motore di installazione di un installate creato con il PDW tenterà di scrivere OLEAUT32.DLL in un sistema operativo WinXP non lo farà perché quello prensente in quest'ultimo sistema operativo è più recente di quello che si sta tentando di installare.
E siccome il file non viene sostituito, a meno che non venga sostituito qualche altro file di sistema, non viene neppure richiesto il riavvio.
Perciò, mi risulta opportuno chiedere:
1) detto questo, ci sono altri motivi per cui un installante preparato con il PDW, "rovini" OLEAUT32.DLL?
2) quali altri file importanti di sistema prebbero venir "rovinati" da un istallante realizzato con il PDW?

Marcus

[Sergio Pappalardo]

Capisco il tuo discorso, ma ci sono dei punti inesatti più alcune cose che non sono menzionate e che invece meritano di essere messe in evidenza.

Il PWD ha molti problemi. O meglio, andava benissimo per i SO in uso quando è stato creato, ma quei tempi sono passati e il PWD non è più al corrente di come le nuove versioni di Windows debbano essere trattate e di quali siano gli accorgimenti che Microsoft raccomanda (specialmente per WinXP e Vista). Ma questo, l'ho già detto nel mio articolo.

Il fatto che il PWD utilizzi alcuni file di sistema che non debba essere distribuiti, tra cui OLEAUT32.DLL (ma è solo uno dei tanti), prelevandoli da una sua cartella... può essere vero ma non sempre è così. Se si predispone il PWD e tale cartella, con i file necessari, appositamente allora sì, ma dalle installazioni di default questo non succede. E l'utente standard tende spesso ad usare le installazioni di default, e si sa quanto sia importante la facilità d'uso in temi critici come sicurezza e stabilità del sistema, in quanto l'anello debole è sempre l'utente finale... quindi una soluzione difficile da attuare è potenzialmente molto meno sicura di una di utilizzo immediato, a prescindere dalle caratteristiche intrinseche delle due soluzioni.

Detto questo, tornando in carreggiata, si può dire che quindi la maggior parte degli utenti-sviluppatori che usa il PWD non ha tale cartella contenente il file OLEAUT32.DLL e gli altri file di sistema in versione meno aggiornata possibile (Win95), di conseguenza il PWD preleverà tali file dal sistema dell'utente, con le conseguenze che tu stesso menzioni in caso il pacchetto venga installato su un sistema meno aggiornato rispetto al sistema sul quale lo sprovveduto sviluppatore abbia preparato il pacchetto (es. classico: WinXP, per distribuire su Win9x, NT, 2000).

Come si evince da qui infatti, dove si legge:

This will cause problems when you try to distribute a package using the
Package and Deployment Wizard. Windows tells the installer that some system
files are out of date (actually it is the above one) and then prompts for a
reboot. Because Windows 2000 will not let an installation program modify
this file (even when you are logged in as administrator!), after the reboot
you get the same message and end up stuck in an endless loop.

Molti infatti, che non usano una cartella adatta allo scopo in cui mettere i file di sistema che il PWD dovrebbe utilizzare, usano lo stratagemma di preparare il pacchetto sempre sotto la versione di Windows più inferiore possibile per il software che andranno a installare (Win95 possibilmente), in modo che tutti gli altri sistemi successivi non abbiano problemi.

Questo problema, e qui mi ricollego alla tua altra domanda "quali altri file diano problemi oltre a OLEAUT32.DLL" i file che devono essere redistribuiti per un'applicazione creata in Visual Basic sono unicamente la virtual machine di VB, ossia il file MSVBVMx0.DLL (dove x indica la versione di VB utilizzata), più ovviamente le dipendenze e gli ocx per i controlli utilizzati all'interno dell'applicazione stessa. Tutti gli altri file sono unicamente dipendenze della stessa virtual machine e non devono essere distribuiti, poichè già inclusi, nella versione appropriata, nel sistema destinazione!
Questi file sono: KERNEL32.DLL, USER32.DLL, GDI32.DLL, ADVAPI32.DLL, OLE32.DLL, OLEAUT32.DLL e non vanno assolutamente redistribuiti col pacchetto.

E tutto questo CyberInstaller lo sa, mentre il PWD no! Ma poverino, non è colpa sua... è troppo vecchio!

A riprova di quanto dico c'è questa interessante discussione condotta da un MVP (non affiliato con Microsoft), in cui legge (estrapolo le parti essenziali):

Quindi ... non ti fidare delle dipendenze tirate fuori da VB ma fai fare tutto ad un installer moderno !
[...]
Citazione: (originariamente inviato da eziogsv)
l' installer microsoft è liberamente scaricabile e distribuibile.... non ho mai sentito di crash dovuti alla sua installazione...

Oh ... io invece sì, e tanti. Leggi questi articoli (ma ne esistono tanti), magari solo per conoscenza:
http://support.microsoft.com/kb/831491/en-us

PRB: Multiple "System Files Are Out of Date" Errors
http://support.microsoft.com/kb/191096/en-us

E leggi anche questo, se ti va ...
http://www.codecomments.com/archive...6-3-859741.html

soprattutto da quando Mike (collega MVP ... ) afferma
"... You must realize PDW came out in 1998 before certain features of Windows ... "

Altri errori che compie il PWD sono quelli di registrazione, es. a volte per registrare correttamente alcuni ocx è necessario cambiare all'interno dello script di installazione setup.lst la stringa $(DLLSelfRegisterEx) con $(DLLSelfRegister). Quanti utenti lo sanno fare? Quanti utenti sanno di questo potenziale problema?
Ancora sui problemi di registrazione: per Vista è necessario utilizzare alcune modifiche per la registrazione di certi ocx, come recito in questo articolo del mio blog.

Io non mi fiderei assolutamente di distribuire un mio software con il PWD. La distribuzione di un software è la confezione, l'abito con cui presentiamo il nostro prodotto ai potenziali clienti. Ci fideremmo di uno strumento obsoleto, abbandonato dalla casa produttrice e con potenziali e comprovati rischi di malfunzionamenti (mancate registrazioni, ecc.) nonchè potenziale causa di crash di sistema e che potrebbe minare seriamente la stabilità dell'intero sistema? Io no. E voi?

Insomma, per concludere, cito l'MVP: "bisogna comprendere che il PDW uscì nel 1998, prima di certe funzionalità dei Windows attuali...".

[Marcus]

Allora Sergio, restiamo in argomento e cioè parliamo di "pericolosità". Mi pare di aver capito che se non siamo utenti-sviluppatori "sprovveduti" e predisponiamo le cose per come dovrebbero essere, dovremmo riuscire a produrre un installante quanto meno non dannoso per il sistema operativo. Corretto?
Ma data la tua esauriente spiegazione, che ovviamente apprezzo, file come USER32.DLL, GDI32.DLL ecc. sono sicuramenti nativi di sistema. E per quanto riguarda OLEAUT32? Non è per caso nativo anche lui? Perché allora il PDW dovrebbe includere questo file e non include (giustamente) gli altri file come USER32.DLL, GDI32.DLL, KERNEL.DLL ecc?
L'unica cosa che mi viene in mente è che vi sia una versione di OLEAUT32.DLL che implementa determinate funzioni necessarie alla MSVBVMx0.DLL, oppure che si sono accorti che alcune funzioni di OLEAUT32.DLL così com'era nativa di sistema, aveva alcuni Bug che andavano sistemati (invece USER32.DLL, GDI32.DLL erano corretti e quindi non c'era bisogno di sistemarli, al massimo si faceva un'upgrade del sistema), e quindi con l'occasione si poteva sistemare tutto.
Cosa puoi dirmi in proposito?

Menzionando invece la vecchiaia del PDW, si va fuori argomento. La sua vecchiaia non è tanto pericolosa, quanto invece non consente di sfruttare come si deve le prerogative degli ultimi sistemi operativi.
Ma questo può essere trattato in un altro argomento di discussione.

Marcus

[Sergio Pappalardo]

Allora Sergio, restiamo in argomento e cioè parliamo di "pericolosità". Mi pare di aver capito che se non siamo utenti-sviluppatori "sprovveduti" e predisponiamo le cose per come dovrebbero essere, dovremmo riuscire a produrre un installante quanto meno non dannoso per il sistema operativo. Corretto?

Certo, ma per assurdo allora se uno è abbastanza esperto potrebbe anche farsi il suo installer personalizzato!...
Un installer non dannoso, ma siamo sicuri di averne testato tutte le funzionalità in ogni possibile contesto? Meglio usare strumenti all'avanguardia e compatibili con le linee guida Microsoft, quanto meno perchè altrimenti non ci si potrà lamentare con Microsoft poi se Windows non funziona a causa di un'installazione fatta male! Se già usi in partenza strumenti non supportati e vecchi di 10 anni, beh.. se riesci a utilizzarli tanto di cappello a te, ma se poi qualcosa non funziona come dovrebbe... dirti che ti sei dato la mazzata sui piedi da solo è cortesia!

Ma data la tua esauriente spiegazione, che ovviamente apprezzo, file come USER32.DLL, GDI32.DLL ecc. sono sicuramenti nativi di sistema. E per quanto riguarda OLEAUT32? Non è per caso nativo anche lui? Perché allora il PDW dovrebbe includere questo file e non include (giustamente) gli altri file come USER32.DLL, GDI32.DLL, KERNEL.DLL ecc?
L'unica cosa che mi viene in mente è che vi sia una versione di OLEAUT32.DLL che implementa determinate funzioni necessarie alla MSVBVMx0.DLL, oppure che si sono accorti che alcune funzioni di OLEAUT32.DLL così com'era nativa di sistema, aveva alcuni Bug che andavano sistemati (invece USER32.DLL, GDI32.DLL erano corretti e quindi non c'era bisogno di sistemarli, al massimo si faceva un'upgrade del sistema), e quindi con l'occasione si poteva sistemare tutto.
Cosa puoi dirmi in proposito?

Bella domanda. Il punto è che i file che citi tu (USER32.DLL, GDI32.DLL, KERNEL.DLL, ecc.) sono proprio fondamentali, quindi redistribuirli sarebbe stato un suicidio. La OLEAUT32 diventava necessaria per permettere l'automazione ole, infatti con i Windows precedenti a Win98 tale file doveva proprio essere aggiornato perchè il runtime di VB (la virtual machine) funzionasse correttamente.
Si legge infatti:

Every Visual Basic 6.0 application requires that the following OLE Automation system files be installed to function.

E come si sa l'automazione OLE è data dai seguenti file:
• OLEPRO32.dll
• OLEAUT32.dll
• ASYCFILT.dll
• STDOLE2.tlb

che però non devono essere redistribuiti per nessun motivo (se non in Win95, essendo la versione di base, dove tali file non erano aggiornati per l'OLE Automation), ma utilizzati solamente quelli di sistema già installati dall'ultimo service pack del sistema operativo in uso (già Win95 OSR2 era apposto!). Ora, il PDW installava tutti questi file, come già detto nella mia precedente risposta. Per fortuna, non si è mai nemmeno lontanamente sognato di installare anche i file del kernel che tu cici!

In ogni caso, il modo di operare del PDW si è rivelata una scelta progettuale non del tutto ben realizzata da parte dei progettisti Microsoft, che hanno cercato di metterci più pezze in seguito.

[Marcus]

Ciao Sergio,

allora i 4 files che hai menzionato sono proprio quelli contenuti in quella cartella di cui parlavamo all'inizio e sono a livello della versione Win95 OEM SR 2.1. Ed essendo di automazione OLE (quindi non nativi prima della versione di Win95 poc'anzi menzionata) dovevano in qualche modo essere redistribuiti. Poi era compito del motore di installazione valutare se installarli oppure no: tipicamente verificandone la versione (visto che trattasi di file binari).
E' chiaro che visto attualmente il PDW ha diverse falle, da intendere come mancanze, e non è neppure paragonabile agli altri prodotti in commercio o free.
Però, si può finalizzare che il PDW se lo conosci *bene* lo puoi ancora usare per distribuire prodotti "casalinghi" (tipo la tombola o risiko in rete con WINSOCK), ma per applicazione semi-professionali o professionali, al fine di poter sfruttare tutte le peculiarità del sistema operativo di destinazione ed andare tranquilli a preparare un'installante anche senza sapere nulla di nulla di come funzionano le cose sotto il cofano (versioni, registrazioni di librerie ecc.) è opportuno affidarsi a prodotti semi-professionali o professionali, purché aggiornati, che possano costruire un istallante dall'aspetto e funzionalità altrettanto semi-professionali o professionali.
Secondo me il problema grande del PDW non sta tanto nel motore di installazione, quando proprio nella composizione guidata che costruisce il file Setup.lst. Se si analizza il sorgente del motore di installazione setup1.exe, si scoprono moltissime cose che neppure sarebbe stato possibile sospettare.

Marcus

[Sergio Pappalardo]

E' chiaro che visto attualmente il PDW ha diverse falle, da intendere come mancanze, e non è neppure paragonabile agli altri prodotti in commercio o free.
Però, si può finalizzare che il PDW se lo conosci *bene* lo puoi ancora usare per distribuire prodotti "casalinghi" (tipo la tombola o risiko in rete con WINSOCK), ma per applicazione semi-professionali o professionali, al fine di poter sfruttare tutte le peculiarità del sistema operativo di destinazione ed andare tranquilli a preparare un'installante anche senza sapere nulla di nulla di come funzionano le cose sotto il cofano (versioni, registrazioni di librerie ecc.) è opportuno affidarsi a prodotti semi-professionali o professionali, purché aggiornati, che possano costruire un istallante dall'aspetto e funzionalità altrettanto semi-professionali o professionali.

E in tutti questi casi... vai di CyberInstaller!

Secondo me il problema grande del PDW non sta tanto nel motore di installazione, quando proprio nella composizione guidata che costruisce il file Setup.lst. Se si analizza il sorgente del motore di installazione setup1.exe, si scoprono moltissime cose che neppure sarebbe stato possibile sospettare.

Certo, la creazione guidata di un pacchetto di installazione e quasi più critica del motore di installazione. Anche in CyberInstaller Suite, il modulo Studio è ben più corposo del modulo Installer (oltre 60.000 righe di codice contro meno della metà). La maggior parte delle segnalazioni al supporto tecnico di CIS riguarda proprio l'implementazione di funzionalità non presenti in Studio, ma che possono essere implementate tranquillamente dal motore di installazione, tramite un po' di lavoro manuale ulteriore (ma spesso non concepibile dall'utente che vuole, giustamente, un prodotto facile da usare e in punta di mouse), oppure sono segnalazioni di bug sempre di Studio. Molti infatti assimilano "CyberInstaller Suite" a Studio e il motore di installazione passa, paradossalmente, in secondo piano.

Ci tengo comunque a sottolineare che CyberInstaller Suite risponde perfettamente a qutti i problemi del PWD menzionati in questa discussione e oltretutto va anche molto oltre, spingendosi dove applicativi blasonati (e commerciali) costando svariate centinaia di euro...

[Badpazzword]

In definitiva stai chiedendo all'oste se il suo vino è buono. [No, seriamente. Sergio non mentirebbe mai per aumentare la sua user base ]

Secondo me il problema grande del PDW non sta tanto nel motore di installazione, quando proprio nella composizione guidata che costruisce il file Setup.lst. Se si analizza il sorgente del motore di installazione setup1.exe, si scoprono moltissime cose che neppure sarebbe stato possibile sospettare.

Beh, a questo punto sarebbe necessario scrivere Setup.lst a mano, o quantomeno modificarlo, con conseguente investimento di tempo e energie. Ma se, come mi sembra, l'obiettivo è semplicemente quello di ottenere un installer semplice e veloce che funzioni, tanto vale usare strumenti GUI più moderni che puoi usare anche in contesti più impegnati; ad esempio CIS o concorrenti. E se il punta-e-clicca può sembrare riduttivo rispetto a un interfaccia di testo (le wizard di InnoSetup, per esempio, lo sono) considera che in CIS la differenza tra i due metodi è davvero minima (credo si riduca alla modifica dell'ordine di installazione dei file...).

Per quanto mi riguarda non ho visto affatto installer di VB5 o VB6 in circolazione negli ultimi anni. Beh, onestamente sono stato all'esterno degli ambiti aziendali e l'unico installer che ho visto negli ultimi sette mesi è apt ma questa è un'altra storia e un altro mondo.

[gibra]

Rispondendo alla domanda, dire Sì e anche di più.

Personalmente l'ho provato poche volte, ed tutte con esito negativo, per via della solita domanda del cavolo che chiedeva di riavviare all'infinito. E mi sto riferendo ad un bel po' di anni fa... Morale, da un amico ho dovuto reinstallare Windows!

Onestamente non capisco nemmeno che senso abbia porsi questa domanda che si riferisce ad uno strumento come il PDW che definire preistorico è un eufemismo.
Se parliamo a livello didattico, che so, sperimentare, provare a creare un installer partendo dal PDW, posso anche capirlo.
Anche se, nonostante tutto, lo ritengo proprio tempo perso perchè sarebbe come reinventare la ruota di pietra, quando oggi abbiamo già i pneumatici da neve, coi chiodi, da strada, da velocità, ecc. ecc. ecc.
Sinceramente, non ci vedo proprio alcuna utilità.

Ciao