OSDev.org

I finally decided to get rid of dealing with stupid bootloaders so I just got GRUB and all is going good. A wrote a hello world kernel in C and it loads and everything is working great.
But is there a way to make a graphical user interface in assembly? I mean, I wouldn't like my OS to have a text based interface.
Any help anyone? Thanks

Hello,

omar wrote:I finally decided to get rid of dealing with stupid bootloaders

Modern boot loaders incorporate many of the fundamental operating system concepts including memory management and drivers; some of which are as complex as little operating systems themselves. It is highly recommended to change this tone if you want to survive in this field.

omar wrote:so I just got GRUB and all is going good. A wrote a hello world kernel in C and it loads and everything is working great.
But is there a way to make a graphical user interface in assembly?

Obviously, yes. If it was not possible in assembly language, it certainly would not be possible in higher level languages. Graphical user interfaces however are really complex and are tailored to object oriented design.

omar wrote:I mean, I wouldn't like my OS to have a text based interface.

Why not? Providing a text based console is very important and provides scripting functionality and command line tools that are more suitable and simpler to use as back-end tools rather then integrated in a single graphical application.

omar wrote:Any help anyone? Thanks

If you have to ask, you are not ready. Seriously.

Your original question (How to make graphics) also has nothing to do with graphical user interfaces at all. There are many layers of software to be written, including but not limited to,

1. Video driver
2. Driver communication and command control
3. Higher level Graphics Device Interface
4. Window Manager and GUI services

The video driver would communicate with the device itself or the firmware and provide video controller services such as frame buffer and vertex buffer command lists, video memory mapping and supported video modes. Note that video modes may be available that the monitor does not support. You would need to implement this through Extended Display Identification Data (EDID) to get monitor device information. The video driver may also use the firmware and provide Video BIOS services such as VESA Bios Extensions (VBE) that may be used.

Hobby operating systems typically just set the video mode during boot time however you can also use firmware services yourself.

Of course, you would need a way to send command lists to the video driver. This would be handed by means of Inter-Process Communication and how the operating system sends Requests Packets. Of course, the driver should be able to use other operating system services as needed, such as allocating a heap store or mapping memory and device registers.

In your case I would just tell GrUB to set a video mode for now and write a video driver around that for now. This would of course mean that you cannot change video modes and also ties your operating system to GrUB.

The Graphics Device Interface should provide abstract graphics services that are independent of the graphics driver. And the Window Manager is your Graphical User Interface. It is responsible for using the GDI to perform device independent rendering to the active video driver across monitors and mapping window coordinates to normalized device coordinates.

In other words, slow down. If you try to jump into graphics too early, you will not make it. Build a strong foundation first before attempting graphics. You could hack it pretty easily, but if you want to write a good graphical user interface you really need to plan properly.

To actually render, the program sends the request to the operating system which passes it to the GDI. The GDI translates the coordinates to device coordinates, builds the command list and sends it to the device driver for render. The device driver renders the contents to the frame buffer which is what you see on screen (well, a part of the frame buffer main window, anyways.)

The video driver renders to the frame buffer by just writing or reading to it as its mapped to the address space. For example, if the video card is configured in VGA mode, the frame buffer will be mapped to 0xa0000 linear. Higher video modes are mapped between the 2GB-3GB range in the physical address space. VBE gives you this info, but if you use GrUB, GrUB will pass this to you so you can render. Most video cards use linear frame buffers (LFB) for high resolution modes so reading and writing them is pretty straight forward - however not always which is why abstraction is important.

Rendering of graphics primitives is a completely different topic of its own so wont discuss that here unless requested.

I would also recommend getting comfortable reading the mouse input before you switch from text mode to GUI mode, because it will be easier to test and troubleshoot in text mode.

Reading from the PS/2 controller is a bit of a headache, so you should probably spend a few days to get the mouse movement (x, y coordinates) and button states (left, right, middle, etc.) working.

Just a suggestion...

Hello.

There are some costfree documents in the public section of vesa.org (need register/login) about to use the VBE-Bios and for to get the monitor informations(EDID).

vbe3.pdf
EEDIDguideV1.pdf
EEDIDverifGuideRa.pdf

Dirk

neon wrote:Why not? Providing a text based console is very important and provides scripting functionality and command line tools that are more suitable and simpler to use as back-end tools rather then integrated in a single graphical application.

I kind of agree with you but, however, I am not so sure why I do that. A text console is something that we take very much for granted. If we made a design decision of not having it, it might help us to come up alternative ideas that may or may not be better. If we still had the text console, we might want to change the very intrinsic features of it, e.g. not allowing a "freely-formatted" input that requires parsing.

Another argument against the command line tools is localization. It is almost impossible to have commands, e.g. "copy" or "move", localized. Output messages can be localized but the command names and command line parameters are still English-only.

Hi,

Antti wrote:

neon wrote:Why not? Providing a text based console is very important and provides scripting functionality and command line tools that are more suitable and simpler to use as back-end tools rather then integrated in a single graphical application.

I kind of agree with you but, however, I am not so sure why I do that. A text console is something that we take very much for granted. If we made a design decision of not having it, it might help us to come up alternative ideas that may or may not be better. If we still had the text console, we might want to change the very intrinsic features of it, e.g. not allowing a "freely-formatted" input that requires parsing.

Another argument against the command line tools is localization. It is almost impossible to have commands, e.g. "copy" or "move", localized. Output messages can be localized but the command names and command line parameters are still English-only.

In my opinion, users don't want to use the command line at all. What they want is applications and tools with decent/graphical user interfaces, plus the ability to write scripts that control applications and tools.

Of course users tend to get what they're given. It's the programmers responsible for creating the applications and tools who prefer the console; partly because stdin/stdout is easier, partly because most OSs don't have good support for "scriptable graphical interfaces", and partly because "plain text" ideas (originating in 1950s mainframes) are a fungal disease that causes terminal brain rot and spreads spores everywhere it goes.


Cheers,

Brendan

The only scenario you want a text-based console is to ssh into remote host, which a graphical (VNC) may just require too much bandwidth.

Take mac for example, most the functionality of the shell can be replaced by node-based automators, you can possibly get rid of the shell and do thing the "GUI" way.

Hi,

bluemoon wrote:The only scenario you want a text-based console is to ssh into remote host, which a graphical (VNC) may just require too much bandwidth.

Take mac for example, most the functionality of the shell can be replaced by node-based automators, you can possibly get rid of the shell and do thing the "GUI" way.

Yes.

The funny thing is, if you look at the VNC protocol you'll see that (for graphics) it works by rendering pixels on the server and sending the resulting frames to the client. This means the bandwidth needed is a lot higher than it would have been if the server sent (e.g.) higher level "list/s of commands describing what to draw" (despite compression); and that the GPU in the client is mostly wasted/unused; and when the server is talking to several clients it struggles to cope with all the rendering involved.


Cheers,

Brendan

Without wanting this thread to turn into a GUI vs. CLI flamewar, I believe both have their place in a modern OS. It's not a one-or-the-other choice.

As an aside, a keyboard has over 100 seperate inputs. A typical mouse has two or three buttons, a scroll wheel and a 2D directional input. It's often far quicker/easier to type what you want than it is to select it with a mouse. Whether you have a command-line or not, don't neglect the keyboard!