Newsgroup: it.comp.lang.delphi
Titolo: Delphi8 vs Delphi7

Salve
sapete dirmi se applicazioni scritte con delphi 7 sono compatibili con
delphi 8?
Possono esserci problemi con le librerie Jedi e RXlib?
Grazie
-- 
Gilberto Marzuillo
Via Ceccano, 13
81100 Caserta
Italia
Tel. 
+39 0823351859
Fax 
+39 06233239522
Cell. 
+39 3476496431
Cell. 
+39 3287141100
web: 
www.marzuillo.com
e-mail: 
gilb...@marzuillo.com
icq: 35603715

 delphi 8?
non sono compatibili: cambiano componenti e relative proprieta' ed eventi,
quindi in buona sostanza vanno riscritte da zero.
Ciao, Sandro

 ha scritto nel messaggio
news:bv06qm$mmpr5$1...@ID-43509.news.uni-berlin.de...


> quindi non ci sarà un seguito per le applicazioni delphi 7 like?
esatto. Win32 e' destinato a sparire per decisione di Microsoft a favore di
.NET e, tra qualche anno, Palladium.
Ciao, Sandro

 ha scritto nel messaggio
news:bv0d01$mv1vq$1...@ID-43509.news.uni-berlin.de...


 Un applicativo in Delphi 8 girerà su Win32 con l'uso del framework vero?
si. Ho sentito gia' in giro lamentele a proposito di D8, ma non ho
approfondito la questione. Uno dei problemi riscontrati per certo (provato
personalmente) e' la lentezza complessiva dell'IDE e del compilatore, ma
d'altronde tutto cio' che ruota intorno a .NET e' pensato in prospettiva
futura: il framework sara' affermato tra un po' di anni, quando le macchine
a quel punto gireranno a 10 GHz e gli attuali 370 MB da installare come
framework saranno poco piu' che bruscolini.
Ciao, Sandro


Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)

 vero?
Esattamente. Le applicazioni potranno essere eseguite se nel sistema è
presente il .NET Framework. Il framework è scaricabile gratuitamente, ma
è auspicabile che nei futuri sistemi operativi sia già presente nel
sistema.
Ciao!


 sistema.
gia. Quale framework? Il 1.0? Il 1.1? quelli che verranno? con relative
patch? patch alle patch? hotfix delle patch alle patch? sappiamo come
"lavora" Microsoft.
Ciao, Sandro

 sistema.
Brrrrr, un brivido freddo lungo la schiena....
-- 
Ciao!
Marco Kregar
marco....@FirebirdSQL.it
www.FirebirdSQL.it
"over the bench the goat sings, under the bench the goat dies"
"Marco Breveglieri" <ma...@NOSPAMabls.it> ha scritto nel messaggio
news:WfTQb.285402$e6.11...@twister2.libero.it...


 sappiamo come "lavora" Microsoft.
Appunto, dov'è il reale problema?
Microsoft lavora in questo modo, lo fa con Win32, quindi se riesco a
lavorare ancora non vedo quale problema avrò con .NET: la storia non
cambia.


> Appunto, dov'è il reale problema?
"I" problemi, non "il" problema.
Ad esempio: tu distribuisci un applicativo con .NET 1.1 ; questi crea
malfunzionamenti vari in certe circostanze su una versione del sistema
operativo non patchata a dovere, il cliente bestemmia e tu non sai a che
santo aggrapparti, perdi ore per stabilire solo alla fine "da te funziona,
ma da lui no" e senza risolvere il problema; dopo due mesi M$ esce con il
.NET 1.1 SP 1 che risolve il problema dell'incompatibilita', il cliente non
riesce a scaricarselo (non ha adsl, oppure gli va lenta, o vattelapesca):
devi scaricarlo e portarglielo. Poi si scopre che il .NET 1.1 SP 1 non e'
compatibile con uno dei componenti di terze parti che stavi usando, e devi
ricompilare il progetto ex-novo, tornare dal cliente e aggiornargli
l'installazione. E via di questo passo.
Vuoi mettere - INVECE - l'assoluta stabilita' e semplicita' dell'eseguibile
monolitico fatto in Delphi x Win32 che, se progettato bene, funziona
indifferentemente da Win95 a XP?
Ciao, Sandro

cambia.
Si Marco, e' vero che la storia non cambia.
Pero' forse a noi sfugge il bailamme di dll e orpelli vari che uno
sviluppatore deve utilizzare se deve installarsi un'applicazione sviluppata in
VB o, peggio, Access. Versioni di dll, runtime di access, il tutto
rigorosamente diverso da macchina a macchia.
Spesso ci dimentichiamo che il nostro amato delphi ci da' queste comodita': io
nel mio setup distribuisco solo l'eseguibile, il db access, e l'MDAC ultima
release (perche' uso tbetteradodataset, senno' potrei andare su qualsiasi
macchina recente). E nient'altro.
Quindi, la storia non cambia si', ma non cambia con accezione negativa
(imvho).
:)
-- 
Morde. 
(
mo...@despammed.com
)
M-List di icld: 
http://it.groups.yahoo.com/group/icld/

 (imvho).
Sono d'accordo. Non vedo il motivo di tutte queste preoccupazioni che
vengono sollevate in questi giorni contro .NET basate al 99,9% su
congetture e non su applicazioni pratiche, se non per quanto riguarda
quei problemi che già sono presenti oggi e che il framework .NET tenta,
almeno concettualmente, di risolvere.


 Brrrrr, un brivido freddo lungo la schiena....
Vabbè signori, io non so più cosa dirvi. :-)


congetture e non su applicazioni pratiche,
Sottoscrivo, vedi ad esempio l'ennesimo thread su palladium nato in questi
giorni. Credo che il fattore ansiogeno faccia parte delle politiche
commerciali di M$ ah ah ah... ad esempio se io ti dicessi che entro un anno
win2k verra' pensionato, cosa penseresti?? Eppure, un mio collega mi ha
inviato questo link:
http://www.newsletter.duke.it/win/insider-198.shtml
Dove e' ben spiegato quali siano le intenzioni commerciali di M$ nei confronti
dei suoi sistemi operativi. Articolo ben fatto, ad esempio si consiglia di
rimanere il piu' possibile ancorati a win2000 anziche' xp, perche' (cito
l'articolo)
"Paul DeGroot, analista di Directions on Microsoft, consiglia invece alle
piccole e medie imprese di restare il più possibile su Windows 2000 e Office
2000 perché, a differenza di Windows XP e di Office XP, non richiedono di
essere attivati. "Mi rende nervoso sapere che, se per qualche motivo, i server
di attivazione non funzionano, non potrei reinstallare il mio sistema
operativo. Purtroppo sono delle cose che succedono e Windows 2000 non ha
questi problemi. Le aziende tendono ad utilizzare i prodotti per un periodo di
tempo maggiore rispetto a quanto viene previsto da Microsoft che, ovviamente,
non trae alcun profitto dal prolungamento del loro utilizzo e che guadagna
solo nel momento in cui vengono acquistati. Il loro obiettivo è quindi quello
di spingere il mercato alle migrazioni e per ottenere ciò, devono rendere
Windows Server 2003 la sola opzione disponibile sul mercato." 
Lo stesso articolo riporta questo link:
http://support.microsoft.com/default.aspx?scid=fh;[ln];lifewin
che indica chiaramente come tra 1 anno incominceranno i pensionamenti dei
windows 2000.
Come vedi, Marco , a volte il fattore ansiogeno e' piu' efficace di una
massiccia campagna commerciale (ricordo ancora quella del lancio di win95,
mastodontica!)
Ciao!!!


 bene, funziona indifferentemente da Win95 a XP?
La stabilità e la semplicità dell'eseguibile dipendono sensibilmente dal
compilatore e anche dal programmatore.
L'eseguibile monolitico è tale fino a mezzogiorno, dato che comunque
ogni applicazione Windows si appoggia comunque su un insieme infernale
di DLL esterne; qual è la differenza tra l'appoggiarsi ad un set di
librerie richiamando funzioni invece di appoggiarsi ad una serie di file
binari contenenti classi?
A mio avviso, paradigma di programmazione a parte, non c'è nessuna
differenza.
Tra l'altro, quali prove ci sono sul fatto che un'applicazione .NET
debba essere (INVECE) più instabile e complessa di un'applicazione
Win32?
Per quanto riguarda il funzionamento all'interno di sistemi operativi
differenti, non è possibile stabilire un fattore di portabilità assoluto
poichè dipende dalle librerie esterne utilizzate, tuttavia è certo che
ci sono maggiori garanzie di funzionamento di un programma che si basa
su una piattaforma maggiormente astratta rispetto al sistema operativo.
Proprio l'altro giorno ho installato un'applicazione Delphi su un
sistema NT 4 Server e non funzionava per via di una librerie di sistema
mancante che ho copiato dal mio sistema XP; il programma funziona, ma di
certo non si tratta di una soluzione logica e sicura al 100%.
Il fatto che ciascun professionista abbia acquisito una certa pratica
alla soluzione di un problema, spesso aggirandolo, non significa che il
problema sia sparito e che debba sicuramente moltiplicarsi.
In definitiva, mi appaiono oscure tutte le congetture che vengono
presentate senza riferimenti pratici a meccanismi di funzionamento del
framework .NET stesso, considerando che tali situazioni sono senz'altro
già tutte presenti al giorno d'oggi con le tecnologie attuali; si tratta
di problemi che il framework, per il modo con il quale è stato
concepito, cerca di porre una soluzione.
