Hola,
Francamente, este es el tipo de comportamiento al que me refería. Pero en
fin, aún así contestaré el mensaje.
A lo mejor los demás estamos hartos de apariciones "deslumbrantes" y
"estelares" de usuarios de PC, que intentan igualar ambas plataformas, que
intentan trasladar lo intrasladable a este otro mundo....
Llevo con el MSX desde 1985. Fui uno de los componentes de Draken Club
(editábamos un fanzine en disco para MSX), tuve abierta una BBS de MSX
durante unos dos años, tengo un Philips NMS8280 con 1Mb, MoonSound, IDE y un
HD de 1.2Gb. Y lo mejor de todo: no lo tengo guardado en una caja, sino que
está montadito en mi escritorio y lo uso regularmente, ahora principalmente
para jugar. Por falta de tiempo, no he podido montar uno de mis proyectos:
una base de datos online con todos los programas de MSX que tenía por casa
(unos 2.000 disquettes entre los que yo tenía de antes y los que me pasó
Angel Cortés cuando cerró su BBS), así que he cedido medio giga de espacio
en uno de nuestros servidores a unos chicos que ya estaban haciendo algo por
el estilo (http://msxfiles.d-webzone.com). Creo que puedo considerarme un
usuario de MSX.
Yo no hablo de convertir el MSX en un PC. Para eso me quedo con el PC, que
ya está montado y no me complico la vida. De lo que yo estoy hablando es de
superar las limitaciones del MSX, de EVOLUCIONAR. Tal vez estés muy contento
con los viejos juegos de MSX1 (personalmente, son los que más pongo), pero
unos cuantos de nosotros preferiríamos usar el MSX para más cosas. Entre
ellas, conectar a Internet, para evitar que los usuarios que no tienen PC
tengan que comprarse uno para poder enviar mails o ver webs. Si tu prefieres
quedarte en los 80 y preocuparte sólo de jugar, eres muy libre de hacerlo.
Nadie se meterá contigo por ello. Pero por favor, no empieces a tirar
piedras a los que preferiríamos que el MSX evolucionara.
programando sobre Solaris, System V y Linux, y todas las cabeceras llevan
'tropecientas' condiciones, preguntando por etiquetas de compilación para
cada kernel... claro!! así si es estandar y portable...
Supongo que te refieres a funciones o constantes que varían de una
plataforma a otra. Obviamente, en esto tienes razón. Pero yo estaba siendo
un poco más humilde. No pretendo (de momento) poder llegar a compilar un
Apache+mod_ssl en el MSX. Pero píllate un FreeBSD y ve a /usr/src/games. A
ver si encuentras muchas etiquetas de compilación condicional por allá. La
mayoría de estos programas compilarán sin problemas en un HITECH-C o un
MSX-C. Sí, son programas sencillos, pero a esto es a lo que me estaba
refiriendo yo.
Decir que todos los 'kernel' de Unix son iguales y que se "compila de
forma transparente",
Perdona, pero no recuerdo haber dicho que todos los kernels de UNIX son
iguales.
Y con todos mis respetos a la gente que está desarrollando UZIX, con
el
mayor de mis respetos insisto.... pero tienen que estar montando "un pan
con
dos ostias"....
Sea lo que sea lo que estén montando, por lo menos lo están intentando, no?
En vez de criticarles, podríamos intentar ayudar. Poco avanzaremos con esa
actitud de atacar a todo lo que es nuevo.
Si lo único que llegamos a imaginar para el desarrollo es lo mismo que
ya está para el resto.... ¡¡es que aquí no pintamos nada!!! Pues se nos
habrá secado la imaginación, y para ser realista yo no tengo un MSX....
Habrá que ser "estándar" en lo único que haya que ser estándar (en los
protocolos y formatos de ficheros, principalmente)... en el resto, se
podrá
ser o no.
Exacto, hay que ser standard en lo que hay que serlo. Y en aquello que no ha
de ser necesariamente standard, yo optaría por una solución más flexible que
la que tu ofreces: que cada uno haga lo que quiera, en vez de intentar
imponer a los demás la forma de pensar de uno mismo.
Por algo será que todos y cada uno de los kernels de los
sistemas operativos que ves por ahí están escritos en C
[>]
Sí... pero un usuario no escribe kernels....
Yo no estaba hablando de usuarios, sino precisamente del desarrollo de un
UNIX para MSX.
Y, por eso, los usuarios de Unix dejan de utilizar C, y pasar a otros
lenguajes (Tcl, Perl, GTK,...)
100% correcto. Perl y shell script en mi caso. Aunque sigo usando C para
cosas que requieran mucha velocidad y sean sencillas (no soy precisamente un
profesional de C).
En C, toda la entrada/salida se maneja como ficheros
En UNIX sí. En otras plataformas no. :)
La multitarea depende del sistema operativo, no del lenguaje. Tú estás
hablando de threads
[>]
El lenguaje deberá poseer las instrucciones para invocar las llamadas
al
sistema que permitan la generación de nuevos procesos...
Si no es así, pues quitamos el fork(), y a ver cómo creamos otro
proceso
para hacer multitarea...
Hombre, teniendo en cuenta que estamos hablando de multitarea en MSX, y que
no tenemos protección de memoria, uno mismo podría modificar la tabla de
procesos del kernel e ir añadiendo sus procesos... :) Lo que yo quiero
decir es que independientemente de si el lenguaje soporta forks o no, si el
sistema operativo no soporta multitarea, poco vamos a poder hacer a no ser
que nos pongamos a jugar con timers a muy bajo nivel.
Un punto interesante: ¿puede el lenguaje "resolver" lo que el hardware
y
el SO estropean? Me refiero a "visión" de la memoria...
Perdon? No sé si te entiendo. Te refieres a qué pasaría si un proceso
sobreescribe la zona de memoria de otro?
haga un SO estilo UNIX sin un microprocesador que implemente modo
protegido,
sin un hardware que implemente espacio virtual de direccionamiento... y
por
UZIX lo hace. De forma muy primitiva y limitando mucho el espacio de memoria
de cada proceso. Pero lo hace. Dejemos que lo perfeccionen. Obviamente,
mientras sigamos trabajando en una CPU sin modo protegido, nada impedirá que
un proceso sobreescriba la memoria que no le corresponda y cuelgue la
máquina.
supuesto, que implemente un servidor X-Window sobre un VDP, que apenas se
sostiene haciendo SCREEN 8....
Servidor X? En esto sí que estoy 100% de acuerdo contigo. Para empezar, no
me veo a los chicos de x.org portando las XFree86 a Z80. Y segundo, que
tampoco lo veo necesario. Total, en casa uso el pine para responder el
correo, el BitchX para entrar a IRC, un cliente FTP normal y corriente...
Todo en modo texto. Todo en xterms. Francamente, lo único que uso en modo
gráfico es el Netscape, y si me viera muy apurado nada me impediría usar el
Lynx. Además, sería cargar mucho la ya de por sí limitada CPU de un MSX.
Creo que podremos pasar sin un servidor X. :)
Pero tanto los que no ven la realidad de la calle, como los que no
conocen el MSX....
Creo conocer el MSX bastante bien. Lo suficientemente bien como para meterme
a programar en assembler un driver IDE que no tuviera las limitaciones del
de Sunrise. Y lo dejé parado cuando ya empezaba a dar sus primeros pasitos
precisamente por mensajes como el tuyo. Si te interesa, tienes las fuentes
en http://usuarios.intercom.es/ag0ny/msxdev.html. Tal vez tu puedas
retomarlo y terminarlo. Si quieres, también puedes mirarte mi antigua web
(de cuando tenía la BBS): http://usuarios.intercom.es/luznet.
Saludos,
Javi Lavandeira
Director Tecnico
Inlander Communications, S.L.
Tel: (+34) 93 310 12 86 Fax: (+34) 93 268 14 79
javilm(_en_)inlander(_punto_)es - http://www.inlander.es
----- Original Message -----
From: Jose Maria Pacheco <josepac(_en_)iponet(_punto_)es>
To: <hispamsx(_en_)onelist(_punto_)com>
Sent: Tuesday, March 14, 2000 9:56 AM
Subject: RE: [hispamsx] El tono de mis mensajes
From: "Jose Maria Pacheco" <josepac(_en_)iponet(_punto_)es>
Hola!
He mezclado la respuesta a un par de mensajes... iré quoteando las
frases.
Perdonadme todos por el tono de mis mensajes, pero es que ya estoy harto
de
ver en la scene del MSX a gente que se cree que lo sabe todo.
[>]
A lo mejor los demás estamos hartos de apariciones "deslumbrantes" y
"estelares" de usuarios de PC, que intentan igualar ambas plataformas, que
intentan trasladar lo intrasladable a este otro mundo....
Porque, se quiera o no, el MSX no es un ordenador, en la definición
que
dan los libros... se parece, pero no lo es.
Y, dado que no sigue las "arquitecturas" más modernas, habrá que ver
sus
posibilidades y limitaciones.
Por otra parte, hacer afirmaciones como
> - El software de UNIX se compila de forma transparente entre
plataformas,
> gracias a un compilador C standard (egcs/gcc).
es faltar a la verdad de una forma bastante burda... me tiro todo el
día
programando sobre Solaris, System V y Linux, y todas las cabeceras llevan
'tropecientas' condiciones, preguntando por etiquetas de compilación para
cada kernel... claro!! así si es estandar y portable...
Decir que todos los 'kernel' de Unix son iguales y que se "compila de
forma transparente", es como decir que todos los coches llevan los mismos
modelos de tornillos... ve con un BMW a la Seat, y le pides recambios....
Y con todos mis respetos a la gente que está desarrollando UZIX, con
el
mayor de mis respetos insisto.... pero tienen que estar montando "un pan
con
dos ostias"....
Si lo único que llegamos a imaginar para el desarrollo es lo mismo que
ya está para el resto.... ¡¡es que aquí no pintamos nada!!! Pues se nos
habrá secado la imaginación, y para ser realista yo no tengo un MSX....
Habrá que ser "estándar" en lo único que haya que ser estándar (en los
protocolos y formatos de ficheros, principalmente)... en el resto, se
podrá
ser o no.
E insisto: el C no es el estádar... es el C++. Y alguno dirá: "... hay
que saber C para C++". Sí; pero lo que se reutilizan son clases e
interfaces, no punteros....
Por algo será que todos y cada uno de los kernels de los
sistemas operativos que ves por ahí están escritos en C
[>]
Sí... pero un usuario no escribe kernels....
Y, por eso, los usuarios de Unix dejan de utilizar C, y pasar a otros
lenguajes (Tcl, Perl, GTK,...)
Repito: ¿para qué reinventar la rueda? Si quieres un lenguaje rápido,
fácil
de usar, potente e interpretado, usa Perl.
[>]
¡¡También digo yo eso!!
La rueda en MSX se llama "BASIC"... ;-DD
El acceso a los periféricos es una característica del sistema operativo,
no
del lenguaje.
[>]
El lenguaje tendrá que poseer las instrucciones apropiadas para
manejar
la E/S, ya sea a alto o a bajo nivel....
En C, toda la entrada/salida se maneja como ficheros, ya sean "cooked"
o
"raw"... y eso es simplificar demasiado el modelo para todos los tipos de
máquinas. Por eso luego se tienen que estar "inventando" librerías que
complementan el kernel, y permiten hacer otra serie de accesos a los
dispositivos que no son "secuenciales"...
La multitarea depende del sistema operativo, no del lenguaje. Tú estás
hablando de threads
[>]
El lenguaje deberá poseer las instrucciones para invocar las llamadas
al
sistema que permitan la generación de nuevos procesos...
Si no es así, pues quitamos el fork(), y a ver cómo creamos otro
proceso
para hacer multitarea...
¿Ni siquiera si haces accesos ilegales a bajo nivel a los dispositivos
del
sistema? Esto también depende del sistema operativo.
[>]
Un lenguaje interpretado no permite "accesos ilegales"...
Si hay un trozo en otro lenguaje (ASM, C), ese trozo depende del otro
lenguaje, no del interpretado....
La gestión de memoria depende del sistema operativo.
[>]
Idem de arriba...
malloc(), calloc(), free(),....
Un punto interesante: ¿puede el lenguaje "resolver" lo que el hardware
y
el SO estropean? Me refiero a "visión" de la memoria...
No me enrollo mucho más... no merece la pena.
Llamaremos al Sr. Tanenbaum (si te escucharan los alumnos de aquí, de
la
Técnica de Informática y de la Técnica de Teleco de Madrid el nombre de
ese
pibe, y ponerlo como ejemplo... la que se podría formar), y le diremos que
haga un SO estilo UNIX sin un microprocesador que implemente modo
protegido,
sin un hardware que implemente espacio virtual de direccionamiento... y
por
supuesto, que implemente un servidor X-Window sobre un VDP, que apenas se
sostiene haciendo SCREEN 8....
El problema que veo en estos momentos con el MSX es que los cuatro gatos
que
saben assembler se pasan el día hablando de cosas de las que no tienen
ni
idea, en vez de ponerse a aprender cosas nuevas. Son considerados gurús
y
todo el mundo toman lo que dicen como palabras divinas. Y todos siguen
ignorando el mundo que les rodea.
[>]
Nos aplicaremos todos el cuento...
Pero tanto los que no ven la realidad de la calle, como los que no
conocen el MSX....
Saludos.
José María.
------------------------------------------------------------------------
GET A NEXTCARD VISA, in 30 seconds! Get rates
as low as 0.0% Intro APR and no hidden fees.
Apply NOW!
http://click.egroups.com/1/975/0/_/666427/_/953024003/
------------------------------------------------------------------------
*HispaMSX. La mailing-list de MSX en castellano*
Para cualquier duda: msxjam(_en_)crosswinds(_punto_)net
