Foro de elhacker.net

Programación => ASM => Mensaje iniciado por: lweb20 en 4 Marzo 2013, 01:43 am



Título: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 01:43 am
Hola que tal jeje. Soy yo de nuevo, me pareció muy creativo el título.

Llevo ya varios meses con el desarrollo de un sistema operativo en 32-bits en modo protegido (obviamente) y quisiera aquí tratar todos los problemas y pequeños detalles (trataré) sobre el modo protegido.

Este post va a ser un poco informativo pero va a haber más preguntas que respuestas. Quiero aclarar que no soy un experto pero no puedo negar que se aprende muchas cosas en el transcurso del camino. No quiero caer mal ni mucho menos quiero ofender a alguien.

¿Por qué elegí 32-bits?
- Porque 16-bits es muy limitado y vulnerable a ataques de aplicaciones al hardware (modo real)
- Porque la mayoría de lenguajes de alto nivel (que son los más fáciles de programar a mi parecer) usan 32-bits. Aclaro que gcc existe una forma de usar 16-bits

Características principales del modo protegido de 32-bits
- No interrupciones de la BIOS (que miedo :S)
- Puedes crear tus propias interrupciones
- Prácticamente 2 niveles de acceso (sistema* y usuario - ring0 y ring3)
- Entre otros que poco a poco voy a ir comentando

Lo interesante del modo protegido
- Crear drivers (controladores)
- Entrar y salir del modo usuario
- Multitarea
- Acceso directo a la memoria (modo sistema*)
- Posibilidad de usar out para enviar comandos a dispositivos (*)
- Manejo avanzado de energía (APM, ACPI)
- Ejecutar aplicaciones de distintas unidades de almacenamiento
- Crear uno mismo sistemas de archivos (hechos y propios)
- Modo virtual

Mis dudas ;D
Aquí si pido ayuda si alguien tiene alguna idea de lo que hablo. Disculpen si son muchas pero llevo tiempo con estas dudas y he tenido más que he ido solucionando poco a poco.

- Entrar al modo virtual y salir (ejecutar alguna interrupción de la BIOS)
- Salir del modo usuario (ya sé entrar :D)
- Ejecutar programas PE (los básicos, buscar el main y ejecutarlo)
- Necesito un manual de hardware del modo protegido. Sobre todo usando el in y el out.


Gracias por leer y disculpen la molestia. Sé que no es su obligación contestar y si podría poner puntos lo haría :)



Nunca edito mis mensajes

* creo


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 01:57 am
http://en.wikipedia.org/wiki/Protected_mode
http://wiki.osdev.org/Protected_Mode
http://www.rcollins.org/articles/pmbasics/tspec_a1_doc.html

http://wiki.osdev.org/Virtual_8086_Mode

Para salir de modo Usuario (o entrar a modo Kernel) podes usar o una interrupcion o alguna de las instrucciones de llamada rapida como sysenter/syscall.

Para ejecutar un PE verdadero tenes que implementar como minimo la NTDLL.dll y para cualquier cosa normal Kernel32.dll y otras. Tendrias que hacer un Loader como el de Windows que cargue las secciones en donde corresponda, que resuelva las funciones importadas ... y mil cosas mas realmente.

http://wiki.osdev.org/Main_Page


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 02:13 am
no no yo me refiero un PE simple a esto por ejemplo:

int main(){
   char* stringToPrint = "hola";
   _asm{
      xor eax, eax
      mov ebx,[stringToPrint]
      int 0x80
   }
   return 0;
}

es decir ninguna librería de windows.

Citar
Para salir de modo Usuario (o entrar a modo Kernel) podes usar o una interrupcion o alguna de las instrucciones de llamada rapida como sysenter/syscall.

- ¿Ejecutar una interrupción? no te entiendo, disculpa. Se puede ejecutar una interrupción en modo usuario pero la pregunta es cómo salir del modo usuario.
- sysenter/syscall háblame un poco más de eso.

Lo que quiero hacer es ejecutar un programa (monotarea) en modo usuario y luego retornar a modo kernel. ¿Se podrá?


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 02:51 am
Por experiencia puedo decir que este es un punto de entrada muy inadecuado para tratar de implementar un sistema operativo.

Por este camino, uno podría tardarse años literalmente (más de 5) para apenas comenzar a crear un sistema operativo.

Lo más que se podría lograr es crear uno simple.

Pero el peligro es desilusionarse después de varias iteraciones de reescribir todo desde cero, y todos estos consejos que doy son para evitar eso. Por supuesto yo no me he desanimado porque realmente quiero aprender las cosas más avanzadas.

También estoy en el foro de OSDev.org (http://forum.osdev.org/search.php?author_id=2984&sr=posts) y OSDever.net (http://forums.osdever.net/search.php?author_id=217&sr=posts), y he llegado a aprender que por más ayuda que uno reciba ahí, necesitará otras fuentes con información más abundante y a un nivel más manejable (además de que lastimosamente la Wiki parece haber sido escrita originalmente por gente con una actitud de que todo es difícil en extremo, pero sin intentar dar realmente suficiente código o pistas para solucionarlo en la práctica).

De esa forma es como yo creé un sistema operativo extremadamente simple de 32 bits, tal vez el sistema de 32 bits didáctico pero útil más entendible que se podría encontrar. Le di el nombre de LowEST Kernel.

Discusiones del Proyecto de LowEST Kernel, Nivel 1 (32 bits) (http://devel.cable-modem.org/forum/viewtopic.php?t=496)

(http://devel.cable-modem.org/img/favicons/www.winzip.com.ico) Código Fuente del Kernel de LowEST, Nivel 1 (32 bits) (http://devel.cable-modem.org/en/projects/x86/OS/LowEST_Kern/LowEST_Kern_2012-07-03.zip)





Realmente he tenido mucha diversión experimentando controlar y detectar discos IDE y ATAPI, y SATA, controlar floppies, el teclado, el speaker, la VGA estándar, etc.

Yo aprendí Ensamblador en 6 meses con el libro de Charte Ojeda, y después de eso aprendí a usar las interrupciones de modo protegido en 1 semana. Después otra semana para comenzar a manejar el teclado, y muchos meses más para manejar el CD-ROM (pero sin leerlo), y en muchos años más para aprender sobre muchas otras cosas, aunque son tantas que en su mayoría solo a nivel superficial.

Lo que mi kernel puede hacer formalmente (y que puedo ayudar a explicar con mayor simplicidad que otras fuentes) es:

  • Bootear desde un floppy con FAT16.
  • Driver del teclado que reconoce Ctr+Alt+Del y Shift.
  • Consola de texto tipo MS-DOS, con soporte para agregarle comandos internos.
  • El kernel puede correr programas del floppy leyendo el directorio raíz del FAT12 y usar funciones importadas del kernel, lo que lo hace ideal para extender pruebas adicionales de bajo nivel en tiempo de ejecución.
Estoy seguro de que puedo ayudar, siempre y cuando se trate de preguntas y un estudio suficientemente extendido, en lugar del típico enfoque de los principiantes de "¿Cómo hago X cosa?" pero sin realmente darse a entender de forma más completa, en el resto de aspectos, casi como en un tutorial formal.

De lo contrario, a menos que uno tenga conocimiento y acceso excepcional a información enriquecida, cualquier otro enfoque puede tardarse años, si es que el aspirante no se rinde antes de tantos años.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 03:15 am
Gracias por eso, no me lo esperaba (en serio), lo revisaré en el transcurso del mes.

Bueno, seguía con mi pregunta actual:

Si no es posible salir del modo usuario (que por simple lógica mía es cierto) se usan las interrupciones del IVT (¿cierto?) pero no creo que se puedan ejecutar operaciones administrativas y para ello supongo que la instrucción sysenter/syscall lo soluciona pero cómo hago aquello ya que todo lo que he encontrado es sobre linux.

En cuanto a "~" no espero crear un gran SO de golpe. Ese es mi lema o algo así. Si quieres algo grande debes ir de lo más minúsculo e ir creciendo POCO A POCO hasta lograr aunque sea tus objetivos (y lo digo así porque en el camino se descubren cosas nuevas). Uno no puede hacer todo solo pero sí aunque sea el inicio.

Mi kernel está hecho en C++ (casi todo es C) y muy poco asm. Sé que el asm es más rápido porque usa registros del CPU y no variables (mayormente) pero C++ es mucho más fácil de comprender ya que tiene una mejor organización (para mi).


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 04:09 am
Tal vez sería mejor desarrollar el tutorial de JamesM (James Molloy) para tener una base más sólida de conocimiento. Sé que lo voy a estudiar debido a preguntas como esta.

Especialmente la sección de llamadas de sistema:

10. User Mode (http://www.jamesmolloy.co.uk/tutorial_html/10.-User%20Mode.html)

Aquí una porción de información importante:

Citar
Llamadas de Sistema

El código que corre en modo usuario no puede correr código que está en, o accede, un área solo de supervisor (mira las banderas de entrada de tabla de páginas) ni ningún código que se instrucciones privilegiadas tales como HLT. Por lo tanto, la mayoría de kernels proporcionan una interfaz por la cual funciones comunes pueden ejecutarse. Una llamada del kernel a través de esta interfaz es llamada "llamada de sistema" o "system call".

La manera histórica, simple, y aún usada ampliamente para implementar llamadas de sistema en x86 es usar interrupciones de software. El programa de usuario establecerá un registro para indicar qué función de sistema desearía ejecutar, luego establecer parámetros en otros registros. Entonces ejecutaría una interrupción de software a un vector específico - Linux usa 0x80. La interrupción de software causa un cambio de modo al ring 0 - el kernel tendrá un manejador para este vector de interrupción, y despachará la llamada de sistema apropiadamente.

Algo importante a notar es que el kernel, cuando ejecuta código de manejo de interrupciones, requiere una pila válida con la cual trabajar. Si no tiene una, el procesador generará un double fault (y eventualmente un triple fault porque el manejador de double fault también necesita una pila válida). Esta sería obviamente una manera muy fácil por la que un usuario malintencionado podría bloquear tu sistema, así que es práctica normal cambiar a una nueva pila, en el momento de cambio demodo de ring 3 a ring 0, diseñada solamente para ser usada por el kernel, y que se garantiza que es válida.

Obviamente si deseas que tu kernel sea multitareas/preemptible (es decir, si deseas ser capaz de cambiar de tareas mientras ejecutas código dentro del kernel), necesitarás una de estas pilas de kernel por tarea, o terminarás sobreescribiendo los datos de una tarea cuando ejecutes otra tarea.


Es natural que casi solo haya material sobre Windows y Linux, no para un kernel personalizado, así que hay que partir de esa información y de los manuales de Intel.

Pero sí es algo bastante difícil de lograr, especialmente si no se tiene más base de código que la de unos pocos meses (y casi imposible de lograr de forma sostenible con dudas de información incluso de cómo programar los puertos de Entrada/Salida).

Los manuales de Intel son todo lo que se necesita para entender de manera detallada esas cosas. Y después vienen muchos tutoriales y otros estándares:

Manuales de Intel (comenzar por 25366617_2A.pdf, 25366717_2B.pdf y 25366517_1.pdf) (http://devel.cable-modem.org/standards/cpu_arch/x86_ia32/manuals/2005-06/)

___________________
___________________
Y sobre terminar de golpe un sistema operativo, no se trata de eso, pero la actitud de tener que avanzar "poco a poco" es inadecuada (la actitud de "si es algo difícil debe tardarse tanto como sea posible" en lugar de "las cosas más difíciles deben buscarse por los medios más abundantes y comenzar a implementarse por lo que se necesita de forma más inmediata, más que hundirse en un mar de teoría que no es inmediatamente aplicable").

Es mejor decidirse a avanzar con mayor rapidez y en cosas inmediatamente aplicables tanto en sistemas operativos y en la programación normal, y recibir ayuda de otros (además de dar cualquier ayuda que se pueda a otros como colectivo), y hacer un esfuerzo concreto en el presente, pero inteligente y reusable, en lugar de pasar años en los fundamentos, en lugar de usar ese tiempo en lograr implementar algo usable que permita avanzar de forma mucho más eficiente. Algo difícil en extremo de lograr para la mayoría de principiantes.

Esto es lo que puedo decir de muchos años de estar en el esfuerzo de tratar de aprender sobre el desarrollo de sistemas operativos.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 10:23 am
no no yo me refiero un PE simple a esto por ejemplo:

int main(){
   char* stringToPrint = "hola";
   _asm{
      xor eax, eax
      mov ebx,[stringToPrint]
      int 0x80
   }
   return 0;
}
es decir ninguna librería de windows.

Es que eso solo en algunas versiones de Windows ni es un PE valido (al no importar ninguna funcion de ninguna DLL). Ademas es puro inline assembly ... pero bueno.


- ¿Ejecutar una interrupción? no te entiendo, disculpa. Se puede ejecutar una interrupción en modo usuario pero la pregunta es cómo salir del modo usuario.
- sysenter/syscall háblame un poco más de eso.

Si, ya te confirmaron lo que te decia, los SOs modernos en modo Protegido pasan al Kernel desde los programas (modo Usuario) con una interrupcion (Linux 0x80, Windows 0x2E) o con instrucciones de llamada especificas (estas son mas modernas asi que antes se usaba siempre una interrupcion). Aca tenes un poco al respecto orientado a Windows:

http://www.codemachine.com/article_syscall.html

Lo que quiero hacer es ejecutar un programa (monotarea) en modo usuario y luego retornar a modo kernel. ¿Se podrá?

Si, seguro, incluso de la misma forma, asi es se termina un programa sin ir mas lejos ExitProcess termina haciendo una llamada al sistema y se supone que en Linux esta la sys_exit para eso mismo (en este SO no tengo mucha experiencia).


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 14:01 pm
Es que eso solo en algunas versiones de Windows ni es un PE valido (al no importar ninguna funcion de ninguna DLL). Ademas es puro inline assembly ... pero bueno.

La idea de ejecutar el formato PE no es cargar sus librerías en la memoria y hacerlo todo como Windows (por decirlo así), más bien es crear un programa en Visual Studio y poder ejecutarlo desde mi sistema operativo; ya que me parece mucho más sencillo el asm inline de Visual Studio que el de gcc (y además es mi IDE favorito).

En cuanto a lo del syscall ya entendí. Déjenme solucionar algunos problemas con mi so. He detectado varios al desactivar la optimización: problemas con el stack, etc..

Ahora la última pregunta hasta que regrese de solucionar estos problemillas: ¿es posible ejecutar una interrupción que ejecute operaciones administrativas del IVT desde el modo usuario (RING3)? Tengo claro que sí es posible ejecutar una interrupción desde el modo usuario, lo que no tengo muy claro es por ejemplo si mediante esa interrupción puedo por ejemplo cargar una nueva GDT, o reiniciar el sistema (administración del sistema, por decirlo así). Ahora esto lo puedo detectar cuando solucione problemas que tengo al entrar al modo usuario, que extrañamente ya no me funciona (se queda colgado o sino error de protección general). Hasta pronto.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 14:38 pm
La idea de ejecutar el formato PE no es cargar sus librerías en la memoria y hacerlo todo como Windows (por decirlo así), más bien es crear un programa en Visual Studio y poder ejecutarlo desde mi sistema operativo; ya que me parece mucho más sencillo el asm inline de Visual Studio que el de gcc (y además es mi IDE favorito).

Podes usar MASM directamente en ese caso, lees un par de estructuras y encontras el Entry Point del ejecutable.

Ahora la última pregunta hasta que regrese de solucionar estos problemillas: ¿es posible ejecutar una interrupción que ejecute operaciones administrativas del IVT desde el modo usuario (RING3)? Tengo claro que sí es posible ejecutar una interrupción desde el modo usuario, lo que no tengo muy claro es por ejemplo si mediante esa interrupción puedo por ejemplo cargar una nueva GDT, o reiniciar el sistema (administración del sistema, por decirlo así). Ahora esto lo puedo detectar cuando solucione problemas que tengo al entrar al modo usuario, que extrañamente ya no me funciona (se queda colgado o sino error de protección general). Hasta pronto.

Si, lo que haces es PASAR a modo Kernel: el manejador de la interrupcion.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 15:19 pm
Yo quiero ayudar de forma práctica y real, así que pido por favor poner todas las referencias y URLs que han servido para implementar ese kernel.

  • ¿Dónde está la información que se usó para crear el kernel básico?
  • ¿Dónde está la información que se usó para pasar a modo de usuario?
  • ¿Dónde está la información que se usó para correr aplicaciones?
  • ¿Qué otra información se usó?

Con esto se puede garantizar ayudar de forma excepcionalmente más fácil, y compartir conocimiento a nivel de implementación, más allá de la teoría cruda.

Yo también pongo unas referencias en este momento, sobre lo que me sirvió para lograr crear programas PE 100% en ensamblador, sin ayuda de ninguna otra librería ni herramienta.

TinyPE (vital) (http://www.phreedom.org/research/tinype/)
Todos los artículos de Matt Pietrek sobre PE (http://www.google.com/search?q=Matt%20Pietrek%20PE)
Las especificaciones PE/COFF (http://www.google.com/search?q=PE%20COFF%20specification)

Gracias a esto puedo crear archivos ejecutables de Windows, desde Windows, DOS o Linux, o cualquier otro sistema que tenga NASM, y sin tantas herramientas.





La idea de ejecutar el formato PE no es cargar sus librerías en la memoria y hacerlo todo como Windows (por decirlo así), más bien es crear un programa en Visual Studio y poder ejecutarlo desde mi sistema operativo; ya que me parece mucho más sencillo el asm inline de Visual Studio que el de gcc (y además es mi IDE favorito).
¿Para qué usar Visual Studio solo para crear un Portable Executable? Es posible que le agregue mucha basura. Yo prefiero crear los PE directamente con ensamblador, 100% sin linkers ni compiladores.

Aquí tengo una muestra de lo que estoy hablando:

(http://devel.cable-modem.org/win32/asm/cuentareloj.ico) cuentareloj.asm (http://devel.cable-modem.org/win32/asm/cuentareloj.asm)

Este programa lo ensamblamos así:

nasm cuentareloj.asm -o cuentareloj.exe
(http://devel.cable-modem.org/win32/asm/cuentareloj.png)

Este incluso se genera automáticamente conteniendo el icono mostrado antes, sin usar linkers ni GCC ni muchísimo menos Visual Studio, y contiene todo lo que seguramente se necestaría para lo que se quiere lograr aquí.


Esto no quiere decir que no pueda usar GCC y NASM, y evitar también el ensamblador inline de GCC. Después de todo es lo más conveniente (comenzar creando programas desde cero por uno mismo) porque de todas maneras uno va a tener que crear un loader capaz de entender el formato.

Otros también recomendarían más darle soporte a los ejecutables ELF, y también sería una buena idea, dado que muchos programas open source y librerías probablemente corran mejor (sin bugs extraños) si simplemente se compilan a ELF.


En cuanto a lo del syscall ya entendí. Déjenme solucionar algunos problemas con mi so. He detectado varios al desactivar la optimización: problemas con el stack, etc..

Ahora la última pregunta hasta que regrese de solucionar estos problemillas: ¿es posible ejecutar una interrupción que ejecute operaciones administrativas del IVT desde el modo usuario (RING3)? Tengo claro que sí es posible ejecutar una interrupción desde el modo usuario, lo que no tengo muy claro es por ejemplo si mediante esa interrupción puedo por ejemplo cargar una nueva GDT, o reiniciar el sistema (administración del sistema, por decirlo así). Ahora esto lo puedo detectar cuando solucione problemas que tengo al entrar al modo usuario, que extrañamente ya no me funciona (se queda colgado o sino error de protección general). Hasta pronto.
Claro que es posible, como se explicaba en el tutorial de JamesM y en muchas otras referencias.

Pero es seguro que esos problemas no sean tan pequeños como parecen.

El problema es que entrar en modo usuario y en multitareas puede ser educativo, pero si estamos en la misma situación en la que yo estuve, sería un error, sería contraproducente pasar tan rápido a modo usuario sin tener un sistema sólido sobre el cual trabajar.

Esto hará mucho más difícil, casi imposible, aprender a usar paginación e implementar permisos apropiadamente, o administrar el hardware, o usar algoritmos ya avanzados sobre administración de memoria.

Es mejor seguir en modo kernel, y documentar todo el diseño y trucos de hardware, y seguir aprendiendo. Esto es lo que yo he estado haciendo, y sé que de esta forma no puedo perder el tiempo reescribiendo todo cuando se vuelva un desastre.

En este momento, es más útil implementar las capas de bajo nivel, no sirve de nada para llevar a cabo ese tipo de programación, y dejar el modo de usuario hasta el final (puede ser más difícil y ligeramente educativo, pero puede ser un enorme estorbo para consolidar un kernel).


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 15:39 pm
Todo el kernel está muy estable (obviamente el manual me ayudó un montón). Muchas cosas no las entendía pero poco a poco mientras modificaba el kernel tuve que leer un poco más para pasarlo a español las funciones y tratar de implementar el lenguaje C++ (orientado a objetos). Y discúlpenme pero creo que está mal ubicado el tema en asm (yo lo puse en C). Uso el IDE de Visual Studio porque acostumbro a crear múltiples algoritmos en un solo programa y así tener una gran librería ordenada. Para mi es bueno asm (ya que es ensamblador y no compilador, nasm y masm sí los comprendo muy bien). Comprendo lo de no usar tantas herramientas, pero mi entorno preferido, como dije, es y será siendo Visual Studio (>2010) ya que con él aprendí a programar. Y respecto a las referencias pues son las que todo el mundo usa. Osdev, Osdever, Wikipedia, Wikibooks, El tutorial de JamesM, entre otros. Existe otra que como veo no muchos la conocen y como veo que mucho insisten (no lo tomen a mal) no veo por qué no mostrarlo (Brokenthorn). Bueno ya lo dije, ejem.

¿Qué es lo que pretendo realmente hacer con el formato PE?
- Estudiarlo poco a poco para más adelante crear mi propio formato más liviano. Por qué digo más liviano: Porque para mi ese formato ocupa demasiado espacio en el disco y de esta forma el sistema operativo, aparte del tiempo que demora en buscar el archivo en la unidad de almacenamiento, demora en leer el archivo (ya que probablemente esté dividido en varios fragmentos) y cargarlo en la memoria.

- Crear una librería para mi sistema operativo y así crear aplicaciones en base a mi sistema operativo y de esta forma facilitar el llamado a syscall. Por ejemplo para leer un archivo usaría una sintaxis muy simple y en español.

Código:
Archivo archivo = SysAbrirArchivo("C:\\archivo.txt");
char* buffer = malloc(Archivo->Tamaño);
SysEstablecerPosiciónArchivo(archivo, 0); // es como un seek
SysLeerArchivo(archivo, buffer, Archivo->Tamaño);
SysCerrarArchivo(archivo);

Algo súper simple y entendible.

Todo esto lo digo porque tuve la oportunidad de leer un sistema operativo hecho en ASM con librería en C de 64 bits (que seguramente muchos saben de cuál se trata) que tenía syscalls e hice algunos programas en base a ese sistema (nasm y gcc).


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 15:46 pm
Y discúlpenme pero creo que está mal ubicado el tema en asm (yo lo puse en C).

Ahi estaria peor ubicado cuando es necesario para la mitad de lo que mostras inline assembly  ;) Aca no tenemos un sub-foro para desarrollo de Kernel/SOs, tal vez debas buscar un foro especifico, pero todos los temas tratados estan mas cercanos a ensamblador que a C++.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 15:54 pm
Ahi estaria peor ubicado cuando es necesario para la mitad de lo que mostras inline assembly  ;)

... todos los temas tratados estan mas cercanos a ensamblador que a C++.

Eso es cierto.

... tal vez debas buscar un foro especifico

¿Cómo así?

Aca no tenemos un sub-foro para desarrollo de Kernel/SOs,

Debería haber :D

Ahh y una pregunta. Estoy depurando con Bochs y quiero que mediante el código hacer un punto de interrupción ¿se podrá? (disculpen la ignorancia xD) Por ejemplo ejecutando int 0x3? o int 0x1?


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 16:10 pm
¿Cómo así?

Uno como OSDev, especifico del tema.

Debería haber :D

No realmente, los sub-foros se crean de acuerdo a la demanda, de esto sobran los dedos de las manos para contar a los realmente interesados  ::)

Ahh y una pregunta. Estoy depurando con Bochs y quiero que mediante el código hacer un punto de interrupción ¿se podrá? (disculpen la ignorancia xD) Por ejemplo ejecutando int 0x3? o int 0x1?

http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 16:11 pm
Desgracia: (xD)

(http://img855.imageshack.us/img855/3168/capturavze.png)

Se pasó hasta abajo del código. Quería un breakpoint ahí.

voy a ver el enlace que me dejaste.

EDIT:

El problema es que quiero parar en una línea específica mas no en una parte de la memoria. La verdad que nunca pude hacer eso, ¿alguna idea? usé el trace y show pero muuuucho "trace" de lo que espero. Como hay varios controladores aparece un trace gigantesco (se cuelga y no continúa) y no logro captar el código que realmente quiero ver.

El Bochs debería tener un puerto (out) para hacer debug :P


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 16:34 pm
Busca la direccion de la instruccion especifica y listo ... fijate si podes generar simbolos de depuracion (ahi en el enlace que te deje lo mencionan), asi se te simplificaria bastante el asunto ...


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 16:41 pm
Gracias :D ya tengo la dirección. Todos se equivocan :) (yo)

Qué bonita dirección xD: 0xC0004330

Ups problema, creo que me equivoqué. La dirección que necesito es la dirección antes de ejecutar ese código verdad? yo la obtuve de la función a ejecutar. ¿Cómo obtengo la dirección de la posición actual? ni idea :S

Por sea caso: cuando pregunto algo siempre voy buscando y viendo la forma de solucionarlo, no me quedo estático esperando la respuesta.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 16:53 pm
Registro EIP = EXTENDED INSTRUCTION POINTER.

No se que usas para compilar el Kernel pero en VC++ podes generar listings con archivos .asm y .map (/FAcs, /map o cosas por el estilo) por ejemplo, ahi verias las direcciones facilmente.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 16:56 pm
Editado por un detalle práctico que olvidé: Para modo de 64 bits, para poder ejecutar interrupciones como las de video, no hay más opción que implementar o usar un emulador como x86emu (referenciado ampliamente en la Wiki y el foro de OSDev):

x86emu.zip (http://devel.cable-modem.org/en/tmp/x86emu.zip)

Por esto aconsejo ir rápido, pero también escuchar lo que otros tenemos que decir en lo que hemos intentado antes. En otras palabras, es mejor olvidarse en mayor medida del modo v86 virtual del modo de 32 bits y usar emulación de software, si uno no tiene drivers de video y aun así quiere poder cambiar modos de video.





Todo el kernel está muy estable (obviamente el manual me ayudó un montón). Muchas cosas no las entendía pero poco a poco mientras modificaba el kernel tuve que leer un poco más para pasarlo a español las funciones y tratar de implementar el lenguaje C++ (orientado a objetos). Y discúlpenme pero creo que está mal ubicado el tema en asm (yo lo puse en C). Uso el IDE de Visual Studio porque acostumbro a crear múltiples algoritmos en un solo programa y así tener una gran librería ordenada. Para mi es bueno asm (ya que es ensamblador y no compilador, nasm y masm sí los comprendo muy bien). Comprendo lo de no usar tantas herramientas, pero mi entorno preferido, como dije, es y será siendo Visual Studio (>2010) ya que con él aprendí a programar. Y respecto a las referencias pues son las que todo el mundo usa. Osdev, Osdever, Wikipedia, Wikibooks, El tutorial de JamesM, entre otros. Existe otra que como veo no muchos la conocen y como veo que mucho insisten (no lo tomen a mal) no veo por qué no mostrarlo (Brokenthorn). Bueno ya lo dije, ejem.
BokenThorn también es una referencia común que todos conocemos, y es muy similar a la de JamesM.

Sobre Visual Studio, al fin de cuentas sería irrelevante en un nuevo sistema operativo, y sería necesario aprender otras herramientas, incluso propias. De lo contrario uno sería demasiado dependiente, el sistema sería débil también en ese aspecto, y de todas maneras Visual Studio o cualquier herramienta son lo de menos cuando uno escribe un sistema operativo, tratando de entender todos los formatos, convenciones y estándares por uno mismo.

Es mejor dejar de depender de estas herramientas en este ámbito. Yo también empecé programando en Visual Basic 6, pero ahora no pienso sino en que si uso esos lenguajes, sea yo quien los implemente, o mi esfuerzo quedaría atrapado esclavo a esas herramientas y lenguajes, en lugar de estar totalmente a mi cargo y ser libre.

¿Qué es lo que pretendo realmente hacer con el formato PE?
- Estudiarlo poco a poco para más adelante crear mi propio formato más liviano. Por qué digo más liviano: Porque para mi ese formato ocupa demasiado espacio en el disco y de esta forma el sistema operativo, aparte del tiempo que demora en buscar el archivo en la unidad de almacenamiento, demora en leer el archivo (ya que probablemente esté dividido en varios fragmentos) y cargarlo en la memoria.
Yo no recomendaría crear un formato propio de ejecutable. Incluso gente mucho más experta evita hacer esto, simplemente porque esto representa una desconexión total con el resto del mundo informático.

Una vez tras otra he comprobado que solo porque crear algo como un formato me resulte aparentemente más fácil que entender otro que alguien más hizo, y que todo el mundo usa, no significa que diseñarlo sea conveniente, comenzando porque será mucho menos robusto y nadie más lo va a usar (en otras palabras, un punto de muerte para un proyecto).

Pero tal vez sirva este formato de ejecutable que he creado para mi kernel. Este es capaz de importar funciones del kernel. Hasta ahora no necesito modo de usuario ni multitareas porque estoy aprendiendo hasta los detalles más intrincados del hardware, y para asegurarme de que mi entendimiento en eso no tenga fallas, estoy creando un emulador de PC.


Este es el programa de muestra, y se puede definir perfectamente en C++ o en C, etc:
Código:
;v2012-06-29
;
;This is a version of CMDARGS2 that uses only imported functions
;from the kernel, and a new, slightly expanded header, to make possible
;for the kernel to link functions/variables imported by the application,
;for itself, instead of having the application do that.
;;


APPBASE equ 1048576*2

bits 32
org APPBASE



%include "include/external_exported_variables.inc"
%include "include/external_exported_functions.inc"



;Our kernel must read this address, jump
;to it and then skip it:
;;
 IntendedBaseAddress  dq APPBASE
 NumberOfFieldsBelow  dq 7
 CommandLinePtr       dq 0
 CommandLineLength    dq 0
 CommandLineParamsPtr dq 0
 KernelFnExportsTable dq 0
 KernelVrExportsTable dq 0
 AppFnImportsTable    dq myImportsFunctionsTable
 AppVrImportsTable    dq 0



;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++





;Clean the screen:
;;
 call dword[clrscr]





;;;INIT: Print each command line parameter in a separate line
;;;INIT: Print each command line parameter in a separate line
;;;INIT: Print each command line parameter in a separate line
;;;INIT: Print each command line parameter in a separate line





;Prepare to show the command line, one parameter a line.
;See if the length of the application's command line can possibly
;contain parameters. If it is 11 bytes or less, it cannot contain
;parameters as of our current kernel:
;;
 mov eax,[CommandLineLength]
 cmp dword[eax],11
 jbe .noparams



;Get rid of the application's raw FAT file name,
;as of our current kernel:
;;
 mov esi,[CommandLinePtr]
 call dword[adjustCommandLineFATname]

;If we detected that there are no parameters after
;stripping the file name, end:
;;
 cmp eax,0
  je .noparams






;Print the received command line:
;;
 ;      ESI == ASCIIZ string to print
 ;
 ;;
  ;Also get rid of the application's command line in our
  ;command line pointer:
  ;;
   mov esi,eax
   mov [CommandLinePtr],esi
   call dword[console_kprint_visible]


;Go to a new line:
;;
 call dword[console_doCRLFeffect]




;Get the number of parameters in the command line. At this
;point there cannot possibly be an parameter-less command line:
;;
 ;Inputs:
 ;      ESI == ASCIIZ string
 ;
 ;Outputs:
 ;      EAX == Number of present parameters in the command line,
 ;             each other separated with blank spaces.
 ;;
  mov esi,[CommandLinePtr]
   call dword[getCommandLineArgsCount]
    mov ebx,eax
    xor ecx,ecx


;Set our destination pointer to copy the specified
;parameters one by one:
;;
 mov edi,cmdstrbuff





;Do a loop to print all of the command line parameters
;individually:
;;
 .parloop:



 ;Copy the current argument:
 ;;
  ;Inputs:
  ;       ESI == Command line string
  ;       EDI == String buffer to copy the argument to
  ;       ECX == Argument number (from 0)
  ;
  ;
  ;Outputs:
  ;       EAX == Nonzero if the argument was found, or 0 if the argument was not found
  ;
  ;;
     call dword[copyCommandLineArg]



 ;Print the argument we just copied:
 ;;
  ;Print the received command line:
  ;;
   ;      ESI == ASCIIZ string to print
   ;
   ;;
    xchg esi,edi
     call dword[console_kprint_visible]
     call dword[console_doCRLFeffect]
    xchg esi,edi



 ;Go to the next parameter. If it is still
 ;below the natural parameter count, keep
 ;looping:
 ;;
  inc ecx
  cmp ecx,ebx
  jb .parloop






;;;END:  Print each command line parameter in a separate line
;;;END:  Print each command line parameter in a separate line
;;;END:  Print each command line parameter in a separate line
;;;END:  Print each command line parameter in a separate line



;We will jump here if our program has no parameters, which means
;that this program won't do anything if we have no command line
;parameters:
;;
 .noparams:





;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++







;Return control to the kernel:
;;
 ret







;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps
;;;INIT: This is the most decent place to put application variables and data without memory management and without code jumps










myImportsFunctionsTable:
                   ImportsCount dd 6
                           clrscr dd clrscr@KernelCore
           console_kprint_visible dd console_kprint_visible@KernelCore
           console_doCRLFeffect   dd console_doCRLFeffect@KernelCore
adjustCommandLineFATname          dd adjustCommandLineFATname@KernelCore
getCommandLineArgsCount           dd getCommandLineArgsCount@KernelCore
copyCommandLineArg                dd copyCommandLineArg@KernelCore






cmdstrbuff times 1024 db 0










;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps
;;;END:  This is the most decent place to put application variables and data without memory management and without code jumps

- Crear una librería para mi sistema operativo y así crear aplicaciones en base a mi sistema operativo y de esta forma facilitar el llamado a syscall. Por ejemplo para leer un archivo usaría una sintaxis muy simple y en español.

Código:
Archivo archivo = SysAbrirArchivo("C:\\archivo.txt");
char* buffer = malloc(Archivo->Tamaño);
SysEstablecerPosiciónArchivo(archivo, 0); // es como un seek
SysLeerArchivo(archivo, buffer, Archivo->Tamaño);
SysCerrarArchivo(archivo);

Algo súper simple y entendible.

Todo esto lo digo porque tuve la oportunidad de leer un sistema operativo hecho en ASM con librería en C de 64 bits (que seguramente muchos saben de cuál se trata) que tenía syscalls e hice algunos programas en base a ese sistema (nasm y gcc).
Eso parece simple pero crear una librería capaz no solo de crear manejadores de archivo de forma estable, sino entender el formato del disco es algo avanzado, y no necesita modo de usuario para poder experimentar con esos algoritmos. Incluso en FAT12, definir unidades e ir más allá del directorio raíz necesita más estudio.

Yo ofrezco definir una investigación en este tema sobre lo que sé (leer archivos del directorio raíz de FAT12), y desde ahí definir cómo se logra más que eso, de forma implementada, con código y explicaciones reales.





Y sobre Bochs, este tiene una instrucción o un puerto de depuración, pero nunca lo he usado porque lo considero contaminar el código.

Lo que hago simplemente es hacer microprogramas con funciones de una futura librería, y los depuro incluso bajo Windows, o usando javascript, o en DOS. De esta forma es mucho más fácil saber qué está mal.

También es posible hacer un dump de la memoria de Bochs, y examinar si esta contiene la estructura que uno esperaría (especialmente en versiones de Bochs cercanas a la 2.6, etc.).





Todo esto es algo que puedo hacer (leer un programa del floppy y ejecutarlo). Tal vez hay problemas con el código de modo usuario, pero sin ver nada de código, y menos aun sin saber la lógica con la que se ha pensado, es imposible saber o ayudar demasiado.

Como digo, para apdender sobre muchos algoritmos, incluso cargar programas de forma multitarea, no requiere modo usuario (y se puede comenzar a hacer algo útil para un kernel que realmente uno vaya a usar de forma entusiasta y que aporte conocimiento -necesario para avanzar con paso firme, evitando estos errores de principiantes y superarlos a lo sumo en 1 año en lugar de en mucho mas que eso-, como visualizar GIFs, BMPs, documentos de texto, iconos, y trucos de hardware, entrar a modo de 64 bits, crear compiladores o ensambladores simples, etc.).

La idea es que lo que se aprenda en el lado de un kernel propio sea usable en cualquier otro entorno. O sino, ¿cuál sería el objetivo, y cuál sería el verdadero beneficio más allá de crear un kernel simple, que muchos hemos creado, pero de forma incompleta e inestable (inestable en que no lo usaremos demasiado ni podríamos fácilmente agregarle demasiadas cosas útiles)?


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 17:08 pm
Por esto aconsejo ir rápido, pero también escuchar lo que otros tenemos que decir en lo que hemos intentado antes. En otras palabras, es mejor olvidarse en mayor medida del modo v86 virtual del modo de 32 bits y usar emulación de software, si uno no tiene drivers de video y aun así quiere poder cambiar modos de video.
.......


Mmm. Amigo no lo tomes a mal, pero sobre el modo usuario sólo es una alternativa para aislar las aplicaciones normales del kernel. No estoy TAN (!) obsesionado con eso. Sé lo que me dices. Llevo meses con ese kernel y he estudiado la FAT como tu.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 17:17 pm
Eternal:

Me sale este error en el VS:

1>user.cpp(39): error C2094: la etiqueta 'eip' no estaba definida

Y los archivos que contienen el código asm no contienen las direcciones de memoria.

Mas cuando obtengo la dirección de la función y pongo un breakpoint con el bochs "b 0xC0004330" (enter) y luego pongo c (enter) y la palabra reiniciar en mi commandline (enter) no se detiene.

EDIT:

¿Está bien usarlo de esta forma?:

long mem;

_asm mov eax, eip
_asm mov mem, eax


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 17:26 pm
EIP es un registro, deberias verlo en el depurador, en el codig no podes usar mov (podes usar lea o hacer una llamadita):

http://stackoverflow.com/questions/4062403/how-to-check-the-eip-value-with-assembly-language

Igual si estas generando el Kernel con VC++ entonces hacete un favor y hace una version de depuracion (/Zi para el compilador /DEBUG para el depurador creo que era, fijate en Google o MSDN) o al menos genera los simbolos (.PDB), despues podes cargar en el WinDbg tu Kernel (con la opcion de carga dump) y con X ver todas las direcciones (son relativas a la base donde fue cargada asi que despues simplemente la sustraes y le sumas la base donde cargaste el Kernel).


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 17:34 pm
Mmm. Amigo no lo tomes a mal, pero sobre el modo usuario sólo es una alternativa para aislar las aplicaciones normales del kernel. No estoy TAN (!) obsesionado con eso. Sé lo que me dices. Llevo meses con ese kernel y he estudiado la FAT como tu.
El hecho es que un modo usuario es más estorbo que algo de valor si no se acompaña de una buena multitarea, paginación, administración de memoria y permisos bien definidos, tanto de memoria, de software, como de puertos I/O.

Estoy intentando iniciar una discusión que pueda ayudarnos a todos. Quiero publicar código y discutir estándares. Está garantizado aprender más que los principiantes de OSDev de esta forma, dado que ni ahí se discute tan plenamente como estoy planteando. Hacer preguntas aisladas como las de estos errores jamás ha ayudado a un principiante. Cientos de principiantes con dudas más y menos complejas no han llegado a ningún lugar de esa forma, y simplemente han dejado de preguntar, uno y otro, y otro.

Este tema podría mantenerse vivo por años si se discute más que esos simples errores de dedo (yo también quiero divertirme ayudando sobre sistemas operativos que es una de las cosas que más me interesan, aprendiendo y haciendo que esto sea cada vez más fácil, con ayuda entre todos).

De lo contrario, si no hay interés en discutir a mayor nivel, puedo garantizar que este tema y el kernel del que hablamos no podrían normalmente durar ni 6 meses más, y mucho menos avanzar el código y el conocimiento de forma notable.





Si solamente son meses los que tiene el kernel pero sin ninguna otra base de experiencia anterior, es natural ver las cosas tan simplemente. Pero no es suficiente ni de cerca.

Yo tengo casi una década tratando de estudiar sobre sistemas operativos, y solo recientemente es que he comenzado realmente a poder desenvolverme y entender en todos los requerimientos, de forma más completa. Y los tutoriales y foros (OSDev, OSDever, Wikipedia, BrokenThorn, el tutorial de JamesM, y el resto de conocidos), no tienen suficiente información (solo hace falta buscar "¿qué efecto tiene cada registro de la VGA y cómo se programa?" para darse cuenta que la mejor información no está tan pública, y sin eso no se llega a ningún lado).

El hecho no es que haya estudiado la FAT. Yo entiendo la FAT12 hasta el nivel de leer el directorio raíz. ¿Este kernel actual tiene más capacidad que eso? Desde ahí se puede aprender mucho más.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 17:38 pm
Ok gracias, suficiente por ahora. Más tarde continúo. Ahora lo extraño es que me parece* que tengo la dirección de memoria pero nunca se detiene (*me parece).

Más tarde o sino mañana hago pruebas y leo lo que me dices.

En cuanto a "~" admiro tu interés pero el modo usuario es útil. ¿Acaso crees que Windows sin modo usuario seguiría vivo? resultados: discos quemados (jeje), Microsoft hackeada, etc.

Edito:
- No planeo usar modo usuario hasta, como dices, dejar todo bien configurado.

Citar
El hecho no es que haya estudiado la FAT. Yo entiendo la FAT12 hasta el nivel de leer el directorio raíz. ¿Este kernel actual tiene más capacidad que eso? Desde ahí se puede aprender mucho más.
- El kernel tiene más que eso.

¿Haz revisado mi penúltimo post?


Título: Re: Modo protegido, dolor de cabeza
Publicado por: ~ en 4 Marzo 2013, 17:44 pm
Ok gracias, suficiente por ahora. Más tarde continúo. Ahora lo extraño es que me parece* que tengo la dirección de memoria pero nunca se detiene (*me parece).

Más tarde o sino mañana hago pruebas y leo lo que me dices.

En cuanto a "~" admiro tu interés pero el modo usuario es útil. ¿Acaso crees que Windows sin modo usuario seguiría vivo? resultados: discos quemados (jeje), Microsoft hackeada, etc.

Edito:no planeo usar modo usuario hasta, como dices, dejar todo bien configurado.
El modo usuario es útil y necesario, pero no es lógico usarlo si no se acompaña de todo lo que realmente lo hace útil (memoria virtual, multitareas, )

Así que, dado que necesito entender primero el hardware de forma intrincada y que nedie más usa el sistema (es monotarea), lo mejor es comenzar en modo kernel puro, y desde ahí aprender.

El enfoque de tratar de implementar el modo usuario y después agregar código más complicado de kernel ya me ha fallado antes, y me ha hecho perder tiempo en reescribir código insostenible (todo el kernel se vuelve insostenible).

Ahora tengo mejores resultados porque voy desde el nivel más bajo, desde lo que realmente necesito para reemplazar a DOS, y desde ahí, cuando esté listo, voy a agregar el modo usuario (la misma progresión de DOS hasta Windows 3, Windows 9x y Windows NT).

Por lo menos este es mi estilo porque me doy tiempo de entender y no puedo equivocarme ni desperdiciar código si me baso en progresos simples pero comprobadamente correctos.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 17:47 pm
pm.

Edito:

Tengo implementado el GDT, IDT, PIC, PIT (lo básico). De ahí deriva los controladores de excepciones. Sistema multipantalla (yo lo inventé :P). Orientado a objetos.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: Eternal Idol en 4 Marzo 2013, 17:50 pm
Gracias, tratemos de no desviar el tema, como ya dije antes este no es el foro idoneo para desarrollo de Kernels o S.O., asi que por favor tratemos de centrarnos en las dudas concretas que se plantean.

Para publicar codigo, discutir standards y demas ya se citaron varios foros incluyendo el de uno de los usuarios que participa en el hilo.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 17:52 pm
Gracias, tratemos de no desviar el tema, como ya dije antes este no es el foro idoneo para desarrollo de Kernels o S.O., asi que por favor tratemos de centrarnos en las dudas concretas que se plantean.

Para publicar codigo, discutir standards y demas ya se citaron varios foros incluyendo el de uno de los usuarios que participa en el hilo.

Exacto. Ese es el problema de este foro. Pero está muy bien así ya que está más ordenado.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: x64core en 4 Marzo 2013, 19:38 pm
Disculpen pero tengo una pregunta razonable, @lweb20:
Como pensas crear ya sea un kernel o SO si nisiquiera sabes como programar en C/C++ y resolver problemas depurando?
me refiero a que para programar tal cosa no solo se necesita un nivel basico del conjunto de instrucciones y de C/C++.
Creo que primero se empieza con un calculadora no ? Bueno es solo pregunta.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: lweb20 en 4 Marzo 2013, 19:41 pm
Disculpen pero tengo una pregunta razonable, @lweb20:
Como pensas crear ya sea un kernel o SO si nisiquiera sabes como programar en C/C++ y resolver problemas depurando?
me refiero a que para programar tal cosa no solo se necesita un nivel basico del conjunto de instrucciones y de C/C++.
Creo que primero se empieza con un calculadora no ? Bueno es solo pregunta.


Sí sé programar en C pero obviamente no lo sé todo.


Título: Re: Modo protegido, dolor de cabeza
Publicado por: MCKSys Argentina en 4 Marzo 2013, 23:35 pm
Sí sé programar en C pero obviamente no lo sé todo.

No te preocupes, NADIE lo sabe todo...  ;)

Saludos!


Título: Re: Modo protegido, dolor de cabeza
Publicado por: x64core en 4 Marzo 2013, 23:42 pm
No es necesario saberlo todo, pero si tener una buena experiencia y un nivel de conocimiento bastante bueno, sino
todo el mundo sabría como programar un kernel  :silbar: y saber como todo funciona.