[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

#36 Felix Gomez
29/06/2006 - 18:07 | Informe spam
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica hay
estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta extendida
y estirada hasta la saciedad. La necesidad de compatilibidad con x86 (16
bits), la necesidad de compatibilidad con x32 (32 bits), el modelo
segmentado, la mierda de la conmutación modo real/protegido, un juego de
instrucciones bastante abstruso y difícil, un pipeline de demasiadas
etapas, con una lógica de predicción de salto etc completamente absurda e
innecesaria, la existencia de cuatro anillos que nadie usa en lugar de
dos, las 16 interrupciones y sus niveles completamente objsoletos y las
que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un procesador
SIMD vectorial, una alu que trabajara con números decimales en lugar de
binarios, etc, pero esto son opiniones y preferencias mías.


No me vale lo de los drivers por que siempre que se produce un cambio en
la maxima memoria direccionable, NECESARIAMENTE hay que reescribir los
drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"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
#37 RFOG
29/06/2006 - 18:09 | Informe spam
"Felix Gomez" wrote in message
news:

"RFOG" escribió en el mensaje
news:uG$
"Felix Gomez" wrote in message
news:
Una pregunta ¿Si es tan facil? ¿Por que no se hace?
¿Por que no ha habido un Autocad para Win NT para micros Alpha? ¿Por que
el Win NT para micros Alpha tenia tan poco sofware?
Y ahora hazte las mismas preguntas para el Windows XP de la IA64.

Si solo es recompilar y ya esta, ¿Por que no se hace?

Algo falla.




Sip, las ganas de las casas. Y los tiempos de test. Y muchas más cosas.
Mis programas, todos compilan tanto en win32 como win64. Si el autocad no
compila es porque está mal hecho. Así de sencillo.



¿Y si Autodesk resulta que tiene unas librerias en ensamblador mas
optimizadas que MS y tiene que reescribirlas si cambia la arquitectura? ¿O
piensas que Autodesk tiene programadores peores que MS?

Simplemente, a fecha de hoy no vale la pena.

Dime tú qué falla.



Todo el que tenga librerias de codigo en ensamblador que a poco grande que
sea la empresa seguro que tiene algo en ensamblador.




Pues no sé, pero sigo pensando que se trata de malas ideas... Cualquier cosa
que se puede hacer en ensamblador se puede hacer exactamente igual en C.

¿Te imaginas a Lightwave o Autocad usando las DirectX?




Pues la verdad es que no.



"RFOG" escribió en el mensaje
news:
"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
#38 RFOG
29/06/2006 - 18:21 | Informe spam
"Felix Gomez" wrote in message
news:%
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica
hay estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?




Je je. Le has dado la vuelta a la tortilla.

A ver, de acuerdo respecto a los estándares, pero ten en cuenta que los
estándares también han de evolucionar, y la arquitectura x86 es vieja, muy
vieja, y debería evolucionar.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta
extendida y estirada hasta la saciedad. La necesidad de compatilibidad
con x86 (16 bits), la necesidad de compatibilidad con x32 (32 bits), el
modelo segmentado, la mierda de la conmutación modo real/protegido, un
juego de instrucciones bastante abstruso y difícil, un pipeline de
demasiadas etapas, con una lógica de predicción de salto etc
completamente absurda e innecesaria, la existencia de cuatro anillos que
nadie usa en lugar de dos, las 16 interrupciones y sus niveles
completamente objsoletos y las que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un procesador
SIMD vectorial, una alu que trabajara con números decimales en lugar de
binarios, etc, pero esto son opiniones y preferencias mías.


No me vale lo de los drivers por que siempre que se produce un cambio en
la maxima memoria direccionable, NECESARIAMENTE hay que reescribir los
drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"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
#39 Felix Gomez
29/06/2006 - 18:33 | Informe spam

Pues no sé, pero sigo pensando que se trata de malas ideas... Cualquier
cosa que se puede hacer en ensamblador se puede hacer exactamente igual en
C.




Pero todo programa en C es del orden de 3 veces mas lento que en
ensamblador.
Respuesta Responder a este mensaje
#40 Felix Gomez
29/06/2006 - 18:41 | Informe spam
Nada es viejo mientras cumpla con su cometido. ¿Hay algo que no se pueda
hacer con la x86-64 que se pueda hacer con otras? No, pues entonces.

¿Los tornillos y destornilladores se puende hacer de otra forma? Si ¿Pero,
para que?




"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Pues mis deseos son diferentes:
Que para programar compiladores solo tengas que aprender una
arquitectura.
En telecomunicaciones que es una materia mas antigua que la informatica
hay estandares para todo y no hay nada propiedad de nadie.
La informatica tiene que tender a eso mismo y dejarse de ideas felices.

Y gracias que vamos encaminados a ello.
¿Tu que opinas?




Je je. Le has dado la vuelta a la tortilla.

A ver, de acuerdo respecto a los estándares, pero ten en cuenta que los
estándares también han de evolucionar, y la arquitectura x86 es vieja, muy
vieja, y debería evolucionar.



"RFOG" escribió en el mensaje
news:
"Felix Gomez" wrote in message
news:%
Y otra pregunta:
¿Que es lo que no te gusta de la x86-64?




Exactamente eso, que es x86-64, o sea, una arquitectura obsoleta
extendida y estirada hasta la saciedad. La necesidad de compatilibidad
con x86 (16 bits), la necesidad de compatibilidad con x32 (32 bits), el
modelo segmentado, la mierda de la conmutación modo real/protegido, un
juego de instrucciones bastante abstruso y difícil, un pipeline de
demasiadas etapas, con una lógica de predicción de salto etc
completamente absurda e innecesaria, la existencia de cuatro anillos que
nadie usa en lugar de dos, las 16 interrupciones y sus niveles
completamente objsoletos y las que se me escapan.

Yo personalmente cambiaría todo eso del core del micro por un procesador
SIMD vectorial, una alu que trabajara con números decimales en lugar de
binarios, etc, pero esto son opiniones y preferencias mías.


No me vale lo de los drivers por que siempre que se produce un cambio
en la maxima memoria direccionable, NECESARIAMENTE hay que reescribir
los drivers para que puedan acceder a toda la memoria.





Lo de arriba.



"RFOG" escribió en el mensaje
news:
"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