| News | Features | Interviews |
| Blog | Contact | Editorials |
| Visopsys: one man's vision to build an operating system |
| By Thom Holwerda, submitted by Andy McLaughlin on 2012-09-17 16:56:46 |
| "Visopsys (VISual OPerating SYStem) is an alternative operating system for PC-compatible computers, developed almost exclusively by one person, Andy McLaughlin, since its inception in 1997. Andy is a 30-something programmer from Canada, who, via Boston and San Jose ended up in London, UK, where he spends much of his spare time developing Visopsys. We had the great fortune to catch up with Andy via email and ask him questions about Visopsys, why he started the project in the first place, and where is it going in the future." |
|
| Useful website |
| By error32 on 2012-09-17 17:26:21 |
| The visopsys website has a lot of useful link to os development documents. Probably already well know to homebrew os-devs |
 - Score: 2 |
| The hardest part |
| By Alfman on 2012-09-17 17:51:34 |
|
Pingdom: "What’s been the hardest part of working on Visopsys?" Andy: "Hardware support, definitely. The world of PC hardware has always been a bit daunting, since there are so many different manufacturers, all interpreting the standards in their own ‘unique’ ways. You might write something like an IDE driver that works on every system you try, release it, and then find out it isn’t working properly on hundreds of other peoples’ systems." I have to agree completely with his answer. Designing and implementing the OS foundation is the "easy" part. It's the part we're all most interested in as programmers. Going through and actually implementing the drivers (often without specifications and even without all hardware configurations) is the part that ultimately bogs down the hobby OS developer. What we need is some kind of universal driver standard that can be shared across all operating systems. Ideally this would be in source form and the layer could be optimised away by the compiler. This way a driver wouldn't be written for "Windows X" but instead for the "2012 PC driver standard". The OS would implement the standard and immediately support numerous compatible hardware devices. It's a pipe dream though. For it's part, MS would never participate, and their cooperation would be pretty much mandatory. |
| - Score: 3 |
| RE: The hardest part |
| By ferrels on 2012-09-17 18:01:37 |
|
That all sounds good in theory, but in practice it reduces your OS to running on hardware of the least common denominator (in terms of performance)....your driver may work on 98%+ of the hardware out there but the performance suffers immensely. VESA drivers for video are a good example of this. Almost all video hardware will work in VESA mode, but you're essentially left with only the most basic functions and features....i.e. no hardware GPU acceleration, limited color depths and resolutions, etc. Edited 2012-09-17 18:02 UTC |
| - Score: 2 |
| RE: The hardest part |
| By tidux on 2012-09-17 18:12:04 |
| That's what the BIOS does. Welcome to 16-bit mode. |
| - Score: 4 |
| RE[2]: The hardest part |
| By Alfman on 2012-09-17 18:13:16 |
|
ferrels, Well, VESA was written ages ago and at that time they performed pretty well because graphics were not accelerated. The reason I stated the "2012 PC driver standard" was because I envisioned the standard itself to be updated every few years to adopt to new hardware interfaces. Non-standard extensions could be implemented too, but the idea would be for new functionality to ultimately be incorporated into the standard at some point. The great thing about this is that the standard could be both forward and backward compatible. As an example. an OS might support the 2012 standard for webcams. Come 2020, when the standard is depreciated, a generic 2012->2020 wrapper layer could never the less assure that all 2020 operating systems could continue to run the 2012 web cam drivers. (I think I uncovered another disincentive for manufacturers to support this :) ) Conversely, it'd be possible to have a generic 2020->2012 conversion driver to allow an older OS to run the newer hardware drivers. Edit: Extending EOL is only a side benefit, but the intention would be to eliminate the duplication of work in OS drivers and make it much easier for all operating systems to support all hardware at least in their basic modes. More advanced features should still be possible even if they're not supported in all operating systems. Edited 2012-09-17 18:19 UTC |
| - Score: 2 |
| RE[2]: The hardest part |
| By Alfman on 2012-09-17 19:07:01 |
|
Of course, BIOS is strictly a legacy interface today, essentially undeveloped since the 1980's. Never the less, in it's prime, consider what a huge phenomenal success BIOS was in achieving a level of hardware independence that would have been impossible without it. The small OS I wrote did run on PCs other than mine. I didn't have to do anything extra to make it run on a laptop, it just did because those standards existed. I am absolutely positive that Andy and all other indy-OS devs you'll find will agree that they crave a standard interface that would just make their OS work everywhere without having to reinvent the wheel and write new drivers for the Nth time. Let's all have a good laugh comparing the idea to a 16 bit BIOS, but on a serious level I'd rather not dismiss the notion of a modernised standard as a joke. It would be tremendously useful in promoting innovation in the operating system space by making it much easier for alternative operating systems to be taken seriously as competitive platforms. |
| - Score: 3 |
| RE[3]: The hardest part |
| By zima on 2012-09-17 19:35:10 |
| Well then that's what the UEFI does now. Or at least was supposed to, I think - didn't really work out (NVM forcing all OS into the same idiosyncrasies; IIRC it follows some of WinNT, so MS even kinda participates...) |
| - Score: 2 |
| RE[3]: The hardest part |
| By zima on 2012-09-17 19:45:57 |
|
Webcams are already more or less covered, by USB video class - don't really even need driver installation (sure, some manufacturer drivers are often/usually provided; but they tend to offer just superfluous trinkets beyond what the OS driver does, and they sometimes introduce some weird issues & performance degradation - that happened to me once, the default OS drivers clearly bogged down the system much less during webcam operation) PS. Compatibility with USB video class is BTW something made mandatory by MS to get Vista & up logo certificate, on a product - which also brought to, say, Linux much better support of any random webcam than it used to be the case - so overall your "It's a pipe dream though. For it's part, MS would never participate" seems not entirely warranted... Edited 2012-09-17 19:55 UTC |
| - Score: 3 |
| RE[4]: The hardest part |
| By ssokolow on 2012-09-17 20:12:24 |
|
Yeah. Microsoft actually does have an incentive to standardize drivers. Aside from malware, the biggest source of kernel instability these days is buggy drivers. So, the more Microsoft can get more hardware sharing less code that they write and test themselves, the more stable Windows becomes. (And the easier it is to push the PR line that locking down the system, iOS-style, will kill rootkits and spyware without harming any legitimate users) Edited 2012-09-17 20:24 UTC |
| - Score: 2 |
| RE[4]: The hardest part |
| By Alfman on 2012-09-17 20:27:35 |
|
Well, maybe, but I only posted that in response to the BIOS comment. I don't consider UEFI firmware a great substitute for a software driver standard. I don't have practical experience with UEFI, but I see some possible negative implications: 1. The hardware firmware can't be managed as easily/safely as software drivers can be. Can I update firmware drivers for one device independently from the rest or is this a monolith firmware? 2. For UEFI services to work, my devices will have to be supported through my mainboard. If the device uses a newer standard, and my os supports the newer standard, is it possible that my mainboard can never the less prevent me from using it because it lacks firmware updates? 3. I don't think UEFI can contain drivers to support all external peripherals - like webcams, cameras, scanners, various adapters, voip devices, etc. It seems like a bad idea to try and cram all the drivers for these in the motherboard's UEFI services. To be honest, I'd rather have a standard that is capable of scaling to all sorts of devices and not one that depends on my motherboard's firmware implementation. So I think a software solution would be better....however I'd like to hear other ideas. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |