Linked by Thom Holwerda on Sat 23rd Oct 2010 22:23 UTC
Windows "Windows 7 might be a massive commercial success and an undeniably rock solid piece of software, but Microsoft is apparently unwilling to rest on those soft and cozy laurels. Asked about the riskiest product bet the Redmond crew is currently developing, its fearless leader Steve Ballmer took no time in answering 'the next release of Windows'." Also of note in this same video interview thing: Ballmer states that Silverlight is now pretty much strictly a client, non-cross platform thing, while explicitly stating that when it comes to doing something universal, "the world's gone HTML5".
Permalink for comment 446951
To read all comments associated with this story, please click here.
Member since:

would be modular and scalable. As a result it would support
* embedded systems
* mobile Phones
* tablets
* desktops
* servers

It would just have a minimal hardware abstraction layer. This HAL only would cover CPU, busses and memory. Only this tiny HAL and a small VM "bootloader" would be CPU Architecture dependend.

Okay, until there I follow you. Sounds like a microkernel.

The VM runtime "bootloader" is a simple interpreter. It's only purpose is to bootload an optimizing VM runtime utilizing JIT technics. Everything else even the optimizing VM runtime itself would run on the optimizing VM runtime. This would include device drivers like graphic card, NIC or SATA drivers. As a result it would support several processor architectures. IMHO at least x86, x86-64, ARM Cortex Mx and Ax and MIPS 32bit and 64bit should be supported.

There I'm lost. It sounds like you would like to write almost all of this OS in interpreted code. This basically means recompiling most of the OS at every boot (except is JITed code is cached in some way). Performance would be horrible. Apart from technological achievement, what's the point of using this instead of platform-independent compiled languages like C and C++ ?

Also the OS itself the schedulers -- I think of schedules as "plugins" --, filesystems, etc. would run on the VM runtime.

Again, why not a microkernel and high-level components written in platform-independents component languages instead ? What's the added benefit ?

It would optionally offer a remote shell, a GUI optimized for handheld devices or a GUI optimized for desktops. The desktop optimzed GUI would support remote access.

Couldn't a properly done GUI infrastructure optimize for both ? (I'm thinking about this in my own OS project, but I'm not there yet so I can't tell about it being doable in practice)

Edited 2010-10-25 13:47 UTC

Reply Parent Score: 2