Hi,
Dex wrote:@Brendan, I have a lot of respect for you as a coder and a writer and what you say makes a lot of sense, but i am not sure that you can achieve your goals, just by making it better.
Everything impacts on everything else, you make a very secure OS, useally makes it less user friendly, you make a OS with lots of DRM so people can not watch copy ed movies, maybe there own copy ed movies, will not make user happy.
The key phrase is "better for their specific purposes". For example, if someone has a 486 with 4 MB of RAM, and the only thing they want to do is play audio CDs, which OS would be best for their specific purpose? Vista and Windows XP won't run, and Windows 95/98 are too bloated. They could probably setup Linux or a BSD to do it but the time it'd take to customise something to suit would be a problem. For this specific purpose I can think of an OS that is better than all of these...
Of course most people want to do more than just play CDs, so there probably wouldn't be a large number of people who would use Dex4u for this specific purpose (even though it's better than any other OS for it). The hard part is finding a specific purpose that a larger number of people would want that other OSs aren't too good at....
B.E wrote:That sounds like M$ - create their own standards, and expect everyone to conform, then when everyone has conformed to this new standard, create another one and force people to use the new standard.
If a user desperately needed to run something like GIMP or Apache, would they change from their existing OS to Linux to do it, or would they just find a version that's been ported to their existing system? If a user desperately needed to run Microsoft Office, would they change from their existing OS to Windows to run it?
Basically, it's very difficult to create an OS that is better than other OSs for a specific purpose if all of the applications can be ported to another OS. In this case you're limited to providing better performance, better reliability, better hardware support, better installation and maintenence, etc, which are all good things but make it much harder to convince someone to leave their existing OS.
For an example of this, consider SkyOS. It looks very impressive, but most of the applications are ported from elsewhere. AFAIK their file system indexing is native code, but other systems (Vista, OS X) do this just as well. Where is the reason for people to leave their current OSs and shift to SkyOS? Nice looking graphics are great for first impressions, but is that enough?
B.E wrote:Anyway I'm curious to how your going to achieve the no linkers part.
All compilers would generate "intermediate language" files, and all libraries would be in this intermediate language. Then there's another compiler which compiles all of the "intermediate language files" into a single assembly language file (which is then assembled to a flat binary, optionally with the special executeable header my OS uses). Dynamic linking (DLLs, shared libraries) will never be supported by my OS, so that isn't a problem. The intermediate language is a low level language (like a portable assembly language). People could write code in this language, but that's not what it's intended for.
B.E wrote:
What I mean is that I've stopped my project and started again from scratch enough times to know that getting things right is infinitely more important than getting things working... Wink
This usually means that you have skipped the inception, and elabloration phases of development.
What I have done on my OS is very little (only a boot loader), code wise. But I have designed the whole OS architecture, and now I can start writing the code (may need to rewrite the boot loader).
I had an older version of the OS that worked fine, had a few device drivers, Othello, a BASIC interpretter (intended as a scripting language), a (text mode) GUI, a CLI and a few other things. It used plain 32-bit paging only, was single-CPU only, didn't do decent device detection, etc.
I wanted to add support for multi-CPU and PAE, and change the device driver interface, switch to "variable sized" messaging and make other improvements, so I started again. The next version ended up with an almost complete kernel that supported plain 32-bit paging and PAE, and multi-CPU, hyper-threading and NUMA. I also added support for internationalization (including support for different time zones, languages, etc in the boot code itself).
The scheduler wasn't too good (in some cases it was "O(n*2)" and sucked when there's a large number of threads running, and didn't handle NUMA and hyper-threading too well), but it did handle a large number of (SMP) CPUs fairly well. There was also an IRQ latency problem in there somewhere that I tracked back to the scheduler disabling IRQs for too long. I attempted to replace the scheduler, but the entire micro-kernel was mostly a single large chunk of code and I ran into trouble finding the scheduler's dependancies. Lastly, during the development Intel and AMD introduced 64-bit and hardware virtualisation, which weren't really part of the original design.
Anyway I figured that if I had trouble changing the scheduler I wrote, then anyone else would find making changes extremely difficult. At the time I was also considering the end uses of the OS (like embedded systems), and a few other mistakes I made (Internationalization shouldn't have been in the boot code, the memory manager was too complex as it supported plain paging and PAE using conditional code, etc). I decided that a microkernel wasn't modular enough, and that I could improve some things, so....
Then I started a short-lived modular system, where different parts of the kernel were designed as seperate modules. For example, you could have 3 memory managers, 2 schedulers, etc and decide which one to use during boot, when the OS is installed and/or when the boot image was created. For this, half of the modules were done in 3 versions (one for plain 32-bit paging, one for PAE and another for 64-bit). During boot there was a "chicken and egg" problem with memory management - to create the paging structures used after boot you needed to allocate physical pages suited for the page colour and NUMA domain, which led to a full NUMA aware memory manager in real mode and certain structures were used for both the boot memory management and the kernel's memory management, which restricted the design of memory managers used after boot. Around this time I started working on a BIOS for Bochs (I needed ACPI SRAT and SLIT tables to improve my NUMA support), and lost track of what I was doing. After a while I returned to this version of the OS, decided I wanted to add support for headless systems and a few other things, and wanted to fix my "chicken and egg" problem. Because it was in it's early stages I stopped it and....
This led to the current version - I've been working on boot code for several months. So far it can boot from floppy, over the network (diskless systems) or can be installed on a custom ROM (embedded systems). The boot code uses a seperate "user interface" module (one module for normal keyboard & video and another one that uses the serial port for headless systems). There's other boot modules used for memory detection, CPU detection, NUMA domain detection, etc, so that these modules can all be replaced easily without effecting the rest of the system (for e.g. in an embedded system you don't need code to detect and find bugs in all CPUs, and you could replace the CPU detection module with something that only works with a specific CPU to save space). Currently I'm porting some older "boot image compression" code to the project, but improving it as I go.
Anyway, most of my problems were the result of "scope creep" and not-enough modularity (too many hidden dependancies between parts). Now my project is extremely modular with formal specifications for each module (no more hidden dependancies). The possibility of scope creep has been reduced too (mostly, the OS is designed to support everything I can think of, except for things I know I'll never want). Somewhere in there was a change in focus too - earlier versions where educational/hobby OSs, but gradually I shifted to more commercial/practical purposes and I found that "good enough" is never really good enough....
Cheers,
Brendan
--
BCOS Project -
http://bcos.zapto.org
.