WinXP che ne pensate?
SiemensMAN
Salve a tutti
Che ne pensate di Windows XP versione Professional?
Microsoft sta facendo passi avanti?
Saluti
dbia...@square.nl
> Che ne pensate di Windows XP versione Professional?
> Microsoft sta facendo passi avanti?
Secondo me no. Windows come sistema operativo ha 4 gravi difetti,
che non sono stati corretti e (mi sa) ci vorra' parecchio prima
che vengano corretti:
1. il sistema e' troppo 'bloccato' sulla sua interfaccia.
Tutte le funzioni dipendono dalla presenza dell'interfaccia
grafica, questo impedisce la creazione di tutti quegli scriptini
di automazione che sono tanto comodi in Unix. Inoltre impedisce
una facile integrazione tra varie "semplici" utility per creare
utility piu' complesse.
2. manca un "vero" sistema di controllo dei processi
se uno dei processi 'muore' inaspettatamente ci sono ottime
probabilita' che l'intero sistema ne risenta, inoltre e' impossibile
controllare lo stato di un processo (Windows non ha idea di cosa
stiano facendo i vari processi), ne' e' possibile uccidere o rimuovere
un processo in maniera sicura. Questo e' un serio problema e costringe
spesso al riavvio dell'intero sistema per aggiornare un singolo
processo.
3. manca un "vero" sistema di comunicazione tra i vari processi.
OLE, DDE, COM, MMF etc. sono dei palliativi inventati via via per
aggirare questo inghippo. La verita' e' che non esiste un vero sistema
di comunicazione tra i vari processi, il che rende impossibile
una vera coesione tra i vari programmi.
4. Il sistema viene rilasciato privo di tutti quegli strumenti di
utilita' che servono per automatizzare ed eseguire le operazioni
di routine (backup/amministrazione etc.), tutto questo e' ottimo
per altri produttori di software (Norton, Symantec etc.), ma significa
che l'utente oltre a pagare la licenza (costosina) di Windows deve
*anche* pagare tutti i tools aggiuntivi....
Davide
thorin_...@gruppocm-cs.it
> Salve a tutti
> Che ne pensate di Windows XP versione Professional?
> Microsoft sta facendo passi avanti?
Dipende se hai o meno gli occhi da gambero.
--
Pierluigi De Rosa (tho...@durin.khazad-dum.net).
<< LINUX: the choice of a GNU generation >>
<< For my real address... ask the Balrog. >>
* Sostenete la Lega per la Soppressione dei Troll *
Zio Ciano
Mah! Un mio collega (m$ developper extremed absoluted optused) mi ha fatto
vedere la beta 2 (credo ndr).
La prima cosa che mi ha fatto notare e' la mitica "interfaccia"; il bellissimo
effetto dissolvenza dei menu e una cosa nuova:
-vedi se io trascino un file nel menu nel cestino vedi il file in trasparenza
dentro il cestino come fosse di plastica trasparente; figo vero-.
CAZZO!! (Ho detto) ma e' una figata... M$ si che sa fare le cose serie.
Te saludo.
--
Zio Ciano
Roby
francamente, oltre alla rinnovata interfaccia ho visto ben poco. Ho provato
la beta 2 per un po di tempo, come interfaccia ho messo quella classica xkè
quella nuova non mi piaceva e non mi era comoda, idem per il menu avvio. La
versione Professional inoltre (considera che era una beta) richiedeva
sensibilmente piu RAM rispetto a Windows 2000. Come vedi adesso sono
passato a linux e mi trovo meglio che con XP :-)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Saluti, Roby [ro...@aruba.it]
You may stop this individual, but you can't stop us all... after all, we're
all alike.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Elle
la compatibilità con win95.
Inoltre delle utility in bundle non gliene frega niente, l'importante è
integrare il browser, il software cd-burning, etc... ma di cose veramente
importanti non se ne parla.
Non so per quale miracolo sia nato NT4, che considero ancora un valido
sistema, discretamente stabile e utilizzabile.
In accoppiata a Linux ovviamente ;)
Comunque spettiamo la versione definitiva, poi potremo giudicare.
<dbia...@square.nl> wrote in message
news:9d65fj$g1ks7$6...@ID-18487.news.dfncis.de...
Marco Costamagna
"SiemensMAN" <pri...@operamail.com> ha scritto nel messaggio
news:MPG.1560b06ecffd4cca98977f@localhost...
Solo se davanti ha un baratro
Stefano Ghirlanda
> E secondo me non li risolverà mai, probabilmente nel 2015 vorranno
> ancora la compatibilità con win95.
Ma se non vogliono neanche la compatibilita' tra Word X.1 e Word X.1.1
:-)
Sinceramente, un mio amico con Win2000 non puo' leggere i file Word 6
perche' pare di default non sia installato il traduttore
necessario... qualcuno conferma?
--
Stefano - Hodie Nonis Maiis MMI est
Francesco Bertani
wrote:
>Sinceramente, un mio amico con Win2000 non puo' leggere i file Word 6
>perche' pare di default non sia installato il traduttore
>necessario... qualcuno conferma?
Da me il filtro e' installato, ma io faccio sempre l'installazione
personalizzata e installo tutti i filtri, non so se di default non
c'e'.
Comunque basta infilare il cd e in 2 minuti il problema e' risolto.
Ciao
Francesco
Stefano Ghirlanda
Veramente Word e' partito da solo con una ricerca in rete non si sa
bene dove (forse la rete universitaria da cui era stato
installato...). A onor del vero, e' bastato il "Cancel" e ha smesso
subito...
Francesco Bertani
wrote:
>Veramente Word e' partito da solo con una ricerca in rete non si sa
>bene dove (forse la rete universitaria da cui era stato
>installato...). A onor del vero, e' bastato il "Cancel" e ha smesso
>subito...
E' stato installato da disco di rete, alcune funzioni non sono
installate ma sono marcate per l'installazione on-demand al primo
utilizzo della funzione.
Comodo se hai una installazione di rete, rompicoglione se la hai fatta
da cd.
Comunque puoi scegliere se e quali funzioni mettere on-demand.
Ciao
Francesco
thorin_...@gruppocm-cs.it
>>Sinceramente, un mio amico con Win2000 non puo' leggere i file Word 6
>>perche' pare di default non sia installato il traduttore
>>necessario... qualcuno conferma?
> Da me il filtro e' installato, ma io faccio sempre l'installazione
> personalizzata e installo tutti i filtri, non so se di default non
> c'e'.
> Comunque basta infilare il cd e in 2 minuti il problema e' risolto.
Se Uord non fosse una ciofeca incompatibile con le sue stesse versioni
precedenti non ci sarebbe neanche bisogno di filtri.
Stefano Ghirlanda
> In un messaggio del Mon, 07 May 2001 18:51:50 GMT Francesco Bertani
> scriveva:
>
> >>Sinceramente, un mio amico con Win2000 non puo' leggere i file
> >>Word 6 perche' pare di default non sia installato il traduttore
> >>necessario... qualcuno conferma?
>
> > Da me il filtro e' installato, ma io faccio sempre l'installazione
> > personalizzata e installo tutti i filtri, non so se di default non
> > c'e'.
> > Comunque basta infilare il cd e in 2 minuti il problema e' risolto.
>
> Se Uord non fosse una ciofeca incompatibile con le sue stesse
> versioni precedenti non ci sarebbe neanche bisogno di filtri.
Guarda, a me starebbe pure bene se fosse chiaro che il formato nuovo
e' meglio del vecchio :-)
--
Stefano - Hodie postridie Nonas Maias MMI est
DarkStalker
<dbia...@square.nl> ha scritto nel messaggio
news:9d65fj$g1ks7$6...@ID-18487.news.dfncis.de...
Io programmo abbastanza spesso con le OGL e C++ Sinceramente
un IDE come VS non mi serve a molto (anche se e' comodissimo).
Spendere quasi un milione per comprarlo mi sembra esagerato...
thorin_...@gruppocm-cs.it
>> > Comunque basta infilare il cd e in 2 minuti il problema e' risolto.
>>
>> Se Uord non fosse una ciofeca incompatibile con le sue stesse
>> versioni precedenti non ci sarebbe neanche bisogno di filtri.
> Guarda, a me starebbe pure bene se fosse chiaro che il formato nuovo
> e' meglio del vecchio :-)
Il che non e' detto.. a meno che non si intenda per migliore il fatto
che aggiunge della fuffa in piu' nel tuo documento .DOC rispetto alle
versioni precedenti :-)
balrog
> Tutte le funzioni dipendono dalla presenza dell'interfaccia
> grafica, questo impedisce la creazione di tutti quegli scriptini
> di automazione che sono tanto comodi in Unix.
Mah. No credo c'entri molto l'interfaccia. Il problema e' che il prompt dei
comandi e' di per se scarso.
--
balrog ):E...
Gabriele Del Giovine
<dbia...@square.nl> ha scritto nel messaggio
news:9d65fj$g1ks7$6...@ID-18487.news.dfncis.de...
> SiemensMAN <pri...@operamail.com> wrote:
> 1. il sistema e' troppo 'bloccato' sulla sua interfaccia.
Qui ti posso dare retta. Una visitina al sito dei linguaggi di scripting
di M$ ti schiarisce le idee. Almeno imparerai a scrivere un virus.
> 2. manca un "vero" sistema di controllo dei processi
> se uno dei processi 'muore' inaspettatamente ci sono ottime
> probabilita' che l'intero sistema ne risenta, inoltre e'
Si vede chiaramente che non sai di cosa stai parlando.
> 3. manca un "vero" sistema di comunicazione tra i vari processi.
> OLE, DDE, COM, MMF etc. sono dei palliativi inventati via via per
> aggirare questo inghippo.
Ulteriore conferma di ciň che ho detto prima.
Memoria condivisa, mutex, semafori, COM, DCOM forse non sai neanche
cosa siano.
> 4. Il sistema viene rilasciato privo di tutti quegli strumenti di
> utilita' che servono per automatizzare ed eseguire le operazioni
Ma come, fanno causa a M$ perchč ingloba un browser e tui vuoi metterci
anche le utilities?
Saluti.
thorin_...@durin.khazad-dum.net
>> Tutte le funzioni dipendono dalla presenza dell'interfaccia
>> grafica, questo impedisce la creazione di tutti quegli scriptini
>> di automazione che sono tanto comodi in Unix.
> Mah. No credo c'entri molto l'interfaccia. Il problema e' che il prompt dei
> comandi e' di per se scarso.
Mecojoni, dipende da quello che *tu* sai farci.
dbia...@square.nl
> Qui ti posso dare retta. Una visitina al sito dei linguaggi di scripting
> di M$ ti schiarisce le idee. Almeno imparerai a scrivere un virus.
Sei in grado di creare uno script che avvia un processo di backup su
nastro? Puoi usare uno script per avviare una connessione dial-up,
spedire della posta e trasferire la posta in ingresso nelle rispettive
caselle postali degli utenti? Puoi utilizzare uno script per leggere
dei dati da un server remoto (tramite TCP-IP) comporre un file PDF e
stamparlo ?
Il tutto *senza* nessun intervento umano ovviamente.
> Si vede chiaramente che non sai di cosa stai parlando.
Ok, spiegamelo tu. Io ho 18 (diciotto) sessioni di Excel "zombie" sul
server. Come le ammazzi senza riavviare la macchina? Quando quella
ciofeca di OpenStep si impalla e comincia a macinare memoria fino a
schiantare il sistema come lo fermi?
> Ulteriore conferma di ciň che ho detto prima.
> Memoria condivisa, mutex, semafori, COM, DCOM forse non sai neanche
> cosa siano.
Io lo so perfettamente (sono MSCP), e sono tutti dei palliativi perche'
in Microsoft inizialmente non hanno pensato che i singoli programmi
possono voler comunicare tra di loro. COM, DCOM etc. sono solo degli
accorgimenti per aggirare questo problema.
> Ma come, fanno causa a M$ perchč ingloba un browser e tui vuoi metterci
> anche le utilities?
Un browser per internet non e' una cosa che utilizzi per mantenere
il tuo sistema funzionante, un programma di archiviazione (stile tar)
lo e'.
Davide
Gabriele Del Giovine
<dbia...@square.nl> wrote in message
news:9danjh$hi8il$8...@ID-18487.news.dfncis.de...
> Gabriele Del Giovine <pi...@pippo.pippo> wrote:
> > Qui ti posso dare retta. Una visitina al sito dei linguaggi di scripting
> > di M$ ti schiarisce le idee. Almeno imparerai a scrivere un virus.
>
> Sei in grado di creare uno script che avvia un processo di backup su
> nastro? Puoi usare uno script per avviare una connessione dial-up,
> spedire della posta e trasferire la posta in ingresso nelle rispettive
> caselle postali degli utenti? Puoi utilizzare uno script per leggere
> dei dati da un server remoto (tramite TCP-IP) comporre un file PDF e
> stamparlo ?
> Il tutto *senza* nessun intervento umano ovviamente.
non vedo dove sta il problema.
> > Si vede chiaramente che non sai di cosa stai parlando.
>
> Ok, spiegamelo tu. Io ho 18 (diciotto) sessioni di Excel "zombie" sul
> server. Come le ammazzi senza riavviare la macchina? Quando quella
> ciofeca di OpenStep si impalla e comincia a macinare memoria fino a
> schiantare il sistema come lo fermi?
Kill PID (PID sta per process ID). E puoi risalire al pid dei processi excel
a partire dal nome dell'eseguibile associato a quel processo.
Basta saper leggere la documentazione delle API di Win32.
> > Ulteriore conferma di ciň che ho detto prima.
> > Memoria condivisa, mutex, semafori, COM, DCOM forse non sai neanche
> > cosa siano.
>
> Io lo so perfettamente (sono MSCP), e sono tutti dei palliativi perche'
> in Microsoft inizialmente non hanno pensato che i singoli programmi
> possono voler comunicare tra di loro. COM, DCOM etc. sono solo degli
> accorgimenti per aggirare questo problema.
Ma che fesserie dici. Esistono gli stessi meccanismi di comunicazione
interprocesso che esistono negli altro OS ed anche di piu.
Saluti.
dbia...@square.nl
> Se conosci le interfacce COM dei vari servizi e programmi coinvolti
> non vedo dove sta il problema.
Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
usare COM per questo tipo di applicazione e' una cosa "elegante"
perche' non lo e'. Inoltre come gestisci gli eventuali errori?
Se uno dei processi si blocca hai ottime probabilita' che ti
visualizzi una bella mascherina su cui qualcuno dovrebbe cliccare...
> Kill PID (PID sta per process ID). E puoi risalire al pid dei processi excel
> a partire dal nome dell'eseguibile associato a quel processo.
Purtroppo se hai avviato il processo tramite COM molto probabilmente
quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non ti
assicura di ammazzare il processo, ci prova e basta. Se hai piu'
sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
distingui una sessione dall'altra?
> Ma che fesserie dici. Esistono gli stessi meccanismi di comunicazione
> interprocesso che esistono negli altro OS ed anche di piu.
Piano con le parole, io non ho insultato nessuno. pipe e memoria
condivisa sono state aggiunte solo ultimamente, inoltre il meccanismo
di sharing della memoria ha seri problemi (rischi di 'spianare' l'heap
del programma con molta facilita'). Le socket non sono supportate a
livello di kernel, l'implementazione Microsoft ha parecchi
problemi ed e' sicuramente meno efficiente di quella Unix.
Usare COM per far comunicare due programmi e' fattibile solo se i due
sono stati progettati per funzionare da server, non sempre e'
cosi', procurarsi le informazioni su quali interfacce sono
disponibili e' un'impresa quasi impossibile in molti casi.
Davide
Gabriele Del Giovine
<dbia...@square.nl> wrote in message
news:9dav0d$hi8il$1...@ID-18487.news.dfncis.de...
> Gabriele Del Giovine <mye...@isnot.here> wrote:
> > Se conosci le interfacce COM dei vari servizi e programmi coinvolti
> > non vedo dove sta il problema.
>
> Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
> usare COM per questo tipo di applicazione e' una cosa "elegante"
> perche' non lo e'. Inoltre come gestisci gli eventuali errori?
> Se uno dei processi si blocca hai ottime probabilita' che ti
> visualizzi una bella mascherina su cui qualcuno dovrebbe cliccare...
> Purtroppo se hai avviato il processo tramite COM molto probabilmente
> quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non ti
> assicura di ammazzare il processo, ci prova e basta. Se hai piu'
> sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
> distingui una sessione dall'altra?
Ma che stai a di...Mica mi riferisco al kill del task-manager..
> > Ma che fesserie dici. Esistono gli stessi meccanismi di comunicazione
> > interprocesso che esistono negli altro OS ed anche di piu.
>
> Piano con le parole, io non ho insultato nessuno. pipe e memoria
> condivisa sono state aggiunte solo ultimamente, inoltre il meccanismo
> di sharing della memoria ha seri problemi (rischi di 'spianare' l'heap
> del programma con molta facilita'). Le socket non sono supportate a
> livello di kernel, l'implementazione Microsoft ha parecchi
> problemi ed e' sicuramente meno efficiente di quella Unix.
Le pipe presenti da poco? i file mappati in memoria presenti da
poco? Ma che stai a di..
> Usare COM per far comunicare due programmi e' fattibile solo se i due
> sono stati progettati per funzionare da server, non sempre e'
> cosi', procurarsi le informazioni su quali interfacce sono
> disponibili e' un'impresa quasi impossibile in molti casi.
Basta saper leggere la documentazione di typelib.tlb. O saper
fare click clack su un object browser. Evidentemente non conosci COM.
Saluti.
balrog
> Mecojoni, dipende da quello che tu sai farci.
Ehm... parlavo di quello di windows.
--
balrog ):E...
thorin_...@gruppocm-cs.it
>> Mecojoni, dipende da quello che tu sai farci.
> Ehm... parlavo di quello di windows.
Ah, allora come non detto.
Henryx
Quando? Tue, 8 May 2001 21:59:43 +0200
In quale articolo? <9d9i81$t16$1...@fe2.cs.interbusiness.it>
| Ma come, fanno causa a M$ perchè ingloba un browser e tui vuoi metterci
| anche le utilities?
Con quello che paghi un win2k pro/server sarebbe il minimo
Henryx
--
===UN*X is SEXY!===
who|grep -i "green eyes"|date; cd ~; apropos fsck; whatis `unzip`|touch;
strip; finger; mount; gasp; yes|more; uptime; umount; sleep
Elle
argomenti che vorrei approfondire... dove trovo documentazione sulla
gestinone avanzata della memoria in Win?
Grazie e ciao
"Henryx" <henr...@libero.it.TOGLIMI> wrote in message
news:dkqbd9...@127.0.0.1...
Valter Minute
[...]
>
>Secondo me no. Windows come sistema operativo ha 4 gravi difetti,
>che non sono stati corretti e (mi sa) ci vorra' parecchio prima
>che vengano corretti:
>
Premetto che la mia non vuole certo essere una difesa di Windows e che non
ho ancora avuto il tempo di vedere XP (se non in qualche articolo).
Le risposte si basano su Windows 2000 (da cui XP dovrebbe essere derivato)
e non sulla famiglia 9X (per cui gran parte delle affermazioni del post
originale sono invece azzeccate).
>1. il sistema e' troppo 'bloccato' sulla sua interfaccia.
> Tutte le funzioni dipendono dalla presenza dell'interfaccia
> grafica, questo impedisce la creazione di tutti quegli scriptini
> di automazione che sono tanto comodi in Unix. Inoltre impedisce
> una facile integrazione tra varie "semplici" utility per creare
> utility piu' complesse.
>
E' vero che windows è pesantemente legato all'interfaccia grafica e questo
(soprattutto per un server) non è un fatto positivo. Esistono però anche
versioni di windows NT che non richiedono monitor-tastiera-scheda video,
orientate soprattutto al mercato "embedded" e in grado di essere
controllate da remoto (anche se mi pare che in XP tutte le versioni a parte
la personal abbiano incorporato un terminal server monosessione).
I sistemi di automazione esistono, sono diversi (e forse meno potenti) di
quelli unix e basati su una concezione diversa. Mentre in *nix si tende a
concatenare tramite pipe l'output di diversi "filtri" per arrivare al
risultato finale, in windows si ricorre a COM e VBScript (anche se nulla
vieta di usare altri linguaggi come python e JScript).
WMI mette a disposizione una struttura che permette di controllare diversi
aspetti del sistema (processi e altro), anche per le unità remote. Il tutto
non è forse alla portata dell'amministratore di rete medio (soprattutto se
è un admin punta e clicca o ha esperienza su unix e pretende di rifare
tutte le cose allo stesso modo).
>2. manca un "vero" sistema di controllo dei processi
> se uno dei processi 'muore' inaspettatamente ci sono ottime
> probabilita' che l'intero sistema ne risenta, inoltre e' impossibile
> controllare lo stato di un processo (Windows non ha idea di cosa
> stiano facendo i vari processi), ne' e' possibile uccidere o rimuovere
> un processo in maniera sicura. Questo e' un serio problema e costringe
> spesso al riavvio dell'intero sistema per aggiornare un singolo
> processo.
WMI permette di controllare lo stato dei processi, killarli e lanciarne di
nuovi.
La chiusura di un processo non lascia tracce sul s.o. (almeno in NT/2000).
Può non essere possibile dall'interfaccia utente chiudere un processo (è
sempre possibile killarlo con utility a linea di comando o da script).
Il problema del riavvio dopo il setup (causa aggiornamento di DLL varie) è
sicuramente un problema, anche se in win 2000 è di molto attenuato e deriva
spesso dalle cattive abitudini degli installer (che forzano il restart
anche quando non è necessario).
Quello che manca è un "package-manager" in grado di gestire le dipendenze
(anche se windows 2000 non soffre dei problemi di sovrascrittura selvaggia
delle DLL che affliggevano le versioni precedenti).
>
>3. manca un "vero" sistema di comunicazione tra i vari processi.
> OLE, DDE, COM, MMF etc. sono dei palliativi inventati via via per
> aggirare questo inghippo. La verita' e' che non esiste un vero sistema
> di comunicazione tra i vari processi, il che rende impossibile
> una vera coesione tra i vari programmi.
>
DDE è sorpassato (veniva utilizzato a 16bit e rimane, purtroppo, per
compatibilità retroattiva).
OLE e COM sono la stessa cosa (o meglio, OLE è un'applicazione di COM) e
non capisco perchè tu li definisca "palliativi". Sono sicuramente sistemi
diversi dalle pipe di unix, ma questo non mi pare meglio o peggio a priori
(ovviamente la differenza la fa anche l'implementazione...).
Cosa intendi per MMF? Memory Mapped File? Make Money Fast? :)
Sicuramente windows NT/2000/XP è un sistema nato per il desktop (o comunque
per reti molto piccole) che cerca di supportare applicazioni server sempre
più complesse, denunciando in alcuni casi le sue "origini". Lo stesso
discorso si può forse fare (ovviamente alla rovescia) per unix sui
desktop...
>4. Il sistema viene rilasciato privo di tutti quegli strumenti di
> utilita' che servono per automatizzare ed eseguire le operazioni
> di routine (backup/amministrazione etc.), tutto questo e' ottimo
> per altri produttori di software (Norton, Symantec etc.), ma significa
> che l'utente oltre a pagare la licenza (costosina) di Windows deve
> *anche* pagare tutti i tools aggiuntivi....
>
Su questo hai sicuramente ragione, anche se nella scelta di un s.o.
dovrebbero contare più i costi di gestione che il costo iniziale del
software.
Parte dei tool di amministrazione è compresa nel resource kit e
l'integrazione di terminal server anche nelle versioni single-user dovrebbe
diminuire l'esigenza di programmi di terze parti.
--
Valter Minute
min...@inwind.it (the reply address of this message is invalid)
Valter Minute
>Gabriele Del Giovine <mye...@isnot.here> wrote:
>> Se conosci le interfacce COM dei vari servizi e programmi coinvolti
>> non vedo dove sta il problema.
>
>Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
Invece i tool unix si interfacciano tra di loro automaticamente?
Perchè si parte sempre dal presupposto che su *nix è necessario capire le
cose prima di farle e su windows no?
Non voglio assolutamente dire che il sistema di controllo tramite COM e VB
script sia migliore di quello tramite pipes e shell script, ma prendere
sempre come termini di paragone un guro di *nix e l'ultimo fesso che usa NT
ti mette allo stesso livello dell'anonimo estensore dei documenti su linux
targati ms.
>usare COM per questo tipo di applicazione e' una cosa "elegante"
definiscimi "elegante" (riferito alla programmazione) in termini oggettivi.
Passare dati tramite pipe è elegante, usare COM no?
Chi sei il dolce & gabbana della programmazione? :)
>perche' non lo e'. Inoltre come gestisci gli eventuali errori?
Codici di ritorno dei metodi COM? Eccezioni?
>Se uno dei processi si blocca hai ottime probabilita' che ti
>visualizzi una bella mascherina su cui qualcuno dovrebbe cliccare...
>
Su questo ti devo dare ragione, buona parte degli applicativi per windows
(soprattutto quelli orientati anche a win9X) non è pensata per un utilizzo
in modalità unattended, anche se con windows 2000 questa tendenza stà
cambiando.
Comunque è un punto debole dei tool, non dell'architettura.
Se scrivo un programmino che prende i dati da una pipe e richiede conferma
all'utente se arrivano dati non validi non è la stessa cosa?
Non puoi dire che COM è un'architettura scadente partendo da un problema di
un applicativo (come io non mi sogno di dire che le pipe non funzionano
bene riferendomi all'esempio di cui sopra).
Criticare un'architettura è ben diverso da criticare la sua implementazione
e criticare l'implementazione dei servizi di base è ben diverso dal
criticare l'implementazione che ne fanno gli applicativi.
>> Kill PID (PID sta per process ID). E puoi risalire al pid dei processi
>> excel a partire dal nome dell'eseguibile associato a quel processo.
>
>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non ti
>assicura di ammazzare il processo, ci prova e basta. Se hai piu'
>sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
>distingui una sessione dall'altra?
>
Come fai a farlo con ps?
>> Ma che fesserie dici. Esistono gli stessi meccanismi di comunicazione
>> interprocesso che esistono negli altro OS ed anche di piu.
>
>Piano con le parole, io non ho insultato nessuno. pipe e memoria
>condivisa sono state aggiunte solo ultimamente,
Windows 95 e Windows NT 3.1
>inoltre il meccanismo
>di sharing della memoria ha seri problemi (rischi di 'spianare' l'heap
>del programma con molta facilita').
Cosa intendi per "spianare" l'heap?
Un processo ha accesso solo alla memoria che gli è stata assegnata dal
S.O., ogni tentativo di accesso ad altra memoria viene bloccato dal S.O.
(anche se sotto 9X, per compatibilità retroattiva, in alcuni casi era
possibile scavalcare questa protezione anche da processi applicativi).
Ovviamente ogni processo si gestisce la sua memoria come meglio crede.
>Le socket non sono supportate a
>livello di kernel, l'implementazione Microsoft ha parecchi
>problemi ed e' sicuramente meno efficiente di quella Unix.
Non parlerei di implementazione di "Unix" (anche perchè è da uno unix che è
stata copiata, se non sbaglio).
>Usare COM per far comunicare due programmi e' fattibile solo se i due
>sono stati progettati per funzionare da server,
huh? Posso passare input sullo stdio a un programma unix che non se lo
aspetta?
La differenza è che in unix un processo (in modalità console) può ricevere
input indifferentemente dall'utente o da un altro processo tramite pipe
(cosa che per altro è vera pure per le console application di windows), lo
stesso non vale per i processi con un'interfaccia grafica.
Visto che in windows la maggior parte dell'interazione con l'utente passa
per l'interfaccia grafica, la maggior parte delle interazioni tra diversi
processi passa per un altro meccanismo (COM). Mi sembra che le GUI per
linux siano orientate a fare allo stesso modo.
>non sempre e'
>cosi', procurarsi le informazioni su quali interfacce sono
>disponibili e' un'impresa quasi impossibile in molti casi.
>
Questo è un problema di chi fa le applicazioni e non rilascia la
documentazione, non un problema dell'architettura.
Se un processo accetta dati sullo stdio puoi passarli senza conoscere il
formato dei dati stessi?
thorin_...@durin.khazad-dum.net
>>Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
> Invece i tool unix si interfacciano tra di loro automaticamente?
Automaticamente no ma ci vuole ben poco, tramite pipe, a farlo.
>>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non ti
>>assicura di ammazzare il processo, ci prova e basta. Se hai piu'
>>sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
>>distingui una sessione dall'altra?
> Come fai a farlo con ps?
Non con ps ma con pstree si.
Davide Inglima ,limaCAT
> controllate da remoto (anche se mi pare che in XP tutte le versioni a parte
> la personal abbiano incorporato un terminal server monosessione).
Cioe', la Microsoft vuole sbattere fuori dal mercato i Cult Of The Dead Cow
facendo dumping del suo prodotto? Geniale! Visto che e' quella l'applicazione
piu' cercata per Windows, mettiamola di serie!
:)
--
Davide Inglima, limaCAT
Valter Minute
<9deviq$hujqa$1...@ID-82990.news.dfncis.de>:
Scherzi a parte, credo che sia una scelta abbastanza logica visto che uno
dei punti deboli di win rispetto a unix č la mancanza di un meccanismo di
controllo remoto "di serie".
Probabilmente ms ha ascoltato i lamenti di chi era costretto ad
amministrare una wan e faceva piů chilometri di un pilota di linea...
Valter Minute
dum.net>:
>In un messaggio del 9 May 2001 09:23:46 GMT Valter Minute scriveva:
>
>>>Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
>
>> Invece i tool unix si interfacciano tra di loro automaticamente?
>Automaticamente no ma ci vuole ben poco, tramite pipe, a farlo.
>
Giusta precisazione, non mi pare di aver sostenuto il contrario.
Volevo solo sottolineare il fatto che l'autore del post sottolineava un
punto ovvio e scontato per entrambi i sistemi: per interfacciare qualcosa
devi prima sapere che dati esporta (nel caso delle pipe) o che funzioni COM
supporta (nel caso di win).
Come ripeti spesso "la differenza la fa il 'pezzo di carne' tra monitor e
tastiera".
Si può criticare il fatto che ci siano poche applicazioni server che
supportano un'interfaccia COM (anche il numero è aumentato notevolmente tra
le varie versioni di NT), non dire che interfacciare due processi tramite
COM è impossibile perchè devi conoscere le interfacce che devi utilizzare.
>>>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>>>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non ti
>>>assicura di ammazzare il processo, ci prova e basta. Se hai piu'
>>>sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
>>>distingui una sessione dall'altra?
>
>> Come fai a farlo con ps?
>Non con ps ma con pstree si.
>
Premetto che non sono molto esperto di unix (e ti prego quindi di perdonare
eventuali vaccate)... ma mi pare che anche con pstree puoi sapere chi ha
lanciato le verie istanze (vantaggio rispetto a ps e al task manager), ma
non puoi distinguere tra due sessioni dello stesso applicativo lanciate
dallo stesso utente (o servizio/demone nel caso in questione) e quindi non
risolvi comunque il problema originale.
Renato 'Hitman' Salzano
che mi circonda e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, Valter Minute interruppe il corso dei miei
pensieri bofonchiando:
>>> Kill PID (PID sta per process ID). E puoi risalire al pid dei
>>> processi excel a partire dal nome dell'eseguibile associato a quel
>>> processo.
>>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non
>>ti assicura di ammazzare il processo, ci prova e basta. Se hai piu'
>>sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
>>distingui una sessione dall'altra?
> Come fai a farlo con ps?
indovinare il PID partendo dal nome dell'eseguibile.
--
Renato "Hitman" Salzano - http://spazioweb.inwind.it/hitman/
e-posta : sonicblast (at) inwind.it / Xena:TWP fan
Webdesigner / indegno sysadmin di www.italservicesnc.it
Powered by Debian 2.x (Woody) on a K6/2 box - 100% Wintel free
Obelix
wrote:
>Che ne pensate di Windows XP
Di eX-Pirled????
>> Microsoft sta facendo passi avanti?
Se erano di fronte ad un precipizio, spero di si...
Obelix
thorin_...@durin.khazad-dum.net
>>> Invece i tool unix si interfacciano tra di loro automaticamente?
>>Automaticamente no ma ci vuole ben poco, tramite pipe, a farlo.
> Giusta precisazione, non mi pare di aver sostenuto il contrario.
> Volevo solo sottolineare il fatto che l'autore del post sottolineava un
> punto ovvio e scontato per entrambi i sistemi: per interfacciare qualcosa
> devi prima sapere che dati esporta (nel caso delle pipe) o che funzioni COM
> supporta (nel caso di win).
Beh nel caso delle pipe non interessa molto che dato vuoi passare (e mi
riferisco alle named pipes). Per esempio io uso una named pipe per
generare in modo casuale una firma ad ogni mail e non penso faccia
differenza fra 4 linee ASCII o altro tipo di dato (a dire il vero non ho
mai provato ma dovrebbe essere cosi')
>>> Come fai a farlo con ps?
>>Non con ps ma con pstree si.
> Premetto che non sono molto esperto di unix (e ti prego quindi di perdonare
> eventuali vaccate)... ma mi pare che anche con pstree puoi sapere chi ha
> lanciato le verie istanze (vantaggio rispetto a ps e al task manager), ma
> non puoi distinguere tra due sessioni dello stesso applicativo lanciate
> dallo stesso utente (o servizio/demone nel caso in questione) e quindi non
> risolvi comunque il problema originale.
Sicuro sicuro? Io ho appena lanciato due istanze di gvim e se usi -p ti
fa vedere il PID
[pier@durin pier]$ pstree -p
init(1)-+-actived(565)
|-apmd(289)
|-atd(355)
|-cardmgr(382)
|-crond(369)
|-gpm(469)
|-gvim(10774)
|-gvim(10777)
senza contare altri switch "interessanti", per esempio
-n Sort processes with the same ancestor by PID
instead of by name. (Numeric sort.)
-p Show PIDs. PIDs are shown as decimal numbers in
parentheses after each process name. -p implicitly
disables compaction.
-u Show uid transitions. Whenever the uid of a process
differs from the uid of its parent, the new uid is
shown in parentheses after the process name.
KJK :: Hyperion
<909AA7E39V...@212.110.0.170>:
>La chiusura di un processo non lascia tracce sul s.o. (almeno in
>NT/2000).
occhio alle socket bind()ate, spesso non vengono chiuse se
l'applicazione viene killata brutalmente
>Può non essere possibile dall'interfaccia utente chiudere
>un processo (è sempre possibile killarlo con utility a linea di
>comando o da script).
è la stessa cosa
l'unico limite è che non si possono killare programmi con un SID
differente dal proprio, ossia i servizi o i programmi di altri utenti.
Ma si risolve molto bene avviando il task manager come servizio
>DDE è sorpassato (veniva utilizzato a 16bit e rimane, purtroppo, per
>compatibilità retroattiva).
DDE è tutt'altro che sorpassato... hai presente quei programmi che
aprono più file nella stessa finestra? funzionano tutti tramite DDE. E'
il modo più economico di fare certe cose e difficilmente verrà
soppiantato, a meno che non arrivi un sostituto degno
KJK :: Hyperion
<9dav0d$hi8il$1...@ID-18487.news.dfncis.de>:
>> Se conosci le interfacce COM dei vari servizi e programmi
>> coinvolti non vedo dove sta il problema.
>Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
>usare COM per questo tipo di applicazione e' una cosa "elegante"
>perche' non lo e'.
intanto Windows ti permette di inserire uno spreadsheet in un documento
di testo da almeno 8 anni, nessun altro sistema operativo c'è arrivato
se non molto di recente
>Inoltre come gestisci gli eventuali errori?
>Se uno dei processi si blocca hai ottime probabilita' che ti
>visualizzi una bella mascherina su cui qualcuno dovrebbe cliccare...
la convenzione di chiamata safecall (nativa di COM) permette l'exception
handling nel modo tradizionale (gestione strutturata, tutti i linguaggi
OO ce l'hanno)
>> Kill PID (PID sta per process ID). E puoi risalire al pid dei
>> processi excel a partire dal nome dell'eseguibile associato a quel
>> processo.
>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non
>ti assicura di ammazzare il processo, ci prova e basta.
kill ammazza, anche troppo bene (gli handle non vengono chiusi, ad
esempio - rischi di trovarti socket aperte sul nulla profondo se ammazzi
un server)
>Se hai piu'
>sessioni di Excel il nome dell'eseguibile e' sempre lo stesso, come
>distingui una sessione dall'altra?
chiudi quelle vive e rimarranno in esecuzione solo quelle morte
>Le socket non sono supportate a livello di kernel,
che buffo, io ho sempre creduto che il networking fosse gestito da un
driver...
>l'implementazione Microsoft ha
>parecchi problemi ed e' sicuramente meno efficiente di quella Unix.
l'implementazione Microsoft non l'hanno fatta loro, è del vecchio codice
BSD di cui hanno fatto il porting
>Usare COM per far comunicare due programmi e' fattibile solo se i
>due sono stati progettati per funzionare da server, non sempre e'
>cosi', procurarsi le informazioni su quali interfacce sono
>disponibili e' un'impresa quasi impossibile in molti casi.
scusa, ma è colpa di COM?
KJK :: Hyperion
<slrn9fog56.c...@harris.sonicblast.it>:
>> Come fai a farlo con ps?
>ps restituisce il pid di ogni processo che giri, non c'e`
>bisogno di indovinare il PID partendo dal nome dell'eseguibile.
ma č una cazzata... ps ti spara un pappone simile:
100 /bin/login
200 /bin/bash
...
e cosě via
se hai una decina di bash in background e sai che una s'č inchiodata,
come fai a sapere quale delle undici (eh sě, c'č anche quella che stai
usando) devi ammazzare?
suppongo che i pid vengano assegnati in ordine pressochč cronologico...
ma oltre a questo che garanzie hai? quasi nessuna, direi... anche con il
pstree che citava thorin non č che te la cavi granchč, metti che tutte e
dieci le bash in background siano figlie della shell di login, che
cavolo fai?
thorin_...@durin.khazad-dum.net
>>> Come fai a farlo con ps?
>>ps restituisce il pid di ogni processo che giri, non c'e`
>>bisogno di indovinare il PID partendo dal nome dell'eseguibile.
> ma č una cazzata... ps ti spara un pappone simile:
Non e' una cazzata, basta saper leggere _bene_ la man page e vedrai che
il modo per distinguere fra tutte le bash c'e'.
Hint: -h -n
per favore, informatevi prima di scrivere di queste cose..
> suppongo che i pid vengano assegnati in ordine pressochč cronologico...
> ma oltre a questo che garanzie hai? quasi nessuna, direi... anche con il
> pstree che citava thorin non č che te la cavi granchč, metti che tutte e
> dieci le bash in background siano figlie della shell di login, che
> cavolo fai?
Strano ma vero, l'output di ps ha anche una colonna TTY: ti sei chiesto
a cosa possa servire?
thorin_...@durin.khazad-dum.net
>>> Kill PID (PID sta per process ID). E puoi risalire al pid dei
>>> processi excel a partire dal nome dell'eseguibile associato a quel
>>> processo.
>>Purtroppo se hai avviato il processo tramite COM molto probabilmente
>>quello e' "System", ed il Kill ti dice "picche". Inoltre il Kill non
>>ti assicura di ammazzare il processo, ci prova e basta.
> kill ammazza, anche troppo bene (gli handle non vengono chiusi, ad
> esempio - rischi di trovarti socket aperte sul nulla profondo se ammazzi
> un server)
Veramente in molti casi non ammazza proprio niente anzi la cosa piu'
comica e' quando alle volte, tentando di uccidere un processo, il task
manager, che dovrebbe essere cio' che mi dovrebbe far uccidere il
processo incriminato, muore lui stesso.
>>l'implementazione Microsoft ha
>>parecchi problemi ed e' sicuramente meno efficiente di quella Unix.
> l'implementazione Microsoft non l'hanno fatta loro, è del vecchio codice
> BSD di cui hanno fatto il porting
Non diciamo cazzate ! Stai forse dicendo che il codice BSD da cui m$ ha
_copiato_ non e' buono? Uhm, veramente comica questa, visto che
implementazioni simili sulle piattaforme *NIX funzionano bene... se
quelli di m$ non sanno neanche copiare bene che possiamo farci?
Valter Minute
127.0.0.1>:
>vmi...@REMOVEMEinwind.it (Valter Minute) wrote in
><909AA7E39V...@212.110.0.170>:
>
>>La chiusura di un processo non lascia tracce sul s.o. (almeno in
>>NT/2000).
>
>occhio alle socket bind()ate, spesso non vengono chiuse se
>l'applicazione viene killata brutalmente
>
Non mi è mai capitato, anche debuggando IIS lanciato come processo (e
stoppandolo quindi brutalmente dal debugger o a causa di miei errori nel
filtro ISAPI che stavo provando).
Può darsi comunque che sia vero in altre condizioni (se hai qualche link
sottomano per verificare mi faresti un grosso favore).
Il post originale comunque parlava di excel che (ma non ci metto la mano
sul fuoco :)) non dovrebbe utilizzare socket.
Il problema esiste sicuramente per 9X (e riguarda parecchie altre tipologie
di handle, non solo i socket).
>>Può non essere possibile dall'interfaccia utente chiudere
>>un processo (è sempre possibile killarlo con utility a linea di
>>comando o da script).
>
>è la stessa cosa
>l'unico limite è che non si possono killare programmi con un SID
>differente dal proprio, ossia i servizi o i programmi di altri utenti.
>Ma si risolve molto bene avviando il task manager come servizio
>
Effettivamente non ho mai dovuto killare un servizio visto che normalmente
lo puoi stoppare dal pannello di controllo (salvo disastri che comunque mi
sono sempre capitati mentre facevo debugging).
>>DDE è sorpassato (veniva utilizzato a 16bit e rimane, purtroppo, per
>>compatibilità retroattiva).
>
>DDE è tutt'altro che sorpassato... hai presente quei programmi che
>aprono più file nella stessa finestra? funzionano tutti tramite DDE. E'
>il modo più economico di fare certe cose e difficilmente verrà
>soppiantato, a meno che non arrivi un sostituto degno
>
Sì, ma serve solo per quello, non per realizzare la comunicazione tra
processi o (peggio) l'automazione degli stessi tramite script (altro
argomento toccato dal post originale).
P.S. viene anche utilizzato da molti programmi di setup per creare le icone
(visto che funziona anche se un utente ha deciso di usare il program
manager invece di explorer).
Valter Minute
<9dp7e0$ano$1...@durin.khazad-dum.net>:
>In un messaggio del 11 May 2001 07:49:45 GMT Valter Minute scriveva:
>
>>>> Invece i tool unix si interfacciano tra di loro automaticamente?
>>>Automaticamente no ma ci vuole ben poco, tramite pipe, a farlo.
>
>> Giusta precisazione, non mi pare di aver sostenuto il contrario.
>> Volevo solo sottolineare il fatto che l'autore del post sottolineava
>> un punto ovvio e scontato per entrambi i sistemi: per interfacciare
>> qualcosa devi prima sapere che dati esporta (nel caso delle pipe) o
>> che funzioni COM supporta (nel caso di win).
>Beh nel caso delle pipe non interessa molto che dato vuoi passare (e mi
>riferisco alle named pipes). Per esempio io uso una named pipe per
>generare in modo casuale una firma ad ogni mail e non penso faccia
>differenza fra 4 linee ASCII o altro tipo di dato (a dire il vero non ho
>mai provato ma dovrebbe essere cosi')
>
>>>> Come fai a farlo con ps?
>>>Non con ps ma con pstree si.
>
>> Premetto che non sono molto esperto di unix (e ti prego quindi di
>> perdonare eventuali vaccate)... ma mi pare che anche con pstree puoi
>> sapere chi ha lanciato le verie istanze (vantaggio rispetto a ps e al
>> task manager), ma non puoi distinguere tra due sessioni dello stesso
>> applicativo lanciate dallo stesso utente (o servizio/demone nel caso
>> in questione) e quindi non risolvi comunque il problema originale.
>Sicuro sicuro? Io ho appena lanciato due istanze di gvim e se usi -p ti
>fa vedere il PID
>
Anche in windows ogni processo ha un ID (e il task manager lo chiama PID,
tanto per essere originali :)), quello che volevo dire č che non puoi
capire (per quel poco che sņ), ad esempio, quale copia di gvim stą
lavorando su /etc/fstab e quale su /etc/inittab.
thorin_...@gruppocm-cs.it
>>Sicuro sicuro? Io ho appena lanciato due istanze di gvim e se usi -p ti
>>fa vedere il PID
> Anche in windows ogni processo ha un ID (e il task manager lo chiama PID,
> tanto per essere originali :)), quello che volevo dire č che non puoi
> capire (per quel poco che sņ), ad esempio, quale copia di gvim stą
> lavorando su /etc/fstab e quale su /etc/inittab.
Uh?
[thorin@mordor thorin]$ GV .fetchmailrc
[thorin@mordor thorin]$ GV .procmailrc
[thorin@mordor thorin]$ pstree -a
init
|-actived
|-(apmd)
|-atd
|-crond
|-deskguide_apple --activate-goad-server deskguide_applet
|-fetchmail -d 300
|-(gdm)
| |-X -auth /var/gdm/:0.Xauth :0
[..]
|-gnome-terminal
| |-(bash)
| | `-(su)
| | `-(bash)
| | `-epic -n thorin -c #cslug devlin.openprojects.net
| `-(gnome-pty-helpe)
|-gnome-terminal
| |-(bash)
| `-(gnome-pty-helpe)
|-gpm -t ps/2
|-gvim -fn 8x16 .fetchmailrc
|-gvim -fn 8x16 .procmailrc
dicevi?
Valter Minute
<9dqng6$qp7$1...@mordor.gruppocm-cs.it>:
>In un messaggio del 15 May 2001 07:38:36 GMT Valter Minute scriveva:
>
>> Anche in windows ogni processo ha un ID (e il task manager lo chiama
>> PID, tanto per essere originali :)), quello che volevo dire è che non
>> puoi capire (per quel poco che sò), ad esempio, quale copia di gvim
>> stà lavorando su /etc/fstab e quale su /etc/inittab.
>Uh?
>
[...]
>
>dicevi?
>
che ne sapevo poco di unix :) (e questa discussione, se non altro, mi stà
facendo imparare qualcosa di utile).
Comunque da quello che ho capito pstree ti fa vedere la command-line (cosa
che potrebbe fare anche task-manager, visto che esiste un'API apposita, se
chi lo ha scritto ci avesse pensato <grin>), ma non funziona se il file è
stato aperto da dentro il programma senza passarlo sulla cl (ovviamente
l'esempio non calza con vi, ma è il caso delle istanze multiple di excel
citate nel post che ha generato questo sotto-thread).
thorin_...@gruppocm-cs.it
>>> Anche in windows ogni processo ha un ID (e il task manager lo chiama
>>> PID, tanto per essere originali :)), quello che volevo dire è che non
>>> puoi capire (per quel poco che sò), ad esempio, quale copia di gvim
>>> stà lavorando su /etc/fstab e quale su /etc/inittab.
>>Uh?
>>
> [...]
>>
>>dicevi?
>>
> che ne sapevo poco di unix :) (e questa discussione, se non altro, mi stà
> facendo imparare qualcosa di utile).
Beh ne sono contento :) Alla fine magari apprezzerai di piu' i vari
giocattolini che UNIX mette a disposizione per potersi divertire con una
macchina :)
> Comunque da quello che ho capito pstree ti fa vedere la command-line (cosa
> che potrebbe fare anche task-manager, visto che esiste un'API apposita, se
> chi lo ha scritto ci avesse pensato <grin>), ma non funziona se il file è
Appunto.. ogni volta che qualcuno mi mette in mezzo le stramaledette API
di Uindous mi viene da chiedere "ma davvero pensano che se io utonto mi
dovessi trovare in mezzo ad un problema improvviso che mi mette in
condizioni di non poter lavorare debba pure andare a perder tempo
installando un compilatore C (perche' l'utonto medio non ce l'ha,
solitamente) e poi imparare a programmare in C ed infine scrivermi il
programmino che mi serve sfruttando le API?
No perche' un conto e' quando gli strumenti li hai _GIA'_ a disposizione
(come accade su UNIX) ed un conto e' quando non li hai e devi andare a
cercarteli con tools di terze parti o peggio dovresti ipoteticamente
andare a scriverteli tu. Sara' che con UNIX sono abituato male e nel
caso del kill dei processi che non vogliono morire (che ha generato un
thread simile non molto tempo fa) si riesce diciamo sempre ad averne
ragione mentre su NT no e mi sono sentito dire, appunto "C'e' una API !"
ed io "E allora?". Mica posso perder tempo a scrivermi un programmino
con le API, faccio prima a fare un reboot (tanto, capirai..)
> stato aperto da dentro il programma senza passarlo sulla cl (ovviamente
> l'esempio non calza con vi, ma è il caso delle istanze multiple di excel
> citate nel post che ha generato questo sotto-thread).
Beh questo e' un problema del modo in cui e' strutturato Uindous :)
Davide Inglima - limaCAT
<thorin_...@durin.khazad-dum.net> wrote:
> riferisco alle named pipes). Per esempio io uso una named pipe per
> generare in modo casuale una firma ad ogni mail e non penso faccia
> differenza fra 4 linee ASCII o altro tipo di dato (a dire il vero non ho
> mai provato ma dovrebbe essere cosi')
Giusto per completezza... e' cosi'. Bladeenc (encoder mp3) si puo'
tranquillamente utilizzare passandogli un wav in input. Un esempio:
cat linus_thorvalds.wav | bladeenc -
--
Davide Inglima, limaCAT
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
miei pensieri bofonchiando:
>>> Come fai a farlo con ps?
>>ps restituisce il pid di ogni processo che giri, non c'e`
>>bisogno di indovinare il PID partendo dal nome dell'eseguibile.
> ma č una cazzata... ps ti spara un pappone simile:
> 100 /bin/login
> 200 /bin/bash
> ...
> e cosě via
> se hai una decina di bash in background e sai che una s'č inchiodata,
> come fai a sapere quale delle undici (eh sě, c'č anche quella che stai
> usando) devi ammazzare?
Ti restituisce per ogni task: user che l'ha lanciato, da che terminale
l'ha lanciato e il suo PID fra le altre info (e sono tantissime).
Questo per _ogni_ task/processo/thread che giri nel sistema.
Leggersi le man page dei comandi fa bene - fallo anche tu.
thorin_...@durin.khazad-dum.net
>> riferisco alle named pipes). Per esempio io uso una named pipe per
>> generare in modo casuale una firma ad ogni mail e non penso faccia
>> differenza fra 4 linee ASCII o altro tipo di dato (a dire il vero non ho
>> mai provato ma dovrebbe essere cosi')
> Giusto per completezza... e' cosi'. Bladeenc (encoder mp3) si puo'
> tranquillamente utilizzare passandogli un wav in input. Un esempio:
> cat linus_thorvalds.wav | bladeenc -
Amen.. non avevo pensato a questo caso, eppure l'ho pure usato spesso,
vedi come alle volte ci si dimentica delle cose che si hanno proprio
sotto al naso?
Leonardo Serni
>vmi...@REMOVEMEinwind.it (Valter Minute) wrote in
><909AA7E39V...@212.110.0.170>:
>>La chiusura di un processo non lascia tracce sul s.o. (almeno in
>>NT/2000).
>occhio alle socket bind()ate, spesso non vengono chiuse se
>l'applicazione viene killata brutalmente
FERMO LI'! Come sarebbe a dire? Esempio: una applicazione fa un bind()
della porta 80; gli do uno shutdown regolare; quella rifiuta; riprovo,
e sparisce; posso avere il socket ancora in bind(), con nessuno che ci
sta dietro a rispondere, e l'applicazione che NON RIPARTE?!?
...e, se questo caso dovesse verificarsi, 'sa fo?
Leonardo
--
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.
Marco d'Itri
>...e, se questo caso dovesse verificarsi, 'sa fo?
Aspetti che scada il timer, succede anche in linux e credo che sia
richiesto da TCP.
--
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer" -- Dilbert
| (Ri)scoprire fidonet: http://bbs.bofh.it
KJK :: Hyperion
>Ti restituisce per ogni task: user che l'ha lanciato, da che
>terminale l'ha lanciato e il suo PID fra le altre info (e sono
>tantissime). Questo per _ogni_ task/processo/thread che giri nel
>sistema.
ripeto: potrebbe non bastare. Ma chiudiamo il discorso perchè non mi
interessa moltissimo una flame su ps
>Leggersi le man page dei comandi fa bene - fallo anche tu.
avercele
KJK :: Hyperion
<c6d3gt8immo1u3sii...@4ax.com>:
>> occhio alle socket bind()ate, spesso non vengono chiuse se
>> l'applicazione viene killata brutalmente
>FERMO LI'! Come sarebbe a dire? Esempio: una applicazione fa un bind()
>della porta 80; gli do uno shutdown regolare; quella rifiuta; riprovo,
>e sparisce; posso avere il socket ancora in bind(), con nessuno che ci
>sta dietro a rispondere, e l'applicazione che NON RIPARTE?!?
può succedere. Successo a me due volte con il server di posta.
Inchiodate la 25, la 110 e la 119. In alcuni *rarissimi* casi l'effetto
collaterale del kill brutale è questo. C'è da dire che è questo server
in particolare ad avere problemi tali da doverlo convincere spesso con
le buone maniere
>...e, se questo caso dovesse verificarsi, 'sa fo?
la prima volta mi bastò riavviare il server, la seconda volta dopo il
vodoo, il malocchio, le galline sacrificate a Baron Samedi e tre
avemarie, non ci furono cazzi e dovetti riavviare la macchina
thorin_...@durin.khazad-dum.net
>>Ti restituisce per ogni task: user che l'ha lanciato, da che
>>terminale l'ha lanciato e il suo PID fra le altre info (e sono
>>tantissime). Questo per _ogni_ task/processo/thread che giri nel
>>sistema.
> ripeto: potrebbe non bastare. Ma chiudiamo il discorso perchè non mi
> interessa moltissimo una flame su ps
Basta eccome, poi se per convenienza vuoi chiudere il discorso
chiudiamo eccome. Con kill su un PID risalendo nella catena (ed
evitando ovviamente quelli che sono direttamente figli di init per
i quali ovviamente non si puo' fare niente) si riesce _sempre_
>>Leggersi le man page dei comandi fa bene - fallo anche tu.
> avercele
Ci sono su tutte le distribuzioni Linux, non parliamo mica di
informazioni nascoste oppure a pagamento.
Valter Minute
<slrn9g1q2k.c...@alexandra.kaleshnokev>:
Sě, ma non credo tu ottenga risultati apprezzabili passando
linux_thorvalds.wev al programma per generare le signature o passando la
"quote of the day" a bladeenc.
Il discorso era partito dal fatto che, tra i "punti deboli"
dell'architettura COM, veniva elencato il fatto che fosse necessario
conoscere le interfacce da utilizzare, considerazione che mi sembra ovvia e
valida anche nel caso delle pipe.
thorin_...@gruppocm-cs.it
>>tranquillamente utilizzare passandogli un wav in input. Un esempio:
>>
>>cat linus_thorvalds.wav | bladeenc -
> Sě, ma non credo tu ottenga risultati apprezzabili passando
> linux_thorvalds.wev al programma per generare le signature o passando la
> "quote of the day" a bladeenc.
E grazie, ci si aspetta che, secondo il paradigma del pezzo di carne,
chi esegue il comando passi dei dati consistenti. Tu apriresti un
database Oracle con il Lettore Multimediale?
Valter Minute
<9dtdqf$48h$1...@mordor.gruppocm-cs.it>:
>In un messaggio del 16 May 2001 08:12:00 GMT Valter Minute scriveva:
>
>>>tranquillamente utilizzare passandogli un wav in input. Un esempio:
>>>
>>>cat linus_thorvalds.wav | bladeenc -
>
>> Sě, ma non credo tu ottenga risultati apprezzabili passando
>> linux_thorvalds.wev al programma per generare le signature o passando
>> la "quote of the day" a bladeenc.
>E grazie, ci si aspetta che, secondo il paradigma del pezzo di carne,
>chi esegue il comando passi dei dati consistenti. Tu apriresti un
>database Oracle con il Lettore Multimediale?
>
Infatti! (per una volta stiamo affermando la stessa cosa, credo che sia una
data da segnare sul calendario...)
Il tutto č partito da questa affermazione (in risposta a un'affermazione di
GdG):
>> Se conosci le interfacce COM dei vari servizi e programmi coinvolti
>> non vedo dove sta il problema.
>
>Infati... devi conoscerle, e non sempre e' cosi', e non dirmi che
>usare COM per questo tipo di applicazione e' una cosa "elegante"
>perche' non lo e'. Inoltre come gestisci gli eventuali errori?
>
Dire che COM (qui visto in contrapposizione con le pipes) non č "elegante"
perchč devi conoscere le interfacce dei vari servizi che vai ad utilizzare
č un'affermazione priva di senso.
Spero che su questo siamo tutti d'accordo :) (e possiamo ricominciare a
scannarci sugli altri aspetti di COM).
Marco d'Itri
>ripeto: potrebbe non bastare. Ma chiudiamo il discorso perchè non mi
E` troppo comodo scrivere cazzate e poi cavarsela con "chiudiamo il
discorso". Ti invito a descrivere uno scenario realistico in cui le
informazioni fornite da ps non sono sufficienti per individuare un
processo.
David Mugnai
>>...e, se questo caso dovesse verificarsi, 'sa fo?
> Aspetti che scada il timer, succede anche in linux e credo che sia
> richiesto da TCP.
Ehm, penso che diciate due cose diverse.
Te intendi lo stato TIME_WAIT che occore dopo la chiusura *regolere* di
un socket.
Loro parlavano della possibilita' che W2K non rilasci i descrittori
di file aperti (socket) quando un programma viene killato. Cosi' per il
sistema la porta in questione e' *ancora* usata e nessun'altro puo'
riaprirla.....
A pero' che figo W2K, da un piacevole senso di incertezza alla vita :)
--
David
To err is human...to really foul up requires the root password.
thorin_...@gruppocm-cs.it
>>E grazie, ci si aspetta che, secondo il paradigma del pezzo di carne,
>>chi esegue il comando passi dei dati consistenti. Tu apriresti un
>>database Oracle con il Lettore Multimediale?
> Infatti! (per una volta stiamo affermando la stessa cosa, credo che sia una
> data da segnare sul calendario...)
Infatti :) Questa e' una giornata eccezionale, considerato che di solito
non andiamo d'accordo..
> Il tutto è partito da questa affermazione (in risposta a un'affermazione di
> GdG):
[..]
> Dire che COM (qui visto in contrapposizione con le pipes) non è "elegante"
> perchè devi conoscere le interfacce dei vari servizi che vai ad utilizzare
> è un'affermazione priva di senso.
> Spero che su questo siamo tutti d'accordo :) (e possiamo ricominciare a
> scannarci sugli altri aspetti di COM).
Si, siamo d'accordo ma non ho intenzione di scannarmi su qualcosa che
non conosco, sinceramente :)
Marco d'Itri
>>>...e, se questo caso dovesse verificarsi, 'sa fo?
>> Aspetti che scada il timer, succede anche in linux e credo che sia
>> richiesto da TCP.
>Ehm, penso che diciate due cose diverse.
>Te intendi lo stato TIME_WAIT che occore dopo la chiusura *regolere* di
>un socket.
No. Intendo il periodo che passa tra il momento in cui uccidi un
programma con un socket TCP aperto e in listening e il successivo
momento in cui un altro programma potra` di nuovo usare quella porta.
Mardy
>DDE è tutt'altro che sorpassato... hai presente quei programmi che
>aprono più file nella stessa finestra? funzionano tutti tramite DDE. E'
>il modo più economico di fare certe cose e difficilmente verrà
>soppiantato, a meno che non arrivi un sostituto degno
DDE = Dynamic data exchange? Secondo me non c'entra molto con l'aprire
file nella stessa finestra (che invece è una delle funzioni di MDI); e
comunque ricordo che da qualche parte nel SDK di Windows, non chiedermi
dove, si sconsigliava l'uso del DDE, in quanto appunto sorpassato.
--
Saluti,
Mardy
Valter Minute
<20010516073435....@pupilla.local>:
[...]
>
>DDE = Dynamic data exchange? Secondo me non c'entra molto con l'aprire
>file nella stessa finestra (che invece è una delle funzioni di MDI); e
>comunque ricordo che da qualche parte nel SDK di Windows, non chiedermi
>dove, si sconsigliava l'uso del DDE, in quanto appunto sorpassato.
>
Generalmente il DDE è utilizzato dalla shell (explorer) per aprire i
documenti gestiti dalle applicazioni MDI (quelle SDI generalmente si
accontentano di un parametro a linea di comando).
E' sorpassato come i file di ini e dozzine di altre funzioni che però
vengono ancora sfruttate da parecchi programmi (ms in primis) poichè sono
implementate direttamente dai framework (MFC) o è possibile trovare codice
copia-incolla pronto all'uso.
Davide Inglima - limaCAT
>> Giusto per completezza... e' cosi'. Bladeenc (encoder mp3) si puo'
>> tranquillamente utilizzare passandogli un wav in input. Un esempio:
>> cat linus_thorvalds.wav | bladeenc -
> Amen.. non avevo pensato a questo caso, eppure l'ho pure usato spesso,
> vedi come alle volte ci si dimentica delle cose che si hanno proprio
> sotto al naso?
Beh, dai, per te e' comprensibile... con tutta quella barba :)
Cmq, Thorin, per controbilanciare posso dirti che
1) ho sfruttato tutti i tuoi post di domande su apt su ico.software
2) ho imparato l'uso di pstree
:p
--
Davide Inglima, limaCAT
Davide Inglima - limaCAT
>> cat linus_thorvalds.wav | bladeenc -
>Sě, ma non credo tu ottenga risultati apprezzabili passando
>linux_thorvalds.wev al programma per generare le signature
Magari se lo uuencodi prima :)
> o passando la
>"quote of the day" a bladeenc.
Azz... non ho una soluzione sulla punta di dita :)
>Il discorso era partito dal fatto che, tra i "punti deboli"
>dell'architettura COM, veniva elencato il fatto che fosse necessario
>conoscere le interfacce da utilizzare, considerazione che mi sembra ovvia e
>valida anche nel caso delle pipe.
E' ovvio... gli umani NON hanno la sfera di cristallo, dovrebbero averla gli
elaboratori? ;)
--
Davide Inglima, limaCAT
thorin_...@durin.khazad-dum.net
>> Amen.. non avevo pensato a questo caso, eppure l'ho pure usato spesso,
>> vedi come alle volte ci si dimentica delle cose che si hanno proprio
>> sotto al naso?
> Beh, dai, per te e' comprensibile... con tutta quella barba :)
:-)))
> Cmq, Thorin, per controbilanciare posso dirti che
> 1) ho sfruttato tutti i tuoi post di domande su apt su ico.software
'azzo e meno male, visto che apt ho iniziato a conoscerlo da
poco.. figuriamoci se fossi stato un esperto !!
> 2) ho imparato l'uso di pstree
Questo gia' e' un bene eheheh
David Mugnai
>>>>...e, se questo caso dovesse verificarsi, 'sa fo?
>>> Aspetti che scada il timer, succede anche in linux e credo che sia
>>> richiesto da TCP.
>>Ehm, penso che diciate due cose diverse.
>>Te intendi lo stato TIME_WAIT che occore dopo la chiusura *regolere* di
>>un socket.
> No. Intendo il periodo che passa tra il momento in cui uccidi un
> programma con un socket TCP aperto e in listening e il successivo
Stiamo dicendo la stessa cosa, che tu chiuda un socket con close(fd)
o uccida un processo (in questo caso la close la fa il kernel),
la connessione entra in stato di TIME_WAIT (poi mi sembra ci sia
la FIN_CLOSE1 e 2) per assicurasi che l'ultimo byte trasmesso sia giunto in
porto.
IL problema di cui parlavano e' un *po'* diverso.> momento in cui un altro programma potra` di nuovo usare quella porta.
--
Marco d'Itri
>Stiamo dicendo la stessa cosa, che tu chiuda un socket con close(fd)
>o uccida un processo (in questo caso la close la fa il kernel),
>la connessione entra in stato di TIME_WAIT (poi mi sembra ci sia
>la FIN_CLOSE1 e 2) per assicurasi che l'ultimo byte trasmesso sia giunto in
>porto.
Non e` lo stesso. Nel primo caso un server puo` immediatamente rifare il
bind su quella porta, nel secondo no.
Davide Inglima - limaCAT
<thorin_...@durin.khazad-dum.net> wrote:
>> 1) ho sfruttato tutti i tuoi post di domande su apt su ico.software
> 'azzo e meno male, visto che apt ho iniziato a conoscerlo da
> poco.. figuriamoci se fossi stato un esperto !!
Gia'... "man qualcosa" :)
--
Davide Inglima, limaCAT
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, KJK :: Hyperion interruppe il corso dei
miei pensieri bofonchiando:
>>l'ha lanciato e il suo PID fra le altre info (e sono tantissime).
>>Questo per _ogni_ task/processo/thread che giri nel sistema.
>ripeto: potrebbe non bastare. Ma chiudiamo il discorso perchè non mi
>interessa moltissimo una flame su ps
Non me ne viene in mente nessuno, e ci ho pensato.
Leonardo Serni
<ab...@1.2.0.1.0.0.1.e.f.f.3.ip6.int> wrote:
>ser...@tin.it wrote:
>>...e, se questo caso dovesse verificarsi, 'sa fo?
>Aspetti che scada il timer, succede anche in linux e credo che sia
>richiesto da TCP.
Seeeeeeeee. Che succeda in Linux puo' essere. Che su IIS basti aspettare
un qualche timer, ti garantisco di no.
Oppure, e' normale che il timer stia su per una decina di minuti, o che,
rialzando IIS, si resetti il timer?
Leonardo Serni
>Inchiodate la 25, la 110 e la 119. In alcuni *rarissimi* casi l'effetto
>collaterale del kill brutale è questo. C'è da dire che è questo server
>in particolare ad avere problemi tali da doverlo convincere spesso con
Eh. Io, stessi problemi, ma con la porta 80.
>>...e, se questo caso dovesse verificarsi, 'sa fo?
>la prima volta mi bastò riavviare il server, la seconda volta dopo il
>vodoo, il malocchio, le galline sacrificate a Baron Samedi e tre
>avemarie, non ci furono cazzi e dovetti riavviare la macchina
A parte che a Baron Samedi dovevi sacrificare dei galli, le galline
sono per Maman Brigitte (l'ho appreso durante i rituali svoltisi in
occasione degli ultimi due "problemini").
Pensando a qualche timer, o a memoria sporca o chissa' che cosa, ho
appunto provato:
- ad aspettare;
- a caricare e scaricare grosse applicazioni;
- a fare un paio di TELNET, a vuoto, sulla porta 80 dell'IP
esterno (hai visto mai?);
ma non e' servito.
Ho chiesto che aprissero la posizione all'Ufficio Personale per una
sistemista vergine con i capelli rossi, e lunedi' dovrebbe giungere
una cassa con due capre nere via DHL.
Sulla copertina di questo cazzo di libro c'e' pure scritto "Compra,
leggi, e non ti pentirai del prezzo" [1]: staremo a vedere.
Leonardo
[1] e' pero' una copia anastatica, usata. L'originale costa piu' di
un anno di stipendio, non avrei saputo come giustificarlo.
Obelix
wrote:
>Sulla copertina di questo cazzo di libro c'e' pure scritto "Compra,
>leggi, e non ti pentirai del prezzo" [1]
Buffo e' quasi la stessa frase delle cha line porno che pubblicizzano
dopo la mezzanotte...
Obelix cambia solo il secondo termine....
Marco Costamagna
<thorin_...@durin.khazad-dum.net> ha scritto nel messaggio
news:9dqcb7$1so$1...@durin.khazad-dum.net...
> In un messaggio del 15 May 2001 03:32:21 GMT KJK :: Hyperion scriveva:
...
> per favore, informatevi prima di scrivere di queste cose..
...E poi per localizzare un processo fra tanti c'e sempre il buon grep :-)
thorin_...@gruppocm-cs.it
>> per favore, informatevi prima di scrivere di queste cose..
> ...E poi per localizzare un processo fra tanti c'e sempre il buon grep :-)
"Il tool piu' bello che esista" (C) A. Rubini, se non ricordo male :)
Leonardo Serni
>>Sulla copertina [...] c'e' pure scritto "Compra, leggi, e non ti
>>pentirai del prezzo" [1]
>Buffo e' quasi la stessa frase delle chat line porno
...e, se pensi che il titolo e' "Il Mazzuolo delle Streghe"...
Leonardo e i corsi e ricorsi storici
KJK :: Hyperion
<9dqcjs$23l$1...@durin.khazad-dum.net>:
>> kill ammazza, anche troppo bene (gli handle non vengono chiusi, ad
>> esempio - rischi di trovarti socket aperte sul nulla profondo se
>> ammazzi un server)
>Veramente in molti casi non ammazza proprio niente anzi la cosa piu'
>comica e' quando alle volte, tentando di uccidere un processo, il
>task manager, che dovrebbe essere cio' che mi dovrebbe far uccidere
>il processo incriminato, muore lui stesso.
mai successo, ma piuttosto segui il mio consiglio, avvia il task manager
come servizio e nelle tue mani avrai un potere smisurato
>> l'implementazione Microsoft non l'hanno fatta loro, è del vecchio
>> codice BSD di cui hanno fatto il porting
>Non diciamo cazzate ! Stai forse dicendo che il codice BSD da cui m$
>ha _copiato_ non e' buono? Uhm, veramente comica questa, visto che
>implementazioni simili sulle piattaforme *NIX funzionano bene... se
>quelli di m$ non sanno neanche copiare bene che possiamo farci?
che ti devo dire, ho solo fatto una constatazione. Nessun giudizio
perchè io le socket non le ho mai digerite, su nessun sistema operativo.
E se posso astrarre dalle socket (DCOM I love you), ben venga
thorin_...@durin.khazad-dum.net
>>> kill ammazza, anche troppo bene (gli handle non vengono chiusi, ad
>>> esempio - rischi di trovarti socket aperte sul nulla profondo se
>>> ammazzi un server)
>>Veramente in molti casi non ammazza proprio niente anzi la cosa piu'
>>comica e' quando alle volte, tentando di uccidere un processo, il
[..]
> mai successo, ma piuttosto segui il mio consiglio, avvia il task manager
> come servizio e nelle tue mani avrai un potere smisurato
Mah, provero'... ma continuo ad avere i miei soliti dubbi sulla
possibilita' che qualcosa di m$ possa funzionare bene, specie dopo esser
"male abituato" con Linux.
>>> l'implementazione Microsoft non l'hanno fatta loro, è del vecchio
>>> codice BSD di cui hanno fatto il porting
>>Non diciamo cazzate ! Stai forse dicendo che il codice BSD da cui m$
[..]
> che ti devo dire, ho solo fatto una constatazione. Nessun giudizio
> perchè io le socket non le ho mai digerite, su nessun sistema operativo.
> E se posso astrarre dalle socket (DCOM I love you), ben venga
Beh secondo me e' proprio cosi', quelli di m$ non sono capaci nemmeno di
copiare e che abbiano copiato lo dice strings(1):
[root@durin windows]# strings ftp.exe | less
!This program cannot be run in DOS mode.
.text
`.data
.rsrc
@.reloc
WSOCK32.dll
USER32.dll
CRTDLL.dll
ADVAPI32.dll
KERNEL32.dll
[..]
@(#) Copyright (c) 1983 The Regents of the University of California.
All rights reserved.
KJK :: Hyperion
dum.net>:
> @(#) Copyright (c) 1983 The Regents of the University of California.
^^^^
alla faccia...
thorin_...@durin.khazad-dum.net
>> @(#) Copyright (c) 1983 The Regents of the University of California.
> ^^^^
> alla faccia...
Gia', eh? Copia di vecchia data e'...
KJK :: Hyperion
<90A37DC02V...@212.110.0.170>:
> Dire che COM (qui visto in contrapposizione con le pipes) non è
> "elegante" perchè devi conoscere le interfacce dei vari servizi che
> vai ad utilizzare è un'affermazione priva di senso.
non serve conoscerle, basta importarle. Tutti i server OLE girano
assieme alla loro type library, con la descrizione dell'interfaccia
Valter Minute
>> "elegante" perchè devi conoscere le interfacce dei vari servizi che
>> vai ad utilizzare è un'affermazione priva di senso.
>
>non serve conoscerle, basta importarle. Tutti i server OLE girano
>assieme alla loro type library, con la descrizione dell'interfaccia
>
Non è obbligatorio fornire e registrare la type library (anche se è vero
che la maggior parte dei server lo fanno).
E comunque una volta importate dovrai pur capire come utilizzarle.
Gianluca
pidof non funziona ?
bye
Gianluca
KJK :: Hyperion
>Non č obbligatorio fornire e registrare la type library (anche se č
>vero che la maggior parte dei server lo fanno)
per pubblicare interfacce DEVI registrarle. Per uso interno non č
obbligatorio, ma per la vera essenza dell'OLE (*scambio* di dati) sě
>E comunque una volta importate dovrai pur capire come utilizzarle.
OLE prevede librerie auto-documentate, anche se molti se ne fregano e
non documentano
Valter Minute
127.0.0.1>:
>vmi...@REMOVEMEinwind.it (Valter Minute) wrote in
><90A866B30V...@212.110.0.170>:
>
>>Non è obbligatorio fornire e registrare la type library (anche se è
>>vero che la maggior parte dei server lo fanno)
>
>per pubblicare interfacce DEVI registrarle. Per uso interno non è
>obbligatorio, ma per la vera essenza dell'OLE (*scambio* di dati) sì
>
Devi registrare le classi, non le type library. I miei oggetti potrebbero
utilizzare un'interfaccia IPippo e non registrare da nessuna parte la sua
definizione.
Ovviamente è buona norma registrare le type library con la definizione
delle interfacce che vuoi rendere accessibili dall'esterno.
Registrare le type library è utile se i tuoi oggetti dovranno essere
utilizzati da sistemi (tipicamente i motori di script) che utilizzano solo
l'interfaccia IDispatch.
OLE è solo un'applicazione di COM e che non è finalizzato allo scambio dati
ma piuttosto all'interazione tra componenti.
>>E comunque una volta importate dovrai pur capire come utilizzarle.
>
>OLE prevede librerie auto-documentate, anche se molti se ne fregano e
>non documentano
>
Comunque dovrai andarti a vedere quella "documentazione" e spesso l'help
relativo a classi e metodi non è sufficiente per capire come utilizzare le
classi.
Marco Costamagna
"Gianluca" <gian...@goldrake.gianluca.org> ha scritto nel messaggio
news:slrn9gb4a3....@goldrake.gianluca.org...
> On Fri, 18 May 2001 09:22:45 GMT, Marco Costamagna
<marco...@LEVAMIhotmail.com> wrote:
> > ...E poi per localizzare un processo fra tanti c'e sempre il buon grep
:-)
>
> pidof non funziona ?
>
Si, ma sono un ultrà di grep :-)