Otra vez al ruedo: ¿hacer un SO?

[Khronos14]

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.

[SERBice]

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:

Uno por cada sistema de archivos, en principio:

• FAT12
• FAT16
• FAT32

Loader:

Programa reducido que logre:

• Pasar a modo protegido
• Esto es tema pendiente a debatir: GDT e IDT ¿en el loader o en el kernel?
• Debe ser capaz de cargar un archivo en memoria (el kernel), en lo posible de gran tamaño y luego pasarle el puntero para su ejecucion. Para hacer esto, el loader debe ser capaz de identificar el sistema de archivos desde el que se cargo, luego de detectar el sistema de archivos del que fue lanzado, debe buscar, encontrar y leer el kernel para hacer lo qeu dije antes.

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.

[anonimo12121]

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

[mr.blood]

Podeis fijaros y tomar ideas de Luxur.

http://luxur.comoj.com/

Me parece una idea genial .

Sa1uDoS

[D4RIO]

Creo que me malinterpretaron algo:

Lo único que podríamos "copiar" de GNU/Linux sería la shell bash o algún driver en concreto.

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

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

[Khronos14]

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.

[D4RIO]

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:

Código (c) [Seleccionar] Expandir

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.

[Khronos14]

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  . 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.

[D4RIO]

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

[Anay]

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.