Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Alcuni dubbi su Net

Per pigrizia scrivo qui, invece che consultare NG più specifici, ma credo
che le risposte siano semplici.
Leggendo i vari post su Net e senza entrare nel merito
(validità/velocità/complessità/etc.) del linguaggio, mi pare di aver
compreso questo:
-Il linguaggio è piuttosto diverso da VB
-Il "traduttore" da VB a VB(suppongo).NET presume certo tipo di
strutturazione in VB (tipi, dichiarazioni, classi, etc.) e, se anche fosse,
produce codice "sporco" (di difficile manutenzione) al punto che se ne
consiglia la riscrittura completa.
-Con Net (è possibile parlare di "suite"?) si può programmare in VB, C# e
forse altri
    Non ho ben capito: Quando si sceglie un linguaggio questo deve valere
per un intero progetto, oppure è possibile, all'interno dello stesso
progetto, "scambiare o intercambiare" linguaggi diversi, in funzione
(suppongo) del contesto e alla ricerca, per esempio, di migliori
prestazioni, un po' (permettetemi l'assurdo paragone) come avviene, con
opportuni tag di avvio e di fine, in una pagina ASP in cui si "scambia" fra
HTML e ASP/VBScript?
    E questo eventuale interscambio (se ammesso all'interno di un progetto),
vale anche all'interno di una singola routine oppure si presume che questa
(supponiamo una Sub o una Function) sia tutta scritta nello stesso
linguaggio, qualunque esso sia?
-Gli OCX, pur ammessi, sono sconsigliati perchè creano una "strana" mistura
fra nuovo e vecchio sistema.
    Suppongo che il framework (che in qualche modo corrisponde al runtime di
VB) contenga tutto quanto serva per gestire quel che in VB si chiamano
controlli (es. un TextBox) e oggetti (es. un Recordset). Giusto?
-Le API sono liberamente richiamabili, fermo restando che (come per VB)
spesso (salvo, magari, problemi o ricerca di velocità) è preferibile usare
la funzione nativa del linguaggio piuttosto che "emularla" con le API
stesse.
-La distribuzione di un eseguibile che non usa OCX aggiuntivi, presume
l'installazione del solo framework (e di eventuali librerie specializzate,
come MDAC_TYP.EXE) e poi, in fase di aggiornamento, la mera copia del nuovo
EXE (sempre che sia compatibile col framework installato sulla macchina
utente).
-Un EXE in Net è, di fatto, una serie di "chiamate" al framework, ma, più di
quanto non avvenga per un EXE prodotto da VB (che pure può essere
considerato una serie di chiamate al runtime) se ne può ottenere "un"
sorgente decentemente leggibile.
    Senza entrare nel merito di come garantirsi (per quanto non sia mai
possibile in assoluto e con qualsiasi linguaggio) una sufficiente protezione
del proprio lavoro, è possibile dire (se mi si può passare, giusto per
capire, il paragone e la terminologia) che un programma in Net è ...
"interpretato" (come poteva essere GWBasic) e non "compilato"?
Grazie per ogni correzione/spiegazione.

 Grazie per ogni correzione/spiegazione.
Prego, ho parlato di questi argomenti in un webcast Microsoft alcuni giorni
fa, se hai dubbi prova a dargli una guardata quando sarà online la prossima
settimana
-- 
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - 
http://www.ugidotnet.org
Weblog: 
http://www.ugidotnet.org/710.blog

 client_ dove il programma sta girando.
Ok, meglio così (anche in termini di velocità di esecuzione), ma mi sfugge
come sia possibile risalire a un sorgente "leggibile", più di quanto non
possa avvenire per un EXE prodotto da VB. Diciamo comunque che sono
questioni puramente "cervellotiche", tanto ... non ci si può far molto. Così
è... ;-)
Grazie di tutto. Chiarissimo.

> client_ dove il programma sta girando.
Ho compreso ("...compilato a Runtime..."). Quindi possiamo dire, sempre con
beneficio di inventario, che l'IL è una specie di pre-EXE (o anche un
post-sorgente) che produce in fase di esecuzione, tramite il JITCompiler, un
eseguibile in linguaggio macchina ottimizzato, ma questo non viene salvato
in modo permanente, ovvero verrà ottenuto (presumibilmente in memoria) ogni
volta che lo specifico applicativo viene eseguito.
Ritiro il discorso fatto prima sulla velocità... ;-)

 Grazie per ogni correzione/spiegazione.
Ufff, siamo arrivati in fondo :)
Credevo non finisse piщ.
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 Credevo non finisse più.
Grazie anche a te per la chiarezza.

 programma sta girando.
Questa non la sapevo.
O meglio, sapevo che c'era qualcosa del genere ma credevo fosse fatta solo
su richiesta, in base a qualche impostazione del compilato.
Mi piacerebbe saperne di più su come funziona questa cosa.
C'entra qualcosa il tool ngen.exe?


 Ciao

 utilizzabile, se no si avvia la "normale" procedura di compilazione...
Io avevo capito che funzionasse proprio così :-).
Ora ho trovato questo:
http://www.devx.com/assets/summitdays/2679.pdf
e mi sa che ho un bel po' da imparare, ancora... :-/
Bye, G.

 Io avevo capito che funzionasse proprio così :-).
Mi parrebbe logico, ma la risposta di Corrado mi ha posto il dubbio...

 C'entra qualcosa il tool ngen.exe?
Visto che hai comunque delle penalties la prima volta che un metodo viene
compilato, puoi effettuare la precompilazione usando NGEN quando installi
l'applicazione (ad esempio il framework è tutto precompilato) ottenendo una
copia della tua assembly (non accessibile) compilata.
A questo punto, se nulla è cambiato sulla macchina (ovvero non è cambiata la
versione del framework) e la tua applicazione non è stata modificata quando
lanci l'applicazione viene subito eseguita la versione compilata senza
passare per il jitter.
NGEN non è un compilatore così evoluto come il JITter il quale può fare
ottimizzazioni anche a runtime (ad esempio può sostituire un ciclo for con
la ripezione dello stesso codice in sequenza se, analizzate le condizioni, è
in grado di capire che la soluzione può portare a delle prestazioni delle
performances.
Attenzione: NGEN _deve_ essere fatto girare sulla macchina client, e sulla
macchina client deve essere comunque presente il codice IL, in quando
l'output di NGEN non contiene i relativi metadati che il .NET framework
necessita.
HTH


Vedi discorso NGEN..., comunque il JIT Compiler ottimizza anche a runtime,
ecco il motivo percui spesso la versione JITtata è più veloce dell'immagine
X86 nativa prodotta da NGEN, non per niente MS ha speso parecchie "energie"
proprio sul JIT Compiler
HTH


programma sta girando.
Io ho inteso quel "compilato a Runtime" come "compilato ogni volta a
Runtime".
Forse non è così, ma allora non mi spiego come debba essere necessario
fornire il codice IL...
Voglio dire, se io, per proteggere il mio sorgente, decido (con tutto il mio
carico che ne può conseguire e che coscientemente mi accollo) di installare
in loco, avviare, ottenere l'EXE vero (dal quale non si può ricavare un
sorgente non leggibile) e eliminare il file corrispondente all'IL, perchè
mai non devo potere?
Se il framework o il motore che si occupa delle verifiche carica prima l'EXE
e lo trova compatibile non ha assolutamente bisogno dell'IL. Certo, se
avviene il contrario allora ... non ci siamo.
Ovvio, se il sistema cambia, probabilmente l'IL va reinstallato. Esattamente
come ora è necessario riregistrare DLL e OCX se quella stessa macchina si
formatta e/o vi si monta un nuovo sistema operativo.

 framework necessita.
Insomma, nessuna maniera per _non_ mandare in giro il proprio IL ? :-(
Bye, G.

 framework necessita.
Ah, forse per questo...
Non so cosa sia NGEN nè se questo debba essere fatto girare ogni volta, ...
lascio stare, ma vorrei tanto poter levare quell'IL...

 proprio sul JIT Compiler
Ciaoè per assurdo io potrei avere un """interpretato""" più veloce del
compilato nativo?
E, sempre accademicamente, come si incasta in tutto questo il C++.net che
può compilare nativamente sulla macchina di svilup? (o anche questo non è
esatto?)


 necessita.
E allora che razza di compilato č?
Bah, comunque al lato pratico mi sembra molto meglio e molto pił comodo
lasciare che tutto il lavoro lo faccia il jitter :)


No, l'output di un assembly contiene IL + Metadati (ovvero info che
autodescrivono l'assembly e, ad esempio, indicano quali altre assemblies
sono necessarie a runtime) e i metadati servono.
Se hai del codice che vuoi assolutamente proteggere (non dirmi che vuoi
proteggere il codice che usi per accedere ad un database...) ci sono
tecniche alternative
1-Obfuscators (VS2003 ne ha uno integrato anche se molto banale...)
2-Demeanor (Ti assicuro che il codice IL è illeggibile)
http://www.wiseowl.com/products/products.aspx
3-Crypta l'assembly e Decriptala a runtime intercettando gli eventi di
AppDomain (se ne è parlato ad un Workshop UGIdotNET l'anno scorso)
4-Metti il codice "strasicuro" in una dll scritta in C++ o similari
Come vedi le alternative esistono...


 esatto?)
C++ può _anche_ generare codice X86 nativo quindi in questo caso nulla
rimane invariato rispetto al passato.


 viene ricompilato al volo, giusto?
Giusto, tieni presente che il file non viene compilato tutto, il JITTer č
"smart" compila solo quello che serve, se hai una dll all'interno della
quale hai delle classi che l'utente non sta usando, perchč compilarle?, se
hai dei metodi che non vengono usati perchč compilarli in codice nativo?


 "soluzioni") con progetti scritti in linguaggi differenti.
[SNIP]
A livello di IDE effettivamente e' cosi', e' possibile pero' usare piu'
linguaggi anche per una singola applicazione: le varie parti possono essere
compilate come moduli non autosufficienti (di per se non sono assembly
autonome, mancano di metadati) e poi linkati tutti in un'unica assembly in
un secondo momento.
Per i compilatori a riga di comando l'opzione e' /target:module, i file
prodotti devono poi essere dati in pasto al linker (al.exe)
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 La società più famosa in questo campo è forse la 
www.remotesoft.com
Perche' offuscare il codice? Io vedo alcune ragioni possibili, e per 
tutte esiste una soluzione migliore dell'offuscare il codice.
Potremmo non voler far vedere il nostro codice per impedire la copia non 
autorizzata del nostro programma. Chi vuole attuare tale pratica pirata 
potrebbe leggere il codice e volerlo modificare eliminando eventuali 
controlli sulla licenza, partire da un codice di alto livello piuttosto 
che da un linguaggio di basso livello (assembly) semplifica questa 
attivita'.
Il framework pero' prevede la possibilita' di firmare digitalmente i 
moduli del programma, rendendo di fatto impossibile la sostituzione di 
un tal modulo senza avere a disposizione la chiave digitale utilizzata 
originariamente (che, naturalmente, non e' inclusa nel compilato IL).
Potremmo non voler far vedere il nostro codice per tutelare il proprio 
knowhow, algoritmi innovativi e particolari sono conoscenza e la 
conoscenza - nella societa' odierna - e' valore, e' denaro.
In tal caso, il problema e' un problema legale e non tecnico. La 
soluzione dovrebbe essere legale e non tecnica, una buona licenza puo' 
fare molto di piu' che un codice difficile da leggere: esistono 
decompilatori anche per il normale codice x86, il lavoro da fare per 
comprendere tale codice sara' piu' lungo, pero' una volta completato il 
risultato e' lo stesso. L'algoritmo sara' conosciuto. Una tutela legale 
invece e' piu' difficile da superare.
Paradossalmente, la facilita' con cui e' possibile decompilare il codice 
IL puo' esserci di aiuto: per valutare se eventuali concorrenti abbiano 
attinto illegalmente al nostro knowhow.
Se poi abbiamo l'assoluta necessita' d'impedire che il nostro lavoro 
cada in mani sbagliate, il mondo dell'informatica e' cambiato negli 
ultimi anni. Il mondo e' ormai connesso.
Costruiamo un web service, mettiamo il codice da tutelare su un nostro 
server e chiamiamolo dal programma che consegnamo all'utente.
-- 
Roberto Lupi

 server e chiamiamolo dal programma che consegnamo all'utente.
Il mondo è connesso? Ma in quale mondo vivi?
Pollice verso.

server e chiamiamolo dal programma che consegnamo all'utente.
Ma è veramente connesso il mondo? Qui in italia mi sembra che i
provider abbiano delle difficolta a procurare e garantire la
"connessione". Ti affideresti realmente ad una soluzione di questo
tipo?
Considerando che molte realtà nostrane sono piccole, avrebbero un
carico maggiore di responsabilità legate al fatto di dover garantire
la sicurezza del server che condivide il codice da pericoli esterni.
Inoltre per le difficolta di connessione del nostro paese ti immagini
se il server resta tagliato fuori e i clienti non possono più
accedervi? Imho è una soluzione da prendere con le molle ...
Ciao!

 originariamente (che, naturalmente, non e' inclusa nel compilato IL).
Puoi spiegare per bene questa possibilità?


> Puoi spiegare per bene questa possibilità?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconstrong-namedassemblies.asp
HTH


 originariamente (che, naturalmente, non e' inclusa nel compilato IL).
Ho letto il link pubblicato da Corrado in questo 3d.
Beh, considerare quella come una protezione del codice è quantomeno ...
ottimistico.

, 
LupoOrmaiR...@libero.it
 says...

Se rileggerai meglio io mio messaggio, vedrai che proponevo la firma digitale per i 
moduli del programma in sostituzione dell'offuscamento del codice, quando la finalita' 
ultima e' la copia non autorizzata del programma.
La possibilita' di firmare digitalmente i moduli di un programma e' utile 
nell'implementare meccanismi anti-copia.
Immagina di implementare un servizio di attivazione simile a quello inserito in Windows 
o nel nuovo Office.
Il programma alla prima installazione si colleghera' ad un server per effettuare la 
registrazione e chiedere un "lease"; un'autorizzazione a funzione per un certo tempo o 
entro certi limiti, potrebbe -come per il Windows- essere legata all'hardware 
installato sulla macchina. Nel mondo .NET, questo lease potrebbe essere un documento 
XML firmato digitalmente e il server potrebbe essere facilmente implementato con un 
webservice accessibile via HTTPS.
Vedi la catena del trust?
- Web service del produttore (consideriamolo sicuro per ipotesi)
- Collegamento SSL (tramite l'impiego di certificati persistenti, consente al programma 
d'identificare il sito del produttore ed impedisce all'utente di simularlo con un finto 
sito)
- Programma client
Ora, perché lo schema funzioni, dobbiamo estendere la catena del trust anche al codice 
che chiede il lease e poi lo interpreta attivando o disattivando le funzioni del 
programma stesso. E, in seconda istanza, dobbiamo estenderlo all'intero programma, in 
modo che l'utente non possa bypassare il processo di richiesta del lease.
La prima parte si ottiene implementando il codice di richiesta e di gestione del lease 
in un modulo firmato digitalmente, che sara' poi utilizzato dagli altri moduli del 
programma. Tale modulo dovra' anche contenere la chiave pubblica per verificare la 
validita' del lease.
La seconda parte si ottiene memorizzando parte del programma (quella che piu' si vuole 
proteggere) in forma crittografata, e decrittandola durante l'esecuzione con una chiave 
presente nel lease stesso.
-- 
Roberto Lupi

 o nel nuovo Office.
...
Ok, immagino, ma se io riscrivo (non copio) e adatto il codice (in bella
vista) di un altro, con le mie personalizzazioni e adattamenti del caso, chi
mi impedisce di far fare al mio codice esattamente quello che fa l'altro?
Non parlo di protezioni che si basano su qualcosa che tu dai per scontato
(per esempio un collegamento internet e un server per un'autorizzazione,
perchè un piccolo artigiano può non sapere cos'è internet e ne ha, IMHO,
tutto il diritto), parlo di artifici, idee e strumenti che io non desidero
divulgare mostrandone il codice.
Per intenderci e per non dare troppo addosso alla mamma, anche XP può essere
attivato per telefono, internet non è così scontata come (già in altro post)
tu pensi.
Anche il mio applicativo deve poter funzionare senza (mai) un collegamento
internet.
Devo (vorrei) poterlo fare senza dover regalare il codice (per quello ed
altro) al mondo intero.
Credo che la richiesta sia lecita, credo che "Perchè offuscare il codice?"
solo il diretto interessato se lo possa, eventualmente, chiedere.