Comments on: Sulla “apparente” superiorita’ di Microsoft Windows Vista http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/ Storie, esperienze e pensieri da Dublino. Fri, 10 Feb 2012 07:25:37 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Matteo Italia http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/comment-page-1/#comment-25956 Matteo Italia Thu, 17 Apr 2008 14:51:34 +0000 http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/#comment-25956 Tra parentesi, il ragionamento fatto dal team della NTVDM è analogo a quello fatto dagli autori di DosBox, che limita di default la memoria allocabile a 16 MB, aumentabili a 64 modificando il file di configurazione (per andare oltre i 64 bisogna modificare i sorgenti e ricompilare).<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('25956','Matteo Italia'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('25956','Matteo Italia','Tra parentesi, il ragionamento fatto dal team della NTVDM è analogo a quello fatto dagli autori di DosBox, che limita di default la memoria allocabile a 16 MB, aumentabili a 64 modificando il file di configurazione (per andare oltre i 64 bisogna modificare i sorgenti e ricompilare).'); return false;">Quote</a></div> Tra parentesi, il ragionamento fatto dal team della NTVDM è analogo a quello fatto dagli autori di DosBox, che limita di default la memoria allocabile a 16 MB, aumentabili a 64 modificando il file di configurazione (per andare oltre i 64 bisogna modificare i sorgenti e ricompilare).
Reply – Quote
]]> By: Matteo Italia http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/comment-page-1/#comment-25955 Matteo Italia Thu, 17 Apr 2008 14:46:29 +0000 http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/#comment-25955 Credo che abbiano pensato che, dal momento che le applicazioni DOS giravano su macchine con risorse veramente limitate, 32 MB fosse il massimo che un'applicazione con un po' di sale in zucca potesse allocare, e che allocazioni maggiori potessero derivare solamente da bug o altri problemi. Oppure ci possono essere applicazioni che non liberano la memoria finché non esaurisce, usando il fallimento di malloc in maniera simile al messaggio WM_COMPACTING di Windows 3.x; vista la grande quantità di memoria presente sulle macchine odierne malloc non fallisce mai e queste applicazioni continuano a mangiare memoria inutilmente. Il limite quindi finisce con il simulare la quantità di memoria presente su una macchina di alta gamma dei tempi del DOS, dando all'applicazione un ambiente di esecuzione "realistico". La rottura di compatibilità con poche applicazioni legacy sarà parsa accettabile vista anche la sempre maggiore diffusione di applicazioni di virtualizzazione, con cui le poche applicazioni non più compatibili gireranno sicuramente meglio (le applicazioni 16 bit in NTVDM girano piuttosto lentamente).<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('25955','Matteo Italia'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('25955','Matteo Italia','Credo che abbiano pensato che, dal momento che le applicazioni DOS giravano su macchine con risorse veramente limitate, 32 MB fosse il massimo che un\'applicazione con un po\' di sale in zucca potesse allocare, e che allocazioni maggiori potessero derivare solamente da bug o altri problemi. Oppure ci possono essere applicazioni che non liberano la memoria finché non esaurisce, usando il fallimento di malloc in maniera simile al messaggio WM_COMPACTING di Windows 3.x; vista la grande quantità di memoria presente sulle macchine odierne malloc non fallisce mai e queste applicazioni continuano a mangiare memoria inutilmente.\r\nIl limite quindi finisce con il simulare la quantità di memoria presente su una macchina di alta gamma dei tempi del DOS, dando all\'applicazione un ambiente di esecuzione \"realistico\".\r\nLa rottura di compatibilità con poche applicazioni legacy sarà parsa accettabile vista anche la sempre maggiore diffusione di applicazioni di virtualizzazione, con cui le poche applicazioni non più compatibili gireranno sicuramente meglio (le applicazioni 16 bit in NTVDM girano piuttosto lentamente).'); return false;">Quote</a></div> Credo che abbiano pensato che, dal momento che le applicazioni DOS giravano su macchine con risorse veramente limitate, 32 MB fosse il massimo che un’applicazione con un po’ di sale in zucca potesse allocare, e che allocazioni maggiori potessero derivare solamente da bug o altri problemi. Oppure ci possono essere applicazioni che non liberano la memoria finché non esaurisce, usando il fallimento di malloc in maniera simile al messaggio WM_COMPACTING di Windows 3.x; vista la grande quantità di memoria presente sulle macchine odierne malloc non fallisce mai e queste applicazioni continuano a mangiare memoria inutilmente.
Il limite quindi finisce con il simulare la quantità di memoria presente su una macchina di alta gamma dei tempi del DOS, dando all’applicazione un ambiente di esecuzione “realistico”.
La rottura di compatibilità con poche applicazioni legacy sarà parsa accettabile vista anche la sempre maggiore diffusione di applicazioni di virtualizzazione, con cui le poche applicazioni non più compatibili gireranno sicuramente meglio (le applicazioni 16 bit in NTVDM girano piuttosto lentamente).
Reply – Quote
]]> By: pallotron http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/comment-page-1/#comment-25950 pallotron Thu, 17 Apr 2008 13:36:12 +0000 http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/#comment-25950 grazie del commento. io non capisco comunque perche' un sistema operativo, di default, debba evitare ad una applicazione di alloccare tutta la memoria che gli serve (come fa a decidere che e' assai? :) ). magari e' un vecchio applicativo scientifico che necessita di memoria. che ne so. buh. uno avrebbe diretto alla retrocompabilita'. se un programma chiede di allocare quella memoria vuol dire che gli serve :D<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('25950','pallotron'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('25950','pallotron','grazie del commento.\r\n\r\nio non capisco comunque perche\' un sistema operativo, di default, debba evitare ad una applicazione di alloccare tutta la memoria che gli serve (come fa a decidere che e\' assai? :) ).\r\n\r\nmagari e\' un vecchio applicativo scientifico che necessita di memoria. che ne so. buh. uno avrebbe diretto alla retrocompabilita\'. se un programma chiede di allocare quella memoria vuol dire che gli serve :D'); return false;">Quote</a></div> grazie del commento.

io non capisco comunque perche’ un sistema operativo, di default, debba evitare ad una applicazione di alloccare tutta la memoria che gli serve (come fa a decidere che e’ assai? :) ).

magari e’ un vecchio applicativo scientifico che necessita di memoria. che ne so. buh. uno avrebbe diretto alla retrocompabilita’. se un programma chiede di allocare quella memoria vuol dire che gli serve :D

Reply – Quote
]]> By: Matteo Italia http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/comment-page-1/#comment-25946 Matteo Italia Thu, 17 Apr 2008 13:10:08 +0000 http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/#comment-25946 Guarda che si sta parlando di applicazioni compilate a 16 bit e quindi eseguite in modalità di compatibilità DOS... mi pare più che normale che, dopo 16 anni che i sistemi Windows sono a 32 bit, Microsoft decida di tagliare un po' la compatibilità con le applicazioni a 16 bit (peraltro per un buon motivo, vedi dopo). Inoltre questa limitazione si verifica per applicazioni compilate con QUALUNQUE compilatore a 16 bit e quindi eseguita in NTVDM, compreso il buon vecchio Microsoft C++ (non ancora Visual) dei tempi andati. Lo scopo di questa limitazione (come spiega l'e-mail che probabilmente viene da un programmatore Microsoft citata in fondo all'articolo) è di evitare che applicazioni a 16 bit allochino quantità enormi di memoria per niente: le applicazioni DOS infatti, lavorando con un sistema operativo senza multitasking avevano a disposizione praticamente tutta la macchina per sé, e quindi anche allocando tutta la memoria fisica disponibile non c'erano altre applicazioni che ne risentissero; allocare troppa memoria invece è dannoso su un sistema multitasking, dal momento che essa è condivisa con altre applicazioni (anche se il problema è di molto diminuito dall'utilizzo della memoria virtuale). Tutto quello che dici dopo sulle applicazioni open source che non dovrebbero funzionare è un mucchio di scemenze, dal momento che le applicazioni che citi sono compilate a 32 bit e lavorano con le API di Windows (come ogni applicazione Windows fa, esattamente nello stesso modo in cui ogni applicazione sui sistemi UNIX-like richiama le syscall).<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('25946','Matteo Italia'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('25946','Matteo Italia','Guarda che si sta parlando di applicazioni compilate a 16 bit e quindi eseguite in modalità di compatibilità DOS... mi pare più che normale che, dopo 16 anni che i sistemi Windows sono a 32 bit, Microsoft decida di tagliare un po\' la compatibilità con le applicazioni a 16 bit (peraltro per un buon motivo, vedi dopo). Inoltre questa limitazione si verifica per applicazioni compilate con QUALUNQUE compilatore a 16 bit e quindi eseguita in NTVDM, compreso il buon vecchio Microsoft C++ (non ancora Visual) dei tempi andati. Lo scopo di questa limitazione (come spiega l\'e-mail che probabilmente viene da un programmatore Microsoft citata in fondo all\'articolo) è di evitare che applicazioni a 16 bit allochino quantità enormi di memoria per niente: le applicazioni DOS infatti, lavorando con un sistema operativo senza multitasking avevano a disposizione praticamente tutta la macchina per sé, e quindi anche allocando tutta la memoria fisica disponibile non c\'erano altre applicazioni che ne risentissero; allocare troppa memoria invece è dannoso su un sistema multitasking, dal momento che essa è condivisa con altre applicazioni (anche se il problema è di molto diminuito dall\'utilizzo della memoria virtuale).\r\nTutto quello che dici dopo sulle applicazioni open source che non dovrebbero funzionare è un mucchio di scemenze, dal momento che le applicazioni che citi sono compilate a 32 bit e lavorano con le API di Windows (come ogni applicazione Windows fa, esattamente nello stesso modo in cui ogni applicazione sui sistemi UNIX-like richiama le syscall).'); return false;">Quote</a></div> Guarda che si sta parlando di applicazioni compilate a 16 bit e quindi eseguite in modalità di compatibilità DOS… mi pare più che normale che, dopo 16 anni che i sistemi Windows sono a 32 bit, Microsoft decida di tagliare un po’ la compatibilità con le applicazioni a 16 bit (peraltro per un buon motivo, vedi dopo). Inoltre questa limitazione si verifica per applicazioni compilate con QUALUNQUE compilatore a 16 bit e quindi eseguita in NTVDM, compreso il buon vecchio Microsoft C++ (non ancora Visual) dei tempi andati. Lo scopo di questa limitazione (come spiega l’e-mail che probabilmente viene da un programmatore Microsoft citata in fondo all’articolo) è di evitare che applicazioni a 16 bit allochino quantità enormi di memoria per niente: le applicazioni DOS infatti, lavorando con un sistema operativo senza multitasking avevano a disposizione praticamente tutta la macchina per sé, e quindi anche allocando tutta la memoria fisica disponibile non c’erano altre applicazioni che ne risentissero; allocare troppa memoria invece è dannoso su un sistema multitasking, dal momento che essa è condivisa con altre applicazioni (anche se il problema è di molto diminuito dall’utilizzo della memoria virtuale).
Tutto quello che dici dopo sulle applicazioni open source che non dovrebbero funzionare è un mucchio di scemenze, dal momento che le applicazioni che citi sono compilate a 32 bit e lavorano con le API di Windows (come ogni applicazione Windows fa, esattamente nello stesso modo in cui ogni applicazione sui sistemi UNIX-like richiama le syscall).
Reply – Quote
]]> By: Marco http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/comment-page-1/#comment-16038 Marco Mon, 04 Jun 2007 13:19:26 +0000 http://blog.angelofailla.com/2007/06/04/sulla-apparente-superiorita-di-microsoft-windows-vista/#comment-16038 a dire il vero cio' succede solo con djgpp perche' e' un compilatore piuttosto vecchio con mingw o cygwin cio' non accade<div class="comment-remix-meta"><a href="#" class="replyto" onclick="replyto('16038','Marco'); return false;">Reply</a> - <a href="#" class="quote" onclick="quote('16038','Marco','a dire il vero cio\' succede solo con djgpp perche\' e\' un compilatore piuttosto vecchio con mingw o cygwin cio\' non accade'); return false;">Quote</a></div> a dire il vero cio’ succede solo con djgpp perche’ e’ un compilatore piuttosto vecchio con mingw o cygwin cio’ non accade
Reply – Quote
]]>