Bug nel JavaScript di Firefox: dati sensibili a rischio

[cdimauro]

Originariamente inviato da Leron

sperando che non richiudano il sito

www.igpozzo.it/altro/brushedleron.zip

c'è sia uxtheme che il tema di win che quello di firefox e pure adblock col bottone personalizzato "a tema"

Una figata! Poi il thema di Pather con lo stile iTunes è semplicemente favoloso!!!

Consiglio anche ad altri di provarlo, perché ne vale veramente la pena... .)

Grazie tante!!!

[Leron]

mi fa piacere che ti piaccia

sto lavorandoci su, voglio migliorarlo un poco soprattutto nei caricamenti delle pagine di firefox

[cdimauro]

Originariamente inviato da Breakthru

Ovviamente non c'entra + nulla con firefox, ma spero sia interessante la discussione (che e' anche nel forum)

Capita spesso ormai, ma l'importante è non scadere nei flame e che la nuova discussione sia interessante...

l'esempio di una utilitaria truccata da ferrari mi è venuto in mente pensando a
- schermate blu improvvise
- blocchi del sistema frequentissimi
- sempre più pesantezza col passare del tempo

questo si applica a win98SE,

L'ho usato per parecchio tempo: mai avuto i problemi di cui parli. Qualche schermata blu m'è capitata, ma molto raramente (poi io lo trattavo veramente il sistema, facendo esperimenti con gli hook di sistema).

non uso winXp, e se pure winXp fosse meglio (so che è un kernel totalmente diverso) è intollerabile aver dovuto aspettare tanto per avere qualcosa di meglio.

Beh, sono passati 4 anni e 5 da Windows 2000 (che era già molto, ma molto meglio di Win98SE): dimmi tu se ALL'EPOCA di Windows 98 (o delle precedenti versioni) ci fossero delle soluzioni alternative ALMENO usabili e produttive.

io penso che se un software viene scritto avendo in mente che deve essere sicuro, non esce fuori con gli n (non so il numero) bug critici che ha IE.

Questo lo dici perché non hai idea cosa significa realizzare del software in generale, e cosa significhi sicurezza. Scrivere del codice "intrinsecamente sicuro" non è cosa facile, anche perché manca una definizione di codice "sicuro".

hai potuto dare un'occhiata ai bug ?

Sì, ma solamente a qualcuno.

al codice?

No, non lavoro alla MS né ho potuto dare un'occhiata proprio ai sorgenti di IE che girano in rete, appartenenti a Windows 2000.
Ho però visto un sorgente di questo "pacchetto", debbo dire che il codice era scritto MOLTO BENE: perfino le macro, che in genere sono particolarmente criptiche, erano molto leggibili e ben documentate / commentate (come tutto il resto del codice).

(qui correggimi che posso facilmente sbagliare: il buffer overflow avviene a causa di mancati contorlli: ti aspetti che ci sia una certa struttura dati in memoria, e invece ce n'era un'altra con risultati imprevisti.)

se ho detto una minchiata non ci sono problemi, il punto è questo: uno stile di programmazione pulito serve proprio a ridurre i bug, quindi molti bug => cattivo stile.

Questo succede per qualunque software, come ho già detto e t'hanno spiegato. Se poi vai a dare un'occhiata anche ai bug che sono stati trovati per Mozilla, FireFox & co., ti accorgi che non sono affatto esenti da falle di sicurezza molto "gravi", che permettono di eseguire codice arbitrario.

riguardo activeX...

ma scusa, ho una domanda su activeX:
è possibile (senza sfruttare bug) installare un programma senza che l'utente lo viene a sapere?
(solo una finestrella con un bottone "ok" e un testo a scelta mia => non lo viene a sapere.)

Certo che è possibile farlo: non è certo colpa degli ActiveX, che sono delle "semplici" collezioni di componenti, ma dell'applicazione che li usa.

se è possibile, un'altro motivo per non fidarsi e non usare mai più software microsoft.

Vedi sopra: non è certo colpa loro. Tra l'altro col SP2 IE chiede il permesso prima, ma è IE a farlo, non gli ActiveX...

se non è possibile, sembra che sfruttare activeX per farlo sia "triviale": scarsa qualità di activeX?

No. E infatti vedi sopra: FireFox & co. non usano gli ActiveX, ma sono state ugualmente trovate delle gravi falli di sicurezza.

se solo un bravo hacker può sfruttare activeX come mai tanti dialer? tutti bravi hacker? no!

Sì, gravi hacker, che puntano sul software più diffuso.

è stupido bloccare i propri dati in un formato proprietario.
i formati liberi esistono, sono migliori, e ci permettono di essere pronti ad ogni utilizzo futuro che vorremo fare senza restrizioni imposte da UN ALTRO.
è sempre sbagliato.
i truffatori esistono, le aziende scorrette esistono, i negozianti imbroglioni esistono, i formati proprietari esistono, le cose brutte esistono, ma di norma vogliamo evitarle.

Hai un'idea errata sui formati proprietari: come t'ho già detto, sono SEMPRE ESISTITI. In qualche modo le informazioni si devono salvare, no?

Quando agli inizi degli anni '80 spuntò WordStar, che permetteva di scrivere file di testo strutturati, la società che lo sviluppava introdusse un SUO formato (proprietario, quindi), che permettava di conservare le informazioni che gli servivano. Avremmo dovuto trucidare i programmatori per quest'affronto alla libertà personale? Non credo proprio: era un normale esigenza, risolta come s'è sempre fatto.

MS, come ho già detto, è l'ultima arrivata, e ha rilasciato da parecchi anni le specifiche dei file prodotti con Office '97: con le versioni successive non ha fatto lo stesso, ma in ogni caso puoi:
- farne a meno e usare quelli vecchi;
- in qualsiasi momento puoi esportare i tuoi dati in parecchi formati.
Quindi, come vedi, il problema non si pone.

Tra l'altro erroneamente la gente considera come "liberi" formati come MP3, MPEG 1/2/4, ecc.: non è affatto vero! Diritti e licenze sono FORTEMENTE in mano alle varie società che li hanno sviluppati / ideati, o che ne hanno realizzato alcune parti.

Anche qui ci sarebbe da discutere: perché usare MP3 anziché OGG Vorbis? Semplicemente perché all'epoca non c'era nulla di simile, OV non esisteva. MP3, quindi, s'è diffuso, e la gente è convinta che si tratti di un prodotto "libero".
Per verificare questo, prova a vedere se con xmms, noatun, kaboodle, o altre applicazioni Linux, riesci ad ascoltare un file MP3: non ci riuscirai, e come minimo ti apparirà un avvertimento che si tratta di un formato proprietario e per problemi di licenza non hanno potuto integrare il relativo codec o plugin.

per i motivi che abbiamo discusso non mi piace microsoft, non utilizzo i suoi software, e invito gli altri a non farlo.

Non sono motivi sufficienti, a mio avviso: sei troppo prevenuto nei suoi confronti. MS è e si comporta come tante altre software house. Tutto il mondo è paese, come si suol dire...

p.s. spero sei daccordo con me che il monopolio (su qualsiasi bene o servizio) fa SEMPRE danno al CLIENTE! il consumatore deve SEMPRE boicottare il monopolio perchè deve tutelare SE STESSO.

Se il monopolio esiste, magari si potrebbe anche pensare di farlo. Ma mi fai vedere com'è possibile fare a meno dell'ENEL e della corrente elettrica?

p.p.s. io ho letto su www.gnu.org l'articolo sulla filosofia che il software non deve avere padroni, lo condivido appieno e vi invito a leggerlo all'indirizzo
http://www.gnu.org/philosophy/why-free.it.html

Mi spiace, ma m'è bastata già l'introduzione di "Codice Libero": ci tengo alla salute (mi si ritorce il fegato quando leggo alcune cose: per questo mi sono fermato all'introduzione di quel libro), e soprattutto debbo pensare a far campare la mia famiglia col mio lavoro di programmatore...

[cdimauro]

Originariamente inviato da xeal

Comunque i sistemi attuali non poggiano sul DOS e non mi sembrano da buttar via;

Fino a Windows 3.1 lo erano: poi no. IMHO, chiaramente.

Comunque, AI TEMPI, anche Windows 3.1 non era da buttar via...

[cdimauro]

Originariamente inviato da edivad82

io penso che con l'andare avanti con il programmare bene o male lo possono far tutti, fare codice sicuro no...servono approcci mentali, rigorosità e molto altro...cosa che tutti i programmatori dovrebbero avere e non solo alcuni...secondo me abbiamo passato la fase dell'ottimizzazione del codice, ora dobbiamo seriamente passare alla sicurezza del codice, sia a causa della maggior completezza dei linguaggi sia per ragioni proprie di bug ecc...

Il problema: è possibile definire cosa sia il codice sicuro?

basta guardare l'approccio di Bernstein, informatevi su Qmail o su djbdns... quello è un approccio verso le prestazioni e verso soprattutto la sicurezza del codice...qmail è sostanzialmente lo stesso dal 1998

e in questo periodo non ci sono stati richiami vari...un esempio di codice scritto con la sicurezza come meta finale

Il codice si evolve: anzi, è normale che lo faccia, perché nascono sempre nuove esigenze.

Dal 1998 a oggi siamo passati da Windows 98 a Windows XP SP2, e XP / 64 è dietro le porte (per non parlare di LongHorn, che il prossimo anno porterà un'altra, grande, rivoluzione).

[cdimauro]

Originariamente inviato da xeal

Java mi piace, e mi piacciono in particolare le caratteristiche a cui ti riferisci, però non si può mai abbassare la guardia: basta un piccolo bug nel compilatore/interprete che sia e i benefici del linguaggio di alto livello vanno a farsi benedire...

A parte questo, basta passare da Java al C++ o un altro linguaggio orientato agli oggetti senza un garbage collector, per ritrovarsi come minimo con un degli enormi problemi di memory leak.

Purtroppo ormai anche all'università si comincia a programmare in Java e, anzi, quasi sempre è l'unico linguaggio utilizzato e studiato per quanto riguarda la programmazione in generale, e a oggetti in particolare.

Francamente preferirei il Pascal a oggetti, che è fortemente tipizzato (quindi obbliga a capire bene con quali strutture / tipi di dati si ha a che fare, e COME gestirli), e che richiede l'uso di costruttori E distruttori quando si comincia a lavorare con gli oggetti.

Lo so: sono troppo di parte...

[cdimauro]

Originariamente inviato da Morkar Karamat

Cmq programmare in Fortran ora come ora lo ritengo "delinquenziale", che i salti incondizionati siano totalmente simulabili attraverso quelli condizionati è stato dimostrato ormai da molti anni (mi pare da Dijkstra),

Non mi pare. Forse ti riferivi al teorema di un nostro illustre collega, di cui adesso mi sfugge il nome, che dimostra che è possibile fare a meno del GOTO, riscrivendo il codice usando cicli WHILE/REPEAT ed eventualmente facendo uso di variabili booleane.

l'unico problema da superare è l'inerzia dei programmatori di vecchia data, + che comprensibile. Anche C/C++ comincia ad essere datato e credo che con la prossima generazione di SO scritti in Java/.NET ci saranno molti meno bug e anche gli interventi di manutenzione sul codice saranno molto facilitati.

Lo credo anch'io. Comunque vorrei spezzare una lancia in favore del Fortran (per quanto non apprezzi proprio questo linguaggio): dalla prima standardizzazione alle ultime è cambiato molto, e permette di utilizzare costrutti e istruzioni ad alto livello.

Tra l'altro Java 5 è a prova di proiettile, oltre che safe è anche fortemente tipato grazie ai warning che sono stati aggiunti per indicare utilizzi "non safe" del polimorfismo e metterli in evidenza

Mumble... Devo dargli una ripassata prima o poi...

Versatilità, sicurezza...e le prestazioni non sono poi male dato che continuano a migliorare i compilatori, spero che nel giro di 5-10 anni diventi davvero lo standard.

Sulla sicurezza ho miei dubbi.

D'altra parte, da EONI è possibile attivare, ad esempio, il controllo sugli indici degli array, o addirittura sull'overflow delle operazioni, ma chi l'ha mai fatto? Si va sempre di fretta, e poi se ne pagano le conseguenze...

[cdimauro]

Originariamente inviato da Leron

mi fa piacere che ti piaccia

M'è sempre piaciuto il look di MacOS...

sto lavorandoci su, voglio migliorarlo un poco soprattutto nei caricamenti delle pagine di firefox

Però io uso Opera...

[cdimauro]

Scusatemi per gli orrori grammaticali: sono troppi da correggere e il tempo che ho è poco...

[fek]

Originariamente inviato da xeal

Poi, quel risultato è ottenuto in parte mediante limitazioni alla libertà del programmatore: ad esempio, Java ti impedisce di gestire direttamente l'allocazione della memoria (intendendo per direttamente la richiesta al sistema operativo di allocarne quanta ne vuoi e più o meno come vuoi: in definitiva lo fa lui), cosa che per un OS è di fondamentale importanza, inoltre non è possibile sovraccaricare gli operatori, limitazione utile da un lato, potenzialmente eccessiva ai fini della scrittura di un OS: in C++, ad esempio, potresti scrivere una tua versione dell'operatore new (o più versioni) per accedere in memoria e gestirne l'allocazione nella maniera più opportuna in determinate circostanze (ma potresti farlo anche con apposite funzioni in C, non potresti farlo in alcun modo in Java).

Mi inserisco in questa vostra discussione perche' e' interessantissima.

Riporto una frase di Don Box che riguarda proprio questo argomento, dove, piu' o meno, dice: "Ogni volta che un nuovo linguaggio o un nuovo paradigma alza il livello di astrazioni, c'e' qualcuno che si lamenta perche' non ha piu' il controllo che aveva prima. E' successo con con il passaggio dall'Assembly al C/C++ ed ora succede col passaggio da codice unmanaged a codice managed. I vantaggi derivati dall'aumento del livello di astrazione hanno sempre superato gli svantaggi dovuto al minore controllo".

Don Box si riferisce al codice gestito (managed) dal framework .NET, ma il discorso e' identico per il codice gestito dalla JVM di Java.
Entrambi gli ambienti innalzano il livello di astrazione, ad esempio eliminando il concetto di memoria, introducendo un raccoglitore di rifiuti che si occupi di liberare gli oggetti non piu' usati, astraggono dai concetti quali il Thread introducendo concetti quali l'esecuzione asincrona.

Tutti questi cambiamenti limitano il programmatore come hai detto tu, gli danno un ambiente di lavoro piu' "controllato", "gestito" che limitano la possibilita' di commettere errori, rendono le applicazioni anche piu' sicure. Ma come hai aggiunto limitano anche l'espressivita' del programmatore nell'esprimere concetti richiesti da certi tipi di applicazioni. E non solo.

Il punto e' che ogni aumento del livello di astrazione e l'aumento di produttivita' che ne deriva portano ad inefficienze nell'esecuzione del codice.

La mia opinione e' che nel 99% dei casi l'aumento di produttivita' giustifichi ampiamente le inefficienze.

Poi esistono applicazioni particolari quali il Kernel di un sistemi operativo, posso anche aggiungere il render loop di un motore 3d, dove gestire i puntatori in maniera nativa, oppure il ciclo di vita di un oggetto, o avere il massimo controllo possibile sull'ambiente sono fondamentali, ma queste sono eccezioni, non la norma. E non credo che le eccezioni dovrebbero penalizzare la produttivita' e la sicurezza nella maggior parte delle applicazioni.

In sintesi sono totalmente a favore degli ambienti gestiti come Java e .NET. Credo sia solo una questione di strumenti ed usare gli strumenti adatti a risolvere un dato problema: devo scrivere il kernel di un sistema operativo, posso farlo in Java o C#? No, perche' non ho gli strumenti espressivi per esprimere determinati concetti. Devo scrivere un'architettura di streaming video peer to peer (), ha senso farlo in C/C++? Si', ma in C# posso esprimere tutti i concetti che mi servono e riesco a farlo in un terzo del tempo, quindi scelgo questo strumento.

[cdimauro]

D'accordo, e infatti ormai da mesi uso quasi esclusivamente Python come linguaggio / ambiente per lo sviluppo delle applicazioni dove lavoro, che offre un notevole livello di astrazione e permette di concentrare le energie sul problema da risolvere, piuttosto che perdere tempo in dettagli implementativi come l'allocazione o la liberazione della memoria...

I problemi sorgono per chi da questi linguaggi / ambienti "comodi" passa poi ad altri, che non offrono gli stessi meccanismi...

[fek]

Originariamente inviato da Morkar Karamat

I programmatori del futuro non saranno per forza tutti dei guru che giocano con i puntatori, anche se qualcuno continuerà giustamente a farlo per determinate parti di codice "critiche", ma i traguardi della programmazione saranno IMHO altri....niente nostalgia

"Every fool can write code that a machine can understand, only good programmers can write code that a human can understand"

[fek]

Originariamente inviato da Morkar Karamat

Bellissima Di chi è? Potrei merrerla in sign...

Marin Fowler in "Refactoring: Improving the Design of Existing Code".

[xeal]

Originariamente inviato da cdimauro
Fino a Windows 3.1 lo erano: poi no. IMHO, chiaramente

Per quel che ho capito da un vecchio (non troppo) articolo di Pc Professionale, il problema principale di Win 9x era la gestione "ibrida" dei processi per ottenere il multitasking, al fine di mantenere compatibilità con il dos: per quelli a 32 bit si realizzava un multitasking prelativo, efficiente, per quelli a 16 bit, compresi alcuni moduli del s.o. stesso, si effettuava un multitasking "cooperativo" (un po' come per il dos, che non era stato pensato per il multitasking), affidando ai processi stessi il compito di rilasciare le risorse a favore degli altri quando lo ritenessero opportuno, oppure (credo) approfittando di un i/o burst per fare uno swapping dei processi, senza un meccanismo di prelazione. Ne conseguiva che, se un processo (a 16 bit) andava in crash, trascinava con sé nel baratro tutti quelli (naturalmente solo quelli a 16 bit) che condividevano/contendevano le stesse risorse, compresi i moduli del kernel a 16 bit, da cui il problema della schermata blu. Con le varie versioni di NT questo problema è stato risolto "cacciando" fuori dal kernel tutto ciò che non è essenziale e i moduli necessari alla compatibilità con il dos e gli applicativi a 16 bit. Con xp di schermate blu ne ho viste ben poche, delle quali una per un paio di ca@@ate fatte da me e le altre per un banco di memoria che stava morendo e, diavolo a farlo apposta, mi dava problemi sempre con lo stesso driver e poche altre cose (dannata polvere ).

Comunque, AI TEMPI, anche Windows 3.1 non era da buttar via...

Mi è capitato di averci ancora a che fare due o tre anni fa, grazie a un mio amico (e coinquilino) al quale era stato praticamente regalato un piccolo cimelio, un portatile (o forse sarebbe meglio dire "trasportabile", data l'epoca della sua nascita) 286 con 2 mega (se non ricordo male) di ram. E' stato divertente smanettarci un po' e lanciarsi banane da un tetto all'altro... Peccato che di li a poco sia defunto il monitor

A parte questo, basta passare da Java al C++ o un altro linguaggio orientato agli oggetti senza un garbage collector, per ritrovarsi come minimo con un degli enormi problemi di memory leak.

Purtroppo ormai anche all'università si comincia a programmare in Java e, anzi, quasi sempre è l'unico linguaggio utilizzato e studiato per quanto riguarda la programmazione in generale, e a oggetti in particolare.

Per questo sono convinto che non farebbe male partire con un po' di programmazione strutturata, meglio se in Pascal, per la sua forte tipizzazione. Credo che basti qualche algoritmo di gestione delle liste con inserimenti e (soprattutto) cancellazioni per inquadrare il problema ed estendere poi il concetto senza troppi problemi agli oggetti.

A proposito di oggetti, la versione in Pascal non l'ho mai approfondita, ma non ho dubbi che sia fatta bene. Per quel che ne so, è un peccato che non abbia avuto altrettanto successo l'erede forse più diretto del Pascal standard, il Modula 2 (non vorrei dire castronerie, ma potrebbe essere stato opera di Wirth), che ne correggeva i difetti (tipo il mancato controllo sui bound di un intervallo) e introduceva la programmazione a oggetti. Probabilmente fu colpa del nome poco incisivo, chissa, lo avessero chiamato Perfect Pascal, Pascal Plus o Pascal 2...

Lo so: sono troppo di parte...

Be', forse lo sono un po' anch'io

[xeal]

Originariamente inviato da fek
In sintesi sono totalmente a favore degli ambienti gestiti come Java e .NET. Credo sia solo una questione di strumenti ed usare gli strumenti adatti a risolvere un dato problema: devo scrivere il kernel di un sistema operativo, posso farlo in Java o C#? No, perche' non ho gli strumenti espressivi per esprimere determinati concetti. Devo scrivere un'architettura di streaming video peer to peer (), ha senso farlo in C/C++? Si', ma in C# posso esprimere tutti i concetti che mi servono e riesco a farlo in un terzo del tempo, quindi scelgo questo strumento.

Perfettamente d'accordo, ed in fondo è proprio li che volevo andare a parare. Il livello di astrazione di cui stiamo parlando sostanzialmente demanda ciò che astrae al livello sottostante (framework/VM) e di conseguenza i linguaggi corrispondenti a tale livello non possono essere usati per sviluppare il software che deve girare ai livelli inferiori, mentre sono ottimi per tutto il resto. In ogni caso, insieme al controllo viene demandata anche la risoluzione di (alcuni di) quei problemi che potrebbero produrre dei bug, per cui potrebbe avere senso fare comunque (magari in circostanze particolari/opportune) un testing a 360 gradi con un occhio di riguardo al comportamento dello strato sottostante, magari per comunicare tempestivamente al team che sviluppa il framework un eventuale bug (esempio banale: l'utilizzo del valore "lenght" associato a ciascun array in un ciclo, insieme a un sistema opportuno di eccezioni per la verifica del rispetto dei confini, dovrebbe scongiurare il pericolo di un buffer overflow/underflow, però un piccolo test, di tanto in tanto, per verificare cosa succede a cavallo del valore limite, credo che male non faccia). Dico questo perchè, a mio modo di vedere, questo demandare il controllo a un livello sottostante da un lato localizza molte problematiche, rendendone probabilmente più facile la risoluzione da parte del team che si dedica allo sviluppo del framework (una volta e per tutte) - e semplificando la vita agli altri sviluppatori - dall'altro un eventuale bug finirebbe per colpire inesorabilmente tutti gli altri, senza possibilità di scampo, quindi ritengo che un minimo di collaborazione in questo senso potrebbe essere auspicabile. IMHO, ovviamente

[fek]

Originariamente inviato da xeal

(esempio banale: l'utilizzo del valore "lenght" associato a ciascun array in un ciclo, insieme a un sistema opportuno di eccezioni per la verifica del rispetto dei confini, dovrebbe scongiurare il pericolo di un buffer overflow/underflow, però un piccolo test, di tanto in tanto, per verificare cosa succede a cavallo del valore limite, credo che male non faccia).

Piu' che non far male, quel test dovrebbe essere obbligatorio. E i test quando e' possibile vanno scritti prima di scrivere il codice relativo.

[cdimauro]

Originariamente inviato da Morkar Karamat

x cdimauro

Forse non ha fatto Dijkstra la dimostrazione vera e propria (ma ne sono quasi sicuro, boh..) ma ha scritto di certo quanto indicato da xeal.

Forse ho trovato il bandolo della matassa http://it.wikipedia.org/wiki/Teorema_di_Jacopini-Bohm

"Il teorema di Böhm-Jacopini, enunciato nel 1966 dagli informatici Corrado Böhm e Giuseppe Jacopini, afferma che qualunque algoritmo può essere implementato utilizzando tre sole strutture, la sequenza, la selezione ed il ciclo, da applicare ricorsivamente alla composizione di istruzioni elementari (ad es. di istruzioni eseguibili con il modello di base della macchina di Turing)."
...
"In effetti esso ha contribuito alla critica dell'uso sconsiderato delle istruzioni go to e alla definizione delle linee guida della programmazione strutturata che si sono avuti intorno al 1970."

Dai un'occhiata a Java 5 (o 1.5 che dir si voglia), oltre a delle macro comode ed utili c'è proprio tutto un nuovo meccanismo per il controllo dell'utilizzo del polimorfismo.

OK, grazie.

Sulla sicurezza in parte ti dò ragione sulla buona volontà, ma è anche vero che dove all'uni insegnano Java ti "radicano" bene in testa l'importanza della gestione delle Eccezioni e di altre cose tanto che quando programmi in C (necessario all'uni di Torino in diversi corsi: quello introduttivo a C e quello di SO focalizzato su Unix ad es.) ti senti "orfano" di tutto ciò e ti rendi conto che stai scrivendo cmq codice "non safe", scarsamente tipato (con quei void* da brividi ) e quando fai linking tra 2 files ti viene male a vedere quanto sia macchinoso il bynding dinamico in C rispetto a Java, per quanto semplici possano essere tali programmi.

Per questo preferisco Pascal e derivati al C...

Il futoro sarà IMHO: 0,1% di codice in linguaggio assemblatore, 2% in C, il resto in Java o simili....

Sono d'accordo (ed è, poi, ciò che ha detto fek...)

ovviamente in attesa di un'altra evoluzione/rivoluzione che, quando sarò della vecchia guardia, osteggerò con tutte le mie forze (spero di no...)

.NET?

[cdimauro]

Originariamente inviato da Morkar Karamat

Poi per le free la situazione è drammatica...sarà che non sono abituato ma per loro ci impiego lo stesso tempo che a fare il resto del programma

Infatti è perché non ci sei abituato.

Le poche volte in cui mi cimento ancora con le classi in Delphi (Pascal), scrivo subito assieme costruttore/i e distruttore/i, codice che alloca e libera la memoria, codice che crea istanze di oggetti e che li distrugge, infarcendo il tutto con blocchi try/(except|finally).

E' anche una questione di mentalità, che si acquisce col tempo lavorando con un linguaggio, e imparando a usarlo e sfruttarne le caratteristiche per scrivere codice "migliore".

[cdimauro]

Originariamente inviato da xeal

Per quel che ho capito da un vecchio (non troppo) articolo di Pc Professionale, il problema principale di Win 9x era la gestione "ibrida" dei processi per ottenere il multitasking, al fine di mantenere compatibilità con il dos: per quelli a 32 bit si realizzava un multitasking prelativo, efficiente, per quelli a 16 bit, compresi alcuni moduli del s.o. stesso, si effettuava un multitasking "cooperativo" (un po' come per il dos, che non era stato pensato per il multitasking), affidando ai processi stessi il compito di rilasciare le risorse a favore degli altri quando lo ritenessero opportuno, oppure (credo) approfittando di un i/o burst per fare uno swapping dei processi, senza un meccanismo di prelazione. Ne conseguiva che, se un processo (a 16 bit) andava in crash, trascinava con sé nel baratro tutti quelli (naturalmente solo quelli a 16 bit) che condividevano/contendevano le stesse risorse, compresi i moduli del kernel a 16 bit, da cui il problema della schermata blu.

Ne abbiamo già parlato in un altro (kilometrico ) thread, comunque sì, sostanzialmente è ciò che si verifica. Questo perché le applicazioni e il s.o. stesso condividono con le sezioni a 16 bit:
- alcune zone di memorie "critiche";
- la gestione degli interrupt;
- l'accesso alle porte di I/O.
Con tutte le conseguenze che un approccio di questo tipo può portare.
C'è da dire che, comunque, con Windows 98 e successori ho avuto ben pochi problemi legati a quest'approccio. Anzi, considerato in che modo ho "torturato" il sistema, direi che hanno svolto egregiamente il loro compito...

Per questo sono convinto che non farebbe male partire con un po' di programmazione strutturata, meglio se in Pascal, per la sua forte tipizzazione.

Non solo per quello (anche Java è fortemente tipizzato): da tempo, fortunatamente, il Pascal è diventato un linguaggio molto maturo, che mette a disposizione del programmatore tantissimi strumenti che permettono di scrivere codice adottando diverse metodologie / modelli di programmazione.

Credo che basti qualche algoritmo di gestione delle liste con inserimenti e (soprattutto) cancellazioni per inquadrare il problema ed estendere poi il concetto senza troppi problemi agli oggetti.

Come per altri linguaggi, ormai i compilatori Pascal-like sono dotati di framework con una miriade di classi, che permettono di gestire anche liste di oggetti.

Però non è così comodo come con Python, ad esempio, dove liste, "dizionari", tuple e insiemi si possono utilizzare molto velocemente, con poco codice, e soprattutto in maniera molto leggibile e "intuitiva"...

Se l'overloading degli operatori fosse supportato come si deve, non sarebbe certo difficile scrivere qualche modulo e classi per implementare questi utili strumenti in maniera similare, ma attualmente non è così...

A proposito di oggetti, la versione in Pascal non l'ho mai approfondita, ma non ho dubbi che sia fatta bene.

Beh, insomma... Il problema principale è che esistono tante, forse troppe estensioni del Pascal in questo senso.
L'estensione a oggetti del Pascal realizzata dall'ISO è molto elegante, come pure quella realizzata da Borland (ne ha fatte due: la prima è rimasta per compatibilità col passato, anche se ha delle interessanti caratteristiche).

Per quel che ne so, è un peccato che non abbia avuto altrettanto successo l'erede forse più diretto del Pascal standard, il Modula 2 (non vorrei dire castronerie, ma potrebbe essere stato opera di Wirth),

Lo è, come lo sono il Modula, il Modula-3 e l'Oberon.

che ne correggeva i difetti (tipo il mancato controllo sui bound di un intervallo)

Questo è un controllo che, invece, era "di default" nelle specifiche del Pascal, come pure il controllo degli indici degli array. Purtroppo si tratta di controlli molto pesanti computazionalmente, per cui le implementazioni che sono arrivate fino a noi ne hanno fatto a meno, relegando a direttive di compilazione l'uso o meno di queste caratteristiche.

e introduceva la programmazione a oggetti.

Se non erro è stata introdotta col Modula-3 (o forse con Oberon): Modula-2 ha introdotto, invece, il concetto di tipo "opaco" (simile al tipo "generic" di Ada). Se ricordo bene, comunque: è passato parecchio tempo da quando ho studiato questi linguaggi...

Probabilmente fu colpa del nome poco incisivo, chissa, lo avessero chiamato Perfect Pascal, Pascal Plus o Pascal 2...

No, ti posso garantire che Modula-2 ha avuto un discreto successo fra i "pascaliani" e nella comunità scientifica, come pure Oberon. Purtroppo non hanno avuto il successo che meritavano...

[fek]

Originariamente inviato da cdimauro

Infatti è perché non ci sei abituato.

Le poche volte in cui mi cimento ancora con le classi in Delphi (Pascal), scrivo subito assieme costruttore/i e distruttore/i, codice che alloca e libera la memoria, codice che crea istanze di oggetti e che li distrugge, infarcendo il tutto con blocchi try/(except|finally).

E' anche una questione di mentalità, che si acquisce col tempo lavorando con un linguaggio, e imparando a usarlo e sfruttarne le caratteristiche per scrivere codice "migliore".

Mauro, scrivo le coppie costruttore/distruttore da 15 anni ormai. Uso tutto cio' che mi e' umanamente possibile fare per evitare i double delete e i memory leak, arrivo a nascondere i costruttori/distruttori e costringere la gente a passare attraverso le mie factory class, cerco di recuperare personalmente gli oggetti che la gente si dimentica alla fine del livello eppure... i double delete sono sempre li' e passo ore e giornate a debuggarli. Si parla di un code base di un paio di milioni di righe di codice qui, quasi 30 programmatori, ci vuole il suo tempo a cercare un double delete o un buffer overrun

Molto semplicemente, nel 2005 mi sono stancato di dovere liberare la memoria esplicitamente.

Non solo per quello (anche Java è fortemente tipizzato): da tempo, fortunatamente, il Pascal è diventato un linguaggio molto maturo, che mette a disposizione del programmatore tantissimi strumenti che permettono di scrivere codice adottando diverse metodologie / modelli di programmazione.

Domanda a bruciapelo: chi ha progettato il Pascal della Borland?