Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] Framework .NET senza CLR...

Ciao a tutti,
dopo essermi avvicinato al mondo .net ne ho relativamente apprezzato
l'ordine delle classi ma disprezzato altamente le prestazioni, in
termini di velocità e occupazione di memoria.
In una pausa tra un OleDb.DataAdapter ed un PrintDocument stavo
fantasticando su una possibile implementazione del framework .net in
modo tale che il risultato finale sia un eseguibile puro, non
assembly. Chiaramente in questo caso le comodità (?) della CLR (ne
cito una a caso: il garbage collection, che a me suona come uno
spazzino che butta via il pattume che il programmatore non è in grado
di pulire da sé) si perdono, ma si guadagnerebbe in velocità e risorse
usate.
In pratica mi chiedo se esiste o esisterà  un compilatore che dato in
pasto del codice 
vb.net
 (o c#) restituisca un bell'exe senza
dipendenze, veloce, piccolo, e magari profumato di rose :-)
Si sfrutterebbe il lavoro fatto da Microsoft per "gerarchizzare e
astrarre" le caratterisitche del s.o...
Per quanto ne so i progetti di porting di .net su altre piattaforme
comunque si appoggiano su una CLR :-/
E' solo un sogno ?
Stefano "HappyMan" (Lago Maggiore - NO)
--
Personal Web 
http://www.sgr.info
Email happyman69 (at) 
libero.it

 termini di velocità e occupazione di memoria.
Adesso sparo un'idiozia :)
Mi pare che nell'SDK del framework ci sia proprio un exe che converte 
gli assembli in codice win32 nativo.
Cosa salti fuori e se poi non necessita veramente del FW non ne ho idea.
Prova a cercare ngen.exe: sembrerebbe che il FW sia comunque necessario, 
ma salta tutto quanto è la compilazione JIT.
Ciao

 dipendenze, veloce, piccolo, e magari profumato di rose :-)
Piccolo? Un exe monolitico per windows che inglobi tutto il codice delle
dipendenze non potrà mai essere imho "piccolo"! ;-)

gli assembli in codice win32 nativo.
ngen genera una immagine dell'assembly e te la mette nella Native
Image Cache, cioč in c:\windows\assembly
Questo procedimento permette all'exe di non usare la compilazione JIT
con il risultato di avere una prima esecuzione piů veloce ma la CLR č
sempre presente, almeno credo :-)
Il mio sogno č piů "impegnativo", avere un qualcosa simile a Delphi
che pur sfruttando la potenza della gerarchia .net generi un exe senza
dipendenze e che giri senza il framework installato, mi accontenterei
anche di qualche dll/ocx di runtime alla vb6 per intenderci ma non il
malloppone intrusivo di .net




Mai programmato in C++ ? :-)
Ho realizzato un software con 140 dialog box (alias form per farmi
capire), accesso al db via odbc, griglia con tutti i crismi, capacità
di stampa (purtroppo non ho l'anteprima a video ma prima o poi
l'aggiungerò), il tutto sta in 1.8 MB, poco più della metà di un ocx
di complessità media, e ho solo un exe.
Gira anche direttamente su cd senza necessità di setup, è veloce e
gira più che decentemente anche su un pc con un Pentium 200 Mhz e 32
MB RAM con Windows 98 (configurazione che resiste ancora tra alcuni
miei clienti più restii ad aggiornamenti hardware).
Si puo' fare tutto, gli strumenti li abbiamo, si deve solo verificare
quando ne vale la pena, sviluppare un programma in C++ richiede un
tempo quasi doppio rispetto a vb6/
vb.net
 :-)


sì, effettivamente è una cosa ambiziosa.....
si potrebbe pensare a un *qualcosa* che in fase di compile/linking vada a
vedere tutte le classi usate in un progetto e le includa nell'exe finale.
Supponendo che sia possibile, credo sia questo l'obiettivo, giusto?
però cosa succede che durante l'esecuzione, per un qualche motivo, DEVE
essere istanziato un oggetto di una classe che NON era stata presa in
considerazione.....
supponi un programma che fa qualcosa di ciclico: non dà problemi per un
milione di anni. Poi, ad un tratto, avviene un errore di run-time e deve
essere istanziato un oggetto per gestire l'errore (non ho idea di come si
chiami 'sta cosa in .NET)......cosa succede se nell'exe non è previsto?
questo nel caso di un errore run-time, ma potrebbero esserci mille casi,
credo......
questo è il mio dubbio.....no?
good coding!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

considerazione.....
La mia visione è purtroppo affetta dal mio background di sviluppatore
a basso livello, dove per esempio il late binding sviluppando in C++
(senza framework di mezzo come MFC ma solo con le API) non l'ho mai
preso in considerazione: se nel mio progetto di un milione di linee di
codice in solo caso devo instanziare una classe che fa una piccola
cosa ebbene il codice di quella classe ci deve essere e deve essere
linkata all'exe.
In realtà però questo è solo un aspetto, tutti i componenti/assembly
che realizzano i vari oggetti .net (datagrid, 
ado.net
 etc) potrebbero
essere resi disponibili nel vecchio modo OLE/COM e usabili similmente
come si fa in vb6, perdendo consapevolmente i vantaggi della CLR.
Ricordiamo però che solo una parte degli oggetti disponibili in .net
sono un qualcosa di "costruito" pesantemente (penso a 
ado.net
 e
datagrid), tutto il resto come textbox, labels, printdocument etc etc
sono "banalmente" risorse che puoi sfruttare con qualche API di
sistema.


 comunque si appoggiano su una CLR :-/
Penso che il futuro (e il presente) della programmazione vada proprio nel
senso opposto di quello che proponi tu... Un po' come se al posto di usare
windows fossimo rimasti in DOS e ogni programma si creasse una grafica simil
windows ogni volta...
            Ciao
                                                    Allanon
-- 
- SPAMKILLER
 L'indirizzo delle risposte é 
itlangv...@michele.sytes.net
 LASCIATE il NOSPAM fa parte dell'indirizzo :-)
  Per superare le impostazioni di protezione antispam scrivete
  nel testo del messaggio la scritta "SPAMKILLER"
Scusate il disturbo, ma non posso più di pubblicità

 tempo quasi doppio rispetto a vb6/
vb.net
 :-)
E un programmatore c++! ;-)
Ciao
[1] Ironico :D

 una grafica simil windows ogni volta...
Infatti hanno abbandonato com e il cosiddetto "dllhell" per tornare ad una
gestione delle librerie simil dos: ogni applicazione la sua directory... per
fare il setup basta copiare i files come si faceva in dos... e il registro è
stato abbandonato in favore di files.ini come si faceva in dos! ;-)

Dipende dalle MFC o ne fai a meno? ;-)
Ti dirň: non ho una posizione pregiudiziale nei confronti di MFC (in
giro trovi chi ne parla malissimo), semplicemente ho sempre preferito
l'approccio API-based :-) Diciamo che sono un programmatore assembler
mancato :-P


windows ogni volta...
Su questo invece non sono d'accordo, per me il paragone non regge..
Ciao 


 mancato :-P
In questo caso allora posso credere alle dimensioni ridotte del file... :-)

 astrarre" le caratterisitche del s.o...
Un GC sarà sempre necessario, pertanto un runtime non potrà mai mancare.
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Stefano "HappyMan" (Lago Maggiore - NO)
--
.A
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
Read my blog at:
http://www.ugidotnet.org/myprofile/blog/BlogReader.aspx?MemberID=4

 Stefano "HappyMan" (Lago Maggiore - NO)
--


quale.NET brilla di meno...
Grazie, in effetti non conoscevo ngen e ho trovato un miglioramento,
ma devo informarmi poi come distribuire l'exe insieme alla sua
"immagine" precompilata che trovo nella Native
Image Cache.
Per i record selezionati hai in linea teorica ragione, ma attualmente
la tabella che carico ha 2 colonne e 2 record :-)
Ciao 
Stefano "HappyMan" (Lago Maggiore - NO)
--


 Image Cache.
Attenzione: Non devi distribuire l'immagine precompilata, devi far girare
NGEN sulla macchina target in quanto NGEN mette l'immagine "JITtata" nella
native image cache del PC locale, attenzione inoltre che se alcune
condizioni vengono a mutare sulla macchina dove hai eseguito NGEN allora il
CLR ignora la copia nella cache e ritorna alla normale modalita' JITted (per
sapere quali guarda MSDN)
Da prove fatte mi pare che il guadagno sia circa del 10%, per eseguire NGEN
sulla macchina locale puoi utilizzare una custom action da inserire nel
programma di Setup.
HTH
-- 
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - 
http://www.ugidotnet.org
Read my blog at:
http://www.ugidotnet.org/myprofile/blog/BlogReader.aspx?MemberID=710

 Su questo invece non sono d'accordo, per me il paragone non regge..
Perché no?
Alla fine tutto quello che fai in windows lo potevi anche fare da DOS... I
programmatori hanno scelto di usare windows al posto di DOS per 2 motivi:
A) perché hanno capito che era la via che stava prendendo il mercato
B) perché potevano usare delle librerie messe a disposizione dal S.O. che
erano molto più avanzate di quelle di DOS.
...non di sicuro per le prestazioni...
Perché ora si passa a .NET?
A) perché é la via che sta prendendo il mercato
B) perché puoi usare delle librerie messe a disposizione che sono molto più
avanzate di quelle di quelle che avevi prima.
....
C) per una questione di portabilità del codice
D) manuteni... insomma manutenzione del codice...


D) manuteni... insomma manutenzione del codice...
Questo per me non è un punto di forza di .net. Puoi manutenere (?) il
codice solo se è scritto bene, indipendentemente dal linguaggio.


codice solo se è scritto bene, indipendentemente dal linguaggio.
Esatto: una capra rimarra' sempre una capra anche se usa .net.
-- 
ciao, hal

 Esatto: una capra rimarra' sempre una capra anche se usa .net.
Sacrosanto. Però è altrettanto vero che ci sono linguaggi che rendono
più semplice scrivere *bene* il codice (ed altri che o rendono più
difficile).


 codice solo se è scritto bene, indipendentemente dal linguaggio.
Certo...
Ma a me sembra molto più semplice e veloce scrivere del buon codice .NET.
Forse perché dopo aver fatto un assembly posso rilasciarne un'altra versione
e fare convire entrambe sullo stesso PC a zero fatica. Forse perché
nell'altra versione mi basta fare un Inherits per evitare di fare ogni volta
un interfaccia per ogni classe e simulare un'ereditarietà creando un istanza
della prima all'interno della seconda classe, forse perché fare una
collection fortemente tipizzata é un operazione da 2 minuti e non devo usare
arcani codici COM (-4) per wrappare la funzione _NewEnum (e non solo, ma
posso anche controllarla molto di più). Forse perché posso fare classi
ereditabili ed interfacce che contengano EVENTI e non devo s-cervellarmi per
trovare un modo di ritornare un evento da una classe "Plug-In" di cui a
priori ho solo l'interfaccia, forse perché faccio un Webservice o un DLL che
contiene la "logica" del programma e dopo preparo delle interfacce utente
via Web o via Windows Forms in poche ore, forse perché mi mancano quei 1000
stupidi limiti di VB6 tipo: non poter esportare dei "Type" da delle DLL,
ecc...
Certo tutte cose che puoi fare anche in VB6... Ma che sbattimento
risparmiato. :-)


nell'altra versione mi basta fare un Inherits per evitare di fare ogni volta
[cut sulle cose che fai]
Ammetto che se vuoi spremere VB6 per ottenere quanto scrivi usando
VB.Net fai prima, ma per il tipo di applicazioni che sviluppo
(definiamole "gestionali" su commissione per realtà specifiche) non ho
mai avuto la necessità di smanettare cosi' tanto (se non per farmi una
classe usando le API per i popup menu): alla fine devo solo
"banalmente" inserire/aggiornare/cancellare dei record in un database,
sfrutto delle classi che ho scritto nel 2000 che inizialmente
incapsulavano i metodi degli RDO, poi convertite per gli ADO (senza
dover ricompilare il resto dei programmi) e ora portate su 
ADO.NET
 in
modo tale da mascherarmi la complessità dei datatable e compagnia...Ma
a ben vedere il mio codice è di una semplicità notevole, senza dover
scomodare TUTTE le caratteristiche della oop :-)
Ciao :-)


 scomodare TUTTE le caratteristiche della oop :-)
Io ho un gestionale legato all'ambiente cartografico...
...partito 2 anni fa con certe esigenze.
...riaggiornato...
...ricorretto...
...creati 4 Plug-in (pagati a parte quindi non distribuiti a tutti)...
...ora é un'accozzaglia di codice...
...da un anno a questa parte mi sono detto che non avrei mai più fatto
programmi senza incapsulare TUTTO in classi per ottimizzare la manutenzione
del codice. Ho creato un generatore di codice per le operazioni ripetitive
(che mi fa rispiarmiare tranquillamente il 60% del tempo).


del codice. 
Questo lo capisci solo dopo aver programmato per un (bel) po' :-)
Quando ho iniziato nel 1996 con vb4 (in una software house di Milano)
io e i miei colleghi, tutti neo laureati in informatica, non avevamo
molta pratica di visual basic (che in facoltà non avevo mai quasi
sentito nominare) e all'inizio il codice scritto fu una vera
schifezza, anche a causa dei problemi dei vari ocx usati (true db grid
in primis) che ci obbligava a numerosi work around...
La pulizia "mentale" nello scrivere codice la si acquisisce solo con
l'esperienza :-)
Ciao e grazie per lo scambio di vedute


 Ciao e grazie per lo scambio di vedute
Grazie a te! ;-)


di VB6)?! :-)
L'unico vantaggio che hai, se vuoi lavorare ad oggetti con vb, e' che
vb6 *non e'* ad oggetti quindi devi forzare molte features che in
vb.net
 puoi realizzare lo stesso.
Pero', per lavorare bene ad oggetti avresti bisogno anche di poter
sovraccaricare gli operatori, ad esempio, e di disporre dei templates
(in questo pecca anche java, forse dovevano uscire con la 1.5, ma in
ferie ho trascurato di aggiornarmi su di esso).
-- 
ciao, hal

di VB6)?! :-)
Io tranne rari casi gli oggetti li creo via codice (.cls), per cui COM
o chi per lui lo vedo poco...
Ciao


 ferie ho trascurato di aggiornarmi su di esso).
L'overload degli operatori si può fare: in C#...
Il passaggio da 
VB.NET
 a C# é veramente minimo (e lo sai di sicuro anche
meglio di me) tant'é vero che esistono addirittura dei "traduttori".
(Citando F. Balena la differenza sta nei punto e virgola... :-)  )


Beh, dimmi che é poco... :-)
Dal punto di vista dell'OOP .net e' certo il benvenuto rispetto a vb6.
Peccato per i prerequisiti hardware e software :-(
-- 
ciao,
hal