La \u201criunione di Praga\u201d ha compiuto vent\u2019anni nel 2018; me ne sono reso conto quando ho dato un\u2019occhiata agli archivi e mi sono imbattuto nella \u201cdocumentazione sulla tecnologia di Praga\u201d, che risale al 22 giugno del 1998. Ai tempi, la nostra preoccupazione era di contrastare qualche virus \u201cinnovativo\u201d e di risolvere problematiche puramente tecniche che avevano a che fare con il nostro motore antivirus. E la soluzione che abbiamo trovato era molto pi\u00f9 ad ampio spettro, pi\u00f9 potente e di maggiore utilit\u00e0. Per molti aspetti Praga \u00e8 stata la tecnologia base dei nostri prodotti per i successivi 10 anni.<\/p>\n
Come \u00e8 iniziato tutto?<\/h3>\n
Ci troviamo nella tappa intermedia, tra gli albori della nostra azienda al secondo piano di una scuola materna nel quartiere moscovita di Strogino, e il nostro incredibile quartier generale tutto di vetro<\/a>. Avevamo concesso la licenza del nostro motore a numerosi partner stranieri e avevamo gi\u00e0 lanciato sul mercato una versione chiamata Antiviral Toolkit Pro 3.0 e con un certo successo. Comunque, il nostro futuro tecnologico non sarebbe stato tutto rose e fiori.<\/p>\n Avevamo due grandi sfide da affrontare, il che era assolutamente necessario, c\u2019erano molte difficolt\u00e0 da superare. La prima riguardava la capacit\u00e0 di processare oggetti sospetti indipendentemente da dove fossero immagazzinati (un tipico esempio sono gli oggetti embedded, una sorta di matrioska grazie al quale un file malware eseguibile si trova all\u2019interno di un file, a sua volta in un altro file etc). La seconda sfida era creare un motore antivirus che potesse essere aggiornato il pi\u00f9 velocemente possibile e che richiedesse delle modifiche minime (o nessuna, ancora meglio) tra le diverse piattaforme.<\/p>\n Nel caso qualcuno lo avesse dimenticato, i creatori di virus degli anni Novanta erano davvero fantasiosi: alcuni nuovi virus non solo richiedevano l\u2019aggiornamento del database per intero, ma del motore stesso<\/em>. Gli utenti ai tempi disponevano di una connessione a Internet molto lenta (nel caso ce l\u2019avessero) e scaricare un aggiornamento di un paio di megabyte poteva costituire un serio problema. Windows 98 si stava facendo spazio ma non aveva ancora sostituito DOS completamente, e qualsiasi innovazione nel nostro campo doveva essere implementata in entrambi<\/em> i sistemi operativi, il che richiedeva molto lavoro.<\/p>\n Insomma, avevamo molti argomenti da trattare durante la nostra settimana di brainstorming a Praga (oltre a me, vi partecipavano Alexey De-Monderik, Andrey Kryukov, Andrey Nikishin, Vadim Bogdanov e Larisa Gruzdeva). Abbiamo noleggiato una sala conferenza di un hotel e ogni giorno, dalle 9 alle 17, affrontavamo tutte queste tematiche. Dopo una giornata di intenso lavoro, andavamo al ristorante o al biliardo per bere una birra e per far riposare le nostre idee affinch\u00e9 potessero svilupparsi.<\/p>\n Sono state giornate di lavoro molto produttive e siamo tornati a Mosca con un progetto; De-Monderik ha scritto una bozza delle idee che ne sono venute fuori ed \u00e8 stato proprio quel documento a ispirare questo articolo.<\/p>\n Kryukov e Nikishin hanno poi continuato a sviluppare Praga, che \u00e8 stato creato ufficialmente nel 1999, quando Andrey Doukhvalov \u00e8 entrato a far parte del team. La sua esperienza in sviluppo di sistemi ha aiutato a trasformare Praga in un progetto concreto e non solo in un sistema di plugin per un motore antivirus.<\/p>\n Praga \u00e8 diventato un sistema modulare indipendente dove gli oggetti venivano creati e gestiti dopo il lancio dell\u2019applicazione, dopo aver osservato la gerarchia degli oggetti e dopo l\u2019abilitazione da parte del kernel di funzionalit\u00e0 come la gestione della memoria e dei messaggi. Tutta la comunicazione con il sistema operativo e l\u2019interfaccia utente avviene mediante un sottile strato, ed \u00e8 stato possibile scrivere quasi il kernel intero dell\u2019antivirus seguendo i \u201cplugin Praga\u201d.<\/p>\n Doukhvalov ha sviluppato la prima versione pronta all\u2019uso per AVP 4.0. Non era ancora stato riscritto \u201callo stile Praga\u201d ma i punti di forze erano gi\u00e0 evidenti:<\/p>\n Grazie all\u2019uso di Praga, eravamo all\u2019avanguardia nel settore IT: l\u2019approccio modulare allo sviluppo del software ai tempi non era cos\u00ec avanzato. Successivamente, negli Stati Uniti abbiamo registrato ben 4 brevetti di Praga: 7386885<\/a>, 7730535<\/a>, 7418710<\/a> e 8234656<\/a>.<\/p>\n Inoltre, Praga si integrava facilmente a codici scritti seguendo diversi principi, per questo \u00e8 stato costruito inizialmente per la versione 4.0 ma solo per risolvere una piccola serie di problemi. Aveva superato la prova cos\u00ec bene che, quando sono sorti problemi pi\u00f9 importanti durante lo sviluppo della versione 5.0, a Doukhvalov gli \u00e8 venuta in mente l\u2019idea di creare una versione completamente nuova di Praga, che ha portato alla rivoluzionaria versione 6 di Kaspersky Anti-Virus, di cui abbiamo gi\u00e0 parlato in dettaglio in passato<\/a>.<\/p>\n Per passare da un \u201cplugin antivirus\u201d a un framework di un intero prodotto, bisogna riorganizzare e reinventare alcuni processi. A questo ci hanno pensato Andrey Doukhvalov and Pavel Mezhuev, senza di loro Praga non si sarebbe potuto adattare a certe task cos\u00ec complesse.<\/p>\n Ovviamente la perfezione non esiste, soprattutto nel nostro mondo, e Praga ha due inconvenienti principali.<\/p>\n Innanzitutto, il debugging era difficoltoso e gli sviluppatori avevano difficolt\u00e0 ad adottare Praga. Indipendentemente da come lo si guardasse, si trattava di un sistema completamente nuovo che imponeva dei requisiti piuttosto rigidi per il design del codice. Inoltre, all\u2019inizio i moduli dovevano essere scritti in puro C, portare avanti la formazione su questo nuovo metodo richiedeva tempo, avevamo bisogno di un numero sempre maggiore di sviluppatori perch\u00e9 l\u2019azienda stava crescendo velocemente e i nostri prodotti diventavano sempre pi\u00f9 complessi.<\/p>\n Cos\u00ec come avviene nel settore IT in generale, la velocit\u00e0 era diventata una priorit\u00e0 e, poco a poco, siamo dovuti passare a framework di oggetti pi\u00f9 conosciuti e convenzionali. Tuttavia, alcuni frammenti basati su Praga continuano a funzionare correttamente all\u2019interno dei nostri prodotti.<\/p>\n Naturalmente, ai tempi questi inconvenienti riguardavano i processi e le risorse. Si potevano e si dovevano risolvere poich\u00e9 i vantaggi derivanti dall\u2019implementazione di Praga erano considerevoli e giustificavano appieno tutte le risorse impiegate. Praga aveva risolto uno dei problemi pi\u00f9 difficili, costosi e importanti da 10 anni a questa parte, ovvero la portabilit\u00e0 di una tecnologia (portabilit\u00e0 binaria compresa) su diverse piattaforme.<\/p>\n Invece di creare un prodotto da zero per ogni sistema operativo e processore, usavamo un motore in debug e pronto all\u2019uso. Questo grande investimento in ricerca e sviluppo non \u00e8 stato completamente ripagato ma ci rende ancora oggi leader in tecnologia: l\u2019UCA (il successore di Praga) \u00e8 ancora largamente utilizzato e per il momento non abbiamo trovato problemi che non possano essere risolti grazie a essa. Un\u2019ulteriore prova che una buona architettura pu\u00f2 reggere a decenni di test.<\/p>\n![\"\"](\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/89\/2018\/07\/27132509\/doc.gif\")
<\/p>\n\n