AndrewAPrice wrote:
rdos wrote:
As for running on hardware that doesn't support long mode, we have two platforms in that category. On that use a modern multicore processor that doesn't run in long mode and the other is one with PIC controller and legacy hardware.
In my household, my x86 devices all support long mode, and everything else is ARM (Raspberry Pi, MacBook, smart phones). So for greatest compatibility of devices, I should target ARM?
An argument you could make is "by building for protected mode, you support all x86-64 hardware automatically, but by building for long mode, you'd have to backport if you wanted to support 32-bit x86."
You're right. My counterargument (that others have made) is that at some point it's worth picking a cutoff point so you don't have to support all of the legacy ways of doing things. Choosing long mode as the cutoff point is good because it's pretty well advertised what are 32-bit or 64-bit CPUs.
Well, maybe for a new design that's reasonable. I started my OS project 1988, after having acquired a very expensive 386SX motherboard. While not much is left since that time, the OS is used on thousands of installations, some which have hardware that doesn't work with long mode. At this point, I'm not very interested in starting a new OS project, as I'm sure it will not be used by anybody else, and my own private needs doesn't require ARM or long mode. So, I will continue to develop my protected mode OS as long as I'm motivated and need new features.
My main point is that people that already work on protected mode OSes, and like me, have considerable amounts of code in assembly, won't need to switch to long mode anytime soon. Unless they want to start from scratch and never get to the point of something useful. Actually, you cannot restart once in a while and expect to build something useful. I never did a full restart, even if I have made considerable redesigns from time to time.
My current project is to port OpenSSL, as I want to be able to connect to and host https websites. I also need this to connect to various Internet services. It's working pretty well, but the Posix socket model is a bit of a problem.
SSL/TLS is an interesting component in the context of services. Where should it be put? What is the interface? This is not an easy issue since there will be a need to sync the implementation with OpenSSL from time to time to keep up with security patches. My current model is to link the library with the application, but I dont like that design too much. It should be a driver in the OS.
I also think people should not be so strict about monolithic vs microkernel designs. My opinion is that some things are better done with microkernel designs while others are better done the monolithic way. The service interfaces should not depend on how they are implemented.