Newsgroup: it.comp.programmare.win32
Titolo: file INI: come si cambia il nome di una sezione?

Premetto che sto programmando in vc6; vorrei sapere se esiste una funzione
MFC o una API che mi permetta di cambiare il nome di una [sezione]
all'interno di un file .ini, in pratica una API simile alla
"WritePrivateProfileString", che si usa per cambiare il valore di una chiave
all'interno della sezione.
Grazie infinite a chiunque possa darmi un'informazione.
Massimiliano

 all'interno di un file .ini
API non mi sembra di averne viste, comunque con un semplice parse del 
file ini potresti farlo 'a mano'.
PS: Usare i registry????
-- 
Luc.

> PS: Usare i registry????
Ma per una volta che qualcuno vuol fare le cose per bene, perche' vuoi
portarlo sulla cattiva strada?
Il registry meno lo si usa meglio e'.
Il registry e' una bomba ad orologeria che ha il solo scopo di rallentare
progressivamente il computer in modo che l'utente compri un nuovo processore
piu' potente, di esaurire lo spazio su disco in modo che l'utente compri un
nuovo processore piu' capiente e di rendere  il sistema progressivamente
piu' instabile in modo che l'utente compri un nuovo OS piu' decente.
Usa il file system, Luke...
Ciaotutti,
*

 portarlo sulla cattiva strada?
Da MSDN:
WritePrivateProfileString
The WritePrivateProfileString function copies a string into the specified 
section of an initialization file. 
Note  This function is provided only for compatibility with 16-bit 
versions of Windows. Applications should store initialization information 
in the registry. 
******
Capisco i tuoi discorsi sui registry e colgo anche i vantaggi ad usare 
gli ini files, però prima o poi ci si dovrà adeguare...
-- 
Luc.


Ma chi lo ha detto? :)
MSDN consiglia di usare il registry proprio perche' in questo modo hai tutti
gli effetti che scrivevo sopra.
Il fatto di programmare per piattaforme Microsoft non fa di te un
programmatore Microsoft: pensa con la tua testa, non seguire pedissequamente
le direttive di M$ come una mucca al macello.
Nel registry vanno tenute le minime informazioni indispensabili (dati delle
classi COM, chiavi di registrazione di un programma, alcuni dati "sensibili"
che devono essere accessibili solo all'utente), tutto il resto viene gestito
piu' correttamente usando dei file INI.
Ciaotutti,
*

gli ini files, però prima o poi ci si dovrà adeguare...
Un file ini è facile da modificare anche per un inesperto, il registro
no, inoltre è facile copiare i file ini e sopostarli su un altro
computer o rimetterli sullo stesso dopo una formattazione. Inoltre i
file ini sono anche portabili su qualsiasi piattaforma.
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di it.comp.lang (per i linguaggi di
programmazione senza un gruppo apposito e per i confronti fra i
linguaggi) partecipa alla discussione sul manifesto su it.news.gruppi.

 piu' correttamente usando dei file INI.
Questo e` il tuo parere; io ad esempio ne ho un altro. Il registry e`
utilissimo per i sistemi multiutente (gestire le impostazioni di ciascun
utente - magari in remoto - con dei file .INI deve essere affascinante), e
non vedo assolutamente tutti i difetti che denunciate:
-Per quanto riguarda la dimensione immensa, il degrado di performance
ecc...: fino a poco tempo fa usavo un sistema NT4 installato dal 96, il
registry era arrivato mi pare a una ventina di MB e non dava nessun problema
di performance.
-Per quanto riguarda lo spostamento delle impostazioni da un PC all'altro:
Windows non e` il MacOS, e` quasi sempre una pessima idea spostare un
programma da un sistema all'altro semplicemente facendo una copia della
directory di installazione. Inoltre se proprio uno vuole spostare le
impostazioni da un sistema all'altro lo puo` fare usando regedit e
esportando la chiave: non e` un'operazione "comune", quindi non vedo
l'utilita` di renderla comoda piu` di tanto.
-Per quanto riguarda la facile editabilita` (e cancellabilita`...) dei file
.INI, questo lo considero addirittura un difetto. Un utente non deve essere
MAI messo nella condizione di dovere andare ad editare manualmente le
impostazioni di un programma; deve essere quest'ultimo a fornire ogni
strumento necessario per farlo. Altrimenti il programma e` fallato, e
(commenti ironici a parte :-)) questa e` un'eventualita` eccezionale che non
deve costituire regola.
--
Bye! Lorenzo Lutti

 piu' correttamente usando dei file INI.
sono pienamente d'accordo con *Alessandro*, anche se è vero ciò che dice
Lorenzo Lutti a proposito della multiutenza. inoltre IMO è molto più
comoda la funzione per leggere dai file INI che dal Registry (perché
permette di specificare il valore di default, che verrà utilizzato nel
caso in cui non esista la chiave indicata)
Faber

deve costituire regola.
Tutti i programmi un po' complessi hanno opzioni che possono
difficilmente essere cambiate e che è più comodo modificare
manualmente (ovviamente se sai cosa fare).


 utente - magari in remoto - con dei file .INI deve essere affascinante)
Non vedo la difficoltà.
La cosa si fa da decenni nel mondo unix.
Basta creare un file .ini per ogni utente.
Ciao   Manlio Perillo

l'utente compri un nuovo OS piu' decente.
scusa la franchezza, ma non sai cosa stai dicendo

: 
PS al mio messaggio precedente. M'è venuta la curiosità di vedere
quanti e quali file ini ho attualmente. E di farti vedere che problemi
causa l'uso di file di configurazione. Diamo un'occhiata alla lista
(parziale - riporto solo quelli interessanti, e di questi solo quelli
che usano l'estensione .ini):
D:\home\Hyperion\fp.ini
Questo è dell'IDE del FreePascal. E' al posto giusto ma per il motivo
sbagliato: il programma in questione crea un file di configurazione per
ogni directory in cui viene avviato. Carino e utile, ma ci sono modi
meno confusionari per farlo. Inoltre se il file è nascosto (tutti i
file di configurazione che tengo nella home lo sono) non lo trova,
chiede di crearne uno nuovo, ma dato che esiste già va in errore. Oh
bene, pare di essere ai tempi del DOS. Credo lo sposterò di qui, ma il
vero problema è che parte integrante della configurazione è nelle
variabili d'ambiente, che non è MAI una buona idea. In definitiva devo
solo cambiare le proprietà del link nella quick launch, ma tremo al
pensiero di cosa succederebbe associando i file .pas a detto editor
D:\home\Hyperion\gsview32.ini
GhostScript. Anche questo al posto giusto ma per il motivo sbagliato:
è qui solo perchè ho definito una variabile d'ambiente HOME, sennò chi
sa dove sarebbe
La mia home conta inoltre altri 13 file, di cui 4 usati da Windows (e
tra questi c'è il mio HKEY_CURRENT_USER), 4 messi da me per comodità,
e i restanti 5 imposti da programmi mal scritti o adattati in tutta
fretta
D:\home\Hyperion\Dati applicazioni\Corel [omissis]
La Corel apparentemente c'ha azzeccato. Solo apparentemente perchè ho
dovuto modificare i permessi di un'altra directory per farlo funzionare,
nonostante la configurazione sia qui
D:\home\Hyperion\Dati applicazioni\Opera\adprefs.ini
D:\home\Hyperion\Dati applicazioni\Opera\Opera.ini
Opera, gioie e dolori. Non è stato facile farle accettare che il file
di configurazione fosse qui e non nella stessa directory dell'eseguibile.
In pratica, solito link nella quick launch, le passo il path del file
di configurazione via riga di comando (sperando non me lo cerchi di
aprire come URL, una volta me l'ha fatto), ma se viene avviata in altro
modo, ad esempio per l'apertura di URL via DDE, un casino indescrivibile
D:\home\Hyperion\Dati applicazioni\Qualcomm\Eudora\Eudora.ini
Anche qui, apparentemente, tutto ok. Praticamente, un disastro. Solito
link nella quick launch, solito bisogno di tenere il programma aperto
tutto il tempo per non farlo impazzire
D:\home\Hyperion\Dati applicazioni\XNews [omissis]
Non farti ingannare: in questa directory ho dovuto metterci anche
l'eseguibile. Se anche mio padre usasse questo programma non ho idea di
come potrei fare (anche perchè l'eseguibile da solo stazza oltre 1 MB, e
l'idea di copiarlo a destra e a manca non mi attira per nulla)
D:\programmi\grafica\suite\Corel\Draw9\Config [omissis]
La maggior parte (notare: non tutti) dei file in questa directory si
intendono di sola lettura, e vengono usati come template per le
configurazioni dei singoli utenti. Quindi OK
D:\programmi\media\player\Sonique [omissis]
Pessima scelta. Per liberarmi dell'odiosa playlist di esempio ho dovuto
avviare Sonique almeno una volta da amministratore. Anche il fatto di
salvare le playlist temporanee nella directory di Windows, con nomi di
file che mettono a dura prova i limiti di FAT (e anche di NTFS - ricordo
le ore che passai ad eliminare uno di quei file, con il nome contenente
un "?"), non è stata una grande pensata
D:\programmi\miscellanea\4NT\4NT.INI
Il peggiore in assoluto. Di tutti i programmi per cui un file di
configurazione condiviso tra tutti gli utenti è una cattiva idea, una
shell comandi è sicuramente il peggiore. Persino il file batch di
inizializzazione è condiviso, ma qui è bastato un pizzico di magia:
ALDEBARAN\Hyperion [d:\programmi\miscellanea\4nt]
::more 4start.btm
@echo off
if exist %HOME%\profile.bat call %HOME%\profile.bat
Funziona, ma non dovrei essere costretto a fare cose del genere
D:\programmi\miscellanea\GhostView\gsview\gsview32.ini
D:\programmi\miscellanea\GhostView\gsview\printer.ini
Questi fanno da template per il file di configurazione vero e proprio,
quindi OK. Ma rimane il fatto che serve la variabile d'ambiente HOME
D:\programmi\rete\ftp\LeechFTP [omissis]
Questo è sfuggito alla ricerca automatica, perchè il file ini non è MAI
riuscito a crearlo (e se ne lamenta ogni volta - ricordi quello che ho
detto prima? beh, LeechFTP è scritto in Delphi). Ma io lo ricordo, lo
ricordo molto bene
D:\programmi\rete\posta\Eudora [omissis]
Non ho controllato, ma questi dovrebbero fornire solo i default
D:\programmi\rete\server\Apache\conf
D:\programmi\rete\server\Hamster\Hamster.ini
Questi sono dei server, possono fare quello che gli pare fintantochè
funzionano... inoltre Apache supporta configurazioni multiple tramite
apposito argomento della riga di comando (uno dei "modi meno
confusionari" a cui accennavo). Hamster è viziato dalla sua natura
mista di server/programma interattivo, quindi è un caso un po' a parte
D:\programmi\rete\sharing\Gnucleus\GnuConfig.ini
D:\programmi\rete\sharing\Gnucleus\GnuServers.ini
Orribile. Ho dovuto concedere il permesso di scrittura a Everyone
sull'intera directory. Devo decidermi a spedire la patch al team di
sviluppo
D:\programmi\rete\web\browser\Opera [omissis]
Non posso cambiare i pulsanti della toolbar di Opera senza essere
amministratore. Bella fregatura, vero? no, spostare i file ini nella
directory di configurazione non funziona, ho già provato
D:\WINNT\imagedit.ini
Credo si tratti dell'horrido editor grafico incluso in VB5. Roba
d'anteguerra. Comunque non perdonabile, almeno comprensibile
D:\WINNT\NETSCAPE.INI
Uno dei miei incubi peggiori. Fortunatamente ne sono fuori
D:\WINNT\OLE2VW32.INI
Ole Viewer. Anche questo abbastanza vetusto. La codebase risalirà a
Windows 3.11, probabilmente. Vedi sopra
D:\WINNT\setihome.ini
Stranamente il non riuscire più ad usare Seti@Home dopo l'upgrade a
Windows 2000 non mi stupisce affatto
D:\WINNT\vb.ini
D:\WINNT\vbaddin.ini
Lasciamo perdere che è meglio... ebbene sì: VB 5 era abbastanza vecchio
da fare cazzate del genere
D:\WINNT\vide.ini
Altro IDE mezzo zoppo portato in fretta e furia da Unix
D:\WINNT\winsight.ini
Provare Delphi 4 è degenerato in un disastro, e mi ha lasciato residui
ovunque. Questa è roba sua. Tutto Delphi 4 comunque se ne strafrega
della multiutenza, come dimostra questo inopportunamente posizionato
file di configurazione
D:\WINNT\system32\esentprf.ini
[...]
D:\WINNT\system32\pschdprf.ini
Questi sono giustificati dalle notevoli dimensioni (mediamente 100 KB
l'uno), e apparentemente dalla necessità di essere modificabili senza
strumenti particolari

[...]
Tu citi come problema il fatto che molti programmi mal fatti hanno
problemi a trovare i file ini, ma ci sono anche molti (troppi)
programmi che quando sono installati creano nuove sezioni nel registro
e poi non le cancellano. Un file ini inutile è più semplice da trovare
di una chiave nel registro.


 [CUT]
Molto interessante.
Ma questo problema non è forse dovuto alla mancanza in Windows
di un meccanismo standard per la gestione delle home directory?
Questo è presente solo in Windows2000 (anche se in modo diverso da
Unix).
Ciao  Manlio Perillo

tutto è molto semplice.
I file ini non bastano a coprire tutte le caratteristiche del registro.
Oltre all'esportazione/importazione di file come testo (quello che fa
regedit), anche questa insufficiente, esiste l'esportazione come file
di hive, ossia un file che può essere direttamente copiato dal sistema
nel registro, cosa che si può fare facilmente con regedt32, e meno
facilmente con le apposite funzioni del registry (RegSaveKey e
famiglia). Per i patiti dei file testuali c'è questo duo:
ALDEBARAN\Hyperion [d:\home\hyperion]
::regdmp /?
usage: REGDMP [-h hivefile hiveroot | -w Win95 Directory | -m \\machinename]
              [-i n] [-o outputWidth]
              [-s] [-o outputWidth] registryPath
where: -h specifies a specify local hive to manipulate.
       -w specifies the paths to a Windows 95 system.dat and user.dat files
       -m specifies a remote Windows NT machine whose registry is to be manipulated.
[...]
       registryPath specifies where to start dumping.  Valid prefix names for
          easy access to well known parts of the registry are:
          HKEY_LOCAL_MACHINE -> \Registry\Machine
          HKEY_USERS -> \Registry\Users
          HKEY_CURRENT_USER -> \Registry\Users\...
          USER:   -> HKEY_CURRENT_USER
[...]
ALDEBARAN\Hyperion [d:\home\hyperion]
::regini /?
usage: REGINI [-h hivefile hiveroot | -w Win95 Directory | -m \\machinename]
              [-i n] [-o outputWidth]
              [-b] textFiles...
where: -h specifies a specify local hive to manipulate.
       -w specifies the paths to a Windows 95 system.dat and user.dat files
       -m specifies a remote Windows NT machine whose registry is to be manipulated.
[...]
       textFiles is one or more ANSI or Unicode text files with registry data.
       The easiest way to understand the format of the input textFile is to use
       the REGDMP command with no arguments to dump the current contents of
       your NT Registry to standard out.  Redirect standard out to a file and
       this file is acceptable as input to REGINI
[...]
           Key names can be followed by an Access Control List (ACL) which is a
           series of decimal numbers, separated by spaces, bracketed by a
           square brackets (e.g.  [8 4 17]).  The valid numbers and their
           meanings are:
[...]
           If there is an equal sign on the same line as a left square bracket
           then the equal sign takes precedence, and the line is treated as a
           registry value.  If the text between the square brackets is the
           string DELETE with no spaces, then REGINI will delete the key and
           any values and keys under it.
[...]
           Valid value types and format of data that follows are:
[...]

[...]
Infatti non ho detto che i file ini sono meglio ma che in molti casi
in cui serve solo un luogo dove scrivere alcune semplici informazioni
sono più semplici da gestire.


Unix).
E' presente in tutti i Windows NT. Anzi, ne sono presenti diversi,
ognuno con sfumature particolari. C'è una bella variabile d'ambiente
settata dal logon manager, %userprofile%, che punta alla directory del
profilo, quella che contiene l'hive del registro dell'utente, per
intenderci. Se hai anche una directory home diversa da quella del
profilo, vengono settati %homedrive% e %homepath%. E almeno da Windows
NT 4 in poi c'è %appdata%, se vuoi fare le cose per bene e salvare i
file al posto giusto
Se nel tuo programma includi anche Internet Explorer 4 o, meglio,
shfolder.dll (minuscolo componente di libera ridistribuzione), puoi
anche usare la funzione SHGetSpecialFolderLocation per scoprire dove
si trovano:
 - la directory dei documenti personali
 - il desktop dell'utente
 - i preferiti
 - il menu avvio
 - l'esecuzione automatica
 - i modelli di documento
 - gli strumenti amministrativi
(sì, è necessaria una funzione anzichè una variabile d'ambiente, perchè le locazioni ritornate sono folder, ma non è detto che siano anche delle directory, non so se mi spiego)
Esempio pratico: la patch per Gnucleus che ho preparato e devo spedire
al team per farla approvare (e per testarla, chè io non ho Visual C++)
e a cui mi pare di aver accennato, consiste, tra le altre cose, di
questo (nota: le righe prefissate da un "+" devono essere aggiunte al
file originale, quelle con il "-" devono essere tolte, quelle senza
nulla davanti vanno lasciate invariate e servono a ricostruire il
contesto del testo da modificare):
--- \programmi\rete\sharing\Gnucleus\Source\GnucleusDoc.cpp    Thu Sep 13 00:52:18 2001
+++ GnucleusDoc.cpp    Wed Sep 19 04:15:57 2001
@@ -105,7 +105,74 @@
     GetModuleFileName(NULL, szModule, _MAX_PATH);
     m_RunPath = szModule;
     m_RunPath = m_RunPath.Mid(0, m_RunPath.ReverseFind('\\') + 1);
-    
+
+    // Configuration path
+
+    /*
+    The configuration path is (in descending order of priority):
+     - GNUCLEUSROOT environment variable
+     - <user application data>\Gnucleus directory
+     - %HOMEDRIVE%%HOMEPATH%\Gnucleus directory
+     - %USERPROFILE%\Gnucleus environment variable
+
+    If the path obtained in this way is not valid, the executable's parent directory will be used
+    */
+    LPTSTR szTemp = (LPTSTR)0;
+    DWORD nSize = 0;
+
+    if(nSize = GetEnvironmentVariable("GNUCLEUSROOT", (LPTSTR)0, 0))
+    {
+        nSize = ExpandEnvironmentStrings("%GNUCLEUSROOT%\\", (LPTSTR)0, 0);
+        szTemp = new TCHAR[nSize];
+        ExpandEnvironmentStrings("%GNUCLEUSROOT%\\", szTemp, nSize);
+    }
+    else if(SHGetSpecialFolderLocation(0, CSIDL_APPDATA, &(LPITEMIDLIST)pidl) == NO_ERROR)
+    {
+        LPTSTR szTemp2 = new TCHAR[MAX_PATH];
+
+        if(SHGetPathFromIDList(pidl, szTemp2))
+        {
+            nSize2 = strlen(szTemp2);
+            nSize = nSize2 + strlen("\\Gnucleus\\");
+            szTemp = new TCHAR[nSize + 1];
+
+            strcpy(szTemp, szTemp2);
+            strcpy(szTemp[nSize2], "\\Gnucleus\\");
+        }
+
+        delete[] szTemp2;
+
+    }
+    else if(
+        GetEnvironmentVariable("HOMEDRIVE", (LPTSTR)0, 0) &&
+        GetEnvironmentVariable("HOMEPATH", (LPTSTR)0, 0);
+    )
+    {
+        nSize = ExpandEnvironmentStrings("%HOMEDRIVE%%HOMEPATH%\\Gnucleus\\", (LPTSTR)0, 0);
+        szTemp = new TCHAR[nSize];
+        ExpandEnvironmentStrings("%HOMEDRIVE%%HOMEPATH%\\Gnucleus\\", szTemp, nSize);
+    }
+    else if(nSize = GetEnvironmentVariable("USERPROFILE", (LPTSTR)0, 0))
+    {
+        nSize = ExpandEnvironmentStrings("%USERPROFILE%\\Gnucleus\\", (LPTSTR)0, 0);
+        szTemp = new TCHAR[nSize];
+        ExpandEnvironmentStrings("%USERPROFILE%\\Gnucleus\\", szTemp, nSize);
+    }
+    else
+        nSize = 0;
+
+    // If the path is not empty, exists and is a directory, use it
+    if(
+        (nSize > 0) &&
+        (CreateDirectory(szTemp, 0) || GetFileAttributes(szTemp) != 0xFFFFFFFF) &&
+        (GetFileAttributes(szTemp) & FILE_ATTRIBUTES_DIRECTORY)
+    )
+    {
+        m_ConfPath = szTemp;
+    }
+    else
+        m_ConfPath = m_RunPath;
+
     // Views
     m_pViewConnect   = NULL;
     m_pViewShare     = NULL;
Prima di tutto, riguardo alla logica che ho applicato nella
determinazione del path:
 - iniziamo con una variabile d'ambiente fatta apposta. Questo
   permette di forzare la directory della configurazione, o di
   mantenere configurazioni multiple. Se questa variabile è presente,
   è evidente che l'utente desidera che venga usata questa, e
   nessun'altra, quindi ci fermiamo qui
 - vecchie versioni della Shell API (precedenti alla 4.7) non
   specificavano una directory per i dati delle applicazioni, quindi se
   ci troviamo in un Windows NT 4 poco aggiornato non ci sarà utile, e
   proseguiamo con i due metodi successivi, che sappiamo funzioneranno.
   Se ci troviamo in Windows 98/ME/2000 tutto ok, ci fermiamo qui perchè
   siamo sicuri che la directory è valida (è la funzione stessa a crearla
   se non esiste, o a specificarla se non è specificata)
 - se siamo arrivati qui è perchè molto probabilmente siamo su un NT 4.
   Vediamo se ci è stata assegnata una home. Se la risposta è no,
   ripieghiamo sulla directory del profilo
 - leggiamo la directory del profilo dall'environment, e incrociamo le
   dita... tanto, anche se non funziona, rimane sempre la possibilità di
   definire la variabile GNUCLEUSROOT e decidere la directory che più ci
   aggrada
 - la directory non esiste, non è una directory o semplicemente
   l'euristica per la determinazione della stessa è fallita? ci
   arrendiamo definitivamente, e usiamo la directory dell'eseguibile
Tutto questo casino semplicemente perchè:
 - Gnucleus è un programma da end-user, quindi la maggior parte degli
   utenti avrà Windows 98 anzichè NT, di qui il moltiplicarsi dei
   controlli
 - mi pare di capire che il registro non stia simpatico nemmeno agli
   sviluppatori di Gnucleus. Se voglio che la patch venga accettata
   meglio attenermi. Anche se un semplice valore nel registro che
   puntasse al file di configurazione predefinito sarebbe stato
   sicuramente più pulito di questa manfrina, che sinceramente
   appiopperei al programma di installazione...
Ma in definitiva la patch in cosa consiste? Praticamente ho aggiunto
un nuovo campo all'oggetto rappresentante l'istanza corrente del
programma, chiamato m_ConfPath, da usare al posto del preesistente
m_RunPath - ricavato dal path dell'eseguibile (cosa che significa
sempre guai). Dopodichè ho modificato tutte le righe di codice che
impropriamente usavano m_RunPath, ad esempio:
@@ -165,9 +231,9 @@
 {
     //FreeLibrary(m_hRas);
 
-    m_pPrefs->SaveConfig(m_RunPath + "GnuConfig.ini");
-    m_pPrefs->SaveServers(m_RunPath + "GnuServers.ini");
-    m_pCache->SaveNodes(m_RunPath + "GnuCache.net");
+    m_pPrefs->SaveConfig(m_ConfPath + "GnuConfig.ini");
+    m_pPrefs->SaveServers(m_ConfPath + "GnuServers.ini");
+    m_pCache->SaveNodes(m_ConfPath + "GnuCache.net");
 
     if(m_ShutDown)
         ShellExecute(NULL, "open", m_RunPath + "Evolver.exe", NULL, NULL, SW_SHOW);
Spero che questo abbia chiarito la mia posizione in merito. Sono ancora
aperto alla discussione e lo sarò sempre, dato che questo è il mio terzo
o quarto argomento in ordine di preferenza, in fatto di programmazione.

di una chiave nel registro.
Dipende. Tutto dipende. Questo dipende dalla carenza di editor veramente 
ben fatti per il registro. Dal fatto che Microsoft inizialmente voleva 
addirittura impedire la modifica diretta del registro. Dal fatto che il 
registro è una delle pochissime parti vitali di Windows a non avere un 
posto nel namespace della shell (questo da solo basta a capire come non 
si voglia che il naso dell'utente medio ci si intrufoli). Dal fatto che 
quasi tutte le software house riguardo alla questione registro siano più 
dittatoriali della Microsoft stessa, eppure non compensano con adeguate 
interfacce per la configurazione. Dipende infine dal fatto che il 90% 
degli installer è fatto con il culo, o risale a quando l'avvocato 
Agnelli doveva ancora fare la prima comunione, certamente molto prima 
che esistesse il registro, e quindi dal fatto che nessuno voglia 
adottare Microsoft Installer, credendo che l'unico miglioramento sia 
un'interfaccia più figa (vedi InnoSetup)
Si lamentano che non esiste standard, e quando ne viene proposto uno, 
tutti si credono di capirne di più di Microsoft e non lo adottano. Se ne 
accorgono troppo tardi, quando Microsoft già cerca di rattoppare 
proponendo un nuovo standard che sperano più appetibile del precedente. 
Vedi COM che sta per passare il testimone a .NET: per Microsoft si 
tratta letteralmente del padre che lascia lo scettro al figlio nel 
testamento. Oltre a milioni di dollari che vanno giù per il cesso

 o quarto argomento in ordine di preferenza, in fatto di
programmazione.
e gli altri quali sono?  :)
Faber

 +    else if(nSize = GetEnvironmentVariable("USERPROFILE", (LPTSTR)0, 0))
non ho provato a compilare, pero` questo assegnamento all'interno dell'if
non produce degli warning ?
Mi pare di avere letto che non hai VC, neanche io...  :-(
HTH
ciao
Massimo

o quarto argomento in ordine di preferenza, in fatto di programmazione.
Voglio sapere gli altri! :-)


    controlli
Dici bene. Tutto questo casino nasce a causa di Windows 98 (->Windows 3.1
-> DOS) che sono essenzialmente e totalmente singolo utente.
Windows2000 putroppo si porta appresso questa eredità.
Forse grazie a l'unificazione di WindowsXp le cose cambieranno...
(P.S. molto grave a mio parere non fare supportare a WinXp Home più
 di un processore)
Se nel mondo Unix tutto è più ordinato è perchè è da sempre stato
multiutente.
Fino ad ora in Windows2000 l'unico programma 'serio' che ho visto
è stato ACDSee 4.0.
E' stato l'unico che mi ha chiesto se doveva essere installato anche
per gli altri utenti o se solo per l'amministratore.
Questo lascia spazio ad un'altra domanda.
Posso installare una aplicazione come utente semplice in modo
che sia visibile solo a me?
Ciao  Manlio Perillo

per gli altri utenti o se solo per l'amministratore.
Bhé ma ci sono tanti "bei" programmi che si installano come se fossero
su winnt anche su win98, io invece ho il problema opposto non conosco
a fondo il comportamento di winnt per la gestione degli utenti (ho
solo win9.x) e quindi non sarei in grado di pogrammare un software
serio per un sistema multiutente.


e poi non le cancellano.
Anche perché troppi utenti cancellano i programmmi senza
disinstallarli.


dell'if non produce degli warning ?
Non dovrebbe, è una tecnica molto comune. Al massimo può avvertirmi che 
potrei stare cercando di confrontare due espressioni con l'operatore di 
assegnazione

Voglio sapere gli altri! :-)
Vedi risposta a Faber :)

 usare <windows.h> come ti comporteresti?
Rinuncerei. La portabilita` al 100% non esiste, a meno che non si tratti di
programmi assai semplici o piattaforme assai simili. Se vai a vedere i
sorgenti di tutti i programmi un po' complessi che si compilano sotto a piu`
piattaforme, noterai una cospicua presenza di macro #ifdef
_UNACERTAPIATTAFORMA_ ...
--
Bye! Lorenzo Lutti

sistema operativo
Io in realtà stavo pensando ad un programma Python che non usa le api,
per aggiungere solo questa caratteristica ciò che devo definire
aumenterebbe molto.


e gli altri quali sono?  :)
Il mio preferito in assoluto è il kernel di Windows NT, nonostante 
l'oscurità che lo avvolge. E quindi: oggetti del kernel, device driver, 
sottosistemi e altri eseguibili nativi, e lo stupendo modello di 
sicurezza. E ovviamente il registro :)
E' seguito a breve distanza dalla programmazione cross-platform: 
mantenere una sola codebase per più sistemi operativi, scrivere codice 
portabile, sfruttare al massimo le potenzialità di ogni sistema 
operativo, eccetera. A questo proposito, sono contrario alle librerie di 
compatibilità, come Cygwin, e in generale a tutte le forzature, e 
propendo piuttosto per librerie di astrazione, come la CLX di Borland
Poi viene l'usabilità. Progetto di interfacce grafiche e design in 
generale. Ottenere un software facile da usare ma non banale, potente ma 
non per soli iniziati. Coerente e pulito. Ma soprattutto che rispetti 
l'utente
Infine l'ambiente Windows. Non l'API Win32 che a tratti è deludente, ma 
l'ambiente, e l'integrazione con esso. E quindi, soprattutto, utilizzo 
di e supporto per COM: interagire con la shell, esporre classi di 
oggetti istanziabili e programmabili, implementare interfacce per 
estendere componenti esistenti. Ma anche un uso proprio del registro, di 
piccoli componenti come la tray area, supporto per la multiutenza, e 
tante altre piccole cose
(sembra quasi un'intervista :)

che sia visibile solo a me?
Sì. In Windows 2000 tutte le funzioni e i componenti che fanno uso del 
registro lo fanno in una maniera molto più intelligente: prima cercano 
chiavi e valori in HKEY_CURRENT_USER, se l'operazione fallisce riprovano 
con HKEY_LOCAL_MACHINE. In pratica: se l'utente l'ha configurato, usa la 
sua configurazione, altrimenti leggi i valori predefiniti.
Prova ad esempio a copiare una delle voci dei programmi installati da 
dove si trovano (HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
\CurrentVersion\Uninstall) a un path identico ma che si trovi in 
HKEY_CURRENT_USER. Ora apri "installazione applicazioni" nel pannello di 
controllo, e stupisciti
Funziona anche con i componenti OLE. Praticamente questo significa che 
ora è possibile installare degli ActiveX per uso personale senza essere 
amministratori. Quelli attualmente esistenti non lo supportano, ma basta 
un RegSvr32 un po' più "furbo" per risolvere molto facilmente, grazie ad 
un'altra utile funzione introdotta in Windows 2000...

XP ha parecchie limitazioni poco pubblicizzate.
XP Home?


macro #ifdef _UNACERTAPIATTAFORMA_ ...
C'è GNU Autoconf che è già un passo avanti, serve proprio ad evitare 
cose del genere: non ti interessano le piattaforme, ti interessano le 
sue *caratteristiche*. E quindi: che compilatore C posso usare, dove si 
trova, che cosa può fare, dove trovo gli header, le librerie, dove 
installo il programma, eccetera. Il problema? Autoconf funziona solo su 
Unix. E funziona bene: *BSD, Linux, Solaris, SunOS, Aix, Autoconf li 
conosce tutti e genera sempre i makefile giusti. Ma è perfettamente 
inutile se si usa su MacIntosh o su Windows (e lo so bene). Inoltre 
risolve solo i problemi dei programmatori, non degli utenti
Allora come si fa? Ci sono diverse strade, nessuna è quella definitiva, 
anche perchè la perfezione si paga cara:
 - emulazione. Vedi Cygwin, U-Win, Wine e mille altri. Quello che io
   chiamo "forzare il piolo tondo nel buco quadrato". Miopia ("deve
   funzionare! in fondo si tratta solo di reimplementare quelle due-tre
   librerie di sistema...") o ignoranza ("che schifo questo sistema
   operativo, non ha la caratteristica X! dovrò usare Y e Z per
   emularla"). Nella maggior parte dei casi funziona (Cygwin per esempio
   è ufficialmente piattaforma supportata da Autoconf), nel senso che
   almeno il programma compila...
 - minimalismo. Si scrive in codice portabile un subset minimale del
   programma e si spera che qualcun altro se lo prenda abbastanza a
   cuore da aggiungere quello che manca. Vedi i programmi zip e unzip,
   della InfoZip
 - eclettismo. Conoscenza di tutte le piattaforme che si intende
   supportare.
   Su Windows:
    - gli utenti si aspettano:
       - un'interfaccia grafica, il più integrata possibile (menu
         contestuali, drag&drop, finestre di dialogo standard,
         eccetera)
       - un file help con sommario e indice
       - manuale in formato PDF per la stampa
       - di trovare nel menu avvio le icone del programma installato
       - supporto completo per il file system
       - integrazione nella shell (menu contestuali, icone e
         associazioni per i file, ma non solo)
    - gli amministratori si aspettano:
       - di poterlo disinstallare dal pannello di controllo
       - che sia configurabile tramite pannello di controllo o console
         MMC
       - che rispetti le policy
       - che supporti la multiutenza
       - che rispetti gli altri programmi installati (che quindi non
         sovrascriva librerie altrui, che si installi nelle directory
         giuste, eccetera)
    - i programmatori si aspettano:
       - di poter usare tutte le funzionalità del programma tramite una
         dll
       - interfacce COM utilizzabili anche da linguaggi limitati, come
         Javascript o Visual Basic
       - type library per i suddetti linguaggi
       - file header e import library per i programmatori C
       - unit per i programmatori Pascal
   Su Unix:
    - gli utenti si aspettano (ma spesso si accontentano di meno):
       - integrazione con almeno uno dei maggiori toolkit per interfacce
         grafiche (generalmente si punta su Motif). Qui aiuta molto QT
       - documentazione in formato Man o TexInfo, installata al posto
         giusto e ragionevolmente completa
       - manuale in formato PostScript per la stampa
       - integrazione con almeno un ambiente desktop (un'utopia)
       - configurazione posta in ~/.nomeprogrammarc o ~/.nomeprogramma/
       - tutte le funzioni accessibili da riga di comando
       - possibilità di avere l'output su stdout, per passarlo ad altri
         programmi senza file intermedi
    - gli amministratori si aspettano:
       - un file di configurazione predefinito in /etc
       - supporto per la multiutenza
       - rispetto dello standard sulla gerarchia del file system
    - i programmatori si aspettano (e non si accontentano):
       - di poter interagire con il programma tramite pipe e/o socket
       - che tutti i formati usati siano testuali o almeno documentati
       - file header e import library
       - documentazione delle funzioni in formato Man
   Sembra una cosa impossibile, ma ad esempio Opera accontenta
   ragionevolmente quasi tutte le categorie di utenza su tutti i sistemi
   supportati. Riguardo alla documentazione si ricorre all'astrazione,
   scrivendola in un formato universale (come DocBook, una DTD per XML)
   e convertendola in tutti i formati necessari (prodigi dell'XML).
   Sulla configurazione mi sono già pronunciato. Il vero vespaio è non
   tanto l'interfaccia grafica, al giorno d'oggi siamo messi un po'
   meglio di anni fa (quando i manuali sul porting dicevano senza stare
   a ricamarci su: riscrivetevela da zero), ma piuttosto l'integrazione
   nel desktop. In generale, lo si fa tranquillamente in Windows, e su
   Unix se ne sceglie uno, al massimo due. Oppure non lo si fa affatto

aumenterebbe molto.
In realtà in un caso come questo la cosa più semplice è costruirsi una
piccola estensione in C con una funzione che faccia quello che vuoi il
sorgente python sarebbe portabile e non dovrei portarmi in giro un bel
po' di librerie per una semplice funzione.


 - eclettismo.
Che il piu` delle volte significa appunto usare molte macro di
preprocessore. :)
--
Bye! Lorenzo Lutti


Ma per fare una cosa del genere devo sempre passare per l'Amministratore, no?
Ciao e grazie  Manlio Perillo

Un'idea simpatica e` quella di MojoNation
Ovviamente è scritto in Python :-)
Però io trovo che la sua interfaccia grafica non sia un granché.


agevolando le operazioni di backup.
Sembra che tu stia parlando di unix...


 (sembra quasi un'intervista :)
...non abbiamo fatto in tempo a parlarne al Meeting di ICLVB  :)
Faber

l'Amministratore, no? 
Prova. Devi solo esportare una chiave qualsiasi, cambiare il nome della 
chiave, cambiare la root in HKEY_CURRENT_USER e reimportarla. Che poi il 
programma per essere realmente disinstallato necessiti di privilegi da 
Administrator, è un'altra storia. Qui sto solo cercando di dimostrare 
che *teoricamente* l'installazione di programmi come User non ha alcuna 
limitazione

te ne accorgi č perchč Explorer emula Program Manager)
Sbaglio o anche il programma di installazione per le applicazioni VB6
fa la stessa cosa?


> scusa la franchezza, ma non sai cosa stai dicendo
E infatti Microsoft non consiglia di formattare le macchine di sviluppo ogni
sei mesi.
E da nessuna parte e' mai stato scritto che se il computer rallenta va
formattato.
E nessuno ha mai consigliato di crearsi un ghost con l'installazione
ottimale in modo da poter ripristinare facilmente la configurazione quando
il PC diventa un chiodo.
E non vi e' alcuna ragione di mantenere i programmi su una partizione
diversa da quella del sistema, visto che non si verifica mai la necessita'
di formattare la partizione di sistema...
E via dicendo :)
Ciaotutti,
*


Il programma di installazione di VB6 e' uno spettacolo, perche' e'
scritto... In VB6 :)
Infatti esistono DUE programmi di setup, il primo che fa comparire la
finestrella "please wait copying..." che installa le runtime minime di VB,
il secondo (customizzabile) che esegue l'installazione vera e propria.
Puoi studiartelo con cura cercando setup1 sotto PDW, directory wizards, se
la memoriua non mi inganna, sotto il path di installazione di VB.
Ciaotutti,
*

il secondo (customizzabile) che esegue l'installazione vera e propria.
Appunto nel secondo c'è una label con scritto qualcosa del genere
"Questa label serve per la comunicazione DDE con Program Manager".



Mica e' impossibile... "Se non e' rotto non aggiustarlo" e' un motto valido
anche in programmazione...
Ciaotutti,
*