May 2004 - Posts
Come promesso, e a caldo che più caldo non si può, un po' di commenti sul seminario di questo pomeriggio, argomento: WS e Remoting.
Il relatore (chissà perchè non lo indicano mai nelle presentazioni degli eventi sul sito Microsoft) era un personaggio noto: Silvano Coriani ! Credevo che si interessasse prevalentemente di formazione su piattaforme server, e db nello specifico, invece ho scoperto che lo spettro è molto più ampio. Ebbravo Silvano !
Di conseguenza, il mio timore di un approccio più commerciale che tecnico era decisamente infondato.
L'avvio è stato decisamente soft, dato anche il fatto che in sala non tutti consocevano il .NET framework. Quindi una mezzoretta a parlare di problematiche di programmazione distribuita, partendo dai limiti di COM/DCOM ed arrivando alla soluzione .NET. Silvano ha dato un'enfasi, giustificatissima direi, al modello di programmazione SOA, senza entrare nei dettagli e senza parlare di Indigo (che ha comunque nominato, anche se solo in un accenno) ma sottolineando maggiormente le tematiche generali dell'architettura e le problematiche che cerca di risolvere (non sapevo che l'acronimo SOAP fosse stato da alcuni ribattezzato ServiceOrientedApplicationProtocol, c'è da dire che sono stati veggenti con i nomi !).
Un pizzico di XML + XSD + SOAP + WSDL, giusto per spiegare le sigle ed inquadrarle in un ambito più generale, e via con i web services.
Da buon relatore le demo le ha fatte con Notepad, csc e wdsl.exe. Un po' scomodo ma gli esempi erano già pronti ed in pratica il Notepad lo ha usato in visualizzazione e basta (per quello va più che bene, a parte il syntax highlighting e l'indentazione ...). Insomma, con l'aiuto di uno sniffer e di un paio di maschere client ad hoc ha illustrato con chiarezza quello che sta dietro al concetto di servizi web. Niente di nuovo per chi le cose le conosce (e mi ci metto dentro anch'io, almeno a questo livello introduttivo), ma direi efficace per chi non ne ha un'idea precisa.
Sono rimasto sorpreso che abbia anche introdotto i concetti di WS-* (e ho visto che aveva installato WSE2, cosa che io devo ancora fare, anche se installare non vuol dire sperimentare, per quello ci vorrebbe un po' più di tempo).
Quindi la parte finale è stata dedicata a Remoting.
Per inciso, Remoting è probabilmente una delle parti del runtime che conosco meglio. Questo dipende da un minimo di esperienza d'uso in più rispetto ad altre tecnologie .NET, e in effetti anche dalla lettura di diverso materiale. Silvano ha citato Ingo Rammer, un punto in più solo per questo (Ingo ha scritto uno dei più bei libri di informatica che io abbia mai letto, e uno dei pochi che ho studiato approfonditamente). Per necessità di tempo è stata una presentazione decisamente introduttiva, ma penso che i punti chiave li abbia esposti.
Finish. In anticipo, addirittura !
Conclusione: una sessione introduttiva, senza dubbio, e, almeno per me, niente di nuovo sul fronte occidentale. Non inutile, comunque.
Intanto credo che serva sempre vedere modi diversi di presentare le cose. E anche se quello di oggi è stato un modo direi abbastanza standard, devo fare i complimenti a Silvano per la chiarezza e la capacità di sintesi. Ascoltare una persona che in 3 ore ti parla di programmazione distribuita, WS, Remoting, ti fa le demo e ci mette dentro anche una breve introduzione a XML, passando da un accennino su COM, beh, ti fa rendere conto che un conto è conoscere le cose, un conto è saperle spiegare.
Ho anche scoperto il sogno della mia vita (non è vero, non l'ho scoperto oggi ... ma ne ho avuto conferma, direi): da grande voglio fare lo speaker/trainer/mentor, o come lo volete chiamare, insomma.
Di strada da percorrere ce n'è parecchia, non lo metto in dubbio, però mi piace l'idea di coniugare lo studio di cose che mi piacciono (mica del latino !) con il trasferimento delle conoscenze acquisite a qualcun altro.
Per ora continuo a leggere un sacco di roba, cerco di portare avanti qualche esame di certificazione, e chi vivrà vedrà ...
Detto ciò vi saluto ... cu !
Per chi abita a Genova e dintorni (facciamo una milionata di persone), lavora o studia nel campo dell'informatica (e iniziamo a restringere il numero), usa tecnologie Microsoft (qui non restringiamo di molto :-)) ed è libero questo pomeriggio (qua si scende a qualche unità), segnalo questo evento.
Si tiene al DISI (dipartimento di Informatica dell'università di Genova).
E' facile da raggiungere: da Albaro, percorrendo via Pisa da piazza Lenonardo verso levante, al primo semaforo a sinistra, poi la seconda traversa a destra (ok, andatevelo a guardare qui che è meglio).
Dovrebbe anche essere abbastanza interessante.
Sono curioso di vedere soprattutto l'approccio alla conferenza.
Il pubblico dovrebbe essere tendenzialmente diverso dal solito: studenti universitari, credo, per la maggior parte (io faccio eccezione!). Quindi gente che ha una preparazione informatica sicuramente sopra la norma, ma che magari conosce ambienti diversi e che di .NET potrebbe sapere pochino.
Si sa che, per ragioni di costo (le licenze Microsoft non sono esattamente economiche) e anche didattiche (i corsi di OS utilizzano quasi sempre una variante unix, a partire dal famoso Minix che devi conoscere se studi sul Tanebaum, ad arrivare a Linux, che peraltro è quello che usano al DISI) gli studenti universitari generalmente non utilizzano piattaforme Microsoft all'università. Poi Windows ce l'hanno magari installato sul PC personale, ma questo è un altro discorso.
Parlando con alcuni studenti di facoltà scientifiche qui a Genova, mi sono accorto di come Microsoft sia in genere considerata monopolista e contro il vero spirito del "software libero". Non entro nella discussione che penso abbia occupato Terabyte di spazio sui vari webserver disseminati per il mondo. Però sono veramente curioso di vedere se l'approccio da parte dei relatori sarà prevalentemente "commerciale" (tipo "guarda che bello che è il nostro prodotto"), magari di tipo commerciale-tecnico (tipo "guarda che bello che è il nostro prodotto, ti consente l'interoperabilità con altre piattaforme non MS tramite WS, perche SOAP bla bla bla) oppure esclusivamente tecnico.
Credo che nel parlare ad un pubblico tendenzialmente preparato e magari parzialmente ostile (in senso buono, chiaramente) la scelta migliore sia l'esposizione di contenuti tecnici con poco spazio al commerciale.
Se io fossi un amante spudorato di Linux e dintorni, una conferenza di stile commerciale mi allontanerebbe ancora di più dal concorrente di turno (MS). Una discussione più tecnica, al contrario, mi dovrebbe consentire di valutare pregi e difetti di un'alternativa. E' chiaro che chi ha preconcetti non va da nessuna parte (vale anche in senso contrario, perchè c'è tanta gente pro-Microsoft che disprezza il mondo dell'open-source solo per partito preso), ma questo è un discorso più generale che si applica ad un campo molto più vasto che non quello dell'informatica.
Quindi vedremo.
Spero che introducano anche Indigo, magari un accenno e un paio di dritte sull' "usa questo oggi, che domani farai meno fatica a cambiare". Mi sono perso la sessione di Paolo a Bologna che parlava della Roamap per Indigo perchè ero di là a seguire Roberto che parlava WinFS (come sono difficili, a volte, le scelte). Quindi sentiamo un po' cosa diranno questo pomeriggio.
Comuque, se siete in quel ristretto numero di cui sopra, niente scuse e venite ! E' pure gratis !
Domani vi faccio sapere com'è stata.
CUnext
Recentemente mi è capitato di leggere alcuni articoli datati (se così si può dire per cose scritte 4 anni fa, ma sappiamo che nel mondo della tecnologia, e dell'informatica soprattutto, 4 anni sono un bel po') che introducevano al grande pubblico il .NET Framework. E' stato curioso leggere le entusiatiche presentazioni di un prodotto all'epoca ancora in beta a distanza di anni dal suo rilacio e confrontare le promesse e le aspettative di Microsoft con quello che poi è stato, in realtà.
Due cose mi hanno colpito, in particolare.
Da un lato la promessa di un'estrema facilità di sviluppo (gestione automatica della memoria, gestione delle eccezioni, FCL, eccetera). E qui niente da dire (beh, qualcosa sì, in realta, chi ha letto la storia di Pino sa a cosa mi riferisco); non si può negare che con una buona conoscenza degli strumenti a disposizione la rapidità di sviluppo è parecchio aumentata. Occhio che rapidità di sviluppo non significa solo metterci poco tempo a completare un progetto, ma anche metterci poco tempo a mantenerlo e ad estenderlo.
Dall'altro l'enfasi che veniva data all'interoperabilità fra linguaggi. Io scrivo un componente in C#, dal quale derivo un componente scritto in VB.NET che uso da MC++, e via dicendo. Vero anche questo, e gran cosa sicuramente. Continuando nella dissertazione, l'autore dell'articolo (scusate, non ho sottomano il link e non ricordo il nome dell'autore, prometto un update quanto prima) scriveva con entusiasmo qualcosa di questo genere: "Pensate, sono già sviluppati o in fase di completamento nmila compilatori che "target-izzano" (non mi viene in italiano, deformazione da libri in inglese) il runtime .NET".
Quest'ultima affermazione è stata sicuramente confermata dai fatti. Non conosco il numero aggiornato di compilatori che producono moduli managed, ma credo che siano veramente tanti.
I motivi sono palesi.
Innanzitutto è decisamente più semplice scrivere un compilatore per .NET. Non sono per niente esperto di compilatori, ma ci vuole poco a capire che, se da un lato la parte di analisi sintattica rimane, credo, della stessa complessità, dall'altro la fase di generazione dell'output è decisamente più affrontabile. Alla fine, se vogliamo guardare il mondo a strati (virtualizzazione, questa sconosciuta ...) la macchina virtuale CLR è a ben più alto livello della macchina virtuale con cui dobbiamo avere a che fare con i compliatori x86. Insomma, senza dilungarmi su questioni che conosco troppo superficialmente, semplicità è la parola chiave.
In secondo luogo credo che la crescente diffusione di .NET abbia portato gli amanti dei più disparati linguaggi di programmazione a cercare di rendere il proprio pupillo .NET-aware. Ed ecco nascere Fortran.NET, Cobol.NET e chi più ne ha più ne metta. Che poi esistano sviluppatori che scrivono per .NET in Cobol, questo è tutto da verificare (non dico che non ce ne sono, questo no, ma è indubbio che la percentuale sia irrisoria rispetto ai "colossi" di mamma Microsoft).
Terzo punto. Didattica ed "esercizio di stile". Non fraintendetemi, non è denigratorio. Tutt'altro. Dall'alto della mia inesperienza credo che portare a termine un progetto di compilatore per .NET sia un'esperienza fantastica e decisamente istruttiva: sia perchè ti costringe ad imparare molto bene le fondamenta della piattaforma che utilizzi (ricado sempre sul discorso "internals", che fissa !), sia perchè credo che ti faccia vedere le cose da un punto di vista un po' differente. Il classico utente (non stiamo parlando di utenti che aprono Word e leggono la posta, ma di programmatori, ovviamente) talvolta identifica la tecnologia che usa con il linguaggio di programmazione con il quale si esprime. Sviluppare un compilatore per .NET, o comunque interessarsi a questi argomenti, credo che aiuti a capire che il linguaggio di programmazione è un semplice strumento di astrazione sintattica che rende le caratteristiche della piattaforma disponibili al programmatore: ne isola il funzionamento reale tramite la definizione di costrutti più vicini a quelli della mente umana, che non è esattamente una abstract stack machine ...
E qui arriva il punto: ma se il linguaggio è solo uno strumento sintattico, la scelta è assolutamente indifferente ? E' solo una questione di gusti ?
Beh, no, in effetti.
Intanto non esiste, che io sappia, un linguaggio ad alto livello che renda disponibili tutte le caratteristiche del runtime: che so, C# non consente metodi globalli, VB.NET non consente overload di operatori, eccetera eccetera, sono solo due esempi. Quindi a volte la scelta del linguaggio può anche essere determinata dal numero di funzionalità sottostanti che questo mette a disposizione.
Secondariamente, costrutti analoghi scritti in linguaggi differenti non è detto che producano codice IL uguale. I compilatori fanno, o non fanno, ottimizzazioni e via dicendo, insomma non producono gli stessi risultati. Quindi anche un discorso di prestazioni può avere la sua influenza, anche se credo che ben pochi considerino questo aspetto.
Infine, e qui la distinzione è fra C#/VB/MC++ e il resto del mondo (faccio un'eccezione per Delphi), il supporto e la documentazione hanno un ruolo importantissimo, e non possiamo negare che la maggioranza di noi, quando ha deciso di sviluppare in .NET, la scelta l'ha fatta tra i prodotti di casa Microsoft. Uno perchè, anche senza conoscerli, li abbiamo ritenuti migliori già in partenza. Due perchè una scelta "standard" ci dovrebbe tenere al riparo da spiacevoli inconvenienti.
Ecco perchè. secondo me, prodotti "esoterici" hanno poca diffusione al di là dell'accademia. Ed è un peccato, perchè magari nascondono fantastiche funzionalità che ignoriamo solo per avere quel minimo di garanzia di supporto. E se, nella produzione "industriale", in effetti è una scelta sensata, chi sviluppa per hobby, o comunque senza fini commerciali, dovrebbe per lo meno ampliare la gamma di scelta.
Quindi, giusto per aggiungerne uno alla gamma, vi segnalo Nemerle. Ho letto giusto due cosette e mi è piaciuto abbastanza. Sappiatemi dire.
cU
Mi sono trasferito a Genova più o meno da 4 anni, per motivi di studio prima e di lavoro poi.
Credo che, almeno all'inizio, vedere la mia stanza vuota sia stato ... strano per i miei genitori. In fondo era la MIA camera e in un certo senso facevo parte dell'arredamento (un modo un po' squallido per dire quello che intendo).
Da circa due anni, però, la mia stanza non è più vuota.
No, avete capito male. Non sono stato sostituito. Fatto sta che due anni fa è entrata in casa mia una persona speciale. In realtà è entrata più in camera mia che in casa mia, perchè dalla mia stanza si muove ben poco per evidenti problemi di deambulazione.
Però intanto è lì, seduta sulla sua poltrona di fronte alla sua televisione. La potete immaginare con un rosario in mano e un'aria pacifica e serena. Pensa al passato e prega per il futuro. Il presente lo accetta tranquillamente.
Un tempo era una cuoca meravigliosa (se la trovo in un prossimo post vi scrivo la ricetta delle crocchelle di patate, posto che il copyright me lo permetta !). E anche una persona molto attiva e vivace. Vivace lo è rimasta, attiva, beh, nei limiti dell'eta (quasi 92, quante firme che farei per arrivarci in quel modo).
Se le dico che l'ho nominata in un blog sicuramente mi guarda con un'aria interrogativa. Ogni tanto mi chiede qualcosa su questo misterioso computer. Chissà come se lo immagina ? Dalle domande che mi fa credo che lo immagini più o meno come una televisione, solo un po' più interattivo (in un certo senso ha pure ragione).
So che i miei genitori le hanno detto che ho aperto questa strana cosa che assomiglia a un diario su Internet. Volevo solo scrivere qualcosa che potesse capire anche lei.
Ah, dimenticavo. Si chiama Zelinda, anche se io la chiamo Cucci. E ora ha la sua identità sulla rete. Insomma, ci sono un po' tutti, ci doveva essere anche lei, no ?
Credo che sia uno dei blog più "linkati", e sicuramente a ragione.
Mi ero ripromesso di segnalarlo non appena avessi aperto il mio blog. Lo so che lo conoscete già, ma non si sa mai ...
E il blog di Chris Brumme.
Se pensate di avere una conoscenza avanzata del CLR, leggetelo e sappiatemi dire.
Assolutamente imperdibile.
In questo post, Shawn Van Ness sottolinea come spesso l'idea di sviluppare codice che gira nelle amorose braccia di un runtime intelligente produca nel programmatore una sorta di "abbandono": ci pensa il CLR, quindi perchè preoccuparsi tanto ?
Vero nel 90% dei casi (la percentuale la butto lì, comunque vero molto spesso), ma in alcune situazioni di qualcosa bisogna anche prendersi carico.
L'esempio di Shawn evidenzia la necessità di analizzare il valore di ritorno delle funzioni Win32 invocate con P/Invoke. Secondo me la problematica è molto più generale.
Sviluppare in .NET è semplicissimo.
O no ?
Vi racconto la storia di Pino, vecchio programmatore C++ ma vero novizio di .NET. (Pino è un nome inventato !)
Pino deve sviluppare un gestionale e, per ragioni diverse che non sto ad elencare, lo vuole fare in C#.
Apre VS.NET e scopre l'editor stile VB6. Pino è abituato a message pump e WM_PAINT, e non gli sembra vero quello che vede.
Mette un paio di controlli, fa doppio click su un bottone e gli si apre la finestra di codice con un handler già bello e pronto, insomma, facilissimo !
Così in 4 e 4 8 fa un sacco di form (coloratissime, di solito la prima cosa che si fa è iniziare a cambiare colore ai controlli, e viene fuori un guazzabuglio che fa venire la nausea solo a guardarlo ...), fa un paio di chiamate al provider dati e ottiene un Dataset pieno di roba, due tocchi di databinding ed ecco che il gestionale che doveva essere pronto dopo 1 mese è già fatto, e in soli 4 giorni di lavoro ! Chissà il capo di Pino quanti complimenti che gli farà ... bravo Pino, sapevo che potevo contare su di te, ti darò più responsabilità all'interno del gruppo, eccetera eccetera.
Poi Pino inizia a testare un po' meglio il suo applicativo. La ditta è piccola, il reparto di test non esiste (qui non vorrei aprire un capitolo che meriterebbe non un post, ma un libro intero, e magari lo hanno già scritto. Intanto date un'occhiata qua), quindi ci pensa lui.
Funzionicchia, però Pino si accorge che la memoria occupata sale un po' troppo, diciamo che va oltre ai 100Mb e continua a crescere, piano piano.
Che fare ? Una rapida occhiata all'MSDN e Pino trova la documentazione della classe System.GC, vede il metodo Collect, gli piace e lo chiama. Niente da fare, non funziona.
Pino iniza a preoccuparsi. La colpa è sicuramente di quest'accidenti di gestione automatica della memoria. Almeno in C++ si facevano delle belle new e le realtive delete, tutto sotto controllo, nessun problema, nessun consumo. Questo .NET proprio non funziona, è mal fatto, non va bene per applicazioni critiche (notate che Pino sta sviluppando un "critico" gestionale !).
Basta, Pino rinuncia.
Riapre VS6, usa MFC. "Però, che brutto rispetto alle Form .... ma in compenso ho controllo su quello cha faccio", pensa Pino mentre inizia a sbattersi con la MESSAGE_MAP e le DDX.
Pino, alla fine, ha consegnato il suo gestionale, fatto in MFC e ADO, con pochi giorni di ritardo, quelli persi a provare a farlo in C#. Il suo capo è stato comprensivo, ma ben lontano da fargli i complimenti: l'interfaccia è scarna e al cliente potrebbe non piacere granchè.
"Però almeno funziona", pensa Pino, che si mette a studiare sul Prosise come migliorare l'aggiornamento di una ListView.
Qui finisce la storiella di Pino.
Pino non esiste, o meglio, credo esistano diversi Pini in giro per il mondo.
Alcuni desistono ai primi problemi e ritornano sui propri passi. Sono quelli un po' più esperti, che sono abituati a fare anche un po' di profiling durante lo sviluppo. Ma noi sappiamo che Pino era un esperto programmatore C++, quindi non ci stupiamo della sua scelta.
Altri scrivono quintalate di righe di codice. Di solito se ci dai un'occhiata trovi 4 o 5 metodi che si chiamano button1_Click o simili, con 1000 righe di codice procedurale per ciascuno. Non sto neanche a dire cosa succede quando si inizia ad incartare qualcosa.
Comunque hanno in comune il fatto di non aver studiato le nuove tecnologie prima di usarle, e di aver pensato che sarebbe bastato leggersi un po' di documentazione durante la codifica per far funzionare tutto con prestazioni ottimali.
Morale della storia: le ditte che hanno dei Pini fra i loro dipendenti hanno avuto un'esperienza negativa nel passaggio alla tecnologia .NET (alla fine Pino era uno dei migliori sviluppatori che avevano, chissà cosa possono combinare quelli un po' più mediocri), quindi il salto non lo effettuano. Il C++ va benissimo, funziona bene da che mondo e mondo, perchè cambiare ?
Credetemi, non è così inverosimile.
CUNext
Ieri sera stavo leggendo alcuni post "vecchi" (nel senso che sono di qualche mese fa) di Marco Russo. Ce ne sono diversi che vorrei segnalare, ma dovendo fare una scelta vi rimando a questo.
Ormai i commenti negativi sul TaskManager si sprecano, e aggiungere il mio di certo non dà valore aggiunto alla discussione.
Un fatto che illustra chiaramente come il TaskManager non sia proprio il pezzettino di Windows meglio riuscito è che sono stati sviluppati diversi add-in che ne estendono le funzionalità.
Uno che vi voglio segnalare è stato scritto da Zoltan Csizmadia . Purtroppo non ho il link al quale ho trovato il suo add-in. Vi scrivo la e-mail, che fra parentesi lui stesso incoraggia ad utilizzare per avere informazioni (almeno questo risulta dall'onnipresente AboutBox della sua extension).
A parte le funzionalità aggiunte (che a dire il vero non sono molte) è interessante dare un'occhiata al codice (il suo TaskManagerEx è completo di codice sorgente - C++ e MFC). Per chi ne ha voglia, non dovrebbe essere troppo complicato prendere spunto dall'approccio di Zoltan e personalizzare il TM aggiungendo delle estensioni utili.
Detto questo, è indubbio che un tool come Process Explorer è mooooolto meglio. D'altra parte, Mark Russinovich è una garanzia !
Alla prossima e buona giornata a tutti.
Buongiorno e ben svegliati !
Qui a Genova il barometro dice alta pressione e vento lieve.
Ci sono 24 gradi fuori (almeno qui da me) e devo dire che ci si gode veramente le primavera.
Ho su la pasta (col pesto, ovviamente !) quindi approfitto dei 2 minuti che mancano prima che diventi un pappone colloso.
Dannazz maledizz alle scadenze ! Sarebbe proprio da prendere la macchina e andare in riviera. Tra l'altro di gente in spiaggia già ce n'è parecchia, e dagli torto.
Mi sento già gli insulti di chi non ha il mare a due passi ma a duecento chilometri: "Molla il lavoro, deficiente!".
Credo che il mare sia una di quelle cose che quando ce l'hai lì ad un passo non lo apprezzi neanche tanto, lo dai un po' per scontato. Ma sono sicuro che se mai mi dovessi trasferire ne sentirei la mancanza nel giro di un nanosecondo.
Quindi la massima (trita e ritrita) di oggi è: "Imparare ad apprezzare le cose che si hanno, finchè durano".
Mmmmhhhh ... io quasi quasi lo spengo davvero il pc stopomeriggio e vado a Boccadasse, che C# può anche aspettare una mezza giornata.
CUnext
Tra ieri e l'altro ieri ci ho perso due mezze giornate prima di riuscire a completare una build senza errori. E sino a 10 minuti prima funzionava tutto (sì, vabbè, dicono tutti così ...).
Niente da fare: "Cannot delete the project output: is the file read-only ?"
Dopo ore passate a capire chi si teneva bloccato sto benedetto file e soprattutto perchè (eh già il file se lo bloccava devenv.exe alias VS, ma il motivo, era quello che proprio mi sfuggiva) ....
... ecco che mi imbatto in un articoletto carino carino della KnowledgeBase (per chi ha voglia, è il KB313512).
E scopro quanto segue: in solution multiprogetto che condividono l'output directory, se uno degli assembly referenziati supera le dimensioni di 64 KB, Intellisense pensa che sia il caso di bloccarselo tutto per sè (gelosia ?!) e quando in fase di build si tenta di cancellare il file per poi sovrascriverlo (lo fa VS in automatico, ma abbiamo gli stessi risultati se lo facciamo a mano da Explorer), ecco che ci siamo fregati.
E il brutto è che questo non avviene sempre, ma solo quando l'assembly è > 64 KB. Così magari tutto è ok, poi aggiungiamo un metodo stupido stupido e abbiamo varcato la soglia.
Ovviamente ci sono tanti modi per aggirare il problema, non ultimo quello di evitare di utilizzare un'unica directory di output per gli assembly generati. Leggete l'articolo per una discussione completa.
Quello che è curioso, però, è la causa del bacherospo.
Però, pensandoci bene ... ma sì, basta essere concisi nella codifica e non generare mai assembly più grandi di 64 KB ! Uomo avvisato ...
Ma guarda un po' cosa si scopre in giro per la rete ...
La mia cultura sullo scheduling dei thread in OS Windows (parlo di NT/2K/XP, ovviamente !!) è in effetti un po' raffazzonata.
Mi ricordo (ma non vi so dire dove) di aver letto cose tipo: "la durata di un quantum non è documentata e non è impostabile" oppure "un quantum dura all'incirca 10 ms" e via dicendo.
Premesso che sino a 20 minuti ignoravo le informazioni fornite da Mark Russinovich a questo link ...
http://www.sysinternals.com/ntw2k/info/nt5.shtml
...e che in effetti vivevo felice lo stesso, dateci una letta, se avete voglia. E' davvero interessante.