On Sat, 8 Jan 2005 04:09:17 -0600, "Jon Slaughter"
<nobody@nowhere.com> wrote:
[color=blue]
><I previously posted this in comp.os.misc, but no one answered and its been
>3 days... actually no one has posted any messages at all(atleast they are
>not showing up), so, while it might not be completely on-topic, and I know
>how this news group is very bitchy about off topic messages, it is
>none-the-less close enough(IMO)>[/color]
Perhaps one of the embedded systems groups would be appropriate -- ??
[color=blue]
>is there a C++ out there that I can use to build code for the intel
>architecture that is non-os specific. By that, I mean where I can create
>binaries that work without an os? I'm working on a small os and I'd like to
>develop some utilities and I'd rather not write them in assembly at this
>point(eventually I will have to in some for or another, but). Basicaly I
>just need memory management and BIOS disk access. That is, I need some way
>to allocate memory in an organized way and some way to "open" "files"(though
>I can actually code the routines to use int 13h myself, it would be nice if
>this has already been done(where I can specific the sectors that contain the
>file).[/color]
Well, you seem to assume that at least the BIOS is available... At the
very least, you will need to write some assembler code which
bootstraps your code from the disk. Take a look at the Linux LILO or
grub, for example.
[color=blue]
>Some things that would be nice: If it used flat memory model(not necessary
>but would be nice to have access to more than a meg). If it could load files
>on a sector basis istead of a filename basis. If the binary could be built
>for windows and non-os with little modification(so I could test it on my VM
>hard drive).[/color]
You want "Windows(R) AND non-OS"? That's a pretty tall order...
[color=blue]
>For the file stuff, to be clear, it would be nice for something like
>
>#ifdef non_os
>fstream somefile(drive, sector start, sector end, ios::write)
>#else
>fstream somefile(VM filename, start, end, ios::write)
>#endif
>
>then to write the buf to the disk
>
>somefile.write(buf, size)
>
>or something like that.
>
>
>Just wondering if there is anything out there that can do something like
>this. I suppose I could write the code myself, but then I might as well
>just do it in assembly.
>[/color]
In theory, C++ is a platform-independent language. That means that you
can write the same correct C++ code and expect it to compile and build
on all standards-conforming platforms.
In practice, all the C++ implementations I have seen rely mostly on
the C runtime libraries. And all the C runtime library implementations
I have seen (actually only 4...Borland, Microsoft, GCC and
Dinkumware's cross-platform source libraries) rely heavily on the
operating system for opening files, allocating memory, etc.
So what one usually does is, for example, "Hey, I need to open a file
here for reading" and writes std::ifstream(...) without giving a
second thought as to *how* streams are implemented on the platform at
hand. Your OS-specific stuff should all be in a different layer, most
likely buried deep within the implementation of the particular C (not
C++) runtime library you are using.
Now there are many OS which have been developed with C (Windows and
Linux, for example, since you have already limited yourself to the
Intel platform(s) [presumably the 32-bit x86 architecture? There are
other Intel processors, you know...]). I don't know of any OS which
used C++ ... I remember reading that Linus Torvalds actually tried it
for Linux once, but found it just too painful and went back to C ...
besides, this was in the "dark ages" of C++ where there were no
templates, etc.) So it can be done. The question is more one of design
IMHO.
And at some point, you will have to interface with the hardware ...
after all, that is what an OS does, isn't it? So the question is, do
you want to sprinkle your code with hardware-specific stuff using
#ifdef's, or do you want to abstract the hardware layer? Obviously,
you need some kind of abstraction because unless you are 100% sure
that your code will never have to run on any other platform besides
the one you develop it for (e.g. custom-built hardware for the
military), you will need to abstract it to a large degree. And because
C++ *is* platform-independent, there are no C++ standard functions for
implementing hardware interrupt handlers, device I/O, etc.
There are C++ compilers (such as Intel, Comeau) which generate C code
to be parsed by a backend C compiler. This means that you can compile
the same source code on either Linux or Windows (since both compilers
mentioned support these OS) depending on which version you target, and
thus be platform-independent. In addition, both of these compilers are
very standards-conforming. You might be able to find some compiler for
embedded systems which could prove to be more useful.
The GCC compiler has been ported to several different platforms, for
example. And you have the advantage of it being open source. What you
need to do (IMHO) is to download the GCC source and examine as many
different implementations of it as might be of interest to you (as you
can find), then adapt it for your purposes. Be aware of the licensing
issues, though (GPL).
--
Bob Hairgrove
NoSpamPlease@Home.com 
non-specific os C++ building 
