“Fundamentals”
Where we will be looking at modular engineering from a historical perspective. And present the first of several installments in a series on “OS upgrades”.
Part I: “Fundamentals”.
Back in the long, long ago, when the Romans fought back the Germanians with the help of their hand- powered gps- systems, upgrades must’ve been a cumbersome and difficult process. (Which evidently explains why it never took off commercially back then.)
For one, the system was probably one of a kind. At the core of the construction there would be methods and worksmanship built on not only unique techniques - but also uniquely constructed materials. So if an adjunct were to change or improve on a part of the construction, it would’ve required the reassembly of the entire machine, and changes on every level. The genius of the construction simply required it.
Today the situation is different. The Germans have returned, and the industrial revolution has given us assembly lines, along with replaceable building blocks and “just about in time” assembly techniques.
Strangely enough - almost exactly the same technical evolution was what enabled software and computer designs to improve so quickly over the past fifteen- twenty years. Now, instead of coding anything from coffee- machines to radio- transmission relays by inventing each part from scratch - and then welding it to the rest permanently, so we would’ve had to scrap the entire construction before making any changes - we typically create relatively generic building blocks that perform abstract functions instead. Blocks which then can be easily changed and improved individually, without breaking the program.
Because in this way, improvements on parts of programs can be taken care of without touching the underlying architechture and the hardware. And improvements in the architecture can be made, without changing the fundamentals of the programs that run on it. This then makes it comparatively easy to reuse software, as well as improve the hardware underneath. Not to mention that user- interfaces can be changed, without this breaking program logic.
Symbian OS, like most other OSes, is built with the same idea in mind (not all the time, perhaps, but still). The hardware would have certain minimum requirements for interfaces, which then the OS will use to provide a set of common functions. Which would be provided through the microkernels - which again could be extended to speak with new external hardware outside the chip - which in turn would be used to create and support higher level methods and functions, that might be of use to the average programmer. On top of this, there would be other sets of libraries and functions branching off, such as s60 and UIQ - all built on top of the translations between the high- level and low- level apis.
So one not entirely inaccurate way to represent a computer, in this case a phone running Symbian OS, would be something vaguely like this:
In other words - we can typically predict that significant hardware- changes will still enable existing microkernel implementations. They may have to be changed slightly over time, but they will simply not be significantly changed, becuase doing so would require unecessary rewriting of higher level implementations in the system. (Or, more to the point, throw away years of hard- earned experience and accomplishment.)
In the same way that the higher- level OS functions and methods would be kept conceptually for providing support to the extra libraries. The implementation might change, but not to the point where they (should) break the higher- level apis. It just would not do to rewrite the internal logic of a programming language in order to fit it to the phone, after all.
Therefore, the largest part of the work would be in 1. adapting the microkernel extensions to interface correctly with different hardware, as well as writing those to fit with the low- level apis (typically 3rd party, chip production, etc). And 2. providing compatibility between the high- level OS functions and low- level apis. As well as 3. maintaining backwards- compatibility between the existing UI layer (UIQ, S60) and the high- level functions.
It also means that if consistent OS- level implementations (Symbian) were provided, few or no changes would need to be made for the UI- layer (s60 or UIQ) to run happily on different hardware. (Even if that UI would use other instruction sets not specifically part of the UI- layer, such as OpenGL ES.)
In the same way, as long as it is physically possible to provide support for the needed high- level apis (either through hardware or software - i.e., either through microkernel supported hardware acceleration, or through low- level software- implementations of the same functions), then no insurmountable obstacles exist for installing new UI- layers on older phones.
In theory, at any rate.
(next: part II, “Possibilities”. What are the practical problems?)
Loading ...
Leave a Reply