Enter the Qube, a New Graphics Environment for CLI OSes

Qube is a multiplatform Desktop Environment with support for networking protocols such as TCP/IP, PPP, SMTP, HTTP etc. developed from scratch by Interactive Studio. The Qube environment was designed for a wide variety of console operating systems and it’s designed to be easily portable. It supports multitasking even on non-multitasking operating systems, such as DOS. The basic installation occupies less than 4MB of disk space (download the DOS package) and it looks very attractive (check for screenshots inside) with GUI elements coming from the MacOS (buttons, launch bar), BeOS (icons), Windows (desktop’s context menu style) and even Java (scrollbars). Today, we host an interview with the mastermind behind Qube, Michal Stencl.Qube was created by a single person – Michal Stencl (22), during the past year. He started to work on desktop environments in general when he was 15 years old and he released his first one, with its own executable format applications, called “Unfiroms”, two years later. The second environment was called SEAL and was released 3 years ago for MS-DOS and it’s currently distributed by default with the FreeDOS package. Michal Stencl lives n Bratislava, Slovakia and he is the Winner of the Grant Programming Competition in his country.

OSNews: So, what is Qube really? Is it an OS inside the OS, or a graphics Toolkit?

Michal Stencl: It’s something like Windows 95, not a real OS, but it’s able to be ported to all console systems and it takes less than 4MB of memory. Something like GUI with support of its own executables files.

OSNews: Do you think it will be easy to port it on Linux as well?

Michal Stencl: Sure. I think it should not take more than 2 weeks altogether.

OSNews: Will the executables for the DOS Qube will be the same under Linux, or they will need recompilation to meet the ELF format? (Windows is using PE)

Michal Stencl: No. These executables are not the same to Windows. Qube is using MX binary file format.

OSNews: So, no recompilation will be needed between applications for the Linux Qube and the Windows Qube?

Michal Stencl: Yes, Linux and WIndows Qube applications will be the same ones, but the Windows and Linux engine of Qube will need to be recompiled. However, we should not forget that Qube is not a Windows application, it’s a DOS one in its current form.

OSNews: Will you release an SDK for Qube?

Michal Stencl: Sure. We released API/SDK, but it takes some time, because we need to prepare more documentation. At the end of this week we will upload the Qube SDK – WIP (work In Progress) that will help people understand the architecture of Qube and will allow them to create applications for the Qube environment.

OSNews: What is Qube aiming for? Does it aim the embedded market, or the Desktop market?

Michal Stencl: It’s aimming at both. But because of the big tolerance for small embedded systems it’s better to first aim the embedded market.

OSNews: Are you currently using VESA on Qube? If yes, I have to say that your implementation was quite fast and it even featured transparency.

Michal Stencl: Yes, We use VESA, no accelerated cards.

OSNews: Does your GUI Toolkit support arbitary shape windows ? (non-rectangles that is)

Michal Stencl: Yes, it supports them. The best way to see the support of arbitary shape windows is look at icons. Icon is an object like anything else in Qube. Qube was designed to be able to insert views to other views and to objects as well. It’s a little different idea to put everything into everything. Imagine Windows, if you need to put the object to another one, you must select if it’s a child or main window. You can’t insert visible object to unvisible such as events or drivers.
Qube was designed to easily put one object to another, the developer should not care about object properties. There is ability to insert windows to buttons and buttons to icons. There is also a ability to insert window into the object that corresponds to an event. It finds its parent by looking for the parent of the event.

OSNews: IS Qube and its SDK accessible through C, C++ or Java? In which language it was written on?

Michal Stencl: Qube SDK will be accessible through poor C, C++ is optional, you can use C++ to make programs in Qube as well. We think about making something “like” MFC for Qube as well. Anyway, Qube has been coding in C, but there is an object oriented foundation behind it. It supports structures like objects, where each structure contains variables and functions. These functions are not real functions, they are pointers to functions. This way you can change everything you want in low-level and high-level objects as well. You can change behaviours of of all objects such as buttons or windows in RUN-TIME. You can redirect graphics/disc output to modem output for example. This is only one example of what Qube can do. There is also the ability to change anything in the run-time. If you would like to make own object that’s derived from button and would like to use it for all buttons in the environment, you should only change the initial function that creates the buttons and prepointed this function to yours. Whenever some applications will create the button, your button will be drawn.
Lets see how this works :
Imagine a view that has predefined behaviours by Qube. This is the same like in the OOP idea. But, what’s different is that you can change these predefined behaviours by objects that are loaded after the definition of these behaviours. You can change that, because functions inside these objects that defines these behaviours are pointers to functions. So, it gives you an advantage to prepointed them to other functions (still with me?).

I had a discussion recently to support Java for Qube soon, but we are sure C,C++ will still be dominand.

OSNews: Are you planning to add a full networking stack that will support networking cards? How about a browser?

Michal Stencl: Yes, mainly under Linux systems though. Qube was released for a wide variaty of operating console systems, but there is possibility to support more systems that are a lot different among them. Qube architecture is the following :

(system depended functions of OS) -> LOW-LEVEL API -> HIGH-LEVEL API -> LIBRARIES AND MODULES -> APPLICATIONS

The Qube engine supports everything for creating a desktop environment with network protocols and multitasking. The original idea was to skip problems with development of GUI engine for alternative console OSes. Anyway, you have a choise to only support the OS you want and Qube will make sure you have all you need for that particular system. There are differences between other OSes which can break compatiblity, but Qube will be able to load, at run-time, certain modules which can extend your current system. If you will not add these features, your system will run as default.
Example :
Under Linux, we can support LAN cards and redirect functions that handle communation to be able to connect through LAN. When you start at DOS mode, these features will be disabled and the system will still run correctly, but without LAN support.

A browser for Qube is not available yet. We are still working on and welcome all ideas to port other browsers for our environment.

OSNews: What kind of filesystem Qube uses? Can Qube “see” and execute files from the host Operating system?

Michal Stencl: Qube was designed to have the same style of filesystem under all OSes, without trying to change the filesystem of the host OS. It doesn’t make any virtual FAT tables on disc or something. In the root directory of Qube some *.DEF files can be found. These files are used for information about paths to important directories for Qube. These directories are placed in Qube ROOT directory such as TRASH (trashbin), DOCS (documents), DESKTOP (for desktop files), DEV (for devices, cd, hd, floppy, etc..).
Example :
Imagine that “host.def” file in ROOT directory of Qube contains string “C:\Qube\DEV”
and “_hd0” file is placed in “C:\Qube\DEV” directory contains string like “C:\”

When you call an open function through Qube API that have to open file “hello.txt” on your C drive, you need to select path as :
“localhost://_hd0/hello.txt” – this string will be parsed by the API to “C:\hello.txt”.
If you change “_hd0” file in C:\Qube\DEV directory to “a:\” you will open “hello.txt” file on your floppy.

We use some technology found in existing protocols as you can see. Each prefix such as “localhost” or “desktop”, “memory” define protocol and are supported by functions that returns the correct place of files on the filesystem you are working on. These protocols are defined by pointers to functions that can open, close, find, write, etc… files on devices you need. You can support your own protocols and register them through the API. All high-level functions will now be able to communicate with the same behaviour as before.
This is how Qube can see all files on your filesystem and will be able to open and write these files as well, without changing anything in the host OS.

There is a (future) possibility to run specific executables on each platform by redirecting of few system functions in low-level API.

OSNews: In your papers you say that Qube brings multitasking, even if the host OS does not support multitasking (as in the DOS situation). Please talk to us about the back end of Qube, technically-wise.

Michal Stencl: Qube brings multitasking using the same trick that Windows 95 uses. It’s not the same under NT or Linux though. It was important to support Qube on non-multitasking operating systems as well (like we do in the DOS case). All of our applications, objects and views receive events from the Qube engine. You can work with many applications at once and can you select periods in miliseconds of receiving these events for your objects, but applications are not based on own stack size.

OSNews: What are your future plans for Qube?

Michal Stencl: We would like to port Qube to embedded Linux in the near future and enter the embdedded system market too. Qube can be very useful for companies and people who need to use and add a nice graphic environment with Internet support into their own systems.