Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] Windows basato su dotNET: una minaccia? <g>

Salve,
Riflettevo su quanto detto da M$ riguardo basare Windows su dotNET...
quindi ad ogni aggiornamento del framework dovremo reinstallare Windows?
Opinioni?
Andrea

 ha scritto nel messaggio
news:bl90op$9egrp$1...@ID-170738.news.uni-berlin.de...

Ciao a tutti :)
E perche mai si dovrebbe reistallare Windows ?
-- 
MAX
http://www.birreonline.net
Chi beve birra campa cent'anni

 E perche mai si dovrebbe reistallare Windows ?
Pensaci un attimo... windows interamente basato su dotNET... il che
significa aggiornare il "core" ma siccome il core č tutto dotNET, bisogna
scaricare il Windows compilato per quella versione. Ci pensi? ^_^
Andrea

 ^_^
e rispetto ad adesso, che cosa cambia? :-)
--
Salutoni
Sergio

 ha scritto nel messaggio
news:bl91cs$9djmm$1...@ID-170738.news.uni-berlin.de...

Be ma adesso si installa una SP che non ti fa reinstallare il computer, idem
per .NET, nuovo framework, si installa, si reboota e via...


 via...
Assolutamente no.
Windows compilato con una versione precedente del framework non
funzionera' con la nuova versione. Ergo bisognera' avere il Windows
compilato per quella specifica versione... sai che divertimento...
Andrea

  e rispetto ad adesso, che cosa cambia? :-)
Cambia che ora, sebbene sia quasi una reinstallazione, non devi
avere un Windows specifico per supportare una certa versione delle DLL, a
meno di non volerne usare funzioni specifiche.
Andrea

 ha scritto nel messaggio
news:bl92vj$9bjkl$1...@ID-170738.news.uni-berlin.de...

Stante la situazione attuale, non e' esatto perche' la medesima assembly, e
addirittura l'intero framework, puo' coesistere in piu' versioni diverse
sullo stesso sistema e ciascun programma .NET da essa dipendente, se non
specificato diversamente, utilizza la stessa versione contro il quale era
stato compilato.
Ma a parte questo, mi sembra un po' presto per dare giudizi assoluti su
"funzionera'" o "non funzionera'", quando nemmeno si sa come verra'
implementato il tutto...
Ciao
-- 
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Ciao
Ciao
Andrea

 compilato per quella specifica versione... sai che divertimento...
Aggiorni il framework ma non il numero di versione ad esempio.
D'altronde anche oggi quando scarichi una SP ti viene sostituito metà S.O.


 scaricare il Windows compilato per quella versione. Ci pensi? ^_^
Hai installato la patch per il worm "Blaster"?
Allora hai già aggiornato il core di un windows "COM"...
Non credo che windows sarà mai COMPLETAMENTE .NET, come ora non é
COMpletamente COM.
Però probabilmente le parti COM verranno sostituite con parti .NET
Comunque la previsione di un windows "quasi" completamente .NET era prevista
per fine 2004, ma pare sarà posticipata al 2006.
                        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à

 Beh, se il buon giorno si vede dal mattino... <eg>
Allora sarà un biongiorno!!! :-)


per fine 2004, ma pare sarà posticipata al 2006.
Poi ci vorranno ancora 4 o 5 anni di service pack per renderlo
funzionante <g>
-- 
ciao, hal

 funzionante <g>
Più che altro si sono accorti che non esistevano ancora PC in grado di far
girare un Windows ""quasi" completamente .NET": probabilmente prevedono che
prima del 2006 non saranno ancora diffusi i PC  a 10GHz con 100GB di ram e
1TB di disco rigido! :P

 COMpletamente COM.
sara' NETtamente COM ? :)

 sara' NETtamente COM ? :)
ROTFL! :D

 sara' NETtamente COM ? :)
Ahahahahahahahahhhhh!!!!
ROTFL


 ha scritto nel messaggio
news:bl9c31$9jhpm$1...@ID-51318.news.uni-berlin.de...

A parte la battuta,
penso che la Microsoft deve iniziare a preoccuparsi.
COM presumo è l'apoteosi del declino.
COM deve essere registrato.
.NET non è esente da COM.
In considerazione che a clienti cominciano a dolere i zipidè e iniziano a
mollare Windows, e presumo COM,
per passare a Linux, conosco solo che è un sistema operativo.
Linux utilizza componenti COM ?
Se no, la continuazione è in salita.
Spero che la Microsoft non ostacoli l'utilizzo di .NET sotto Linux, anzi
aiuti, anche se ho capito riguarda solo C#,
altrimenti non solo perde terreno su Windows, ma rischia di mettere in crisi
tutti i convertiti a .NET
Ave
giuseppeD

 aiuti, anche se ho capito riguarda solo C#,
Non proprio, il progetto Mono (
www.go-mono.com
) include anche un compilatore
mbas cosi' definito
"MBAS is a CIL compiler for the Visual Basic language, an extended version
of VisualBasic.NET. It's based on the MCS compiler and still in heavy
development, though many language features are already supported."
Credo che MS abbia tutto l'interesse affinche il .NET framework giri anche
su Linux e quindi non ostacolera' (anzi...) il progetto...
HTH
-- 
Corrado Cavalli [Microsoft .NET MVP-MCP]
UGIdotNET - 
http://www.ugidotnet.org
Weblog: 
http://www.ugidotnet.org/710.blog

> E perche mai si dovrebbe reistallare Windows ?
Beh... se si vogliono ottenere delle buone prestazioni bisogna eliminare
quello che ora e' il livello API, e includere direttamente in quello che
ora e' l'albero delle classi .NET il codice che prima veniva richiamato
dallo stesso. Credo che fosse questa l'intenzioni di Microzozz... Almeno
cosi' si ottenevano prestazioni un po' migliori, anche se 'sti GC, IL e
JIT ancora nn mi vanno giu', e neanche al mio processore! :)
Forse e' solo una mia idea,ma se cosi' fosse un eventuale SP sarebbe
MMOOOOOLTO pesante, e avrebbe grossi rischi per il sisetma!!!!
Vabbe' che se MZ avesse problemi col pagare i danni lo Slammer l'avrebbe
gia' xlomeno duramente colpita.... xo' una cosa cosi' nn credo la
rischierebbe....
Bah... cmq ciao a tutti!
DisgustingAngel
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


--
.A
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
Read my blog at: 
http://www.ugidotnet.org/4.blog

 giuseppeD


 si passa il termine) VB6... :-))
[SNIP]
Inoltre il "core" del framework stesso, gia' oggi, viene compilato in nativo
all'atto dell'installazione


 nativo all'atto dell'installazione
E se cambio scheda madre e processore?


non provato, ma potrebbe anche continuare a funzionare: il JITer mette le
compilazioni in una cache,  ed al caricamente di un assembly controlla se
esiste già una copia JITtata, nel qual caso controlla che sia ancora valida.
In sua assenza (non esiste o non è + valida), rieffettuerà la compilazione.
Citando una (vecchia) pubblicità: "I Love this game!" :-)


 che sia ancora valida. In sua assenza (non esiste o non è + valida),
Forse ho capito male... non si parlava di "core" del framework compilato in
fase di _installazione_? Assomiglia molto alla scelta del kernel sotto
linux. Una volta scelto te lo tieni finchè non ricompili... la cosa non è
automatica...
Ora mi chiedo se tale "core" non funzioni più lentamente in caso di cambio
radicale di piattaforma o se addirittura non spari fuori degli errori in
caso di assenza del supporto di istruzioni specifiche?

 ha scritto nel messaggio
news:blbcun$24fm$1...@half.spin.it...

Perche' ora se cambi scheda madre e processore i programmi compilati in
nativo smettono di funzionare? o ti sei mai posto il problema che non
fossero ottimizzati per il processore nuovo?
Ciao


 non fossero ottimizzati per il processore nuovo?
Io si infatti di norma ricompilo _almeno_ il kernel sotto linux o scarico i
binari ottimizzati per windows: mica tutti sono distratti! ;-)
Analizziamo l'andamento di questo ramo del thread: si afferma che .NET è
superiore in velocità dato che viene compilato in fase di installazione
(l'unica ragione valida per farlo imho è l'ottimizzazione del codice per la
specifica piattaforma oltre _forse_ ad una dipendenza da COM [spero di no]),
chiedo se ci potrebbero essere di problemi _almeno_ prestazionali in fase di
cambio di piattaforma hardware del PC (cosa piuttosto facile in questo
periodo), mi si risponde che l'ottimizzazione non ha importanza! :P


ripeto: non ho provato... In ogni caso, AFAIK il concetto di "compilazione
nativa" nel senso statico del termine non esiste quando si parla di .NET;
quello che avviene è una compilazione JIT di tutti gli assembly caricati in
memoria ed eseguiti. Il framework stesso non è compilato, ma JITtato in fase
di installazione. Nulla ti impedisce, infatti, di usare un decompilatore
(ILDASM, Reflector, Anakrino) per ottenere il sorgente del framework (prova,
ad esempio, con mscorlib.dll). Ecco perchè (ripeto: pur non avendo provato)
il framework potrebbe "sopravvivere" ad un cambiamento di HW, e _senza_
penalizzazioni prestazionali.


 periodo), mi si risponde che l'ottimizzazione non ha importanza! :P
Non ho detto questo, pero' facevo notare che quando oggi installi Windows o
un qualunque software per Windows, scritto con il piu' performante dei
linguaggi e compilato con il compilatore piu' cazzuto, nella maggioranza dei
casi sei certo che *non e'* ottimizzato per la tua piattaforma specifica,
perche' e' stato compilato in qualche scantinato buio a Redmond o a casa
mia... che cosa cambierebbe rispetto a questa situazione? in meglio il fatto
che almeno il primo setup viene ottimizzato, in peggio nulla, perche' al
massimo devi ricompilare o procurarti i binari ottimizzati.
Per inciso, mi stai dicendo che e' possibile scaricare il kernel di Windows
ottimizzato per vari processori? se e' cosi', allora si', faccio parte dei
distratti perche' lo ignoravo allegramente... dove, di grazia? :-)


 ad esempio, con mscorlib.dll).
In questo caso pero' penso tu lo possa fare sulla versione IL di
mscorlib.dll, che e' sempre presente, non su quella "jittata"
Ciao


 di grazia? :-)
Fai parte dei distratti perchè non leggi bene ciò che scrivono gli altri:
"di norma ricompilo almeno il kernel sotto linux" o "scarico i binari
ottimizzati per windows"; non ho parlato di kernel ottimizzati di windows io
anche se non sarebbe male: nel GB di pattume che accompagna le ultime
release di windows potevano includere anche 200-400MB di dll ottimizzate per
i vari processori tanto non se ne accrogeva nessuno con gli hard disk
attuali! ;-)

 penalizzazioni prestazionali.
Le mie sono curiosità... non ho tempo di mettere su un ambiente di prova
anche se sarebbe interessante vedere i risultati di chi magari per caso ha
provato. Per il momento .net non interessa minimamente il mio core
business... se le cose cambieranno o mi verrà richiesto da un cliente
_pagante_ vi farò sapere. ;-)


yup! E' quello che in Rotor è chiamato "PAL" (Platform Abstaction Layer): in
un incontro con i PM del CLR, li ho visto modificare "al volo" il PAL per
aggiungere una istruzione al set di IL e modificare CLR e JITter per
riconoscerla e compilarla nativamente... Uno spettacolo!



AFAIK MS non è contraria all'open source in sè, ma alla licenza GPL.


 AFAIK MS non è contraria all'open source in sè, ma alla licenza GPL.
Per questo il codice viene mostrato solo _ora_ e _parzialmente_ a ristrette
commissioni governative: mi chiedo se suddette commissioni proveranno a
compilare il codice per assicurasi che le dll risultanti corrispondano
veramente a quelle in circolazione! ;-)


ceh, che io sappia il sorgente di Windows _dovrebbe_ essere disponibile
anche alle università, anche se non ne conosco le modalità di richiesta.
Rotor, invece, è liberamente scaricabile/modificabile dal sito MS, e
compilabile su Windows e FreeBSD
AFAIK l'idea di MS sul "codice aperto" è: "io te lo faccio vedere, ma tu non
lo usi per scopi commerciali, perchè la ricerca per produrlo l'ho pagata
io"...


 ottimizzati per windows"; non ho parlato di kernel ottimizzati di windows
io
Allora perdonami ma sei tu quello che non leggi bene: la premessa parlava
di Windows stesso basato sul framework .NET (quindi per quanto mi riguarda
si parlava di kernel o di qualcosa di molto vicino, scritto in .NET) e in
questo ramo del thread era sorta la questione "... questi GC, JIT ecc. mi
piacciono poco", dove Andrea faceva notare che il JIT "viaggia" abbastanza,
e io che in un Windows con il core .NET, il core stesso probabilmente
verrebbe anche jittato subito e quindi "viaggerebbe" ulteriormente.
In questo senso, il discorso del cambio hardware mi sembrava poco pertinente
peche' gia' adesso, come mi confermi, non puoi procurati il core in C++ di
Windows ottimizzato per il tuo sistema (e siamo d'accordo sarebbe bello),
quindi non vedo come la compilazione in fase di installazione di questo
ipotetico Windows possa peggiorare la situazione...


 situazione...
Ma tu te l'immagini i tempi di aggiornamento/installazione del sistema se
l'OS si ricompila da solo integralmente ogni volta che cambio hardware? Il
mio dubbio, pertinente o meno, era proprio sull'esistenza di tale
automatismo, compatibilità con cambi di schede madri/processori! ;-)
In più se devo dirla tutta ogni strato software aggiunto (specialmente in
caso di sistemi operativi) rallenta le prestazioni e consuma risorse: invece
di snellire e ridurre in microsoft si aumentano le righe di codice e gli
strati di astrazione. :-(

Nessun problema, visto che nella native image non ci sono i metadati le
assemblies originali (in IL) _devono_ essere comunque presenti sulla
macchina percui nel caso l'immagine non sia più valida il .NET framework
passerà automaticamente alla versione "non jitted", uno dei vantaggi delle
native image è quello del page sharing, se vuoi saperne di più su NGEN ecco
un link interessante 
http://blogs.gotdotnet.com/jasonz/


 E se cambio scheda madre e processore?
Boh, ti dirò:
io non avevo .NET, ma avevo ancora un windows 2000 senza SP e una partizione
Linux.
Cambiata MB e CPU non funzionava più niente (salvo Lilo)!
E' vero che ti parlo di windows 2000 senza SP e Red Hat 6.0 ed é passata un
po' d'acqua sotto i ponti, però mi sa che il problema non é di certo il
framework...


 E' vero che ti parlo di windows 2000 senza SP e Red Hat 6.0 ed é
Anche con l'ultimo SP non risolvi... se il controller del disco cambia e non
č supportato win2k non parte e ti da schermata blu! :-(