Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
OSNews, Generic OSes "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."
Thread beginning with comment 535589
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: The hardest part
by zima on Tue 18th Sep 2012 18:07 UTC in reply to "RE[4]: The hardest part"
Member since:

I only posted that in response to the BIOS comment. I don't consider UEFI firmware a great substitute for a software driver standard

It was mostly just half-joking continuation of "That's what the BIOS does. Welcome to 16-bit mode" post just above ...though UEFI did have also that goal in mind, IIRC. And which, as I said, didn't really work out - and you pointed out some possible issues with the UEFI approach.

Problem is, perhaps that's one of the very few ways of achieving such total plug'n'play? The others would be a) drawing on the work of existing standard bodies (but I have some doubts if Haiku, Syllable or Visopsys support, say, even USB video class) b) drawing on the work done for the big boys (what NDISwrapper does, and ReactOS has a goal of using all standard Windows drivers IIRC; I believe there's also notable BSDs <-> Linux cross-pollination, extending also to Haiku and such).
Either way, it would force more idiosyncrasies of dominant OS onto independent ones - would that be good?

Cameras are also covered BTW, VoIP devices largely fall under some device class for external USB soundcards, and there was also some standard for scanners IIRC.

Reply Parent Score: 2

RE[6]: The hardest part
by Alfman on Tue 18th Sep 2012 19:23 in reply to "RE[5]: The hardest part"
Alfman Member since:


"Problem is, perhaps that's one of the very few ways of achieving such total plug'n'play?"

I think it depends what you mean by PNP. As a hardware spec, PNP refers to the mechanisms of allocating the resources (memory, ports, interrupts, dma) for hardware and identifying it. This is mostly solved by Bios/UEFI already and I see no reason to change it. Even when no drivers are available in the OS, the system is still able to allocate device resources via PNP. I don't think there's a PNP problem for hobby operating systems in general.

You keep suggesting to draw on the work of existing standards bodies, and to the extent that we can I agree it's a good idea. However I am not aware of any standards that approach the driver problem holistically and with the goal of being applied across operating systems. Your usb video class example is fine, but it falls short of solving the more general problem (even assuming all usb webcams could use this standard). Once my OS has implemented this USB standard, can I plug in any PCI frame buffer capture card and use it? Can I plug in a firewire device and capture from it? Can I plug in an eithernet/Wifi webcam device and capture from it? Can I pair to a bluetooth webcam? The answer in most cases is going to be no because the USB standard is just that, it's not intented as a generic solution to the driver problem. I want a driver solution that can continue to work even if a new bus comes along to replace USB. I want something specifically designed to solve the driver problem for all operating systems without regards to the standards of a specific bus.

A second thing to keep in mind is that this driver standard should not seek to dictate how manufacturers should build their hardware. I feel they should be unrestricted to build the hardware however they want. It would be the software driver's responsibility to bridge the gap between the driver standard and the hardware interface.

If needed they could add proprietary extensions until the time when the standard officially adopted those extensions. Even then, the existing hardware wouldn't need to be updated, only the drivers. This would mean the functionality defined in the standard would always be available to all operating systems, only non-standard functionality would be OS specific.

"Either way, it would force more idiosyncrasies of dominant OS onto independent ones - would that be good?"

Your example was taking existing drivers today (say from windows) and making them the defacto standard. That's not what I had in mind. Shared drivers would be designed from the ground up to be more agnostic.

Reply Parent Score: 2

RE[7]: The hardest part
by zima on Mon 24th Sep 2012 23:58 in reply to "RE[6]: The hardest part"
zima Member since:

Thing is, approach like that of USB video class is likely pretty much one of the very few workable solutions. Another being just using Windows (and/or Linux...*) drivers.
If you wish for such "total PNP" (and I used the term more broadly, what the abbreviation says), that is what in practice you want, I think. What is realistic (on several fronts, also how it impacts / constraints OS architectures).

And all USB can use this standard - it will just take some time. Though the thing is, webcams get typically integrated now ...more and more peripherals either gets integrated or disappears, random driver woes become less of issue.
Firewire also has similar ~class for a long time BTW ...oh, but it disappears. As do TV tuners. Also, ethernet/wifi cameras don't need drivers, and the USB will be almost certainly around for a long time...

OTOH, if something were to come that would really be as all-encompassing shared driver model as you envision, it could quite possibly somewhat preclude future improvements, or at get in their way more than would otherwise be the case (with how we already must care about compatibilities, legacies, and such). Once really introduced, not much would get improved. You description reminded me a bit about Kronos group, OpenGL stagnation, relatively limited "standards" of doing things within it.

And I don't really think there's any big "driver problem" to be solved, anyway.

* BTW, funny thing about Linux kernel devs that came to my attention - apparently they are quite willing to work under NDAs when working on drivers. Which basically says "now that Linux is strong, we'll also do the things which impair newcomer operating systems"

Edited 2012-09-25 00:12 UTC

Reply Parent Score: 2