Linked by Eugenia Loli on Fri 27th Jan 2006 17:34 UTC
OSNews, Generic OSes This Visopsys 0.61 maintenance release adds Disk Manager support for resizing NTFS filesystems and arbitrary partitions, purely unprivileged user-space processes, I/O port permissions and protection, IDE block mode I/O, Linux swap detection and clobber, improved atomic kernel locks, many C library additions, a calendar program, and bugfixes.
Permalink for comment 90069
To read all comments associated with this story, please click here.
some thoughts
by transputer_guy on Fri 27th Jan 2006 20:56 UTC
transputer_guy
Member since:
2005-07-08

When I look at the Visopsys screenshots I get get turned off by the Windows theme although I respect the work the author has done to get there. I would like to at least to see newer GUIs as sharp as say BeOS but it goes deeper than that.

On the theme of breaking through with new UI ideas, I very much doubt any new OS built with C/C++/C# is going to be so very different from others, the language holds the creators back too much. First the classes have to be designed and built to put together the basic components needed to build anything and C/C++ is single threaded to the bone. GUIs and their apps need to be built in languages that are more supportive of concurrency and that needs to be in the language as a 1st class entity, not tacked on by building in threads objects later. In effect, the event queue that most GUI kits build on top of C/C++ is already in the parallel languages and done much better.

When I compare the APIs of BeOS, Win32, MacOS, Java, and others I see alot of similarities but no consistant clear path as to how these things should be built. Why do apps that look incredibly simple in the developer sample folders require so much house keeping code to make them work properly. Hence why we see so few apps on OSes for which there is less traction whether commercial or open source.

The line that I am thinking along is to take plain C with simple classes and add concurrency by adding signal ports to each class that makes it into a process or module with live signals that really acts like a physical object. Creating hierarchies of these is pretty straight forward too. This language already exists in the chip design space and is called Verilog and another called VHDL but these are not C like enough and are too big. They do have concurrency as 1st class though and creating communicating hardware hierarchies is easy in these languages. Ironically Verilog is moving towards C by adding much of the old C language datatypes. By starting the other way around and taking a simplified C++ and adding the parallel capabilities of Verilog I think we would have a par language that would make building much more interesting OSes and GUIs a charm.

There is another problem and that is the whole file system issue of multiple references and broken symlinks. Filesystems need to support the notion that a file contents is separate from the place that you view it ie it is viewed through a reference and that allows multiple views/references that are all equal. Once you have that type of file system the file system hierarchy can then be exploited to build the components into bigger things. An app is then equivalent to a folder of components and refs to other smaller nested parts. So a scrollbar for instance is simply a sub folder in the OS path, and has refs to more subparts plus a process-class-module that describes how it communicates with other parts. Now the hierarchy of a program construction follows the same hierarchy as the directory objects it is built from very similar to the way chip designs are built. Ofcourse this would be initially quite slow but caching would hide delays after some use.

thinking out loud

transputer guy

Reply Score: 2