OMF kernel
Rod Pemberton
Anyone else using OMF objects for their OS kernel?
I'm linking two 32-bit objects together: a Multiboot header in NASM and a
test Multiboot kernel in C. One C compiler produces AOUT and COFF, no ELF,
while the other produces OMF. The header compiles for all formats. I've
got no problems with linking them as COFF+COFF and AOUT+COFF into a
Multiboot kernel since GNU LD produces raw binaries. (I'm using Chris
Giese's MBLOAD instead of GRUB or GRUB4DOS.)
But, the other C compiler I'm using produces (MS) OMF only. (I'm not going
to specify since I don't want that to cloud the issue.) I.e., I need to
link OMF+OMF into a kernel binary. This compiler produces a number
of executable formats including various Windows executables, a version of
ELF which seems to be corrupted, 32-bit DOS DPMI executables, and 16-bit DOS
.com's. If 16-bit DOS.com's are the closest thing to a binary, how do I
produce a 32-bit flat/raw/kernel binary? Or, what OMF linker produces
binaries or a format suitable for a kernel? Or, what Windows executable
format (PE, NE, LE, LX, etc.) is a good choice for linking two OMFs into a
kernel? PE? By "good choice" I mean minimal overhead and executable
headers small enough that the MB header will be always be below the 8k
requirement when linked. Or, should I use Agner Fog's OBJCONV to convert to
COFF and link with GNU LD? Or, should I just produce a DOS DPMI application
and unstub it with DOS32A's SB.exe unbind utility? My preference would be
to stay with the C compiler's toolchain and not introduce more utilities.
The MB header needs _end and _edata. AFAICT, the linker provides these
after/during linking. The OMF kernel is compiled using "DOSSEG" segment
ordering.
Lots of choices and feeling a bit lazy...
Rod Pemberton
Alexei A. Frounze
I don't use GRUB, I have my own stuff that loads 16-bit .COM/.EXE apps
which either contain 32-bit code somehow attached or load it.
Anyhow, I found DJGPP's COFFs to be the easiest to deal with. If you
can keep a working DOS box with DJGPP for development, it will be very
easy. The DJGPP's COFF headers of a fully relocated binary are pretty
simple. You don't need the DPMI stuff (stubs, and so on), although,
IIRC, it was useful for you for debugging purposes.
I sometimes combine 16-bit and 32-bit code in a very simple manner. I
compile the 16-bit code into a fully relocated binary and then INCBIN
it in NASM into 32-bit code or the other way around. I can choose
where to place things with ORGs, file ordering and LD linker scripts.
See my LFBemu -- 16-bit code was written with NASM, 32-bit with DJGPP
(gcc, ld) and NASM. The result is a .COM app that contains both 16-bit
and 32-bit code. No other special tools were used for this.
Alex
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:ga4l2f$tb1$1...@aioe.org...
>
> Anyone else using OMF objects for their OS kernel?
I'm using a somewhat modern C/C++ compiler that produces
PE Windows apps. I strip out all of the libraries, include
"special" labels in my code so that the linker doesn't
try to link in the FPU library, etc., and then I start my
code at:
int mainCRTStartup() {
Then I simply skip the first 0x400 bytes of the file and
the remaining PE is a binary image of my code, byte for byte.
Ben
Matt
> Anyone else using OMF objects for their OS kernel?
>
> I'm linking two 32-bit objects together: a Multiboot header in NASM and a
> test Multiboot kernel in C. One C compiler produces AOUT and COFF, no ELF,
> while the other produces OMF. The header compiles for all formats. I've
> got no problems with linking them as COFF+COFF and AOUT+COFF into a
> Multiboot kernel since GNU LD produces raw binaries. (I'm using Chris
> Giese's MBLOAD instead of GRUB or GRUB4DOS.)
>
> But, the other C compiler I'm using produces (MS) OMF only. (I'm not going
> to specify since I don't want that to cloud the issue.) I.e., I need to
> link OMF+OMF into a kernel binary. This compiler produces a number
> of executable formats including various Windows executables, a version of
> ELF which seems to be corrupted, 32-bit DOS DPMI executables, and 16-bit DOS
> produce a 32-bit flat/raw/kernel binary? Or, what OMF linker produces
> binaries or a format suitable for a kernel? Or, what Windows executable
> format (PE, NE, LE, LX, etc.) is a good choice for linking two OMFs into a
> kernel? PE? By "good choice" I mean minimal overhead and executable
> headers small enough that the MB header will be always be below the 8k
> requirement when linked. Or, should I use Agner Fog's OBJCONV to convert to
> COFF and link with GNU LD? Or, should I just produce a DOS DPMI application
> and unstub it with DOS32A's SB.exe unbind utility? My preference would be
> to stay with the C compiler's toolchain and not introduce more utilities.
>
> The MB header needs _end and _edata. AFAICT, the linker provides these
> after/during linking. The OMF kernel is compiled using "DOSSEG" segment
> ordering.
>
> Lots of choices and feeling a bit lazy...
>
>
> Rod Pemberton
I just link as an a.out, then I have a custom program that strips the
header and writes the raw flat binary to an image file for use.
I did cheat when it came to a couple of bits of the interrupt code,
where to simplify the linking process between my assembler code and my C
code, I converted the assembler to hex, and inserted it to the C code as
data, then do a copy/execute to install it. It allows me to patch the
assembler on the fly to alter addresses that it has to refer to that are
otherwise hidden from the assembler by the compiler.
Matt
Jeroen van Bemmel
From your posting it appears you are tied to this specific C compiler?
Why not use GCC on Cygwin? It produces PE-i386 by default, you can use
objcopy combined with ld scripts to produce a flat binary
Regards,
Jeroen
Rod Pemberton
news:ULGdnSwbFKIvLFvV...@bt.com...
> I did cheat when it came to a couple of bits of the interrupt code,
> where to simplify the linking process between my assembler code and my C
> code, I converted the assembler to hex, and inserted it to the C code as
> data, then do a copy/execute to install it.
"cheat"? Until now, I've been starting my OS by a DOS TSR... ;) If it
works, it works. It might be poor design, but if it's not causing any
problems...
My current "primary" compiler doesn't produce a modern format like ELF.
There is an experimental version available to do so, but it's incompatible
with my current code. The other one doesn't support much POSIX. So, it's
always the lowest common denominator of functionality...
RP
Rod Pemberton
news:S1mxk.1151$QA5...@fe107.usenetserver.com...
> int mainCRTStartup() {
>
> Then I simply skip the first 0x400 bytes of the file and
> the remaining PE is a binary image of my code, byte for byte.
>
Skip or strip? So, the PE header is only 0x400? If so, that's nice. (I'm
not upto date on PEs.) And, the initial instruction entry point is actually
at 0x400? Is that true of all PEs? Or, is that only for your compiler or
your combination of options?
RP
Rod Pemberton
news:0bfa1e48-df0a-411f...@a8g2000prf.googlegroups.com...
>
> I don't use GRUB, I have my own stuff that loads 16-bit .COM/.EXE apps
> which either contain 32-bit code somehow attached or load it.
I ran across a description of Solaris BEF the other day which uses DOS
.com's as real mode extended Int 13h BIOS device drivers:
http://developers.sun.com/solaris/developer/support/driver/wps/realmode/html/befif.html
Supposedly, this is for bootable devices not supported by one's BIOS, e.g.,
CD-ROM, network or SCSI. Obviously, it might be a bit out of date for
modern BIOSes. And, I don't know if they actually used this for Solaris or
not. Their code has some license terms.
And, I was thinking: "Well, if some of those drivers are available, they
might be retrofitted to work with FreeDOS, etc."
Anyway, the idea seems to fit with your tools...
> Anyhow, I found DJGPP's COFFs to be the easiest to deal with. If you
> can keep a working DOS box with DJGPP for development, it will be very
The DJGPP test app works, but I'd like the old OW compiler to work too... I
was hoping to find a format that is good for linking OMFs into a kernel.
I'll probably look some more into PE since I think it's likely to be around
longer than some of the other formats. Unstubbing a DPMI app. is a method
that fits with my DOS development tools but requires a tool not native to
that compiler.
I don't plan to support new OW, so maybe unstubbling is the way to go.
Although I originally decided to use both compilers, I think I've changed my
mind and decided to continue to use old OW just as a sanity check, C
compliance check, and non-POSIX code check of my C code until the core OS is
complete. I may eventually convert the OS to Linux or my compiler if I ever
complete that...
RP
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Skip. Infact, I use the first 0x400 bytes as a common data buffer
between my loader and my kernel. For instance, I load the kernel
to 0x00600000 (6 meg) including the 0x400 bytes the linker puts on
the first, then overwrite the first 0x400 bytes with data items
I have collected in the loader, before the loader jumps to
0x00600400.
It was tricky finding all of the parameters for the compiler,
since most are not well documented, but once I got all of them
I needed, it went well.
Also, you can only place int mainCRTStartup() in the main file
and it must be first in the list of files to compile and link.
You can not place any other procedure/function in that file.
All other code and data must be in a different set of files.
All other files must be in "folders" under the IDE. You can
not have another file in the "main trunk" that is alphabetically
lower than the name of the main file, the file where mainCRTStartup()
resides.
I guess I could easily read in the "start offset" from the PE
header before I overwrote it, but I just hardcode the offset
for now. A simple code addition and dword variable would
make it so that I didn't need so many restrictions as I
stated above.
Since this compiler comes with a decent IDE, I can simply
press F7 and it will make the kernel, loader, and all other
files, as well as create a 1.44meg floppy image all with a
press of the F7 key, all staying on the windows desktop.
Then Alt-Tab to Bochs, up arrow, enter, and Bochs is running
my newly built kernel.
I am sure you and others know which compiler I may be using,
but since it is not necessarily legal to create another OS
using this compiler, I won't mention it's name. As long
as I don't plan to distribute this OS for profit, I don't
think anyone is going to get to upset. If and when I do
release the source and all documentation, I will have to
compile it using GCC or something else for sure. However,
for my own personal enjoyment, this compiler is just fine.
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
Alexei A. Frounze
> "Alexei A. Frounze" <alexfrun...@gmail.com> wrote in messagenews:0bfa1e48-df0a-411f...@a8g2000prf.googlegroups.com...
>
>
>
> > I don't use GRUB, I have my own stuff that loads 16-bit .COM/.EXE apps
> > which either contain 32-bit code somehow attached or load it.
>
> I ran across a description of Solaris BEF the other day which uses DOS
>
> Supposedly, this is for bootable devices not supported by one's BIOS, e.g.,
> CD-ROM, network or SCSI. Obviously, it might be a bit out of date for
> modern BIOSes. And, I don't know if they actually used this for Solaris or
> not. Their code has some license terms.
>
> And, I was thinking: "Well, if some of those drivers are available, they
> might be retrofitted to work with FreeDOS, etc."
>
> Anyway, the idea seems to fit with your tools...
>
> > Anyhow, I found DJGPP's COFFs to be the easiest to deal with. If you
> > can keep a working DOS box with DJGPP for development, it will be very
>
> The DJGPP test app works, but I'd like the old OW compiler to work too... I
> was hoping to find a format that is good for linking OMFs into a kernel.
> I'll probably look some more into PE since I think it's likely to be around
> longer than some of the other formats. Unstubbing a DPMI app. is a method
> that fits with my DOS development tools but requires a tool not native to
> that compiler.
>
> I don't plan to support new OW, so maybe unstubbling is the way to go.
> Although I originally decided to use both compilers, I think I've changed my
> mind and decided to continue to use old OW just as a sanity check, C
> compliance check, and non-POSIX code check of my C code until the core OS is
> complete. I may eventually convert the OS to Linux or my compiler if I ever
> complete that...
>
> RP
You can unstub OW's executables (or specify your own stub if needed).
The result (at least for 32-bit DOS target) is an LE-format
executable. That's an OS/2 / VXD format. You'll need to work with
that.
I also see that OW (1.7) supports ELF, which GRUB supports directly.
Have you tried ELF?
I think, unless there're some serious bugs lurking around, OW is
pretty good for OS dev since it comes with everything you need (wasm,
wlink, 16/32-bit wcc/wpp, etc).
Alex
Rod Pemberton
> I also see that OW (1.7) supports ELF, which GRUB supports directly.
> Have you tried ELF?
Yes, for OW 1.3, which seems to have some problems with ELF. Or, maybe it's
a problem Chris Giese's MBLOAD loader... I'm not sure. I haven't tried an
OW 1.3 ELF against GRUB4DOS or GRUB. I decided that ELF was a good choice
because it's likely wherever my OS ends up that the ELF format won't be an
option. But, the a.out options of Multiboot are useable by any kernel. The
a.out options are the extra address fields indicated by bit 16 of the MB
flags. So, even though OW can produce ELF and Multiboot is supposed load
ELF, I'd prefer to keep the format independent and keep the code base
identical. I may still play around with it bit though. :)
> I think, unless there're some serious bugs lurking around, OW is
> pretty good for OS dev since it comes with everything you need (wasm,
> wlink, 16/32-bit wcc/wpp, etc).
I've searched their newsgroups to see how others managed to produce OS
kernels. There's not much info. That usually means it's so blatantly
obvious to everyone else how to do it that no one is asking or stating how
to do so... :) Or, no one is doing it. I probably need to learn more about
their build tools.
Rod Pemberton
Wolfgang Kern
Rod Pemberton said:
...
> I've searched their newsgroups to see how others managed to produce OS
> kernels. There's not much info. That usually means it's so blatantly
> obvious to everyone else how to do it that no one is asking or stating how
> to do so... :) Or, no one is doing it. I probably need to learn more
> about their build tools.
Sure, but my own system wont rely on any foreign tools and except
for DEMOs (they need DOS6.00 to install) there is nothing in common
with either FAT/L'unix/NT filesystems in my OS-install routines.
It may create a new partition wherever it finds free space and may
also override BIOS-settings by using my own boot-loader in a primary
partition.
__
wolfgang
alex
> Sure, but my own system wont rely on any foreign tools and except
> for DEMOs (they need DOS6.00 to install) there is nothing in common
> with either FAT/L'unix/NT filesystems in my OS-install routines.
> It may create a new partition wherever it finds free space and may
> also override BIOS-settings by using my own boot-loader in a primary
> partition.
>
> __
> wolfgang
>
>
yep
Marven Lee
> Alexei A. Frounze wrote:
>> I think, unless there're some serious bugs lurking around, OW is
>> pretty good for OS dev since it comes with everything you need (wasm,
>> wlink, 16/32-bit wcc/wpp, etc).
>
> I've searched their newsgroups to see how others managed to produce OS
> kernels. There's not much info. That usually means it's so blatantly
> obvious to everyone else how to do it that no one is asking or
> stating how to do so... :) Or, no one is doing it. I probably need
> to learn more about their build tools.
I use an ELF cross-compiler on Cygwin to build my kernel.
I created an i386-kielder-elf target by modifying the config files
of gcc and binutils. I looked at what other OSes did in the
config files, say BeOS, QNX or RTEMS and added my own
entries for Kielder.
I created several patches for GCC, Binutils and Newlib
along with a shell script to apply these patches then builds
a cross-compiler.
Look at the kielderdev.tar.bz2 file on my Kielder OS webpage.
http://web.bethere.co.uk/kielder/osdev.html
It has the patches and script. It also patches and builds
ports of GNU Coreutils, Less, and PD-KSH for my OS.
You could look through the patches to see what files
I altered, looking for "diff -urN" lines to see what files I modified,
then do a search for the word "kielder" in those files.
I suppose you could do...
grep "diff -urN" patchname
To list the files I modified.
You could also look at the kernel source to see what my
initialization code and kernel linker script looks like...
kernel/i386/asm/entry.S
kernel/i386/init/main.c
kernel/i386/kernel.ls
You could look at the osdev.org wiki, it has a section
that covers making a cross compiler which is more
or less the same as what I do.
http://wiki.osdev.org/GCC_Cross-Compiler
--
Marv
hitlar...@gmail.com
Rod Pemberton
>> Look at the kielderdev.tar.bz2 file on my Kielder OS webpage.
>>
>> http://web.bethere.co.uk/kielder/osdev.html
>>
>
>
Web Archiv's WayBack Machine didn't archive Marvin's source:
http://web.archive.org/web/20080930121341/http://web.bethere.co.uk/kielder/osdev.html
There is this webpage which has his source:
http://www.cod5.org/archive/k/kielder.html
Note that the code has been repackaged and could be modified.
I wasn't able to locate another source for his code on the internet.
I don't have a copy of his code in my OS collection.
We haven't seen a post from Marvin in a few years.
Rod Pemberton
--
Scientists now say we'll experience a mini-ice in 2030.
So, I guess we need more global warming today ...