OSDev.org

Hi all,

This is just a quick pre-release announcement to tell you that the svn repo (go to www.tbos32.co.nr, click on "Source" and read the instructions) for Titanium Bonfire Operating System/32 is working and stable! As of r14, I've written (free of other source code, for those who have doubts) a simple vprintf() and printf() implementation and started switching the usage of sys.monitor.write() to printf().

The OS itself calls functions in an almost C++-like way. 01000101 came up with a way to abstract functions and easily swap them out for other ones via structs and function pointers. I liked the flexibility of the idea, so I use it as well.

Do a "make all" to compile and put on the floppy image, or "make qemu" to do that and launch qemu. There's a pre-made floppy image in the repo.

Have fun,
--Troy

Troy Martin wrote: The OS itself calls functions in an almost C++-like way. 01000101 came up with a way to abstract functions and easily swap them out for other ones via structs and function pointers. I liked the flexibility of the idea, so I use it as well.

Yo dawg. I herd u like funkshun pointurz, so I put some funkshun pointerz in ur funkshun strukz, so u can .... nevermind

If you are going to abuse function pointers like that, why not just use C++. The C programmers out there think your code looks fugly and hates OO, and the C++ programmers out there hate that you don't have other OO features such as inheritance...

you effectively put off everyone but yourself off that project...

Is there any real reason for using such a different and out-of-the-way method?

edit:

oh wait the idea of switching out function pointers on the fly does sound kinda neat.. not for what you use it for, but rather like for driver interfacing or something like that.. I think I already do that to an extent though lol

I originally implemented that style in ArcticOS (still is) as an experiment and because I liked the organization. I doubt there's really any big benefit to this method, but it makes my coding life a bit easier with it being laid out this way. My implementation is a bit different than TBOS32's but the generic x.y.z() is the same. I honestly don't want any flaming about it as it's A: not that important, and B: not really a "feature".

Anyways, gratz on getting it stable. Any other features than some printf functionality?

It's great and all having your own OS. I started on mine, and then came to the pragmatic reality that every line of assembler and almost every line of C has been written before me, and that I wasn't actually creating anything innovative. I now have some really neat ideas that quite thoroughly depart from a lot of conventional operating system theory. So far I haven't written a line of code, but I /am/ working on a thesis paper. I hope that TBOS, among all the other individual projects on OSDev all have great innovative ideas as well, and it looks like you've got a decent start.

*** Please accept the following as constructive criticism. I don't mean to offend. ***

When I first started with C a five and a half years ago, I thought this concept of 'struct-within-struct' was a great idea. I'd never seen C++ at that time, but by the time I'd got to know C++, I'd also learned that C is not an object oriented language and never will nor should be. The idea behind it is great from an organizational point of view but programmers are losing scope, in theory and in code.

C is not about objects. It can emulate them partially, but when you get right down to it, C 'objects' are the actual source code files themselves. Headers are interface details and each individual source code file is the implementation. That's partially what 'static' and 'extern' modifiers were for. Each C file has imported functions (via headers), internals (via 'static'), and exports. That way organizational code could be managed using UNIX file systems. (ala "#base/src/sub/obj.[ch]") Emulating objects using structures in C is just syntactic sugar that overall does not actually increase code readability but actually detracts from it. From your source code, in "common.c" ask yourself from an outsider's view:

• 1. Where is 'sys' declared?
  2. How much searching does it take to find the definition, and;
  3. Then again for the declaration?

Then apply those three questions to each sub-structure. When you break it down, it actually doesn't help developers or maintainers. The thing it does do however is increase is memory usage and add extra layers of abstraction into the code to be later confusing when it comes time for debugging. (Remember, the computer has no knowledge of what structs are, they are merely blocks of data smushed together. The assembly isn't neat.) This isn't to say that structures are bad at all, but just that overuse of them only hinders development. Use structs for tagged bits of data that should be kept together from a conceptual point of view, and more so, use function pointers where things actually need a proper abstraction layer, within a specific build architecture.

I agree. Why not just use C++ as apparently an object-oriented structure like that is what you want? I remember using C when I started out with OS development, but my first programming language was C++ and I kept thinking about using C++ in my OS. Eventually I switched to C++, had a lot of problems, switched back to C, and then when I knew a little more about OSDev, back to C++. The reason I switched was primarily because I was missing classes, inheritance, member functions and all that stuff. It's not necessary in any way, but it hell as is very useful and handy.

If I were you, I'd just take the C++ overhead and switch to it in the process, then code yourself a nice C++ class with nice member functions that interfaces with the hardware where needed . Although the function pointer way might come in handy somewhere, I doubt having loads of pointers like that is a good idea (unless you're planning on using it to use different kind of drivers, as someone else suggested before me).

I like C over C++, I don't know why. And I plan to be able to detect for certain features that I can use in optimization and shiz.

01000101 wrote:Anyways, gratz on getting it stable. Any other features than some printf functionality?

Thanks! I've implemented a basic RAMdisk and a few functions to handle reads and writes, but I think I should use an unsigned char* instead of void* to make access easier.

Troy Martin wrote:I like C over C++, I don't know why. And I plan to be able to detect for certain features that I can use in optimization and shiz.

01000101 wrote:Anyways, gratz on getting it stable. Any other features than some printf functionality?

Thanks! I've implemented a basic RAMdisk and a few functions to handle reads and writes, but I think I should use an unsigned char* instead of void* to make access easier.

Each function pointer is a pointer-word size. Add the levels of indirection, and the scoping problems, and you're gonna find it's nowhere near as easy and fast as you think it is.

syntropy wrote:Each function pointer is a pointer-word size. Add the levels of indirection, and the scoping problems, and you're gonna find it's nowhere near as easy and fast as you think it is.

I meant for the ramdisk pointer.

I think you're still missing the point that everyone is trying to make. You're trying to fit all that C++-style stuff into C, which is going to end up getting overcomplicated in the future.

I guess what we're trying to say is: If you want to use (/abuse) objects, why do it in a language that isn't object-oriented?

And,

but I think I should use an unsigned char* instead of void* to make access easier.

Have you ever heard of a cast?

pcmattman wrote:Have you ever heard of a cast?

Ye gods, yes, but just using an unsigned char* instead of a void* is way easier than them damn casts, will save time and confusion in the future..

And please, no more ranting about the fact E and I have taken an OO concept and placed it in C. It has its uses and downfalls. My opinion? Its uses outweigh its downfalls.

troy: i cant wait to see how you final wil look, i dont use protected mode, because my simple mind cant get it to work, so i figure i wil stay in pmode. good job on your os

pmode is protected mode unless you meant real mode?

Even though I think OO is kind of dumb in the first place (at least explicitly within a language), I think Troy may have a good idea. The point is not the object oriented-ness, but instead the fact that all system functions are addressed indirectly through a structure. That means you can change which function is called for any pointer in that "sys" structure at any point during the execution of the kernel. You don't have to have branches in basic functions that check to see whether paging is on or the heap is active etc... you just change the function that handles things, which is significantly faster (and nicer to the cache) than a branch. There may be problems when multithreading with having this much global state in the kernel though. I wouldn't call the idea OO, I would call it liberal use of function pointers, a pattern which has always served me well.

ehem... my idea

but, only if it's a compliment... It's TroyMartin's if it's being bashed.
btw, if you want to see my set up (with the original idea, as there are differences between TM's and mine), you can check out the OS project here. It's kind of an experimental OS project to try out newer ideas as I've beaten some of the older ones to death.