Newsgroup: it.comp.programmare.win32
Titolo: [Teoria] Win32 su piattaforma .net

 L'avvento di .net puo' essere paragonato a questo evento passato ?

 L'avvento di .net puo' essere paragonato a questo evento passato ?
IMHO direi di si', non tanto per l'impatto sostanziale che avra
sulle applicazioni quanto piuttosto per l'inversione di tendenza che
aveva portato in auge il paradigma della programmazione per componenti
rispetto quella ad oggetti. Difficile dire dove Microsoft voglia
effetivamente puntare. Ci sono voci che vogliono un disimpegno su
COM+/MTS in favore di .NET/SOAP altre tendono al escluderle per
problemi di scalabilita' del CLR. Insomma siamo ancora in piena
trasformazione. Nei prossimi mesi avremo di sicuro un quadro migliore
della situazione.
Ciao,
Il Michett@
--

per gestione di dati via ODBC,
Tutte cose che rimarranno. Win32 non sparira' di certo (scommetto che
Win64 sara' molto simile), e ODBC e' l'unico modo stabile di accedere
a DB eterogenei (DAO, RDO, ADO e cosi' via e' gia' molto se durano un
anno uomo)
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

Personalmente credo tantissimo in .NET, sono convinto che semplificherà
parecchio le cose a noi sviluppatori, mettendoci a disposizione, finalmente,
dei linguaggi semplici e veramente ad oggetti (c#, 
VB.NET
), un Framework
adeguato, un IDE superbo (osservate gli screenshots se avete dubbi), un
accesso ai database comodissimo 
ADO.NET
Bisogna dire che l'intera struttura di .NET è comunque destinata
all'ambiente Win32 per cui le conoscenze in proposito non saranno certo un
male, al limite, risulteranno superflue...
Credo anche che chi ha maturato una certa esperienza con le VCL e Delphi in
generale, si troverà benissimo e gioirà di poter disporre di un IDE stabile,
visto che quello di Delphi spesso fa i capricci, mentre l'IDE di visual
studio è in genere più stabile...
Una domanda: avete letto l'evoluzione prevista per COM? pare che IUnknown
diventerà IComponent.
Credo che chi conosce le VCL abbia già capito tutto...
ciao, Davide.

 Sito Papero -> 
http://utenti.tripod.it/papero
Win64 e' la semplice estensione di Win32 per Windows 2000 che sfrutta
i nuovi processori Intel a 64bit (Itanium). Non ci saranno grossi
cambiamenti a parte la ricompilazione del codice per sfruttare
l'incremento della spazio di indirizzamento dati che un processore
full 64bit offre.
Al contrario, uno dei problemi che presto ci troveremo di fronte
ha il sapore dell'amarcord. In un processo potra' girare solo codice
con lo stesso spazio di indirizzamento dati. Che si traduce in un bel
problema con quello a 32bit fornito da terze parti e caricato
dinamicamente! Oltre al windowing 16/32 adesso ci si aggiunge un
32/64. Un chicca per i puristi...ma funzioneranno i 16bit????
Non che me ne importi piu' di tanto ma spero ci risparmino un
indegno 16/64 :-6 (anche se alla Microsoft sono capacissimi di
propinarti un 16/32/64)
Quando su MSDN leggi:
 [...]
 ROBERT HESS: Are we providing a thunking mechanism to get across that
 barrier?
 KYLE MARSH: We're not going to allow ... Well, we supply the common
 RPC to do the translation or the move between the two processes. We don't
 allow the mixing of an address space in a single process. So if you have
 a 64-bit application, all of its components must be 64-bit-the DLLs, any
 in-proc COM-they must be 64-bit. Another process can run on the system as
 a 32-bit process, using what we call the WOW layer, the Windows On Windows
 64 layer, which allows 32-bit processes to run on a 64-bit processor and
 64-bit Windows. So we'll handle the, it's not so much a thunking, but
 we'll handle the translation between those in our published methods.
 ROBERT HESS: So it sounds like the best attitude then is to try to
 embed COM as deeply as possible within your application, so you're exposing
 COM interface, isn't that why you don't need to worry about it quite as
 much?
 KYLE MARSH: Yeah, you don't need to worry, we'll do a lot to make it work.
 Another hint there is if you make most of your stuff out-of-proc, your
 COM components so they could run out, then you have a choice of deciding
 whether it has to be 64 or 32, and you can stair-step your schedule
 somewhat.
 If it has to be an in-proc thing, then you must make it 64-bit right now,
 in order to move forward. So you can make decisions about stair-stepping
 and development a little that way too.
[...]
...ti rendi conto che a breve ci saranno ulteriori CASINI (come se quello
gia' abbondantemente pagato alla camera dei deputati non bastasse :^)
Ciao,
Il Michett@
--
Vedi intervista a KYLE MARSH (Software Design Engineer - Microsoft
Win64 project team): 
msdn.microsoft.com/theshow/Episode005/default.asp

studio e' in genere piu' stabile...
... mentre i programmi fatti con Visual C++ e MFC sono delle vere rocce, e
Visual Studio stesso ne e' un esempio

 Visual Studio stesso ne e' un esempio
Alla Borland e meglio che si mettono al lavoro perche .NET rischia
di seppellirli! BTW qualcuno di voi ha testato quella lumaca di
JBuilder 4? Vorrei proprio vederlo in faccia chi ha assegnato il
primo premio al quel RAD java..... :-6
Ciao,
Il Michett@
--

> Alla Borland e meglio che si mettono al lavoro perche .NET rischia di
seppellirli!...
Giusto!
In effetti, le comodità come gli insiemi Screen.Forms, TComponent.Components
e TWinControl.Controls, le avranno anche introdotte alla Borland, ma pensare
di poterne disporre anche in Visual C++, C# o VB mi fa credere che .NET ci
cambierà la vita...
Per non parlare della gestione degli eventi, ho studiato qualche frammento
di codice C# ed ho letto cose del tipo:
Bottone1.AddEventHandler(MiaFunzione);
YEAH!
Davide.

 Davide.
La gestione di eventi e deleghe e' sicuramente uno degli aspetti piu'
interessanti del C#. Peccato che non abbiano introdotto i potentissimi
template dal C++ cosi' come hanno elegantemente trasformato i puntatori
di funzione con le delegates, sarebbe stato perfetto!
Ciao,
Il Michett@
--

> > Bottone1.AddEventHandler(MiaFunzione);
ERRATA CORRIGE:
Bottone1.OnClick += new EventHandler(this.MiaFunzione);
MI CHIEDO:
il += implica che potrò associare "enne" gestori di evento (di tipo
EventHandler) allo stesso evento (in questo caso, l'OnClick)??
Per quanto riguarda i templates, certo, sarebbero stati comodissimi, anche
se disponendo di un FrameWork REALMENTE ad oggetti, la loro utilità
diminuisce... Es. la classe pila di interi, diventa una pila di oggetti, per
cui che ci metta dentro interi, stringhe o eventi (WOW!), l'implementazione
non cambia...
Ciao, Davide.

 non cambia...
Questo e' sicuramente vero!! ;)
Ciao,
Il Michett@
--

OK! è tutto bellissimo!
Ma secondo te (VOI), io che avevo intenzione di dedicarmi, nei prossimi
mesi, ad MFC, ADO, COM(+), cosa devo fare?
Investire troppo tempo nelle MFC in particolare mi pare insensato, dal
momento che il nuovo Framework le rimpiazzerà completamente.
Certo, l'esperienza non fa mai male ma forse sarebbe meglio dedicarsi da
subito al framework .NET, al c#, 
ADO.NET
 e simili...
Secondo voi, il fatto che sia una beta (quindi soggetta a tanti cambiamenti
per definizione), rende questo discorso e lo studio della piattaforma .NET
in genere prematuro?
Il bello è che nei prossimi mesi sarò impegnato nello sviluppo di diverse
applicazioni e dovrò usare la tecnologia disponibile oggi, visto che Visual
Studio.NET sarà rilasciato, forse, a fine 20001.
Ciao, Davide.

 Studio.NET sarà rilasciato, forse, a fine 20001.
...addirittura 18.000 anni gli ci vorranno ? ;-)))
Massimo

 Massimo
ROTFL
la mia, avrebbe potuto essere una battuta, ma è stato un errore!
Ciao.


Ciao,
Il Michett@
--

propinarti un 16/32/64)
Scommetto che faranno un emulatore a 32 bit. Al suo interno conterra'
l'attuale emulatore a 16 bit.
la compatibilita' con l'8088 e' un must a cui Itanium non potra'
rinunciare :-(
