Newsgroup: it.comp.os.win.xp
Titolo: Restart Manager in Windows Vista

Con Windows Vista gli utenti non devono riavviare il computer per la
maggior parte degli aggiornamenti o dopo l'installazione di
un'applicazione. Windows Vista conosce quali applicazioni e servizi
stanno usando determinati file, e se un file deve essere aggiornato,
Windows Vista può coordinare il salvataggio dei dati
dell'applicazione, chiudere l'applicazione o stoppare il servizio,
aggiornare il file, e automaticamente riaprire l'applicazione o far
ripartire il servizio. Questa capacità è fornita da una feature
chiamata Restart Manager.
Restart Manager funziona con Microsoft Update, Windows Update,
Microsoft Installer, ecc. e le applicazioni che sono state scritte per
avvantaggiarsi del nuovo Restart Manager possono ripartire e
ripristinarsi allo stesso stato e con gli stessi dati che avevano prima
del restart.
http://groups.google.com/group/P4_Werterxyz/
Saluti da P4

 ha scritto nel messaggio 
news:1130051360.3...@f14g2000cwb.googlegroups.com...
Con Windows Vista gli utenti non devono riavviare il computer per la
maggior parte degli aggiornamenti o dopo l'installazione di
un'applicazione.
CUT
Ma va? Che figata, dillo a chi usa Linux che loro non hanno mai riavviato...
Fabio 

 riavviare il computer
E' un altro accrocchio MS style (come la dllcache)... invece che modificare
la gestione del file lock hanno scelto una soluzione che permette, solo in
certi casi, di non dover riavviare.

 certi casi, di non dover riavviare.
Non hai capito un fico secco! Questo Restart manager consente di
sostituire file dll ecc. che sono attualmente in uso e quindi anche i
file bloccati saranno sostituibili. 
Saluti da P4

 file bloccati saranno sostituibili.
Ci sono arrivati adesso ??
.:[CRT]:. che riderebbe fino al 2050 se P4 ha un Audi o una Wolkswagen: la 
centralina monta un processore AMD. 

 riavviare il computer
Fantastico! Quando scoprirarro il fuoco e la ruota?
-- 
IBM: Idiots Being Mental
News 2000 [v 2.06] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 Saluti da P4
Fatti una sega con davanti Novella 2000, mentecatto! 

 file bloccati saranno sostituibili.
Ma l'hai letto il testo che hai copia-incollato?
Te lo riquoto:
"se un file deve essere aggiornato, Windows Vista può coordinare il
salvataggio dei dati dell'applicazione, chiudere l'applicazione o stoppare
il servizio,
aggiornare il file, e automaticamente riaprire l'applicazione o far
ripartire il servizio. Questa capacità è fornita da una feature
chiamata Restart Manager."
In particolar modo la sequenza:
1. Salvataggio dei dati.
2. Chiusura applicazione.
3. Aggiornamento del file.
4. Riapertura dell'applicazione.
Indica chiaramente che la sostituzione dei files locked non è possibile
neanche su Vista.
Se la sostituzione dei files locked fosse possibile, la sequenza sarebbe
stata questa:
1. Freeze del processo in questione con tutti i suoi threads.
2. Sostituzione del file lockato.
3. Resume del processo e dei threads.

 3. Resume del processo e dei threads.
In Windows vista esistono 2 tecniche per applicare le patch:
1) l'hot patching che consente di applicare le patch direttamente in
MEMORIA, caricando in memoria le nuove dll, aggiornando i riferimenti
ecc. e rimandare l'aggiornamento fisico del file solo dopo che il
servizio o l'applicazione è ripartita.
2) il warm patching che consente di sbloccare i file in uso (unlock)
con una tecnica semplice: stoppare tutti i servizi e tutte le
applicazioni che stanno usando quei file, aggiornare i file, far
ripartire i servizi e le applicazioni che usavano quei file e
ripristinare il loro stato. Quindi l'unlock dei file è svolto
correttamente in Windows Vista.
A seconda dei casi Windows Vista applica l'una o l'altra tecnica o
entrambe.
Saluti da P4

 
Bla Bla Bla pubblicita' ??!!
(Difficile postare una sola volta e ?)

 Saluti da P4
[/stracuttone]
Azzz avete visto????
Win$ sta' colmando il divario
con Gnu-Linux......ancora una decina
di anni e poi Win$ assomigliera' a
Linux del......... 2005  ^_^
Byezzzzz e Happy Linux....!!!

stoppare tutti i servizi e tutte le applicazioni che stanno usando quei
file, farli ripartire e ripristinare il loro stato.
In entrambi i casi Windows non è in grado di sovrascrivere un file locked,
per farlo deve, o rimandare l'aggiornamento del file fino a quando esso non
viene sbloccato (e ciò spesso coincide col riavvio) o fare l'unlock del file
chiudendo e poi riaprendo i programmi/servizi che lo stanno utilizzando.
Come dicevo prima, si tratta di "accrocchi", e cioè di palliativi ad un
problema che avrebbe dovuto essere risolto rimettendo mano al kernel e
rivedendo le politiche di locking invece che limitarsi ad usare questi
trucchetti.

 trucchetti.
La soluzione adottata in Windows Vista è migliore perchè consente di rendere 
tutte le applicazioni consistenti con le nuove dll. Un semplice unlock 
brutale non garantisce una completa consistenza. 

 file bloccati saranno sostituibili. 
Se il software č stato scritto per sfruttare tale feature, come tu
stesso hai detto.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 brutale non garantisce una completa consistenza. 
E sì che mi pareva che i vari *x non avessero di questi problemi, pur
mantenendo la consistenza.


 mantenendo la consistenza.
e in che modo? o patchando in memoria (hot patching) o riavviando 
l'applicazione e il servizio (restart manager) cioč esattamente come fa 
Windows Vista. Altri modi non esistono.

>servizio o l'applicazione è ripartita.
Che te ne frega di rimandare l'aggiornamento fisico del file quando l'hot 
patching ti patcha in memoria e non ti costringe di riavviare?
Se hai tanta fretta hai il warm patching che stoppa e riavvia i servizi 
consentendo l'aggiornamento fisico del file.
Rileggi quello che dice P4:
"In Windows vista esistono 2 tecniche per applicare le patch:
1) l'hot patching che consente di applicare le patch direttamente in
MEMORIA, caricando in memoria le nuove dll, aggiornando i riferimenti
ecc. e rimandare l'aggiornamento fisico del file solo dopo che il
servizio o l'applicazione è ripartita.
2) il warm patching che consente di sbloccare i file in uso (unlock)
con una tecnica semplice: stoppare tutti i servizi e tutte le
applicazioni che stanno usando quei file, aggiornare i file, far
ripartire i servizi e le applicazioni che usavano quei file e


 Windows Vista. Altri modi non esistono.
ti è stato detto prima:
1. Freeze del processo in questione con tutti i suoi threads.
2. Sostituzione del file lockato.
3. Resume del processo e dei threads.
senza chiudere l'applicazione o modificare la memoria, come ne esiste
almeno uno di metodo.
Bye, Giubbe

 Rileggi quello che dice P4:
Sei sempre tu P4 vero?

 3. Resume del processo e dei threads.
Si ma in quel caso quando rimetti in esecuzione il processo dopo la
"pause", quello sta ancora lavorando sui dati prodotti dalla vecchia
dll, quindi è inconsistente con le nuove dll; se vuoi che sia
nuovamente consistente lo devi rimettere in esecuzione e quindi ricadi
per forza nel meccanismo di Windows Vista che prevedere la riesecuzione
del processo/servizio da capo.
Quindi non serve a nulla forzare l'unlock dei file per patchare se poi
tutte le applicazioni stanno ancora lavorando con le vecchie dll e con
i vecchi dati prodotti da quelle vecchie dll. Windows Vista è
superiore in questo.
Saluti da P4

 dll,
Che stai a dì? Guarda che le patch non modificano il risultato, ma solo in
modo in cui viene prodotto! Se un programma si aspetta, in uscita da una
funzione della dll, un intero con un preciso significato anche dopo la
patch tale risultato avrà lo stesso significato altrimenti dovresti
cambiare tutto il programma e non solo la dll!
In caso di correzione di bug il programma malfunzionava prima della patch e
se proprio in quel momento stava elaborando quel dato continuerà a
malfunzionare fino a quando l'utente non richieda nuovamente l'elaborazione
dell'input. Per esempio, se il programma alla richiesta dell'apertura di
una dialogbox presentava un messaggio di errore, subito dopo la patch
(nella tua ipotesi di sostituzione dopo aver effettuato la chiamata)
apparirà lo stesso errore. Sarà corretto nell'istante in cui l'utente
ritenta l'apertura della finestra.
Lo stesso dicasi per qualsiasi altra elaborazione in cui ci sia una
correzione di un errore, ma è l'utente e non il SO che di volta in volta
decide se è il caso di riaviare l'applicazione.
bye

 ritenta l'apertura della finestra.
STRONZATE. Perchè il programma ha già caricato il codice della dll e
se non rimetti in esecuzione il programma dall'inizio il codice è
sempre lo stesso, quindi il bug c'è ancora, ecco perchè forzare
l'unlock di un file non ha senso se non si rimettono in esecuzione le
applicazioni.
Saluti da P4

 STRONZATE. Perchè il programma ha già caricato il codice della dll
Inutile discutere con un ignorante! Nemmeno il programma è caricato
completamente in memoria (fin dai tempi del DOS!, si usava l'overlay),
figurati una libreria dinamica!
Ma anche ammettendo che tu abbia ragione il SO potrebbe benissimo
ricaricare in memoria la DLL modificata!
Del resto Linux funziona così e bene fin dalla nascita quindi ciò che tu
ritieni impossibile è nei fatti stato già implementato diversi anni fa.
bye

1) l'hot patching che consente di applicare le patch direttamente in
MEMORIA, caricando in memoria le nuove dll, aggiornando i riferimenti, ecc.
e rimandare >l'aggiornamento fisico del file solo dopo che il servizio o
l'applicazione è ripartita.
In quale modo pensi che si faccia ad applicare una patch direttamente in
memoria senza freezare il programma?
E ancora, se è possibile applicare la patch direttamente in memoria
caricando le nuove dll al posto di quelle vecchie, che senso ha rimandare
l'aggiornamento fisico del file su disco? Come vedi "cambiare la politica
del file locking" avrebbe senso eccome!

 ricaricare in memoria la DLL modificata!
Ho ragione io anche perchè secondo il ragionamento che avevi fatto
prima che bastava cambiare il file della dll perchè il programma se ne
accorgesse della nuova dll, implicherebbe che ad ogni chiamata di
funzione l'applicazione o il sistema opearativo dovrebbe rileggerla dal
file cioè accedere al disco, cosa CHE OVVIAMENTE NON E'.
Inoltre quello che tu dici di ricaricare la dll è esattamente quello
che fa l'hot patching di Windows Vista...
Anzi più precisamente non basta un semplice ricaricamento della dll
perchè le DLL non vengono caricate in zone a caso di memoria, ma nella
porzione di memoria associata ai processi che la richiedono, quindi un
semplice caricamento non basta, occorre caricarlo nella zona di memoria
associata al processo. 
Saluti da P4


X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7.12) Gecko/20050915,gzip(gfe),gzip(gfe)
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

che fa l'hot patching di Windows Vista...
Visto che č possibile? Gestisce bene il lock e non devi riavviare alcunchč,
ma per te č dura capirlo!
Bye

 
beh 
anche alla m$ si sono accorti di questa utilità
cmq la vedremo sul campo
:)

 
frena 
vai troppo di fretta
:)
prima hanno scoperto l'acqua fredda
dopo che serviva a lavarsi
ora dagli tempo di capire come scoprire il fuoco x scoprire anche l'acqua
calda no?
:)

 
oh che bello
pensa ai prox worms 
eh eh

 si parla di Windows).
Vengono caricati solo la prima volta nel momento in cui devono essere
usate per la prima volta, dopo di che ci rimangono e si usa sempre quel
codice. Quindi se tu la sostuisci l'applicazione continua ad usare il
vecchio codice. Se così non fosse ad ogni chiamata di funzione
occorrerebbe rileggere la dll dal disco e i nostri dischi non si
fermerebbero mai :-)
Saluti da P4

 fermerebbero mai :-)
Per te "memoria virtuale", "pagina di memoria", "page fault" e
"working set" sono parole senza senso, vero?


 "working set" sono parole senza senso, vero?
la dll viene caricata 1 volta sola o all'inizio del programma o solo la
prima volta nel momento in cui deve essere usata per la priva volta una
funzione contenuta in essa, dopo di che il programma continua ad usare
sempre lo stesso codice. Poi se nel frattempo quell'area di memoria
fisica finisce in memoria virutale cioè su disco nel file di swap, è
comunque una pagina che non viene cambiata, cioè quando ritorna in
memoria fisica hai comunque sempre il codice della vecchia dll
contenuto in quella pagina, cioè in parole povere IL FILE DELLA DLL
NON VIENE MAI PIù RILETTO, QUINDI SE TU LO CAMBI L'APPLICAZIONE NON
PUò ACCORGERSENE.
Saluti da P4

 anche alla m$ si sono accorti di questa utilità
Meglio tardi che mai, diceva qualcuno... Nel mentre preparerò un rito 
voodoo, per assicurarmi che nulla si frapponga fra questa affermazione e il 
risultato finale, perché ancora non mi fido molto ;-)
-- 
サムエレ 

 la dll viene caricata 1 volta sola o all'inizio del programma o solo la
Tu vivi nel mondo delle favole, e non sarò certo io a dirti come funziona.
Vai a rileggere il libro di Sistemi Operativi, e poi vai a ridare l'esame,
se mai lo hai dato...
Bye

 C:\>iao Angelo
Inutile sprecare byte, lui non capirą mai, al limite si accorge di non
sapere ribattere e file via. 
Tempo sprecato "parlare" con P4.
Bye

 Tempo sprecato "parlare" con P4.
Leggi qui e crepa idiota!
http://groups.google.com/group/comp.os.ms-windows.programmer.misc/browse_frm/thread/9a97466974957b6b/788b30720c921622?lnk=st&q=replace+a+dll+in+use&rnum=4#788b30720c921622
"running you may be able to rename or move the file and copy a new file
with
the old file name, but the running programs will continue to use the
old
file until the programs are restarted."
GJC [MS Windows SDK MVP]
Software Consultant (Embedded systems and Real Time Controls)
http://www.mvps.org/ArcaneIncantations/consulting.htm-gchan...@mvps.org
traduzione: "ma i programmi che sono in esecuzione continueranno ad
usare il vecchio file di dll fino a che non vengono fatti ripartire"
Saluti da P4

 Bye
Leggi qui e crepa idiota!


 rename dll_new with dll?
    In both cases, you can't.  Depending on what operating system
you're
running you may be able to rename or move the file and copy a new file
with
the old file name, but the running programs will continue to use the
old
file until the programs are restarted.
--
-GJC [MS Windows SDK MVP]
-Software Consultant (Embedded systems and Real Time Controls)
-
http://www.mvps.org/ArcaneIncantations/consulting.htm-gchan...@mvps.org

 with
Ma non dire fregnacce che poi qualcuno ti crede. Sempre che si sia ancora
qualcuno che ha il coraggio di credere alle tue parole. 
Rispondo per l'ultima volta poi torna sul libri o restituisci la laurea!
http://support.microsoft.com/default.aspx?scid=kb;en-us;140570
I programmi continueranno ad usare il vecchio file semplicemente perchè la
sostuzione vera e propria avverrà al riavvio!
Finisco qui perchè una persona intelligente già ha capito come funziona e
pure che è tecnicamente fattibile. Tu continua pure a stare nel tuo brodo!
Bye

 un'applicazione.
Che figata! Ecco quello che tutti aspettavano per tornare a Win!
;-)
-- 
Attila, Powered by 2.6.13.3

 sostuzione vera e propria avverrà al riavvio!
Ha ragione P4, inutile che ti arrampichi rigirando la frittata. Prima hai 
detto una cosa poi la neghi e ne stai dicendo un altra. Rileggi il discorso 
dall'inizio.