[Windows Vista] Carta abierta a Microsoft. Limitaciones en windows Vista (32 bits)

27/06/2006 - 19:25 por JM Tella Llop [MVP Windows] | Informe spam
(borrador - la version oficial se publicará en varios idiomas al objeto de
presionar a los Jefes de Producto para que se replanteen el alcance de
Windows Vista y prime una apuesta por la tecnologia y no por una teorica
compatibilidad con dudosos dispositivos).


Carta abierta a Microsoft. Limitaciones en windows Vista (32 bits)


Sorprendentemente me he encontrado que en la ultima beta liberada (5456.5)
del mes de Junio, posterior a la beta 2 oficial, Microsoft ha limitado la
memoria disponible por Windows Vista siendo esta siempre inferior a los 4 GB
y en algunos casos unicamente estan disponible 2 GB de memoria. Hasta el
momento, y en la ultima beta oficial (beta 2) liberada al publico, Vista
podia "ver" toda la memoria hasta los 4 GB. En la beta 1 no existia
limitacion, se usaba el modo PAE completo y se podia usar perfectamente mas
de 4 GB, en mi caso particular 8 GB.

Recordemos un poco el pasado y la cantidad de memoria disponible para los
sistemas operativos.

RECORDANDO
-

Siempre y cuando el chipset de una placa madre soporte la reasignacion de
los recursos a los dispositivos PCI, es posible en 32 bits el usar 64 GB de
memoria si el procesador soporta PAE (todas las CPUs de Intel y todos los
modelos actuales de procesador AMD). Esto es debido a la utilizacion del
modo PAE el cual puede usar 4 bits de uno de los registros de control para
ampliar a 36 bits el bus de direcciones. (fisicamente en los Pentium y
compatibles ya existen 64 lineas de direcciones).

NOTA: La reasignacion por parte del chipset y cuales lo soportan o no puede
verse en el siguiente articulo:
http://www.multingles.net/docs/jmt/4gbmem.htm

En el pasado, Microsoft permitia:

* Sistemas operativos de escritorio: hasta 4 GB de memoria. Si además se
activaba el modo PAE en el boot.ini, era posible usar los 4 GB completos ya
que el sistema operativo, bajo las premisas anteriores del tipo de chipset y
procesador, reasignaba el hardware por encima de los 4 GB.

* Sistemas operativos servidores: hasta 64 GB de memoria con las premisas
anteriores y el limite de memoria estaba en funcion del tipo de Server
adquirido (Data Center podia usar mas memoria que la version Enterprise y
esta mas que la version Server Standar)

Dentro de los sistemas operativos de escritorio, tanto W2000 Profesional
como XP y XP-SP1 podian sin problemas usar los 4 GB completos siempre y
cuando se pusiese el modificador /PAE en el archivo boot.ini

El modo PAE tiene implicaciones:

1) El acceso a memoria es ligeramente mas lento al existir a nivel de nucleo
tres niveles de indireccion en vez de dos. Realmente es inapreciable.

2) Todos los drivers de dispositivos deben estar bien codificiados, ya que
es necesario que los apuntadores a memoria tengan presente que pueden
existir direcciones por encima de los 4 GB (es decir se deben usar
apuntadores de 64 bits). Esto es lo normal ya que figura en la
especificacion de construccion de drivers, y cualquier driver certificado lo
cumple. Tambien es verdad, que muchos driver de terceros fabricantes tienen
una escasa calidad y en estos casos puede que esten mal codificados sin
cumplir las especificaciones anteriores y por tanto fallar al sistema
operativo en el modo PAE.


PRIMERAS LIMITACIONES EN XP-SP2
-

Al ser necesario el modo PAE en XP-SP2 debido a que Microsoft decidió
implementar la proteccion de ejecucion de tareas en las areas de datos (Data
Execution Prevention) tambien se encontró en una disyuntiva: si permitia el
modo PAE completo existia el peligro de que los drivers mal diseñados
hiciesen fallar al sistema operativo. Por otra parte, el PAE era necesario
para la proteccion de tareas.

Ante esta disyuntiva Microsoft decidió poner un modo PAE limitado. Es decir,
PAE activado, pero con las tablas de desciptores a memoria internas del
sistema operativo de 32 bits. Con esto limitaba el acceso a memoria ya que
al no reasignarse las direcciones por encima de 4 GB debian usarse
direcciones reales por debajo de los 4 GB para el uso de dispositivos
hardware. Esto implicaba que con SP2, aunque tuviesemos 4 GB de memoria, la
memoria real disponible al sistema operativo siempre era menor. Dependiendo
del hardware, podian ser 3,5 GB, 3 GB, 2,5 GB. En general era mayor o igual
a 2 GB pero nunca los 4 GB que hubiesemos adquirido.

En ese momento, y a pesar que como betatester protesté en su dia por esta
limitacion, la respuesta de Microsoft fun un simple "by design" sin mas
explicaciones.

Incluso en aquel momento esta decision pudiera ser logica: se debe primar la
estabilidad, a pesar de la mala calidad de drivers de terceros, a la memoria
en uso, maxime cuando los recursos consumidos por XP-SP2 eran de unos 256 MB
y un sistema, en aquel entonces, con cantidad de memoria de 1 GB o superior
era raro y a precios realmente prohibitivos.


ACTUALIDAD - Windows Vista

En la actualidad el precio de memoria es irrisorio, es normal equipos
incluso portatiles con 2 GB de memoria de serie. Igualmente los sistemas
operativos como Vista, y con el aero activado, consumen nada mas instalarse
cerca de 1 GB de memoria. Tenemos además pendiente por parte de Microsoft la
implantacion del nuevo File System (WinFs) el cual se apoyará en un nucleo
de SQL-Server. En ese momento, será necesario cerca de los 2 GB simplemente
para que nuestro sistema "empiece a andar". Esto unido al bajo precio de la
memoria hace casi imprescindible el poder usar sin limitaciones los 4 GB.

Recordemos ademas que las actuales tarjetas graficas (por ejemplo las
actuales 7950 de nVidia), ya usan 1 GB de memoria. Si no hay reasignacion de
memoria a los dispositivos, esta cantidad de memoria será disminuida de la
memoria real accesible por debajo de los 4 GB. Realmente se disminuye mucho
mas ya el propio hardware de la placa base ya necesita direcciones de
memoria, y la especificacion PCI además, asigna una granularidad o marcos de
memoria por debajo de los 4 GB a cada slot PCI.

Hasta la beta 1 de Vista, Microsoft no habia impuesto limitaciones a la
cantidad de memoria. Se podia usar con Vista e 32 bits 8 GB de memoria sin
problemas. En la versiones intermedias entre beta1 y beta2, Microsoft
decidiío limitar la cantidad de memoria a 4 GB. Esto puede ser comprensible
debido a la politica comercial comentada en los primeros parrafos y dejar
por encima de los 4 GB para las versiones de 64 bits o las versiones
servidoras (LongHorn) de 32 bits.

La sorpresa aparece en la primera build posterior a la beta 2. (la 5456.5).
Aparece una limitacion: lo mismo que en XP+SP2 el modo PAE está restringido
y no hay reasignacion del hardware por encima de los 4 GB. En mi caso
particular, en una maquina con 8 GB, solo se puede usar 2,5 GB. Esta
cantidad se quedará escasa en cuanto salga el WinFs, o bien si queremos usar
programas devoradores de memoria como es la clasica multimedia debido a que
el sistema operativo ya usa 1 GB nada mas instalarse.

No sirve en este caso la posible disculpa de pasarse a 64 bits. Vista de 64
bits obliga a que todos los drivers sean de 64 -escaso en el mercado- pero
lo mas grave es que obliga a que sean certificados. El tema es tan crudo que
es imposible por ejemplo, instalar Vista 64 en una simple y actual
controladora SATA (en modo SATA - no Legacy) ya que los drivers no son
certificados. Permitirá la instalacion, pero en el primer boot, no arrancará
informando que hay un driver de boot que no tiene el corrrespondiente hash
de nucleo registrado.


¿QUE DEBE PRIMAR?

¿que debe primar en este caso en Microsoft?. ¿la compatibilidad de drivers
dudosos -y cada vez mas escasos- o bien apostar por la tecnologia y dejar
disponibles los 4 GB?

Creo, honestamente, que Microsoft se ha equivocado al no realizar una
apuesta por la Tecnologia de la que tanto presume en este nuevo Sistema
operativo.

Recordemos que existe un serio competidor en sistema de escritorio: Linux. Y
esta es dejar abierta una posibilidad a su crecimiento. Una posibilidad
real.



Jose Manuel Tella Llop
MVP - Windows
jmtella@XXXcompuserve.com (quitar XXX)
http://www.multingles.net/jmt.htm
news://jmtella.com

Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no
otorga ningún derecho.

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

Preguntas similare

Leer las respuestas

#26 Felix Gomez
29/06/2006 - 12:18 | Informe spam
Voy por partes:

-
"RFOG" escribió en el mensaje news:
On Thu, 29 Jun 2006 03:50:43 +0200, Felix Gomez wrote:

Y no me salgas con que los servidores es otra vaina, porque no. Hace 10 años si pero ahora no.
Y la IA32 son extensionnes de 16 bits segun tu. Y las IA16 son extensiones de la IA8.

Nada no me convence tu postura atavica de quedarse en los 32 bits.



A ver, que las extensiones de 64 bits de AMD son un poco abortivas es evidente para cualquiera que se haya tragado los datasheets
correspondientes. Eso no quiere decir que no sean funcionales o que vayan mal, no.




Se basan en el paso de los 16 a los 32 de Intel.


Lo que se quiere significar es que el paso de los 32 a los 64 es un buen momento para hacer borrón y cuenta nueva en cuanto a la
arquitectura interna de un micro. Quizás ignores el hecho de que los micros ahora son casi todos RISC con tamaño de instrucción
variable, y que el juego de instrucciones que todos conocemos se ejecuta sobre ese otro grupo de instrucciones... Dentro de los
micros actuales hay una especie de traductor/compilador...




Esto ya lo sabia.

¿Tu sabes la cantidad de mierda obsoleta que hay dentro de un micro actual? Todo por conservar las 16 interrupciones clásicas, el
modo x86, el modelo segmentado (que en su momento sirvió pero ahora es un lastre que lo complica todo), los pipelines "a la"
x86, x32, etc. ¿Sabes la simplificación que supondría deshacerse de todo eso y cambiar por completo de arquitectura?




No pueden hacer borron y cuenta nueva, mira la IA-64 en que se ha quedado. El paso de un programa en la IA-32 a la x86-64 se puede
automatizar sin necesidad de cambiar demasiadas cosas en el codigo fuente(Nombres de registros, modos de funcionamiento, alguna
instruccion y poco mas). Mientras que el cambio de la IA32 a una revolucionaria habria que reescribir todo. Una cosa es EVOLUCION y
otra diferente es REVOLUCION. Y las revoluciones en tecnologia han sido, son y seran siempre de muy poco exito comercial(32 bits del
MAC, los IBM Personal System 2, la arquitetura RISC, la IA-64)

Dime un solo caso de una tecnologia revolucionaria que haya triunfado.

Pues eso.


Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
> La ansiedad es un arroyito de temor que corre por la mente. Si se le alimenta puede convertirse en un torrente que arrastrara
todos nuestros pensamientos.
Respuesta Responder a este mensaje
#27 Felix Gomez
29/06/2006 - 12:30 | Informe spam
Si es el precio, pero no el del usuario final sino el de fabricacion del superordenador, antes eran las propias fabricantes de
superordenadores las que diesñaban los procesadores y ahora lo unico que hacen es conformarse con lo que hay en el mercado y diseñar
a partir de ahi, con la consiguiente reduccion de costes que no de precio final. Un Cray cuesta mucho dinero, de 100.000$ para
arriba.


-
"RFOG" escribió en el mensaje news:
On Thu, 29 Jun 2006 00:04:43 +0200, Felix Gomez wrote:

La epoca de hacer procesadores especificos para servidores y especificos para ordenadores domesticos paso a la historia ya que
las
que hacian para servidores quebraron o se disolvieron. Ahora se tiende a hacer que los domesticos sirven para servidores y
viceversa. Y baste solo un apunte:
http://www.top500.org/static/lists/...istics.pdf
De los ordenadores mas potentes del mundo casi un 40% son ya con las "extensiones" de 64 bits. Mientras que los RISC(Power PC,
Sparc, PA-RISC, Alpha) son un 22% y los IA-64 son un 7,4%. Osea que el 40 % de los procesadores que estan montados en los
ordenadores mas potentes tienen el mismo nucleo que los procesadores de ordenadores domesticos, eso hace 10 años era impensable.
Y
fijate en que en los grandes ordenadores la arquitectura predominante hace 10 años era la RISC y ahora es la CISC. ¿Que ha
pasado
entonces? ¿Ha bajado el nivel de los informaticos de alto nivel? ¿Se han vuelto locos los informaticos de alto nivel? ¿O mas
bien no
habia ventajas de RISC a CISC, solo una manera diferente de programar?

Y yo te digo que tenemos "extensiones" para rato. Y auguro extensiones de 128 bits.





Quizás ese cambio se deba al precio de esos equipos...


Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
> La ansiedad es un arroyito de temor que corre por la mente. Si se le alimenta puede convertirse en un torrente que arrastrara
todos nuestros pensamientos.
Respuesta Responder a este mensaje
#28 RFOG
29/06/2006 - 12:57 | Informe spam

¿Tu sabes la cantidad de mierda obsoleta que hay dentro de un micro
actual? Todo por conservar las 16 interrupciones clásicas, el modo x86,
el modelo segmentado (que en su momento sirvió pero ahora es un lastre
que lo complica todo), los pipelines "a la" x86, x32, etc. ¿Sabes la
simplificación que supondría deshacerse de todo eso y cambiar por
completo de arquitectura?




No pueden hacer borron y cuenta nueva, mira la IA-64 en que se ha quedado.
El paso de un programa en la IA-32 a la x86-64 se puede automatizar sin
necesidad de cambiar demasiadas cosas en el codigo fuente(Nombres de
registros, modos de funcionamiento, alguna instruccion y poco mas).
Mientras que el cambio de la IA32 a una revolucionaria habria que
reescribir todo. Una cosa es EVOLUCION y otra diferente es REVOLUCION. Y
las revoluciones en tecnologia han sido, son y seran siempre de muy poco
exito comercial(32 bits del MAC, los IBM Personal System 2, la arquitetura
RISC, la IA-64)

Dime un solo caso de una tecnologia revolucionaria que haya triunfado.

Pues eso.






Los cambios solo serían necesarios a nivel de drivers y de sistema
operativo. Todo eso que comentas lo abstrae el sistema operativo, y si
alguna aplicación se mete a ello, sencillamente: está mal hecho, para eso
tienen un SO.

¿Te piensas que el cambio de un sistema operativo a otro no requiere rehacer
la mayoría de los drivers? ¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el compilador/intérprete. ¿Tu
sabes la cantidad de compiladores que hay en el mercado, al menos uno por
arquitectura? ¿Tu sabes que para cambiar un compilador sólo hay que
modificar el back-end? Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>> La ansiedad es un arroyito de temor que corre por la mente. Si se le
alimenta puede convertirse en un torrente que arrastrara todos nuestros
pensamientos.




Respuesta Responder a este mensaje
#29 Felix Gomez
29/06/2006 - 13:49 | Informe spam

Los cambios solo serían necesarios a nivel de drivers y de sistema operativo. Todo eso que comentas lo abstrae el sistema
operativo, y si alguna aplicación se mete a ello, sencillamente: está mal hecho, para eso tienen un SO.




Todo compilador de C permite codigo embebido en ensanblador.


¿Te piensas que el cambio de un sistema operativo a otro no requiere rehacer la mayoría de los drivers?



Compara la adaptacion de un driver de IA-32 a x86-64 con la de IA-32 a IA-64.
O la de IA-32 a la de MAC.

¿Por que si es tan facil como dices no hay dispositivos que valgan para mas de una arquitectura y si los hay para la x86-64 y la
IA32?


¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el compilador/intérprete.?


Si
¿Tu sabes la cantidad de compiladores que hay en el mercado, al menos uno por arquitectura?



Si

¿Tu sabes que para cambiar un compilador sólo hay que modificar el back-end?



No, prueba a migrar una aplicacion de C de MS a C de Borland. Y tambien prueba de C de MS a C de Linux.
Y para colmo de C de MS a C de MAC. Y ya no te cuento si te metes con ventanas la migracion resulta complicadisima.




Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>>> La ansiedad es un arroyito de temor que corre por la mente. Si se le alimenta puede convertirse en un torrente que arrastrara
todos nuestros pensamientos.








Respuesta Responder a este mensaje
#30 RFOG
29/06/2006 - 16:29 | Informe spam
"Felix Gomez" wrote in message
news:
>
Los cambios solo serían necesarios a nivel de drivers y de sistema
operativo. Todo eso que comentas lo abstrae el sistema operativo, y si
alguna aplicación se mete a ello, sencillamente: está mal hecho, para eso
tienen un SO.




Todo compilador de C permite codigo embebido en ensanblador.



¿Y? ¿Tiene algo que ver? ¿Cuántos de tus programas para PC tienen
ensamblador embebido? ¿Piensas que eres más listo que el compilador?


¿Te piensas que el cambio de un sistema operativo a otro no requiere
rehacer la mayoría de los drivers?



Compara la adaptacion de un driver de IA-32 a x86-64 con la de IA-32 a
IA-64.
O la de IA-32 a la de MAC.




A ver una cosa. Estás confundiendo el tocino con la velocidad. Esos cambios
ya se han producido sin problemas. Hay fabricantes que hacen drivers para
MAC, linux, w9x, solaris, etc. Sería un nuevo driver. Y si no que en lugar
de vender hardware que vendan lechugas.

¿Por que si es tan facil como dices no hay dispositivos que valgan para
mas de una arquitectura y si los hay para la x86-64 y la IA32?


¿TU sabías que las aplicaciones de sistema se
hacen en C/C++/VB y que el único cambio sería el compilador/intérprete.?


Si
¿Tu sabes la cantidad de compiladores que hay en el mercado, al menos uno
por arquitectura?



Si

¿Tu sabes que para cambiar un compilador sólo hay que modificar el
back-end?



No, prueba a migrar una aplicacion de C de MS a C de Borland. Y tambien
prueba de C de MS a C de Linux.
Y para colmo de C de MS a C de MAC. Y ya no te cuento si te metes con
ventanas la migracion resulta complicadisima.




Otra vez churras con merinas. Hablas de convertir entre plataformas. Coge
una aplicación Win32 bien hecha y pásala a win64. Coge una aplicación linux
2.4 y pásala a linux 2.6. Lo mismo con MAC. Sólo es necesario recompilar.
Otra cosa es el hatajo de programadores inútiles que hay por el mundo que no
tienen ni idea de programar.

Pues cambiando la arquitectura del procesador, el sistema operativo y el
back-end del compilador correspondiente, pasar de un hipotético win64 x64 a
un win64 nueva_arq sólo debería requerir una recompilación.

Tu me hablas de convertir entre sistemas operativos diferentes, no
arquitecturas... Hubo una época en el que windows nt funcionaba bajo varias
arquitecturas... con un mismo código fuente sólo había que recompilar para
el micro adecuado.



Pues eso.




Visita mi blog: http://rfog.blogsome.com
Libros, ciencia ficcion y programacion
>>>> La ansiedad es un arroyito de temor que corre por la mente. Si se le
alimenta puede convertirse en un torrente que arrastrara todos nuestros
pensamientos.












Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida