Quote of the day.
Mike Gonta
http://forum.osdev.org/viewtopic.php?p=191348#p191348
"aeBIOS is a project that tries to make all the broken ugly mess
from the 1970's "real mode BIOS" available in protected mode,
so it's easy to make broken and ugly protected mode software
(rather than broken and ugly real mode software)... :)"
Mike Gonta
look and see - many look but few see
Mike Gonta
http://kerneltrap.org/node/6884
Not that I'd ever claim that the BIOS is wonderful either, but at least
everybody knows that the BIOS is just a bootloader, and doesn't try to
make it anything else.
The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient
and obviously oldfashioned, that you have to be crazy to want to do
anything serious in it. Real mode, 16-bit code is actually an _advantage_
in that sense. People know how to treat it, and don't get any ideas about
it being some grandiose framework for anything else than "just load the OS
and get the hell out of there".
Rod Pemberton
news:irjpd4$hg1$1...@speranza.aioe.org...
>
> Linus Torvalds wrote:
> http://kerneltrap.org/node/6884
> Not that I'd ever claim that the BIOS is wonderful either, but at least
> everybody knows that the BIOS is just a bootloader, and doesn't try to
> make it anything else.
> The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient
> and obviously oldfashioned, that you have to be crazy to want to do
> anything serious in it. Real mode, 16-bit code is actually an _advantage_
> in that sense. People know how to treat it, and don't get any ideas about
> it being some grandiose framework for anything else than "just load the OS
> and get the hell out of there".
>
Yup. He's clueless...
Does he know (x86) DOS exists?
Does he know DOS was wildly successful?
Does he know DOS was built on top of BIOS calls?
Is he aware of how useful DOS is?
C compilers galore.
x86 assemblers galore.
Programming utilities galore.
No real OS impedements to interfere with development of raw OS code.
Three (3) DOS files. Bam! Install or run Linux from anything...
etc.
Rod Pemberton
PS. I'm not sure what to make of your PE "thingy." I'm not sure what it's
purpose is. So, I didn't comment. I don't think I use PEs, except if they
are already part of programs written by other people... I looked at it,
but I'm not seeing it. So, I guess you'll have to explain it to me...
Mike Gonta
> "Mike Gonta" wrote in message
>>
>> Linus Torvalds wrote:
>> http://kerneltrap.org/node/6884
>> Not that I'd ever claim that the BIOS is wonderful either, but at least
>> everybody knows that the BIOS is just a bootloader, and doesn't try to
>> make it anything else.
>> The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient
>> and obviously oldfashioned, that you have to be crazy to want to do
>> anything serious in it. Real mode, 16-bit code is actually an _advantage_
>> in that sense. People know how to treat it, and don't get any ideas about
>> it being some grandiose framework for anything else than "just load the
>> OS
>> and get the hell out of there".
>>
>
> Yup. He's clueless...
Just part of his criticism of EFI.
>
> Does he know (x86) DOS exists?
> Does he know DOS was wildly successful?
> Does he know DOS was built on top of BIOS calls?
> Is he aware of how useful DOS is?
>
> C compilers galore.
> x86 assemblers galore.
> Programming utilities galore.
> No real OS impedements to interfere with development of raw OS code.
I'm working on a stripped down minimal Atomic Embedded DOS (aeDOS)
which will run on top of aeBIOS.
Atomic in the sense that there will be no OS state, merely like
extended BIOS functions (32 bit PM of course).
Embedded in the sense that the functions will be available to the
loaded PM32 boot sector/kernel files the same as BIOS calls.
Mike Gonta
> purpose is. So, I didn't comment. I don't think I use PEs, except if
> they
> are already part of programs written by other people... I looked at it,
> but I'm not seeing it. So, I guess you'll have to explain it to me...
The PE file is easy to create (at least with FASM it is, NASM can produce a
COFF which has to be linked. A simple utility could convert a COFF.
The end result is a headerless flat binary file followed by a PE relocation
table followed by a simple footer. Given the size of the file the loader can
easily determine if the binary is loaded to an address other than the
preferred
address and do the fixups.
1. After conversion it is no longer a PE.
2. Can be used as a simple flat binary file.
3. Can be loaded to it's final location and fixed up (if needed) in place.
http://board.flatassembler.net/topic.php?t=12896
Rod Pemberton
>
> The PE file is easy to create (at least with FASM it is, NASM can produce
a
> COFF which has to be linked. A simple utility could convert a COFF.
> The end result is a headerless flat binary file followed by a PE
relocation
> table followed by a simple footer. Given the size of the file the loader
can
> easily determine if the binary is loaded to an address other than the
> preferred address and do the fixups.
>
> 1. After conversion it is no longer a PE.
> 2. Can be used as a simple flat binary file.
> 3. Can be loaded to it's final location and fixed up (if needed) in place.
>
Sorry, it seems we discussed this a while back where I apparently had a
clearer picture of what you were doing.
What are you using to load it? reloc it?
In the other thread, I mentioned some ways and loaders for them. Was there
something better about this way?
http://groups.google.com/group/alt.os.development/msg/442d25018cda7818
Rod Pemberton
Rod Pemberton
>
> I'm working on a stripped down minimal
> Atomic Embedded DOS (aeDOS)
> which will run on top of aeBIOS.
>
32-bit? Cool...
It is just a command line, or is it trying to become a real DOS?
Next, if you add in a 32-bit minimal BIOS, you'll have OS (almost) entirely
in 32-bit.
ISTM, FreeDOS-32 project stalled.
http://freedos-32.sourceforge.net/
Rod Pemberton
Mike Gonta
> "Mike Gonta" wrote in message
>>
>> Atomic Embedded DOS (aeDOS)
>> which will run on top of aeBIOS.
>>
>
> 32-bit? Cool...
Of course.
> It is just a command line,
It is just helper functions.
> or is it trying to become a real DOS?
A real DOS can be built on top.
> Next, if you add in a 32-bit minimal BIOS, you'll have OS (almost)
> entirely
> in 32-bit.
aeBIOS will soon have the ability to load an "option" file which can
hook and replace various BIOS functions with PM32 replacements.
This will happen before aeBIOS loads the user supplied PM32 boot sector.
This will be part of a test and develop stage which will eventually
replace the hardware independent and generic hardware functions.
> ISTM, FreeDOS-32 project stalled.
> http://freedos-32.sourceforge.net/
Some encouragement here:
http://sourceforge.net/userapps/wordpress/jhall1/2011/05/02/the-future-of-freedos/
Mike Gonta
>>
>> a COFF which has to be linked. A simple utility could convert a COFF.
>> The end result is a headerless flat binary file followed by a PE
>> relocation table followed by a simple footer. Given the size of the
>> file the loader can easily determine if the binary is loaded to an
>> address other than the preferred address and do the fixups.
>>
>> 1. After conversion it is no longer a PE.
>> 2. Can be used as a simple flat binary file.
>> 3. Can be loaded to it's final location and fixed up (if needed) in
>> place.
>>
>
> Sorry, it seems we discussed this a while back where I apparently had a
> clearer picture of what you were doing.
>
> What are you using to load it?
The main point is that it is a simple headerless binary file, just load and
go.
> reloc it?
I haven't got that far, I'm just using it for now as a simple bin file.
No relocations, just load and go.
> In the other thread, I mentioned some ways and loaders for them. Was
> there
> something better about this way?
> http://groups.google.com/group/alt.os.development/msg/442d25018cda7818
Nothing special, it's just very easy to produce with FASM, no utility
required.
I've also added a simple checksum to the "footer" to verify that it is
indeed
a relocatable binary format (.rbf extension maybe)?
http://board.flatassembler.net/topic.php?p=129559#129559
Rod Pemberton
>
> > ISTM, FreeDOS-32 project stalled.
> > http://freedos-32.sourceforge.net/
>
> Some encouragement here:
>
http://sourceforge.net/userapps/wordpress/jhall1/2011/05/02/the-future-of-freedos/
>
FreeDOS is 16-bit. It's doing just fine.
FreeDOS-32 is 32-bit. It's different. It's stalled.
RP
Mike Gonta
> "Mike Gonta"wrote in message
>>
>> > http://freedos-32.sourceforge.net/
>>
>> Some encouragement here:
>>
> http://sourceforge.net/userapps/wordpress/jhall1/2011/05/02/the-future-of-freedos/
>>
>
> FreeDOS is 16-bit. It's doing just fine.
If all the Jim Hall talk about a "Modern DOS", USB, networking, GUI and
mutitasking
is going to attract new 16 bit real mode developers - it certainly is!
> FreeDOS-32 is 32-bit. It's different. It's stalled.
It's using FreeDOS as a base with a DOS extender - not that much different.
The goal is probably to get to 32 bit protected mode and that's probably
why it's stalled.
hopcode
> "Rod Pemberton" wrote in message
>> > "Mike Gonta" wrote in message
>>> >>
>>> >> I'm working on a stripped down minimal
>>> >> Atomic Embedded DOS (aeDOS)
>>> >> which will run on top of aeBIOS.
>>> >>
>> >
>> > 32-bit? Cool...
> Of course.
>
i am sure You have heard about baremetal; it is a
very promising OS ( http://www.returninfinity.com/baremetal.html )
even if in a starting stage yet.
Also, why not 64bit aeDOS ?
Cheerz,
--
.:hopcode[marc:rainer:kranz]:.
x64 Assembly Lab
http://sites.google.com/site/x64lab
Mike Gonta
> Mike Gonta ha scritto:
>> "Rod Pemberton" wrote in message
>>> > "Mike Gonta" wrote in message
>>>> >>
>>>> >> I'm working on a stripped down minimal
>>>> >> Atomic Embedded DOS (aeDOS)
>>>> >> which will run on top of aeBIOS.
>>>> >>
>>> >
>>> > 32-bit? Cool...
>> Of course.
> Also, why not 64bit aeDOS ?
That will have to wait for 64 bit aeBIOS, which I have future plans for.
Rod Pemberton
> "Rod Pemberton" wrote in message
> > "Mike Gonta"wrote in message
> >>
>
> It's using FreeDOS as a base with a DOS extender
>
Huh? Well, I was running it from MS-DOS... There does appear to be FreeDOS
in their bootdisk directory. Although I started it from DOS, I was thinking
it was startable on it's own... It has it's own loader for DOS startup:
x.exe, so maybe it's using an DOS extender too. I didn't look to deep. I
saw that some stuff worked and other stuff wasn't. Then, their project
stalled.
IIRC, it's compiled C or C++. IIRC, I started it from a .bat. x.exe would
load various .o driver modules and then the app.o. E.g., drivers: dpmi.o,
clock.o, etc. So, I think they're were a bit past PM startup. Their demo
app's worked. It seems I've deleted the .o's, so I'd have to rebuild to
check.
Once you're in PM, you can remove DOS, VCPI, or DPMI (as I do for my stalled
OS...), etc.
Rod Pemberton