Fecha actual Jue Ago 22, 2019 5:26 pm

Historial de Logros de BOOTCFG

[html]Programacion/OS/BOOTCFG/Description.txt[/html]


Usuarios leyendo este tema: Ninguno

Historial de Logros de BOOTCFG

Notapor ~ » Mar Jun 20, 2017 2:20 am


Mapa del sistema de lo que BOOTCFG
y el kernel de LowEST, Nivel 1, contienen
actualmente:




BOOTCFG es el cargador de arranque nativo para mi kernel de LowEST.

BOOTCFG está diseñado para correr bajo DOS, aunque los trucos que
contiene son útiles para la plataforma de la PC en general.


La versión inicial se puede descargar aquí, actualmente en desarrollo
para su nivel. Contiene el kernel de LowEST más reciente mientras se
desarrolle cada versión para proporcionar la cadena completa de herramientas
para cargar nuestro sistema:
 BOOTCFG__v2017-06-16.zip




El kernel que contiene actualmente tiene un error en el que la disquetera
necesita ser accesada por lo menos 1 vez, por ejemplo cambiando al drive a:
o listando su contenido, ANTES de cargar el kernel con PATIO.COM y tratar
de cargar programas dentro del kernel. De lo contrario, todos los intentos
de accesar el medio desde nuestro kernel fallarán, así que tengo que
aprender más detalles para hacer innecesario el tener que accesarla desde
DOS por lo menos 1 vez.

Hoy le agregué el comando "exittodos" con el que puedo entrar y salir al DOS,
cargar y descargar mi kernel, siempre y cuando no haya algún problema
críticamente malo como correr un programa que destruya la estabilidad de la
computadora al regresar al DOS, aunque esto es extremadamente valioso porque
me permitirá depurar cada programa que corra y hacer que ni DOS se trabe al
salir del sistema al corregir todos los errores y deficiencias.






El kernel de LowEST está pensado para ser 100% compatible y amigable con DOS,
así que una vez que esté cargado, debo asegurarme de no alterar en lo más mínimo
el primer Megabyte (a excepción de cosas como variables del BIOS para el tiempo
y otras cosas para las que sería útil reflejar la configuración), y si altero
un área tengo que asegurarme de guardarla primero en otro lugar para poder
restaurarla cuando deje de usarla, así cuando regrese al DOS todo estará intacto.


Pero ese detalle de que el acceso al diskette falla me hace pensar que quiere decir
que el controlador y/o la disquetera no han sido configurados para inicializarlos,
así que tengo que aprender a hacer eso, desde mis programas de LowEST y/o desde
el kernel de LowEST, para que no falle en ningún caso... voy a tener que preguntar
eso en OSDev.....



Voy a acumular diferentes versiones útiles de un mismo programa de prueba, y
va a llegar un momento en el que voy a finalizar toda una versión del proyecto
en un único archivo ZIP.

Para la siguiente versión, debería limpiar el código y los archivos y eliminar
las versiones de los programas que no sean la última, de todas formas ya estarán
archivadas en el código de la versión anterior, y nos convendrá más limpiar
todo el código para empezar solo con lo mínimo posible para la nueva versión,
así que lo primero que tenemos que hacer para cada nueva versión es limpiar todo.

Incluir DOSLFN o ponerlo aparte en un lugar claro, una versión que nos sirva
para MS-DOS, FreeDOS, etc.......


Ahora lo que más me convendría es:

- Implementar paginación y módulos cargables del kernel.
- Subsistema de archivos para abstraer los dispositivos y los sistemas de archivo.
- Soporte completo para FAT32, con archivos, directorios, nombres cortos y largos,
  leer archivos de diferentes formas, escribir archivos... esto será crítico para
  tener un sistema más capaz.





App Roach: Crazy Test Library/Snippets/API





















Agregar mi programa ATADETEC.COM a LowEST y también al kernel de una forma con la que
podamos guardar la configuración detectada. También los de Craig Hart.

El primer paso en abstraer los dispositivos de un mismo tipo, en este caso de
almacenamiento, es crear un arreglo de estructuras portables que describan en detalle
completo cada disco duro, floppy, CD/DVD, y otros, además de discos dinámicamente
conectables como unidades USB, para lo que tendremos que hacer que se puedan eliminar
entradas del arreglo de discos, y que cada elemento diga si es una unidad fija interna
o removible (si es que eso tiene sentido desde el punto de vista de los estándares
de programación de hardware).


Hasta ahora, he comprobado que puedo detectar manualmente toda la memoria sin hacer
que el sistema se trabe, en el espacio de 32 bits.






Nuestro sistema tiene que reflejar a la perfección la estructura interna del hardware,
no debería agregar más terminología cuando esta ya esté definida a nivel de hardware,
y debería exponerla.




Después de alcanzar una meta, tengo que cambiar mi atención hacia los proyectos que otros
hacen para no dejar de aprender ya que en ese momento de logro también voy a quedarme
estancado en ocurrencias, y dejar de cierta forma guardado el disfrute de mis propios logros, dejarlo
en primer lugar para que mi cuerpo, células, cerebro, todo yo, lo disfrute a un nivel
vital desde el punto de vista de energía, vitalidad y más inteligencia.




Veo que cuando logro algo, todo se vuelve un tumulto de disfrute en la forma que percibo
mentalmente, y eso me ayuda a deshacer el ruido interno, así que veo que tiene un uso
intrínseco inesperado... solo tengo que seguir logrando más cosas, acelerar y tomarme la
tarea de crear suelos de 1 día para precipitar más avances.

Es como una fiesta de células.

Hoy por ejemplo podría averiguar cómo configurar el floppy correctamente, y cómo portear
ATADETEC.




Ver cómo funcionan los drivers de ReactOS/Windows XP y VxDs para basar el uso avanzado de
hardware no estándar en drivers de ese tipo cuando me ponga a agregar cosas más complejas a
mi sistema. Ese es el camino a seguir, y lo mismo con los drivers de Linux, básicamente
poder correr cualquier driver que exista siquiera para un dispositivo.

Para el hardware de PC 100% estándar, vamos a usar las configuraciones y programación conocida
desde en núcleo de nuestro kernel, así que siempre y cuando tengamos dicho hardware, todo será
más eficiente.


Comprobar si, una vez cargado el driver de la Sound Blaster desde DOS en la 386DX, podemos
hacer uso de esta al portear DMAW.C a Ensamblador y a nuestro kernel, veamos si podemos hacer
uso libre de esa tarjeta de sonido, porque si es así, deberíamos usarla para aprender cosas
de sonido y sobre cómo implementar un clon de estas, deberíamos conseguir o reactivar las computadoras
Pentium I o Pentium III, o ver si es posible con la Thinkpad 390x u otras, configurar primero
la tarjeta de sonido como Sound Blaster estándar con un driver de DOS, y después entrar en nuestro
sistema, correr un programa de prueba, madurarlo, y con eso empezar a implementar capacidades
de sonido.


Conseguir PCs con 2 puertos PS/2.


Pero como digo, todo el hardware estándar debe considerarse parte integral inseparable
de la PC, presente o ausente siempre en las mismas direcciones de memoria, pero con la
capacidad de que podamos configurarlo fácilmente aunque sea en el código fuente en dado
caso de que haya hardware con las mismas capacidades pero que esté en otras direcciones
de acceso.



Trabajar en agregar intérpretes para C, C++, Ensamblador x86 NASM portable,
paginación y protección de memoria y procesos, como mínimo, para tener todo lo que
necesitemos para hacer pruebas de importante nivel bajo nuestro sistema operativo y,
ya que es autónomo, nos dará todo el poder crudo de la máquina.....







2017-06-21 (Miércoles)
-----------------------------------

Parece que las DLLs son como módulos de kernel. Solo se cargan una vez solo que
a nivel de privilegio de usuario, a menos que sean drivers. Además eso quiere decir
que solo podría haber un número limitado de DLLs cargadas simultáneamente en
memoria. También el sistema necesitaría arreglar las direcciones en el ejecutable
para reubicarlos en donde hayan sido efectivamente leídas.


Es realmente poco lo que tengo que saber para implementar cualquier cosa, en este
caso lo de las librerías dinámicas simples, pero es algo que tengo que extraer de
una extensiva meditación, lectura e intentos de implementarlo.

Es igual de lento que cuando trato de buscar cómodamente un camino no verbal que
aparentemente no está pero que cuando le doy seguimiento mentalmente con tranquilidad,
ya que las lógicas maestras siempre son calmadas, cuando nos ponemos a entenderlas
y estudiarlas. Así que es lo mismo, es de buscar ese camino lógico no verbal de
forma natural en lo que leemos, que se vaya formando a partir de todo el material
"descomprimido" con relleno, detectar qué es lo realmente fundamental, y avanzar
desde ahí.

Solo es de ponernos a meditar descansando, hasta acostados, pero aquí no solo vamos
a tratar de pensar cómo implementar esto, sino que vamos a leer muchísimo
material externo como un módulo extra a cargar a nuestras acciones, para
alimentarnos con un flujo de información externa válida descomprimida
que tenemos que procesar para nuestra implementación.


A ver qué efecto tiene hacer eso con un tema difícil como la paginación,
librerías dinámicas, multitareas, relocaciones... a ver en cuánto tiempo
sin limitarnos terminamos entendiendo lo suficiente como para implementarlo.
































I'm currently looking for the best way to initially make use of paging and given that I need to load modules dynamically into my kernel core, I think that I have come up with learning some details, but I don't know if it's a complete view on its own.


It seems that paging was never intended as a relocation mechanism. The very only thing paging does is mapping physical memory addresses to virtual addresses, but since you can only map a virtual address once in a process, you woldn't be able to map all of the dynamic loaded libraries to, say, address 0x100000 for the same process, so you would really have a limited number of libraries loaded simultaneously depending on the size of the memory.

I say that paging isn't really for relocation because we could recompile at run time, write position-independent code, use protected-mode or real-mode segmentation, instead of paging. We could even use the same physical address for all libraries, keep track of which one is currently loaded, and load back and forth the one we need, but obviously this last thing would produce a very unclean and confusing system.

It seems that if we want to relocate something, the only really intended thing to do so is to actually know which parts of the opcodes to relocate depending on where the program was actually loaded, by the time the code is loaded, and do so manually. Then we will have a relocation system portable to flat memory, real-mode, paging, protected-mode segmentation...

Shared libraries, dynamic link libraries, drivers, etc., are in reality like kernel modules, so they are only loaded once and mapped for any processes that want to use them. They need to be relocated first of course, except maybe for very few cases. The only detail is that all those libraries or drivers can be loaded with different privilege levels, but they are still basically kernel modules.

______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
So, I'm figuring out that if I want to use paging for dynamically loading modules into my kernel and programs, I'd actually be better of by developing a relocation system instead, to begin with.

But for that it seems that I would need my relocator to know all of the x86 opcodes in existence for 16, 32 and 64-bit mode, then provide it with a table with the start address of each instruction, so that it relocates as indicated.

It seems to me that I cannot do this with paging alone. If I were to load dynamic libraries in their own virtual address spaces  using multitasking capabilities for it, I would probably need some inter-process calling functions to make use of such libraries, but then I would need some way to distinguish between libraries, if I load them to the same virtual address in different virtual spaces. Then I would need to indirectly call those libraries via a position-independent mechanism like an interrupt that selected between them. But it seems too unclean of a code base.

[b]It seems that whichever method I choose to use to implement dynamic loading, it has its own different yet equally complex details to implement, but a generic relocator for code and data seems to come before memory management. It seems to be portable to any memory system/layout.[/b]

The only other option would be to link modules statically into the kernel, but even in my OS, which is extremely basic, the need to dynamically load stuff at any address can no longer be escaped without becoming stuck with lack of system capabilities.

I thought that I could have the kernel load a binary, program or library, at any address, and then return me the base load address probably in EBP/WIDEBP, but then I would probably need to rewrite all of the code I've ever created to support this position independence, and if I load more than one library it would also become very difficult and very unclean to keep a base address initially in EBP for each one and switch between them, and being able to store and find it repeatedly.


So how do you do with or without a relocator and with or without paging, [b]to support dynamic loading of kernel module,
 library code, and then program code[/b]?














Al implementar la parte de la memoria virtual que saca las páginas hacia disco, podríamos
guardarlo en una estructura de archivos y directorios en una forma fácil de leer (y depurar)
y dejar dichos archivos ahí hasta después de que se cierre el programa. Después deberíamos
tener la libertad de eliminar los archivos y directorios que no estén usándose, o ponerle
también funciones al sistema para que lo haga de forma limpia.






Si yo tengo actualmente 33 años acabados de cumplir y alguien más tiene 22 años,
tengo que tomar en cuenta que tenemos una diferencia de 22 años, y si yo viví
mi mejor época en el 2004-2005, esa misma persona la habrá vivido 11 años después,
es decir que su mejor época la habrá vivido en el 2015-2016, y si este año en el
que estoy poniendo esto es el 2017, quiere decir que esa persona está viviendo
su mejor época justo en estos años, así que si se comporta de forma "pedante"
puede que no sea eso, sino que simplemente no ha terminado de ver cómo es su mejor
época de vida, una de sus mejores épocas sin contar más atrás, así que podrían
sentirse tan bien como yo en esa época.

Igual el resto de la gente con desfase de más o menos años, habrán vivido sus
mejores épocas, o las vivirán, en tiempos correspondientes... así que tengo que
tomar eso en cuenta para saber cómo se sentirían, además de detectar cómo se
podrán de hecho sentir...... no todos se sentirán exactamente igual a mí.



Hay que cuidar no solo lo interno del código sino que también su uso externo,
tanto en un programa como ya a nivel de usuario, para asegurarnos de que de verdad
está bien hecho.


Escribir funciones con información de reubicación en cada opcode donde haya una
dirección a hacer independiente. Por lo menos eso va a hacernos estudiar más
de los opcodes y a pensar en hacer el código mucho más portable, aunque tengamos
que reescribir todo lo que hayamos hecho en Ensamblador x86 hasta ahora, pero
quedará extremadamente portable.







Tan pronto como se cargan más de 2 cosas en memoria, especialmente 2 procesos
o librerías de sistema y después varios programas, todos de diferente tamaño,
necesitaremos algún tipo realmente estable de reubicación de direcciones (relocation).

Como mínimo nuestro código debe estar preparado con etiquetas de ese tipo, y después
algún tipo de stub en el programa mismo que sea código independiente de posición,
o simplemente un reubicador simple de código que simplemente examine la lista de
direcciones a reubicar, y les sume la dirección base en la que realmente termine
cargando ese código.



Y también, tan pronto seamos incapaces de lidiar con la fragmentación de memoria,
necesitaremos la paginación.

Cuando solo es un proceso, y cuando cargamos todas las librerías dinámicas proceso
por proceso de forma privada, podemos finalizar la ejecución de forma ordenada
para que el sistema nunca se ponga inestable, y regresarle el control al kernel.
Entonces, el siguiente programa simplemente cargaría otra vez todas las mismas
librerías y las del programa anterior simplemente desaparecerían.



Realmente tengo que hacer uso más extensivo del sistema que estoy haciendo, agregar
algunas cosas como cargar archivos enteros a una posición determinada de memoria,
o funciones normales para leer parte de un archivo.

Con eso podría extenderme y hacer poco a poco un cargador con reubicaciones como
programa externo. También podría ensayar la protección y las excepciones de una forma
en la que si un programa externo falla, este simplemente se cierre.

Para eso creo que voy a necesitar multitarea que, aunque no cambie de tareas
inicialmente, sí llame a los programas con multitarea para que si algo falla,
pueda seguir siempre usando el sistema y pueda regresar al DOS y seguir haciendo
más y más pruebas.

Creo que todo esto viene antes de que de hecho la paginación me sea útil
o alcanzable, antes de que realmente tenga necesidad de usar tantas cosas.

Creo que es una forma natural en la que poco a poco podría alcanzar ese nivel porque
parece que de todas formas necesito jugar con el sistema que tengo para ver por dónde
va cada cosa.



Tengo que agarrarme de contarle inicialmente a alguien lo que necesito hacer
en términos que cualquiera pueda entender, preguntando si conocen algo y haciendo
una comparación para hacer una clase excelente, también grabarlo,

Una vez que le cuente una cosa de ese tipo a alguien, a quien sea, puedo quedarme agarrado
de esa pista y seguirle contando a absolutamente cualquier otro, para no aburrirme y para
llevar el control de lo que estuve haciendo. Así cada vez que me aburra o haya
conflicto le puedo contar eso a alguien, y si mantengo esa pista permanentemente
como los cilos de trabajo o como el desarrollo constante de un kernel,
voy a poder hacer uso de transmitir esa perspectiva vaya donde vaya,
no importa quién sea.





¿A veces has hecho señas en lo que escribís para encontrar algo?
Apues así son los programas para encontrar la dirección de cada función
o cosa que hay en el código, variables, direcciones de cualquier cosa,
y entonces tengo que agregarle al programa una función y de esas señas
(o etiquetas) a cada dirección que necesite reubicar de forma simple,
aunque eso me va a tardar un rato.







Tengo que ir paso a paso y agregar microtrucos para asegurarme de agregar
lo mejor en el código, tan pronto como a partir de mi creatividad detecte
que algo es un microtruco aislado y autónomo.

Por ejemplo, el agregar una tabla de reubicación y etiquetas a todo el código
de un programa es un microtruco para agregar la capacidad de reubicación
(relocation) más simple, a todas las direcciones relativas al inicio del
programa, al sistema, aunque tenga que agregar muchísimas etiquetas.




Puedo ver cuánto valor comprimido real y capacidad de nivel de sistemas operativos
tiene lo que aprendí en el ITCA, con mi amiga gata y con el libro de Ensamblador 2005
de Charte Ojeda... todavía estoy expandiendo útilmente el conocimiento que aprendí
en ese tiempo aunque tenga nivel básico, pero sigue sirviendo perfectamente bien.




Solo hay que ver cómo funcionaban los programas de MS-DOS para ver que ni siquiera
usaban librerías cargadas dinámicamente y realmente tampoco reubicación de código,
y tenían multihilera, 32 bits, gráficos, red, acceso al disco, y como mínimo tenían:

- Lectura de archivos del disco.
- Carga de programas hijo.
- Línea de comandos.


Así que yo debería poder ensayar absolutamente cualquier cosa con el sistema que tengo,
y por supuesto ir agregando cosas cada vez más complejas pero sin perder lo simple...
este es un momento en el que debería poder aprovechar ya todos los libros y código
que tengo.





Un administrador gráfico como el explorador de archivos para DOS no necesita mucha
multitarea, a menos que empecemos a agregar la capacidad de lanzar programas hijo,
que sería una gran herramienta para DOS, quizás sería una de las cosas que más
interesaría en DOS para liberarse de Windows, reconocer todo tipo de discos,
sistemas de archivos, y tener cada vez más visores y editores de diferentes tipos
de archivos. Con eso se cubriría una cantidad realmente grande de lo que hace Windows,
pero definitivamente debería ser un sistema basado en DOS el que libere a la PC de
Windows.

Después de eso necesitaremos una librería de drivers de diferente tipo para tener
todos los dispositivos disponibles.






Podemos tratar de hacer que:

- Si un programa necesita acceso a cosas no estándar pero estas solo existen de forma virtual.

- Si necesita acceso directo a ese hardware estándar.

Entonces que ese programa se corra de forma 100% emulada en nuestro sistema, para poder usar
hardware moderno y seguir teniendo 100% de compatibilidad con la PC estándar, que es una
meta irrenunciable para poder aprovechar el poder actual de computación con la altísima
calidad científica de los estándares iniciales de las PCs.




Ignorar los errores de sintaxis y otros parecidos.










En este punto ya podría aprovechar el código de cualquier programa para aprender de este,
empezando por el de las cosas, tareas, trucos y programas que realmente uso actualmente.
Si empiezo por implementar eso en vez de cosas más teóricas y sin cohesión final para
aplicaciones finales, y hago yo esas aplicaciones finales junto con los trucos bien
documentados de librería, entonces realmente voy a poder avanzar en todo sentido.






Si escribo algo en un foro y alguien responde pero yo no he pedido que me respondan (aunque
realmente no me moleste) ni esperaba que lo hicieran, entonces no tengo por qué distraerme
con eso.













EOF
Imagen
IP for hosts file (email udocproject@yahoo.com to get updates if website becomes offline):
Código: Seleccionar todo
190.150.9.244 archefire.org



See what I'm doing in real time:
Main Desktop 1
Main Desktop 2
Avatar de Usuario
~
Site Admin
 
Mensajes: 2958
Registrado: Sab Nov 10, 2012 1:04 pm

Agregar Capacidad Simple de Reubicación (Relocation) para los Ejecutables Crudos del Kernel de LowEST, Nivel 1

Notapor ~ » Jue Jun 22, 2017 2:01 pm











________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________


En este primer nivel puedo agregar lo siguiente para que el kernel
y sobre todo los programs externos lo usen:

- Funciones para especificar el dispositivo, partición y sistema de archivos a usar.

- Funciones para encontrar un directorio o archivo. Devolver el clúster inicial
  además de la información que ya sabemos de dispositivo, partición y sistema de archivos,
  mediante nombre corto o nombre largo, dependiendo del sistema... empezar por usar
  directamente las funciones de FAT en los programas, y poco a poco dar la libertad
  de usar esas funciones más primitivas u otras más generales... en forma de escalera...
  esto nos va a dar la libertad y facilidad de usar muchos niveles de desarrollo
  de inmediato sin esperar a completar la cadena completa de nivel de C para usar
  funciones perfectamente utilizables a bajo nivel...

- Funciones para obtener el tamaño de archivo y leer un offset cualquiera del archivo.

- Funciones para cargar drivers nativos para poder usar cualquier driver que
  siquiera exista para un dispositivo cualquiera, cargarlo y correr un programa
  que use esos drivers y librerías relocalizadas con un estilo monotarea para
  ese programa. De esta forma podremos hacer funcionar sobre todo programas de
  DOS con código, que simplificaríamos y pondríamos en forma de librería, y después
  también en modo V86 buscando una forma de emular el entorno entero de la computadora
  para que el programa pueda hacer uso de este.

- Capacidad de correr programas hijo.

- Usar funciones del BIOS mediante modo V86 y/o emulación completa.








Normalmente tengo todo el día para lograr una única cosa, pensarla mejor de lo que
esperaba, y dejarla hecha, así que no tengo por qué rendirme en un día ni dejar de
tratar... sé que puedo tratar de hacer eso normalment en un proceso de 2 o 3
intentos que avanzan entre sí.







Podría terminar reimplementando un emulador como Bochs para mi sistema y correrlo
como un programa hijo.






Es posible que pueda evitar la fragmentación de memoria sin paginación si mantengo un
búfer circular de memoria en el que mientras el programa padre principal corra, este
se aumente cada vez que se reserve memoria dinámica, para que así cada programa nuevo
quede en una zona libre... al final es posible que al inicio de la memoria que estaba
usada queden áreas libres. También podría hacer que se carguen pequeños snippets solo
cuando lo necesite, podría especificar qué tamaño de código necesitaría para que no pueda
haber fragmentación (calcular en base a los programas y librerías dinámicas usadas, que
es algo que realmente no cambiaría normalmente en tiempo de ejecución con binarios).
Así podría poner el área de datos arriba de esa zona de binarios, y después podría
separar los datos que nunca cambiarán, calcular su tamaño máximo, y después arreglarme
de alguna forma con los datos dinámicos de tamaño desconocido... son trucos que me van
a servir a medida maduren para la administración formal de memoria.



Lo que sí no debo olvidar es que puedo agregar modos de operación, niveles y diferentes
casos de funcionamiento al sistema mientras mejoro los niveles básicos que ya funcionan,
sin interferir con estos ni destruirlos... así terminaré soportando diferentes cosas
pero eso solo será el efecto colateral de haberme puesto a avanzar con cosas que se
encargan de más tareas sin abandonar los niveles iniciales de mi desarrollo.





Lo primero que debería implementar es un administrador de archivos gráfico para DOS
con soporte completo para los diferentes sistemas de archivo, protección, multitarea,
paginación, librerías, APIs de Windows 9x y NT/XP, soporte para todos los tipos de
drivers existentes, sea cual sea, solo importa que existan drivers para un dispositivo
dado, capacidad completa para correr programas hijo, librerías dinámicas, y cada vez
más visores y editores para poder manipular rápido los archivos, salir al sistema base,
o al DOS, y seguir tranquilamente en lo nuestro.

En esto, absolutamente todos los sistemas operativos y programas de los que pueda aprender
los diferentes trucos, me van a servir. Creo que debería empezar con Slackware 10.x
y Topologilinux 7.0.1, que son los que entiendo mejor, y también ReactOS, MenuetOS,
VisOpSys, y los sistemas que publican en OSDev.org, OSDever.net, el código de Programmer's
Heaven, Pouet, de los proyectos de código abierto, los libros, y el resto de recursos
prácticos.

Un administrador de archivos de tipo GUI para DOS con drivers IDE, USB, SATA, red,
todos los sistemas de archivos, hardware nuevo y viejo, y drivers de ese mismo
tipo para DOS (por lo menos para mejorar el acceso y el booteo del DOS)
es actualmente la cosa más útil que podría hacer para hacer posible usar de forma
útil y rápida un sistema por demás simple y rápido, orientado totalmente al desarrollo
desde la plataforma de la PC pero pensando en la portabilidad con esos estándares.

Al mismo tiempo, no nos quedaríamos atrapados en ningún sistema existente solo por usar
las funciones que tiene de visor/editor/administrador de archivos con programas hijo
de todo tipo en multitarea.

















Hasta Linux debería ser una librería... así se siente que no se está dañando ni
rezagando, ni cortándole la circulación.
















Para resolver un problema solo necesitamos acampar ahí en su terreno y aprender
poco a poco qué detalles, soluciones y usos hay de acuerdo a lo que realmente
necesitamos y disfrutamos. Ya hay sistemas operativos finales hechos por miles
y miles de personas y con la industria misma, así que tenemos libertad de hacer
un sistema operativo que supla nuestras necesidades personales. Siempre aprenderemos
de todo todo, pero necesitamos resolver nuestros problemas reales para saber cómo
manejarlos ya que son las cosas con las que tratamos todo el tiempo, y a las que
podemos aplicarles mejor cualquier tecnología nueva para nuestro ambiente.











Podemos detectar fácilmente si una tarea es de un solo detalle o si es compuesta.
Si se nos ocurren muchísimas cosas que hacer con entusiasmo, quiere decir que
tendremos que hacer todo eso y ganar experiencia, habilidades y conocimiento
individual, especialmente concentrado para cada detalle. Si se nos ocurre solo
una cosa, quiere decir que es una idea que no tiene competencia a su nivel máximo
y tendremos que completarla.

La propiedad especial aquí es que si se trata de una tarea compuesta y se nos ocurre
muchísimo que hacer, podemos usar un truco en el que solo nos concentramos única y
exclusivamente en un único tema, aspecto, punto o detalle de esa tarea, como si fuera
lo único que necesitáramos hacer. El efecto es que podremos hacer el resto de tareas
según necesitemos sin pensar ni preocuparnos porque solo nos preocupará acampar
en un único problema hasta llevarlo al nivel de solución funcional que se nos
ocurra en ese momento. Es posible que solo necesitemos una parte intrínseca común
de los otros temas o aspectos para el que estamos tratando de resolver, así que
será mucho más fácil de desenmarañar. Una vez que completemos ese punto podemos
reevaluar y buscar otros detalles de vanguardia individual a desenmarañar de otra
forma, escribiendo el código específico a este y común a los otros temas, pero obviamente
para su lógica autónoma.

Es decir que la propiedad especial de esto es que si nos centramos en un único
detalle, especialmente si lo llevamos a su nivel de implementación trivial más simple
pero útil por sí mismo sin dependencias lógicas que lo precedan ni tareas simultáneas
de las que preocuparse, hará que podamos avanzar en el resto de tareas relacionadas,
y sin darnos cuenta lo haremos intrínsecamente, involuntariamente soloa hasta en la medida
que la lógica aparentemente de otras cosas esté ahí, porque´sería lógica común
de la que hacen uso para existir y funcionar como conceptos lógicos capaces de afectar
una tarea. Si empezamos a ese nivel desenmarañado con las infinitas funciones
en cuestión en limpio como para usar esos átomos o partículas lógicas, no tendremos
límite en el nivel de abstracción que podremos llevar después, aunque tendremos que buscar
los casos, lenguajes, bases, nivel de las capas existentes, ideales, para que no se vuelva
tan confuso que el código no se vea limpio.

No por nada se llama ensamblador, si realmente tenemos que desensamblar la lógica,
llevarla a las tareas individuales manejables en forma de microinstrucciones simplemente
de la plataforma de la lógica maestra de cada tarea, ni siquiera de un procesador, aunque
tengamos que conectarlo de la forma más limpia para que sirva en la máquina además de
manual o naturalmente.

Así nuestra capacidad de resolver las cosas se vuelve muy simple, inmediata y dura,
además de divertida, como probablemente están implementados todos los snippets buenos
de MS-DOS y juegos, que no tienen ni versión de tan buenos que son, e igual los
juegos de Atari... por eso quizás los programadores disfrutaban tanto encontrar
ese nivel simple, compacto pero completo de lógica.




Quizas por eso avancé tanto en el emulador de PC en HTML5, porque toda la lógica
involucrada ya está desenmarañada en sus tareas reducidas al mínimo, pero combinables
como instrucciones de procesador, así que puede que sea muy extenso, pero la naturaleza
de CPU y otros chips de funciones finales que tiene le dan claridad.
Probablemente la ingeniería se trata de llevar cada cosa a ese nivel discreto, final,
simple, desenmarañado individualmente, de detalles usables de forma final, de los que
hay infinitos.

La intención es llegar a desglosar cada tarea en sus puntos finales, simples, que
no tienen competencia, que son puntos de vanguardia ("top notch", "bleeding edge",
advanced) en donde solo tendremos que atenderlos individualmente a ellos siempre
a nivel fundamental en el que podemos empezar simples y agregar poco a poco
más experiencia codificada en más tareas y casos.










Con esta forma de trabajar aprenderemos realmente a ser vitales hasta nivel
microscópico, nanoscópico, y más.




Parece que en Internet lo ideal sigue siendo el contenido simple, liviano,
pixelado, pequeño, como de 8 o 16 bits... es más entendible, compacto, práctico,
y hace que nos concentremos desde los detalles más básicos, desde cero,
para aprender en todo momento.





Hay varios niveles de desarrolladores de sistemas operativos (OS Devs).
Están los que son parte de la industria que vienen haciendo computadoras,
sistemas operativos, programas de prueba y programadores de usuario desde que
hay computadora personal.

Están los que arman sistemas operativos desde cero y saben bastante de sistemas
operativos pero no se han puesto a usar el tiempo que no tienen para invertirlo
en eso.

Están los que saben bastante de sistemas operativos, pero usan programas de
aplicación mayoritariamente de otros. Avanzan muy rápido pero no se ponen a
tocar el estado de usabilidad del nivel más bajo y manual.

Están los que escriben sistemas operativos desde cero usando solo el Ensamblador
de la computadora de destino, normalmente la PC. Siempre que usan una herramienta
de un tercero para avanzar en un aspecto logran desenmarañarse para avanzar un
poco más pero se benefician también de forma máxima haciendo las cosas desde cero.
Obviamente si no entienden la estructura de todos los estándares existentes
harán un sistema que alcance estrictamente solo su conocimiento y habilidad máximos
actuales.

El resto que solo se ve escribir pero no en términos de implementación directamente
está trolleando y haciéndole perder tiempo y energía a la gente del foro, por la razón
que sea, y lo más sabio es no responderles para evitar acumular tiempo y energía
perdidos.











Mostrar código fuente en cuestión, preferiblemente que hayamos hecho o que entendamos,
junto con la lectura ordenada de un documento. Tal vez sea mejor hacer eso en átomos
de videos en una lista de reproducción, así podemos agregar más ejemplos para un mismo
tema, microtema, punto, detalle, de la lectura de un libro, así que cada parte de
un documento en la que nos detenemos deberíamos hacerla un video por más corto que sea...
así podremos agregar de forma sistemática, estructurada, como una base de datos de
video, más conocimiento que explique cada parte.


Sería una lista enorme y tal vez sería mejor actualizarla y accesarla con una
lista de reproducción como un único video ya compilado, así podríamos crear
la estructura localmente de forma tan masiva como queramos....





También deberíamos:

- Recodificar el 100% de archivos de todo tipo a formatos que puedan usar hasta las
  computadoras más viejas.

- Escribir visores para cada tipo de archivo individual.









Parece que después de todo un emulador no es tan difícil de hacer si este solo
trata con lógica desenmarañada de hardware que llevar a cabo en software, pero
igualmente desenmarañada. Por más complejo que sea el hardware, este ya está
desenmarañado al nivel lógico puramente aplicado, así que si no lo vemos así,
no estamos tratando con esa lógica.





Hay que usar muchísimo los verbos de precedencia para la programación.
"Más tarde", "antes de", "justo después", en los comentarios... así
sabremos qué buscar, si escribimos todo paso a paso, así aunque no
logremos poner un índice a seguir a todos los comentarios, vamos
a saber qué buscar antes, después de eso, en dónde estamos..., y si
tenemos un historial general todo se va a desenmarañar de inmediato.





Cuando nos ponemos a hacer cosas difíciles permanentemente nos dormimos más veces
porque hacemos más esfuerzo y también porque nos distraemos mentalmente lo suficiente
como para dormirnos sin problemas. Pero lo más importante es que aunque creamos
que es algo demasiado difícil, es lo que necesitamos para estar en nuestra mejor
condición mental de una forma en la que hasta sin querer el ruido inútil externo
deja de percibirse ya que esos pensamientos obviamente tienen más intensidad que
el ruido solo por su dificultad.






Agregar todas las funciones del hardware y el CPU puramente en software.
Así las tendremos a disposición todavía más libre y podremos hasta hacer
uso de ellas, lo que se llama emularlas, cuando lo necesitemos.
El sistema tiene que tener una librería completa de las funciones
del hardware y lógica electrónica para ser más versátil y robusto,
ya que el hardware es nuestra API principal, así que simplemente necesitamos
reflejarlo implementándolo en software.

Quizás las implementaciones de cosas más nuevas como ACPI y USB en realidad
simplemente implementan las funciones de su hardware totalmente en software
para tener comunicación, funcionalidad y sincronía en los dos, así que no
es de sorprenderse y lo que tenemos que hacer es simplemente implementar
TODAS las funciones directamente crudas de PCI, ACPI, USB, etc., en software,
tanto como si de un emulador optimizado se tratara.......



Escribir código con funciones de hardware como si no tuviéramos ese hardware
a disposición.

Si ponemos ese código de "emulación" o reimplementación puramente en software
junto con el de los drivers, no solo agregaremos y entenderemos más trucos,
sino que esas funciones básicas las podremos usar como librerías genéricas para
infinidad de otras aplicaciones que ahorita ni nos imaginamos. Por ejemplo,
con un motor genérico de interpretación del CPU x86 para 16, 32 y 64 bits,
después podríamos usar sus funciones genéricas, parte del código de administración
del CPU, para el relocator (reubicador) de binarios, aunque podríamos usarlo
para muchísimas más cosas, pero basándonos en haber reimplementado el CPU como
un artefacto o librería genéricos de software, igual que como el hardware
une diferentes dispositivos para llevar a cabo la tarea de levantar la máquina,
nosotros también levantaríamos aplicaciones de software usando en gran parte
la reimplementación de software del hardware para manipular de diferentes
formas sus tareas correspondientes.






Pero si es así quiere decir que siempre sería mejor no subir innecesariamente
la abstracción y agregar siempre emuladores anidados a los programas para que
hagan uso de funciones de nivel de hardware, para nosotros siempre seguir
programando en Ensamblador Portable como si de una PC estándar se tratara,
total o parcialmente reimplementada en software según necesitemos.




Con esto poco a poco me estoy acercando a un emulador específicamente pensado
para correr de forma interpretada el programa de 16 bits SCAR hasta en Windows
de 64 bits.
perfeccionar esa forma de programar








Palabras sinónimos y conceptos relacionados pueden ayudarnos a dar con
funciones relacionadas con lo que nosotros ya hemos hecho.
Buscar y comparar lo que sabemos con el código de un programa.
Ver si entendemos los conceptos aunque sea a nivel natural.
Ver cuánto sentimos que nos resulta familiar el código de otro sistema.
Detectar lo que siente el autor, absorber su energía/esencia intelectual,
cultivarla, evaluar lo que dice, tratar de entender el flujo mental y
llevar todo a sus átomos lógicos.




No dejar de repetir el leer ese código, especialmente cuando no estemos
haciendo nada más, nada más que cosas de ocio, usarlo hasta para "spammear"
sitios con nuestro estudio, masivo, pero que al final demostrarán ser
un cultivo constructivo intelectual.

Pero hacerlo a mano, hasta hacer un grupo de videos localmente donde
se vea cómo repetimos la lectura una y otra vez, con micrófono
activado, y después volver a ver eso mientras dormimos......

Cuando estemos extremadamente aburridos, confundidos, paralizados, con un
momento de demasiada monotonía percibida, hacer precisamente esto....

Igual que cuando estamos inventando código, ver el código de otros
de forma súper colorida y gráficamente estructurada.

También buscarle el punto de inicio, tratar de buscar cómo
se mira el programa, llevar la cuenta de cómo va funcionando,
busquémosle el inicio principal, y otros inicios de
funciones incondicionales, y después extendámonos en orden
para ver cómo se ejecutaría, pero en nuestra mente........
después visualizar cómo podrían surgir ejecutándose las
diferentes funciones no secuenciales de utilería.


Un sistema de este tipo NUNCA es mayormente secuencial.

Ejecutar los casos de acuerdo a lo "inestable" y "mano alzada"
de nuestra mente esperando que el código todavía funcione...
algo entenderemos y probablemente nos acostumbremos
a mantener los detalles de forma más estable, pero hacer esto
también cuando nos estemos durmiendo o buscar la forma de
llevarnos esto hasta cuando nos estemos bañando, impreso o
en una máquina, y seguir acostumbrándonos a ejecutar código
fuente directamente en nuestra mente... tener programas
en cuestión estructurados a nivel de ejecución, corriendo
en nuestra mente, no desactivarlos nunca, como nuestro
sistema operativo y computadora principal, nosotros
mismos, para tener más claridad...... si las demás
computadoras externas para las que no tenemos una interfaz
ideal nos están sirviendo todo el tiempo, ¿por qué no
hacer eso también con la máquina más avanzada y con
interfaz más directa, que somos nosotros mismos y nuestro
cerebro, si realmente al final eso hará también que al final
todo el peso útil, las habilidades, capacidades y conocimiento
profundo de la tecnología caigan con su peso dentro de
nuestro entorno personal y mental para aprovecharlos a nivel
vital, biológico, personal, humano?



Seguir convirtiendo más a OSDev.org en un sistema operativo
directamente... empezar agregando lo que saben aunque sea como
programas externos de prueba a nuestro sistema para conectarnos
realmente a lo que originalmente trataban de enseñarnos y
así sobrepasar los mensajes de trolles......

Usar lo que nos enseñan y decirles lo que pensamos y cómo nos
resultó para que tengan referencia de cómo funciona en cierto
tipo de sistema, en este caso el nuestro.








Emular la paginación en el kernel para entender por lo menos cómo la
manejaríamos a nivel de CPU.....


Usar la técnica de entornos infinitos a cada paso a ejecutar.


Desenmarañar la lógica colectiva de OSDev, compararla con los
sistemas finales existentes, arreglarla con estos, e implementarla.


Podemos hasta gritar mentalmente, sin involucrar los músculos,
para darle más intensidad a nuestro estudio de cosas complejas.
Así, una vez que encontremos, minuciosamente siguiendo cada
partícula del código, trucos, podremos concentrarnos en
terminar de entenderlos y documentarlos.








Tomarnos suficiente tiempo para entender cada línea, tanto como para
que se nos empiecen a ocurrir cosas y hasta que ya no se nos ocurran,
y entendamos qué afectar, hacer y mantener con cada línea.

Aprovechar la capacidad de súper scripting del cerebro para entender
lo que está pasando muchas veces para la mayoría del código sin
necesidad de saber la dirección física de algo.

La "dirección física" es un mismo concepto, necesidad,
tarea, contexto o lógica, donde se acumulará el entendimiento
y los resultados formalmente calculados de una tarea, no tanto
así una dirección binaria de memoria, aunque sabemos que al
final el programa siempre llega precisamente a eso, solo
tenemos que verlo con naturalidad y flexibilidad.


Es una carrera de estudio de locos, pero si nos detenemos
para que florezca y gane vitalidad cada línea de código,
poco a poco, realmente vamos a terminar entendiendo.


Solo ver el nombre de todo, archivos, funciones, etc.,
eso nos va a decir de que se trata y con solo ver ya
lo sabremos, solo tenemos que evaluar cuánto en nuestra
creatividad se nos ocurre hacer eso mismo sin ver,
y después viendo.

En vez de memoria, aquí tenemos creatividad, habilidades,
información, velocidad, experiencia y energía mental
y física para poder procesar un concepto.


HASTA PARA PENSAR EN CÓMO HARÍAMOS ALGO SIN VER, TENEMOS
QUE PENSAR EN SERIO UN RATO CÓMO HACERLO, ANOTAR IDEAS,
EXPANDIR LO QUE YA HEMOS HECHO, Y DESPUÉS VER CÓMO
ESTÁ HECHO EN EL LIBRO, CÓDIGO O RECURSO EXTERNO,
Y POCO A POCO COMPARAR Y VOLVER A MEDITAR CADA
PASO ADICIONAL... ASÍ ENTENDEREMOS Y PENSAREMOS
DE FORMA CADA VEZ MÁS CERCANA CON DISTANCIA
CONOCIDA MEDIDA ENTRE NUESTRO NIVEL Y ESTILO Y EL
DE OTROS, AUNQUE NO SEPAMOS NADA... SI ES ASÍ
ENTONCES NO SABER NADA ES NUESTRA DISTANCIA ENTRE
LO QUE OTRO HIZO.










EOF
Imagen
IP for hosts file (email udocproject@yahoo.com to get updates if website becomes offline):
Código: Seleccionar todo
190.150.9.244 archefire.org



See what I'm doing in real time:
Main Desktop 1
Main Desktop 2
Avatar de Usuario
~
Site Admin
 
Mensajes: 2958
Registrado: Sab Nov 10, 2012 1:04 pm

BOOTCFG - New Commands Added

Notapor ~ » Sab Jul 22, 2017 2:14 pm



Download the current source code:
Image BOOTCFG__v2017-06-16.zip

I have added new commands to the kernel console, and of course it shows
how to do those tricks so that others who need it can add those tricks
to their systems.

off -- This command
is intended to fully turn off as many things as we can
before manually turning off the computer.
It's intended to contain more and more cases
until we learn how to turn off the computer
by software. With this, the machine will need to be
fully turned off to use it again. So far I've seen
that the hard disks will stay turned off even when
pressing the reset button, which is good if what
we want is to turn off the machine and save power.

It will try to turn off the 4 default ATA hard disks,
will turn off the keyboard LEDs, will make the PIT
work as slow as possible, will make the screen go
black and in the best cases turn off its light using
standard VGA registers, and will finally halt the CPU
for being able to turn off the system mostly to avoid
the hard disks to suffer when suddenly cutting off power.

clk -- All times
specified in the kernel are now µs microseconds.
A debug command that will try to wait for 1 minute
before clearing the screen and re-printing the kernel
identification message. With this we can test how
accurate is our PIT waiting code. I currently can wait
58 effective seconds in a 2GHz machine and around 50
effective seconds in a 550MHz machine. It seems to vary,
it's notorious when at lest 60 seconds are waited.

The best I've achieved so far is using a PIT divisor of
1193180/298295 or around 4 microseconds per tick, and I
still don't know if it works in my 386DX. If not, I will
probably have to slow it down when working there.

disktest0/diskreadtest28 -- Another debug command
intended to read 28-bit LBA-compliant sector 0 from the
Primary Master ATA hard disk, so it shows how to read
sectors using PIO mode (reading through I/O ports),
so with that we can start studying partitions to finally
add, read, write files and directories, delete, create,
extend, shrink, read full and partial clusters...


Image I have added
an icon to the kernel file to start testing how to add
a graphic to my raw binaries that can be seen
immediately in any file explorer.

Now I boot kernel.ico
instead of kernel.bin. This icon of a cob-like fruit with the
grains inside is appropriate for my kernel and similar
enough to my previous icon of a flame from
NES Zelda 1.

I have added:

- Several data files for changing standard VGA
  modes (soon to be used).

- Code to drive the PC speaker (set frequency,
  read current frequency, turn on, turn off).

EOF
Imagen
IP for hosts file (email udocproject@yahoo.com to get updates if website becomes offline):
Código: Seleccionar todo
190.150.9.244 archefire.org



See what I'm doing in real time:
Main Desktop 1
Main Desktop 2
Avatar de Usuario
~
Site Admin
 
Mensajes: 2958
Registrado: Sab Nov 10, 2012 1:04 pm


Volver a BOOTCFG

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado


cron