SoloCodigo

Ademas debes tener en cuenta que no solo se depende del sistema operativo,
puedes crear u programa en assembler que solo funcione en algunos tipos de pentium 4 y en otros no...
adicionalmente maquinas con arquitetura diferente tampoco correrian tu programa, por ejemplo una maquina que use procesadores RISC generalmente no ejecutaria un programa hecho para un 8086... esto tambien implica que hay sistemas operativos que solo corren en un tipo determinado de maquina como ( por el momento) los Apple.

Sin lugar a dudas un apunte correcto, practicamente cada arquitectura tiene sus instrucciones y codigo binario propio.

Programar en assembler siempre produce código mucho mas rápido, como lo dice eternal depende en gran parte del programador, pero tienes desventajas en ese sentido ya que el código muchas veces nisiquiera es portable de una maquina a otra aunque sean de la misma familia, cosa que con un lenguaje de mas alto nivel no sucede pues el compilador o la maquina virtual o como se llame en punto net el JIT del  MSIL o lo que sea... se encarga de producir código de alta calidad de acuerdo a las caracteristicas propias de la maquina y/o del sistema operativo.

En este punto creo que se podria decir que el asm mas 'portable' hoy en dia seria el bytecode que se ejecuta para la maquina virtual de java.. pero tambien resulta ser falso ya que mauina virtual es una sola aunque este instalada en maquinas diferentes 

Yo no dije eso en ningun momento, no hable sobre la velocidad del codigo. En ese aspecto es incluso mucho mas dificil ganarle al compilador y se necesitan muchos mas conocimientos. No es lo mismo optimizar para tamaño que optimizar para velocidad.

Y si, .NET y Java son muy portables, mientras esten sus respectivos 'ayudantes' instalados  

PD. El lenguaje es assembly, assembler es el programa que ensambla.

Je-Ni-Al!
Gracias, esta
Lo siento por lo de compilar, tienes razon es ensamblar.
Bueno, entonses es pocible ensamblar un programa en x OS y correrlo en otro OS totalmente diferente?
Tiene que ser directo al BIOS?
Ha, si, los codigos ensamblados son mas pequeños que los de c, c++, cobolt...?
Grasias una vez mas.
 

En la practica no es posible porque, como te comentaba antes, los Sistemas Operativos suelen tener un formato de ejecutable propio. Sin tener en cuenta que la BIOS solo es accesible directamente en S.O. de 16 bits (MS-DOS) y no en S.O. de 32 bits como Windows o Linux.
Por lo tanto no es posible hacer siquiera un programa que solo haga ret ya que no es reconocido como un ejecutable por los dos S.O. al mismo tiempo.

Si lo podrias hacer para CP/M y MS-DOS (el segundo esta MUY basado en el primero) con un ejecutable COM que justamente no tiene cabecera.

Olvidandonos del formato que seria solo un problema del binario y no del codigo el verdadero inconveniente es la interfaz de los servicios que hace imposible portar un programa hecho en assembly de un S.O. a otro.

En general al carecer de libreria de run time (rutinas de IO, cadenas, etc) el programa de assembly suele ser mas chico por menos codigo. El tamaño de las rutinas existentes en ambos binarios ya depende de la calidad del programador vs la calidad del compilador  

Esa libreria (OPENGL32) solo funciona en XP porque tiene importada la funcion IsWow64Process cuyos requisitos son:

Requirements
Client: Requires Windows XP.
Server: Requires Windows Server 2003.
Header: Declared in Winbase.h; include Windows.h.
Library: Use Kernel32.lib.

Intenta conseguir una version un poco mas compatible.  

Esta bien el programilla.

¿Seguro que viene con Visual C++ 6.0?

No me suena mucho el nombre.¿Que viene en el menu de herramientas o a parte?

Si, no viene con el .NET 2003 pero si con el 6.0, esta en la carpeta tools (no tengo instalado el 6.0 aca).

 

El Dependency Walker te permite ver las librerias de las cuales depende (estaticamente) un ejecutable, viene con VC++ 6 y tambien lo podes bajar de aca:

http://www.dependencywalker.com/

     

hola, gracias por la ayuda, ya se como escribir en el sector 0, averigue sobre una rutina de C llamada biosdisk y hare uso de ella, pero, ahora descubri que lo que debo escribir no es ni un exe ni un com (o almenos eso entiendo), sino un .bin el cual no se como generar con tasm, y ademas el codigo que he hecho no compila asi no mas creo que es porque no tiene la estructura normal de un programa corriente de ensamblador por lo que entiendo que debo traducir directamente a unos y ceros pero no se como, gracias

Por partes:

biosdisk no es de C, es de un compilador de Borland, NO TE RECOMIENDO que uses eso sino alguna de las alternativas descriptas arriba, son las maneras correctas de hacerlo.

exe no podes usar porque tiene cabecera y el codigo del boot sector tiene que ser eso simplemente codigo. COM podes usar tranquilamente al ser un formato sin cabeceras, codigo puro. BIN es simplemente codigo en hexadecimal, no existe nada que sea binario en archivos, la minima unidad de datos es el byte, despues el micro (creo) lo interpretara en binario.
En resumen si haces un .COM con su org a 07C00h lo podes usar en el primer sector del diskette.

Era mucho mas simple como venias haciendolo (sin archivo de definiciones). Por cierto WINAPI es una macro que esta definida jutsamente a __stdcall, con lo cual pusiste lo que te dije extern "C" y __stdcall pero sacaste algo que ya usabas antes (dllexport).

   

Yo lo sigo viendo en retos    

Hola a todos, saben hace ya algun tiempo tengo una libreria vesa, y de hecho corre bien en sistemas operativos que no tengan tecnologia nt(como XP), precisamente juank menciono que no corren el este tipo de sistemas operativos, pero he descubierto que en algunos computadores si corren mientras tanto en otros no, y quisiera saber por que es capaz de correr en algunas computadoras si, es mas por que en una misma computadora con XP, en ocasiones corre y en otras ocasiones, ya con un sistema nuevo pero al fin al cabo XP no.

XP es 100% NT.

una pregunta?

vamos a usar las funciones de la BIOS donde se pueda? o vamos a programar todo?

me parece a mi que en un inicio la parte de teclado pantalla y diskette se lo dejemos a la bios que muy bien lo hace    y cuando tengamos algo consistente empecemos a reemplazar ese codigo on el nuestro.

estoy de acuerdo con el tema de los modulos

BIOS sin dudas, mas rapido y mas seguro (años de desarrollo tienen sobre sus espaldas) y mas compatible    

Si, concuerdo con Bob, seria mejor solo usar herramientas de terceros para construir el S.O. y que sea todo el codigo hecho por nosotros.

Doy mi voto para FASM y les propongo un par de cositas para un futuro no tan lejano, esto se podria leer reemplazando FAT12 por _nuestro_file_system como decia Bob:

_El OS ya que va en diskette podria soportar FAT12

_El loader obviamente se escribiria en el primer sector pero segun el formato de FAT12 (que empieza con un jmp al codigo del loader y sigue con campos indicativos)

http://www.mega-tokyo.com/osfaq2/index.php/FAT12%20document

_El Kernel (un solo archivo de codigo finalmente) podria escribirse en el diskette con un copy paste desde Windows o un copy desde MS-DOS

Modulitos:

loader: se encargaria de leer el disquette en busca del kernel, podria usar un nombre fijo siempre, podria complementar eso con la espera de una tecla como F5 para permitir elegir el nombre, todas las ideas que se nos ocurran y podamos implementar. Seria un modulo de codigo separado.

kernel: se encargaria entre otras cosas de establecer las interrupciones que proveera el S.O. (sus servicios) que inicialmente serian init_app y exit_app. Seria un modulo de codigo separado con otro submodulos que en este caso serian archivos en realidad.

Dentro del Kernel podriamos tener (y serviria para distribuir tareas):

Keyboard: encargado de entrada y salida por teclado
Shell: encargado de la interfaz (con sus comandos como ls/dir, info del sistema y de iniciar el proceso de ejecucion de otros programas)
FileSystem: encargado de todo lo relacionado con el FileSystem, enumeracion de directorios/archivos, lectura de los mismos y eventualmente escritura
Utils: encargado de cosas como strings
Video: encargado de salida grafica (mas adelante)

Bueno, me voy unos dias de vacaciones asi que les dejo un par de cosas para que las vayan pensando y comenten lo que les parece      

Como comentaba en el otro foro creo que no se puede hacer (legalmente) un Sistema Operativo con MASM con lo cual queda excluido, habria que decidir entre FASM y NASM como bien decis.

En cuanto al primer objetivo me parece correcto y en sintonia con todos tus mensajes. Primero intentemos hacer algo que podamos hacer y no pensemos hacer un Windows/Linux que es una utopia.

Un nanoDOS no estaria mal para empezar, podriamos delinear un par de modulos asi todos pueden contribuir.