Ecco un titolo che frulla insieme argomenti da riempire un paio di libri.
Periodicamente mi trovo a rimettere le mani su codice C++. È normale perché ogni linguaggio+runtime (anche C++ necessita di un runtime) ha un suo campo di applicazione che dipende dai requisiti del progetto... nulla di nuovo.
E infatti C++ nativo (non CLI) è tutt'ora lo strumento preferibile per l'estendibilità della shell, IE, WMI, DirectX, mmc e molto altro ancora.
Cari programmatori managed, una documentazione come quella che avete a disposizione oggi sarebbe stata il paradiso terrestre per chi ha lavorato / lavora con ATL, MFC, Win32, C++ e tutto quello che ci sta intorno. Questi sono strumenti potenti, estremamente efficaci, collaudati e robusti ma anche semplici da abusare e perciò tramutare un progetto in un disastro.
Se guardo alla complessità dei sistemi che ho realizzato in 9 anni di programmazione managed, sono assolutamente certo che con linguaggi+runtime nativi non avrei potuto costruire sistemi altrettanto complessi dal punto di vista architetturale.
C'è invece un enorme, gigantesco, pantagruelico gap tra i tecnicismi del mondo managed e quelli del mondo nativo: nel mondo nativo tutto si giocava sulla comprensione e l'applicazione del tecnicismo, sull'hack, sull'algoritmo che eseguiva dei tweak nei meccanismi standard; nel mondo managed il tecnicismo è quasi sempre poca cosa, l'architettura è regina, il numero di layer cresce a dismisura (entro certi limiti è buona cosa), le ambiguità su una tecnologia sono estremamente più basse.
Ed è qui che si gioca la partita dell'obfuscation, cioè della protezione del software.
Nell'era nativa la protezione degli hack e dei tweak erano il maggior valore del software. Ricordo ancora che debuggando i primi viewer di immagini per SuperVGA sotto DOS ho capito come superavano il limite dei 64K per caricare su più banchi le immagini ad alta risoluzione. (Non si scandalizzino i più giovani, ma nell'era pre-80386 la memoria era segmentata e la memoria grafica era "solo" 64K, quindi come caricare immagini più grosse?)
Nell'era managed, guardi come funziona un software e l'architettura è "in chiaro" non perché puoi usare reflector ma perché è evidente come funziona già da come vengono installati gli assembly o guardando una traccia di rete. Buona parte del codice managed che scriviamo "traspare" ad un utente esperto o al power user equipaggiato di ProcMon e vari altri tool. Se poi si passa a Reflector tutto è più chiaro ma non sono daccordo che sia solo il sorgente a rendere tutto così palese.
La complessità del codice managed ha come side effect il fatto di essere tanto e di doverlo conoscere bene per poter essere usato. Se ti do un milione di righe di sorgente è come non averlo. Il tempo che ci metto a capirlo forse non vale neppure il gioco. E questo è il motivo per cui spesso dico che il sorgente non è il valore del progetto.
È chiaro che non si può generalizzare e se scrivo una applicazione di calcolo ingegneristico che in mille righe risolve problemi mai visti prima, ecco che la sua protezione diventa strategica. Ma chi pensa che il codice C++ sia protetto by design si sbaglia di grosso. Ho letto e debuggato kilometri di codice assembler, i compilatori sono abbastanza "stupidi" da scrivere codice assembler con dei pattern, che una volta riconosciuti permettono di capire molto di più di quanto si creda (Esempio: ECX è il registro usato per il this di una classe C++). Ci sono poi applicazioni come DASM (un disassemblatore), il famoso debugger IDA pro che fa veri miracoli, o ancora gli analizzatori di codice PE (il formato di exe e dll) che permette di fare un guessing della marca e della versione del compilatore usato.
La transizione dai tecnicismi di C++ alla complessità "verticale" delle applicazioni managed spiega anche il calo di interesse nel proteggere il codice compilato. L'obfuscation del codice può essere una necessità ma non ritengo che sia più largamente sentita come un tempo.