Programming Forums - View Single Post

Mad_guy · Dec 22nd, 2005, 11:29 PM

Could you please explain to me how exactly you're going to get Mac programs (which are all primarily PPC architectures right now,) Linux programs (which encompass a wide variety of formats and architectures), and Windows (PE files are primarily for x86 but Alpha ones exist as well,) to work together harmoniously. You're at least going to be narrowing out Windows files or Mac files - because the two just are't compatable (PPC and x86, Linux can go both ways.) THEN of course even if you did manage to work that shit out, you'd have to have some type of light abstraction (or heavy emulation) layer to make that kind of shit work on architectures in which they weren't originally compiled.

Let's also completely ignore the fact that, if you want this programs to work natively, you will have to somehow work out all the dynamic and static linking methods associated with all the programs. This means that your applications you want to work on the OS will have to have their own subsystems (such as how Windows has Win32 and POSIX subsystems) or something related in order to get each application to work well, because a linux ELF probably won't work on Windows or your OS unless you have the libraries to support it, you also, have to make sure these things don't clash.

And finally, if you're going to make an 'operating system which never crashes,' I assume you will be going for either:

* A Microkernel
* No loadable drivers (the bane of all stability when coming to kernels of any variety.)

Both have their problems - no drivers means basically no hardware support, and a Microkernel these days is WAY too slow because the drivers have to continuously communicate inbetween process spaces whenever they're called (which is about every time a process does something in a lot of systems.) Added onto that, the thought of a Microkernel is almost inherently flawed anyway. The general theory is that drivers and the kernel are loaded into two seperate spaces, so if a driver crashes then the kernel still stands and the system stays up as long as the kernel is stable. That is a good idea, but in reality, what if the driver that falls over like a bitch is your file system driver or the driver that might handle process and thread scheduling? It's pretty unlikely your operating system will be able to fully recover from something like that, so the kernel will have to deal with it, and it will probably be delt with via reboot. And if you go for a monolithic kernel (a la NT or Linux), well, the thought of never crashing is silly.

Dec 22nd, 2005, 11:29 PM	#16
Mad_guy Hobbyist Programmer Join Date: Oct 2004 Location: Sandstorm, Techno Club Posts: 239 Rep Power: 4	Could you please explain to me how exactly you're going to get Mac programs (which are all primarily PPC architectures right now,) Linux programs (which encompass a wide variety of formats and architectures), and Windows (PE files are primarily for x86 but Alpha ones exist as well,) to work together harmoniously. You're at least going to be narrowing out Windows files or Mac files - because the two just are't compatable (PPC and x86, Linux can go both ways.) THEN of course even if you did manage to work that shit out, you'd have to have some type of light abstraction (or heavy emulation) layer to make that kind of shit work on architectures in which they weren't originally compiled. Let's also completely ignore the fact that, if you want this programs to work natively, you will have to somehow work out all the dynamic and static linking methods associated with all the programs. This means that your applications you want to work on the OS will have to have their own subsystems (such as how Windows has Win32 and POSIX subsystems) or something related in order to get each application to work well, because a linux ELF probably won't work on Windows or your OS unless you have the libraries to support it, you also, have to make sure these things don't clash. And finally, if you're going to make an 'operating system which never crashes,' I assume you will be going for either: * A Microkernel * No loadable drivers (the bane of all stability when coming to kernels of any variety.) Both have their problems - no drivers means basically no hardware support, and a Microkernel these days is WAY too slow because the drivers have to continuously communicate inbetween process spaces whenever they're called (which is about every time a process does something in a lot of systems.) Added onto that, the thought of a Microkernel is almost inherently flawed anyway. The general theory is that drivers and the kernel are loaded into two seperate spaces, so if a driver crashes then the kernel still stands and the system stays up as long as the kernel is stable. That is a good idea, but in reality, what if the driver that falls over like a bitch is your file system driver or the driver that might handle process and thread scheduling? It's pretty unlikely your operating system will be able to fully recover from something like that, so the kernel will have to deal with it, and it will probably be delt with via reboot. And if you go for a monolithic kernel (a la NT or Linux), well, the thought of never crashing is silly. __________________ os: mac os 10.5.4 revision control: git editor: emacs site