Just a thought, if we have to make our application cross-platform, then is it possible to create a cross-application OS?
No.
Lets say you do go and invest - a monumental amount of - effort in building you're Uber-OS (that will run Mac apps, Linux apps, Unix apps, Android apps, i-phone apps, Nokia apps, Symbian apps, SAP apps, Windows Apps etc).
Then there's nothing stopping someone writing a new OS that you don't support.
P.S. And there are hundreds (if not thousands) of different hand held devices out there for scanning products, weights and mesures etc many of which have their own flavour of OS.
Technically yes as long as you limit the scope of all to all applications that run on major OSes.
It is theoretically possible to create an OS that could handle applications run on the 4-5 most common OSes but the amount of work involved would be monumental.
Every time a new feature was added to any of the OSes, you'd need to add it to your OS too - So as well as being almost impossible to build, you'd need a large enough dev team to stay ahead of 4-5 of the largest dev teams/groups in the world.
No but with virtualization you could have a single computer that can run any application.
First there is the practical impossibility of successfully following the evolution of an indefinite number of operating systems. Do we take embedded OS into account? How about one-shot OS for specific applications? How about proprietary OS with no access to documentation?
Then there is also the - very difficult, if not impossible - problem of merging the various paradigms used in the wild. Ideally you would want OS services like the clipboard, or networking or ... or ... to work in a uniform way and allow applications to cooperate as if targeted to the same OS.
(Let's not even think about the various hardware-dependent applications.)
After all this, you should also consider what the application development for your own OS would be like...
I wonder if this is a good case for Gödel's incompleteness theorems :-)
PS: That said, there are quite a few projects attempting to bridge the various OS gaps:
http://en.wikipedia.org/wiki/List_of_computer_system_emulators
http://en.wikipedia.org/wiki/List_of_emulators#Operating_System_emulators
What you can do is use virtual machines, such as VMWare's software, and emulate several operating systems on the same physical machine.
What do you define by an operating system that can run all applications?
Applications are mostly written in a higher level language and then translated into binary code that differs between machine architectures (like Intel and PowerPC) and operating systems (like Windows or Unix-based systems).
Java for example is only cross-platform because not the language itself is cross-platform (any high level language is), but because there exist Java virtual machines for different architectures and operating systems that abstract the heterogeneity of the underlying system.
It is definitely not theoretically impossible (nothing is except for some mathematical problems), but can you imagine what one would have to do in order to make such a thing work? You can basically run Linux programs in Windows with CygWin, you can also run Windows programs in Linux with Wine. All of those try to create a small operating system (e.g. the Windows core) into your other OS (e.g. Linux). This is probably not what you want.
To summarize, I can't imagine anyone really trying to do that. With all the money in the world, seriously. Better invest in writing native apps for the operating systems you want to support.
Related
Preface: I'm a student about to take a course in Operating Systems. I thought I'd do some prep by watching a series on YouTube first.
Throughout the course of watching about 10 of the videos in this series, I have learned that roughly the operating system's purpose is to serve as an interface for System Programs/Applications/I/O devices/etc. to communicate with the system's hardware.
This got me thinking about how Apple's hardware is not modularly customizable. How Apple users can't swap out hardware components as easily as users on a system running Windows OS. I began to think that most likely this is because the OS Apple implements is built very specifically with the original hardware their products come with to run as efficiently as possible.
Is there any truth to this logic? I'm basically just trying to apply what I've been learning to a "real-life" example.
This got me thinking about how Apple's hardware is not modularly customizable.
It is quite customizable but not with their own hardware. The "hardware" that Apple is shipping is mostly x86-64 CPUs with a recent chipset like an xHCI, an AHCI and a modern PCI network card, etc. This is unless you have an M1 computer which is their most recent product based on an ARM architecture. They licensed the architecture from ARM ltd. and are manufacturing their own CPU. I think this is a very good and open decision from Apple unlike several bad ideas they had about their phones like removing the 3.5mm jack or using a lightning plug instead of USB-C.
If you do have an x86-64 CPU, the OS Apple built called MacOS can run on the computer. It is simply forbidden by Apple's license of use. The fact that their hardware is less customizable has mostly to do with screws and the way that the case is made than with the OS itself.
I'm currently doing a course about Operating Systems.
I understand that a kernel is a core part of an operating system that acts as a bridge between user applications and the data processing elements of a computer such as the CPU.
Why do we need Drivers then (e.g Touchpad drivers), doesn't the kernel control all computer hardware?
Because there are literally thousands (if not hundreds of thousands) of companies that produce hardware devices. The Operating System company cannot write software to handle all of them, so they provide a generic programming model using which those hardware companies can write software that could talk to their hardware.
Important to note is that although drivers are not actually part of the kernel as such, they do have some low-level privileges (direct access to hardware) because their code runs in Executive mode, unlike normal applications which run in User mode and generally do not access hardware directly. The whole point is that once the OS provides a way to write hardware-controlling software (called drivers), any vendor or person is free to write a software that could take advantage of the specialized features of their/his hardware device.
Also note that some hardware devices follow well-known standard (such as keyboards, mice, many video drivers, monitors etc.) and most OS come with built-in support for those devices. On the other hand, some devices do not have or follow standards, while still other can have both kinds of features, i.e. a subset of features that could be accessed by the default driver, plus a subset of features that doesn't follow any standards and thus is not supported by default driver. In all such cases, hardware manufacturers supply their own driver that knows the ins and outs of their hardware and therefore can take advantage of all features efficiently.
Certainly kernel does control all the hardware. However, there are way too many different hardware devices out there.
To deal with this vast variety of different devices, developers write specialized modules - and these are called drivers.
I am heavily interested in Operating System theory and design and have decided I would like to play with developing an OS. I have a background in x86 assembly and have looked into ARM also. I would like a development board to develop the OS for. Has anyone had experience with OS development and/or can suggest some hardware to use?
One board I am considering is the LPC1769 LPCXpresso board.
I am aware I could use a VM, but I would like to use actual hardware.
Well.. I personally started off with an RTOS called freertos (http://www.freertos.org/). This is an open source RTOS and is very minimalistic. It is also supported across a ton of platforms and is well written and maintaned. I ran it on a PIC32 microcontroller kit. However I would recommend you try something like Arduino boards which are more suited for beginners.
Happy learning!
Old thread, you have found your way by now, but I would definitely recommend the FreeRTOS + LPCXpresso 1769 combination.
I have some applications that are written in ANSI C. Will I be able to run the binary files of those apps on the iPhone? If not directly, is there any other useful method to do so? I don't want to rewrite the applications.
The binaries? Unlikely. When you compile to a specific platform, you tend to be locked into that platform. You can't, for example, take binaries created on a PPC Mac and expect them to run on an Intel CPU.
Your first problem is that the binaries are a different language (different processors have different instruction sets such as Intel x86, PPC, SPARC and so on). The second is that other platforms may not have the same way of implementing lower-level functions like disk I/O or user interaction.
If it's ANSI/ISO C, you should probably be able to re-compile it for the new platform. Or you may be able to use an emulator to run the binary unchanged. But running the binary directly on different hardware that it wasn't made for is not going to fly unfortunately.
It probably won't be able to run. You should compile the source code to the specific plataform.
I'm analyzing the iPhone platform (for a paper). I've made a list with issues,
developers/architects have to consider, before working with the iPhone SDK.
The questions aims at people, who want to release iPhone software. What constraints restrict them in comparsion to other mobile platforms, such as Android, Windows Mobile, Symbian, etc.
Feel free to add hurdles, which I may have forgotten to list.
Thanks.
iPhone platform constrains/hurdles:
No physical keyboard
No replacable battery
One Application A Time
Sandbox File System
Restricted Deployment Cycle (Dev program...)
App Store Approval Process
No replaceable battery is no concern for software developers whatsoever, as there are no APIs for battery manipulation or replacement. This is no more of a concern for iPhone developers than "access to electricity" is a practical concern for developing for other platforms.
Others I would add:
Requires a Mac. Fairly obvious one, not a terrible barrier to entry compared to other closed systems like game consoles, but still higher than some other phone/mobile platforms like Windows Mobile, J2ME or Brew.
Costs money to debug on real hardware. You can only run and debug in the simulator unless you buy a $99 developer program subscription, which lets you pair iPhone and iTouch hardware with your Xcode install and run apps on it.
Objective-C as the programming language. It really shouldn't deter anyone but a lot of developers get really grumpy about learning anything new or different.
Must accommodate interruptions (i.e., the user may get a call at any time and the app must be prepared to save any state necessary and quit within a fixed time limit).
Not specific to iPhone but like any platform, you are constrained by the CPU/GPU/RAM the device has, and in the iPhone's case this is obviously quite a bit less hardware than people with a desktop background are accustomed to.
Restrictive wording in EULA regarding embedded scripting languages. It is apparently forbidden to execute any scripts via an iPhone application, which is quite a bummer as embedded scripting languages are quite common these days and very useful.
Limited CPU speed
Limited RAM
Objective-C is effectively the main
dev language
Power management concerns (I'm not sure if lack
of a replaceable battery is a concern
of mine). High CPU utilization can be a drain on the battery (and cause extra heat). In other words there are CPU intensive things I choose not to do, in order not to drain the battery too fast.
Only one IDE
inability to access other apps' data
easily