Foro de elhacker.net

Habia hecho un hermoso post, pero de idiota aprete backspace fuera del area de texto y el navegador perdio todo (cargó la págian anterior) jaja.... que paja pocas ganas de escribir todo de nuevo....


Bueno, la idea es esa, hacer un SO. Esto ya se ha intentado varias veces antes y muchas más se ha hablado.

Antes de que alguien venga a decir "es dificil", "mejor hagan una distro de linux", "estudien minix" o cosas similares aviso que la idea es, desde un comienzo, partir de "la nada", aprender, desarrollar y construir algo par air viendo su avance.

Es MUY buena idea ver, analizar y usar fragmentos del codigo de Linux, Minix o sistemas GNU / GPL, pero solo como referencia, no es la idea hacer otra distro de un sistema existente, sino construir uno.

¿con que finalidad?: Aprender, divertirse, basicamente esas dos finalidades. Posiblemente sea un sistema Horrible, inestable, reducido,... mal hecho en muchos aspectos, pero no es la idea superar o igualar a ninguno de los sistemas existentes (ni siquiera al MS DOS :P)


Me gustaria saber quien esta dispuesto a intentarlo, con entusiasmo y perseverancia, sabiendo que no sera tarea facil y que llevara mucho tiempo, si sabiendo esto aun te gusta la idea, pues bienvenido al tren.


Basado en experiencias anteriores, seria bueno evitar tratar cuestiones como "¿que nombre le vamos a poner?" o "¿y el logo?"... o discutir sobre si sera grafico, consola, si tendra soporte para video en 3d y esas cosas qeu estan a AÑOS LUZ del punto actual.

En este punto inicial lo que hay que lograr es:

Boot desde FAT 12, 16 y 32 (floppy y pendrive/HDD), tampoco seria mala idea EXT2 o similares dada su amplia especificacion disponible.

Secuencia de inicio: Boot Sector > Loader > Kernel

El loader deberia, en teoria entrar al modo protegido (32bits. Aca hay que hacer una breve comprobacion de hardware), mapear la memoria, controlar interrupciones y luego cargar el kernel desde el sistema de archivos (el cual habra que detectar oportunamente si se usadan varios sistemas de archivos).

El kernel se deberia de encargar de gestionar la memoria mapeada con el loader (¿convendra mapear la memoria con el kernel?... buena pregunta), proporcionar funciones apis (en lo posible compatibles con POSIX) para manejo de sistema de archivos, keyboard, puerto serial, paralelo, video (text mode inicialmente).



Creo que eso es mas que suficiente para un comienzo, de hecho es mucho (BOOT SECTOR en varios sistemas de arhcivos, un loader y la carga de un kernel)


El lenguaje a usar cual será?

Para el boot sector, creo que no queda otra alternativa que usar ASM, la buena noticia es que tenemos buenos codigos disponibles en Linux, ReactOS, FreeDOS, MenuetOS, etc.

FASM es una buena alternativa dado que permite compilar para muchas arquitecturas (x86, x64 seran los preferidos) y plataformas (windows, linux... que no usaremos, y la compilacion binaria "bruta", que si usaremos)

para el Loader, el Kernel y el resto, C / C++, segun sea aplicable.

Para C/C++ una buena alternativa es CodeBlocks que usa el compilador GCC y esta disponible (IDE y Compilador) para Windows y Linux, eso facilitaria las tareas de depuracion y programacion entre los interesados que tengan o queiran probar compilar/desarrollar desde diferentes sistemas.


Sin mas que decir espero que alguien se sume a la idea y que podamos llegar a hacer algo presentable y no muera en el intento como ha ocurrido antes en muchos proyectos.

EDIT:

Aca dejo un par de links utiles, ire agregando mas con el paso del tiempo.

Los pongo en el primer post por organizacion.

Especificaciones de los sistemas de arhcivos FAT:

Yo me apunto de buena gana, pero a ver en que queda la cosa  ;D

Yo creo que lo mejor es que el Kernel sea puramente x64, seguir usando x86... Hasta los netbooks de hoy en día traen procesador x64.

Nasm también sería una buena opción.

Saludos.

Perfecto¡¡ maravilloso has puesto en un post mis ideas, todo lo que llevaba un tiempo pensando hacer.
Contad conmigo, yo me apunto, aunque estoy acabando la carrera y mi tiempo sera limitado contadconmigo.
Una pregunta ¿monolitico o micronucleo?  Yo tenia pensado hacer un micronucleo modificado, por lomenos para que se diferencie de algo a Linux, tener software libre donde elegir.
Un saludo.

La idea de x64 es tentadora, pero me parece algo demasiado alto para comenzar. Todos los procesadores de 64bits son compatibles con x86, y pueden ejecutar 16, 32 y 64bits (el tio bill no hizo compatible windows x64 con aplicaciones de 16bits simplemente por capricho, podia haberlo hecho).

De todas formas, queda a criterio de la mayoria del grupo si será x86 o x64, lo decidiremos en grupo, como una democracia.


Nasm también sería una buena opción claro, para el boot sector, no para el SO :D


Por otro lado, ¿monolitico o micronucleo?...


Linux es monolitico con la posibilidad de cargar modulos, Windows es monolitico hibrido. Minix es micronucleo y Mac OS X tambien es micro nucleo.

A mi, personalmente me gusta mas monolitico... no me gusta mucho la idea de dejar las aplicaciones tan "libres", prefiero que el SO se encargue de todo el hardware, como linux. Corrijanme si me equivoco.

micronucleo modificado, ¿a que te refieres? ¿hibrido?

Bueno pues, ya somos 3, espero que mas gente se apunte, cuantos mas seamos, mejor será, de todos modos debemos organizarnos bien para que no se fragmente el grupo por diferencias de ideas.... pero eso se verá cuando seamos un grupo de mayor tamaño, hasta ahora solo somos 3, lo cual no está mal ^^

Hola, que tal.

Decirte que a mi también me interesa bastante la idea, y creo que puede estar muy bien para aprender.
Respecto a monolitico o micronucleo, en mi opinion creo que es mejor que sea el so quien gestione el hardware.

La verdad es que me gustaría bastante participar.

Saludos

Perfecto Leber, bienvenido :D

He agregado unos links utiles al final del primer post. Ire agregando mas (en el primer post por cuestiones de organizacion) con el paso del tiempo y segun sea la necesidad.

Mucha suerte con el proyecto, para cualquier duda aquí estamos.

Les agrego un link donde podrán encontrar bastante información sobre el tema.

http://wiki.osdev.org/Main_Page

Saludos

Windows es micronucleo modificado (lo he estado analizando hace unos dias en sistemas por eso lo se ;) )
A mi me gusta mas micronucleo por el tema de que nohabra que eestar compilando todo el santo dia, pero vamos,  me da igual yo lo hago por aprender, nada mas.

Bueno para quien quiera irse dando ya una idea dejo el link de los manuales de los procesadores Intel: http://www.intel.com/products/processor/manuals/index.htm

Estaría bien estandarizar los programas que vamos a usar, yo trabajare sobre Windows asi que que haya para ambos SO please :P

Bueno, por lo de compilar todo el dia, no creo que sea problema... no sera (al menos no en sus inicios) como el kernel linux que necesita de mucho tiempo para compilar.

Por otra parte, Windows NT es un monolitico modificado, y no al reves. De todas formas, no deja de ser un nucleo hibrido.






Como dije en el primer post, FASM o NASM para el boot sector (Disponible para Windows y Linux) y CodeBlocks (IDE para C/C++ con el compilador GCC, disponible para Windows y Linux).

Luego pondre unos links de interes en el primer post, mas los que han aportado. :D

Buenas, me gustaria formar parte del proyecto  ;D

PD: No se mucho (casi nada  :xD) sobre como hacer un SO pero me gustaría aprender..

Hola a todos!!

A mi también me gustaría contribuir en un proyecto como este, pero reconozco que es algo que requiere muchos conocimientos, tiempo y dedicación.

Además es un proyecto bastante ambicioso y difícil de realizar.

Yo básicamente en lo que puedo ayudar es en la programación en C++, aunque esto no es suficiente :( y además supongo que se necesita un nivel elevado y de momento no lo tengo.

Saludos  ::)

Hola, creo que de momento lo primero sería que SERBice (puesto que es el creador del post y de la idea) creara una cuenta en algún repositorio de código (codegoogle, sourceforge). De esta manera podríamos colaborar todos, subiendo nuestros aportes.

Estuve pensando en el tema del bootloader y lo mejor es cargar nuestro kernel desde una imagen .iso. Cargar el kernel desde un .img es muy sencillo pero cuando pasa los 1440KB hay que portar el código para que se cargué desde una .iso. Creo que lo más conveniente es usar Grub y para crear la iso utilizar mkisofs desde consola (funciona en Windows y en GNU/Linux).

Mañana subiré un amago de kernel para que escriba algo en pantalla.

Saludos.

Requiere conocimientos, tiempo y dedicacion, por supuesto.

Ambicioso?, eso es relativo. como dije antes, no se pretende competir con nada ni nadie, ni siquiera con MS-DOS. La idea es aprender y lograr hacer algo razonablemente estable y operativo, por mas limitado que sea.




Muchas veces (en otros threads y proyectos) se ha discutido sobre si construir un bootloader o usar grub, lilo o alguno similar.

La idea del proyecto es hacer un So desde lo mas abajo posible, lo cual incluye el boot sector, bootstrap (bootloader) y luego el kernel. De momento iremos pasoa  paso, BootSector y BootLoader, luego nos preocuparemos por el kernel.

para hacer la secuencia boot necesitamos, minimamente, soportar FAT12/16, para de este modo leer los arhcivos que iran ejecutandose secuencialmente (Boot Sect > Boot Loader > Kernel > Drivers), de otro modo no podriamos leer nada.

En cuanto a lo del repositorio, hace varios dias estuve evaluando las diferentes alternativas y tengo pensado hacer un repositorio.

Luego le echare un ojo a codegoogle... ¿alguien sabe si codegoogle tiene SVN o algun sistema similar?


Solo como cierre de este mensaje: Recuerden que la idea es aprender, desarrollar y lograr hacer algo como grupo. No se pretende hacer algo de altisimo nivel con GUI... no es la idea competir o asemejarse a NT, Linux ni a DOS, sino hacer un simple SO (que probablemente crezca con el paso del tiempo y el aporte de la gente).

Yo soy partidario de VER y usar las ideas y fragmentos de codigos de otros proyectos (como GRUB, Linux, ReactOS, Wine -para soportar soft windows-, especificaciones coff y elf, etc), pero siempre desarrollando un modelo propio, aun cuando este no sea la mejor implementacion, pero la idea es hacer algo propio de este grupo, no hacer copy/paste.

Jajaja yo podria hacer minijuegos para el SO xDD con SDL...

Dudo que puedas usar librerias  :laugh:
En cuanto al S.O. es una buena idea, hacerlo entre todos, en cierto foro del que no voy a decir el nombre un usuario del que tampoco voy a decir el nombre esta trabajando en un S.O. llamado Luxur. Ya le ha incluido incluso una Interfaz Grafica (Simulada y con colorines, nada de GUIs).
Lo que quiero decir con esto, es que no es una idea tan descabellada, que si se tienen los conocimientos y las ganas de hacerlo se puede lograr.
Por cierto ¿Vas a usar POSIX o algo por el estilo o todo desde 0 ?

Hi again boys,

Hoy me puse a curiosear por el foro, y veo esto. Como saben, tengo un poco de code de BootSector, pero no tiene nada relacionado a carga del kernel ni sistema de archivos.

En mi opinión, si alguien tiene la documentación de lo necesario para bootear desde GRUB es lo ideal, sino está el boot de FreeBSD que está bien armado.

Se debería abarcar C desde el principio, con esto quiero decir que podría usarse el código de Minix hasta el seteo del main() de INIT. Después el Kernel y lo demás se van diferenciando.

Si va a ser un proyecto para aprender, divertirse y joder un poco, hagámoslo seguro y bien friki. Los microkernels son para que el usuario cargue cosas en caliente. Podemos hacer un monolítico y diferenciar bien la kernel-land para hacer que el sistema completo sea caprichoso.

Bueno, acá tienen a alguien para ANSI C, ensamblador, algo de x86 y organizacion.

Por cierto, sigue mi invitación a que se use GIT. Lo estoy usando en la empresa, para los proyectos que me toca llevar, y la verdad es que GIT hace la vida más fácil. Ya portaré mi lenguaje (aún gestandose en C) a este nuevo SO cuando se pueda.

Saludos!

Al final, me retrasé un día en publicar este amago de kernel. Como ya dije utiliza Grub como bootloader y carga un pequeño kernel en C.
Utilicé como tutorial: http://www.osdever.net/bkerndev/Docs/basickernel.htm

Me ayudó muchísimo y conseguí crear una ISO booteable que mostrara esto:

(http://img684.imageshack.us/img684/2946/nitroos.png)

Lamentablemente, solo se puede compilar desde GNU/Linux aunque el manual está hecho para Windows no fui capaz de compilarlo en Windows: ¡me falla el linker!
Mi idea era tener 2 scripts: 1 .bat y un .sh y poder compilarlo tanto en Windows como en GNU/Linux.

Nitro OS no es el nombre definitivo del kernel  ;D, fue una tontería que se me ocurrió. La imagen está tomada desde mi netbook con Ubuntu netbook 10.10, mientras tenía manuales abiertos en mi pc Windows  :xD

/*
*	Nitro OS kernel
*
*/
 
#include "inc/types.h"
#include "inc/video.h"
 
void NitroOS (ULONG magic, ULONG addr)
{
	InitVgaMode();
	WriteLine("Kernel name: Nitro OS\n");
	WriteLine("Prueba de un Kernel cargado desde Grub para elhacker.net\n\n");
	WriteLine("Fdo: Khronos\n");
    for (;;);
}
 

Aquí os dejo todo el código fuente, con la ISO ya lista por si queréis probarla.
http://www.multiupload.com/E12IIORG3K

Creo que lo mejor es que se cree un repositorio para ir subiendo nuestros aportes, porque andar subiéndolo a un servidor de descargas es un coñazo para todos. También, si alguien es capaz de compilarlo desde Windows, se agradecería mucho su aporte.

Saludos.

Una idea genialisima,me apunto yo tambien,me interesa muchisimo este tema sobre los S.O


saludos

Tiren un nombre y creo un proyecto en GitHub.

¿Alguien más que esté familiarizado con el flujo de desarrollo distribuído clásico de GIT con parches y redes de confianza?  De otra forma puedo encargarme de la administración de esta parte (al menos por ahora).

También se necesitarán maintainers. Al inicio basta con que el kernel pueda correr el proceso INIT, así que el planificador de tareas no necesita capacidad de planificar. Hay que ver qué partes se desarrollan, y en mi opinión, el code de FreeBSD es siempre una buena referencia si no se sabe que hacer.

Por ahora me parece buena idea compilarlo en LINUX, ya que al fin y al cabo, si se implementa POSIX usaremos un Shell UNIX y Makefiles.

Por cierto, soy partidario de documentar y llevar bien armado el diseño antes de meterse a hacer código. Prefiero un thread de 50 mails para decantar en una solución concreta y correcta de un problema, antes que 10 veces modificar lo mismo por picar código.

Se aceptan nombresss y documentos. De otra forma esto va a quedar en lo mismo que los anteriores.

xD4RIOx, la idea es crear un kernel que sea distinto de los actuales. Lo único que podríamos "copiar" de GNU/Linux sería la shell bash o algún driver en concreto.

El nombre que propongo: Nitro OS.

Saludos.

Bueno, vamos por partes y conceptos generales (nada de codigo)

Sistema nuevo, desde cero.

Posix?: algun dia, de momento tenemos que, desde el sector se arranque se carque un loader (de unos pocos kb) y que el mismo sea capaz de pasar a modo protegido, logrando cargar un archivo grande, osea el kernel

¿por que el kernel es un archivo grande?: no lo es aun, pero si esto prospera serà, y nos encontraremos con la limitaciond e cargar un archivo de varios MB en memoria y ahi se complicará. Es mejor preeer esto desde el inicio.

Nombre: No soy partidario de empezar a decidir el nombre, el logo, y todos esos detalles que no hacen al sistema y solo son una distraccion para todos. No obstante, si insisten en ello, les propongo dos nombres. ProjectOS (o ProyectOS) y PolygonOS (o PoligonOS), ambos son un juegop de palabras, el primero (ProjectOS) significa Proyecto de Sistema Operativo, el segundo (PolygonOS) se basa en una idea mas elaborada, la misma consiste en que EN EL FUTURO el sistema será grafico (o tendra algun agregado como kde) que dibujará poligonos para construir una interface.

Considero que si se pone un nombre, debe tener algun tipo de coherencia y relacion con la idea. Sin ofender, Nitro OS suena a intento de suite stand alone de "niño hacker" recien iniciado.... suena demasiado "pomposo" y presumido. (lo digo con la mejor intension).


GRUB?: Se puede hacer que el kernel sea compatible con GRUB, no es dificil, es solo poner unos encabezados en el archivo del kernel para que GRUB pueda "entenderlo", no obstante DEBEMOS DESARROLLAR LA SECUENCIA DE INICIO DESDE CERO, para aprender bien ya que esa es la idea.

Codigo Minix / FBSD: Sirve como referencia... todos sirven, Minix, ReactOS, Linux, Menuet, FreeBSD.... incluso el nucleo de Mac OS X (Darwin) ¿sabían que es open source?, pero repito  SOLO COMO REFERENCIA, no es la idea hacer un copy & paste y ya.... hay que entender la logica y funcionamiento del sistema completa, y para ello debemos ir todos juntos, paso a paso.

En cuanto a la documentacion, estoy deacuerdo. Debe documentarse en exceso, para que todos logremos entender que hace cada fragmento del sistema, en lo posible funcion por funcion (seria un exceso linea a linea).


GIT: La verdad no conozco GIT, yo uso SVN y vi que CodeGoogle lo usa, creo que seria conveniente CodeGoogle, veré si puedo crear uno.

Compilador a usar: sin dudas, GCC, es multiplataforma (Windows/Linux/MAC). Asi mismo, hay varios IDE's que trabajan con GCC, lamentablemente yo aun no logre hacer un Flat Binary (binario "puro") con Code::Blocks (IDE para GCC). Luego seguiré investigando.... otra alternativa de IDE es Dev C++.

Lenguaje: Sin dudas ANSI C dado que es el mas "nativo".

No queria dejar eso del "Juego con SDL": Amigo, eso sera MUCHO mas adelante (hablamos de años creo yo). SDL funcionaria en el sistema si se porta al mismo, no hay forma de usarla sino.


Resumire, de forma ordenada, las cosas que hay que hacer y su orden.

Boot Sector:


Loader:



Para finalizar quisiera expresar mi alegria por la gente que se ha sumado y decirles que si mantenemos una organizacion y una misma linea, lograremos llegar a buen puerto. Lo m{as importante es ir todos en el mismo sentido, y no distraernos con cosas demasiado lejanas en el tiempo (como jeugos, interfaces, drivers para dispositivos avanzados -placas graficas por ejemplo-), centremosno en iniciar el sistema, manejar la memoria e interceptar las interrupciones.
Si el so ejecutará programas, será DE A UNO, como lo hace DOS. Luego agregaremos MultiTask, no nos apuremos.


Yo me ausentare por 7 dias por razones laborales, pero luego volvere y vamos a darle con todo a esto gente. Si tienen ideas, vayan pensandolas, hagan un txt con sus ideas, analicen, pros y contras, como la implementarian?. Una descripcion lo mas detallada posible, asi todos podemos ir entendiendo nuestras ideas y debatirlas en grupo (no sean demasiado soñadores).

Nuevamente: Bienvenidos a todos y esperemos que mas gente se sume.

Es verdad XDD .
Bueno puedo hacer tipico juego de consola XD sin graficos xDD.Así si os aburrís podeis descansar un poco. xD

Nombre del SO SO System Open

Podeis fijaros y tomar ideas de Luxur.

http://luxur.comoj.com/

Me parece una idea genial ;).

Sa1uDoS

Creo que me malinterpretaron algo:

Mencione que *compilarlo* en LINUX es buena idea, no hable de copiar Linux. Aún así, "bash" no es parte de Linux  ;D

Por otro lado, remarcar algunos puntos:

Si se planea usar POSIX en el futuro, obviamente no lo tendremos en cuenta para elaborar las internas del planificador o el loader (Sencillamente no forman parte de POSIX). Pero se debe tener en cuenta el estándar que se pretende cumplir antes de tener qué corregir para cumplirlo, o al menos me parece lo más sabio.

El desarrollo del kernel, por su parte, no tiene porqué depender del desarrollo de un Loader. Quienes quieran dedicar tiempo a crear un loader propio, bienvenidos sean, y trabajen libres en ese área, pero si el kernel bootea desde GRUB y los demás quieren meterle tiempo a desarrollar otras cosas, deben ser libres de hacerlo. Modularizar es también descentralizar, y eso significa que definitivamente no iremos todos juntos sabiendo cada cosa que se escriba.

Documentos: Hay documentos técnicos detallados que explican el funcionamiento de cada parte. Hay documentos que explican el funcionamiento/finalidad de un módulo, hay otros para un subsistema. En principio: No aceptar código sin una estructura y documentación medianamente razonables. La filosofía que aprendí de Linus y Junio y creo, es aplicable a cualquier proyecto.

Compilador: Se puede tener un márgen de aceptación, donde gcc debe poder compilar.

GDT e IDT son tablas de descriptores. La IDT guarda las interrupciónes que serán parte del núcleo. Funcionalmente, carguemos de donde carguemos, la IDT deberá setearse, así que no es parte del loader.


Khronos14: Pasame ese código a soft.d4rio en GMail y seguimos en contacto

Estoy de acuerdo con xD4RIOx, creo que deberíamos centrarnos en el desarrollo del kernel porque GRUB es un buen bootloader.

xD4RIOx, aquí tienes todo el código fuente y la ISO ya creada:
http://www.multiupload.com/E12IIORG3K

Pero no vale mucho, acabo de encontrar unos errores en la función PutChar y tengo que arreglarla.

Lo prioritario ahora sería hacer un script para compilar el kernel desde Windows, yo no fui capaz, me falla el linker.

Saludos.

Propondría primero tomar esto y llevarlo a algo más simple, y definir hacia dónde nos extendemos:

Por un lado veo muchos tipos de datos que no se porqué están definidos, es decir, no veo problema en usar 'char *' en lugar de PCHAR, aunque si me parece coherente definir BYTE:

typedef unsigned long ULONG;
typedef unsigned int UINT;
typedef unsigned char UCHAR;
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
typedef char * PCHAR;

La estructura de fuentes la cambiaría un poco para que sea más fácil usarla después, y haría un makefile en vez de un script SH. De esa parte me encargo sin problemas (makefiles).

Fuera de eso hay cosas en español y otras en inglés (no se vos, pero me gusta en inglés porque es más internacional y pueden participar otros). Y faltaría una carpeta de documentación para ir llevando los datos de importancia, las APIs, etc.

En horario Argentina, a eso de las 19:00 o 20:00 hs estaré disponible. Podemos arreglar algo via mail, o como sea, e ir armando bien las partes primordiales, así como la organización del proyecto.

Agregame a GTalk: soft.d4rio en Gmail. Nos podemos enfocar en hacer las syscalls y que funcione un shell, que es lo mínimo.

Lo primero es dejar bien definidas las convenciones a usar (lo de los tipos me preocupa jaja!). En mi experiencia, los seres humanos no podemos ponernos de acuerdo en el 100% de las ideas, pero sí podemos hacerlas convivir. Que ese sea el espíritu.



PD: Para mi caso particular, el script para Windows no resulta prioritario porque uso Linux. Personalmente lo creo más conveniente porque al final implementaremos POSIX, y trabajar desde un sistema *nix me parece razonable... *PERO* si alguno lo necesita hacer es bienvenido a colaborar para que el SO pueda compilarse desde Win también. Todos somos amigos y queremos divertirnos haciendo esto. A la larga, el que lo crea entretenido diseñará instaladores copados para diversas plataformas y será su proyecto y su colaboración y su orgullo haberlo hecho. A mi hoy me basta que podamos correr una ISO y ver que el kernel trabaje, en esa parte me pienso enfocar, y no quiere decir que todos pretendan lo mismo. Pero juntemos las ideas que cada uno tenga y organicemonos para que se pueda hacer lo máximo posible. Algunas cosas quedarán rezagadas, pero trataremos de hacer un sistema de todos, donde cada uno pueda configurarlo y correrlo a su capricho.

Nos comunicamos luego. Estaré concentrado con mi lenguaje, pero siempre hay lugar para un proyecto nuevo y con ganas.

Si, lo mejor es que nos pongamos de acuerdo en definir los tipos de datos. Definí PCHAR porque estoy acostumbrado a usarlo en Delphi, pero no tengo problema en usar * char  ;D. Creo que las más importantes son BYTE, WORD Y DWORD porque son conocidas por todo programador.

Lo del makefile es buena idea, y la carpeta de documentación estaba empezando a hacerla. La documentación la estaba escribiendo con el OpenOffice para luego exportarla a formato pdf. Creo que un makefile para Windows es necesario, para mi por lo menos, ya que mi PC potente que es donde programo tiene Windows.

No se si estaré conectado a esa hora, aquí en España son 4 horas más. Pero podemos comunicarnos vía mail (te lo mandé por privado).

Saludos.

Me resulta gracioso que aquí en la empresa también trabajo con España, así que tengo un reloj con tu hora local jeje.

Te escribo luego y vemos qué hacer, ahora tengo trabajo!
Saludos

Usar GRID, ya pensando en POSIX, y ¡como no¡¡ monolotico..
Yo creía que ibamos ha hacer un proyecto nuevo y para aprender no un Linux más, para eso es mejor compilar una distro personalizada y nada mas.
Yo si el proyecto inicial desde el mismo boot para aprender sigue en pie  a ese me apunto, para este que estais haciendo, y sin animo de ofender a nadie, hay programas que con 3 click te hacen tu distro linux personalizada.
Un saludo y mucha suerte en vuestro proyecto.

Anay nadie habló de hacer una distribución Linux, no se de donde sacas eso. Si leyeras el post entero y vieras el código fuente que subí, sabrías que esa "cosa" (porque no es un kernel ni es nada) lo único en lo que se parece a una distro es que usa GRUB.

Lo de la posible implementación de POSIX daría compatibilidad con aplicaciones *NIX, pero no es definitivo, quedan años para llegar a algo como eso.

Saludos.

Hola la verdad esque ahora tengo demasiado tiempo libre, ando de NEET y llevo siguiendo este hilo un tiempo, y me interesa el proyecto, me interesa participar en el. Ahora en este punto en mi opinión si se implementa el booteo desde GRUB nos estamos saltando una parte importante y divertida! vamos, que como se ha dicho no competimos con nadie, y hasta donde veo el tiempo no es problema. Es por eso  que invito a la creación de forma primitiva del bootstrap, que sinceramente hacer que bootee un binario en 80386 no es muy dificil, tal vez lo dificil y que no se como hacer es cargar desde ese binario el Kernel, pero vamos con calma, no aceleremos.

Lo que sabemos:
Los requisitos mínimos para un bootstrap: binario de tamaño 512 bytes, ni uno más ni uno menos. La posición de carga del binario en 07C00h, Terminación en la posición 0AA55h y con solo esto ya es suficiente para hacer que la BIOS bootee el binario creado desde NASM, ahora habria que implementar el resto del bootstrap para hacer la carga.

[ORG 7C00h]                        ; Posicion de inicio de booteo
 
main:   jmp main                   ; Ciclo
times 512-($-$$)-2 db 0            ; Codigo de 512 bytes
dw 0AA55h                          ; fin de posición para booteo
 

Este código es suficiente para que bootee:

nasm -f bin archivo.nasm -o boot.bin

y hacemos:

qemu boot.bin

y si la salida es parecida a esta:

Starting SeaBIOS (version 0.5.1-20100616_333654-volta)
 
Booting from Hard Disk...

Entonces sabremos que ha booteado con exito.

Lo próximo optimizar el bootstrap entrar en modo protegido y cargar un ejecutable a modo de Kernel

Espero que sigamos en el desarrollo del bootstrap.
Saludos

Al grano con todo esto:

1. Si quieren hacer el boot para un SO, nadie lo impidió ni lo impedirá, pueden hacer uno para este mismo sistema mientras aun soportamos GRUB.
2. Pensar en implementar un standard como POSIX NO es pensar en armar un LINUX, es simplemente soportar unos ciertos parámetros que nos permiten compilar cientos de aplicaciones para nuestro SO. Sin que esto haga que el kernel sea el mismo.
3. LINUX NO ES MONOLITICO. Lo fue hace muchos años, pero conceptualmente la carga de kernel modules no es un comportamiento monolítico.


gankutsuo: Si deseas más info, yo tengo un fragmento de boot que hace bastante más que eso y está documentado, si lo encuentro mañana a las 20 hs (argentina) te lo puedo mandar para que lo vayan viendo los que deseen ponerse con esta parte. Yo me apunto para ir haciendo el resto, paso del boot.


Khronos14: Me tome la libertad de ponerle 'Mythos' por ahora. En la documentacion hay un documento que explica porqué me parece flexible. Pensa en los nombres de las releases: 'mythos cracken', 'mythos thor', los aplicativos de gestion, etc... es flexible. Si te gusta lo dejamos así.

Hice un repo en GITHUB. Por ahora podemos arreglarnos mandandonos los parches por mail. Si te familiarizas con las branches de git, el format-patch y el 'git am' ya estamos. Yo se los enseñe a mis compas del trabajo en unos dias y lo usamos para los proyectos actuales.

Instalate GIT en tu linux y hacete un "git clone git://github.com/D4RIO/Mythos.git". Con eso ya te bajas el repo actualizado.
Create un branch desde donde está, vas tocando lo que queres y me pasas el parche que sacas con git format-patch, o el zip completo, y yo lo agrego.

No cambie los fuentes pero hice el makefile y puse soporte para mkisofs y genisoimage. Iremos metiendo mano.

Saludos, me voy a dormir.
Happy Hacking

Gankutsuo, si pones en Google Bootloader ASM tienes resultados e información para aburrir.
http://www.programmersheaven.com/download/42655/0/ZipView.aspx

Este Bootloader soporta FAT12, activa el modo protegido y carga un kernel en memoria.

xD4RIOx: me parece bien el nombre, al mediodía pruebo a instalar GIT y programaré un rato, ahora tengo clases.

Saludos.

Gracias xD4RIOx y Khronos 14, en realidad se cuanta información se encuentra en googe de esto, y todo lo documentado que está, los mil loaders a manera de ejemplo que andan por allí rondando y de los cuales se puede aprender mucho! La intención original del post era mostrar lo fácil que es un booteo e ASM lo interesante y pedagójico que es y lo bonito que es desarrolla uno propio, pero bueno, también entiendo sus puntos de vista y el porque quieren pasar del boot,así que estudiare un poco algunos ejemplos que tengo y los que me han pasado y sus diferentes métodos para lanzar el Kernel a ver si puedo salir con algo.

Saludos

hola

casualmente yo en la zona de programacion n general, pregunte sobre esto de los sistemas operativos, me gustaria saber si tambien me puedo incluirme aqui para hacer el proyecto Nitro OS, la pregunta en la otra zona es que no sabia por donde empezar, y no si se tambien pueda entrar aqui, llevo algunos años programando en C pero casi nunca lo hago en ASM, asi que no se si solo esten aceptando personas que ya sean profesionales en C y ASM

me gustaria participar porque he estado leyendo manuales de MINIX, ReactOS, descargue los codigos fuente pero no se por donde empezar a leer tanto codigo y los tutoriales dan referencia para que sirve todo, pero aqui ya vi un comienzo para mi

o van a documentar todo para seguirlos?, y mientras seguir investigando sobre MINIX y ReactOS, es que si me gustaria aprender pero bueno, espero pueda ayudar o puedan documentar todo para los que nos dio ganas de hacer esto

salu2

gankutsuo: Estoy en el trabajo, por eso no puedo pasarte el mio.

Te propongo clonar el proyecto mythos y crear un branch "mythboot-dev":

git clone git://github.com/D4RIO/Mythos.git
git checkout -b mythboot-dev

En este branch se puede ir haciendo el mythboot, el bootloader del sistema. De todas formas usamos GRUB y el stage2 eltorito para quemar imagenes de CD y probarlas, y siempre se dara la posibilidad de instalar con GRUB, como lo dan otros sistemas. El loader es, como dijimos, por puro hobbie de hacerlo (que me parece perfecto).

Ya esta hecho un grupo de google en:

  http://groups.google.com/group/mythos-devgroup (http://groups.google.com/group/mythos-devgroup)

Donde tienen el link (a la derecha) para solicitar la invitacion al grupo. Esto es para impedir que se suscriban esos bots infelices que nos amargan el desarrollo.

Supongo que entenderán que contemos con moderación de los cambios en la rama 'master'. Antes de que el codigo sea incluido debe estar bien formateado, correctamente identado, comentado, ser comprensible, estar documentado, etc, etc... según normas que definiremos entre todos.

Para enviar, proponer, rechazar o aceptar un parche se encuentra la lista, donde discutiremos y les daremos soporte sobre cómo hacer las cosas. Con el tiempo estabilizaremos flujos y costumbres y nos iremos haciendo camino al andar.

Saludos, los espero por la lista. Recuerden que el proyecto es de todos, todos lo hacemos posible, y es mi deseo que todos esten contentos con el desarrollo. No estaremos siempre de acuerdo en todo, pero nos las arreglaremos para construir.

PD: Cualquier duda sobre como trabajar de forma distribuida usando GIT me la preguntan, iremos armando documentos de referencia dentro del repositorio. Todos contaran con una mano de ayuda y todos daran una mano a quien puedan. Entre todos lograremos avanzar.


Belial & Grimoire:
Seras bienvenido, siempre hay algo en lo que se puede colaborar. El kernel en sí contara con algunas partes en ASM, pero siempre que sea posible, usaremos ANSI C. Lo que conozcas sirve, tus propuestas sirven y tus ideas se tendran en cuenta como las de todos.
La documentacion sera el fruto de las ganas de cada uno y espero que haya suficiente. Cualquiera tiene que ser capaz de entender cómo fuimos desarrollando Mythos, porque al fin y al cabo formara parte de la historia del OS.
Nos veremos, apuntate en la lista y clona el repo.

La idea orignal era (por que veo que la cambiaron) hacer un boot, un loader y un inicio de kernel. MONOLITICO, cortito, simple y sin implementaciones POSIX o soporte para ejecutables ELF, PE o lo que se les ocurra. Era una idea SIMPLE y BASICA, para que todos aprendan desde CERO.


Como dije antes, no iba a faltar quien diga que es otra distro mas, o que hagamos una distro... claro ejemplo es esto.

Cabe destacar que tanto Linux como Windows (NT) son MONOLITICOS hibridos y que la unica diferencia (a grandes rasgos) es que son monoliticos con la capacidad de cargar modulos. No obstante, NO ME INTERESA discutir esto, no vine a discutir sobre como esta hecho tal o cual sistema o a ver quien la tiene mas larga (quien escuche serrat entendera esto :P)


Esa es la idea basica y principal, y por la que cree el thread e invite a la comunidad, pero ha sido cambiada por dos personas.


Esto es simple, yo ya vi fracasar en este mismo foro un proyecto POR LAS MISMAS COSAS que estan discutiendo ahora y xD4RIOx lo sabe mejor que nadie....


Ya me sonaba conocido el nombre (http://foro.elhacker.net/programacion_general/creando_el_sistema_operativo-t175134.0.html;msg1126746#msg1126746).


Voy a ser concreto, si siguen con la pesima idea de GRUB, POSIX, y todas esas implementaciones que estan a AÑOS LUZ de, basicamente NADA, yo me abro de esto.


La idea no es usar GRUB, ni usar POSIX, es simplemente hacer un Boot Sector, luego un loader y un kernel, en ese orden, sin saltarse nada. Y otra parte fundamental de la idea es QUE SEA PESIMO, pero que sirva de aprendizaje para todos.

No se pretende soporte PE, ELF, posix, grub, nada de eso... para eso ya hay cosas hechas, a ver si lo entienden!.


Dejen de llevar la idea inicial, simple y basica para cualquier lado, saltarse etapas y complejizarla. Lean el primer post del thread y razonen. Si quieren GRUB y un kernel, retomen el "ReadyOS", proyecto que "destruyeron" con estas mismas ideas y dejaron en la nada.


xD4RIOx, vos esperas que tus mismas ideas, planteos y decisiones que NO FUNCIONARON en el otro proyecto lo hagan aca? ¿acaso no aprendiste nada?...


Bueno, si siguen en esta misma direccion, yo me voy ya que no era mi idea y ya vi lo que pasa con estas ideas, planteos y si se toma esta direccion.... nadie aprende nada y un puñado de personas que sabe un poco (solo un poco) mas que el resto toma el control del proyecto, cambian la idea principal, desvian la tematica, luego lo abandonan y todo queda en la nada.

Al que le interesa la idea SIMPLE y BASICA inicial, me avisa y vemos si hacemos algo partiendo de esa idea.

Saludos.

SerBice veo que mis palabras fueron malinterpretadas pero basicamente lo que trate de decir en solo un renglón es lo que tu has puesto aquí, yoestoy de acuerdo contigo y a tu proyecto me uno sin duda alguna, aunque mis conocimientos son bien escasos.

Dear SERBice:

Perdón la tardanza, vos querés aprender a hacer un boot y el inicio de un kernel monolítico, llamemosle idea A. Mis "ideas, planteos y decisiones" se resumen en que a mi no me importa tanto la parte del boot, sino el kernel en sí. Aplicar POSIX se resume en ir cumpliendo sus estándares conforme vamos haciendo cosa por cosa como se hace en un proyecto organizado. Si te copa la idea A entonces adelante, nadie te priva de ello, pero no hagas vanos intentos de decir que los proyectos anteriores fracasaron por mis ideas, eso es tonto desde el planteo.

El proyecto del Sistema quedó dormido nuevamente, no sin que yo haga todo el intento porque la gente proponga algo. El gran problema es que nadie propone nada, y cada uno planea tener su código, tocarlo, compilarlo, etc, sin tener en cuenta lo que ITIL llamaría la gestión de configuración, para lo cual sugerí GIT porque conozco sus flujos de trabajo y los uso siempre.

Si te quieres unir y hacer el boot, eres bienvenido, quiza resucitemos el proyecto. No veo porqué tanta molestia.

http://groups.google.com/group/mythos-devgroup

perdon por revivir este tema pero no se me vengan abajo con el proyecto que esta bastante bien....sino pueden iniciar en modo protegido tomen el codigo de mi kernel ...ami no me molesta q usen mi codigo para eso es opensource...pero gente  continuen con el proyecto...

el source de mi kernel esta en http://luxur.com.ar

es bien basico y facil de entender...hasta hice pdf para explicar todo sobre el kernel y cada linea del kernel esta comentada en español para su correcto entendimiento.

saludos.

tema muy interesante cuenta conmigo  ;D

Si piensan utilizar el shell bash me apunto a la creación de Scripts. Cuenten conmigo.

Hola:

En el código hubieras puesto el WriteLine de una vez.

/*
*	Nitro OS kernel
*
*/
 
#include "inc/types.h"
#include "inc/video.h"
 
void NitroOS (ULONG magic, ULONG addr)
{
	InitVgaMode();
	WriteLine("Kernel name: Nitro OS\n" +
        "Prueba de un Kernel cargado desde Grub para elhacker.net\n\n" +
	"Fdo: Khronos\n");
    for (;;);
}
 

Meta, el hilo está muerto, fíjate en las fechas.

En C no se pueden sumar cadenas de strings mediante + como otros lenguajes de alto nivel, por lo tanto tu corrección está mal hecha.

Saludos.

Gracias por los avisos. Me confundí con el C#, ;)