Newsgroup: it.comp.lang.vo-clipper
Titolo: Ricerca in memoria ...

Buona giornata a tutti.
Qualcuno è in grado di dirmi se esiste la possibilità di sapere quando
l'eseguibile "rilascia" se stesso e le sue DLL dopo l'istruzione self:quit()
?
Mi spiego:
Un applicativo si accorge che vi sono aggiornamenti da scaricare... lancia
un secondo programma di aggiornamento e si chiude... (il nuovo prg è in una
dir differente con proprie dll)
In nuovo programma lanciato, a volte, trova ancora in uso alcuni file
(quelli utilizzati dal precedente programma).
E' possibile, invece che ritardare l'apertura del nuovo programma
indiscriminatamente (a volte i file colpevoli non sono interessati
all'aggiornamento), ritardarlo con un eventuale loop "whileevent" solo nel
caso in cui il file da copiare sia ancora in uso ?
Spero di essermi spiegato
Ringrazio in anticipo.
Giancarlo

Mi rispondo chissà possa tornare utile:
Se prima di copiare i file tento di aprirli in maniera esclusiva (per lo
meno l'eseguibile che so possa essere ancora in memoria) con il comando
fopen(...
posso controllare se il file è libero oppure meno. E quindi solo in
quest'ultimo caso parcheggiare il mio aggiornamento ......
Buon lavoro a tutti
e grazie al news inglese attivo come al solito.
Giancarlo

 ha scritto nel messaggio
news:CeLb8.65834$om6.1...@news1.tin.it...
Nel C c'e' qualcosa come WaitObject per controllare lo handel di un
applicazione, in questo caso del processo padre.

/*
-------------------------------------------------------------------------
 Funzione..: RunProcess
 Utilizzo..: esecuzione di un file con contollo dello handle
 Ritorna...:
 Note......:
-------------------------------------------------------------------------
*/
BOOL RunProcess ( LPSTR cmdline )
 {
 STARTUPINFO    si;
 PROCESS_INFORMATION pi;
 BOOL      retval = FALSE;
 ZeroMemory( &si, sizeof(si) );
 si.cb = sizeof(si);
 // Start the child process.
 retval =
 CreateProcess( NULL,     // No module name (use command line).
      cmdline,    // Command line.
      NULL,             // Process handle not inheritable.
      NULL,             // Thread handle not inheritable.
      FALSE,            // Set handle inheritance to FALSE.
      0,                // No creation flags.
      NULL,             // Use parent's environment block.
      NULL,             // Use parent's starting directory.
      &si,              // Pointer to STARTUPINFO structure.
      &pi           // Pointer to PROCESS_INFORMATION structure.
      );
 if ( retval )
  {
  // Wait until child process exits.
  WaitForSingleObject( pi.hProcess, INFINITE );
  // Close process and thread handles.
  CloseHandle( pi.hProcess );
  CloseHandle( pi.hThread );
  }
 return retval;
 }

 applicazione, in questo caso del processo padre.
No, non nel C ma nelle API di Windows: si può utilizzare la
GetModuleUsage()
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 GetModuleUsage()
Si, scusatemi... abitudine old-style.
Il fatto è che mi viene spontaneo usare il C per accedere al sistema, anche
perchè la documentazione delle API ha sempre fatto riferimento ad una
sintassi dei comandi in C, header compresi.

 sintassi dei comandi in C, header compresi.
Sicuramente il linguaggio "naturale" per le API Windows è il C. Però
attenzione a non farle diventare parte del C standard (come vorrebbe la
Microsoft...).


 Microsoft...).
Microsoft tende a far suo quello che e' stato creato da altri
    (vedi C/C++, Java, Stacker, NDD, Internet ecc.).
Per quanto riguarda il concetto di standard, penso che sia un utopia da 6
mesi circa.

 mesi circa.
Assolutamente no! Fintanto che esisterà uno standard C e uno standard
C++ ratificati dall'ISO (l'ente standardizzatore internazionale) ci si
potrà riferire a questi due linguaggi come "standard".


 potrà riferire a questi due linguaggi come "standard".
e adattare il codice da "C ANSI" a "C Borland" a "C MS" a "C Watcom"...

 e adattare il codice da "C ANSI" a "C Borland" a "C MS" a "C Watcom"...
Scrivendo in C o in C++ standard non c'è bisogno di alcun adattamento,
ammesso che i compilatori citati siano conformi. Il problema sorge
quando si utilizzano funzioni non standard che ogni compilatore è quindi
libero di implementare o meno nella forma che vuole. Questo discorso
però è ben diverso dal dire che parlare di standard è un'utopia. Perché
sei mesi poi?...


 Perché sei mesi poi?...
ovvio che era un'esagerazione

 che creano forti dipendenze.
Si, ma anche quelle possono essere trattate nel giusto modo, ad esempio
incapsulandole in parti del codice ben sotto controllo e non
"inquinandone" l'intero progetto.


 ha scritto nel
messaggio news:3C727EEF...@emagsoftware.it...
