i'm working on my own os for 4 month now. i have some things done but i don't know whats the better way to move on. i had 2 ideas of building things up. i've chosen the direct way - first writing the bootloader, switch to pm and initialize and launch the os.

now the 2 ideas:
1. i have already implemented some drawing (on vesa-gfx-screen). so, what about directly setting up a gui with some nice buttons, then an allocator, then some disk access and some more hardware, but everything with fixed memory addresses (i.e. windowing information at 0x00010000, programs starting at ..., stacks at... and so on) - things will seem like windows. it won't be possible to run without gui, or
2. going back to textmode. making things universal with some kind of multiple consoles which can run a single task. then implement the diskaccess and some commands (dir, cd, launch programs, switch between consoles). the gui will be a program which can be launched once (more than once?) from the consoles. on this gui more programs can be launched. this will then look like linux.

i'm still thinking about something.. new.. something different but i can't figure it out.
the questions:
which one of the ideas mentioned above is better? i think i can implement both of them.
has anyone this new idea i'm searching for?
Posted on 2003-06-07 12:24:19 by hartyl
For my own internal reasons i have choosen version 1) from above

SolarOS already has a GUI, and we are now going for HDD acces ...
I can still use text like mode insode a "console like" window... Actually i guess hawk is going to do that soon

I never did liked an OS without an GUI, even if i can understand the needs and uses for such things.
Even in my Forth systems i tryed to implement a gui ... so i guess i am an GUI oriented person.

However i have tried to tough almost all aspects of an OS in my implementation because otherwise i could find myself redoing things at half way... not my case as i have huge experience (hihihi and i am modest also)

To avoid this i like to keep it functional at all times and "let the water follow the path and fill in the caves"

There are many pre-thinkings out there that are just plain wrong IMHO (like paging and virtual memory and preemptive multitasking :P)
Posted on 2003-06-07 12:41:57 by BogdanOntanu
i have thought of another question related to 2.:
in order to have consoles in textmode and a windowmanager-app in vesa-gfx i'll have to switch the grafics. how's that done? i.e. in pm i can't call int 0x10 anymore.
so, the questions:
does calling int 0x10 need the ivt in realmode? if so, i guess it's located at 0000:0000, but i overwrite it with my one. or is this one mapped directly somewhere else? where's the code which is executed when calling int 0x10? is it then enough to temporarily switch back to realmode, call some ints and switch back to pm? or can i walk around this problem with some i/o ports, i.e. is it possible to switch between gfx- and textscreen with ports?

yes, these are the questions spinning in my head :)
Posted on 2003-06-08 05:21:49 by hartyl
The code that gets executed is in the BIOS. It is possible to change graphics mode by accessing the hardware registers - that is what the BIOS does. The 'correct' way is the set-up a call gate to execute 16 bit code and preserve the BIOS functionality -- this assuming that you don't have a PM driver for your video card that executes under the OS.
Posted on 2003-06-08 11:06:35 by bitRAKE
so, i can create a call gate to a 16bit segment where i can put my code. there i can simply use the int 0x10? would be brilliant - please confirm.
Posted on 2003-06-08 12:38:59 by hartyl
Yes, 16-bit code can be called that way. INT 10h executes the address that is in the interrupt vector table - which should have been preserved. It's been a few years since I've studied this, but I do know it is possible.
Posted on 2003-06-08 13:06:37 by bitRAKE
ya, that's the problem i've thought of. is the ivt located at 0000:0000 at bootup? it is just a list of words as pointers to the functions i think. unfortunately i overwrite this ivt with my idt (created dynamically)... i currently use the first megabyte in the memory. so, just preserving this one word of the ivt and calling it is enough?

at bootup:

mov ax,[0x0014]
mov [int10ptr],ax

and then when calling in 16bit callgate:
call [int10ptr]

but i still want to reference to my initial question: which of the 2 ideas mentioned is better? which one is the better one to develope?
Posted on 2003-06-09 03:54:22 by hartyl
Personally, I'd ditch the whole text mode thing, but it all depends on the lowest system you want to support. VESA compatiblity seems like a good start. The only text that should display in text mode it to let the user know the OS is loading. :) I don't miss 80x25 (or lower) two color displays one bit!

Most the implementations I've seen preserve the first one meg for legancy 16-bit support - you can't be certain what the BIOS requires in 16-bit mode, or what other functions it will call.
Posted on 2003-06-09 04:30:24 by bitRAKE
ok, i've decided. i'll move on with idea #1.
but... not that the thread ends: how do i set up a gui?

u know i've already started doing that. now i know that i'm on the right way. i had the following ideas to implement:
- use a fixed space to save the windowing information (64kb sould be enough).
- i save the position, size, some flags, owner, owning process
- via mouseinterrupt the windowmoving is done - but just in the memory (sets a flag for the window to draw).
- some kind of main-thread (os-loop) checks for redrawing.
- drawing is done by checking for every pixel wheather it is on top (i.e. nothing is over it)

but the drawing is the slow thing (i think). checking for every pixel is damn slow.
how can i better implement the drawing stuff? is there a better way?
Posted on 2003-06-09 13:54:01 by hartyl
here are some ideas for you

may be you can out do any OS out there
Posted on 2003-06-09 21:09:10 by rob.rice

before thinking about GUI I'd start width memory management and multi tasking
thoughts. These are the points some of the I-want-my-own-OS-coders reject for later.
Ofcource drawing your own windows might be fun but it's not necessary to
develope your own OS to do this. Some points to think about now are:

- memory management system (paging, free memory bitmap or page stack)
- multitasking (preemptive, time slice, interrupt-driven, processor support)

Bye Miracle
Posted on 2003-06-10 07:01:28 by miracle
actually i paused developing the os currently - i don't feel like doing it now, but it will come back soon since i'm very interrested in it.
paging is one of those things i don't even want to create (ok, i don't know much about it. isn't it that thing where you can say "this 4kb-chunk is now accessable with this address"?). preemtive multitasking already works (timer interrupt). i can create threads dynamically - a sceduler is what i want to make. the os sould work for all 386er or higher.
i thought of writing an allocator to reserve memory which can be accessed by the selectors.
you're right, writing a gui seems to be fun. when i get a clear idea of how i set it up i'll finish it... do you have one?
Posted on 2003-06-10 13:36:17 by hartyl