OSDev.org

Brendan: I've been following your writing and OS development for a while. It's one of the best thought out and developed visions I've seen. Good job!

On a side note, a while ago I tried some of the OS'es under development including BCOS and I think it either hanged or rebooted both of the machines I tested it on. Is that something that can help you with compatability testing? (as in, if that still happens in the recent version of your OS do you want to find out what the problem is?)

No chance for such a thing. There's gonna be more talking and less walking as Solar has stated once, so, thanks, I stay with my own project - with which I've got enough to do btw.

stay safe

beyond infinity wrote: There's gonna be more talking and less walking as Solar has stated once...

And believe me, I've been there, done that. Fed two years of my spare time into it, with very little to show for it. :-[

IMHO, you shouldn't look for help with your OS before you have the core system up and running, setting a solid base of "previous art" / "decided matters". Top-down management doesn't work for OS design.

Wow very well thought out proposal. I personally think things like this are doomed but I'm not here to put anyone's ideas down so if you guys can gain some momentum I'll be glad to help in any way I can.

Hi,

Rob wrote:Brendan: I've been following your writing and OS development for a while. It's one of the best thought out and developed visions I've seen. Good job!

I'm honoured - flattery is rare

Rob wrote:On a side note, a while ago I tried some of the OS'es under development including BCOS and I think it either hanged or rebooted both of the machines I tested it on. Is that something that can help you with compatability testing? (as in, if that still happens in the recent version of your OS do you want to find out what the problem is?)

The previous release was actually meant to lock-up after displaying a list of detected devices. In my haste I didn't add anything (no status message, etc) to indicate that this was as far as it was meant to go, so it does look like it hangs for no reason. I'm not sure if this is the problem you encountered (there was another problem involving IRQ8 and the RTC's periodic timer frequency on some machines, and possibly other problems), but this code is no longer in use.

The new code still follows the same design principles, but the old code isn't as useful as I'd hoped - splitting things into modules isn't as easy as it sounds, and most of it is actually being rewritten.

Things have also been progressing slowly because I spent 2 months working on a replacement BIOS for Bochs. Fortunately this BIOS has reached a "usable" stage, and I can now use it (in conjunction with a small patch for the emulator's source code) to test the OS with many CPUs (up to 255), dual core, hyper-threading and NUMA in a large variety of configurations.

Currently the new version of the OS consists of boot code only (including CPU detection, memory detection, SMP, NUMA, etc), and the kernel modules haven't been started. I have been intending to release the new version for the last week (before starting kernel modules)...

Nelson wrote:Wow very well thought out proposal. I personally think things like this are doomed but I'm not here to put anyone's ideas down so if you guys can gain some momentum I'll be glad to help in any way I can.

I tend to agree - the idea is doomed, but if it does die I'd like it to be a natural death that people can learn from (and you never know, there is a chance that it could result in a very impressive OS, even if it is a rather small chance).

It may seem like a well thought out proposal, but in reality it's a rushed proposal based on a decade of (part time) research, design and refinement. To be honest, I personally wouldn't vote for it - the proposed "project leader" can be a little stubborn, and I'm not too sure what would happen if it ever did become a commercial product.

Despite this I have released the latest version of the OS, including full source code - something that I haven't done for a very long time...


Cheers,

Brendan

Hello....
Its nice to see our first Project Specification. I agree with Brendens proposal. And I guess he'll make a good Project Leader. I will obey his command... but first we should discuss some division of labour. Brenden can form some teams of different modules.... People can join their most prefered module....



1. Device driver
2. Core OS
3. GUI
4. System calls
5. etc....

The entire project for a long time would be number 2 on that list. Number 4 would be mixed in and number 1 would come afterwards. Number 3 would be one of the last things to do.

I'm more than willing to help with drivers, I've got documentation for a few and I know how I want to program them - but I can't load modules in my own kernel so I can't use that knowledge yet. I also don't have much time for my own kernel.

I expect this to dissolve around april, when I'll have time again (starting with Breakpoint, which for me will be a breakpoint in life one way or another). I think I should be able to get the module loading working by june/july (if I'm lucky I'll have some time between the end of january and half of february but I'm moving during that period as well so I'm not very sure). By then, I'll have all my OS dev time devoted to module development, and that'll be PCI device drivers for the first few months.

I'm planning on Radeon (as far as reverse engineering and open source drivers allow me), IDE (plus booting), RTL8169, EHCI, USB storage (plus booting), USB keyboard, USB mouse, RTL8139, OHCI, few more drivers for my sisters new computer (she has an AMD64 ! yay!) and then I'm done with drivers. I can probably port these within a day if I learn about Brendan's OS beforehand for a short while. Don't expect me to complete anything quickly though, I prefer doing stuff right the first time.

Yes, AtlantisOS 0.0.3 is taking its time. I know. Module stuff won't speed up and I'm completely very very cramped for time (got about 9 hours a day, less in weekends, for cleaning, washing, dishes, sleeping and OSdevving, so that doesn't leave me much).

Hi,

Kemp wrote:The entire project for a long time would be number 2 on that list. Number 4 would be mixed in and number 1 would come afterwards. Number 3 would be one of the last things to do.

Not necessarily. If my proposal is selected (and I'd still want to wait a week for other proposals, letting the dust settle, etc) there's several activities that can be started....

First, there's the languages part of the regional database, which has many incomplete entries. People could just add their own information (and many helpfull people have), or someone can become responsible for seeking out the missing information and completing what they can. This only really requires a good web browser (something that can handle UTF8 character sets). Even though the regional database hasn't been integrated with the new version yet, it will be.

Then there's existing code that isn't commented and/or isn't formatted. This is a little tedious, but you only need a text editor (and optionally, GCC to make the "System Build Utility" if you want to see how your formatting looks straight away). This is also a great way to become familiar with the code itself...

There's also a whole pile of "CPU errata" that needs to be done (see here for an example, and this page for an explanation). This is hard work (trying to understand the manufacturer's information isn't easy).

Next, there's only a "raw floppy" boot loader at the moment. The previous version had a boot loader for GRUB, which shouldn't be too hard to modify to suit the new version (almost all of it remains the same). Also there's old code for creating bootable CD images that could be ported to the new version (most of it also remains the same, but it's a little trickier). Both of these would need a little knowledge of the OS's boot process (but very little) and some knowledge of either GRUB, or the ISO9660 format and El'Torito.

Then there's real mode code in the "boot manager". This is meant to have a menu system built into it, which has been allowed for but not implemented. The idea here is that the boot API should have a new function to display a menu, which allows the user to select an option and returns which option was selected. This can involve scrolling the list of options (if it's too long). This is more challenging, because the boot manager runs in 640 * 480 *16 colour mode (which can be painful). There's already a system of video buffers (for performance) and code to draw characters, etc.

Also, the boot manager is supposed to get a list of options from the boot image and parse it (e.g. a boot configuration file). This boot configuration file doesn't have a format yet, but only needs to handle "variable = something". This would also include a new boot API function that allows boot modules to ask for the contents of a variable (where the boot API function tries to find it and return it).

Then there's support for a "default" video mode. This would mean writing a new (real mode) boot module that gets a list of available video modes using VBE BIOS functions, uses the boot API menu (above) to allow the user to select one of them (and test the currently selected video mode). This needs to wait until the boot manager has support for menus, but someone could start it and obtain a list of available video modes. The idea here is that if there's no video driver for the video card, the user can still use high resolution video modes.

Once the video mode selection module is done, support for different colour depths would need to be added to each "kernel setup module". There's 3 kernel setup modules (32 bit, PAE/36 bit and 64 bit) and 5 colour depths left to implement, but the same code can be used for both 32 bit and 36 bit (PAE makes no difference here). This works out to 20 routines to blit characters (8 * 8 and 8 * 16 fonts) and 10 routines to draw the title.

I'm about to run out of room (there's more), but this should at least give people an idea of what can be started. I know some of it isn't very exciting, but that's how these things go (it gets more interesting as more is implemented).

@Candy: I've got some plans for reverse engineering. Let's just say that the BIOS I'm working on could be very handy for virtualization, and that if an OS allowed any real device to be assigned to a "hypervisor", then that hypervisor could boot some other OS and create a log of every single interaction between the guest OS and the device. Unfortunately, long term plans aren't suitable for short term goals...


Cheers,

Brendan

Brendan: I've updated the Dutch language in that database:
http://bcos.hopto.org/cgi-bin/showlang.cgi?dut

The Dutch language does not have an AM/PM identifier as far as I know but uses the 24 hour time format.

I'm not sure what is meant by the line "EXIT string". I see that it is defined with the word "Exit" in the English language. But I have to know the context to use something meaningful in Dutch. The rest should be correct.

I'll try the latest version of your loader on my systems here to see what happens.

United Kingdom. We still uses pounds not euros.

Rob wrote: The Dutch language does not have an AM/PM identifier as far as I know but uses the 24 hour time format.

Yes, same for Serbian language, on AM/PM string.

Off-topic part:

Rob wrote: Brendan: I've updated the Dutch language in that database:
http://bcos.hopto.org/cgi-bin/showlang.cgi?dut

The Dutch language does not have an AM/PM identifier as far as I know but uses the 24 hour time format.

Well, I thought I deleted that stuff..

I'm not sure what is meant by the line "EXIT string". I see that it is defined with the word "Exit" in the English language. But I have to know the context to use something meaningful in Dutch. The rest should be correct.

I'll try the latest version of your loader on my systems here to see what happens.

I prolly think it's in the context of: 'Exit program'. Which then would be 'Afsluiten'

As for the on-topic part:

I agree with most people here, I bet it can't be done, and if it's possible.. you'd be planning for like months/years. You just have too many people with different opinions about doing things.

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''

``It will take one year,'' said the master promptly.

``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''

The master programmer frowned. ``In that case, it will take two years.''

``And what if I assign a hundred programmers to it?''

The master programmer shrugged. ``Then the design will never be completed,'' he said.

Source: The Tao Of Programming

Hi,

There's 2 parts to the database, one for languages and the other for "zones". For example, the entry for the "United Kingdom" zone would specify "English" as the default language, so that people who live in the United Kingdom can just tell the OS where they live and usually not worry about setting the language (but the defaults can always be changed).

The zones part of the database has "time format strings", which specify how the time should be displayed in different areas of the world. For somewhere like Australia this would be something like "1:23 PM", while for Serbia or Norway it'd be "13:23" with no AM or PM string.

The problem is that if someone wants to use Dutch or Serbian in Australia (for e.g.), then the OS would try to use Australia's time format string with Dutch or Serbian AM/PM strings. Regardless of what happens, it's not going to be right because what's right and wrong will depend on personal preference - some might want to see "1:23 PM" , but others might want a 24 hour format.

I guess what I'm saying is that these settings are defaults, and may be overridden (or corrected) by the user/s themselves. Because these conflicts can't be resolved and (hopefully) won't happen often, anything in them should be fine. For example, it wouldn't matter much if they said "morning" and "afternoon", or "sunrise" and "sunset".

For the Yes, No, Exit and Cancel strings, these were intended for standard dialog box buttons. To be honest I'm not too sure why I put Exit in there, and other strings (like "Next", "Back", "Open", "Save" and "Accept") would have made more sense. It's hard to know what to include without including too much, and it is something that should be reconsidered.

@Curufir: I've changed the United Kingdom back to "GBP" and the pound sign - I think this was my fault entirely :-[.


Thanks,

Brendan

Hi,

DennisCGc wrote:I agree with most people here, I bet it can't be done, and if it's possible.. you'd be planning for like months/years. You just have too many people with different opinions about doing things.

I'm skeptically optimistic, in that I've done it before with a small team without many problems - me and 2 others, where I did most of the programming and made design descisions, and they provided support, suggestions, testing, bug checking and a little code.

To me the largest pitfall is true democracy - a good discussion followed by a final descision can help to avoid problems, while a lengthy debate with no clear majority can stall a project indefinately.

For my proposal, the fundamental design is pre-determined. This still leaves plenty of room for discussion while providing people with a clear consistant view of where the project is heading. Apart from discussion, in the end there will be a list of work that needs to be done. Some people may wish to participate in the discussion only, some may want to tackle smaller items from the list and others might prefer larger items, as the larger items will be more work but offer more flexibility. If no-one wants to do any of the items on the list then I'd do them, but that's what happens now...

Still, the week is far from over, alternatives are still possible, and perhaps nothing will be selected. As long as I get some sleep before the week is over I'll be content.


Cheers,

Brendan