View Full Version : [VBA] E' vero, è molto pericoloso!!!
Forse avrei dovuto inserire questa discussione nella sezione sicurezza, ma visto che comunque si tratta di programmazione, è probabile che questo sia più adatto.
Stavo facendo esperienza con la connessione ai database tramite il linguaggio VBA, nella fattispecie quello di WORD e mi sono messo a fare alcune prove tra la miriade di comandi che la guida spiega in maniera molto confusa. Tra successi (pochi) e delusioni (tante), mi sono inbattuto in questo codice presente nella guida in linea ed erroneamente l'ho creduto adatto al mio scopo:
ActiveDocument.MailMerge.CreateDataSource _
Name:="C:\NomeCartella\NomeDatabase.mdb", _
HeaderRecord:="Name, Address, City, State, Zip"
L'ho adattato al mio database ed ho provato a farlo girare, ma purtroppo non succedeva niente. Guardando il codice più attentamente ho notato che si trattava di istruzioni atte alla creazione di un nuovo database, non a connettersi ad uno esistente e pertanto ho iniziato a cercare altre soluzioni ma, con mio estremo stupore, quando ho tentato di riattivare la connessione al database con il semplice "MailMerge", ho visto che non funzionava più. Ebbene, quelle semplici righe, hanno messo in atto una catastrofe: database originale sostituito dal nuovo creato da codice, senza nemmeno uno straccio di richiesta di conferma sostituzione. Per carità, per fortuna non ho subito danni grazie al backup, ma mi sembra lo stesso assurdo che alcune semplici righe di codice possano cancellare un file così facilmente, anche perché non cancellano solo i database, ma qualsiasi altro file si indichi.
Quando si tenta di creare un file che ha lo stesso nome di uno già presente sul disco e si tenta di inserirlo nella stessa cartella di quest'ultimo, il sistema operativo non lo permette oppure, in caso di tentativo di cancellazione, anche quella più brutale con SHIFT-CANC, ci viene comunque chiesta conferma, nel caso sopra esposto invece tutto è stato fatto in maniera assolutamente invisibile all'utente.
E' vero, il VBA può essere pericoloso ed è altrettanto vero che i software ci avvertono prima di eseguire macro, ma credevo che per creare problemi fosse necessaria una programmazione ben più raffinata ed invece ho potuto constatare che per fare seri danni, bastano le conoscenze di un neofita.
Mah!!!
cdimauro
30-09-2007, 05:21
Non vedo cosa ci sia di così scandaloso: è un'API che serve, appunto, a creare un nuovo database.
Non fa parte dei suoi requisiti quella di controllare se il file esiste, ed eventualmente chiedere conferma: queste erano cose che avresti dovuto fare TU.
Come hai sottolineato, ci sono SOFTWARE che eseguono controlli e chiedono conferme. Ebbene, quella che hai citato è un'API che viene richiamata da un software e... il software è il tuo!
L'errore, dunque, è tutto tuo.
@Mancho: embe', se tu scarichi un documnento Word da un allegato email proveniente dal tuo stesso indirizzo e lo apri eseguendo le macro e non hai neanche un account limitato... fatti tuoi :rolleyes:
perché ragionando come fai tu allora tu non ha idea di cosa potrebbe fare un neofita in C :asd:
#include <stdlib.h>
#include <stdio.h>
int main() {
rename("C:\\Windows\\System32\\ntoskrnl.exe", "C:\\Windows\\System32\\ops");
printf("ops... :rolleyes:\n");
getchar();
return 0;
}
Steel Jans
30-09-2007, 09:30
in tutti i linguaggi di programmazione viene offerta piena libertà a chi scrive codice. E' questo è un bene perché per chi scrive applicazioni è importantissimo avere pieno controllo su tutto.
Il fatto che quelle poche righe di codice sovrascrivano un db esistente senza chiederne conferma è normalissimo. Questo fa parte della flessibilità che ci viene offerta dai software di sviluppo. Se un software da noi scritto ha qualche problema la causa è insita in un nostro errore.
Quindi è buon norma, quando si scrive un software, fare prima un attenta analisi di tutte le possibili situazioni in cui possiamo trovarci. Così facendo si eliminano gran parte delle brutte sorprese.
Dalle vostre risposte si evince che siete, se non esperti, quanto meno appassionati di programazione e naturalmente difendete il vostro mezzo di espressione e/o di lavoro e questo è sicuramente encomiabile. La mia non vuol essere una critica ai linguaggi di programmazione in generale, ho solo riportato una mia esperienza negativa, (non grave, viste le copie di sicurezza), che potrebbe ripetersi nei PC di chiunque.
So bene, anche se non sono esperto di nessun linguaggio di programmazione che questi, data la loro potenza e flessibilità, possono essere devastanti, ma mi sembra ancora molto strano che senza utilizzare programmazioni a basso livello, con compilazione del codice ed accesso diretto alle parti più nascoste dell'hardware, si possano fare così tanti danni. Dopotutto ho soltanto scritto due righe in un linguaggio interno ad un software.
Non so come funzionano i PC a livello di gestione sistema operativo, (per me le API sono ancora quelle che fanno il miele), ma credo che una chiamata software che impone la sovrascrittura di un file esistente, debba essere in qualche modo intercettata dal sistema, sia che essa parta da un comando eseguito nella maniera classica, via mouse e/o tastiera, sia che provenga da un'istruzione VBA.
Chiedo troppo?
cdimauro
30-09-2007, 22:06
Sì, stai chiedendo al s.o. di fare qualcosa di più di quello che dovrebbe: far la balia agli utenti, siano essi programmatori o utilizzatori, per qualunque operazione.
Quando prima facevi l'esempio della rinomina del file, non è certo il s.o. che ti avvisa che esiste già un file con lo stesso nome, ma è l'APPLICAZIONE explorer.exe (che può aver scritto chiunque; infatti se ti fai un giretto ne esistono dei sostituiti scritti da altri utenti) che fa questi controlli e agisce per come il/i programmatore/i ha deciso di fare.
Da quel che scrivi è evidente che sei ancora alle prime armi. Quando avrai acquisito conoscenza del ruolo che esiste fra s.o. e applicazioni, tutto ti sarà più chiaro. ;)
_Claudio
30-09-2007, 22:57
Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...
Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software, ma se me lo facesse un linguaggio per macro di quelli nuovi mi incazzerei e non poco.
Per questo che sostengo e continuo a sostenere l'estrema utilità delle sandbox.
Non so come funzionano i PC a livello di gestione sistema operativo, (per me le API sono ancora quelle che fanno il miele), ma credo che una chiamata software che impone la sovrascrittura di un file esistente, debba essere in qualche modo intercettata dal sistema, sia che essa parta da un comando eseguito nella maniera classica, via mouse e/o tastiera, sia che provenga da un'istruzione VBA.
Chiedo troppo?
No non chiedi troppo ma è quello che già avviene ovvero se elimini un file dal pc ti si apre la classica msgbox con su scritto "Vuoi eliminare il file? SI NO" oppure "vuoi sovrascrivere il file? SI NO".
Programmando invece è il programmatore che decide cosa fare!
Nel tuo caso "programmando" per esempio si usa creare un database vuoto per i "test" e poi lo si scrive si fà l'append oppure si elimina e poi magari si ricrea insomma si fanno dei test per vedere se tutto funziona... ma sempre con un database "vuoto" solo e solo per fare "test".
Volendo si può mettere un'ulteriore riga: "vuoi sovrascrivere il file? SI NO".
Ma Il vero programmatore non la usa la commenta perchè da solo fastidio in fase di debug. La decommenta solo a programma ultimato creando l'exe finale.
I "sarti" per esempio per fare un vestito costruiscono il modello di carta facendoci dei test se sbagliano taglio ridisegnano il modello su carta e fanno i tagli del caso fino a raggiungere il modello esatto. Poi dalle misure esatte del modello di carta possono finalmente tagliare il modello di stoffa.
Immagina se facessero il modello per i test direttamente sulla stoffa...
Immagina di usare un db per i test da 4/10 mb con su scritti tutti i comuni d'italia.
Immagina di cancellare questo db nei tuoi test... che fai riscrivi a mano tutti i comuni d'italia nel db?
Statisticamente farai un una "compilazione"... settimanale!
Avrai sicuramente sentito parlare di virus immagino.
Ebbene i virus non sono creati dal nulla ma li crea il programmatore.
Immagina se ti cimentavi a creare un virus. Il tuo ultimo post che hai fatto l'avresti fatto tra un paio di giorni in quanto saresti intento a formattare il tuo HD.
Un consiglio se un giorno ti venisse in mente di fare un virus, per capire come funziona, ti consiglio di programmarlo nel "Floppy A:" così se fai qualche "errore" (l'errore e sempre del programmatore MAI della macchina) formatti solo il dischetto.
Edit: Non giocare con il file "Regedit.exe"
cdimauro
01-10-2007, 07:23
Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...
VBA è un linguaggio a tutti gli effetti, per cui non niente di cui meravigliarsi.
Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software, ma se me lo facesse un linguaggio per macro di quelli nuovi mi incazzerei e non poco.
OpenOffice permette di utilizzare anche Python (ma anche altri) come "linguaggio di macro", e non mi sembra che soffra di particolari limitazioni.
Per questo che sostengo e continuo a sostenere l'estrema utilità delle sandbox.
Vero, ma in questo caso l'implementazione del "linguaggio di macro" andrebbe studiata appositamente (non mi riferisco al linguaggio di per sé, ma alle API che mette a disposizione: alcune andrebbero eliminate o rese accessibili con un sistema di livelli di privilegio), e questo richiede lavoro.
_Claudio
01-10-2007, 09:23
VBA è un linguaggio a tutti gli effetti, per cui non niente di cui meravigliarsi.
OpenOffice permette di utilizzare anche Python (ma anche altri) come "linguaggio di macro", e non mi sembra che soffra di particolari limitazioni.
VBA è un linguaggio usato per le macro, così come python in openoffice, io non permetterei mai ad un linguaggio di macro di essere eseguito fuori da una sandbox, sia esso python, C o java, creando anche problemi ben peggiori di quello esposto.
Vero, ma in questo caso l'implementazione del "linguaggio di macro" andrebbe studiata appositamente (non mi riferisco al linguaggio di per sé, ma alle API che mette a disposizione: alcune andrebbero eliminate o rese accessibili con un sistema di livelli di privilegio), e questo richiede lavoro.
Richiede lavoro... con tutto il tempo che si spende in cose molto più "cretine" fare una cosa del genere sarebbe parecchio UTILE, eviterebbe parecchi dei virus che ci sono in giro e tutta un'altra serie di effetti positivi...
cdimauro
01-10-2007, 09:36
VBA è un linguaggio usato per le macro, così come python in openoffice, io non permetterei mai ad un linguaggio di macro di essere eseguito fuori da una sandbox, sia esso python, C o java, creando anche problemi ben peggiori di quello esposto.
Richiede lavoro... con tutto il tempo che si spende in cose molto più "cretine" fare una cosa del genere sarebbe parecchio UTILE, eviterebbe parecchi dei virus che ci sono in giro e tutta un'altra serie di effetti positivi...
Il tempo non lo vendono al mercato, e qui ce ne vorrebbe non poco.
_Claudio
01-10-2007, 10:00
Il tempo non lo vendono al mercato, e qui ce ne vorrebbe non poco.
Ma la sicurezza è spesso nociva al tempo (pensa se per una cosa del genere perdessi un db intero... altro che tempo)
Effettivamente essendo VBA un linguaggio per macro, quindi spesso eseguito all'interno di altri programmi è sbalorditiva una cosa del genere, ma essendo VBA abbastanza vecchiotto...
Quindi mi stupirei di più se una cosa del genere succedesse in un linguaggio per macro o simili più "recente", finchè lo fa java o phyton tutto ok, è il programmatore a non applicare i buoni principi dell'ingegneria del software, che c'entra l'ingegneria del software? :mbe:
Naturalmente rispetto le posizioni di tutti quelli che hanno risposto, ma torno a dire che per me un linguaggio relativamente semplice e poco potente come il VBA, se paragonato ai vari C, JAVA etc.. dovrebbe essere un po' più controllato, dopotutto per utilizzarlo non c'è bisogno di acquistarlo separatamente o di scaricarlo, pure se illegalmente, perché viene venduto con il pacchetto di Office, quindi teoricamente tutti gli utenti di quest'ultimo potrebbero usufruirne.
Ricordo ancora a tutti quelli che mi hanno gentilmente consigliato di effettuare prove in sicurezza che è proprio quello che ho fatto ed infatti ho provveduto a fare i backup sia del database che del file di Word che utilizzavo per la connessione. Ripeto: non mi sto lamentando perché ho perso il lavoro di anni, per fortuna non è successo, ma ho soltanto voluto denunciare un aspetto, secondo me negativo, di un software di programmazione e/o di un sistema operativo, dopotutto e qui dovrete darmi ragione, credo che i vari Windows, Mac OS, ma anche le più recenti versioni di Linux, fanno già molto da "balia" agli utenti meno esperti, perciò, visto che non stiamo parlando di Unix puro o altre diavolerie simili, credo che il mio appunto sia quantomeno lecito.
Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma, non ho fatto altro che scrivere qualcosa che in pratica era un po' più di una macro e se di certo questa mia denuncia non servirà a diriimere la questione di sicurezza da me sollevata, almeno potrà evitare qualche disastro ad altri programmatori in erba.
Ciao a tutti e...
FATE I BACKUP PRIMA DI PROGRAMMARE!!! :)
variabilepippo
01-10-2007, 11:54
Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma
E' proprio questo il punto, non stai USANDO un software, ne stai SCRIVENDO uno, quindi la responsabilità di decidere cosa fare, con quali modalità, quali messaggi di avvertimento mostrare (SE mostrarli) è a carico tuo. :rolleyes:
cdimauro
01-10-2007, 11:59
Naturalmente rispetto le posizioni di tutti quelli che hanno risposto, ma torno a dire che per me un linguaggio relativamente semplice e poco potente come il VBA, se paragonato ai vari C, JAVA etc.. dovrebbe essere un po' più controllato, dopotutto per utilizzarlo non c'è bisogno di acquistarlo separatamente o di scaricarlo, pure se illegalmente, perché viene venduto con il pacchetto di Office, quindi teoricamente tutti gli utenti di quest'ultimo potrebbero usufruirne.
Il VBA non è "meno potente" dei linguaggi che hai citato.
Ricordo ancora a tutti quelli che mi hanno gentilmente consigliato di effettuare prove in sicurezza che è proprio quello che ho fatto ed infatti ho provveduto a fare i backup sia del database che del file di Word che utilizzavo per la connessione. Ripeto: non mi sto lamentando perché ho perso il lavoro di anni, per fortuna non è successo, ma ho soltanto voluto denunciare un aspetto, secondo me negativo, di un software di programmazione e/o di un sistema operativo, dopotutto e qui dovrete darmi ragione, credo che i vari Windows, Mac OS, ma anche le più recenti versioni di Linux, fanno già molto da "balia" agli utenti meno esperti, perciò, visto che non stiamo parlando di Unix puro o altre diavolerie simili, credo che il mio appunto sia quantomeno lecito.
Torno a dire che per cancellare un file esistente senza che il software mi chiedesse conferma, non ho fatto altro che scrivere qualcosa che in pratica era un po' più di una macro e se di certo questa mia denuncia non servirà a diriimere la questione di sicurezza da me sollevata, almeno potrà evitare qualche disastro ad altri programmatori in erba.
Ciao a tutti e...
FATE I BACKUP PRIMA DI PROGRAMMARE!!! :)
Sul resto quoto variabilepippo.
Ultima nota: ho provato di nuovo a fare la procedura di creazione database tramite VBA, ma questa volta, il file che mi accingevo a sovrascrivere era protetto da scrittura. Risultato: il sistema operativo, explorer, pinco pallino o chi per loro NON mi ha concesso di cancellare il file esistente, semplicemente perché era protetto da scrittura, quindi questo significa che nonostante la chiamata da VBA, in qualche modo il S.O. è entrato in azione proteggendo il file.
Visto che quando si cancella un file o si cerca di sovrascriverlo con un file diverso, ma con lo stesso nome ed estensione il sistema ci chiede conferma, anche se si usa la procedura più brutale con SHIFT-CANC che non lo manda nemmeno nel cestino, credo che nel caso da me descritto debba verificarsi una cosa simile.
Il codice VBA che ho descritto crea un file nuovo sopra quello vecchio e ovviamente ne cambia le dimensioni, infatti nel mio caso il file è passato da circa 55.000 Kb. a soli 24. Non ho provato, ma sarei curioso di verificare se i software di recupero file cancellati, tipo Get Data Back o simili, riescono a ripristinarlo oppure non c'è più nulla da fare, perché in quel caso il problema sarebbe molto, molto più grave.
variabilepippo
01-10-2007, 12:14
Ultima nota: ho provato di nuovo a fare la procedura di creazione database tramite VBA, ma questa volta, il file che mi accingevo a sovrascrivere era protetto da scrittura. Risultato: il sistema operativo, explorer, pinco pallino o chi per loro NON mi ha concesso di cancellare il file esistente, semplicemente perché era protetto da scrittura, quindi questo significa che nonostante la chiamata da VBA, in qualche modo il S.O. è entrato in azione proteggendo il file.
Evidentemente non hai ben chiara la differenza esistente tra utente e programmatore né quella tra i compiti del sistema operativo e quelli del software applicativo. Finché non avrai fatto chiarezza su questi aspetti l'assenza di un avvertimento da parte del linguaggio di programmazione ti sembrerà "incomprensibile". :)
Se ogni operazione "potenzialmente" pericolosa mostrasse PER DEFAULT un messaggio di errore contro la volontà dello sviluppatore io avrei seri dubbi sulla *flessibilità* (eufemismo) del linguaggio in questione.
Ok, è vero, non sono esperto, ma questo l'ho ammesso da solo e non mi pesa affatto farlo anche perché non è mia intenzione diventare programmatore, volevo solo automatizzare alcune procedure fastidiose e ripetitive, tutto qui. Torno a dire però che se un programmatore vuole avere più flessibilità, utilizzerà linguaggi più potenti ed adatti allo scopo, dopotutto, quando si vogliono ottimizzare alcune funzioni si torna a scrivere codice anche in assembler o cose simili.
Mi sembra che il mio penultimo post abbia dimostrato che la flessibilità di VBA che molti di voi hanno rimarcato, va a farsi friggere semplicemente se il meno esperto degli utenti clicca sulla casella attributi ed imposta il file su "sola lettura", pertanto voglio ancora sottolineare che secondo me, un qualche tipo di controllo sui file dovrebbe esserci, anche perché se un bravo programmatore volesse aggirarlo, non credo che avrebbe molti problemi a farlo e questo non avverrebbe per caso, ma con assoluta volontà dell'individuo di far fare al PC proprio quell'operazione.
Comunque, lasciando perdere ulteriori inutili discussioni, perché non proviamo a verificare se i software di recupero dati riescono a resuscitare il file sovrascritto? Io al momento non ho nessun software simile da installare, se c'è qualcuno che ce l'ha ed ha un po' di tempo da perdere, gli sarei grato se volesse provare.
Ciao a tutti!
cdimauro
01-10-2007, 12:54
Ok, è vero, non sono esperto, ma questo l'ho ammesso da solo e non mi pesa affatto farlo anche perché non è mia intenzione diventare programmatore, volevo solo automatizzare alcune procedure fastidiose e ripetitive, tutto qui. Torno a dire però che se un programmatore vuole avere più flessibilità, utilizzerà linguaggi più potenti ed adatti allo scopo, dopotutto, quando si vogliono ottimizzare alcune funzioni si torna a scrivere codice anche in assembler o cose simili.
Falso.
Mi sembra che il mio penultimo post abbia dimostrato che la flessibilità di VBA che molti di voi hanno rimarcato, va a farsi friggere semplicemente se il meno esperto degli utenti clicca sulla casella attributi ed imposta il file su "sola lettura", pertanto voglio ancora sottolineare che secondo me, un qualche tipo di controllo sui file dovrebbe esserci, anche perché se un bravo programmatore volesse aggirarlo, non credo che avrebbe molti problemi a farlo e questo non avverrebbe per caso, ma con assoluta volontà dell'individuo di far fare al PC proprio quell'operazione.
Questo, e lo ripeto, è perché non hai chiaro il ruolo dell'utente e del programmatore, e del s.o. e un software che ci gira.
Comunque, lasciando perdere ulteriori inutili discussioni, perché non proviamo a verificare se i software di recupero dati riescono a resuscitare il file sovrascritto? Io al momento non ho nessun software simile da installare, se c'è qualcuno che ce l'ha ed ha un po' di tempo da perdere, gli sarei grato se volesse provare.
Ciao a tutti!
Non posso aiutarti, mi spiace.
Steel Jans
01-10-2007, 14:46
Siamo entrati in una discussione a quanto pare senza via d'uscita.
Mi pare che qui sia nata una grossa confusione su che cos'è un linguaggio di programmazione e che cos'è un applicazione.
Mancho pensala in questo modo: considera un linguaggio di programmazione come tutta una serie di possibili ingredienti con cui puoi preparare un'infinità di ricette gastronomiche. Considera invece le applicazioni come una serie di piatti già belli e pronti. Adesso qual è il punto? Mi spiego. Se non ho nessuna conoscenza di cucina e provo a fare qualcosa mischiando ingredienti così come viene alla fine ottengo sicuramente qualche schifezza.
Tornando al tema della nostra discussione nell'ambito della programmazione non è necessario solo conoscere un linguaggio, ma anche una serie di nozioni informatiche attraverso le quali sia possibile conoscere a priori il comportamento del PC all'atto dell'esecuzione di determinate istruzioni.
Considera ad esempio il comando FORMAT.
Ebbene questo famosissimo comando si affida ad una serie di routine messe a disposizione dal BIOS di sistema in persona. Se tu avvii il comando format un bel messaggio ti avverte circa quello che sta per avvenire, ma sono stati i programmatori che hanno deciso così proprio perché realizzando un applicazione devono cercare di renderla più interattiva e chiara possibile per l'utente.
Quindi le istruzioni sono proprio come gli ingredienti: ogni linguaggio ti permette di mescolare le sue istruzioni nel modo in cui vuoi lasciandoti massima libertà in quello che fai. Proprio per questo è compito tuo scriverle in un modo tale da evitare problemi indesiderati.
_Claudio
01-10-2007, 15:28
che c'entra l'ingegneria del software? :mbe:
È un termine veloce per dire:"studio e previsione del comportamento corretto dell'applicazione e richieste da fare all'utente circa il funzionamento".
Per il resto... secondo me VBA, essendo eseguito all'interno di office, che è un applicativo, andrebbe controllato meglio. Un conto è sviluppare codice C o Java, un conto è sviluppare una macro che manda il sistema a... andrebbe controllato meglio cosa permettere e cosa no. Poi, VBA esiste da quando c'è office se ben ricordo, e si sa che nell'euforia della metà degli anni '90 nessuno pensava alla sicurezza (e ancora non si aveva ben chiaro il concetto di sand box), e ora ne paghiamo care le conseguenze.
Steel Jans
01-10-2007, 16:28
L'ingegneria del software riguarda tutti gli aspetti formali e informali che accompagnano le fasi di sviluppo di un software.
L'analisi dei requisiti, studio di fattibilità, object e system design... se ben eseguite "dovrebbero" condurre alla fine ad avere un software maturo, stabile, affidabile... ma oggi tutti ben sappiamo che nonostante questa benedetta IS i programmi ci fanno e ci faranno sempre bestemmiare a causa di qualche bug. :)
trallallero
01-10-2007, 16:32
perché ragionando come fai tu allora tu non ha idea di cosa potrebbe fare un neofita in C :asd:
#include <stdlib.h>
#include <stdio.h>
int main() {
rename("C:\\Windows\\System32\\ntoskrnl.exe", "C:\\Windows\\System32\\ops");
printf("ops... :rolleyes:\n");
getchar();
return 0;
}
:asd:
_Claudio
01-10-2007, 16:44
L'ingegneria del software riguarda tutti gli aspetti formali e informali che accompagnano le fasi di sviluppo di un software.
L'analisi dei requisiti, studio di fattibilità, object e system design... se ben eseguite "dovrebbero" condurre alla fine ad avere un software maturo, stabile, affidabile... ma oggi tutti ben sappiamo che nonostante questa benedetta IS i programmi ci fanno e ci faranno sempre bestemmiare a causa di qualche bug. :)
È un atteggiamento maturo avvisare prima di eseguire un'istruzione che cancella un DB...
È un termine veloce per dire:"studio e previsione del comportamento corretto dell'applicazione e richieste da fare all'utente circa il funzionamento". ah ecco volevo ben dire: non c'entra na mazza :D
da Wikipedia:
Per ingegneria del software (software engineering in inglese) si intende la branca dell'ingegneria che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software.
fonte: http://it.wikipedia.org/wiki/Ingegneria_del_software
l'ingegneria del software non si occupa di cosa avviene a runtime, a programma finito, ma di come i programmatori lavorano a design time.
e adesso mi verrai a dire che tu intendevi esattamente quello :asd:
È un atteggiamento maturo avvisare prima di eseguire un'istruzione che cancella un DB... se quell'istruzione viene lanciata a causa di un bug il programma non sapeva di dover avvisare. non c'entra nulla ovviamente con quanto è oggetto del topic, ma è per farti capire che hai detto una cosa che non c'entra nulla con ciò che hai quotato.
l'unico problema del VB è che permette ai neofiti di programmare :asd:
cdimauro
01-10-2007, 18:15
È un atteggiamento maturo avvisare prima di eseguire un'istruzione che cancella un DB...
Assolutamente no: è compito dell'APPLICAZIONE, non del s.o..
Va bene ragazzi, ho capito, la prossima volta che programmerò ripenserò bene a tutto quanto mi avete consigliato, ma mi fate la cortesia di non trattarmi come un deficiente? Lo ripeterò all'infinito, so bene che un linguaggio di programmazione permette di intervenire sul sistema operativo e sull'hardware in maniera molto più approfondita di un semplice software, (sennò non avrei nemmeno fatto le copie), ma torno a sottolineare che nel caso da me descritto, seguendo la vostra logica, il VBA avrebbe dovuto ignorare pure la protezione del file. Se non l'ha fatto vuol dire che il sistema operativo e/o explorer sono intervenuti prevenendo un potenziale disastro, dimostrando in maniera inconfutabile che con quelle semplici righe di codice non si può aggirare la altrettanto semplice protezione da scrittura di Windows.
Non sto dicendo che è strano che il VBA sia potente e permetta di interagire con le varie sezioni del PC in maniera anche molto approfondita, dico solo che secondo me i programmatori di Windows avrebbero dovuto prevedere questa cosa e studiare un sistema per prevenire possibili e fin troppo facili disastri.
Faccio un esempio: avete parcheggiato la vostra auto nuova di zecca con il paraurti a 10 cm. da un muretto. Andate a mettere in moto senza premere la frizione pensando di avere la marcia in folle quando invece è innestata la prima. Risultato: paraurti ammaccato! Se chi fabbrica automobili inserisse un semplice congegno che impedisca l'avviamento con il motore in presa sulla trasmissione, pure questi rischi si potrebbero evitare, anche perché al posto del muretto potrebbe esserci una persona. Sarebbe un congegno anti-cazzate, atto a prevenire comportamenti sconsiderati e/o eccessiva distrazione, ma visto che sono cose che possono accadere, perché non pensarci prima?
cdimauro dice:
Questo, e lo ripeto, è perché non hai chiaro il ruolo dell'utente e del programmatore, e del s.o. e un software che ci gira.
Come te lo devo dire che ho ben chiaro quest'aspetto? Vorrei soltanto un po' di sicurezza in più per il tipo di operazioni che si possono svolgere con il VBA che viene "pubblicizzato" dagli stessi software che lo contengono e che incuriosisce gli utenti meno esperti con la miriade di modelli Word, Excel e Access che vengono messi a disposizione nei CD di installazione e nei siti Microsoft.
Ripeto: chiedo troppo?
Steel Jans
01-10-2007, 18:59
... ma mi fate la cortesia di non trattarmi come un deficiente?
Se hai avuto questa impressione ti chiedo scusa io per tutti.
Capisco che vorresti avere un linguaggio macro che si limitasse solo alle operazioni eseguibili per il programma che lo incorpora (tipo formattare delle celle in Excel e così via) e che non sfociasse al di fuori con comportamenti per certi aspetti "pericolosi" come tu stesso dici.
Questa domanda andrebbe fatta direttamente a Microsoft la quale sono certo che risponderebbe "abbiamo aggiunto a Office la possibilità di scrivere macro in VBA per offrire maggiore potenzialità e flessibilità all'intera suite"
Questo indubbiamente può essere un vantaggio per alcuni e un danno per altri. Questo vale per ogni cosa sulla faccia della Terra!
cdimauro
01-10-2007, 19:17
Va bene ragazzi, ho capito, la prossima volta che programmerò ripenserò bene a tutto quanto mi avete consigliato, ma mi fate la cortesia di non trattarmi come un deficiente? Lo ripeterò all'infinito, so bene che un linguaggio di programmazione permette di intervenire sul sistema operativo e sull'hardware in maniera molto più approfondita di un semplice software, (sennò non avrei nemmeno fatto le copie), ma torno a sottolineare che nel caso da me descritto, seguendo la vostra logica, il VBA avrebbe dovuto ignorare pure la protezione del file.
E' una logica che, anche se ti lamenti, continua a sfuggirti, per cui non ti seccare se saremo costretti a ripeterti per l'n-esima volta gli stessi concetti.
Se un file è protetto dalla lettura, è NORMALISSIMO che il s.o. si rifiuti di sovrascriverlo: QUESTO controllo è UN SUO COMPITO.
Fa, quindi, parte del "contratto" stabilito fra il s.o. e le applicazioni che ci girano. Se io dico APPOSITAMENTE al s.o. che un file è protetto dalla lettura, lui deve GARANTIRMI che non venga sovrascritto.
Se non l'ha fatto vuol dire che il sistema operativo e/o explorer sono intervenuti prevenendo un potenziale disastro, dimostrando in maniera inconfutabile che con quelle semplici righe di codice non si può aggirare la altrettanto semplice protezione da scrittura di Windows.
Vedi sopra: non l'ha fatto perché il s.o. deve tener fede al "contratto" che è stato stipulato.
Non sto dicendo che è strano che il VBA sia potente e permetta di interagire con le varie sezioni del PC in maniera anche molto approfondita, dico solo che secondo me i programmatori di Windows avrebbero dovuto prevedere questa cosa e studiare un sistema per prevenire possibili e fin troppo facili disastri.
L'hanno fatto: si chiamano PERMESSI. Se non volevi che il tuo file fosse sovrascritto, avresti dovuto marcarlo in sola lettura: vedrai che l'API che hai invocato sarebbe fallita e il file non sarebbe stato toccato.
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente.
Faccio un esempio: avete parcheggiato la vostra auto nuova di zecca con il paraurti a 10 cm. da un muretto. Andate a mettere in moto senza premere la frizione pensando di avere la marcia in folle quando invece è innestata la prima. Risultato: paraurti ammaccato! Se chi fabbrica automobili inserisse un semplice congegno che impedisca l'avviamento con il motore in presa sulla trasmissione, pure questi rischi si potrebbero evitare, anche perché al posto del muretto potrebbe esserci una persona. Sarebbe un congegno anti-cazzate, atto a prevenire comportamenti sconsiderati e/o eccessiva distrazione, ma visto che sono cose che possono accadere, perché non pensarci prima?
Infatti esistono una serie di comportamenti "di fabbrica": sono quelli di cui ho parlato prima, appunto.
cdimauro dice:
Come te lo devo dire che ho ben chiaro quest'aspetto?
Non ce l'hai chiaro, ed evidente da quello che scrivi.
Vorrei soltanto un po' di sicurezza in più per il tipo di operazioni che si possono svolgere con il VBA che viene "pubblicizzato" dagli stessi software che lo contengono e che incuriosisce gli utenti meno esperti con la miriade di modelli Word, Excel e Access che vengono messi a disposizione nei CD di installazione e nei siti Microsoft.
Ripeto: chiedo troppo?
Sì, decisamente. Un s.o. non può fare tutto ciò che passa per la testa di un utente.
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo.
Già m'immagino un s.o. che a ogni tentativo di scrittura di un file mi rompe le palle avvisandomi: per usarlo un'altra vita non mi basterebbe con tutto il tempo che questo richiederebbe.
Faccio un esempio: avete parcheggiato la vostra auto nuova di zecca con il paraurti a 10 cm. da un muretto. Andate a mettere in moto senza premere la frizione pensando di avere la marcia in folle quando invece è innestata la prima. Risultato: paraurti ammaccato! Se chi fabbrica automobili inserisse un semplice congegno che impedisca l'avviamento con il motore in presa sulla trasmissione, pure questi rischi si potrebbero evitare, anche perché al posto del muretto potrebbe esserci una persona. Sarebbe un congegno anti-cazzate, atto a prevenire comportamenti sconsiderati e/o eccessiva distrazione, ma visto che sono cose che possono accadere, perché non pensarci prima? si chiama cambio automatico http://forums.nsn3.net/style_emoticons/default/55.gif
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente. concordo, anche perché molti utenti hanno idee diametralmente opposte ed in aperto contrasto, quindi qualcuno va scontentato per forza. però mi sfugge come mai si sta parlando di "programmatori di Windows": non si parlava di quelli che hanno creato il VBA, ovvero i programmatori di Office che hanno integrato Visual Basic nella suite?
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo. bingo!! è questo il punto, concordo. http://forums.nsn3.net/style_emoticons/default/55.gif
la message box che chiede conferma dell'eliminazione di un file c'è, fa parte dell'interfaccia grafica di Windows e usa persino una tecnica anti training effect: mette il tasto "No" come default. chi ha progettato le API per il VBA però ha pensato che quella in particolare doveva agire ad un livello più basso e che, in caso, sarebbe stato compito della macro chiedere prima di cancellare. l'importante è che l'autore di questo congegno abbia specificato chiaramente questa cosa nell'apposita documentazione: se l'ha fatto (e molto probabilmente è così, anche se non ce l'ho sottomano) e tu ti aspettavi un risultato diverso da quello descritto allora chi ha sbagliato sei tu.
[...] e usa persino una tecnica anti training effect: mette il tasto "No" come default. AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!! :D
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows? Vediamo di fare altrettanto:
E' una logica che, anche se ti lamenti, continua a sfuggirti, per cui non ti seccare se saremo costretti a ripeterti per
l'n-esima volta gli stessi concetti.
E a te continua a sfuggire che non mi sto affatto lamentando, ma sto solo cercando di analizzare un aspetto di un software che a mio parere ha qualche lacuna.
Se un file è protetto dalla lettura, è NORMALISSIMO che il s.o. si rifiuti di sovrascriverlo: QUESTO controllo è UN SUO COMPITO.
Fa, quindi, parte del "contratto" stabilito fra il s.o. e le applicazioni che ci girano. Se io dico APPOSITAMENTE al s.o. che un file è protetto
dalla lettura, lui deve GARANTIRMI che non venga sovrascritto.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
L'hanno fatto: si chiamano PERMESSI. Se non volevi che il tuo file fosse sovrascritto, avresti dovuto marcarlo in sola lettura: vedrai che
l'API che hai invocato sarebbe fallita e il file non sarebbe stato toccato.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto e poi, hai mai provato a lavorare con un database in sola lettura? Guarda cosa fanno le tue API!
http://img227.imageshack.us/img227/852/snap1up4.png (http://img227.imageshack.us/my.php?image=snap1up4.png)
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda e comunque non mi aspetto di certo che venga ascoltata, ne mi strapperò i capelli se nessuna modifica verrà mai apportata in tal senso.
Infatti esistono una serie di comportamenti "di fabbrica": sono quelli di cui ho parlato prima, appunto.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no?
Non ce l'hai chiaro, ed evidente da quello che scrivi.
Come fai a dire che non ce l'ho chiaro, me l'hai forse visto?!? Ti garantisco che è sul rosa-pallido e probabilmente se fosse scuro, sarebbe anche meglio. Non so se mi spiego!
Scusa la battutaccia, ma credo proprio di non trovare altri argomenti per controbattere questa tua particolare affermazione!
Sì, decisamente. Un s.o. non può fare tutto ciò che passa per la testa di un utente.
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo.
Già m'immagino un s.o. che a ogni tentativo di scrittura di un file mi rompe le palle avvisandomi: per usarlo un'altra vita non mi basterebbe con
tutto il tempo che questo richiederebbe.
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente e poi, se un programmatore volesse avviare un comando che distrugga tutti i file in un disco, non credo avrebbe problemi a farlo, aggirando le protezioni.
Una piccola citazione se l'è meritata anche 71104:
AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!!
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io?
Con la risposta al mio esempio automoblistico poi, non hai fatto altro che confermare la mia tesi, infatti il cambio automatico è un'evoluzione di quello manuale e pertanto i suoi inventori hanno pensato bene di aggiungere una funzione in più rispetto a quest'ultimo, eliminando in maniera decisa il rischio che potrebbe derivare da una distrazione dell'utente. Ciò rappresenta di certo una complicazione, infatti molte persone che non l'hanno mai usato, non riescono nemmeno a mettere in moto, perché se non sbaglio, c'è da premere il pedale del freno, ma con un minimo d'esperienza, ci si riesce benissimo.
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows? Vediamo di fare altrettanto:
E' una logica che, anche se ti lamenti, continua a sfuggirti, per cui non ti seccare se saremo costretti a ripeterti per
l'n-esima volta gli stessi concetti.
E a te continua a sfuggire che non mi sto affatto lamentando, ma sto solo cercando di analizzare un aspetto di un software che a mio parere ha qualche lacuna.
Se un file è protetto dalla lettura, è NORMALISSIMO che il s.o. si rifiuti di sovrascriverlo: QUESTO controllo è UN SUO COMPITO.
Fa, quindi, parte del "contratto" stabilito fra il s.o. e le applicazioni che ci girano. Se io dico APPOSITAMENTE al s.o. che un file è protetto
dalla lettura, lui deve GARANTIRMI che non venga sovrascritto.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
L'hanno fatto: si chiamano PERMESSI. Se non volevi che il tuo file fosse sovrascritto, avresti dovuto marcarlo in sola lettura: vedrai che
l'API che hai invocato sarebbe fallita e il file non sarebbe stato toccato.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto e poi, hai mai provato a lavorare con un database in sola lettura? Guarda cosa fanno le tue API!
http://img227.imageshack.us/img227/852/snap1up4.png (http://img227.imageshack.us/my.php?image=snap1up4.png)
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda e comunque non mi aspetto di certo che venga ascoltata, ne mi strapperò i capelli se nessuna modifica verrà mai apportata in tal senso.
Infatti esistono una serie di comportamenti "di fabbrica": sono quelli di cui ho parlato prima, appunto.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no?
Non ce l'hai chiaro, ed evidente da quello che scrivi.
Come fai a dire che non ce l'ho chiaro, me l'hai forse visto?!? Ti garantisco che è sul rosa-pallido e probabilmente se fosse scuro, sarebbe anche meglio. Non so se mi spiego!
Scusa la battutaccia, ma credo proprio di non trovare altri argomenti per controbattere questa tua particolare affermazione!
Sì, decisamente. Un s.o. non può fare tutto ciò che passa per la testa di un utente.
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo.
Già m'immagino un s.o. che a ogni tentativo di scrittura di un file mi rompe le palle avvisandomi: per usarlo un'altra vita non mi basterebbe con
tutto il tempo che questo richiederebbe.
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente e poi, se un programmatore volesse avviare un comando che distrugga tutti i file in un disco, non credo avrebbe problemi a farlo, aggirando le protezioni.
Una piccola citazione se l'è meritata anche 71104:
AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!!
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io?
Con la risposta al mio esempio automoblistico poi, non hai fatto altro che confermare la mia tesi, infatti il cambio automatico è un'evoluzione di quello manuale e pertanto i suoi inventori hanno pensato bene di aggiungere una funzione in più rispetto a quest'ultimo, eliminando in maniera decisa il rischio che potrebbe derivare da una distrazione dell'utente. Ciò rappresenta di certo una complicazione, infatti molte persone che non l'hanno mai usato, non riescono nemmeno a mettere in moto, perché se non sbaglio, c'è da premere il pedale del freno, ma con un minimo d'esperienza, ci si riesce benissimo.
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows? Vediamo di fare altrettanto:
E' una logica che, anche se ti lamenti, continua a sfuggirti, per cui non ti seccare se saremo costretti a ripeterti per
l'n-esima volta gli stessi concetti.
E a te continua a sfuggire che non mi sto affatto lamentando, ma sto solo cercando di analizzare un aspetto di un software che a mio parere ha qualche lacuna.
Se un file è protetto dalla lettura, è NORMALISSIMO che il s.o. si rifiuti di sovrascriverlo: QUESTO controllo è UN SUO COMPITO.
Fa, quindi, parte del "contratto" stabilito fra il s.o. e le applicazioni che ci girano. Se io dico APPOSITAMENTE al s.o. che un file è protetto
dalla lettura, lui deve GARANTIRMI che non venga sovrascritto.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
L'hanno fatto: si chiamano PERMESSI. Se non volevi che il tuo file fosse sovrascritto, avresti dovuto marcarlo in sola lettura: vedrai che
l'API che hai invocato sarebbe fallita e il file non sarebbe stato toccato.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto e poi, hai mai provato a lavorare con un database in sola lettura? Guarda cosa fanno le tue API!
http://img227.imageshack.us/img227/852/snap1up4.png (http://img227.imageshack.us/my.php?image=snap1up4.png)
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda e comunque non mi aspetto di certo che venga ascoltata, ne mi strapperò i capelli se nessuna modifica verrà mai apportata in tal senso.
Infatti esistono una serie di comportamenti "di fabbrica": sono quelli di cui ho parlato prima, appunto.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no?
Non ce l'hai chiaro, ed evidente da quello che scrivi.
Come fai a dire che non ce l'ho chiaro, me l'hai forse visto?!? Ti garantisco che è sul rosa-pallido e probabilmente se fosse scuro, sarebbe anche meglio. Non so se mi spiego!
Scusa la battutaccia, ma credo proprio di non trovare altri argomenti per controbattere questa tua particolare affermazione!
Sì, decisamente. Un s.o. non può fare tutto ciò che passa per la testa di un utente.
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo.
Già m'immagino un s.o. che a ogni tentativo di scrittura di un file mi rompe le palle avvisandomi: per usarlo un'altra vita non mi basterebbe con
tutto il tempo che questo richiederebbe.
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente e poi, se un programmatore volesse avviare un comando che distrugga tutti i file in un disco, non credo avrebbe problemi a farlo, aggirando le protezioni.
Una piccola citazione se l'è meritata anche 71104:
AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!!
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io?
Con la risposta al mio esempio automoblistico poi, non hai fatto altro che confermare la mia tesi, infatti il cambio automatico è un'evoluzione di quello manuale e pertanto i suoi inventori hanno pensato bene di aggiungere una funzione in più rispetto a quest'ultimo, eliminando in maniera decisa il rischio che potrebbe derivare da una distrazione dell'utente. Ciò rappresenta di certo una complicazione, infatti molte persone che non l'hanno mai usato, non riescono nemmeno a mettere in moto, perché se non sbaglio, c'è da premere il pedale del freno, ma con un minimo d'esperienza, ci si riesce benissimo.
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows? Vediamo di fare altrettanto:
E' una logica che, anche se ti lamenti, continua a sfuggirti, per cui non ti seccare se saremo costretti a ripeterti per
l'n-esima volta gli stessi concetti.
E a te continua a sfuggire che non mi sto affatto lamentando, ma sto solo cercando di analizzare un aspetto di un software che a mio parere ha qualche lacuna.
Se un file è protetto dalla lettura, è NORMALISSIMO che il s.o. si rifiuti di sovrascriverlo: QUESTO controllo è UN SUO COMPITO.
Fa, quindi, parte del "contratto" stabilito fra il s.o. e le applicazioni che ci girano. Se io dico APPOSITAMENTE al s.o. che un file è protetto
dalla lettura, lui deve GARANTIRMI che non venga sovrascritto.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
L'hanno fatto: si chiamano PERMESSI. Se non volevi che il tuo file fosse sovrascritto, avresti dovuto marcarlo in sola lettura: vedrai che
l'API che hai invocato sarebbe fallita e il file non sarebbe stato toccato.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto e poi, hai mai provato a lavorare con un database in sola lettura? Guarda cosa fanno le tue API!
http://img227.imageshack.us/img227/852/snap1up4.png (http://img227.imageshack.us/my.php?image=snap1up4.png)
Di certo i programmatori di Windows non possono mettersi nella testa di quello che pensa OGNI utente.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda e comunque non mi aspetto di certo che venga ascoltata, ne mi strapperò i capelli se nessuna modifica verrà mai apportata in tal senso.
Infatti esistono una serie di comportamenti "di fabbrica": sono quelli di cui ho parlato prima, appunto.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no?
Non ce l'hai chiaro, ed evidente da quello che scrivi.
Come fai a dire che non ce l'ho chiaro, me l'hai forse visto?!? Ti garantisco che è sul rosa-pallido e probabilmente se fosse scuro, sarebbe anche meglio. Non so se mi spiego!
Scusa la battutaccia, ma credo proprio di non trovare altri argomenti per controbattere questa tua particolare affermazione!
Sì, decisamente. Un s.o. non può fare tutto ciò che passa per la testa di un utente.
Inoltre fra s.o. e applicazione esistono dei precisi vincoli, e tu stai chiedendo al primo di svolgere parte delle mansioni del secondo.
Già m'immagino un s.o. che a ogni tentativo di scrittura di un file mi rompe le palle avvisandomi: per usarlo un'altra vita non mi basterebbe con
tutto il tempo che questo richiederebbe.
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente e poi, se un programmatore volesse avviare un comando che distrugga tutti i file in un disco, non credo avrebbe problemi a farlo, aggirando le protezioni.
Una piccola citazione se l'è meritata anche 71104:
AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!!
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io?
Con la risposta al mio esempio automoblistico poi, non hai fatto altro che confermare la mia tesi, infatti il cambio automatico è un'evoluzione di quello manuale e pertanto i suoi inventori hanno pensato bene di aggiungere una funzione in più rispetto a quest'ultimo, eliminando in maniera decisa il rischio che potrebbe derivare da una distrazione dell'utente. Ciò rappresenta di certo una complicazione, infatti molte persone che non l'hanno mai usato, non riescono nemmeno a mettere in moto, perché se non sbaglio, c'è da premere il pedale del freno, ma con un minimo d'esperienza, ci si riesce benissimo.
cdimauro
02-10-2007, 07:33
AAAAAARGH!! ho provato ora a cancellare un file (definitivamente con Shift+Del, non cestinandolo): mi ha messo "Yes" come tasto di default!!! :D
ecco, sapete che vi dico? questo è un vero e proprio (seppur minore) difetto di Windows.
Mica è detto: l'impostazione di default per i tasti riguarda la conferma dell'AZIONE che si è scelto di svolgere. A me sembra la scelta più intuitiva. ;)
cdimauro
02-10-2007, 08:01
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows?
Le tue illazioni lasciale fuori dalla discussione, cortesemente: sono un professionista e non mi faccio influenzare da niente quando esprimo dei giudizi di carattere tecnico.
Vediamo di fare altrettanto:
E a te continua a sfuggire che non mi sto affatto lamentando, ma sto solo cercando di analizzare un aspetto di un software che a mio parere ha qualche lacuna.
Ti è già stato spiegato, e non soltanto da me, che quello di cui ti lamenti è un problema attinente al software e NON al s.o..
In questo caso è il TUO software che non si comporta come tu vorresti, per cui è necessario che sia tu stesso ad apportare le modifiche necessarie allo scopo.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
Dove sta scritto? Fammi vedere in quale parte della documentazione delle API di Windows è riportato che il s.o. ha il compito di chiedere conferma nei casi che hai citato.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto
Se il file NON è protetto, mi sembra a dir poco ovvio che le API non protestino nel caso in cui accedi a un file per sovrascriverlo o cancellarlo.
e poi, hai mai provato a lavorare con un database in sola lettura?
Sì, e funziona benissimo per quello che ci si può fare.
Guarda cosa fanno le tue API!
http://img227.imageshack.us/img227/852/snap1up4.png (http://img227.imageshack.us/my.php?image=snap1up4.png)
Mi sembra normale: VBA ha visto che il file è a sola lettura e non potendo scriverci ti ha avvisato.
Un splendido esempio di APPLICAZIONE che esegue dei controlli e avvisa l'utente. Già, perché non è certo il s.o. che ti sta avvisando.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda e comunque non mi aspetto di certo che venga ascoltata, ne mi strapperò i capelli se nessuna modifica verrà mai apportata in tal senso.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no?
No, perché, e te lo ripeto nuovamente, NON è compito del s.o. ma dell'applicazione effettuare i controlli di cui parli e addirittura visualizzare un messaggio di conferma: questo è TUTTO a carico dell'applicazione.
Di quello che chiedi POTREBBE anche farsene carico il s.o., ma a questo punto da sistema operativo diventerebbe sistema INoperativo, perché sarebbe praticamente impossibile lavorarci, visto che le operazioni di (ri)scrittura sono frequentissime, e l'utente NON può mettersi a chiedere conferma OGNI VOLTA.
Come fai a dire che non ce l'ho chiaro, me l'hai forse visto?!? Ti garantisco che è sul rosa-pallido e probabilmente se fosse scuro, sarebbe anche meglio. Non so se mi spiego!
Scusa la battutaccia, ma credo proprio di non trovare altri argomenti per controbattere questa tua particolare affermazione!
Non ti preoccupare: non avendo altri argomenti è facile scadere su battute inutili come questa.
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente
Che, come dicevo prima, è un'operazione MOOOOLTO frequente. Il sistema diventerebbe INGESTIBILE. Tanto varrebbe tornare all'abaco, che non fa di questi scherzi.
e poi, se un programmatore volesse avviare un comando che distrugga tutti i file in un disco, non credo avrebbe problemi a farlo, aggirando le protezioni.
Appunto: e chi è il s.o. per impedire di eseguire ciò che l'utente ha ordinato? Nessuno: deve eseguire e basta.
Esattamente come quando TU gli hai chiesto cortesemente di sovrascrivere il tuo file.
Una piccola citazione se l'è meritata anche 71104:
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io?
Perché quei controlli non sono a carico del s.o., come ti ho già ripetuto n volte.
Esistono dei PRECISI meccanismi per cui scattano dei controlli da parte del s.o., e quello che tu chiedi NON è fra questi, perché NON E' ASSOLUTAMENTE DESIDERABILE CHE VENGANO EFFETTUATI. Altrimenti il sistema diventerebbe inusabile, appunto.
I controlli che non fa il s.o., e di cui TUTTI I PROGRAMMATORI DOVREBBERO ESSERE A CONOSCENZA QUANDO LAVORANO CON QUESTE COSE, sono a carico dell'applicazione.
Tu non hai studiato come funziona il s.o. e come si comportano le sue API, per cui non sei titolato a lamentarti di alcunché, visto che le hai usate in maniera errata. I tuoi errori è bene che impari a piangerteli da solo senza addossare la colpa agli altri.
Con la risposta al mio esempio automoblistico poi, non hai fatto altro che confermare la mia tesi, infatti il cambio automatico è un'evoluzione di quello manuale e pertanto i suoi inventori hanno pensato bene di aggiungere una funzione in più rispetto a quest'ultimo, eliminando in maniera decisa il rischio che potrebbe derivare da una distrazione dell'utente. Ciò rappresenta di certo una complicazione, infatti molte persone che non l'hanno mai usato, non riescono nemmeno a mettere in moto, perché se non sbaglio, c'è da premere il pedale del freno, ma con un minimo d'esperienza, ci si riesce benissimo.
Il cambio automatico non è stato AGGIUNTO a quello manuale: sono mutuamente esclusivi. O hai l'uno o hai l'altro.
Se compri una macchina con cambio manuale, può succedere ciò che hai riportato prima, ma E' INUTILE CHE TE NE LAMENTI perché funziona così. Altrimenti avresti potuto comprarne una con quello automatico, no?
Le scelte sono a carico dell'utente, non di chi progetta le macchine (che fanno quello che possono, limitatamente alla tecnologia a disposizione, per rendere la vita più facile agli automobilisti).
cdimauro
02-10-2007, 08:33
Sbaglio o non si vedono gli altri messaggi? :confused:
cdimauro
02-10-2007, 08:33
Ci riprovo. :D
cdimauro
02-10-2007, 08:33
Finalmente!!! :)
Ma che diavolo aveva il server?!? Mah.
EDIT: sbaglio o questo comportamento capita quando sono stati cancellati dei messaggi? Qui sembra ne manchino 3 all'appello, che fanno sballare la visualizzazione. Eventualmente sarebbe meglio non cancellarli, ma visualizzarli ugualmente, ma col contenuto cancellato.
trallallero
02-10-2007, 08:42
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto.
su s.o. Unix like puoi rimuovere per sbaglio tutta la directory / ;)
se vuoi essere avvisato sei tu che devi aggiungere -i al comando rm.
Azz!!! Scusatemi, ho quadruplicato il mio ultimo post, ma purtroppo l'ho inviato in un orario in cui il forum era in manutenzione ed il browser non mi dava mai la conferma di spedizione, pertanto ho provato più volte pensando che il messaggio non fosse stato recapitato. Non prendetelo come un tentativo di rimarcare in maniera ossessiva le mie convinzioni, anche se per qualcuno, forse, ce ne sarebbe bisogno!
Toranando alla nostra discussione, per quanto mi riguarda la chiudo qui, perché non posso continuare a parlare con chi non vuole ascoltare e insiste, lui si, a fare illazioni sulle mie presunte lamentele che ho più e più volte confermato non essere tali.
Ciao a tutti e scusatemi ancora, non tanto per i 4 post fotocopia, ma per la mia ignoranza in programmazione che tanto vi ha infastidito. Lo prometto, in futuro, prima di fare alcune richieste o delle semplici constatazioni in materia, studierò a fondo il codice del sistema operativo, le API e quant'altro servisse allo scopo, così magari, non dovrò nemmeno interpellarvi.
cdimauro
02-10-2007, 09:14
Ottimo, ma il sorgente di Windows ce l'hanno soltanto alla MS e a un programmatore è sufficiente conoscere le API e quello che fanno per poter lavorare.
P.S. Comunque non mi sono affatto lamentato della tua quadruplice risposta. Inoltre la tua incapacità o non volontà di prendere atto dell'errore che hai commesso e del funzionamento di un s.o. e di un'applicazione traspare fin dal primo messaggio che hai scritto.
Non c'è bisogno di condire il tuo messaggio con delle battutine che lasciano il tempo che trovano: non stai parlando con dei beoti che non si accorgono del malcelato sarcasmo con cui hai farcito il tuo nuovamente inutile post.
vorrei spezzare una fiocina nei confronti del VBA con un esempio
un venerdì sera sono arrivato a casa ubriaco fradicio alle 5 di mattina, mi sono messo davanti al mio serverino linux che stava beato facendosi gli affari suoi, ignaro di quello che stava per succedere...
guardo un po' i file della directory /var/log premendo i tasti in maniera pesante e goffa....apro un'altra shell e digito "su" ..."password_del_mio_utente_root"...e mi ritrovo sulla root "/", digito un paio di comandi da root per guardare delle cose...
...vado in cucina a bere un bicchiere d'aqua, pesantemente riporto le mie chiappe davanti al server, e mi chiedo "perchè non cancellare tutti sti file di log che ormai sono diventati grandissimi e numerosi?"
"OK"--------> lancio un bel
rm -R *
...sento il disco fisso che inizia a smacchinare a manetta...aspetto un po'...una goccia di sudore mi cade dalla fronte...ho una sensazione sinistra....la sensazione si fa sempre più forte....con una faccia degna di Homer Simpson vedo che la shell da cui ho lanciato il comando non era quella che si trovava in "/var/log/" bensì quella di root che era in "/"....
fermo la cancellazione, digito "ls"-----> "command not found" :cry: :cry:
....ho fatto un casino immane...
MORALE DELLA STORIA: nemmeno il comando "rm -R *" mi ha chiesto conferma di quello che stavo fancendo, in quanto non è prevista la protezione contro i FAGIANI in linux :fagiano: :fagiano:
ero io che mi dovevo preoccupare di quello che stavo facendo
SECONDA MORALE DELLA STORIA: mai fare ste cose da ubriachi....:mbe:
Cdmauro, la tua dedizione nel ribattere punto su punto è quantomeno encomiabile, sarai mica un programmatore di Windows? no, ma è un troll molto più esperto di te.
E' un suo compito chiedere conferma anche prima di cancellare o riscrivere file non protetti, per cui nel mio caso non rispetta il contratto. è compito della shell, non del kernel, altrimenti apparirebbero message boxes pure quando un'applicazione cancella i suoi files di sistema temporanei, e l'esecuzione di quel thread dell'applicazione sarebbe dunque bloccata fino all'intervento dell'utente. quella API di VBA evidentemente non si interfaccia alla shell, ma al kernel.
ripeto che l'unica cosa che conta è che sia tutto documentato: se un programmatore crea un software che si comporta in un certo modo non frega niente a nessuno che solo a te non piace come si comporta: quello di cui a tutti frega è che il programmatore abbia scritto chiaramente da qualche parte che quel programma si comporta così.
Non l'hanno fatto per nulla, altrimenti le famose API avrebbero dovuto ronzare anche se il file non era protetto eh? che? cioè io cancello un file non protetto da scrittura e allora mi deve apparire una message box perché altrimenti Windows è vulnerabile? o cosa? :wtf:
e poi, hai mai provato a lavorare con un database in sola lettura? Guarda cosa fanno le tue API! lui si è espresso in maniera sintetica ed imprecisa, ma era chiaro che non intendesse negare l'accesso in scrittura al (o ai) file(s) del database, bensì la cancellazione. c'è da dire che anche così non viene negata la possibilità di troncamento, quindi non è una soluzione completa.
E ci mancherebbe altro, non è mia abitudine pretendere l'impossibile, d'altra parte non credo che la mia richiesta sia così assurda perché non programmi ed è evidente: tu proponi di porre a livello di UI (User Interface) qualcosa che non lo è.
A questa serie di comportamenti di fabbrica, poteva tranquillamente essere aggiunto quello da me auspicato. O no? no: ce lo devi aggiungere tu. supponi che una macro debba gestire 10 database differenti e che debba usare quell'API fino a 10 volte: l'utente che fa, risponde a 10 messaggi identici? l'API da te citata all'inizio del topic non ha nulla a che vedere con l'UI; l'UI la devi realizzare tu, punto e basta.
Scusa la battutaccia, ma no dai, che hai un futuro nel Bagaglino :asd:
almeno in mezzo a quei comici falliti il tuo coso rosa pallido susciterebbe qualche minima ilarità :asd:
Non credo che il S.O. dovrebbe avvisarti ad ogni tentativo di scrittura file, ma solo nel caso si tenti di sovrascriverne uno esistente l'avanzato sistema di sicurezza di Windows permette di impostare differentemente i permessi di scrittura e di append di un file.
Una piccola citazione se l'è meritata anche 71104: PIETA'!! :ave:
Se secondo te questo è un difetto o almeno una mancanza, allora perché non lo è anche quella che ho descritto io? o no, mi hai fregato genio tattico :asd:
quale sarebbe "quella che hai descritto tu"? prima di rispondermi controlla che non sia un comportamento documentato, perché se lo è tanto mi basta per non considerarlo un difetto.
Mica è detto: l'impostazione di default per i tasti riguarda la conferma dell'AZIONE che si è scelto di svolgere. A me sembra la scelta più intuitiva. ;) preferirei se il tasto predefinito fosse il "No": può sempre capitare di premere Shift+Del su un file e di avere dopo un ripensamento :fagiano:
trallallero
02-10-2007, 11:17
...
nel .bashrc:
alias rm='rm -i'
;)
EDIT: o meglio
rm()
{
test sbronzo && echo "vai a dormire che e´ meglio" || rm $*
}
:D
nel .bashrc:
alias rm='rm -i'
;)
EDIT: o meglio
rm()
{
test sbronzo && echo "vai a dormire che e´ meglio" || rm $*
}
:D
meglio ancora
alias rm ='shutdown -h now'
:)
@akyra
ti ha chiesto addirittura una password.. cosa vuoi di più? :fagiano:
cdimauro
02-10-2007, 19:22
no, ma è un troll molto più esperto di te.
Ehi, tu, un po' di rispetto! :nera: E poi perché sarei un troll? :mbe:
preferirei se il tasto predefinito fosse il "No": può sempre capitare di premere Shift+Del su un file e di avere dopo un ripensamento :fagiano:
A questo punto dipende dai casi: per Shift + Del tu trovi più sensato che sia impostato su "No", ma "Yes" per operazioni "non distruttive" (le classiche conferme per operazioni comuni e ripetitive) è la soluzione migliore.
Qui, però, non può essere il s.o. a scegliere la soluzione di default: servirebbe un hint dall'applicazione.
Ehi, tu, un po' di rispetto! :nera: E poi perché sarei un troll? :mbe: :Prrr: non era assolutamente da prendere come un insulto. ormai io stesso, anche su questo forum, ho "trollato" tante di quelle volte che per me quella parola ha perso l'accezione negativa :D
_Claudio
02-10-2007, 22:59
l'unico problema del VB è che permette ai neofiti di programmare :asd:
quoto...
Assolutamente no: è compito dell'APPLICAZIONE, non del s.o..
Secondo me sarebbe buono che fosse compito di Office avvisare se una macro esegue un'istruzione così "pericolosa", visto che microsoft è la prima a farci una testa tanta sul problema della sicurezza...
È compito dell'ingegneria del software o del semplice buon senso sviluppare applicazioni non catastrofiche, ma siccome le macro le usano anche i neofiti che credono che l'ingegneria del sw si mangi... sarebbe buono abbassare di un livello certi controlli.
cdimauro
03-10-2007, 07:24
quoto...
Io no, perché da quando le semplici macro sono state sostituite da linguaggi ad hoc, è stato fatto un enorme passo in avanti.
E si è anche dato la possibilità a tanta gente di cominciare a programmare (con tutti i limiti del caso).
Secondo me sarebbe buono che fosse compito di Office avvisare se una macro esegue un'istruzione così "pericolosa", visto che microsoft è la prima a farci una testa tanta sul problema della sicurezza...
È compito dell'ingegneria del software o del semplice buon senso sviluppare applicazioni non catastrofiche, ma siccome le macro le usano anche i neofiti che credono che l'ingegneria del sw si mangi... sarebbe buono abbassare di un livello certi controlli.
Office è un'applicazione come un'altra.
Comunque mi trovi sostanzialmente d'accordo, ma avevo già scritto che non è una cosa semplice perché richiede non poco tempo.
x Alberto: non c'è problema. :)
È nerd!! :eek: tu non scrivi E maiuscola e apostrofo, tu fai Alt+0200 :D
È compito dell'ingegneria del software o del semplice buon senso sviluppare applicazioni non catastrofiche, ma siccome le macro le usano anche i neofiti che credono che l'ingegneria del sw si mangi... almeno non le attribuiscono un significato errato
_Claudio
04-10-2007, 09:24
nerd!! :eek: tu non scrivi E maiuscola e apostrofo, tu fai Alt+0200 :D
Certo, bisogna essere precisi, mica si può scrivere gli accenti al posto degli apostrofi...:read: :read: :D :D
almeno non le attribuiscono un significato errato
Non è questione di significato errato o meno, è (non e') questione di non dare la possibilità ai troglammatori di fare danni catastrofici.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.