te envio mis felicitaciones y orgullo de hombre, como creador ya haz alcanzado una meta enorme, espero no te obseciones por terminarlo tu solo. lo que haz echo hasta aca es suficiente, ya inspira a nuevos programadores. gracias
No me obsesiono porque no lo continuaré. Hacer todo lo que viene detrás es para genios, y no lo soy, y llevaría mucho tiempo y me tendría que dedicar solo a eso. Y debo seguir contando otras historias en ParcelaDigital. Muchas gracias por tu comentario.
Con el Spectrum aprendí a programar en ensamblador de Z80. habia un ensamblador que se llamaba GENS y un desensamblador que se llamaba MONS. yo los tenia los dos.
Pues la verdad no sé si muestro el código al 100% en pantalla, pero casi todo está. Para lo que muestro en el vídeo el código no es grande. Es complicado, pero no grande. Eso sí, lo hecho es una pequeñísima parte de lo que necesita un SO de los 80, para hacer un SO completo el código fuente sería mucho más grande. Gracias por tu comentario.
Hay muchos años y muchas horas de trabajo detrás de alcanzar el conocimiento. Y aún así está muy lejos del conocimiento necesario para construir al 100% un sistema operativo. Gracias por tu comentario.
A mí también me llamó la atención. Hacer un sistema operativo completo tiene muchísimo trabajo y requiere muchísimo conocimiento. Lo del video solo es una pequeña parte de todo lo que hay detrás de un SO ochentero. Gracias por tu comentario.
Saludos desde Venezuela, soy informatico y empece en los 80's, tambien tengo entendido que los SO establecen un orden de prioridades para los procesos, esto viene de los computadores que usaron en las misiones apolo a la luna
En realidad, un sistema monotarea como éste, solo tiene una tarea que ejecutar, y es la que se "adueña" en la ejecución. Otra historia es la multitarea. Inicialmente los SO utilizaban una multitarea cooperativa, donde el proceso "mandaba", podríamos decir, y normalmente otro proceso no comenzaba hasta que el que estaba en marcha no terminaba. Después llegaron los SO's con multitarea apropiativa, donde la CPU es la que decide en cada momento que proceso se va a ejecutar. Entiendo que te refieres a eso cuando hablas de procesos. Gracias por tu comentario.
Me has retrocedido al tiempo en que programábamos el 6502 en ensamblador. Una observación sobre el video, no se ven las letras del editor ni de la pantalla de tu ordenador. Si quieres mostrar el trabajazo que te has dado, pon la fuente mas grande ,tienes la parte central del video vacía y en blanco. Y si es porque te puedan copiar el código fuente, no creo que haya nadie que se ponga a hacer lo que tu has hecho. Gran trabajo, felicitaciones..
Muy interesante. Una locura hacerlo hoy en día de 0. Sólo pensar en controlar los puertos, las IRQs, acceder a tarjetas externas sin drivers ni nada.. uffff :)
Menudo proyecto ! Me encantaría ayudarte en lo que pudiera aunque estoy muy oxidado con la arquitectura de un PC . La verdad me he tirado hace mucho a Arduino y FPGAs ultimamente . Pero si necesitas una mano cuenta conmigo .
Pues este video es como para dárselo a mi abuelo! je je jeje 😁 no, mentiras. Muy bueno. Con los años, todo este conocimiento se pierde con las nuevas generaciones, y la IA que viene a hacernos la vida mas tonto... digo, mas fácil! PD: no sabes donde me descargo la imagen "disquete" del sistema operativo D.O.S 3.30 de IBM para el IBM PC XT ? Saludos desde Cali Colombia
Busca el PC-DOS en archive.org, allí seguro que encuentras imágenes del disco. Después se trata de conseguir volcar la imagen en disco en un ordenador que tenga disquetera. Gracias por tu comentario.
Saludos, me suscribí, espero publiques el código fuente y el API de tu sistema, tengo un editor de texto que puedo rehacer para tu sistema, te lo enviaré con su código fuente en ensamblador. Jhonatan.
No me he planteado publicar el código porque lo que muestro en el vídeo es la base, muy básica. Lo realmente complicado viene detrás, y requiere mucho conocimiento y mucho tiempo de dedicación. El objetivo era mostrar esa pequeña introducción. Gracias por tu comentario.
Basicamente para programar en assembly language se necesita conocer bien la arquitectura del processador su set de instrucciones registradores buffers operaciones logicas ect ect ect........
Hola capo una pregunta solo Tenes que conseguir los programas para crearlo y saber un poco de Hardware y los cálculos matemáticos pasar a código maquina 0 y 1 binario lo hace el Programa ? recién me inicio en esto te ganaste un suscriptor..!
Hay que conocer muy bien al hardware, hay que conocer muy bien el funcionamiento del microprocesador, y hay que programar en ensamblador las partes más fundamentales y en lenguaje C el resto.
Pues la verdad, no lo he probado, pero me da que no funcionará. Lo hecho está totalmente enfocado a lo que había en los ochenta. Gracias por tu comentario.
En los últimos años he investigado mucho con la IA y ahora mismo es una tecnología que llama mucho la atención en muchos aspectos, pero que falla bastante en otros. Es una inteligencia artificial que te puede ahorrar trabajo, pero se requiere al lado a una "inteligencia no-artificial" que revise y supervise todo. En el aspecto de crear código fuente la IA te puede quitar trabajo, pero no es muy efectiva a la hora de generar un código tan complejo y que funcione bien. Le tienes que estar guiando constantemente. Gracias por tu comentario.
Todo lo que sea avanzar sobre la base que se ve en el vídeo, ya se entra en un mundo complicado. No solo hay que tener en cuenta que el sistema operativo es monousuario, sino que además es de 16 bits, y la memoria no es líneal, porque no estamos ante un modo protegido, sino ante un modo real. Por tanto, de mano, la RAM se divide en memoria convencional (los primeros 640 Kb), memoria alta, y memoria reservada. Después se puede utilizar la interrupción de la BIOS 0x15 para consultar el espacio máximo de RAM, desarrollar código para reservar y lberar bloques de memoria, hablar de pila, heap, o memoria del usuario. De los 4 módulos que hablo en el vídeo (bootloader, kernel, filesystem, y comandos de usuario) todo eso de la gestión de la RAM iría dentro del kernel monolítico, como la interacción con cualquier otro componente hardware del equipo. En el kernel va toda la interactuación del sistema con los servicios de hardware. Como indico en el vídeo, desarrollar un SO de 16 bits monousuario, monotarea, y con núcleo monolítico es realmentre largo y complicado. Muy complicado. El vídeo muestra una base sencilla, fácil de aplicar (comparado al resto, porque en Ensamblador no hay nada fácil). Entonces nos podemos imaginar lo complicado que será desarrollar un SO con multitarea o multiusuario, con micronúcleo o microkernel... Gracias por tu comentario.
@@parceladigital gracias por responder, no hablo de crear un SO multi. Digo que el caballo de batalla del MS DOS era que el vector de memoria de los aplicativos, quedaba siempre marcado por la misma direccion de carga. Tal como hay una interrupcion para invocar al disco en el arranque y que por defecto nos devolvera el primer sector, cilindro invocando a la cabeza cero, esto tiene como automatizacion (lo que el cmos y la bios digan) que banco de memoria es el de arranque para comenzar el volcado de lo que el procesador vaya concluyendo como resultado final. La lucha que todos teniamos y tu tambien lidiaste con ello, era dejar el mayor espacio libre en la memoria base para poder lanzar programas cuyo ejecutable de lanzamiento siempre rascaba algo mas de los 300kb de ram. Si el SO en ram ocupa memoria base, lo estamos quitando de la gestion aplicativa. De esta manera, cuando el MS DOS terminaba la carga, siempre coincidian los bloques mas importantes en las direcciones cargadas en ram y podias entender que direcciones en hexadecimal eran las criticas. Por ese motivo, los virus que se programaban por esa epoca, solo funcionaban en MS DOS, porque Linux, a parte de ser liberado el primer kernel en 1993, gestionaba la memoria completamente diferente y los vectores de ataque eran mucho mas complejos. Una abstraccion usada en Linux en los primeros kernels, fue la de darle al usuario un acceso a un disco ram, sobre el cual podria ir montando el resto de herramientas y aplicativos, pero todos ellos siempre necesitaban el puntero base de acceso al recurso fisico instanciado en ram. Esto producia que, si un archivo se infectaba con algun virus (pongamos por caso que en mi propio ordenador quiero modificar un archivo base de arranque del kernel), lo estaria haciendo en una imagen temporal de la ram, que al reinicio, se perderian los cambios. La manera de hacerlo perdurable era montando los perifericos de hardware y accediendo por referencia al puntero ram, entonces con un ls se listaba el contenido de archivos del medio fisico al cual estas apuntando desde la instancia de la ramdisk. No era hasta que el kernel terminaba de cargar, que liberaba el usuario maquina o root y permitia el login al usuario como usuario maquina, solo entonces, podrias indicarle al sistema que debia montar. Esto requeria en primera instancia, montar las carpetas de sistema base, si deseabas que el sistema base te montara el acceso al aera de usuario segun terminaba de arrancar, debias modificar el archivo de inicio (ya con la carpeta del sistema referenciada como puntero en ramdisk) y los valores de inicializado. No pretendo que tu retro DOS sea asi, porque no es el objetivo, pero si que me resultaria muy interesante que, al finalizar el ejercicio, permitieras al sistema base de 16 bits, lanzar otra instancia de si mismo y que ambas instancias se comunicaran, siendo que ambas son monousuario, que la instancia esclava dependera de la maestra y que se puedan instanciar tantos esclavos como ram lo permita (16Mb a dia de hoy es como unas casi cuatro mil veces menos de lo que esta soportado)
Efectivamente, mucho me tocó lidiar con el MS-DOS para optimizar la memoria. Al principio lo hacía a mano, en las últimas versiones de MS-DOS primero ejecutaba el MEMMAKER, pero no realizaba la mejor optimización, y una vez ejecutado, hacía cambios a mano en autoexec.bat y config.sys para optimizar la memoria. El MS-DOS utilizaba el modo real, y solo podía direccionar los primeros 640 Kilobytes de la RAM. El resto era memoria alta, extendida o expandida. Recuerdo que en los noventa había videojuegos que ocupaban tanto de la convencional, que había que optimizar muchísimo para liberar 625 o 630 kb de convencional para que pudieran ser ejecutados. Anoto tu sugerencia, aunque hacer lo que hace el vídeo, que es una base muy básica, me llevó demasiado tiempo y demasiados problemas a solucionar. Trabajar en desarrollo de SO's son palabras muy mayores. El objetivo es que personas que tuvieran cierto nivel de conocimiento de programación, pero que nunca hubieran bajado al bajo nivel, puedan comprender de forma "sencilla" (si se puede decir) la base de un SO de aquellos años ochenta. Que el QDOS, el CP/M, o el propio MS-DOS en sus primeras versiones eran muy sencillos. Por tener, no tenían ni carpetas. Gracias por tu comentario.
@@parceladigital ciertamente el desarrollo de software orientado a sistemas, es muy complejo, y antes de abordar su codificacion, se hacian unos calculos previos sobre cuantos ciclos de relog se consumian por tarea y si los ciclos eran completos o quedaban a mitad. La lucha eterna del CISC y su software era esa misma, la de ser capaces de ir cerrando tareas a ciclos completos sin dejar huecos por optimizar. Las ventajas muchas: Se evitaban casi el 90% de los problemas de la fragmentacion en memorias cache y su traslado a la ram. Muchas de las inestabilidades de windows 98 y Me, eran precisamente esas: Fragmentaban las memorias de trabajo y los cierres de sesion acababan con archivos corruptos, por lo que un Windows 98 y/o Me no solian dirar mas de un anio sin tener que formatear. En las workstation se recomendaba usar windows NT, heredero de la arquitectura de software Xenix. Su implementacion en Windows XP y Windows 2000, nos hizo cobrar la esperanza de qucrosoft podria hacer cosas buenas, pero el software basado en arquitecturas de anillo nulo, son demasiado malos a la hora de evitar amenazas externas, si bien para puestos de trabajo ofimaticos y de produccion son de lo mas cookies y te encarinias con ellos, nunca debemos olvidar que no estamos solos en un mundo interconectado y es por esta interconexion por lo que Windows y su arquitectura de software de anillo nulo se demuestra completamente dependiente de estar conectados con sus creadores desde el puesto final de usuario, porque son ellos los que proporcionan la verdadera seguridad, centralizada en su capacidad de decirle a tu maquina como debe vigilarse a si misma. Por otro lado, Linux es un sistema muy peligroso, pues es como si le das dos pistolas a un mono, si la persona que usa Linux en modo escritorio la tienes integrada en una red corporativa y los conocimientos de esa persona no son los adecuados, ese ordenador con Linux puede llegar a exponer la seguridad de la red al completo de una manera mucho mas peligrosa que un windows, pero las ventajas no se pueden comparar, las capacidades que te permite linux a la hora de hacer analisis forense, no las tiene windows, por eso, la seguridad real de Linux es su capacidad neta de estar en un estado de consumo minimo, en las tareas comunes que permiten apalancar el uso de la maquina de cara al usuario, mientras que windows, su consumo es el maximo en las tareas comunes y no comunes con un apalancamiento en el hardware y de cara al usuario, maximo. Cada cual en su liga, tienen su concepto de seguridad definido. Con ninguno de los dos sistemas se puede decir que, uno esta completamente seguro.
Sí, se puede programar una BBS enb Python. El Python es un lenguaje muy versátil, permite muchas cosas. Pero en los ochenta las BBS no se hacían en Python, lógicamente el lenguaje no fue lanzado hasta el año 1991. En los ochenta, normalmente, las BBS se desarrollaban en lenguaje C.
Soy programador y has hecho un buen trabajo. Sólo que no necesitas aclarar 100 veces que es una tarea complicada. Cualquiera puede darse cuenta de ello.
Complicado es programar en alto nivel, esto es mucho más que eso, es otro nivel. Por eso tienen tanto mérito aquellas personas que en solitario o en pequeños grupos desarrollaron aquellos sistemas operativos en los setenta y primeros años ochenta. Este vídeo lo ve mucha gente que le gusta esto, pero que nunca ha programado... incluso repetirlo 100 veces, se puede quedar corto. Fui durante unos cuántos años profesor de informática, y me quedó claro que la reiteración no solo no sobra, sino que puede ser necesaria.
@@parceladigital Tengo 79 años y podrás imaginarte que la programación era a nivel máquina. "es complicado, es complicado........ " me suena a "Mirá mamá, sin manos!!!!"
Ahora no, ni siquiera en ensamblador. Pero en el pasado sí se hacían cosas en binario. Y algunas sin salir de casa. Todavía recuerdo ver revistas de Spectrum que compartían el código de videojuegos sencillos íntegramente en binario.
Esta historia me suena, como el sr, Bill Gates compró en su día un S.O. muy parecido al que has diseñado, por la modesta cifra de 5000$ y luego vendió a IBM, haciéndose multimillonario, monotarea y monousuario, sistema de 16 bits. Tiene mucho mérito hoy en día muy pocos programan en ensamblador, hace muchos años hablo del 1982 con 11 años mi intención era comprarme mi primer micro-ordenador Z80 de 1k de memoria y sólo era posible programar en ASM. Mucha fuerza y a seguir en este camino que nos aporta mucho a todos.
Recuerdo aquellos años ochenta del éxito del ZX Spectrum 16 o 48k que en las revistas de Spectrum venían los ejemplos de pequeños juegos a desarrollar directamente en binario, ni ensamblador, ni leches, todo más complicado. En parceladigital.com tengo publicado un artículo en texto donde hablo del QDOS (poco después 86-DOS, también tengo publicado un vídeo donde instalo en máquina virtual una de esas versiones anteriores al MS-DOS). En primera instancia Microsoft pagó entre 50.000 y 75.000 dólares a la empresa de Tim Paterson por el QDOS. Pero cuando el MS-DOS tuvo éxito, la empresa del QDOS demandó a Microsoft e IBM, y ahí sacó hasta un millón de dólares. Es decir, en realidad el QDOS no fue vendido barato, se vendió por algo más de 1 millón de dólares de 1981, que era mucho dinero. Programar en lenguaje ensamblador hoy en día requiere muchisimo conocimiento, mucha paciencia, y mucho tiempo libre. Yo hago cositas, pero solo eso, meterse más a fondo da miedo y escalofrios. Gracias por tu comentario.
No estoy de acuerdo. Compró por 50.000 (0 75.000 dólares según algunas fuentes). Y cuando Microsoft licenció el MS-DOS a IBM y se dispararon las ventas, SCP, empresa creadora del Q-DOS, que finalmente se llamó 86-DOS demandó tanto a Microsoft como IBM, y con esa demanda se afirma que ingresaron otro millón de dólares (aproximadamente), como compensación. Se ganó bajo demanda, los derechos ya habían sido comprados por los 50.000 dólares.
Tremendo trabajo, increible que algo tan simple solo demuestra que por más que pasen los años los computadores siguen siendo calculadoras
Gracias por tu comentario.
😅 mi cerebro salio del grupo , rayos bro , que eres un genio real en accion !!!!, te felisito por tu tremendo trabajo!!
En realidad los genios son los que terminan el sistema operativo, esto solo es la base inicial. Gracias por tu comentario.
te envio mis felicitaciones y orgullo de hombre, como creador ya haz alcanzado una meta enorme, espero no te obseciones por terminarlo tu solo. lo que haz echo hasta aca es suficiente, ya inspira a nuevos programadores. gracias
No me obsesiono porque no lo continuaré. Hacer todo lo que viene detrás es para genios, y no lo soy, y llevaría mucho tiempo y me tendría que dedicar solo a eso. Y debo seguir contando otras historias en ParcelaDigital. Muchas gracias por tu comentario.
Con el Spectrum aprendí a programar en ensamblador de Z80. habia un ensamblador que se llamaba GENS y un desensamblador que se llamaba MONS. yo los tenia los dos.
Gracias por tu comentario.
De Hispasofht
Mi admiración! Aquí un nuevo suscriptor.
Una pregunta, el código mostrado son secciones para ilustrar o es el código completo que digitaste?
Pues la verdad no sé si muestro el código al 100% en pantalla, pero casi todo está. Para lo que muestro en el vídeo el código no es grande. Es complicado, pero no grande. Eso sí, lo hecho es una pequeñísima parte de lo que necesita un SO de los 80, para hacer un SO completo el código fuente sería mucho más grande. Gracias por tu comentario.
@ Gracias a ti!
Que proyecto tan magnifico ! Y que dominio de la informatica ! Me encantaria tener tu nivel !!!!!! Te saludo en la distancia.
Hay muchos años y muchas horas de trabajo detrás de alcanzar el conocimiento. Y aún así está muy lejos del conocimiento necesario para construir al 100% un sistema operativo. Gracias por tu comentario.
Impresionante. Jamas, JAMAS ME SUSCRIBO con ver 1 video, pero es que te llevas todos los premios. Ansioso por lo que sigue
Demasiado benévolo con tu comentario. Gracias por escribir y suscribirte.
buen trabajo. Es de esas cosas que siempre me llamó la atención hacer. Saludos
A mí también me llamó la atención. Hacer un sistema operativo completo tiene muchísimo trabajo y requiere muchísimo conocimiento. Lo del video solo es una pequeña parte de todo lo que hay detrás de un SO ochentero. Gracias por tu comentario.
Qué bonito! Mola muchísimo!
Gracias por tu comentario.
impresionante ver como antes se tenía control sobre absolutamente toda la máquina. Mis felicitaciones.
Gracias por tu comentario.
Saludos desde Cuba. Mi respeto bro.
Muchas gracias por tu comentario. Y saludos para Cuba.
Muy buen contenido, felicidades por el contenido
Gracias por tu comentario.
Espectacular, felicidades!!!
Gracias por tu comentario.
Saludos desde Venezuela, soy informatico y empece en los 80's, tambien tengo entendido que los SO establecen un orden de prioridades para los procesos, esto viene de los computadores que usaron en las misiones apolo a la luna
En realidad, un sistema monotarea como éste, solo tiene una tarea que ejecutar, y es la que se "adueña" en la ejecución. Otra historia es la multitarea. Inicialmente los SO utilizaban una multitarea cooperativa, donde el proceso "mandaba", podríamos decir, y normalmente otro proceso no comenzaba hasta que el que estaba en marcha no terminaba. Después llegaron los SO's con multitarea apropiativa, donde la CPU es la que decide en cada momento que proceso se va a ejecutar. Entiendo que te refieres a eso cuando hablas de procesos. Gracias por tu comentario.
Currazo!! Felicitaciones por el proyecto.👍🏻👌🏻
Gracias por tu comentario.
Gracias por la aclaración.
Gracias a ti, por comentar.
Me has retrocedido al tiempo en que programábamos el 6502 en ensamblador. Una observación sobre el video, no se ven las letras del editor ni de la pantalla de tu ordenador. Si quieres mostrar el trabajazo que te has dado, pon la fuente mas grande ,tienes la parte central del video vacía y en blanco. Y si es porque te puedan copiar el código fuente, no creo que haya nadie que se ponga a hacer lo que tu has hecho. Gran trabajo, felicitaciones..
Te agradezco tu apreciación y consejo, y lo tendré en cuenta para el futuro. Gracias por tu comentario.
Muy interesante. Una locura hacerlo hoy en día de 0. Sólo pensar en controlar los puertos, las IRQs, acceder a tarjetas externas sin drivers ni nada.. uffff :)
Efectivamente todo lo que viene detrás muy complicado. Gracias por tu comentario.
Súper interesante 👍👍
Muy interesante aun me acuerdo las practicas con el Z80 CPU y con un comun teclado hexadecimal y un display solo de puros leds
Otros tiempos muy interesantes. Gracias por tu comentario.
Menudo proyecto ! Me encantaría ayudarte en lo que pudiera aunque estoy muy oxidado con la arquitectura de un PC . La verdad me he tirado hace mucho a Arduino y FPGAs ultimamente . Pero si necesitas una mano cuenta conmigo .
También estoy oxidado, y ya me costó hacer lo que se ve en el vídeo. Gracias por el apoyo, y por el comentario.
muy interesante
Pues este video es como para dárselo a mi abuelo! je je jeje 😁 no, mentiras. Muy bueno. Con los años, todo este conocimiento se pierde con las nuevas generaciones, y la IA que viene a hacernos la vida mas tonto... digo, mas fácil! PD: no sabes donde me descargo la imagen "disquete" del sistema operativo D.O.S 3.30 de IBM para el IBM PC XT ? Saludos desde Cali Colombia
Busca el PC-DOS en archive.org, allí seguro que encuentras imágenes del disco. Después se trata de conseguir volcar la imagen en disco en un ordenador que tenga disquetera. Gracias por tu comentario.
@@parceladigital Gracias 🤩
ya estoy suscrito
¡Gracias!
👏👏👏👏👌
🙏
😁 ya me subcribi a tu canal
Gracias por suscribirte.
Saludos, me suscribí, espero publiques el código fuente y el API de tu sistema, tengo un editor de texto que puedo rehacer para tu sistema, te lo enviaré con su código fuente en ensamblador. Jhonatan.
No me he planteado publicar el código porque lo que muestro en el vídeo es la base, muy básica. Lo realmente complicado viene detrás, y requiere mucho conocimiento y mucho tiempo de dedicación. El objetivo era mostrar esa pequeña introducción. Gracias por tu comentario.
Basicamente para programar en assembly language se necesita conocer bien la arquitectura del processador su set de instrucciones registradores buffers operaciones logicas ect ect ect........
Hola capo una pregunta solo Tenes que conseguir los programas para crearlo y saber un poco de Hardware y los cálculos matemáticos pasar a código maquina 0 y 1 binario lo hace el Programa ? recién me inicio en esto te ganaste un suscriptor..!
Hay que conocer muy bien al hardware, hay que conocer muy bien el funcionamiento del microprocesador, y hay que programar en ensamblador las partes más fundamentales y en lenguaje C el resto.
Fantástico trabajo. Me pregunto si este tipo de código sigue funcionando en BIOS modernas UEFI (sin compatibilidad CSM)...
Pues la verdad, no lo he probado, pero me da que no funcionará. Lo hecho está totalmente enfocado a lo que había en los ochenta. Gracias por tu comentario.
Sería interesante que una IA te ayude y probar en un hardware real de 16 bits .👍🏻
En los últimos años he investigado mucho con la IA y ahora mismo es una tecnología que llama mucho la atención en muchos aspectos, pero que falla bastante en otros. Es una inteligencia artificial que te puede ahorrar trabajo, pero se requiere al lado a una "inteligencia no-artificial" que revise y supervise todo. En el aspecto de crear código fuente la IA te puede quitar trabajo, pero no es muy efectiva a la hora de generar un código tan complejo y que funcione bien. Le tienes que estar guiando constantemente. Gracias por tu comentario.
Y el apartado del mapeo de la ram y el manejo de la memoria por el mono que lo usa? (mono usuario...)
Todo lo que sea avanzar sobre la base que se ve en el vídeo, ya se entra en un mundo complicado. No solo hay que tener en cuenta que el sistema operativo es monousuario, sino que además es de 16 bits, y la memoria no es líneal, porque no estamos ante un modo protegido, sino ante un modo real. Por tanto, de mano, la RAM se divide en memoria convencional (los primeros 640 Kb), memoria alta, y memoria reservada. Después se puede utilizar la interrupción de la BIOS 0x15 para consultar el espacio máximo de RAM, desarrollar código para reservar y lberar bloques de memoria, hablar de pila, heap, o memoria del usuario. De los 4 módulos que hablo en el vídeo (bootloader, kernel, filesystem, y comandos de usuario) todo eso de la gestión de la RAM iría dentro del kernel monolítico, como la interacción con cualquier otro componente hardware del equipo. En el kernel va toda la interactuación del sistema con los servicios de hardware. Como indico en el vídeo, desarrollar un SO de 16 bits monousuario, monotarea, y con núcleo monolítico es realmentre largo y complicado. Muy complicado. El vídeo muestra una base sencilla, fácil de aplicar (comparado al resto, porque en Ensamblador no hay nada fácil). Entonces nos podemos imaginar lo complicado que será desarrollar un SO con multitarea o multiusuario, con micronúcleo o microkernel... Gracias por tu comentario.
@@parceladigital gracias por responder, no hablo de crear un SO multi. Digo que el caballo de batalla del MS DOS era que el vector de memoria de los aplicativos, quedaba siempre marcado por la misma direccion de carga. Tal como hay una interrupcion para invocar al disco en el arranque y que por defecto nos devolvera el primer sector, cilindro invocando a la cabeza cero, esto tiene como automatizacion (lo que el cmos y la bios digan) que banco de memoria es el de arranque para comenzar el volcado de lo que el procesador vaya concluyendo como resultado final.
La lucha que todos teniamos y tu tambien lidiaste con ello, era dejar el mayor espacio libre en la memoria base para poder lanzar programas cuyo ejecutable de lanzamiento siempre rascaba algo mas de los 300kb de ram. Si el SO en ram ocupa memoria base, lo estamos quitando de la gestion aplicativa. De esta manera, cuando el MS DOS terminaba la carga, siempre coincidian los bloques mas importantes en las direcciones cargadas en ram y podias entender que direcciones en hexadecimal eran las criticas. Por ese motivo, los virus que se programaban por esa epoca, solo funcionaban en MS DOS, porque Linux, a parte de ser liberado el primer kernel en 1993, gestionaba la memoria completamente diferente y los vectores de ataque eran mucho mas complejos.
Una abstraccion usada en Linux en los primeros kernels, fue la de darle al usuario un acceso a un disco ram, sobre el cual podria ir montando el resto de herramientas y aplicativos, pero todos ellos siempre necesitaban el puntero base de acceso al recurso fisico instanciado en ram. Esto producia que, si un archivo se infectaba con algun virus (pongamos por caso que en mi propio ordenador quiero modificar un archivo base de arranque del kernel), lo estaria haciendo en una imagen temporal de la ram, que al reinicio, se perderian los cambios. La manera de hacerlo perdurable era montando los perifericos de hardware y accediendo por referencia al puntero ram, entonces con un ls se listaba el contenido de archivos del medio fisico al cual estas apuntando desde la instancia de la ramdisk. No era hasta que el kernel terminaba de cargar, que liberaba el usuario maquina o root y permitia el login al usuario como usuario maquina, solo entonces, podrias indicarle al sistema que debia montar. Esto requeria en primera instancia, montar las carpetas de sistema base, si deseabas que el sistema base te montara el acceso al aera de usuario segun terminaba de arrancar, debias modificar el archivo de inicio (ya con la carpeta del sistema referenciada como puntero en ramdisk) y los valores de inicializado.
No pretendo que tu retro DOS sea asi, porque no es el objetivo, pero si que me resultaria muy interesante que, al finalizar el ejercicio, permitieras al sistema base de 16 bits, lanzar otra instancia de si mismo y que ambas instancias se comunicaran, siendo que ambas son monousuario, que la instancia esclava dependera de la maestra y que se puedan instanciar tantos esclavos como ram lo permita (16Mb a dia de hoy es como unas casi cuatro mil veces menos de lo que esta soportado)
Efectivamente, mucho me tocó lidiar con el MS-DOS para optimizar la memoria. Al principio lo hacía a mano, en las últimas versiones de MS-DOS primero ejecutaba el MEMMAKER, pero no realizaba la mejor optimización, y una vez ejecutado, hacía cambios a mano en autoexec.bat y config.sys para optimizar la memoria. El MS-DOS utilizaba el modo real, y solo podía direccionar los primeros 640 Kilobytes de la RAM. El resto era memoria alta, extendida o expandida. Recuerdo que en los noventa había videojuegos que ocupaban tanto de la convencional, que había que optimizar muchísimo para liberar 625 o 630 kb de convencional para que pudieran ser ejecutados. Anoto tu sugerencia, aunque hacer lo que hace el vídeo, que es una base muy básica, me llevó demasiado tiempo y demasiados problemas a solucionar. Trabajar en desarrollo de SO's son palabras muy mayores. El objetivo es que personas que tuvieran cierto nivel de conocimiento de programación, pero que nunca hubieran bajado al bajo nivel, puedan comprender de forma "sencilla" (si se puede decir) la base de un SO de aquellos años ochenta. Que el QDOS, el CP/M, o el propio MS-DOS en sus primeras versiones eran muy sencillos. Por tener, no tenían ni carpetas. Gracias por tu comentario.
@@parceladigital ciertamente el desarrollo de software orientado a sistemas, es muy complejo, y antes de abordar su codificacion, se hacian unos calculos previos sobre cuantos ciclos de relog se consumian por tarea y si los ciclos eran completos o quedaban a mitad. La lucha eterna del CISC y su software era esa misma, la de ser capaces de ir cerrando tareas a ciclos completos sin dejar huecos por optimizar. Las ventajas muchas: Se evitaban casi el 90% de los problemas de la fragmentacion en memorias cache y su traslado a la ram.
Muchas de las inestabilidades de windows 98 y Me, eran precisamente esas: Fragmentaban las memorias de trabajo y los cierres de sesion acababan con archivos corruptos, por lo que un Windows 98 y/o Me no solian dirar mas de un anio sin tener que formatear. En las workstation se recomendaba usar windows NT, heredero de la arquitectura de software Xenix. Su implementacion en Windows XP y Windows 2000, nos hizo cobrar la esperanza de qucrosoft podria hacer cosas buenas, pero el software basado en arquitecturas de anillo nulo, son demasiado malos a la hora de evitar amenazas externas, si bien para puestos de trabajo ofimaticos y de produccion son de lo mas cookies y te encarinias con ellos, nunca debemos olvidar que no estamos solos en un mundo interconectado y es por esta interconexion por lo que Windows y su arquitectura de software de anillo nulo se demuestra completamente dependiente de estar conectados con sus creadores desde el puesto final de usuario, porque son ellos los que proporcionan la verdadera seguridad, centralizada en su capacidad de decirle a tu maquina como debe vigilarse a si misma.
Por otro lado, Linux es un sistema muy peligroso, pues es como si le das dos pistolas a un mono, si la persona que usa Linux en modo escritorio la tienes integrada en una red corporativa y los conocimientos de esa persona no son los adecuados, ese ordenador con Linux puede llegar a exponer la seguridad de la red al completo de una manera mucho mas peligrosa que un windows, pero las ventajas no se pueden comparar, las capacidades que te permite linux a la hora de hacer analisis forense, no las tiene windows, por eso, la seguridad real de Linux es su capacidad neta de estar en un estado de consumo minimo, en las tareas comunes que permiten apalancar el uso de la maquina de cara al usuario, mientras que windows, su consumo es el maximo en las tareas comunes y no comunes con un apalancamiento en el hardware y de cara al usuario, maximo. Cada cual en su liga, tienen su concepto de seguridad definido. Con ninguno de los dos sistemas se puede decir que, uno esta completamente seguro.
Gracias por tu aportación, que es realmente interesante.
🇲🇽♀️👍🏻♀️🇲🇽
Se podría programar una bbs con algún lenguaje de alto nivel como Python ??
Sí, se puede programar una BBS enb Python. El Python es un lenguaje muy versátil, permite muchas cosas. Pero en los ochenta las BBS no se hacían en Python, lógicamente el lenguaje no fue lanzado hasta el año 1991. En los ochenta, normalmente, las BBS se desarrollaban en lenguaje C.
Soy programador y has hecho un buen trabajo.
Sólo que no necesitas aclarar 100 veces que es una tarea complicada.
Cualquiera puede darse cuenta de ello.
Complicado es programar en alto nivel, esto es mucho más que eso, es otro nivel. Por eso tienen tanto mérito aquellas personas que en solitario o en pequeños grupos desarrollaron aquellos sistemas operativos en los setenta y primeros años ochenta. Este vídeo lo ve mucha gente que le gusta esto, pero que nunca ha programado... incluso repetirlo 100 veces, se puede quedar corto. Fui durante unos cuántos años profesor de informática, y me quedó claro que la reiteración no solo no sobra, sino que puede ser necesaria.
@@parceladigital Tengo 79 años y podrás imaginarte que la programación era a nivel máquina.
"es complicado, es complicado........ " me suena a "Mirá mamá, sin manos!!!!"
Nadie lo hace en binario
Ahora no, ni siquiera en ensamblador. Pero en el pasado sí se hacían cosas en binario. Y algunas sin salir de casa. Todavía recuerdo ver revistas de Spectrum que compartían el código de videojuegos sencillos íntegramente en binario.
Esta historia me suena, como el sr, Bill Gates compró en su día un S.O. muy parecido al que has diseñado, por la modesta cifra de 5000$ y luego vendió a IBM, haciéndose multimillonario, monotarea y monousuario, sistema de 16 bits. Tiene mucho mérito hoy en día muy pocos programan en ensamblador, hace muchos años hablo del 1982 con 11 años mi intención era comprarme mi primer micro-ordenador Z80 de 1k de memoria y sólo era posible programar en ASM. Mucha fuerza y a seguir en este camino que nos aporta mucho a todos.
Recuerdo aquellos años ochenta del éxito del ZX Spectrum 16 o 48k que en las revistas de Spectrum venían los ejemplos de pequeños juegos a desarrollar directamente en binario, ni ensamblador, ni leches, todo más complicado. En parceladigital.com tengo publicado un artículo en texto donde hablo del QDOS (poco después 86-DOS, también tengo publicado un vídeo donde instalo en máquina virtual una de esas versiones anteriores al MS-DOS). En primera instancia Microsoft pagó entre 50.000 y 75.000 dólares a la empresa de Tim Paterson por el QDOS. Pero cuando el MS-DOS tuvo éxito, la empresa del QDOS demandó a Microsoft e IBM, y ahí sacó hasta un millón de dólares. Es decir, en realidad el QDOS no fue vendido barato, se vendió por algo más de 1 millón de dólares de 1981, que era mucho dinero. Programar en lenguaje ensamblador hoy en día requiere muchisimo conocimiento, mucha paciencia, y mucho tiempo libre. Yo hago cositas, pero solo eso, meterse más a fondo da miedo y escalofrios. Gracias por tu comentario.
Primero lo LICENCIÓ y luego lo compró
No estoy de acuerdo. Compró por 50.000 (0 75.000 dólares según algunas fuentes). Y cuando Microsoft licenció el MS-DOS a IBM y se dispararon las ventas, SCP, empresa creadora del Q-DOS, que finalmente se llamó 86-DOS demandó tanto a Microsoft como IBM, y con esa demanda se afirma que ingresaron otro millón de dólares (aproximadamente), como compensación. Se ganó bajo demanda, los derechos ya habían sido comprados por los 50.000 dólares.
Correcto se lo compro a Seattle Computers en Oregon al dueño fe esta compañia que era amigo del socio de Bill Gates.
Para el que le interese, ya otros clones del MSDOS pero de código libre como el Freedos y otros.