| |
|
41
|
Programación / Programación General / Re: ¿Como puedo crear un SO?
|
en: 26 Septiembre 2013, 22:50 pm
|
|
Sobre aprender C al 100%, claro que es posible. Por supuesto que hablamos solo de la sintaxis, los operadores, punteros, e instrucciones como if, case, while, do-while, además de poder resolver expresiones con paréntesis y otras agrupaciones, sean funcione, números, o combinaciones. Lo mismo va para aprender al 100% la sintaxis de los macros que comienzan con #. Para esta tarea puede muchísimo crear un compilador para C, aunque para esto es necesario conocer sobre Ensamblador y teoría de parsers.
Sobre aprender el 100% de la librería estándar de C (que de ninguna manera es lo mismo que aprender C, ya que se puede ser un gran programador de C y de sistemas operativos, incluyendo de Windows, usando librerías que no son la de C, como sucede cuando se usa la WinAPI), también es posible aunque sería una tarea de toda una vida profesional, y no quedaría tiempo de hacer absolutamente nada más a tal nivel de concentración.
Sobre crear un sistema operativo, claro que es posible, pero veamos cómo hasta los mejores pequeños desarrolladores de sistemas operativos en el mejor de los casos pueden crear un clon bastante simple aunque muy complejo de UNIX y que no sea Linux, con interfaz gráfica y capacidad de mostrar archivos gráficos, y con editores de texto con coloreado. Y una enorme parte de ese trabajo lo logran porteando software y librerías ya existentes a su sistema, además de que son programadores excelentes, prácticamente de nivel mundial.
En la medida que uno no cuente ocn ayuda efectiva, rápida y directa, y no haya recibido la mejor educación informática, lo más que podría lograr es un sistema operativo incluso más simple que DOS.
En mi caso particular, tengo casi 10 años estudiando sobre sistemas operativos, y todo lo que he logrado es un sistema operativo con varios comandos de bajo nivel para el hardware desde una consola simple, teclado PS/2, y que bootea desde un floppy, y que también puede cargar programas de muestra desde ahí. También he logrado crear un compilador y un lenguaje simple, un emulador de PC incompleto en HTML5, aprendí Ensamblador de x86 en general (16, 32 y 64 bits), y algunos proyectos interesantes que se podrían integrar después con lo aprendido, como entender el algoritmo de Base64, crear ejecutables de Windows solo con un ensamblador y sin enlazador, y un programa de modificación de GIFs manejando directamente el algoritmo LZW y el formato de archivo, en HTML5.
Sin tener un conocimiento del más alto nivel desde un principio, sino que siendo autodidacta, sin vivir en un medio sin conocidos como Silicon Valley, y sin más ayuda que el material de libros, tutoriales y wikis en Internet, y con una inteligencia alrededor de lo normal, eso es aproximadamente todo lo que se puede lograr en casi 10 años , incluso con todo el tiempo del mundo.
|
|
|
|
|
42
|
Programación / .NET (C#, VB.NET, ASP) / Re: Cifrar de forma segura una Pass en el Source
|
en: 26 Julio 2013, 19:32 pm
|
|
Resultaría más práctico hacer un hash sobre los valores concatenados de usuario y contraseña y almacenar solamente eso.
Así, cuando se ingrese el usuario y contraseña, se calcularía, por ejemplo, el hash MD5 de esos valores con el hash MD5 almacenado en el código fuente.
Aunque todo esto podría no servir de nada si alguien más tiene acceso a la aplicación y si ese alguien es capaz de eliminar ese paso de seguridad, a menos que todos los datos estén cifrados también usando ese valor MD5 como "semilla" de cifrado, como mínimo por ejemplo, de una combinación alterada del "alfabeto" de Base64.
Así que si los caracteres de Base64 son originalmente:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/="
que se determine dinámicamente un orden diferente con algún algoritmo, que resultaría en una cadena como:
"CDEFGHopIJKLMPtuQRST34UVWXABYZabcdefghijklNOmnqrsvwxyz01256789+/="
Aunque esto seguiría sin servir de nada tan pronto alguien más tuviera acceso al programa, y a los valores de nombre de usuario y contraseña.
|
|
|
|
|
43
|
Programación / Programación General / Re: Planeación de una emulación escalable de x86
|
en: 4 Mayo 2013, 22:45 pm
|
Después de todo este tiempo, he logrado decidir qué cosas deberían haber sido las primeras en implementar para nuestra emulación. Actualmente he implementado nuevamente el CPU actualmente con unas 50 instrucciones de la 8086 (modo de 16 bits puro de una 386). Aquí está el emulador actual corriendo (se puede tardar unos segundos en descargar la imagen actual de BIOS provisional, incluida en el código fuente): Emulador de PC Pre-Alpha en HTML5
 Z86Emu Version 2013-04-23; 0001
RAX=B800
RCX=0000
RDX=0000
RBX=0000
RSP=0500
RBP=0000
RSI=0011
RDI=0000
RIP=002B
ES=F000
CS=F000
DS=F000
SS=0000
FS=0000
GS=0000
;_eflags_
dd 00000000000000000000000001000110b
; |||||| ||||||||| | | |
; |||||| ||||||||| | | |___ (00)Carry Flag (CF) -- STATUS
; |||||| ||||||||| | |_____ (02)Parity Flag (PF) -- STATUS
; |||||| ||||||||| |_______ (04)Auxiliary Carry Flag (AF) -- STATUS
; |||||| |||||||||_________ (06)Zero Flag (ZF) -- STATUS
; |||||| ||||||||__________ (07)Sign Flag (SF) -- STATUS
; |||||| |||||||___________ (08)Trap Flag (TF) -- SYSTEM
; |||||| ||||||____________ (09)Interrupt Enable Flag (IF) -- SYSTEM
; |||||| |||||_____________ (10)Direction Flag (DF) -- CONTROL
; |||||| ||||______________ (11)Overflow Flag (OF) -- SYSTEM
; |||||| |++------------(12)(13)I/O Privilege Level (IOPL) -- SYSTEM
; |||||| |_________________ (14)Nested Task (NT) -- SYSTEM
; ||||||___________________ (16)Resume Flag (RF) -- SYSTEM
; |||||____________________ (17)Virtual-8086 Mode (VM) -- SYSTEM
; ||||_____________________ (18)Alignment Check (AC) -- SYSTEM
; |||______________________ (19)Virtual Interrupt Flag (VIF) -- SYSTEM
; ||_______________________ (20)Virtual Interrupt Pending (VIP) -- SYSTEM
; |________________________ (21)ID Flag (ID) -- SYSTEM
Para evaluar el código actual (en el Dominio Público), descargar este archivo:  Z86Emu_PreAlpha_2013-05-04.zipLo Que Queda por Hacer A diferencia de las versiones Pre-Alpha anteriores que había puesto aquí, desde esta versión particular del emulador, se ha implementado toda una infraestructura formal que permite capturar los puertos de Entrada/Salida, y regiones de memoria (de video, de otros periféricos, etc.), y manejarlas tanto a nivel lógico como de datos de dichos puertos. Como se ve en la emulación, podemos manejar la memoria VGA, pero a diferencia de versiones anteriores, he averiguado hasta el cansancio la forma de cómo estructurar dicha memoria exactamente igual que una VGA estándar, en cada uno de sus modos de texto y gráficos (por ahora solo está implementada la funcionalidad del modo de texto 80x25x16). Como se ve, también se ha implementado capacidad de hacer un dump de todos los registros del CPU (y luego de regiones de memoria, de la memoria VGA, de los registros de cada periférico) y a la vez detener la emulación hasta que dejemos de revisar sus valores en busca de errores.
Esto literalmente hace posible que nuestro emulador se vuelva tan y más poderoso que emuladores tradicionales como 8086emu, con un alto grado educativo para el desarrollador, una vez que implementemos más cosas.Lo siguiente por hacer es implementar el 100% de las instrucciones de la 8086/8088, y esto nos dará la posibilidad de implementar un BIOS estándar a emular. También necesitamos implementar un teclado PS/2, tal como se muestra preliminarmente aquí: Referencia Visual Interactiva de Valores de Teclas del Teclado
 Con esas cosas (CPU 8086 completo, teclado PS/2 y depuración mediante dumps de registros, memoria y periféricos), se nos hará posible depurar lo suficiente como para implementar una unidad de floppy, DMA, el timer, el controlador de interrupciones, y un BIOS estándar, y completar la emulación de la VGA estándar, y afinar la emulación de las regiones de memoria aunque una lectura o escritura atraviese dos regiones de tipos diferentes. Teniendo esto, ya tendremos un emulador completo de PC 8086, el cual podremos escalar a una 386, y a una Pentium con PCI, FPU, gráficos Super VGA, mouse PS/2, CD/DVD emulado, disco duro emulado, sonido Sound Blaster y/o AC'97, y emulación de una conexión a Internet (emulando los paquetes de bajo nivel encapsulados en un XMLHttpRequest ordinario). Una vez logardo eso, solo nos queda terminar de aprender sobre los estándares de hardware mediante su emulación/implementación, sino que gracias a esto podremos finalmente aprender de forma fácil y absolutamente completa, lenguajes como C, C++, y desde ahí profesionalizarnos. Unos 3 años sería un tiempo estimado bastante justo para lograr al menos el inicio de esto.
Todo desde un navegador con soporte para HTML5, incluso uno móvil con suficiente memoria, lo que le daría mucho más valor a todo el código clásico de PC, y le daría enorme portabilidad directo en el navegador.El Siguiente Paso Concreto El siguiente paso concreto es terminar de implementar el 100% de instrucciones de una 8086/8088. Juzgando por el tiempo que me llevó implementar las primeras 40-50 instrucciones, implementar el resto de instrucciones de 16 bits puros se llevaría no menos de 1 o 2 semanas (especialmente para instrucciones con prefijos, que las modifican y les dan un tamaño variable, impredecible de antemano, pero determinable). Creo que voy a seguir escribiendo detalles variados a medida que termine de pensar bien cómo serían los siguientes pasos en el tramo actual de camino de implementación. Lo que he hecho hasta ahora, especialmente determinar las funciones de la VGA estándar, con decenas de registros y por lo menos unas 300 funciones internas a implementar, comenzando por la memoria, han sido un dolor de cabeza literal, pero que ya he superado, y con mayor habilidad como compensación, y la posibilidad de comenzar a ver la forma de un emulador de PC realmente útil en el mundo real, y extremadamente portable en infinidad de dispositivos móviles y de escritorio gracias a HTML5, y de volvernos especialistas en emulación a lo largo de los años. |
|
|
|
|
45
|
Foros Generales / Foro Libre / Re: ¿Quien ha entrado a la Deep Web?
|
en: 6 Marzo 2013, 21:56 pm
|
|
Yo he usado Tor Browser Bundle y FreeNet.
Y contrario a lo que muchos creen, uno solo encuentra lo que busca, y a veces difícilmente.
Nunca me he topado con ese tipo de material que mencionaban ateriormente.
Una de las cosas más interesantes es el Tor Library, y otras páginas en FreeNet que son interesantes, como unas sobre historias de viajes a Chernobyl, con fotos y todo.
Es interesante al buscar cosas curiosas y de valor.
|
|
|
|
|
46
|
Programación / Programación General / Re: Planeación de una emulación escalable de x86
|
en: 6 Marzo 2013, 21:51 pm
|
Este es un script que escribí en javascript para convertir un archivo de paleta de colores de 768 bytes usualmente (256 colores en grupos de 3 bytes RGB) a código fuente de Ensamblador: PAL2srcPara quienes están más interesados en javascript aquí hay un truco. Uno puede definir un link generado con javascript codificado en Base64, y también puede definir el nombre de archivo con la nueva propiedad download="nombre_de_archivo.exe". Así que podemos tener un link de la forma: <a href="data:application/octet-stream;base64,SG9sYQ==" download="Prueba.txt">Descargar archivo generado</a>
Y esto descargaría un archivo llamado Prueba.txt que contiene Hola. Aquí usamos este truco para generar el código fuente y descargarlo automáticamente al dar clic al link generado, ya con un nombre de archivo de código fuente de Ensamblador adecuado:PAL2src<body bgcolor="#aaaaaa">
<pre id="a1">
</pre>
<script>
var file1="PALETTE_80x25x16.BIN";
var file2="PAL320x200x256.BIN";
var buff=new Array();
document.getElementById("a1").innerHTML="";
function genLink(idx, file)
{
var xhr=new XMLHttpRequest();
xhr.open("GET", file, true);
xhr.responseType="arraybuffer";
xhr.onload=function()
{
buff[idx]=new DataView(this.response);
document.getElementById("a1").innerHTML+='<a href="data:application/octet-stream;base64,'+btoa(PAL2src(idx, file))+'" download="'+file+'.asm">'+file+".asm</a>\n";
}
xhr.send();
return xhr;
}
function PAL2src(idx, file)
{
var str=file.substring(0, file.indexOf("."))+":\r\n";
for(var x=0; x<buff[idx].byteLength; x+=3)
{
str+=" Color_"+(x/3)+": db ";
str+="0x"+buff[idx].getUint8(x).toString(16).toUpperCase()+",";
str+="0x"+buff[idx].getUint8(x+1).toString(16).toUpperCase()+",";
str+="0x"+buff[idx].getUint8(x+2).toString(16).toUpperCase()+"\r\n";
}
return str;
}
genLink(0, file1);
genLink(1, file2);
</script>
|
|
|
|
|
47
|
Programación / Programación General / Re: Planeación de una emulación escalable de x86
|
en: 6 Marzo 2013, 16:54 pm
|
Quiero usar imágenes de floppy de 1.44 Megabytes, pero esos son demasiados datos. Así que pienso comprimirlos con PHP, con un código como el siguiente: <?php
function print_gzipped_output($filez="LowEST_Kern.img")
{
$HTTP_ACCEPT_ENCODING = $_SERVER["HTTP_ACCEPT_ENCODING"];
if( headers_sent() )
$encoding = false;
else if( strpos($HTTP_ACCEPT_ENCODING, 'x-gzip') !== false )
$encoding = 'x-gzip';
else if( strpos($HTTP_ACCEPT_ENCODING,'gzip') !== false )
$encoding = 'gzip';
else
$encoding = false;
//print "afds";
if( $encoding )
{
// $contents = ob_get_clean();
$contents=file_get_contents("LowEST_Kern.img");
$_temp1 = strlen($contents);
if ($_temp1 < 2048) // no need to waste resources in compressing very little data
print($contents);
else
{
header('Content-Type: application/octet-stream');
header('Content-Encoding: '.$encoding);
print("\x1f\x8b\x08\x00\x00\x00\x00\x00");
$contents = gzcompress($contents, 9);
$contents = substr($contents, 0, $_temp1);
header('Content-Length: '.strlen($contents));
print($contents);
}
}
else
print(file_get_contents("LowEST_Kern.img"));
}
print_gzipped_output();
?> Con esto, una imagen de floppy casi vacía puede pasar de 1.44 Megabytes a solo unos 13.5 Kilobytes. Esto necesito integrarlo al XMLHttpRequest que lee datos de floppy en el emulador. Otro truco más, de PHP, globalmente útil para muchas otras cosas, que vamos a usar para este proyecto. Y la compresión GZIP no la tengo activada globalmente en el servidor porque así no puedo ver mi sitio desde mis Palm LifreDrive, así que voy a usar compresión solo para aplicaciones especiales como esta, que de todas formas no pueden correr en la Palm (no hay HTML5 ahí). Para modo de 32 bits necesitamos una nueva versión del byte Mod/RM y el nuevo byte SIB. Las cosas se vuelven difíciles porque se pueden usar instrucciones de 32 bits en código de 16 bits, e instrucciones de 16 bits en código de 32 bits. Así que es difícil pensar cómo implementar esa funcionalidad sin duplicar código, y que sea usable globalmente por todas las instrucciones. Las tablas que usamos son las siguientes (de los manuales de Intel):   Este es el código capaz de generar opcodes para todos estos casos. Pero igual que con la tabla para 16 bits, direccionar los registros en orden de acuerdo a los diferentes casos de la tabla (registros generales, MMX o XMM), o una ubicación de memoria, requiere un poco más de código. Eso sé cómo hacerlo en la mayor parte. Lo que no sé es concretamente, cómo recuperar la instrucción con todo y sus prefijos, y llamar la funcionalidad particular de cada instrucción a través de una función que interprete los bytes Mod/RM y SIB, y les pase los operadores.
Creo que antes de esto, sería necesario crear un desensamblador para cada instrucción, y así distinguir si nuestro código está siendo capaz de descifrar las instrucciones.
Así que creo que ese va a ser el siguiente paso: Crear un desensamblador comenzando con las instrucciones XOR, como prueba de concepto.function modrmwords(modrm)
{
if(mod(modrm)==1)
{
return "0";
}
if(mod(modrm)==2)
{
return "0,0,0,0";
}
return "";
}
function xor_32()
{
var str="bits 32\n\n";
for(var modrm=0; modrm<256; modrm++)
{
if(mod(modrm)<=2)
{
if(mod(modrm)==0 && rm(modrm)==5)
{
str+="db 0x31,"+modrm+",0,0,0,0\n";
continue;
}
if(rm(modrm)==4)
{
for(var sib=0; sib<256; sib++)
{
var sibstr=SIB32(modrm, sib);
if(sibstr!="")
{
str+="db 0x31,"+modrm+","+sibstr+"\n";
}
}
continue;
}
else
{
str+="db 0x31,"+modrm;
}
var modrmstr=modrmwords(modrm);
if(modrmstr!="")
str+=","+modrmstr+"\n";
else
str+="\n";
continue;
}
//If we are here, the Mod field is 3:
///
// if(mod(modrm)==3)
// {
// str+="db 0x31,"+modrm+"\n";
str+="\n";
// }
}
return str;
}
function SIB32(modrm, sib)
{
if(base(sib)==5)
{
if(mod(modrm)==0)
return sib+",9,9,9,9";
if(mod(modrm)==1)
return sib+",8";
if(mod(modrm)==2)
return sib+",32,32,32,32";
}
// if(index(sib)!=4)
{
return sib+","+modrmwords(modrm);
}
return "";
} Estoy reuniendo y depurando el repositorio final de definiciones de valores de registros VGA. Por ahora tengo los registros para el modo 320x200x256 colores, 640x480x16 colores, y 320x240x256 colores (Mode X). Al principio tuve problemas en depurar el modo 640x480x16 colores, pero ahora los valores de registros son coherentes con el resto de referencias, y el video funciona bien. Esta es una captura de pantalla rápida que muestra que el modo Gráfico VGA 640x480x16 colores ahora lo hemos depurado y ya funciona correctamente, al entrar a este sin usar el BIOS:  Para ver las definiciones en código fuente, ir aquí: Definición Concisa de Registros VGALo que nos interesa para esto es la sección Configuración de Registros para Modos de Video. La "basura" que se veía anteriormente en la captura de pantalla es el contenido de la fuente en modo texto, que aparentemente comienza en la dirección 0xA0000, la misma en la que comienza la memoria de modo gráfico VGA estándar. Esto también demuestra cómo se logra poner un logo y texto en la pantalla de inicio del BIOS. Es posible que para BIOSes que realmente usan modo gráfico y aun así son capaces de mostrar un logo, lo que hagan sea modificar algunos caracteres de la fuenta ASCII, desde los caracteres 128 a 255 como fragmentos del logo, y así logran estar en modo texto y mostrar por ejemplo el logo de Energy Star, etc., en modo de texto.Ahora pongo aquí un índice que pienso rellenar con la información pertinente, que demuestra todo lo que necesitamos entender en principio para continuar con un emulador de VGA: Guía de Programación a la EGA, VGA y Super VGA |
|
|
|
|
48
|
Programación / ASM / Re: Modo protegido, dolor de cabeza
|
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. |
|
|
|
|
49
|
Programación / ASM / Re: Modo protegido, dolor de cabeza
|
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. |
|
|
|
|
50
|
Programación / ASM / Re: Modo protegido, dolor de cabeza
|
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.zipPor 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: ;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. 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)? |
|
|
|
|
|
| |
|
Mostrar Mensajes
