I am wanting to get started with creating a gui (graphical user interface) operating system, but i have no idea where to get started, i would like to code it all in assembly using FASM. if someone could post an example or tutorial on how to get started, it would be a big help.. thanks

Down load my CdPod, this is a very basic gui, come with fasm code, vesa, pmode, cdplayer,keyboard input, fonts etc.
and fits on the bootsector of floppy 512bytes.
its called CdPod.ZIP get it here:
http://board.flatassembler.net/topic.php?t=2164&start=50

You will not get a much simpler demo .

PS: needs vesa 2 and one that users 32bit (not 24bit )most vesa2 use 32bit now.

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

You can check SOLAR OS code (the GUI part)
http://www.hostileencounter.com/os_main.html

I can explain you the GUI concepts, it is not very complicated

For a start:
-you will need to be able to create windows with at least properties: type, x,y,dx,dy,caption, a list of childs
-you will need to be able to draw such windows in an orderly fashion
-you will need to be able to click and select/bring to front
-you will have to drag/move/resize such windows

I noticed from ASHLEY4's CdPod that the drawing for the "CdPod" is done in assembly, can the drawing be done from an image, then called upon in assembly? .... what i mean is, can you create an image of what you want, say a .jpg or .bmp picture, then in assembly, tell it to draw that image on the screen?, without having to draw each pixel in assembly. ... thanks everyone

hehe, can I cause some noise here?

The GUI should be easy, ie, you only represent graphics, the GUI englobates much things Graphic User Interface only say that there is a graphic way for users to interact with the computer, but dosent say nothing about the background. Also dosent say nothing about the functions used, how is it, and others things.

The point, pheraphs you are thinking only in plot some on the screen and peraphs interact a little whit was is in the screen, but you should note more acurately that the Graphic User Interface is impacted by the hided things that the developer of such Interface should take care, the data structures used, the handling of them, the timing, the selection of the correct methods and naming, etc. all this will not oly impact the Final user of a application, but also would Impact how a person do use Your methods for do a graphic application.

dont know, but I guess you can copy blocks of memory, if you have already drawed teh image, also pheraphs is the called swap of buffers.

The GUI is never easy, there is no real tutorial, and no real algorithms for doing this... you need to discover yourself.

Of course backbuffering and swaping buffers as a concept can help drawing without flicker but there is much more to it that THAT simple algorithm.

IMHO the Solar OS GUI shows how to do this pretty good...
but unfortunately i have not yet written a tutorial about it.

But i will kindly answer any questions about modern GUI creation.

Yes i know that I have made some decisions in order to simplify things at start but nobody said that you should make the same decissions also. There is no conceptual limitation in Solar GUI. With a few small modifications you can easily make it the best GUI arround... maybe i will do that someday

IMHO before starting the GUI you will need:
================================
- a stable and functional protected mode 32 bit environment
- mouse and keyboard functional drivers
- graphical mode initialization done ok (i assume VESA) and a LFB pointer
- some basic graphical routines for:
--clear the screen
--draw some text on screen (+fixed pitch bitmap fonts for a start)
--draw filled rectangles on screnen

I has started with just clearing the screen and drawing the mouse cursor over it each frame, then i have made my first windows and made them interact with the mouse (select and bring to front ,move,resize)

All this was done in statically alocated memory for a start...but later on i have moved into using dynamically allocated memory (a must for a GUI) but that would complicate things too much for a start.

Doing everything in small steeps is very important, and understanding the process is also.

Keep thing functional at all times because this gives your brain the much needed gratification.

Do not plan in advance too much because it is very unlikely that you will get it right from the first try...

It is not going to be simple, and is not about just drawind an image on screen... it is much more ...

I think a good memory manager must be present before one starts coding the gui...

To me you should have a fully functioning CLI OS before even thinking about GUI, Once you have that, you need to look to the future, not go with the GUI we have now.
To me this means MENU's, as in not using the mouse as much, this may seem strange, but let me explain.
PC are moving from the desktop to the living room, car, mobile, kitchen etc.
we have PDA, mobile phones, Game consoles etc.
Mouse is not good for uses with this new environment, menus work much better in this environment, with menu you can use remote controls, keyboards, joypads, buttens

Even M$ has had to add this to XP, with the media centre.
A skin able GUI like the XBOX dash, but for a desktop OS would be good.

As people use devics like PDA, mobile phones, Game consoles and get use to menu, they will want them on there desktops, so be ready .

PS: Redragon, you can use bmp, jpg etc,for a skinable GUI, i did it in assembly code for size.

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

Roticv,

Not exactly... after all you are testing a GUI and not a memory manager

But I agree, you will need a memory manager pretty soon in GUI development...

However you do not need it at the start
Since you do not know how your GUI will develop --> you do not really know what kind of memory manager you will need

Yes, altought you can start doing "some experiments" in mouse input, kb input, timing and generation of events (altought the events are there, you only need to clasificate them when is proper to do that).

Handle the time for dont flod events is nice I think .

does anyone have an example of how to show a picture, by telling it to show a .bmp or .jpg file? like how ASHLEY4 explained it:

"PS: Redragon, you can use bmp, jpg etc,for a skinable GUI, i did it in assembly code for size."

thanks everyone!

Redragon, in my os you would do this to show a bmp.

Here's a link to a skin able interface: http://eboxy.sourceforge.net/
Also check out thing like winamp skins, xbox dash skins etc.

PS: Remember that a bmp is big in size and you would not get many images on a floppy.
so you would need a compressed image format or a atapi driver (cd/dvd).

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

I was wondering with that code,is it using FASM? also which part of it defines the name of the picture?, and what else is needed to make it compile?.....thanks!

Hi, yes its fasm, here how it works

The above code is used with my OS atapi driver, where its loaded from the cd.
you can get a iso and burn it to a cd to try it, it call "DemoVesa.zip
http://www.falconrybells.co.uk/

Heres a screenshot ( a bit dark).

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

I was going to try that on a cd, but my only CD-RW decides its not gonna allow writing to it anymore so, ill need to stick with a floppy for now. Can that code be used for a floppy, if the bmp was small enough? Also, can the code you provided be assembled the way it is, and load a default bmp file that is included with it? If anyone wouldnt mind, it would be very greatly appreciated if someone could make a basic downloadable example, that displays a bmp, and boots from a floppy, with the source code included ( to learn from ).. thanks very much everyone ... sorry for all the questions ive asked, im new at this..

Yay my screenshot.

It was dark due to poor lighting and use of the flash. Thats why I put a second pic on.

If you look carefully on top of the ice cream container there is my fish mouse pad!

Also next to the closeup the is a toy. It might be a plush toy or something?

Jas20

EDIT: IT HAS CAME TO MY...what....of sorry... attention that I got the meaning of light and dark mixed up. Opps!
--
I've been quite invisible here.

jas20, I did not mean dark as in no light, but as in evil, or the darkside .

\\\\||////
(@@)
ASHLEY4.

Batteries not included, Some assembly required.

i'd code a gui like linux. linux itself is no gui. linux is only the kernel. the gui is kde. and the kernel handles the basics, like multitasking, switching and loadings drivers, and the kde only draws the outputs to the screen. i'd NEVER code both together. first code a kernel, which supports an fs and mt (multitasking), than you're able to organize the data, which is the job of the kernel. then you can code the other things, like the gui, because it runs like a programm. it shouldn't be the os. it should only put out the outputs, and give the inputs to the kernel, to work with it. that's what i think... and that's the way, i'll go.