Link alla notizia: http://news.hwupgrade.it/14279.html

Qualche giorno fa si è tenuta una chat pubblica in cui Microsoft ha rilasciato alcuni dettagli relativi alle caratteristiche degli elementi di rete nel prossimo sistema operativo Longhorn

Click sul link per visualizzare la notizia.

davvero ottimale :)

Originariamente inviato da Fabio Boneschi
La speranza è ovviamente che il PnP sia realmente efficace e non esponga a pericolosi rischi come accadde per il predecessore.

Come non citare questo passo. Spero anch'io che questa volta venga scritto in maniera robusta.

>seconda metà del 2006

che ritardo

ehm...però samslaves ricorda che questo OS avrà differenze paragonabili al passaggio Win98->XP cioè IMMANI. Ogni punto del sistema è stato modificato.

Ti dico alcune parti

GDI+ Eliminata, ora tutto viene disegnato dall'hardware tramite le DX chiamate WGF 1.0
Tutto il sistema operativo è basato sul .NET Framework garantendo una maggiore interoperabilità fra sistemi.
Nuovo File System simile ad un motore SQL (che verrà introdotto poco dopo in maniera ufficiale, ma sarà disponibile in beta anche a chi prende Longhorn all'uscita)

E taaaanto altro ancora

Megasoft il paragone mi sembra forzato. Da Windows 98 a NT 5.x (comprendo quindi anche il 2000) è cambiato pressoché tutto, si è avuto veramente quel salto di qualità che serviva.
Questo lo vedo più come un'aggiornamento dell'architettura, considerando anche, che alcune parti [quelle veramente rivoluzionarie] non saranno pronte con il lancio ufficiale.

Quoto Hal per quanto riguarda la notizia della disponibilità di alcune delle feature principali del nuovo OS all'atto della sua uscita,e sì, se non sbaglio anche il file system non sarà pronto per allora.

Per quanto riguarda poi l'attesa e il ritardo di questo sistema operativo.. beh sinceramente non mi preoccupo più di tanto, più tempo richiederà la sua uscita più tempo sopravviverà l'attuale XP che sinceramente per quello che faccio con Win basta e avanza :)

Saluti!

Sì ma una volta tanto sembra che mamma M$ stia lavorando come si deve... intendiamoci però che io passerò a longhorn solo quando usciranno tutte le cose piùinteressanti, ed il nuovo file system è solo un esempio...
Però con una 6800GT non lo potrò usare vero (maledetti WGF... :muro: )

Se per parti rivoluzionarie intendi WinFs... a me non pare poi così sta gran rivoluzione rispetto a quel che fanno Indigo e Avalon...

...personalmente...aspettero' il service pack 1...;-)...

Mhn...Hal2001 non è un aggiornamento dell'archittetura è proprio cambiare il concetto di programmazione sotto Windows.

1) A parte il kernel e poche altre parti sensibili è tutto fatto e basato sul .NET Framework e questo è integrato con il SO a differenza di come è ora (ovvero un ADD-ON opzionale). Questo garantirà la famosa interoperabilità fra software completamente diversi. (ex. Io faccio una parte del codice di un soft in Delphi perchè sono esperto in questo e un'altro membro della mia società mi da una mano aggiungendo del codice in VB.NET. Tutto questo senza avere i minimi casini di DLL come si hanno ora :D)

2) Scompariranno le GDI+, ovvero il motore di disegno attualmente usato in Windows per passare alle WGF e all'elaborazione hardware. Questo permette di avere fronzoli grafici a manetta senza rallentare per niente il sistema operativo dato che la CPU non farà più operazioni di disegno.

3) WinFS sarà disponibile in beta insieme al LongHorn e si potrà installarlo già da allora ed è anch'essa una rivoluzione. Sarà come usare Google in locale...ricordiamoci che fin'ora la ricerca è fatta tutta da Findfirst...findnext (chi è programmatore capirà :D)
4) Indigo cambierà il concetto di Webservice integrando un nuovo modo di concepire il web, un web interattivo che utilizzerà appunto il .NET Framework.

è un cambiamento davvero radicale, non è un mero aggiornamento :D

Ok volevo cancellare questo inutile messaggio ma non riesco, approfitto per chiedere lumi su come fare.

:)

Originariamente inviato da riva.dani
Sì ma una volta tanto sembra che mamma M$ stia lavorando come si deve... intendiamoci però che io passerò a longhorn solo quando usciranno tutte le cose piùinteressanti, ed il nuovo file system è solo un esempio...
Però con una 6800GT non lo potrò usare vero (maledetti WGF... :muro: )

LongHorn richiede una scheda video DX9.0b compatibile quindi la tua scheda andrà perfettamente :D (potessi tenerla io una 6800GT ç__ç)

Originariamente inviato da riva.dani
Però con una 6800GT non lo potrò usare vero (maledetti WGF... :muro: )

Credo che richieda WGF 1.0 e la tua scheda ci rientra perfettamente essendo niente altro che le Dx9. Le DX Next saranno la versione 2.0 delle WGF, con pixel e vertex unificati, inutili per una semplice interfaccia grafica.

Oddio mica ho detto che sarà XP con una nuova calcolatrice :p

Quando dico che sarà un aggiornamento dell'architettura esistente, mi riferivo al fatto che tutti questi miglioramenti (o quasi) li potremo assaggiare anche nell'attuale OS di Microsoft. Il mio discorso era da prendere in questo senso. Il punto due però cancellalo completamente, sei un illuso se credi veramente che la cpu sarà completamente sgravata dai calcoli degli effetti grafici :D

Originariamente inviato da Hal2001
Oddio mica ho detto che sarà XP con una nuova calcolatrice :p

Quando dico che sarà un aggiornamento dell'architettura esistente, mi riferivo al fatto che tutti questi miglioramenti (o quasi) li potremo assaggiare anche nell'attuale OS di Microsoft. Il mio discorso era da prendere in questo senso. Il punto due però cancellalo completamente, sei un illuso se credi veramente che la cpu sarà completamente sgravata dai calcoli degli effetti grafici :D

La speranza è l'ultima a morire. :sofico:

>Sì ma una volta tanto sembra che mamma M$ stia lavorando come si deve...

Quante volte l'ho sentita sta frase dal 94 ad oggi...

Originariamente inviato da ShinjiIkari
>Sì ma una volta tanto sembra che mamma M$ stia lavorando come si deve...

Quante volte l'ho sentita sta frase dal 94 ad oggi...

Evitiamo flame e bruciacchiature dai. Non sei contento con Microsoft? Butta nel cesso Windows e usa Linux, FreeBSD, BeOS o MacOS o cosa preferisci, ma BASTA. non sopporto più le persone che hanno come professione accendere flame. :sofico:

cosa intendi?

Probabilmente ora che uscirà useremo questi HD ad un prezzo accessibile (si spera).

http://www.digit-life.com/news.html?114951

Originariamente inviato da k-Christian27
Probabilmente ora che uscirà useremo questi HD ad un prezzo accessibile (si spera).

http://www.digit-life.com/news.html?114951


quelli sono 4 HD da 250gb messi insieme.

Io + che altro spero che la compatibilita' all' IPv6 porti finalmente ad una migrazione verso questo standard

Non credo che sarà una grande rivoluzione..sia perchè nell'OS mancheranno dei pezzi importanti sia perchè ho molti dubbi che alla microsoft faranno un testing adeguato che risolva l'installazione su tutto il parco macchine mondiale..un pò come è accaduto con win xp insomma.
Secondo me bisognerà aspettare un rodaggio lungo quantomeno quanto quello di win xp se non di più..inoltre bisognerà aspettare l'OS completo con tutte le features per cui è stato creato....ci vorranno anni insomma.

Inoltre bisognerà vedere quanto sarà ergonomicamente fruibile...me ne frega assai di winFS e del motore grafico se il sistema operativo non funziona o è organizzato male o chissà che altro.

Quando uscì OSX nella versione 10.0 seppure testato a fondo su un parco macchine limitatto,aveva dei grossi problemi che poi furono migliorati in seguito e che adesso possiedono le stesse features di longHorn "solo" nella versione 10.3/10.4.Ho grossi dubbi quindi che microsoft abbia fatto lo stesso percorso internamente all'azienda e che fornirà un prodotto finito e rock solid.

Credo insomma che win XP sarà lo standard per molto tempo in questo caso.

anni? WinFS esce esattamente pochi mesi dopo LongHorn.
Cmq te lo dico io, in massimo 1 anno dall'uscita di LongHorn avremo un buon 60 % di macchine Windows XP che passeranno al nuovo OS.

Originariamente inviato da Megasoft
anni? WinFS esce esattamente pochi mesi dopo LongHorn.
Cmq te lo dico io, in massimo 1 anno dall'uscita di LongHorn avremo un buon 60 % di macchine Windows XP che passeranno al nuovo OS.

Le cifre che ho sentito io da parte di MS parlano di cinque anni per raggiungere il 50% del mercato OS.

dicevano lo stesso con Windows XP e dopo 2 anni era gia la parte maggiore del parco PC mondiale. :)

Originariamente inviato da Megasoft
dicevano lo stesso con Windows XP e dopo 2 anni era gia la parte maggiore del parco PC mondiale. :)

Solo due? Davvero?

Mi incuriosisci, hai qualche link a qualche statistica? Perche' pensavo molto meno.

il sistema per funzionare chiede troppo
un sistema non è scalabile come i giochi
mi pare assurdo che uno riesce a fare girare un gioco ma non riesce a fare funzionare un SO


io mi ricordo una lamentela di un programmatore di basic
all'uscita di .net
affermava che le applicazioni erano + lente di un 20-30 %


winfs e come google ....
ma per caso qualcuno fara ricerche facili sul mio Pc dalla rete?
:sofico: :D :D

è un linguaggio interpretato il .NET, ma le differenze prestazionali con i linguaggi nativi è dell'ordine del 5 % totale, mica 10,20 xD

si ma della maggior parte degli utenti con xp quanti lo compreranno avendo xp funzionante?


quanto costerà 300€ ? :rolleyes:

Originariamente inviato da Megasoft
è un linguaggio interpretato il .NET, ma le differenze prestazionali con i linguaggi nativi è dell'ordine del 5 % totale, mica 10,20 xD

Scusami, perche' e' la seconda volta di fila che dico il contrario di quello che dici tu :)

.NET non e' interpretato. Il CLI viene tradotto in codice nativo prima di essere eseguito da una specie di JIT compiler, oppure addirittura al momento di installare l'applicazione.

Alcuni dei problemi prestazionali della piattaforma .NET sono dovuti al Garbage Collector che e' eseguito nello spazio utente, mentre se fosse eseguito a livello kernel avrebbe accesso ad alcune ottimizzazioni altrimenti impossibile che ridurrebbero questo gap prestazionale.
A quanto so, neppure in LH il GC sara' eseguito a livello kernel, ma in futuro e' probabile che questo passo venga fatto.

Ne approfitto per riportarti questo a parziale prova di cio' che hai affermato sulla diffusione di WinXP:


XP SP 2 (Build 2600) 539,558 37.71 %
XP SP 1 (Build 2600) 517,054 36.14 %
XP (Build 2600) 200,037 13.98 %


http://www.steampowered.com/status/survey.html

immagino che tutti voi naturalmente siate in possesso di una copia di win xp originale (e bello scatolato) così come non ho dubbi abbiate posseduto gli altri precedenti sistemi sempre con scontrino fiscale al seguito.....bravi bravi....

Ma scusa mi sembra logico che sia tradotto da un compilatore JIT prima di essere eseguito. Ma se tu guardi il file .EXE non è altro che ibrido allo stesso livello di JAVA. Non sono veri e propri eseguibili, ma mero codice da interpretare quando verra avviata l'applicazione(e se ricordo bene il JIT non compila tutto sul momento, ma solo le parti necessarie)


Originariamente inviato da fek
Scusami, perche' e' la seconda volta di fila che dico il contrario di quello che dici tu :)

.NET non e' interpretato. Il CLI viene tradotto in codice nativo prima di essere eseguito da una specie di JIT compiler, oppure addirittura al momento di installare l'applicazione.

Alcuni dei problemi prestazionali della piattaforma .NET sono dovuti al Garbage Collector che e' eseguito nello spazio utente, mentre se fosse eseguito a livello kernel avrebbe accesso ad alcune ottimizzazioni altrimenti impossibile che ridurrebbero questo gap prestazionale.
A quanto so, neppure in LH il GC sara' eseguito a livello kernel, ma in futuro e' probabile che questo passo venga fatto.

Ne approfitto per riportarti questo a parziale prova di cio' che hai affermato sulla diffusione di WinXP:



http://www.steampowered.com/status/survey.html

Originariamente inviato da ShinjiIkari
>Sì ma una volta tanto sembra che mamma M$ stia lavorando come si deve...

Quante volte l'ho sentita sta frase dal 94 ad oggi...
Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti). :rolleyes:

Originariamente inviato da cdimauro
Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti). :rolleyes:

uh copiarsi, che paroloni :D



bbooooni :sofico:

Originariamente inviato da cdimauro
Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti). :rolleyes:

Infatti il Q-Dos (che poi diventerà MS-DOS) lo ha scritto di sana pianta, così come XENIX :asd:

Originariamente inviato da eta_beta
io mi ricordo una lamentela di un programmatore di basic
all'uscita di .net
affermava che le applicazioni erano + lente di un 20-30 %
VB.net non l'ho mai usato, ma mi ricordo che con VB6 ho provato a fare un gioco e andava parecchio lento... comunque le prestazioni non mi sembrano proprio l'obiettivo di VB :D

winfs e come google ....
ma per caso qualcuno fara ricerche facili sul mio Pc dalla rete?
:sofico: :D :D
Se permetti all'amministatore il format c: o il del .*, cosa succede se uno entra nel PC come amministratore? :D
C'è sempre un equilibrio fra esigenze di sicurezza e esigenze dell'utente. A me sembra un'ottima idea l'indicizzazione del contenuto del disco, soprattutto se è eseguita a livello nativo dal sistema operativo. Piuttosto per la sicurezza mi farebbe comodo un sistema di gestione dei permessi a granularità fine (non so se è fra le caratteristiche di WinFS), così solo tu accedi agli indici.

Originariamente inviato da ShijiIkari
Quante volte l'ho sentita sta frase dal 94 ad oggi...
Infatti ho seguito il lancio di Win95 (non avevo ancora il PC), provato la beta di Win98 e di WinXP (Wisthler). Win95 e 98 non erano granchè, il primo aveva problemi costanti specie se si chiudeva male, il secondo era praticamente una copia del 95 migliorata.
Invece secondo me si dovrebbe riconoscere il buon lavoro svolto per XP.

Originariamente inviato da cdimauro
Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti). :rolleyes:
Beh ... tutto da sola é una parola grossa , Win 2000 ( e XP ) hanno grosse parti di codice derivate da FreeBSD .

Originariamente inviato da Cfranco
Beh ... tutto da sola é una parola grossa , Win 2000 ( e XP ) hanno grosse parti di codice derivate da FreeBSD .

Sicuro sicuro di quello che dici?

Originariamente inviato da Megasoft
Ma scusa mi sembra logico che sia tradotto da un compilatore JIT prima di essere eseguito. Ma se tu guardi il file .EXE non è altro che ibrido allo stesso livello di JAVA. Non sono veri e propri eseguibili, ma mero codice da interpretare quando verra avviata l'applicazione(e se ricordo bene il JIT non compila tutto sul momento, ma solo le parti necessarie)

No, puoi compilare direttamente in codice nativo senza mai passare per il CLI. E' un eseguibile vero e proprio.

Originariamente inviato da DjLode
Sicuro sicuro di quello che dici?

Se ne parla da sempre sui vari NG. Ma se ciò sia veritiero o no non saprei dirti, certo che hanno potuto attingere a piene mani visto che il codice era aperto, ed il fatto di tenere i sorgenti chiusi avrebbe permesso loro di mascherare il tutto, riscrivendo poi con il tempo quelle porzioni di codice.

Lode ma ti sei laureato? :eek:

Augurii!!

Originariamente inviato da fek
.NET non e' interpretato. Il CLI viene tradotto in codice nativo prima di essere eseguito da una specie di JIT compiler, oppure addirittura al momento di installare l'applicazione.
La compilazione a livello di installazione non la sapevo :D
Sembra simile alla compilazione degli shader a livello di installazione dell'applicazione. E' molto interessante perchè permette di applicare ottimizzazioni e codepath (esempio, supporto SSE3) in funzione del sistema su cui il codice viene installato.

Originariamente inviato da Hal2001
Se ne parla da sempre sui vari NG. Ma se ciò sia veritiero o no non saprei dirti, certo che hanno potuto attingere a piene mani visto che il codice era aperto, ed il fatto di tenere i sorgenti chiusi avrebbe permesso loro di mascherare il tutto, riscrivendo poi con il tempo quelle porzioni di codice.

Cioè in pratica sono pure congetture non dimostrare e non dimostrabili? :)

Cmq sì, mi sono laureato :)
E sono già al lavoro :coffee: manco il tempo di diventare freddo :)

Originariamente inviato da fek
No, puoi compilare direttamente in codice nativo senza mai passare per il CLI. E' un eseguibile vero e proprio.

Hai la certezza di ciò che dici? Ma sei proprio sicuro? Io uso i linguaggi .NET da molto tempo...guarda bene, cerca in giro... Ho la certezza di ciò che dico. Se prendi un qualsiasi eseguibile fatto in .NET BASE 1.1 o 2.0 che sia (cioè senza programmi esterni che fanno quel lavoro che dici tu) puoi decompilarlo con Reflector e ciò significa che non è altro che codice ibrido, chiamato anche Bytecode MSIL...
Ma se sai come si fa a compilare così dimmelo scusa, ma dubito perchè in questo modo si perderebbe il motivo stesso per il quale è stato creato il .NET ;)

è stato un salto tecnologico per microsoft, perché NON è stato scritto da microsoft, ma da Digital Equipment Corporation. Il progettista quando è andato in M$ si è portato dietro il progetto.

Tanto è vero che se si guardano alcuni help di M$ e di DEC anche il nome delle variabili è uguale.

Ps Sistemista Digital per circa 10 anni!

Originariamente inviato da vale56
è stato un salto tecnologico per microsoft, perché NON è stato scritto da microsoft, ma da Digital Equipment Corporation. Il progettista quando è andato in M$ si è portato dietro il progetto.

Tanto è vero che se si guardano alcuni help di M$ e di DEC anche il nome delle variabili è uguale.

Ps Sistemista Digital per circa 10 anni!

Guarda che il sistemista di cui tu parli se ne andato già dai tempi del 2000 a quanto ricordo e il vero salto di qualità si è avuto proprio in quel caso. :oink:

Originariamente inviato da Megasoft
Ma se sai come si fa a compilare così dimmelo scusa, ma dubito perchè in questo modo si perderebbe il motivo stesso per il quale è stato creato il .NET ;)

Perchè? .NET ha tra i suoi obbiettivi quello di fornire un compilatore per ogni piattaforma così da sviluppare codice per windows su ogni cosa. Quindi forse si perde uno dei motivi, non certo IL motivo :)

Originariamente inviato da DjLode
Perchè? .NET ha tra i suoi obbiettivi quello di fornire un compilatore per ogni piattaforma così da sviluppare codice per windows su ogni cosa. Quindi forse si perde uno dei motivi, non certo IL motivo :)

Secondo Microsoft il motivo di fondo del .NET è creare un interfaccia comune che unisca i programmatori e in questo modo garantire la compatibilità con ogni sistema anche di 50anni prima e di ottimizzare il software su ogni macchina sfruttando a pieno le caratteristiche di ognuna di queste. Se crei codice compilabile in nativo perdi proprio questa possibilità ovvero il nocciolo del .net :D

Originariamente inviato da fek
No, puoi compilare direttamente in codice nativo senza mai passare per il CLI. E' un eseguibile vero e proprio.

OT:

CLI... :cry: mi ricorda i tempi dell'amiga... nostalgia.

Fine OT

Originariamente inviato da Banus
La compilazione a livello di installazione non la sapevo :D
Sembra simile alla compilazione degli shader a livello di installazione dell'applicazione. E' molto interessante perchè permette di applicare ottimizzazioni e codepath (esempio, supporto SSE3) in funzione del sistema su cui il codice viene installato.

Qui c'e' un articolo interessante che spiega le differenze con Java:

http://www.csharphelp.com/archives/archive10.html


Just like Java, before the managed code is executed, the intermediate language is converted to CPU specific code by a just in time (JIT) compiler. The runtime supplies one or more JIT compilers for each computer architecture it supports. However, the code can be compiled into native form during installation itself.

[...]

Microsoft's designers insist that the runtime never interprets any language, it always executes native code, only conversion to native form may be deferred. Even the scripting languages like VBScript are now compiled and executed!

Il vero salto di qualità è stato da quando si è passato da un S.O. mono utente (ante NT) a un S.O. multi utente (NT).

Il resto Win 2K e Win XP sono state evoluzioni di un progetto NON M$.

P.S. VMS e Open VMS, nonostante siano sistemi "vecchi" hanno molte funzionalità che Microsoft non ha (ad esempio come fai a sapere chi sta facendo il lock di un file in 2k o xp?)

Il fatto che ci sia il JIT non l'ho mai negato anzi l'ho detto pure io. Il codice viene compilato in nativo prima di eseguirlo per guadagnare le ottimizzazioni relative al sistema.

Ma tu mi stai dicendo che gli eseguibili .NET sono nativi e io ti sto solo dicendo che è assolutamente impossibile. Sono puro e semplice bytecode che viene compilato quando l'applicazione viene avviata, ma di per se è cmq codice da interpretare (alias compilare) a run-time :D

Originariamente inviato da Megasoft
Ma se sai come si fa a compilare così dimmelo scusa, ma dubito perchè in questo modo si perderebbe il motivo stesso per il quale è stato creato il .NET ;)

In realta' compilare il codice in nativo non fa perdere "il cuore di .NET" che e' l'interoperabilita'. Quella non deriva dalla rappresentazione del codice, ma dai metadati che sono conservati assieme al codice e che dicono a tool come Reflector come "leggere" il codice al quale sono associati. I metadati non vengono toccati dal processo di compilazione in codice nativo.

Gli assembly del framework, ad esempio, sono distribuiti gia' compilati in codice nativo X86, e sono ovviamente utilizzabili da tutti i moduli compilati per la piattaforma .NET perche' contengono i metadati relativi.

Per rispondere a Megasoft:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconjitcompilation.asp
http://msdn.microsoft.com/msdnmag/issues/05/04/NGen/default.aspx

x Fek:
ora mi leggo per bene l'articolo :D
Comunque la parte che hai quotato mi sembra significativa. Con .NET in teoria l'esecuzione delle applicazioni dovrebbe essere più veloce.

Originariamente inviato da Banus
Per rispondere a Megasoft:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconjitcompilation.asp
http://msdn.microsoft.com/msdnmag/issues/05/04/NGen/default.aspx

x Fek:
ora mi leggo per bene l'articolo :D
Comunque la parte che hai quotato mi sembra significativa. Con .NET in teoria l'esecuzione delle applicazioni dovrebbe essere più veloce.


Ho letto da qualche parte che il JIT e' in grado di fare anche profile instrumented optimisation, in parole povere cerca di capire quali code path sono eseguiti piu' spesso ed ottimizza quelli a discapito dei code path eseguiti meno spesso. In questo modo sarebbe in grado di ottimizzare l'applicazione durante l'uso in base al tipo di uso! Una cosa che un compilatore standard non puo' ovviamente fare.

Originariamente inviato da Megasoft
Il fatto che ci sia il JIT non l'ho mai negato anzi l'ho detto pure io. Il codice viene compilato in nativo prima di eseguirlo per guadagnare le ottimizzazioni relative al sistema.

Ma tu mi stai dicendo che gli eseguibili .NET sono nativi e io ti sto solo dicendo che è assolutamente impossibile. Sono puro e semplice bytecode che viene compilato quando l'applicazione viene avviata, ma di per se è cmq codice da interpretare (alias compilare) a run-time :D

Tratto dal link postato da Banus:

The native code produced by NGen is stored in true Win32® PE files which are called "native images" or "NGen images" which are in turn stored in the "native image cache" or "NGen cache." "NGen cache" is also used more generally to refer to all the information that NGen stores—not only the actual native images but also the information about which assemblies have native images.

e mbe? Il fatto del prefetch lo so, ma non significa che il file .EXE sia nativo, è cmq un bytecode MSIL. :confused:

Originariamente inviato da fek
Ho letto da qualche parte che il JIT e' in grado di fare anche profile instrumented optimisation, in parole povere cerca di capire quali code path sono eseguiti piu' spesso ed ottimizza quelli a discapito dei code path eseguiti meno spesso. In questo modo sarebbe in grado di ottimizzare l'applicazione durante l'uso in base al tipo di uso! Una cosa che un compilatore standard non puo' ovviamente fare.
Da una lettura veloce a uno dei link che ho postato infatti si accennava alla possibilità di compilare solo il codice effettivamente usato. Dal momento che spesso il codice non compilato occupa meno spazio, significa tra l'altro un risparmio in termini di memoria.
Trascurando l'overhead dovuto alla gestione del JIT, ci sono molti vantaggi, anche per le prestazioni. Con l'aumento della complessità dei programmi e potenza dei PC il vantaggio di soluzioni simili sarà probabilmente ancora maggiore.

Originariamente inviato da Megasoft
e mbe? Il fatto del prefetch lo so, ma non significa che il file .EXE sia nativo, è cmq un bytecode MSIL. :confused:

MSDN dice proprio il contrario :)

"The native code produced by NGen is stored in true Win32® PE files which are called "native images"

Originariamente inviato da fek
MSDN dice proprio il contrario :)

"The native code produced by NGen is stored in true Win32® PE files which are called "native images"

non ci stiamo capendo. Le immagini create non diventano l'EXE vengono messe in una cartella di prefetch. l'Exe rimane sempre in bytecode MSIL...

Originariamente inviato da Banus
Da una lettura veloce a uno dei link che ho postato infatti si accennava alla possibilità di compilare solo il codice effettivamente usato. Dal momento che spesso il codice non compilato occupa meno spazio, significa tra l'altro un risparmio in termini di memoria.
Trascurando l'overhead dovuto alla gestione del JIT, ci sono molti vantaggi, anche per le prestazioni. Con l'aumento della complessità dei programmi e potenza dei PC il vantaggio di soluzioni simili sarà probabilmente ancora maggiore.

E dai, diciamocela tutta, fra 5/10 anni smetteremo di programmare in C++/C e programmeremo con framework stile .NET, come oggi non si programma piu' in assembly :)

E scriviamolo sto motore 3d totalmente managed!

Originariamente inviato da cdimauro
Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti). :rolleyes:


questa è la cosa più geniale che ho sentito negli ultimi anni.

Quindi secondo te chi copia dei veri OS che funzionano fa male perchè è uno scopiazzatore..invece se microsoft fa dei sistemi operativi che fanno cagare ma li fa da sola allora è tutto un altro paio di maniche.
Pensa che fessi quelli che usano i derivati di unix per non parlare di Linux,Solaris,OSX..sti copioni,non si rendono conto dell'originalità di windows 98 o di windows XP.

Ma stiamo scherzando?

Tra l'altro fosse vero che microsoft è originale si potrebbe fare anche un piccolo discorso al riguardo ma tra IE 7,la GUI di longhorn e WinFS si parla di roba che viene già adottata da altre parti,altro che novità...senza parlare di cose più importanti come 802.11i o ipv6, per reti wireless a bassa velocità e multigigabit, già implementati in altri sistemi...altro che rivoluzione.
Non voglio dire che Longhorn farà schifo..dico solo che non si può dire che gli altri OS fanno schifo perchè sono dei derivati Unix mentre Windows è originale quando la realtà è esattamente opposta.

Ma posso sapere perchè in ogni cavolo di News deve saltare fuori Apple, i Mac e il suo MacOS? Miseria ma che è na piaga?

scorpion calmati, sembrava che volevi sbranarci. xD
Il fatto che siano viste da altre parti determinate feature di longhorn o chicchessia non è peccato. è uno degli effetti normali del mercato. Se qualcosa tira e va bene le persone seguono quella scia.
è MOLTO diverso creare un SO partendo da zero, te l'assicuro piuttosto che basarsi su una base gia bella e preparata come unix che ha avuto decenni di sviluppi. Ammettiamolo Microsoft ha fatto un ottimo lavoro, ancora più vistoso con Windows XP che è senza dubbio il miglior sistema operativo per utenti medi su sistemi X86. (per sviluppatori rimane linux il paradiso, ma dato che noi sviluppatori siamo pochini :D)
Il MacOSX è un OTTIMO sistema operativo, ma diciamocelo non ha molti dei problemi di XP ed è STABILE come dite, solo perchè su un sistema MacOS puoi mettere SOLO e SOLTANTO ciò che dice la Apple. Su un sistema X86 puoi creare milioni se non miliardi di combinazioni hardware che sono difficilmente gestibili e devo ammettere che in questo campo microsoft ha fatto il miglior lavoro. (vedesi immani problemi sul driver model di Linux e sulla gestione dell'USB)

Originariamente inviato da DjLode
Ma posso sapere perchè in ogni cavolo di News deve saltare fuori Apple, i Mac e il suo MacOS? Miseria ma che è na piaga?

ormai è di moda. Cmq vedi sopra per quello che penso io su questo :D

Originariamente inviato da DjLode
Ma posso sapere perchè in ogni cavolo di News deve saltare fuori Apple, i Mac e il suo MacOS? Miseria ma che è na piaga?


Ammazza..c'hai il mirino...ne ho elencati 6 di OS...forse è perchè non ho messo QNX?
E poi l'OSX è solo un esempio...avessi tirato fuori debian la suse e compagnia bella il discorso sarebbe stato identico.

Dai che ci siamo capiti ;)

Originariamente inviato da Megasoft
scorpion calmati, sembrava che volevi sbranarci. xD
Il fatto che siano viste da altre parti determinate feature di longhorn o chicchessia non è peccato. è uno degli effetti normali del mercato. Se qualcosa tira e va bene le persone seguono quella scia.
è MOLTO diverso creare un SO partendo da zero, te l'assicuro piuttosto che basarsi su una base gia bella e preparata come unix che ha avuto decenni di sviluppi. Ammettiamolo Microsoft ha fatto un ottimo lavoro, ancora più vistoso con Windows XP che è senza dubbio il miglior sistema operativo per utenti medi su sistemi X86. (per sviluppatori rimane linux il paradiso, ma dato che noi sviluppatori siamo pochini :D)
Il MacOSX è un OTTIMO sistema operativo, ma diciamocelo non ha molti dei problemi di XP ed è STABILE come dite, solo perchè su un sistema MacOS puoi mettere SOLO e SOLTANTO ciò che dice la Apple. Su un sistema X86 puoi creare milioni se non miliardi di combinazioni hardware che sono difficilmente gestibili e devo ammettere che in questo campo microsoft ha fatto il miglior lavoro. (vedesi immani problemi sul driver model di Linux e sulla gestione dell'USB)


Io non guardo alla parte utente in un sistema operativo ma guardo all'architettura di tutto l'OS.
tanto di cappello a microsoft che gestisce milioni di combinazioni hardware diverse...ma anche linux lo fa,anche unix lo fa,anche tutti gli altri lo fanno e le loro architetture nella maggior parte dei casi sono rock solid mentre qui ancora si dice che XP è un buon OS perchè non si impalla...un pò come dire che la ferrari è una macchina sportiva perchè ha le ruote larghe.
Poi magari vanno anche bene per le esigenze degli utenti,nessuno dice il contrario...ma da qui a dire che un vaporware è una novità assoluta ed è un buon sistema operativo perchè gli UNIX sono autoreferenti mentre microsft prosegue sulla sua strada..beh ce ne vuole,insomma la motivazione è veramente ridicola.

Poi per quanto riguarda OSX se ne può anche non parlare...ma rappresenta cmq la dimostrazione che i sistemi unix funzionano bene anche a livello utente alto

allora supponendo che tu sia un programmatore...

Sai cos'è un driver model? Hai la minima idea di come sia inguaiato quello dei sistemi Unix Like? Hai presente le miriadi di problemi con l'USB che ha attualmente OGNI distribuzione linux? E questo tu lo chiami... "ma anche linux lo fa,anche unix lo fa,anche tutti gli altri lo fanno e le loro architetture nella maggior parte dei casi sono rock solid mentre qui ancora si dice che XP è un buon OS perchè non si impalla...un pò come dire che la ferrari è una macchina sportiva perchè ha le ruote larghe. "
Linux ha inventato un nuovo sistema di driver l'ormai famoso in america "plug and pray" :sofico:

Conosci:

http://linux-usb.sourceforge.net/ ?

Ricordiamo che il supporto dipende anche e soprattutto dai produttori...

certo che lo conosco, però ancora le mie periferiche non sono riconosciute e fino ad allora continuerò ad usare Win con al limite CoLinux come Linux...

(intendo come periferiche, una scheda SCSI della TekRAM, mouse e tastiera wireless USB, Scheda TV PC-TV Stereo (non quella basata sul chip 878), e tanto altro ancora)

E poi dai, ad esempio il modem speedtouch è supportato, ma diavolo fate un installazione decente che parta su tutti i sistemi, un utente medio non può dannarsi l'anima a cercare la soluzione relativa alla propria versione della propria distro. :sofico:


Ora smettiamola se no finisce nel solito polverone :D

e meno male che la news parlava delle novità del sottosistema di rete di LH, tra cui IPv6 e VoIiP integrati nel sistema... ed è tornata la distriba sul .NET ... :D

Originariamente inviato da Hal2001
Se ne parla da sempre sui vari NG. Ma se ciò sia veritiero o no non saprei dirti, certo che hanno potuto attingere a piene mani visto che il codice era aperto, ed il fatto di tenere i sorgenti chiusi avrebbe permesso loro di mascherare il tutto, riscrivendo poi con il tempo quelle porzioni di codice.
E' sicuramente vero , nella licenza d' uso dei SO Microsoft sono infatti citati esplicitamente alcuni programmatori di codice FreeBSD , in ottemperanza alla licenza del codice che impone di citare gli autori , quanto e quale sia stato usato resta un mistero , anche se sembra si tratti della parte di codice di gestione della rete .

Originariamente inviato da Megasoft

Linux ha inventato un nuovo sistema di driver l'ormai famoso in america "plug and pray" :sofico:
Guarda che il detto é stato coniato per Windows '98 , almeno le citazioni facciamole giuste :rolleyes:
E comunque anche Windows ha le sue immense rogne con l' USB , il mio HD USB 2 ha funzionato per 6 mesi solo su Linux , mentre aspettavo l' SP1 per XP .

io sapevo che microsoft stava collaborando anche con ati e nvidia visto che buona parte dell'interfaccia grafica sarà gestita dalle schede video e nn dal processore! Dite che sarà vero? Ma una soluzione del genere (che la ritengo una buona idea) nn inciderà suelle prestazioni delle schede video durante i giochi?
Inoltre questo longhorn richiede una gran potenza e sicuramente adesso come sistema operativo sarebbe inadeguato......su quale macchina lo monti?? Però per il 2006 nn si prevedono migliorie magnifiche in ambito processore. Cioè nn saranno poi tanto più potenti di adesso. si diffonderanno i dual core ma nn è che poi finisce che un intero core è sempre dedicato al solo sistema operativo mentre l'altro si occupa di far girare i vari programmi?? Sarebbe come avere adesso un processore singol core.
E poi windows xp (come tutti quelli prima) si è diffuso velocemente grazie alle copie pirata! Se microsoft darà un giro di vite alla pirateria la vedo dura la diffusione di questo nuovo sistema operativo!

Originariamente inviato da Hal2001
Infatti il Q-Dos (che poi diventerà MS-DOS) lo ha scritto di sana pianta, così come XENIX :asd:
Q-DOS è MS: tutti le persone di quella società sono entrate a far parte di MS. ;)

Per Xenix il discorso è diverso, ma è un s.o., che non ha neppure avuto successo, rispetto a tutti gli altri che ha sviluppato MS (e partendo da zero, non andando a scopiazzare a destra e a manca).

Originariamente inviato da Cfranco
Beh ... tutto da sola é una parola grossa , Win 2000 ( e XP ) hanno grosse parti di codice derivate da FreeBSD .
Grosse parti? L'unica parte è la gestione della rete (se è vero ciò che dici) e i socket (ma qui TUTTI si sono "ispirati" al lavoro di BSD, che i socket li ha creati): ben poca cosa rispetto a tutto il resto del s.o...

Originariamente inviato da Hal2001
Se ne parla da sempre sui vari NG. Ma se ciò sia veritiero o no non saprei dirti, certo che hanno potuto attingere a piene mani visto che il codice era aperto, ed il fatto di tenere i sorgenti chiusi avrebbe permesso loro di mascherare il tutto, riscrivendo poi con il tempo quelle porzioni di codice.
Supposizioni, soltanto supposizioni. ;)
Se avessero volito giocare sporco avrebbero fatto a meno di elencare i nomi di cui parla Cfranco... :p

Originariamente inviato da vale56
è stato un salto tecnologico per microsoft, perché NON è stato scritto da microsoft, ma da Digital Equipment Corporation. Il progettista quando è andato in M$ si è portato dietro il progetto.
Quindi è NT è un prodotto di MS. Comunque dimentichi che le API Win16 e Win32 le ha sviluppate MS, non DEC. ;)
Tanto è vero che se si guardano alcuni help di M$ e di DEC anche il nome delle variabili è uguale.
Indubbiamente: chi lo nega. Ma NT, quando è nato in DEC, era un s.o. diverso da quel che poi si è rivelato NT...

Originariamente inviato da vale56
Il vero salto di qualità è stato da quando si è passato da un S.O. mono utente (ante NT) a un S.O. multi utente (NT).
Della multiutenza la stragrande maggioranza di utenti MS non s'è n'è fatta niente... ;)
Il resto Win 2K e Win XP sono state evoluzioni di un progetto NON M$.
Il core di NT non era MS, ma lo è diventato dopo che gli ingegneri sono passati a MS. In ogni caso quel core è stato decisamente cambiato, per venire incontro alle esigenze di MS e di tutte le API che erano già state sviluppate, e di cui era necessario mantenere la compatibilità (ma questo dovresti saperlo).
P.S. VMS e Open VMS, nonostante siano sistemi "vecchi" hanno molte funzionalità che Microsoft non ha (ad esempio come fai a sapere chi sta facendo il lock di un file in 2k o xp?)
Il Kernel può saperlo. Se poi manca lo strumento (leggi: il programmino) per farlo, questo è un altro paio di maniche...

Originariamente inviato da scorpionkkk
questa è la cosa più geniale che ho sentito negli ultimi anni.
Ti ringrazio per il complimento... :p
Quindi secondo te chi copia dei veri OS che funzionano fa male perchè è uno scopiazzatore..
Non ho mai detto questo: mi fai vedere dove lo avrei scritto? :rolleyes:

Ho detto che almeno MS i s.o. li ha scritti da zero: non ha fatto come Apple proclamoni che poi non è riuscita a mantenere da sola...
invece se microsoft fa dei sistemi operativi che fanno cagare ma li fa da sola allora è tutto un altro paio di maniche.
A parte il fatto che non fanno cagare (questa è una TUA personalissima e opinabilissima opinione), anche nel caso che le cose stessero così, per lo meno se ha sbagliato l'ha fatto da sola, senza contare sull'aiuto di altri...
Pensa che fessi quelli che usano i derivati di unix per non parlare di Linux,Solaris,OSX..sti copioni,non si rendono conto dell'originalità di windows 98 o di windows XP.

Ma stiamo scherzando?
Io non scherzo di certo: ho semplicemente risposto a una frase poco felice.
Comunque, a parte Apple, quelli che usano s.o. derivati da Unix per lo meno non si vantano dell'originalità...
Tra l'altro fosse vero che microsoft è originale si potrebbe fare anche un piccolo discorso al riguardo ma tra IE 7,la GUI di longhorn e WinFS si parla di roba che viene già adottata da altre parti,altro che novità...
Perché non parli più chiaramente? A cosa ti riferisci?
senza parlare di cose più importanti come 802.11i o ipv6, per reti wireless a bassa velocità e multigigabit, già implementati in altri sistemi...altro che rivoluzione.
Sono tutte specifiche sviluppate da enti, e aperti a tutti: dov'è il problema? E' il tempo impiegato per implementarle? Tutto qui?
Non voglio dire che Longhorn farà schifo..
Anche perché è un prodotto che non è ancora commercializzato...
dico solo che non si può dire che gli altri OS fanno schifo perchè sono dei derivati Unix mentre Windows è originale quando la realtà è esattamente opposta.
Ripeto: dove l'avrei mai scritto questo?

La realtà è che Windows è originale e OS X, Linux, *BSD, ecc. no, perché riprendono sorgenti e API di un s.o. che è nato quasi quarant'anni fa, e che si trascina tutt'oggi.

Può non piacerti l'approccio di Windows, e personalmente preferisco nettamente quello di AmigaOS (AI TEMPI, ovviamente), ma sull'originalità non hai di che discutere, e soprattutto Apple non ha di che vantarsi, visto che la robustezza e la flessibilità di OS X non sono certo farina del suo sacco...

Questo senza nulla togliere alla bontà di OS X, che è un gran s.o...

Originariamente inviato da zephyr83
io sapevo che microsoft stava collaborando anche con ati e nvidia visto che buona parte dell'interfaccia grafica sarà gestita dalle schede video e nn dal processore! Dite che sarà vero? Ma una soluzione del genere (che la ritengo una buona idea) nn inciderà suelle prestazioni delle schede video durante i giochi?
perchè? i giochi vanno tipicamente in full screen
quindi con lo schermo assegnato ad un gioco, le altre applicazioni sarebbero escluse dal redraw, e la gpu non sarebbe impegnata a ridisegnare ANCHE widget, icone ed altro, qualora divenisse un compito affidato a lei (come mi piacerebbe che fosse - per me l' ideale sarebbe il rendering dei widget tramite pixel shader...)
poi certo, se sia giochi che il (chiamiamolo così) "window manager" di LH dovessero accedere a funzioni directx , si richiederebbe che queste librerie fossero completamente thread safe...

Originariamente inviato da cdimauro
La realtà è che Windows è originale e OS X, Linux, *BSD, ecc. no, perché riprendono sorgenti e API di un s.o. che è nato quasi quarant'anni fa, e che si trascina tutt'oggi.

Ti facevo più esperto in SO , ma dopo questa frase capisco che in realtà non lo sei .
L' unica cosa originale di Windows é l' interfaccia ( e anche su questo ci sarebbe da discutere con Xerox e Apple ) il resto é roba "già vista" , d' altra parte un SO ha un solo compito da svolgere ed é estremamente improbabile che dopo decenni di teoria dei sistemi operativi e di studi su come svolgere questo lavoro si possa trovare ancora qualcosa di nuovo .
D' altra parte anche seguire un percorso già tracciato non é di per sè un difetto , anzi , basta vedere il tempo e le energie spese per far funzionare il kernel Mach .

Originariamente inviato da Cfranco
Ti facevo più esperto in SO , ma dopo questa frase capisco che in realtà non lo sei .
L' unica cosa originale di Windows é l' interfaccia ( e anche su questo ci sarebbe da discutere con Xerox e Apple ) il resto é roba "già vista" , d' altra parte un SO ha un solo compito da svolgere ed é estremamente improbabile che dopo decenni di teoria dei sistemi operativi e di studi su come svolgere questo lavoro si possa trovare ancora qualcosa di nuovo .
D' altra parte anche seguire un percorso già tracciato non é di per sè un difetto , anzi , basta vedere il tempo e le energie spese per far funzionare il kernel Mach .

Secondo me si travisa il senso... cdmauro parla di originalità di codice, mentre tu parli di originalità di idee per quel che riguarda la gui...
sono due cose Moooolto diverse...
Potresti spiegare in dettaglio cosa Windows non avrebbe di originale second te (o secondo quali fonti)?

Originariamente inviato da Cfranco
E' sicuramente vero , nella licenza d' uso dei SO Microsoft sono infatti citati esplicitamente alcuni programmatori di codice FreeBSD , in ottemperanza alla licenza del codice che impone di citare gli autori , quanto e quale sia stato usato resta un mistero , anche se sembra si tratti della parte di codice di gestione della rete .

Forse ti sei confuso, Microsoft ha preso codice sotto licenza BSD, non codice del sistema operativo FreeBSD. :rolleyes:

Originariamente inviato da Cfranco
Ti facevo più esperto in SO , ma dopo questa frase capisco che in realtà non lo sei .
Sei tu che hai travisato, come ti hanno già risposto...
L' unica cosa originale di Windows é l' interfaccia ( e anche su questo ci sarebbe da discutere con Xerox e Apple ) il resto é roba "già vista" , d' altra parte un SO ha un solo compito da svolgere ed é estremamente improbabile che dopo decenni di teoria dei sistemi operativi e di studi su come svolgere questo lavoro si possa trovare ancora qualcosa di nuovo .
Infatti. E io non l'ho mai negato: la letteratura informatica in merito è piuttosto eloquente...
D' altra parte anche seguire un percorso già tracciato non é di per sè un difetto , anzi , basta vedere il tempo e le energie spese per far funzionare il kernel Mach .
E chi lo nega? Ma il discorso era un altro... ;)

Originariamente inviato da Superboy
Secondo me si travisa il senso... cdmauro parla di originalità di codice, mentre tu parli di originalità di idee per quel che riguarda la gui...
Linux funziona come UNIX , ma non ne contiene neanche una riga di codice , quindi a maggior ragione il suo discorso non sta in piedi .
Potresti spiegare in dettaglio cosa Windows non avrebbe di originale second te (o secondo quali fonti)?
Cosa ha Windows che non si fosse visto prima ?
:confused:

Originariamente inviato da Megasoft
Forse ti sei confuso, Microsoft ha preso codice sotto licenza BSD, non codice del sistema operativo FreeBSD. :rolleyes:
Il codice che ha preso é sotto licenza BSD e il codice é usato anche da FreeBSD , quello che ho detto non é preciso al 100% ma il senso si capiva bene lo stesso .

Originariamente inviato da cdimauro
Sei tu che hai travisato, come ti hanno già risposto...

Se sei certo che Linux contenga codice UNIX faresti meglio a dirlo a SCO , sono anni che sta cercando un pezzo di codice copiato per la sua disperata causa e ancora non ha trovato niente :p

edit
Microsoft invece ha con SCO un accordo di licenza per l' utilizzo del codice UNIX ...

Originariamente inviato da Cfranco
Ti facevo più esperto in SO , ma dopo questa frase capisco che in realtà non lo sei .
L' unica cosa originale di Windows é l' interfaccia ( e anche su questo ci sarebbe da discutere con Xerox e Apple ) il resto é roba "già vista" , d' altra parte un SO ha un solo compito da svolgere ed é estremamente improbabile che dopo decenni di teoria dei sistemi operativi e di studi su come svolgere questo lavoro si possa trovare ancora qualcosa di nuovo .
D' altra parte anche seguire un percorso già tracciato non é di per sè un difetto , anzi , basta vedere il tempo e le energie spese per far funzionare il kernel Mach .
su questo sono d' accordo con Superboy: l' originalità delle idee, o della filosofia o dei concetti che stanno dietro al progetto della gui o di qualche altro componente di un OS, è una cosa essenzialmente vacua: è ovvio che se una funzione viene riconosciuta utile (per assecondare necessità dell' utente) o interessante (magari in virtù di un certo "coolness factor") per qualsivoglia motivo, verrà implementata, prima o poi (volendo, anche più "prima" che poi... dipende da cosa la struttura attuale del sistema, costringe a fare per attuare l' aggiunta di nuove funzioni senza essere compromessa... e dalla priorità che la nuova caratteristica si vede assegnare)

inoltre, se nel mio piccolo dò uno sguardo a com'è strutturato NT a basso livello, vedo qualcosa di un tantino diverso dal kernel monolitico di Unix e dei figli di Unix, che comunica col resto del codice binario in circolazione nella macchina, attraverso qualcosa di molto diverso dal set di system call di bsd o quello di linux...
nota a margine 1) da documentazione classica, studi e articoli su riviste IEEE, emergerebbero parecchie limitazioni dello unix classico, su, ad es il sistema di threading, la (non) concorrenza del kernel, il supporto (assente nella forma originaria) al real time...
il threading come ce lo aspettiamo oggi (con i thread entità basilari assegnabili dallo scheduler ad una cpu o all' altra) è stato introdotto non in ambito unix , ma da altri OS.. nati in un periodo in cui le differenze tra un sistema operativo e l' altro erano radicali e non sussisteva il livellamento attuale
quindi a rigore di logica si dovrebbe ammettere che anche Linux avrebe "copiato" , se non certo la API, almeno idee e concetti del design di qualche altro OS... a sto punto però io lo chiamo "scambio di idee" più che "scopiazzatura"

nota a margine 2) Mach ... in effetti, Mach non è nato come kernel unix, ma come microkernel agnostico, su cui è poi stata impiantata la API di BSD trasformandolo in un single server

nota a margine 3) se non ricordo male la licenza BSD dice sostanzialmente "è permesso fare ogni uso desiderato del presente codice , purchè venga menzionato l' autore" il che infatti è osteggiato dai sostemitori del "free" SW perchè apre la strada all' utilizzo di SW aperto per progetti proprietari e closed

Originariamente inviato da Cfranco
Se sei certo che Linux contenga codice UNIX faresti meglio a dirlo a SCO , sono anni che sta cercando un pezzo di codice copiato per la sua disperata causa e ancora non ha trovato niente :p
Infatti se non ricordo male ultimamente ha provato anche la strada dei brevetti...

La storia di Linux invece è più complicata, e non mi ricordo tutti i particolari. C'è di mezzo la disputa fra sostenitori della filosofia free e sostenitori del software commerciale, che risale agli anni '70.

Comunque le dispute su "xx ha copiato yy" secondo me sono abbastanza sterili. A questo punto nessun OS è originale, visto che praticamente tutti usano la struttura a directory (Unix '60) e la metafora della scrivania per l'interfaccia visuale (Mac '80).

Originariamente inviato da Cfranco
Cosa ha Windows che non si fosse visto prima ?
:confused:

Vedi che ci riferiamo a due cose differenti! tu parli di modelli ed io di codice! Voglio sapere quale parte del codice di win non è stata scritta di pugno da ms!
Sò anche io che le gui odierne son tutte "copiate" (io direi ispirate) da Xeros, ma ciò non vuol dire nulla, si chiama evoluzione! I prodotti che sanno adattarsi andare nella direzione tracciata dal mercato e proponendo soluzioni all'altezza ( e che son ben vendute) sopravvivono, le altre no.
Non è questione di copiare o non copiare, le "cose" buone sono adottate in massa! ci sono infiniti esempi di questo in informatica...

Discroso completamente diverso è invece incorporare all'interno di un proprio prodotto codice scritto dalla comunità o da altri enti per un uso commerciale (vedi Apple con mac osx), proprio riguardo a questo volevo più informazioni (fonti) del fatto che win nt nn fosse farina del sacco di ms.

Originariamente inviato da Banus
la metafora della scrivania per l'interfaccia visuale (Mac '80).


volevi dire Xerox :)

Originariamente inviato da Superboy
volevi dire Xerox :)
Infatti sapevo che la paternità non era del Mac ma ho messo il primo nome che mi è venuto in mente :p
Nella mia mente non riescono ad entrare troppi nomi :p

Originariamente inviato da jappilas
nota a margine 2) Mach ... in effetti, Mach non è nato come kernel unix, ma come microkernel agnostico, su cui è poi stata impiantata la API di BSD trasformandolo in un single server

Potresti spiegare meglio il concetto?

Originariamente inviato da Cfranco
Se sei certo che Linux contenga codice UNIX faresti meglio a dirlo a SCO , sono anni che sta cercando un pezzo di codice copiato per la sua disperata causa e ancora non ha trovato niente :p

edit
Microsoft invece ha con SCO un accordo di licenza per l' utilizzo del codice UNIX ...
T'hanno già risposto, comunque ti riporto nuovamente quello che avevo scritto:

"La realtà è che Windows è originale e OS X, Linux, *BSD, ecc. no, perché riprendono sorgenti e API di un s.o. che è nato quasi quarant'anni fa, e che si trascina tutt'oggi."

L'originalità di Windows si basa su due fatti: il fatto che MS abbia creato partendo da zero questo s.o. (e derivati), e che le API abbiano ben poco a che vedere con quelle degli altri s.o...

OS X ha preso a piene mani sorgenti E API, e questo è innegabile.

Linux ha preso pezzi di codice free E le API di Unix (open, close, fork, ecc. sono le stesse, vetuste, API sviluppate ai tempi di questo s.o.).

Originariamente inviato da cdimauro
T'hanno già risposto, comunque ti riporto nuovamente quello che avevo scritto:

"La realtà è che Windows è originale e OS X, Linux, *BSD, ecc. no, perché riprendono sorgenti e API di un s.o. che è nato quasi quarant'anni fa, e che si trascina tutt'oggi."
Come ti é stato detto questo non é affatto vero , né i sorgenti né le API di windows sono interamente originali , i primi contengono diverso codice BSD ( mentre Linux é *interamente* scritto da zero ) , le seconde sono basate sullo standard Posix , per finire neppure i concetti guida del SO sono originali in quanto frutto di una rielaborazione di concetti già presenti in altri prodotti .

L'originalità di Windows si basa su due fatti: il fatto che MS abbia creato partendo da zero questo s.o. (e derivati), e che le API abbiano ben poco a che vedere con quelle degli altri s.o...

Tanto é vero che riesco a compilare programmi in C capaci di interagire con Aix , Sun e Windows usando le stesse chiamate di sistema .

OS X ha preso a piene mani sorgenti E API, e questo è innegabile.

Segue lo standard Posix , come Unix , Linux e Windows ...

Linux ha preso pezzi di codice free
Se dici che Linux é una collezione di software Free la cosa é esatta ma fuorviante , Linux é free e ciò che é stato scritto per Linux ( o meglio GNU/Linux ) é free per definizione , Linux non ha saccheggiato niente .
E le API di Unix (open, close, fork, ecc. sono le stesse, vetuste, API sviluppate ai tempi di questo s.o.).
E sono le stesse API che usi quando scrivi programmi Windows ...

Originariamente inviato da Cfranco
Come ti é stato detto questo non é affatto vero , né i sorgenti né le API di windows sono interamente originali , i primi contengono diverso codice BSD ( mentre Linux é *interamente* scritto da zero ) , le seconde sono basate sullo standard Posix , per finire neppure i concetti guida del SO sono originali in quanto frutto di una rielaborazione di concetti già presenti in altri prodotti .


Quello che intendeva è proprio che win ha creato un suo set di api indipendente oltre ad abbracciare lo standard posix, in questo senso è stata "originale": nn ha preso un layer di astrazione e lo ha implementato, ma ha creato una struttura (l'executive) totalmente di suo pugno. All'interno di questa convivono subsystem indipendenti tra cui quello posix, os2, win32.
Vogliamo dare argomentazioni precise e non pressione ai polpastrelli...
-Chi dice che il subsystem win32 nn è originale a livello di api: perchè? (vi basate solo su una convenzione di nomi (sempre che ci sia) o altro?)
- Chi continua ad insistere che win (quale poi? ww, nt, 2k, xp) contiene al suo interno codice BSD porti documenti...
- Che sono i concetti guida di un so? sei un po' generico... parli di look & feel, struttura del kernel, costrutti logici, pattern di programmazione :)


Tanto é vero che riesco a compilare programmi in C capaci di interagire con Aix , Sun e Windows usando le stesse chiamate di sistema.

Segue lo standard Posix , come Unix , Linux e Windows ...


Aix è posix così come win ha il subsystem posix..


Se dici che Linux é una collezione di software Free la cosa é esatta ma fuorviante , Linux é free e ciò che é stato scritto per Linux ( o meglio GNU/Linux ) é free per definizione , Linux non ha saccheggiato niente .


GNU/Linux è una distribuzione di software Free.
Linux è un kernel il cui codice distribuito sotto GPL.
I programmi scritti per GNU nn devono per forza rispettare la gpl...


E sono le stesse API che usi quando scrivi programmi Windows ...

Non sono le stesse api, è solo una namig convention... quando apri un file ti è più intuitivo fare una Open o una Mapfileinmemorysoicanreadit :PPPP

Originariamente inviato da Superboy
Quello che intendeva è proprio che win ha creato un suo set di api indipendente oltre ad abbracciare lo standard posix, in questo senso è stata "originale":
Nessuno dubita che Windows sia "originale" , quello che si contesta é questa precisa frase :
"La realtà è che Windows è originale e OS X, Linux, *BSD, ecc. no, perché riprendono sorgenti e API di un s.o. che è nato quasi quarant'anni fa, e che si trascina tutt'oggi."
Windows é un SO come un altro , simile agli altri in alcune cose e diverso in altre , la cui dose di "originalità" non é superiore a un Linux o a un OS X , anzi trovo quest' ultimo decisamente più innovativo , sia per l' interfaccia grafica sia per il Kernel ( é il primo microkernel che funziona decentemente :winner: )
Non credo poi che siano decisive le Api per decretare quale sia originale , in Unix c' é sleep() in Windows si chiama Sleep() ( notare la maiuscola ) ma sempre la stessa cosa é , alla fine le operazioni gestite sono sempre le stesse , e gli algoritmi sono sempre uguali , se voglio disegnare una finestra cambiano i nomi della chiamata ma quella che si apre é sempre una finestra , dov' é l' innovazione ?
Innovare é fare qualcosa che nessun altro fa , innovativo era Next con l' interfaccia grafica in Postscript , innovativo é stato Os/2 , innovativa é stata Sun con Java , innovativo é stato Mosaic .

Originariamente inviato da Hal2001
Potresti spiegare meglio il concetto?

se si guarda il link (http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/overview.html) si nota che unix non è menzionato

anche qui (http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/About/chapter_1_section_5.html) la apple ammette che Mach avrebbe una sua API, diversa dalla unix sycall table
ma siccome si sa che MAC OS X è un derivato di BSD, vuol dire che tale system call table è stata implementata su un kernel che di suo, è nato per essere più versatile ed elegante dello unix kernel monolitico standard...

Originariamente inviato da Hal2001
Quando dico che sarà un aggiornamento dell'architettura esistente, mi riferivo al fatto che tutti questi miglioramenti (o quasi) li potremo assaggiare anche nell'attuale OS di Microsoft.

E' stata presentata la nuova build [è sempre una alpha] per Windows NT 5.1 e 5.2 [XP e 2003] di Avalon e Indigo.

A questo indirizzo ci sono i 450MB in versione Microsoft Installer [.MSI]: http://www.microsoft.com/downloads/details.aspx?familyid=85ab132b-f1aa-4422-b053-272d79863013&displaylang=en

Originariamente inviato da jappilas
su questo sono d' accordo con Superboy: l' originalità delle idee, o della filosofia o dei concetti che stanno dietro al progetto della gui o di qualche altro componente di un OS, è una cosa essenzialmente vacua:

Se tutti fossero come Microsoft e Dell staremmo ancora all'età della pietra.
Ci vuole qualcuno che porti le innovazioni. Ed è giusto riconoscergli il merito e premiarli.
E Apple da 20 anni nel mondo dei computer sembra quasi l'unica capace di portare innovazioni. Almeno è l'unica che lo fa in modo consistente e a largo spettro: hardware, software, design, ecc.

Criceto io più che innovazione ammiro nell'uomo monopalla (http://forum.hwupgrade.it/showthread.php?s=&postid=7731419#post7731419) l'idea che la macchina deve essere al servizio dell'uomo e non viceversa. L'occhio di riguardo all'estetica. L'innovazione (come lo standard Firewire) che spesso c'è stata è di contorno alla mentalità di uno dei più eccentrici geni del mondo informatico.

la verità è che voi avete torto e io ragione!

ecco

ohhh

l'ho detto....

non seguo la discussione, troppo firtta, pero per quel poco che ho letto do il mio contributo su una questione

lo stack tcp ip era stato preso da bsd, proprio come codice insieme ad altri tool

poi sembra essere stato riscritto, anche se in alcuni tool e ancora possibile ritrovare i tag di bsd, per fortuna non posso verificare, mi manca l'oggetto della discussione, non so se recentemente e stato riscritto tutto quel software ma ai tempi microsoft prese proprio il codice di bsd.

http://www.kuro5hin.org/?op=displaystory;sid=2001/6/19/05641/7357
http://austinlug.org/archives/alg/2002-05/msg00606.html

Originariamente inviato da Mason
lo stack tcp ip era stato preso da bsd, proprio come codice insieme ad altri tool

poi sembra essere stato riscritto, anche se in alcuni tool e ancora possibile ritrovare i tag di bsd, per fortuna non posso verificare, mi manca l'oggetto della discussione, non so se recentemente e stato riscritto tutto quel software ma ai tempi microsoft prese proprio il codice di bsd.


ehmm.... sto leggendo il primo link... e dice proprio l'esatto contrario :) ghgh

riporto: "But it is certainly misleading of the Wall Street Journal to say that BSD code is used "deep inside" the NT networking code"
"And implying that the TCP/IP stack uses BSD code is also false."

I tool sono una cosa, lo stack tcp è ben altro!!!!

Ahh la mala informazione... poi su ste cose la gente ci "sguazza" ^^

3.1 aquista lo stack da spider, che l'ha preso da bsd, riscritto in nt3.5, mi sembra confermato anche dal secondo link.

sbaglio a tradurre/capire?

1) To put a TCP/IP stack in NT

2) To adapt the sockets user-mode API for NT

#1 was solved by licensing code from a company called Spider Systems.

-snip-

Now, some of Spider's code (possibly all of it) was based on the TCP/IP stack in the BSD flavors of Unix.

che ora non ci sia piu' concordo(e ci mancherebbe, sarebbe preuccupante la mancanza di riscritttura), che ci sia stato codice bsd nello stack tcp/ip di win, son abbastanza convinto.

cmq grazie per lo sguazzare nella malainformazione con la sottolineatura del ahh, fa sempre piacere sentirsi dire ste cose... non so... sembra faccia il mondo un posto migliore dove vivere, no?

scusa ho riletto ora la tua ultima frase, ora mi sembra ironica, ti chiedo scusa per la risposta di cui sopra, ma la lascio per non creare incoerenza.

domanda: ma se anche NT avesse riciclato proprio il codice dello stack originario BSD, che male ci sarebbe?
la licenza bsd è parecchio permissiva ....

per me nessuno, anzi commercialmente parlando penso abbiano fatto bene.
io lo dicevo solo perche pensavo potesse interessare alla discussione, non c'e' malizia.

io lo dicevo solo perche pensavo potesse interessare alla discussione, non c'e' malizia.

Allora non c'è neanche profumo d'intesa... Niente da fare, qui si continuerà a discutere a lungo...



Scusate, ogni tanto la devo sparare col botto... Ecco, l'ho fatto... Adesso potete linciarmi :Prrr:

Tornando seri, credo che la diatriba sull'originalità dell'uno o dell'altro os si sia protratta un po' troppo e sia nata da un fraintendimento delle intenzioni di cdimauro nel suo "attacco non cattivo" alla Apple e ai suoi sostenitori. Francamente non ho seguito moltissimo l'evoluzione di OSX, ma per quello che ho capito della "visione" di cdimauro degli eventi, la questione dovrebbe porsi in questi termini:

1. La Apple fa proclamoni sul suo "futuro" nuovo OS: sarà bellissimo, perfetto, meraviglioso, ecc. ecc. (tirando giustamente acqua al suo mulino);

2. Per realizzarlo, però, attinge più o meno a piene mani ai sorgenti *nix (atto contestato ma non per una sua negatività intrinseca);

3. I supporter di Apple (come avviene sempre nel caso di una "fede" di qualche tipo) nel tesserne le lodi usano toni non sempre troppo pacati, additandola a volte come la soluzione ai "mali" introdotti nell'informatica dalla MS, dimenticando che si tratta di due aziende "per fini di lucro", con politiche per certi versi simili, ciascuna con i propri pregi e difetti (ci mancherebbe);

4. Scatta la reazione di cdimauro, il quale ama (quasi fin troppo) ricorrere a metodi da "psicologia d'urto" (cerco di trascinarti su posizioni diametralmente opposte alle tue per fermarci entrambi a metà strada, dove suole indugiare la verità, pigra e indecisa com'è ) per "ricondurre alla ragione" gli interlocutori, insistendo sulla "maggiore originalità" degli OS di casa MS.

Nel criticare la MS, effettivamente, spesso ci si dimentica che talvolta opera con minori "risorse umane" (come mero numero di sviluppatori), contando sulla propria esperienza e sviluppando codice interamente all'interno (salvo acquisizioni varie di sw house e know how; non voglio entrare nel merito di accuse varie su "magheggi" e roba del genere), rispetto a realtà e filosofie diverse (prima che qualcuno mi attacchi su queste affermazioni, tengo a ricordare che i sostenitori dell'open source fanno spesso di queste motivazioni il proprio cavallo di battaglia per sostenere la bontà se non la superiorità della propria filosofia -> vedasi teorie sulla maggiore rapidità nel rilascio di una patch), e pertanto merita comunque rispetto (il lavoro e il sudore degli altri va sempre rispettato: mica gli stipendi vengono regalati alla MS...).

Provo a chiarire meglio questo concetto: supponiamo che io metta mano al kernel di Linux e ottimizzi alcuni algoritmi in maniera geniale, creandone una versione perfetta, meravigliosa, bellissima, la migliore che si possa immaginare/desiderare ("E' un eseempioooo" ). Ecco: senza nulla toglere al mio lavoro eccellente, alla mia fulgida genialità (eh, eh, nessuno sospetterà mai che me ne sto approfittando per farmi da solo dei fanta-complimenti :p :asd: ), sarebbe comunque innegabile che avrei trovato una base solida e ampia, e soprattutto "già bella e pronta" da cui partire, di cui magari andrei a modificare un 10-15-20% (stime indicative relative solo ed esclusivamente al mio esempio), ragion per cui non potrei in alcun modo (ma non potrei in ogni caso) sentirmi autorizzato a denigrare il lavoro altrui, quand'anche di qualità inferiore, ma comunque frutto di un impegno forse, o sicuramente, superiore al mio. Ma a prescindere da ogni valutazione sulla qualità del risultato (quindi uscendo in parte fuor di metafora), io (i miei supporters) non sarei autorizzato (non sarebbero autorizzati) a fare discorsi del tipo "ah, il mio è migliore, io in quattro e quattr'otto ho fatto questo, ho fatto quello... tu invece che sai fare? no, il tuo fa schifo, il tuo non mi piace, buttalo nell'immondizia, buttati dalla finestra, io ce l'ho profumato...", perchè, oltre a mancare di rispetto al mio interlocutore (ai loro interlocutori) e fare una magra figura, potrei (potrebbero) sentirmi dire, in tutta ristposta (e a buon diritto): "Guarda che il mio sw è tutto farina del mio sacco (che poi sia vero al 100% o al 90-80% cambia poco rispetto al mio 10-20%)... e il tuo? no, il tuo fa schifo, il tuo non mi piace, buttati nel cesso e tira lo sciacquone, io ce l'ho più profumato" e così via all'infinito (senza mai sentire l'odore di quel benedetto profumo d'intesa...). In conclusione:

a. il lavoro altrui merita sempre rispetto.

b. l'aver attinto solo alle proprie risorse non rende certo il proprio lavoro migliore, ma è sicuramente motivo di vanto, di orgoglio e, ancora, di rispetto.

My 20 cents. (l'inflazione... :Prrr: ).

quoto xael...

Originariamente inviato da Megasoft
quoto xael...

Mega, ho passato le vacanze pasquali a studiare il CLR ed ho scoperto che... avevamo torto entrambi :D

E' possibile precompilare un assembly in codice nativo, ma la versione CIL con i metadati e' comunque sempre presente e il codice compilato e' messo in una specie di cache usata poi dal JIT. Inoltre gli assembly sono eseguibili in formato PE/Coff che contengono codice CIL che non viene mai eseguito direttamente ma sempre compilato dal JIT (ed il meccanismo di compilazione e' davvero molto "cool") prima dell'esecuzione o al momento dell'installazione.

Studiare l'architettura del CLR vale il tempo che ci si spende sopra, te lo consiglio, e' interessantissimo e mi sono volati due viaggi.

Originariamente inviato da fek
Mega, ho passato le vacanze pasquali a studiare il CLR ed ho scoperto che... avevamo torto entrambi :D

E' possibile precompilare un assembly in codice nativo, ma la versione CIL con i metadati e' comunque sempre presente e il codice compilato e' messo in una specie di cache usata poi dal JIT. Inoltre gli assembly sono eseguibili in formato PE/Coff che contengono codice CIL che non viene mai eseguito direttamente ma sempre compilato dal JIT (ed il meccanismo di compilazione e' davvero molto "cool") prima dell'esecuzione o al momento dell'installazione.

Studiare l'architettura del CLR vale il tempo che ci si spende sopra, te lo consiglio, e' interessantissimo e mi sono volati due viaggi.

Qualche link? :D
Cmq il primo paragrafo lo sapevo. Il resto no, quindi voglio approfondire. :sofico:

Originariamente inviato da fek
Mega, ho passato le vacanze pasquali a studiare il CLR ed ho scoperto che... avevamo torto entrambi :D


Bravissimo :)))))

E' possibile precompilare un assembly in codice nativo, ma la versione CIL con i metadati e' comunque sempre presente e il codice compilato e' messo in una specie di cache usata poi dal JIT.

%SystemRoot%\assembly
li ci sono la GAC, gli assembly nativi, e le dir temporanee dove viene sbrodolata la roba dal jit :P


Inoltre gli assembly sono eseguibili in formato PE/Coff che contengono codice CIL che non viene mai eseguito direttamente ma sempre compilato dal JIT (ed il meccanismo di compilazione e' davvero molto "cool") prima dell'esecuzione o al momento dell'installazione.


l'IL non è eseguibile! è un linguaggio per il quale non hai hardware che lo possa interpretare direttamente (a meno che qualcuno nn produca una cpu che sappia interpretare direttamente l'il, ma di questo se ne è straparlato nel caso di java).
E' quindi impossibile eseguirlo direttamente :) Se invece per "eseguirlo direttamente" tu intendi interpretarlo (ovvero guardare una istruzione alla volta e eseguirne la semantica) allora è come dici tu (dato che questo sarebbe tecnicamente possibile) :)
Non solo, la compilazione è addirittura on demand sui metodi che usi ^^ se hai un metodo mai utilizzato dalla tua applicazione, molto probabilmente nn sarà mai compilato!
Ciliegina sulla torta: la compilazione avviene sfruttando tutte le capacità specifiche della cpu sotto (compatibilmente a tempi di lancio ragionevoli).

Originariamente inviato da Superboy
Bravissimo :)))))

%SystemRoot%\assembly
li ci sono la GAC, gli assembly nativi, e le dir temporanee dove viene sbrodolata la roba dal jit :P



l'IL non è eseguibile! è un linguaggio per il quale non hai hardware che lo possa interpretare direttamente (a meno che qualcuno nn produca una cpu che sappia interpretare direttamente l'il, ma di questo se ne è straparlato nel caso di java).
E' quindi impossibile eseguirlo direttamente :) Se invece per "eseguirlo direttamente" tu intendi interpretarlo (ovvero guardare una istruzione alla volta e eseguirne la semantica) allora è come dici tu (dato che questo sarebbe tecnicamente possibile) :)
Non solo, la compilazione è addirittura on demand sui metodi che usi ^^ se hai un metodo mai utilizzato dalla tua applicazione, molto probabilmente nn sarà mai compilato!
Ciliegina sulla torta: la compilazione avviene sfruttando tutte le capacità specifiche della cpu sotto (compatibilmente a tempi di lancio ragionevoli).

Allora era come dicevo io O__O

Originariamente inviato da Superboy
Non solo, la compilazione è addirittura on demand sui metodi che usi ^^ se hai un metodo mai utilizzato dalla tua applicazione, molto probabilmente nn sarà mai compilato!
Ciliegina sulla torta: la compilazione avviene sfruttando tutte le capacità specifiche della cpu sotto (compatibilmente a tempi di lancio ragionevoli).

Addirittura e' in grado di capire quali metodi sono usati piu' frequentemente e raggrupparne il codice compilato in pagine di memoria adiacenti in modo da minimazzare il working set.
Don Box infatti dice che spesso e' volentieri e' preferibile NON pre-compilare l'assembly in nativo per sfruttare come dici tu le capacita' specifiche della CPU e queste ottimizzazioni dinamiche del working set.

Per Mega:
Questa e' la miglior descrizione del CLR che ho trovato e sulla quale ho studiato:

http://www.amazon.co.uk/exec/obidos/ASIN/0201734117/qid=1112094612/sr=8-2/ref=sr_8_xs_ap_i2_xgl/026-5881035-2469239

Don Box ne fa un quadro molto chiaro, anche dal punto di vista storico, dal quale si comprende sia lo scopo del .NET sia le profonde differenze con Java. Sostanzialmente risolvono due problemi diversi.

OT:

sul sito www.sirene.it plonunciato alla cinese :D parlando del g5 + veloce dice queste cose. ma è vero?



Il processore PowerPC G5 incrementa notevolmente le prestazioni delle varie applicazioni. Messi a confronto con i PC in numerosi test di Photoshop, i sistemi Power Mac G5 dual a 2,5GHz, dual a 2GHz e dual a 1,8GHz hanno avviato 45 filtri risultando il 98%, 82% e 66% più veloci rispetto a un sistema basato su Pentium 4 a 3,4GHz e il 73%, 63% e 48% più veloci rispetto a un sistema dual Xeon a 3,2GHz. Altri test dimostrano che incrementi di prestazioni simili possono essere riscontrati nella creazione di film, video e audio a livelli professionali nonché nell'analisi scientifica della ricerca genetica.

i due programmi sono creati su piattaforma completamente diverse, con ottimizzazioni diverse. Sono TOTALMENTE incomparabili. ;)

Originariamente inviato da Cfranco
Come ti é stato detto questo non é affatto vero , né i sorgenti né le API di windows sono interamente originali , i primi contengono diverso codice BSD ( mentre Linux é *interamente* scritto da zero ),
Il codice BSD è relegato esclusivamente al networking: una piccola parte del s.o.
le seconde sono basate sullo standard Posix,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_port_from_unix_to_win32.asp
"Running UNIX applications on Windows NT using the POSIX subsystem

The first option UNIX programmers look at is the Windows NT POSIX subsystem. However, it only supports POSIX 1003.1, which was the only POSIX version standardized when Windows NT was created. Since then, there has been little demand for extending this subsystem, because most applications have been converted to Win32. The 1003.1 system is of limited interest for fully featured applications, because it does not include many capabilities (such as those in 1003.2, network support, and so on). Full featured applications run under the Windows NT POSIX subsystem do not have access to Windows NT features available to Win32 applications, such as memory-mapped files, networking, and graphics. Applications such as VI, LS, and GREP are the main targets for the Windows NT POSIX subsystem."

Inoltre non mi sembra che le API siano basate su POSIX, anzi sembrano alquanto diverse. Prendiamo quella della creazione di un processo, ad esempio:

"CreateProcess

The CreateProcess function creates a new process and its primary thread. The new process runs the specified executable file in the security context of the calling process.

If the calling process is impersonating another user, the new process uses the token for the calling process, not the impersonation token. To run the new process in the security context of the user represented by the impersonation token, use the CreateProcessAsUser or CreateProcessWithLogonW function.

BOOL CreateProcess(
LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);"

Mi sembra che abbia ben poco a che spartire con una banale fork().
per finire neppure i concetti guida del SO sono originali in quanto frutto di una rielaborazione di concetti già presenti in altri prodotti .
I concetti non c'entrano niente col discorso: sono frutto di studi fatti da parecchi anni. Ma una cosa sono gli studi accademici, e tutt'altra cosa sono le implementazioni e le filosofie che stanno alla base dell'implementazione di un intero s.o...

Se Unix/Linux e Windows sono diversi, ci sarà qualche motivo che va oltre i "concetti"...
Tanto é vero che riesco a compilare programmi in C capaci di interagire con Aix , Sun e Windows usando le stesse chiamate di sistema .
Allora dovremmo chiedere a chi ha sviluppato CygWin perché ha scritto delle librerie inutili. Anzi, dovresti spiegarlo a chi mi ha chiesto di utilizzare quest'ambiente / librerie quando ho dovuto sviluppare delle applicazioni cross-platform.

Tu, comunque, parli di C, che è UN linguaggio e che ho usato poco. Qui stiamo parlando delle API di un s.o., non delle librerie e dell'interfaccia che un AMBIENTE DI PROGRAMMAZIONE espone al programmatore, che sono tutt'altra cosa.
Segue lo standard Posix , come Unix , Linux e Windows ...
Windows ne segue un sottoinsieme. Per fortuna.

In ogni caso ti ricordo che qui stiamo parlando di API di un s.o., non di POSIX, che è una API standard industriale di compatibilità per le applicazioni scritte in C. Compatibilità legata quindi a un ben preciso linguaggio, e relegata a delle librerie.
Se dici che Linux é una collezione di software Free la cosa é esatta ma fuorviante , Linux é free e ciò che é stato scritto per Linux ( o meglio GNU/Linux ) é free per definizione , Linux non ha saccheggiato niente .
Neppure da BSD?
E sono le stesse API che usi quando scrivi programmi Windows ...
Vedi sopra: non è affatto vero. Infatti sempre dal link di cui sopra:

"One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not. Depending on the use of fork and the code base, Win32 has two APIs that can be used: CreateProcess and CreateThread. A UNIX application that forks multiple copies of itself can be reworked in Win32 to have either multiple processes or a single process with multiple threads. If multiple processes are used, there are multiple methods of IPC that can be used to communicate between the processes (and perhaps to update the code and data of the new process to be like the parent, if the functionality that fork provides is needed). See Creating a New Interprocess (IPC) Message Class"

Questa è la dimostrazione che le API dei due s.o. hanno ben poco a che spartire.

Sempre a questo proposito:

"Basic UNIX applications, including many CGI applications, should port easily to Visual C++ running on Windows NT. Functions like open, fopen, read, write and others are available in the Visual C++ run-time library. Also, there is a one-to-one mapping between C UNIX APIs and Win32 APIs: open to CreateFile, read to ReadFile, write to WriteFile, ioctl to DeviceIOControl, close to CloseFile, and so on."

Quindi, come puoi vedere, la "compatibilità" delle API POSIX si riduce a delle LIBRERIE DI UN BEN PRECISO AMBIENTE DI SVILUPPO, e soprattutto a UN BEN PRECISO S.O...

In particolare da quest'ultimo punto ti faccio notare che Windows NT e le sue API (su cui sono basati 2000 e NT) non è certo il primo s.o. della "famiglia" Windows che è stato sviluppato, anzi!

Originariamente inviato da Cfranco
Nessuno dubita che Windows sia "originale" , quello che si contesta é questa precisa frase :

Windows é un SO come un altro , simile agli altri in alcune cose e diverso in altre , la cui dose di "originalità" non é superiore a un Linux o a un OS X , anzi trovo quest' ultimo decisamente più innovativo , sia per l' interfaccia grafica sia per il Kernel
Stai parlando di innovazioni: il mio discorso verteva su altro, come ha anche fatto notare chiaramente xeal.
( é il primo microkernel che funziona decentemente :winner: )
Hai mai sentito parlare di AmigaOS, BeOS, QNX, ecc.? ;)
Non credo poi che siano decisive le Api per decretare quale sia originale , in Unix c' é sleep() in Windows si chiama Sleep() ( notare la maiuscola ) ma sempre la stessa cosa é ,
In questo caso sì, ma non è vero in generale, come ti ho scritto nel precedente messaggio.
alla fine le operazioni gestite sono sempre le stesse , e gli algoritmi sono sempre uguali , se voglio disegnare una finestra cambiano i nomi della chiamata ma quella che si apre é sempre una finestra , dov' é l' innovazione ?
Stai astraendo e semplificando un po' troppo il discorso: aprire una finestra con Windows o X non è assolutamente la stessa cosa. Lo è il risultato finale, ma non è questo in discussione. Infatti non si parlava di innovazione, ma di originalità dei sorgenti e delle API.
Innovare é fare qualcosa che nessun altro fa , innovativo era Next con l' interfaccia grafica in Postscript ,
Vedi sopra: non è dell'innovazione che stiamo parlando.
innovativo é stato Os/2 ,
Per cosa?
innovativa é stata Sun con Java,
Per cosa?
innovativo é stato Mosaic .
E' stato semplicemente il primo a implementare le specifiche HTML.

EDIT: corretta una frase (mancava un "non" :p).

Originariamente inviato da Criceto
Se tutti fossero come Microsoft e Dell staremmo ancora all'età della pietra.
Ci vuole qualcuno che porti le innovazioni. Ed è giusto riconoscergli il merito e premiarli.
E Apple da 20 anni nel mondo dei computer sembra quasi l'unica capace di portare innovazioni. Almeno è l'unica che lo fa in modo consistente e a largo spettro: hardware, software, design, ecc.
Sarà, ma ha impiegato quasi 20 anni per passare da Mac OS a OS X...

Originariamente inviato da amd-novello
OT:

sul sito www.sirene.it plonunciato alla cinese :D parlando del g5 + veloce dice queste cose. ma è vero?

Il processore PowerPC G5 incrementa notevolmente le prestazioni delle varie applicazioni. Messi a confronto con i PC in numerosi test di Photoshop, i sistemi Power Mac G5 dual a 2,5GHz, dual a 2GHz e dual a 1,8GHz hanno avviato 45 filtri risultando il 98%, 82% e 66% più veloci rispetto a un sistema basato su Pentium 4 a 3,4GHz e il 73%, 63% e 48% più veloci rispetto a un sistema dual Xeon a 3,2GHz. Altri test dimostrano che incrementi di prestazioni simili possono essere riscontrati nella creazione di film, video e audio a livelli professionali nonché nell'analisi scientifica della ricerca genetica.
Questa mi sembra tanto la pubblicità che fa la Apple sul sito coi suoi soliti "benchmark".

Originariamente inviato da Megasoft
i due programmi sono creati su piattaforma completamente diverse, con ottimizzazioni diverse. Sono TOTALMENTE incomparabili. ;)
Lo STESSO programma si può usare per fare dei confronti: non ci vedo nulla di male...

Originariamente inviato da cdimauro
Stai parlando di innovazioni: il mio discorso verteva su altro, come ha anche fatto notare chiaramente xeal.
Continuiamo a rimescolare le carte ...

Tutto questo discorso nasce da una tua affermazione infelice ( ed erronea ) sull' "originalità" dei prodotti Microsoft rispetto alla concorrenza , originalità che non si riscontra né in fase creativa , né per quanto riguarda il codice effettivo , come ti é già stato spiegato .
Tu stai motivando una presunta originalità al fatto che le stesse funzioni si chiamino in maniera diversa nei due ambienti , per te questo é essere originali ( e magari il codice dietro é uguale ) mentre dare lo stesso nome é "copiare" , neppure Microsoft stessa , famosa per non perdere mai un' occasione di entrare a gamba tesa sugli avversari , ha mai sostenuto una posizione così ridicola .

Originariamente inviato da Cfranco
Tu stai motivando una presunta originalità al fatto che le stesse funzioni si chiamino in maniera diversa nei due ambienti , per te questo é essere originali ( e magari il codice dietro é uguale ) mentre dare lo stesso nome é "copiare" , neppure Microsoft stessa , famosa per non perdere mai un' occasione di entrare a gamba tesa sugli avversari , ha mai sostenuto una posizione così ridicola .

Non saprei esprimermi sul discorso generale, ma sul particolare discorso che riguarda la fork e l'accoppiata CreateProcess/CreateThread, non si tratta certo di chiamare la stessa funzione in maniera diversa, magari con lo stesso codice dietro, anzi.

Il threading model Unix-like basato sul fork e' profondamente diverso da quello Win32 basato sull'accoppiata Processi/Thread: non solo sono concetti totalmente diversi, ma portano a modelli di programmazione da parte dell'utente completamente diversi (come per altro descritto su MSDN).

Su questo punto in particolare mi sento essere d'accordo con cdimauro.

Originariamente inviato da fek
Non saprei esprimermi sul discorso generale, ma sul particolare discorso che riguarda la fork e l'accoppiata CreateProcess/CreateThread, non si tratta certo di chiamare la stessa funzione in maniera diversa, magari con lo stesso codice dietro, anzi.

Il senso generale del discorso verte sulla sua frase di apertura della diatriba "Windows é originale , gli altri hanno copiato " che sta tentando di tirare avanti .
Sul discorso processo vs thread sono stati versati fiumi di inchiostro , Windows é multithreading Linux supporta multiprocessing e il multithtreading , ma non é questo il punto .

Originariamente inviato da Cfranco
Il senso generale del discorso verte sulla sua frase di apertura della diatriba "Windows é originale , gli altri hanno copiato " che sta tentando di tirare avanti .
Sul discorso processo vs thread sono stati versati fiumi di inchiostro , Windows é multithreading Linux supporta multiprocessing e il multithtreading , ma non é questo il punto .

Sul discorso generale come ho detto non mi pronuncio. Cdimauro ha sicuramente degli argomeni interessanti, anche i tuoi argomenti sono consistenti e non ho un'idea personale a riguardo, tale da poter cambiare il senso del discorso che state facendo.

Sul discorso particolare del modello multithreading Win32, invece, sono pienamente d'accordo con cidimauro nel dire che e' decisamente originale e diverso (non necessariamente migliore) rispetto al modello unix-like.

Originariamente inviato da Cfranco
Continuiamo a rimescolare le carte ...
Non è il mio caso: non sono mai ricorso a misura di bassa lega come questa, pur di avere ragione. :rolleyes:
Piuttosto se riconosco che ho torto non ho difficoltà ad ammetterlo, come tra l'altro ho già fatto in passato.
Tutto questo discorso nasce da una tua affermazione infelice ( ed erronea ) sull' "originalità" dei prodotti Microsoft rispetto alla concorrenza , originalità che non si riscontra né in fase creativa , né per quanto riguarda il codice effettivo , come ti é già stato spiegato .
Ti ripeto nuovamente che non mi trovi assolutamente d'accordo:

1) perché MS non ha usato / copiato codice, se non per piccole parti del s.o. (come hanno fatto tutti, tra l'altro: i socket sono stati "presi in prestito" dai sorgenti BSD);

2) perché ha creato delle API originali.

Entrambe le cose le ho motivate, portandoti anche documentazione tangibile che risponde in maniera precisa alle tue altrettanto precise osservazioni.
Tu stai motivando una presunta originalità al fatto che le stesse funzioni si chiamino in maniera diversa nei due ambienti , per te questo é essere originali ( e magari il codice dietro é uguale ) mentre dare lo stesso nome é "copiare" ,
Le API sono abbastanza diverse, e il modello di programmazione pure: come programmatore Windows dovresti esserne a conoscenza, se hai mai avuto modo di dare un'occhiata all'SDK di MS e metterlo a confronto con le guide per la programmazione per gli altri sistemi.

E non si tratta banalmente di cambiare nome a un'API, perché il funzionamento è diverso, come pure il codice che ci sta sotto (se si comportano in modo diverso, è OVVIO che anche il codice dovrà presentare delle differenze).
Il discorso non vale soltanto per la fork(), ma si estende anche a tante altre funzioni: i Mutex, i semafori, le API di sincronizzazioni fra processi / thread, l'allocazione della memoria, perfino nella gestione dei file.

E' chiaro che alla fine si risolvono gli stessi problemi, ma lo si fa in un altro modo, con una filosofia diversa, e quindi con API diverse.
Vedi anche LongHorn, che porta con sé una nuova ventata di originalità nel codice e nelle API.

Faccio un esempio, giusto per farti capire meglio il mio pensiero.
Come programmatore se devo scrivere un'applicazione che si presenta in un certo modo e fa certe cose, avrò tanti modi per farlo, ma a seconda del s.o. / ambiente di sviluppo, lo farò in modo diverso, anche MOLTO diverso.
Se devo visualizzare una finestra con un bottone sopra, con Windows lo farò in un modo (se uso direttamente le sue API, e anche qui se vai a controllare sono abbastanza diverse da X, dalle librerie QT, ecc.), con Linux in un altro, con OS X in un altro ancora, ecc.

Il tuo problema è che probabilmente utilizzi da tempo librerie e framework e non ti sei interessato di andare a vedere come funziona sotto sotto un s.o. come Windows. Non a caso hai parlato di POSIX, che con le API vere e proprie di un s.o. c'entra ben poco.
neppure Microsoft stessa , famosa per non perdere mai un' occasione di entrare a gamba tesa sugli avversari , ha mai sostenuto una posizione così ridicola .
Le posizioni si sostengono con i fatti, e mi sembra di averne portati abbastanza, che ti hanno anche smentito (vedi POSIX e fork(), ad esempio).

Originariamente inviato da Cfranco
Il senso generale del discorso verte sulla sua frase di apertura della diatriba "Windows é originale , gli altri hanno copiato " che sta tentando di tirare avanti .
Non sto tentando affatto: la porto avanti perché non sei stato in grado si smentirmi.
E poi la mia frase non era quella, ma diceva due cose BEN PRECISE. :rolleyes:
Sul discorso processo vs thread sono stati versati fiumi di inchiostro , Windows é multithreading Linux supporta multiprocessing e il multithtreading , ma non é questo il punto .
Già: il punto è che se scrivo un'applicazione per Linux devo usare la fork(), mentre con Windows ho la libertà di pensare a come "suddividere" nel modo migliore la mia applicazione, se creare n processi e per ogni processo se creare m thread.

Non puoi dirmi che è la stessa cosa. Il risultato che l'utente vede può essere lo stesso, ma è il COME lo riesci a fare che è COMPLETAMENTE DIVERSO.

Poi è chiaro che se usi delle librerie / framework / ambienti, puoi "appiattire" tutto, eliminando quasi del tutto le differenze fra sistemi operativi anche completamente diversi.

Ad esempio posso scrivere un'applicazione in C che funzionerà su qualunque macchina perché avrò avuto cura di usare le librerie standard e/o quelle POSIX.

Ad esempio posso scrivere un'applicazione CLX con Delphi che compilerà e funzionerà indifferentemente con Windows o Linux (x86).

Ad esempio posso scrivere un'applicazione in Java (o .NET), che funzionerà su qualunque piattaforma che implementi una JVM.

Alla fine le tre applicazioni di cui sopra possono anche fare esattamente la stessa cosa, ma in maniera completamente diversa (e usando le API di Windows lo si potrebbe fare in un altro modo ancora).

Spero di essere stato abbastanza chiaro. Ed è anche chiaro che preferisco il modello di API di Windows a quello di Linux e derivati, perché lo ritengo più flessibile come programmatore.

Originariamente inviato da cdimauro
....
Spero di essere stato abbastanza chiaro. Ed è anche chiaro che preferisco il modello di API di Windows a quello di Linux e derivati, perché lo ritengo più flessibile come programmatore.

Guarda , invece di andare a menare il can per l' aia spiegami questa tua frase :
"Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti)."
Visto che quando ti dico che nel codice Microsoft c' é roba BSD tu mi dici che "le API sono originali"
Quando ti dico che in Windows c' é ben poco che non si sia già visto ( anche a livello di API ) , tu mi rispondi "ma io parlavo di codice"
Dimmi cosa c' é di originale al 100% nei SO di Bill Gates che non sia originale al 100% in Linux o MacOs X o BSD .

PS
Se non conosci come funziona Linux evita certe sparate :
il punto è che se scrivo un'applicazione per Linux devo usare la fork(), mentre con Windows ho la libertà di pensare a come "suddividere" nel modo migliore la mia applicazione, se creare n processi e per ogni processo se creare m thread.
Mai sentito parlare di pthread ? :rolleyes:

Scusate se mi intrometto ma a proposito del pthread vs fork() ho trovato questo link:

http://www.llnl.gov/computing/tutorials/workshops/workshop/pthreads/fork_vs_thread.txt


e volevo chiedervi:

è una mia errata compilazione oppure davvero utilizzando 'pthread' si ottengono guadagni davvero notevoli?

Thx.

RaouL.

Originariamente inviato da RaouL_BennetH

è una mia errata compilazione oppure davvero utilizzando 'pthread' si ottengono guadagni davvero notevoli?

Thx.

RaouL.

Prima di tutto stai creando 50000 processi nel primo programma e 50000 thread nel secondo, in ambo i casi sono un numero enorme.
La creazione di un processo ha chiaramente un overhead parecchio superiore a quello della creazione di un thread dovuto a tutte le strutture dati che vanno inizializzate e create.
Questo test però è solo di creazione, l'aspetto forse + importante e per il quale i thread (processi leggeri) son stati creati è quello della maggior leggerezza della schedulazione, cosa che ovviamente dal test non emerge :)

Se non conosci la differenza tra i due concetti qui espressi ti ricerco di mettere "thread vs processi" in google (senza virgolette) e leggere 1 po'! ;)

Risultati presi da DriverHeaven fatti con un benchmark distribuito gratuitamente sul sito, a chi diceva qualche pagina prima della superiorità dei G5 sulle piattaforme X86. :D

Some Comparison results

Comparison results 1 (High End Overclocked Intel PC):
Intel Extreme Edition processor 3.73 ghz @ 4.1ghz (64 bit processor), Asus P5AD2-E Motherboard 1002 bios, 2 gig of OCZ ram running at 800mhz 8-2-3-4. OCZ 520 Powerstream supply. Maxtor 300gig 16 meg Cache HD, Windows XP 64 bit Professional. Photoshop CS.
Other test results will be added shortly on other systems, for more results and to compare with our members, please visit this thread on our forums.

1: Texturiser Test (1)
2.5 seconds
2: CYMK Colour Conversion
3.1 seconds
3: RGB Colour Conversion
5.5 seconds
4: Dust and Scratches
6.1 seconds
5: Watercolour
21.3 seconds
6: Texturiser Test (2)
2.6 seconds
7: Stained Glass
9.5 seconds
8: Lighting Effects
5.2 seconds
9: Mosiac Tiles
12.1 seconds
10: Extrude
38 seconds
11: Smart Blur
22 seconds
12. Underpainting
18 seconds
Total time: 145.9 seconds.

__________________________________________

Comparison Results 3 (High End Macintosh System):
http://homepage.mac.com/znowdog/ - thanks : Lars Broberg
PowerMac G5, dual 2.5, 2GB ram, WD Raptor, Photoshop CS

1: Texturiser Test (1)
10.1 seconds
2: CYMK Colour Conversion
2.2 seconds
3: RGB Colour Conversion
2.4 seconds
4: Dust and Scratches
3.5 seconds
5: Watercolour
29.9 seconds
6: Texturiser Test (2)
8.5 seconds
7: Stained Glass
10.8 seconds
8: Lighting Effects
4.4 seconds
9: Mosiac Tiles
40.4 seconds
10: Extrude
65.8 seconds
11: Smart Blur
60.3 seconds
12. Underpainting
38.4 seconds
Total time: 276.7 seconds.

Originariamente inviato da Superboy
Prima di tutto stai creando 50000 processi nel primo programma e 50000 thread nel secondo, in ambo i casi sono un numero enorme.
La creazione di un processo ha chiaramente un overhead parecchio superiore a quello della creazione di un thread dovuto a tutte le strutture dati che vanno inizializzate e create.
Questo test però è solo di creazione, l'aspetto forse + importante e per il quale i thread (processi leggeri) son stati creati è quello della maggior leggerezza della schedulazione, cosa che ovviamente dal test non emerge :)

Se non conosci la differenza tra i due concetti qui espressi ti ricerco di mettere "thread vs processi" in google (senza virgolette) e leggere 1 po'! ;)

Grazie :)

Il concetto mi è chiaro, e mi riferivo all'indicazione fatta da Cfranco sui pthread da utilizzare al posto della fork() su macchine *nix.

Thx.

RaouL.

Originariamente inviato da Cfranco
Guarda , invece di andare a menare il can per l' aia spiegami questa tua frase :
Qui l'unico che sta cercanco di rigirare la frittata mi pare che sia tu: io ho sempre spiegato chiaramente quel che penso, come quella frase, appunto, che si commenta da sola.
Comunque te la rispiego dopo.
Visto che quando ti dico che nel codice Microsoft c' é roba BSD tu mi dici che "le API sono originali"
Quando ti dico che in Windows c' é ben poco che non si sia già visto ( anche a livello di API ) , tu mi rispondi "ma io parlavo di codice"
1) Non ho mai cercato di rigirare la frittata, come vorresti far credere.
2) Ho sempre detto chiaramente quel che penso.
3) Qui l'unico che continua a cambiare discorso sei tu.

Te lo ripeto nuovamente, per rispondere a entrambe le cose:

1) perché MS non ha usato / copiato codice, se non per piccole parti del s.o. (come hanno fatto tutti, tra l'altro: i socket sono stati "presi in prestito" dai sorgenti BSD);

2) perché ha creato delle API originali.

Quindi, come vedi, non ho negato che nel codice di Windows sia presente del codice BSD, ma ho già detto e sai benissimo che si tratta di piccole parti.

Sull'originalità delle API te l'ho già scritto e dimostrato portando documentazione sulle differenze che esistono, ad esempio, per la creazione dei processi. Comunque su questo, visto che continui a insistere, torno più avanti.
Dimmi cosa c' é di originale al 100% nei SO di Bill Gates che non sia originale al 100% in Linux o MacOs X o BSD .i.
Te l'ho già scritto: codice e API.
PS
Se non conosci come funziona Linux evita certe sparate :
Mi sembra che qui l'unico che fa pasticci confondendo le API di un s.o. con quelle di librerie e framework sia proprio tu. :rolleyes:

Non solo: quando si parla di codice e API (originali) sposti il discorso su idee, concetti e "innovazione".
Mai sentito parlare di pthread ? :rolleyes:
Certamente. Direttamente dal link di RaouL_BennetH (http://www.llnl.gov/computing/tutorials/pthreads/):
What are Pthreads?

Historically, hardware vendors have implemented their own proprietary versions of threads. These implementations differed substantially from each other making it difficult for programmers to develop portable threaded applications.

In order to take full advantage of the capabilities provided by threads, a standardized programming interface was required. For UNIX systems, this interface has been specified by the IEEE POSIX 1003.1c standard (1995). Implementations which adhere to this standard are referred to as POSIX threads, or Pthreads. Most hardware vendors now offer Pthreads in addition to their proprietary API's.

Pthreads are defined as a set of C language programming types and procedure calls, implemented with a pthread.h header/include file and a thread library - though the this library may be part of another library, such as libc.

There are several drafts of the POSIX threads standard. It is important to be aware of the draft number of a given implementation, because there are differences between drafts that can cause problems.

[...]

The Pthreads API is defined in the ANSI/IEEE POSIX 1003.1 - 1995 standard. Unlike MPI, this standard is not freely available on the Web - it must be purchased from IEEE.

[...]
The current POSIX standard is defined only for the C language. Fortran programmers can use wrappers around C function calls. Also, the IBM Fortran compiler provides a Pthreads API. See the XLF Language Reference, located with IBM's Fortran documentation for more information.

Le parti in grassetto e sottolineate sono le mie, e si commentano da sole.

Quanto alle API: http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-3.html
System Calls

System calls are like special functions that manage OS routines which live in Kernel Mode.

A system call can be called when we:

access an I/O device or a file (like read or write)
need to access privileged information (like pid, changing scheduling policy or other information)
need to change execution context (like forking or executing some other application)
need to execute a particular command (like ''chdir'', ''kill", ''brk'', or ''signal'')

System calls are almost the only interface used by User Mode to talk with low level resources (hardware). The only exception to this statement is when a process uses ''ioperm'' system call. In this case a device can be accessed directly by User Mode process (IRQs cannot be used).

NOTE: Not every ''C'' function is a system call, only some of them.

Below is a list of System Calls under Linux Kernel 2.4.17, from [ arch/i386/kernel/entry.S ]

.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
.long SYMBOL_NAME(sys_waitpid)
.long SYMBOL_NAME(sys_creat)
.long SYMBOL_NAME(sys_link)
.long SYMBOL_NAME(sys_unlink) /* 10 */
.long SYMBOL_NAME(sys_execve)
.long SYMBOL_NAME(sys_chdir)
.long SYMBOL_NAME(sys_time)
.long SYMBOL_NAME(sys_mknod)
.long SYMBOL_NAME(sys_chmod) /* 15 */
L'elenco delle API è abbastanza lungo: ho riportato soltanto le prime.

Quando vuoi sono disponibile ad analizzare una per una anche tutte le API del kernel di Linux (scusa il gioco di parole), confrontarle con quelle che sono state create da quasi quarant'anni a questa parte dall'introduzione di UNIX, e ancora con le "equivalenti" che Windows mette a disposizione.

Questo per evidenziare due cose:

1) che le API di Linux sono sostanzialmente le stesse (con ciò intendo: prendo la fork(), la open(), la read(), ecc. e analizzo funzionamento, interfaccia e parametri) di Unix, per le routine disponibili per entrambi i kernel;

2) che le API di Windows sono nettamente diverse (e originali).

Sempre dal link che ho riportato, ecco altre informazioni in merito alla discussione: http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-5.html
5.4 Kernel Threads

Even though Linux is a monolithic OS, a few ''kernel threads'' exist to do housekeeping work.

These Tasks don't utilize USER memory; they share KERNEL memory. They also operate at the highest privilege (RING 0 on a i386 architecture) like any other kernel mode piece of code.

Kernel threads are created by ''kernel_thread [arch/i386/kernel/process]'' function, which calls ''clone'' [arch/i386/kernel/process.c] system call from assembler (which is a ''fork'' like system call):
http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-6.html
6.7 Fork
Overview

Fork is used to create another task. We start from a Task Parent, and we copy many data structures to Task Child.



| |
| .. |
Task Parent | |
| | | |
| fork |---------->| CREATE |
| | /| NEW |
|_________| / | TASK |
/ | |
--- / | |
--- / | .. |
/ | |
Task Child /
| | /
| fork |<-/
| |
|_________|

Fork SysCall

What is not copied

New Task just created (''Task Child'') is almost equal to Parent (''Task Parent''), there are only few differences:

obviously PID
child ''fork()'' will return 0, while parent ''fork()'' will return PID of Task Child, to distinguish them each other in User Mode
All child data pages are marked ''READ + EXECUTE'', no "WRITE'' (while parent has WRITE right for its own pages) so, when a write request comes, a ''Page Fault'' exception is generated which will create a new independent page: this mechanism is called ''Copy on Write'' (see Cap.10 for more).
Per adesso è tutto. Vediamo se avrai da ridire anche su queste informazioni prese da linux.org... :rolleyes:

Originariamente inviato da cdimauro
Per adesso è tutto. Vediamo se avrai da ridire anche su queste informazioni prese da linux.org... :rolleyes:
Prendi sempre e soltanto quello che ti piace , sottolineando solo frasi isolate dal contesto .
Intanto chiariamo un discorso :
Le API di Windows sono chiamate a librerie C , non vedo perché continui a distinguere quello che c' é in *.so da quello che puoi trovare in un *.DLL , di più Le API di Windows sono scritte per essere interfacciate a programmi scritti in C/C++ tutti gli altri linguaggi devono far uso di Wrapper appropriati .
Punto secondo :
1) perché MS non ha usato / copiato codice, se non per piccole parti del s.o. (come hanno fatto tutti, tra l'altro: i socket sono stati "presi in prestito" dai sorgenti BSD);

2) che le API di Windows sono nettamente diverse (e originali).

1:
A) La parte di networking non é né piccola né marginale in un SO .
B) Non mi risulta che Linux sia fatto di codice copiato in misura maggiore rispetto a Windows , questa é una tua affermazione che insinui fin dall' inizio senza portare alcuna prova .

2:
Non ritengo che cambiare i nomi alle funzioni che fanno le stesse cose sia "innovazione" , in pratica tu ritieni che Microsoft sia da premiare perché ha dato alle chiamate di sistema nomi diversi alle stesse chiamate .

Originariamente inviato da cdimauro
3) Qui l'unico che continua a cambiare discorso sei tu.

Io sto ancora aspettando che tu giustifichi la tua affermazione originale :
"Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti)."
Il senso di questa frase é chiarissimo , prenditi la responsabilità delle tue affermazioni senza sbrodolarti in post chilometrici dove non dici niente su quello che ti viene chiesto , anzi l' unica cosa che dici é
2) Ho sempre detto chiaramente quel che penso.
Ma di questa chiarezza finora non ho trovato traccia .

Originariamente inviato da Cfranco
Prendi sempre e soltanto quello che ti piace , sottolineando solo frasi isolate dal contesto .
Intanto chiariamo un discorso :
Le API di Windows sono chiamate a librerie C , non vedo perché continui a distinguere quello che c' é in *.so da quello che puoi trovare in un *.DLL , di più Le API di Windows sono scritte per essere interfacciate a programmi scritti in C/C++ tutti gli altri linguaggi devono far uso di Wrapper appropriati .

Hihihi le ha saltate xkè sinceramente si danno per scontate certe nozioni...

A) La parte di networking non é né piccola né marginale in un SO .
B) Non mi risulta che Linux sia fatto di codice copiato in misura maggiore rispetto a Windows , questa é una tua affermazione che insinui fin dall' inizio senza portare alcuna prova .

A)Si è gia discusso che il codice di Spier è stato utilizzato solo nella primissima release di nt, per una parte sola dello stack, il quale è stato poi totalmente riscritto nella release successiva (tra l'altro a brevissima distanza temporale) la quale ha iniziato a fare la fortuna di NT.

B) stai travisando nuovamente come ti abbiamo gia detto più volte il piano della discussione !!!

Non ritengo che cambiare i nomi alle funzioni che fanno le stesse cose sia "innovazione" , in pratica tu ritieni che Microsoft sia da premiare perché ha dato alle chiamate di sistema nomi diversi alle stesse chiamate .

A) non stiam parlando di innovazione, idee migliori et simiglia ma di codice, come ti abbiamo gia detto più volte non è questo che si discute! cavoli è scritto almeno 4 volte in questa pagina possibile che tu ignori ancora il messaggio?

B) Microsoft non ha cambiato nome alle funzioni, si è inventata un suo modello di sistema operativo! il kernel è ibrido monolitico/microkernel, e la struttura delle api è totalmente originale, ne consegue come è gia stato scritto un modello di programmazione completamente diverso.

Io sto ancora aspettando che tu giustifichi la tua affermazione originale :
"Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti)."
Il senso di questa frase é chiarissimo , prenditi la responsabilità delle tue affermazioni senza sbrodolarti in post chilometrici dove non dici niente su quello che ti viene chiesto , anzi l' unica cosa che dici é

Ma di questa chiarezza finora non ho trovato traccia .

Non capisco cosa ci sia da obiettare, è tutto vero... dal primo BSD in poi tutto ciò che nè deriva sono fork più o meno recenti ! Non progetti originali!
Lui sta argomentando quello che dice al contrario di te che sostieni posizioni senza apportare argomentazioni (sempre che finalmente abbia capito che il piano della discussione non è sull'innovazione e/o originalità delle interfacce)

Originariamente inviato da Superboy
B) Microsoft non ha cambiato nome alle funzioni, si è inventata un suo modello di sistema operativo! il kernel è ibrido monolitico/microkernel, e la struttura delle api è totalmente originale, ne consegue come è gia stato scritto un modello di programmazione completamente diverso.


Mi sono letto tutta la discussione e se prima non avevo le idee chiarissime, ora anch'io la vedo come hai detto tu qui.

Aggiungo alla discussione il fatto che l'API delle Win32, fra l'altro, e' solo un wrapper C sul resto del sistema che e' scritto in C++, mentre in passato era scritto anch'esso in C. Lo so, anch'io non credevo a questa notizia fino a quando non l'ho sentita da una fonte molto autorevole.

Non prendete pero' questa notizia come la Verita' Rivelata, perche' non e' scritto da nessuna parte, MS non lo ha mai affermato pubblicamente e non esiste alcun link che ne parli.

Originariamente inviato da fek
Aggiungo alla discussione il fatto che l'API delle Win32, fra l'altro, e' solo un wrapper C sul resto del sistema che e' scritto in C++, mentre in passato era scritto anch'esso in C. Lo so, anch'io non credevo a questa notizia fino a quando non l'ho sentita da una fonte molto autorevole.

Cita la fonte su su :D :D :D :D

Originariamente inviato da Superboy
Cita la fonte su su :D :D :D :D

"Gente" in MS che lavora sul Kernel di WinXP.

Originariamente inviato da fek
"Gente" in MS che lavora sul Kernel di WinXP.

Ela madonnaa.... :) nn mi son trattenuto...

cmq hai info + precise? immagino tu ti riferisca ai vari servizi dell'executive layer (gestione di IO,GDI,memoria,processi)... e quando parli di wrapper ti riferisci ai subsystem (win32, posix, os2) che si appoggiano su quest'ultimo?
Le api dell'executive nn sono documentate, ma immagino che siano 1-1 mappate nel subsystem win32 no?

Originariamente inviato da Superboy
B) Microsoft non ha cambiato nome alle funzioni, si è inventata un suo modello di sistema operativo! il kernel è ibrido monolitico/microkernel, e la struttura delle api è totalmente originale, ne consegue come è gia stato scritto un modello di programmazione completamente diverso.

:nono:

Siamo al ridicolo ...

:muro:

Ragazzi mi sono rotto di sprecare il fiato a combattere contro i depliant pubblicitari di Bill Gates , fra un po' mi direte che ha inventato lui il concetto di SO e che gli altri lo hanno solo copiato .
Buonanotte

Originariamente inviato da Cfranco
:nono:

Siamo al ridicolo ...

:muro:

Ragazzi mi sono rotto di sprecare il fiato a combattere contro i depliant pubblicitari di Bill Gates , fra un po' mi direte che ha inventato lui il concetto di SO e che gli altri lo hanno solo copiato .
Buonanotte

Si vede che non hai idea di come windows funzioni quindi tanto meno in grado di fare un paragone con un kernel monolitico come linux....
scusami eh, ma il "siamo al ridicolo" proprio è fuori luogo...

Originariamente inviato da Superboy
Si vede che non hai idea di come windows funzioni ...

:rolleyes:
Comunque se ne sei convinto ... sono affaracci tuoi , solo non andarlo a dire a quelli che ne fanno materia di studio , rischieresti di farli morire dalle risate .

Originariamente inviato da Cfranco
:rolleyes:
Comunque se ne sei convinto ... sono affaracci tuoi , solo non andarlo a dire a quelli che ne fanno materia di studio , rischieresti di farli morire dalle risate .

Cmq è vero, son più ferrato sul funzionamento del kernel linux che di quello di win, ma in ogni caso ne faccio materia di studio, altrimenti non mi permetterei di parlare...
Comunque anzichè portare documenti a favore delle tue "tesi" continui a scrivere commenti sterili finalizzati a distruggere ciò che altri scrivono argomentando fin troppo rispetto quello che fai tu... ti rendi conto che non hai scritto un commento che sia un minimo costruttivo e che porti un qualche riferimento a quello che dici?

Siamo qua per imparare e confrontarci uno con l'altro, ma se si fan i bambini e si mette il broncio "io con te non ci parlo più" non si scrive più nulla di utile, nè per noi stessi nè per le altre persone che leggono magari per sapere o anche solo per curiosità...

Originariamente inviato da Cfranco
Prendi sempre e soltanto quello che ti piace , sottolineando solo frasi isolate dal contesto .
L'unico che ha argomentato finora sono io: a supporto delle tue parole non hai portato che tue elucubrazioni mentali che cozzano contro la realtà dei fatti che ho AMPIAMENTE RIPORTATO E DOCUMENTATO.
Intanto chiariamo un discorso :
Le API di Windows sono chiamate a librerie C ,
Non è affatto vero. Evidentemente sei talmente abituato a programmare con librerie e framework che non riesci a distingue fra le API di un s.o. e quelle offerto da un ambiente di sviluppo. :rolleyes:

Che le API di Windows siano fatte in C o C++ nessuno lo nega, ma questo NON C'ENTRA NULLA COL DISCORSO.
non vedo perché continui a distinguere quello che c' é in *.so da quello che puoi trovare in un *.DLL ,
Perché non stiamo parlando delle API offerte da una generica libreria, ma da quelle del s.o...
Stiamo parlando delle API che ESPONE un s.o. come Windows, confrontandole con quelle di altri s.o., come Linux / Unix.
Stiamo cercando di vedere in che modo queste API influenzano la programmazione in seno a un sistema.
di più Le API di Windows sono scritte per essere interfacciate a programmi scritti in C/C++ tutti gli altri linguaggi devono far uso di Wrapper appropriati .
Questa è la più grossa assurdità che abbia sentito. :rolleyes:

La prima cosa che impari quando studi le API dei sistemi operativi è che normalmente sono definite language agnostic, ossia che NON DIPENDONO da uno specifico linguaggio. Infatti devono essere accessibili a prescindere dal linguaggio di programmazione utilizzato.

Che poi, quando vengono progettate, si debbano effettuare delle scelte che facilitino un linguaggio piuttosto che un altro, è una cosa a dir poco ovvia.
Ad esempio, NORMALMENTE vengono utilizzati dei puntatori ad array di caratteri (terminati da un carattere di valore 0) quando è necessario passare delle stringhe.

Comunque, per spentire la tua poco felice affermazione basta prendere un linguaggio completamente diverso da C/C++ e che è perfettamente in grado di richiamare un'API di Windows (o Linux, visto che ne esiste il porting) direttamente: Delphi, che è Pascal-like, e che tra l'altro ha una gestione COMPLETAMENTE DIVERSA delle stringhe (ne ha due tipi, addirittura, e che hanno poco a che spartire con quelle "offerte" da C).

Se Delphi non ti piace, possiamo prendere anche l'assembly, che è messo anche peggio, visto che non c'è neppure il concetto di stringa.
Punto secondo :

1:
A) La parte di networking non é né piccola né marginale in un SO .
T'hanno già risposto. E comunque ne avevamo già parlato. :mc:
B) Non mi risulta che Linux sia fatto di codice copiato in misura maggiore rispetto a Windows , questa é una tua affermazione che insinui fin dall' inizio senza portare alcuna prova .
Vatti a rileggere tutti i messaggi: sono stanco di ripetere sempre le stesse cose.
2:
Non ritengo che cambiare i nomi alle funzioni che fanno le stesse cose sia "innovazione" , in pratica tu ritieni che Microsoft sia da premiare perché ha dato alle chiamate di sistema nomi diversi alle stesse chiamate .
Purtroppo debbo notare che di tutto quello che ho scritto e anche dei CHIARISSIMI esempi che ho fatto, non hai fatto tesoro: continua pure a pensarla come vuoi. :mc:

Intanto come funziona l'interfaccia s.o. / applicazione e le implicazioni che ha sul modello di programmazione rimarranno concetti a te completamente estranei.
Io sto ancora aspettando che tu giustifichi la tua affermazione originale :
"Almeno MS i s.o. li tira fuori di sana pianta: non va a copiarsi FreeBSD, Mach, ecc. perché è stata incapace di realizzarne uno da sola (dopo anni di prese in giro e annunci altisonanti)."
Il senso di questa frase é chiarissimo , prenditi la responsabilità delle tue affermazioni senza sbrodolarti in post chilometrici dove non dici niente su quello che ti viene chiesto
L'ho già fatto AMPIAMENTE. Al contrario, tu continua pure a non portare NESSUNA ARGOMENTAZIONE e cercare di ribaltare i discorsi con delle INUTILI PAROLE. :mc:
, anzi l' unica cosa che dici é

Ma di questa chiarezza finora non ho trovato traccia .
Per tutti gli altri non è così: l'unico che ha problemi di comprensione qui sei tu. Ma a questo punto non so se ci sei o ci fai. :mc:

Prendendo in prestito una tua frase: se non conosci NEPPURE come funziona un s.o. a livello astratto, evita certe sparate...

EDIT: qualche correzione grammaticale.

Originariamente inviato da Cfranco
:nono:

Siamo al ridicolo ...
E' quel che penso da qualche giorno a questa parte, quando leggo i tuoi messaggi...
:muro:

Ragazzi mi sono rotto di sprecare il fiato a combattere contro i depliant pubblicitari di Bill Gates , fra un po' mi direte che ha inventato lui il concetto di SO e che gli altri lo hanno solo copiato .
Buonanotte
Qui hai tirato fuori il tuo spirito da troll schierato: non sei capace di argomentare e cerchi di chiudere il discorso tacciando tutti di fare l'avvocato di Bill Gates. :mc:

Il problema è che gente come te non è capace di portare avanti una discussione lasciando da parte le proprie personali convinzioni e affrontando un discorso sul piano squisitamente tecnico: appena si parla di Windows, MS, Linux, ecc. la razionalità e il rigore scientifico vanno a farsi benedire e l'obiettivo è di abbattere "il nemico riconosciuto".

Su una cosa hai ragione: è fiato sprecato stare a parlare con uno che continua ad arroccarsi su delle posizioni che sono state fatte a pezzi... :mc:

Originariamente inviato da Cfranco
:rolleyes:
Comunque se ne sei convinto ... sono affaracci tuoi , solo non andarlo a dire a quelli che ne fanno materia di studio , rischieresti di farli morire dalle risate .
Ecco, comincia a farlo tu: studiati come funziona un s.o., come viene progettato e realizzato, qual è il suo compito nei confronti delle applicazioni, e le implicazioni che comportanto certe scelte strutturali dal punto di vista del programmatore (di applicazioni).

Finora quello che farebbe capottare dalle risate persino Linus Torvalds sei tu... :asd: :mc:

Originariamente inviato da Cfranco
:nono:

Siamo al ridicolo ...

:muro:

Ragazzi mi sono rotto di sprecare il fiato a combattere contro i depliant pubblicitari di Bill Gates , fra un po' mi direte che ha inventato lui il concetto di SO e che gli altri lo hanno solo copiato .
Buonanotte

Permettimi, pero' mi sembra un po' arrogante affermare che stai combattendo per cercare di spiegarci qualcosa perche' siamo solo vittime del marketing. Tutto sommato sia io sia superboy sia cidimauro qualcosina sull'argomento la sappiamo. Io non sono ferratissimo sulle API, ma credo di essere in grado di apprezzare gli argomenti che avete portato fino ad ora.

come programmatore delphi (ormai son 8 anni xD) devo dar ragione a superboy & Co. Il delphi NON usa un wrapper (uno strato software che nasconde un componente software), bensi ha un file Windows.pas creato dalla borland che non è altro che una serie di dichiarazioni che fanno riferimento alle funzioni interne di windows.

D'altra parte è anche vero che delphi contiene i formati usati dalle API di Windows.
Infatti fra le stringhe troviamo la Shortstring (stringa a 256 caratteri massimi), String (stringa lunga), PChar (stringa terminante con lo zero). Quest'ultimo è identica a quella usata nelle API.
Stessa cosa per le DWord molto usate nelle API e presenti nel Delphi.

Il mio Pascal e' fermo al Turbo Pascal 8.0 :p ma se non sbaglio le API di windows usano lo stack frame pascal-like. Oppure cdecl?

seee ancora turbo pascal 8? :D

Ora siamo al compilatore Pascal 14.0 (Delphi 7.0) e Pascal 15.0 (Delphi 8.0) e Pascal 16.0 (Delphi 2005)
:D

Su quest'ultima cosa non so che dirti. Quando posso faccio a meno di usare le API. :sofico:

Originariamente inviato da fek
Il mio Pascal e' fermo al Turbo Pascal 8.0 :p ma se non sbaglio le API di windows usano lo stack frame pascal-like. Oppure cdecl?
Per Delphi non ci sono problemi: puoi dichiarare una funzione con qualunque modello ti serve: cdecl (C-like), interrupt, pascal (default), safecall, stdcall (per le API di Windows), register (spero di non averne dimenticato nessuno).

Delphi è molto cambiato come linguaggio: la versione 2005, uscita di recente, permette di scrivere applicazioni Win32 classiche, multipiattaforma (per Linux/x86, tramite il framework CLX) e .NET.

Originariamente inviato da Megasoft
come programmatore delphi (ormai son 8 anni xD) devo dar ragione a superboy & Co. Il delphi NON usa un wrapper (uno strato software che nasconde un componente software), bensi ha un file Windows.pas creato dalla borland che non è altro che una serie di dichiarazioni che fanno riferimento alle funzioni interne di windows.
Esatto. Si tratta per lo più della definizione delle strutture e della dichiarazione come "extern + stdcall" della API di Windows, per richiamarle direttamente. ;)

Lo stesso avviene per Kylix, che è il porting di Delphi per Linux.
D'altra parte è anche vero che delphi contiene i formati usati dalle API di Windows.
Infatti fra le stringhe troviamo la Shortstring (stringa a 256 caratteri massimi), String (stringa lunga), PChar (stringa terminante con lo zero). Quest'ultimo è identica a quella usata nelle API.
Stessa cosa per le DWord molto usate nelle API e presenti nel Delphi.
La cosa interessante è che per chiamare le API di Windows non serve usare le PChar o convertire una stringa (la vecchia ShortString, ormai poco usata, o la nuova AnsiString, che è quella di default = string) in PChar: usando la string (quindi AnsiString) è sufficiente fare un casting con PChar alla stringa da passare. :D

In questo modo si possono usare tranquillamente le flessibili stringhe che Delphi usa di default, senza alcun compromesso di spazio (nessun codice aggiuntivo: un cast non genera niente, e inoltre non serve maggior spazio per il buffer necessario alla conversione) e di velocità (anche qui: un cast non genera niente).

Questo perché per le AnsiString il compilatore aggiunge automaticamente il carattere #0 alla fine di ogni stringa, quando se ne modifica la lunghezza. Poiché le AnsiString sono puntatori al primo carattere della stringa (la lunghezza e la capacità sono convervati ad offset negativi rispetto al puntatore base), ecco che col cast "otteniamo" una stringa C-like. :D

Originariamente inviato da Megasoft
seee ancora turbo pascal 8? :D
Su quest'ultima cosa non so che dirti. Quando posso faccio a meno di usare le API. :sofico:
Beh, le API di Windows le usi e basta perché sono già tutte definite. ;)

Però se devi scrivere un ActiveX, una DLL, un OCX o altro ti serve specificare l'apposito qualificatore per far sì che sia possibile utilizzarli per qualunque programma che non sia scritto in Delphi o in altri ambienti che supportano il modello usato per il passaggio dei parametri. :D

Originariamente inviato da cdimauro
Beh, le API di Windows le usi e basta perché sono già tutte definite. ;)

Però se devi scrivere un ActiveX, una DLL, un OCX o altro ti serve specificare l'apposito qualificatore per far sì che sia possibile utilizzarli per qualunque programma che non sia scritto in Delphi o in altri ambienti che supportano il modello usato per il passaggio dei parametri. :D

Beh quello si chiama COM in tutte le varie salse ^^ uno standard binario per la programmazione a componenti :) per qualificatore intendi l'interfaccia immagino

COM è un altro modello rispetto alle DLL, o sbaglio?

Per qualificatore intendo la keyword da usare per definire in che modo avviene il passaggio dei parametri alla procedura/funzione, e se dev'essere l'applicazione a liberarne lo spazio dallo stack o la routine stessa.

Originariamente inviato da cdimauro
COM è un altro modello rispetto alle DLL, o sbaglio?

Per qualificatore intendo la keyword da usare per definire in che modo avviene il passaggio dei parametri alla procedura/funzione, e se dev'essere l'applicazione a liberarne lo spazio dallo stack o la routine stessa.

che io sappia dentro ad una dll ci può essere di tutto, funzioni C, oggetti c++, oggetti COM (che poi vengano realizzati solo in c++ per comodità è un altro discorso^^)...
Cmq ho capito che intendi, ti riferisci a direttiva del compilatore tipo WINAPI ecc...

Originariamente inviato da Megasoft
seee ancora turbo pascal 8? :D

Ora siamo al compilatore Pascal 14.0 (Delphi 7.0) e Pascal 15.0 (Delphi 8.0) e Pascal 16.0 (Delphi 2005)

Ci ho scritto il mio primo gioco in TP8 :D
Ah, il TP3, che bei tempi...

Poi mi sono trasferito definitivamente al C++ e linguaggi C-like.
Pero' prima o poi do' un'occhiata a Smalltalk.

Originariamente inviato da cdimauro
Per Delphi non ci sono problemi: puoi dichiarare una funzione con qualunque modello ti serve: cdecl (C-like), interrupt, pascal (default), safecall, stdcall (per le API di Windows), register (spero di non averne dimenticato nessuno).

Delphi è molto cambiato come linguaggio: la versione 2005, uscita di recente, permette di scrivere applicazioni Win32 classiche, multipiattaforma (per Linux/x86, tramite il framework CLX) e .NET.

Ehm... sono rimasto un po' indietro sul fronte pascal.

Originariamente inviato da cdimauro
COM è un altro modello rispetto alle DLL, o sbaglio?

Per qualificatore intendo la keyword da usare per definire in che modo avviene il passaggio dei parametri alla procedura/funzione, e se dev'essere l'applicazione a liberarne lo spazio dallo stack o la routine stessa.

No, un oggetto COM puo' essere contenuto in una DLL. La DLL non e' altro che un formato che puo' contenere "generiche" librerie caricabili dinamicamente.

Originariamente inviato da fek
Ci ho scritto il mio primo gioco in TP8 :D
TP8 = Delphi 1.0, se non ricordo male.
Che gioco era?
Ah, il TP3, che bei tempi...
Per chi ci è passato... :D
Poi mi sono trasferito definitivamente al C++ e linguaggi C-like.
Pero' prima o poi do' un'occhiata a Smalltalk.
E' un linguaggio bellissimo. Secondo me sarebbe da rivalutare: adesso le macchine hanno sufficiente potenza di calcolo anche per far girare un linguaggio interpretato come questo.
D'altra parte Python è un linguaggio sostanzialmente interpretato, visto che quasi tutto viene deciso a run-time.
In questo periodo sto usando Python, e devo dire che mi trovo molto bene: è un linguaggio semplice, ma potente, e che permette di scrivere codice molto velocemente, pur rimanendo molto leggibile.
Ehm... sono rimasto un po' indietro sul fronte pascal.
Potresti ritornarci in futuro, visto che prima o poi i giochi si faranno con .NET... :D

x quanto riguarda gli oggetti COM, è chiaro: non avevo capito bene prima... :p

Originariamente inviato da cdimauro
TP8 = Delphi 1.0, se non ricordo male.
Che gioco era?

Per chi ci è passato... :D

E' un linguaggio bellissimo. Secondo me sarebbe da rivalutare: adesso le macchine hanno sufficiente potenza di calcolo anche per far girare un linguaggio interpretato come questo.
D'altra parte Python è un linguaggio sostanzialmente interpretato, visto che quasi tutto viene deciso a run-time.
In questo periodo sto usando Python, e devo dire che mi trovo molto bene: è un linguaggio semplice, ma potente, e che permette di scrivere codice molto velocemente, pur rimanendo molto leggibile.

Potresti ritornarci in futuro, visto che prima o poi i giochi si faranno con .NET... :D

x quanto riguarda gli oggetti COM, è chiaro: non avevo capito bene prima... :p

No, nel passaggio dal TP 7.0 al Delphi 1.0 c'è stato un fantomatico (nessuno lo ha cagato xD) Turbo Pascal For Windows 1.0 che aveva il compilatore a versione 8.0 anche se poi questo compilatore è rimasto con lo stesso numero anche su Delphi 1.0.

Ora come ora Delphi è un linguaggio che ha le stesse potenzialita del C++, e cmq ricordiamoci che appena si passa al .NET tutti i linguaggi si appiattiranno. :rolleyes:

Per questo preferisco Delphi (rispetto al C++): trovo che il codice sia più leggibile, più facile da suddividere in moduli, e la sintassi è più rigorosa.

Comunque ricordo che TP7 prevedeva già di generare eseguibili per Windows (3.x?).

no, TP 7.0 che io ricordi generava solo programmi DOS/16

Originariamente inviato da Megasoft
no, TP 7.0 che io ricordi generava solo programmi DOS/16
Mi avete fatto scompattare il vecchio Pascal 7, cmq nella dir bin ci son anche eseguibili win, io ho sempre usato turbo.exe ^^ ma bpw.exe che era? ora mi manca una dll borland e nn parte :)

BP
The BP package is a functional superset of the TP one, and contains the following compilers: TURBO.EXE, TPC.EXE (as in TP); BP.EXE, BPC.EXE & BPW.EXE (TPX is not needed, given BP). It also has the TASM.EXE assembler.

BP.EXE & BPW.EXE can compile so that program and code can use more than 640 KB of RAM (up to 16 MB on a '286, 512 MB on >='386, AIUI) - this is DPMI or protected mode; both DOS & Windows BP IDEs can compile for all three targets, MSDOS (real mode), DPMI (protected mode), and WINDOWS. BP.EXE seems in general the best tool, except that the IDE cannot itself launch a Windows program, even from within a DOS box. They can generate, and their programs can use, DLLs.

IMHO, BP7 has advantages over TP7, even if one only makes, in the end, DOS mode programs. TPX.EXE, BP.EXE and BPW.EXE, but not TURBO.EXE, include a very useful Browse facility on the Search menu, which finds all use of a specific variable, in the IDE. BP has the TD.EXE and TDX.EXE Debuggers, etc.; as I recall, TD is on the Tools menu (and TDX can be added), which is handy for looking at code; BP7 and BPW can compile DPMI, which enables faulty Heap code to produce Error 216.

BP7 includes RTL sources including the TV RTL source, which TP7 users could buy.

2000-07-27 : Claim seen that BPC.EXE does not run correctly in a DOS box in a new PIII/750 PC, though OK on a PII/450. Unconfirmed.

>64 MB RAM
I have heard that BP.EXE may not work in a PC with more than 64 MB of RAM; the c.l.p.b mini-FAQ refers, recommending the addition of NOVCPI to the DEVICE=EMM386.EXE line in config.* files.

I've also seen
1) SET DpmiMem=8192 - in autoexec.bat
2) Device=EMM386.exe RAM - in config.sys (instead of noEMS key)
suggested.



Preso da una guida su internet...sembra che centri però boh, mai usato in vita mia o.o

Originariamente inviato da cdimauro
TP8 = Delphi 1.0, se non ricordo male.
Che gioco era?


Un giochino di calcio simile a Kickoff II. Non l'ho mai distribuito pero'.


E' un linguaggio bellissimo. Secondo me sarebbe da rivalutare: adesso le macchine hanno sufficiente potenza di calcolo anche per far girare un linguaggio interpretato come questo.
D'altra parte Python è un linguaggio sostanzialmente interpretato, visto che quasi tutto viene deciso a run-time.
In questo periodo sto usando Python, e devo dire che mi trovo molto bene: è un linguaggio semplice, ma potente, e che permette di scrivere codice molto velocemente, pur rimanendo molto leggibile.

Devo impararlo prima o poi, ho letto che ha tool di Refactoring strepitosi. Fino ad ora il miglior tool che ho visto e' quello di Eclipse per Java.


Potresti ritornarci in futuro, visto che prima o poi i giochi si faranno con .NET... :D


Prima o poi scrivo una parte dell'engine in C# :D

(lo sto gia' facendo in realta')

A proposito di dll e Turbo Pascal 7 (Borland Pascal, per la verità):

Writing DLLs

The structure of a Borland Pascal DLL is identical to that of a program,
except that a DLL starts with a library header instead of a program header.

The library header tells Borland Pascal to produce an executable file with
the extension .DLL instead of .EXE. It also ensures that the executable file
is marked as being a DLL.

If procedures and functions are to be exported by a DLL, they must be
compiled with the export procedure directive.

Example:
This implements a very simple DLL with two exported functions:

library MinMax;

{The export procedure directive prepares Min and Max for exporting}

function Min(X, Y: Integer): Integer; export;
begin
if X < Y then Min := X else Min := Y;
end;

function Max(X, Y: Integer): Integer; export;
begin
if X > Y then Max := X else Max := Y;
end;

{The exports clause actually exports the two routines, supplying an
optional ordinal number for each of them}

exports
Min index 1,
Max index 2;

begin
end.

Libraries often consist of several units. In such cases, the library source
file itself is frequently reduced to a uses clause, an exports clause, and
the library's initialization code.

For example:
library Editors;

uses EdInit, EdInOut, EdFormat, EdPrint;

exports
InitEditors index 1,
DoneEditors index 2,
InsertText index 3,
DeleteSelection index 4,
FormatSelection index 5,
PrintSelection index 6,
.
.
SetErrorHandler index 53;

begin
InitLibrary;
end.

Dovrebbe bastare questo per creare funzioni accessibili da programmi realizzati in altri linguaggi :)

Naturalmente, l'utilizzatore dovrà prevedere una qualche corrispondenza tra i tipi, ma per scriverle dovrebbe bastare questo.

Guarda che quella stessa funzione è nella guida di Borland Delphi 7.0. Fortuna che la borland è qualcuna che mantiene gli standard :D

Originariamente inviato da Megasoft
Preso da una guida su internet...sembra che centri però boh, mai usato in vita mia o.o
C'entra, c'entra... :D

Originariamente inviato da fek
Devo impararlo prima o poi, ho letto che ha tool di Refactoring strepitosi. Fino ad ora il miglior tool che ho visto e' quello di Eclipse per Java.
Penso di sì.
Non ricordo dove l'ho letto, ma se non ricordo male una software ha realizzato un progetto per una software house (MS, se la memoria non m'inganna): interamente in Python sia per questione di velocità di scrittura del codice sia per gli strumenti di validazione/testing che permette questo linguaggio / ambiente.
Quando il codice ha completato tutte le fasi richieste, è stato "congelato", e mano a mano le varie parti sono state riscritte in C++ (quella di scrivere codice, moduli, o classi Python, e poi riscriverle in C/C++ per velocizzarle, è una sua caratteristica "nativa").
Prima o poi scrivo una parte dell'engine in C# :D

(lo sto gia' facendo in realta')
Immaginavo... ;)

Originariamente inviato da cdimauro
Penso di sì.
Non ricordo dove l'ho letto, ma se non ricordo male una software ha realizzato un progetto per una software house (MS, se la memoria non m'inganna): interamente in Python sia per questione di velocità di scrittura del codice sia per gli strumenti di validazione/testing che permette questo linguaggio / ambiente.
Quando il codice ha completato tutte le fasi richieste, è stato "congelato", e mano a mano le varie parti sono state riscritte in C++ (quella di scrivere codice, moduli, o classi Python, e poi riscriverle in C/C++ per velocizzarle, è una sua caratteristica "nativa").

Ma questa e' un'idea assolutamente furba. Praticamente hanno fatto una via di mezzo fra un Prototipo e' un Tracer Bullet Developing.
In linguaggi cosi' ad alto livello e' molto veloce prototipizzare il problema e poi, quando il domino della soluzione e' chiaro, puoi buttare via il prototipo e riscrivere la soluzione in C++, oppure tenere il codice (in questo caso non e' piu' un prototipo), e fare refactoring di alcune parti in C++.

Credo che nei prossimi anni si vedranno molti esempi di programmi ibridi, e la piattaforma .NET percorre questa strada. Mi piacerebbe anche vedere altri linguaggi "compilare" in bytecode Java.

Originariamente inviato da fek
Ma questa e' un'idea assolutamente furba. Praticamente hanno fatto una via di mezzo fra un Prototipo e' un Tracer Bullet Developing.
Mi daresti un' infarinata su entrambi i pattern/criteri/metodi ? ;)

In linguaggi cosi' ad alto livello e' molto veloce prototipizzare il problema e poi, quando il domino della soluzione e' chiaro, puoi buttare via il prototipo e riscrivere la soluzione in C++, oppure tenere il codice (in questo caso non e' piu' un prototipo), e fare refactoring di alcune parti in C++.
interessante.. :)

Originariamente inviato da jappilas
Mi daresti un' infarinata su entrambi i pattern/criteri/metodi ? ;)


Non ho capito la domanda, scusami.

il "Prototipo" e il "Tracer Bullet Developing" cosa sono, come funzionano? :)

visto che ne accenni in un contesto di programmazione, code refactoring, ecc intuisco che si tratti di qualcosa di attinente (design pattern?) che però non avevo ancora sentito ...
e siccome dovrei entrare in quel ramo mi interessa approfondire da chi ne sa più di me... ;)

Originariamente inviato da jappilas
il "Prototipo" e il "Tracer Bullet Developing" cosa sono, come funzionano? :)


Il prototipo di un software e' esattamente l'equivalente del prototipo in scala, ad esempio, di una macchina o di un aereo.
Qunado si ha un problema da risolvere e non si conosce la soluzione, si puo' iniziare a buttare giu' un po' di codice esplorando una serie di possibili soluzioni per capirne le loro implicazioni, i problemi che potrebbero emergere, eventuali strade chiuse.
Affinche' il prototipo sia utile, dev'essere molto veloce da scrivere, non e' importante che sia performante, stabile o sicuro, l'importante e' che dia un'idea della soluzione migliore per il problema.
Un prototipo e' tale nel momento in cui viene abbandonato quando ha raggiunto il suo scopo, e la soluzione scelta e' implementata in maniera propria.
Se non viene abbandonato, non e' un prototipo per definizione.

Il Tracer Development Bullet invece e' una metodologia di sviluppo che deriva il nome dai proiettili "traccianti". Per mirare a qualcosa si spara con un proiettile tracciante nella direzione generale del bersaglio e poi si aggiusta man mano il tiro usando le informazioni del tracciante. Nel software significa implementare velocemente una soluzione approssimativa al problema e poi raffinarla man mano che il problema diventa piu' chiaro. E' simile all'idea di Design Evolutivo, utile quando il problema da risolvere non e' perfettamente chiaro e i requisiti non sono stabili e immutabili (nel 99% dei casi quindi), dove il design del software evolve man mano che viene scritto e man mano che sia il problema sia la soluzione diventano piu' chiari. Sono i concetti alla base delle metodologie di sviluppo agili. La differenza con il Prototipo consiste nel fatto che la prima soluzione approssimativa non viene abbandonata e riscritta ma raffinata man mano durante lo sviluppo.

In entrambi i casi usare un linguaggio ad alto livello puo' rivelarsi utile, decisivo nel caso del Prototipo.


visto che ne accenni in un contesto di programmazione, code refactoring, ecc intuisco che si tratti di qualcosa di attinente (design pattern?) che però non avevo ancora sentito ...
e siccome dovrei entrare in quel ramo mi interessa approfondire da chi ne sa più di me... ;)

Ce ne sarebbe da parlare per tre o quattro libri :D

In teoria Refactoring e Design Pattern non sono strettamente legati, almeno cosi' si pensava fino a qualche anno fa. Adesso con l'affermarsi di metodologie di sviluppo "agili", si tende a non implementare i Design Pattern fin da subito, ma a evolvere il Design del software verso l'uso dei Design Patter dove e quando fosse necessario. Il cardine di questo processo di evoluzione e' il Refactoring del codice.
Secondo la definizione di Martin Fowler, Refactoring e' "il processo di miglioramento della struttra del codice mantenendo invariato il suo comportamento osservabile". In altre parole si tratta di rendere migliore la struttura interna del software, eliminando le duplicazioni, semplificandolo, eliminando i "code smell" (i cattivi odori nel codice :p) ma facendo in modo che il comportamento esterno del codice sia invariato, che praticamente risolva esattamente i problemi che risolveva prima della ristrutturazione senza introdurre nuovi bug.

Se sei interessato a questi argomenti ti consiglio i seguenti libri:

Il "classico" Design Patterns:
http://www.amazon.co.uk/exec/obidos/ASIN/0201633612/qid=1112977039/sr=8-2/ref=sr_8_xs_ap_i2_xgl/026-1611787-4794840

La Bibbia del Refactoring, questo non deve mancare in nessuna biblioteca di un programmatore:
http://www.amazon.co.uk/exec/obidos/ASIN/0201485672/qid=1112977072/sr=1-1/ref=sr_1_3_1/026-1611787-4794840

Refactoring To Patterns, che stabilisce un collegamento fra i Design Pattern ed il processo di Refactoring:
http://www.amazon.co.uk/exec/obidos/ASIN/0321213351/qid=1112977072/sr=2-1/ref=sr_2_3_1/026-1611787-4794840

A questi, secondo me, va aggiunto assolutamente questo libro di Kent Beck:
http://www.amazon.co.uk/exec/obidos/ASIN/0321213351/qid=1112977072/sr=2-1/ref=sr_2_3_1/026-1611787-4794840

Quando avrai finito questi libri, il mondo non sara' piu' lo stesso e capirai di non aver mai imparato a programmare :D
A me e' successo cosi'.

e della spiegazione (chiarezza esemplare, molto professionale) :)
e delle "letture consigliate" che appena sto meglio (attualmente sto uscendo da un' "influenza" che mi ha distrutto) cerco in libreria ;)

Quando avrai finito questi libri, il mondo non sara' piu' lo stesso e capirai di non aver mai imparato a programmare :D
ehm... già ora ammetto che, pur avendo nozioni di teoria dei pattern, criteri di design, ciclo produttivo e ciclo di vita del SW, conoscenze di base di pascal/delphi/VB/C/++/#, non ho mai imparato davvero a programmare (oltre "Ciao Mondo" cioè)... :O
dev' essere colpa del mio tipico "timore reverenziale" nei confronti del mezzo che mi ha un po' trattenuto dal fare pratica ed esperienza su problemi reali... mea culpa mea culpa
mi sa che mi conviene darmi una mossa in fretta, prima che cambi troppo anche il mondo intorno a me... :muro:

Originariamente inviato da jappilas
ehm... già ora ammetto che, pur avendo nozioni di teoria dei pattern, criteri di design, ciclo produttivo e ciclo di vita del SW, conoscenze di base di pascal/delphi/VB/C/++/#, non ho mai imparato davvero a programmare (oltre "Ciao Mondo" cioè)... :O


Sei in una posizione per certi versi invidiabile invece.
Se conosci bene la teoria, non hai ancora imparato tutte le pratiche "sbagliate" che chi ha anni di esperienza deve invece dimenticare e puoi concentrarti sulle pratiche che oggi si sa danno i migliori risultati.

Io, ad esempio, sono passato attraverso la programmazione procedurale quindici anni fa, che poi ho dovuto dimentcare per imparare un approccio ad oggetti al design. E sono passato attraverso i classici errori della programmazione ad oggetti, come l'abuso dell'ereditarieta', le classi troppo grandi, i metodi troppo lunghi. Poi ho dovuto dimenticare l'abitudine ad ottimizzare prematuramente. Ed ora sto dimenticando l'approccio alla programmazione classico (scrivi prima il codice e poi vedi se funziona), per passare ad un approccio totalmente nuovo e piu' produttivo: scrivi prima i test per vedere se il codice che stai scriverai funziona.

Come dice Kent Beck nel suo libro: "Ho insegnato a mia figlia di 8 anni a programmare e per lei e' inconcepibile che si possa scrivere una riga di codice senza avere un test che fallisce".

Sua figlia di 8 anni e' un programmatore migliore di me.

Certo, pero', ti mancano anni di esperienza, ma partendo da basi piu' solide non ti sara' difficile recuperarli in fretta ed avere un approccio alla costruzione del codice piu' pulito e meno contaminato da abitudini sbagliate.

Originariamente inviato da fek
Io, ad esempio, sono passato attraverso la programmazione procedurale quindici anni fa, che poi ho dovuto dimentcare per imparare un approccio ad oggetti al design.

Premetto che la mia esperienza nel campo è infinitesimale (ed esclusivamente universitaria), però, dai, un po' di esperienza procedurale male non fa, almeno dovrebbe lasciare un po' di abitudine all'ordine che con la programmazione ad oggetti a volte si rischia di trascurare, rendendo il codice poco leggibile (piccolo esempio: tempo fa, leggendo il codice di una classe d'esempio nell'sdk java quasi mi dannavo a cercare la dichiarazione delle variabili "globali", ovvero le variabili membro, che ho trovato praticamente in fondo alla classe, in mezzo ad alcuni metodi, cosa che non ho gradito molto - con tutto il rispetto per chi ha scritto quel codice, le cui capacità vanno indubbiamente ben oltre le mie).

Sua figlia di 8 anni e' un programmatore migliore di me.

Ricordo che un po' di tempo fa (forse circa un anno) si parlava di bambini e computer, ed è saltato fuori che la figlia di cdimauro (all'ora aveva due anni se ben ricordo) stava imparando a usarlo (be', diciamo ad accenderlo :D). Che le nuove generazioni abbiano un rapporto "precoce" con il computer, nei modi giusti, credo sia molto positivo, che ci soffino il lavoro (io non ce l'ho nemmeno un lavoro :p) prima di aver finito le medie (inferiori) credo lo sia un po' meno :p :D :D

Sei in una posizione per certi versi invidiabile invece.
Se conosci bene la teoria, non hai ancora imparato tutte le pratiche "sbagliate" che chi ha anni di esperienza deve invece dimenticare e puoi concentrarti sulle pratiche che oggi si sa danno i migliori risultati.
...
... come tirare su di morale un aspirante sw engineer e motivarlo per impegnarsi a dare il meglio... :)
...sono passato attraverso i classici errori della programmazione ad oggetti, come l'abuso dell'ereditarieta', le classi troppo grandi, i metodi troppo lunghi. qui mi tornano in mente le lezioni di Informatica II, sotto una docente folle che spiegava OO programming in questi termini... "ragazzi allargate la mente, astraete la realtà... Ippogrifo deriva sia da Cavallo e da Mammifero, sia da Grifone e da Uccello, Mammifero e Uccello a loro volta derivano da Animale, Animale da EssereVivente ed EssereVivente dalla classe primigenia Element..." a parte che sull' implementazione dei costruttori e metodi è meglio sorvolare, mi sto chiedendo ancora come ho fatto a non rimanere contaminato dagli sproloqui della tizia e dalla sua mania per Smalltalk... :DPoi ho dovuto dimenticare l'abitudine ad ottimizzare prematuramente. Ed ora sto dimenticando l'approccio alla programmazione classico (scrivi prima il codice e poi vedi se funziona), per passare ad un approccio totalmente nuovo e piu' produttivo: scrivi prima i test per vedere se il codice che stai scriverai funziona. O_o non male l' idea... si arriverebbe alla fase di stesura del codice vero e proprio dopo aver scritto l' algoritmo della procedura automatizzata che effettua il test formale...
il che se adesso non prendo una cantonata, richiederebbe aver prima "progettato" i flussi operativi, le interazioni, e i datatype coi relativi range, che il programma finale, è chiamato ad avere... il che vorrebbe dire contare su una buona fetta di debugging eseguito o almeno pianificato a priori... bello :)

Come dice Kent Beck nel suo libro: "Ho insegnato a mia figlia di 8 anni a programmare e per lei e' inconcepibile che si possa scrivere una riga di codice senza avere un test che fallisce".
Sua figlia di 8 anni e' un programmatore migliore di me.
rispondo a xeal: il modo per evitare che le nuove generazioni ci soffino il lavoro c'è: consiste nel mantenere alto il livello operativo
un linguaggio di programmazione è appunto un linguaggio, definito da una grammatica formale e da un insieme di regole sintattiche e semantiche: quindi chiunque può imparare a esprimersi in quel linguaggio.... però presumibilmente ci saranno delle differenze su "cosa" verrà detto in quel linguaggio... in ampiezza e struttura dei costrutti, complessità algoritmica, formule impiegate, ecc, nonchè regole formali di verifica e testing, saranno diversi i risultati a cui può arrivare un giovanissimo, oppure un (per dire) laureato in ingegneria con le conoscenze che si presume che abbia e che sono quelle che lo salvano

x jappilas: be', dai, l'idea che un bambino vada a testare il tuo codice e ti costringa ad ascoltare la sigla di un cartoon se non gli piace trovo che sia proprio comica... come immaginare che una bambina per fare uno scherzetto al padre spinga un bottone (magari su una ciabatta) proprio mentre sta per salvare un po' di lavoro... :D

Scherzi a parte, non so quanto la complessità e l'efficienza degli algoritmi e delle formule potrà "salvarci": la potenza di calcolo crescente rende sempre più sacrificabili, entro certi limiti, queste caratteristiche a favore della semplicità e della leggibilità (è sicuramente più semplice e chiaro scrivere max = a >= b ? a : b; piuttosto che max = (((unsigned)(b-a)) >> SIGN_POS)*(a - b) + b; ). Naturalmente servirà sempre la supervisione di qualcuno più esperto e smaliziato. Comunque ti sei laureato? se è così, auguri!

Ricordo che un po' di tempo fa (forse circa un anno) si parlava di bambini e computer, ed è saltato fuori che la figlia di cdimauro (all'ora aveva due anni se ben ricordo) stava imparando a usarlo (be', diciamo ad accenderlo :D).
Già. :D
Adesso ne ha quasi quattro (fra qualche mese), ma a quanto pare propende più per il campo umanitario / artistico (il computer di papà interessa soltanto perché è papà che lo usa :p). Sigh. Sob. :cry:
Che le nuove generazioni abbiano un rapporto "precoce" con il computer, nei modi giusti, credo sia molto positivo, che ci soffino il lavoro (io non ce l'ho nemmeno un lavoro :p) prima di aver finito le medie (inferiori) credo lo sia un po' meno :p :D :D
Lo penso anch'io. Anche perché poi alle superiori incontrano dei professori che insegnano "informatica" :rolleyes:, e i ragazzi me li ritrovo la sera a dovergli fare delle lezioni private... ;) :( :muro:

... come tirare su di morale un aspirante sw engineer e motivarlo per impegnarsi a dare il meglio... :)
qui mi tornano in mente le lezioni di Informatica II, sotto una docente folle che spiegava OO programming in questi termini... "ragazzi allargate la mente, astraete la realtà... Ippogrifo deriva sia da Cavallo e da Mammifero, sia da Grifone e da Uccello, Mammifero e Uccello a loro volta derivano da Animale, Animale da EssereVivente ed EssereVivente dalla classe primigenia Element..."
Per me farebbero meglio a prendere spunto dal manuale alla programmazione a oggetti che la Borland aggiunge agli altri, quando rilasciò il Turbo Pascal 5.5 (con le prime estensioni orientate agli oggetti al Pascal "targato Borland"): riprendendolo in mano ancora oggi, non mi meraviglio che (ai tempi) sia stato classificato come la miglior introduzione alla programmazione a oggetti mai scritta...
Un capolavoro di semplicità e chiarezza.
a parte che sull' implementazione dei costruttori e metodi è meglio sorvolare, mi sto chiedendo ancora come ho fatto a non rimanere contaminato dagli sproloqui della tizia e dalla sua mania per Smalltalk... :D
Peccato: ricordo che una ventina d'anni fa sono rimasto letteralmente stregato da questo linguaggio, leggendo il corso pubblicato a puntate da MC MicroComputer...
Adesso m'è rimasto soltanto qualche vago ricordo, ma un'idea molto chiara: era un bellissimo linguaggio! :p

Scherzi a parte, non so quanto la complessità e l'efficienza degli algoritmi e delle formule potrà "salvarci": la potenza di calcolo crescente rende sempre più sacrificabili, entro certi limiti, queste caratteristiche a favore della semplicità e della leggibilità (è sicuramente più semplice e chiaro scrivere max = a >= b ? a : b; piuttosto che max = (((unsigned)(b-a)) >> SIGN_POS)*(a - b) + b; ). Naturalmente servirà sempre la supervisione di qualcuno più esperto e smaliziato. Comunque ti sei laureato? se è così, auguri!
Personalmente ormai ho smesso di ottimizzare codice, se non quando mi rendo conto che farlo mi richiederebbe più o meno lo stesso tempo che scrivere del codice generico, oppure se intuisco che quella parte di codice è critica e avrebbe bisogno di girare quanto più velocemente possibile.

Per il resto adesso il mio obiettivo principale risolvere un problema, nel più breve tempo possibile, che il codice sia leggibile (questo dipende anche dal linguaggio), facile da mantenere ed eventualmente da cambiare (velocemente).

Non ricerco più l'ottimizzazione a tutti i costi, pensando a come risparmiare qualche ciclo di clock o intervallare il codice in modo da risparmiare qualche stallo alle pipeline dei moderni processori.

Ovviamente l'esperienza che ho accumulato in tutti questi anni mi è molto utile, e ne faccio tesoro (certamente può fare la differenza, alcune volte), ma ormai il mio approccio alla programmazione è decisamente cambiato...

Originariamente inviato da cdimauro
Già. :D
Adesso ne ha quasi quattro (fra qualche mese), ma a quanto pare propende più per il campo umanitario / artistico (il computer di papà interessa soltanto perché è papà che lo usa :p). Sigh. Sob. :cry:

E allora tu comprale una tavoletta grafica e insegnale a usare Paint e programmi simili per le sue piccole opere d'arte, così intanto si appassiona... :D

Lo penso anch'io. Anche perché poi alle superiori incontrano dei professori che insegnano "informatica" :rolleyes:, e i ragazzi me li ritrovo la sera a dovergli fare delle lezioni private... ;) :( :muro:

Ti capisco, certi corsi sono fatti con i piedi o quasi :rolleyes:. Mi è capitato di dare qualche ripetizione a una mia cugina per un corso universitario di informatica di base (Ing. Civile nuovo ordinamento, non nella mia Università, dove del resto non ho idea di cosa facciano per il corso equivalente). Quel corso era troppo striminzito e allo stesso tempo troppo vasto, risultando troppo vago: dava un'accozzaglia di concetti e nozioni spiegati superficialmente, al punto che in molti casi sarebbe stato preferibile non fornirli, generando solo confusione. Per farti un esempio, si accennava sinteticamente (e troppo superficialmente per capirci qualcosa) allo scheduling dei processi e in particolare a FCFS e Round Robin. Di FCFS si diceva che è implementato mediante liste FIFO (senza aver MAI spiegato prima, né dopo, cosa sia una lista concatenata né tantomeno cosa sia una lista FIFO), col risultato che mia cugina confondeva i due termini e i due concetti, al punto che credeva che FCFS fosse una lista FIFO, o un altro nome della lista FIFO, o che la lista FIFO servisse per assegnare la cpu a un processo, e col materiale di cui disponeva è già molto che avesse formulato queste ipotesi, credimi... :rolleyes: Così ho dovuto spiegarle un po' in dettaglio (ma sempre in sintesi, quanto bastava a chiarirle le idee) cos'è la schedulazione dei processi, come funziona FCFS, come funziona Round Robin, cos'è una lista Fifo e che diavolo c'entra con FCFS... Tralascio i dettagli di flusso e la distinzione tra algoritmi sequenziali e iterativi, mi veniva da piangere... Non è affatto bello vedere qualcosa che ami fatto a brandelli senza alcun ritegno...