OSDev.org

I'm not really a osdever at this stage, but i wonder if anyone ever copied the look of Windows 9x. I know that this is so complex, but did anyone manage to get it "part" done? May i see some possible screenshots?

ReactOS?

Yeah one that isn't ReactOs.

Were you talking about LikeOS?
http://forum.osdev.org/viewtopic.php?f= ... 62&start=0

GUIs are pretty complex. It also gets really messy when doing it with C. Thus, not many out here have a OS with a running GUI.

Copying something else (in this case Win9x) is really boring, as we're creating our own OS. You'll see some fancy custom GUIs, but almost no copies.

no92 wrote:GUIs are pretty complex. It also gets really messy when doing it with C. Thus, not many out here have a OS with a running GUI.

Copying something else (in this case Win9x) is really boring, as we're creating our own OS. You'll see some fancy custom GUIs, but almost no copies.

And having utterly different and incompatible UIs in different OSes is all exciting and refreshing. Not.

SeanMc wrote:I'm not really a osdever at this stage, but i wonder if anyone ever copied the look of Windows 9x. I know that this is so complex, but did anyone manage to get it "part" done? May i see some possible screenshots?

What do you mean by "copied the look"? If you are talking about just appearance of windows, then there are a lot of GUIs with similar design: from extreme perversions like Miraculix and KolibriOS to GTK themes "Raleigh" and "Redmond". It's rather simple to draw similar rectangles.

If you mean deeper things (e.g.: queue of WM_ messages for all kind of events, or maybe organization of virtual folders such as "My Computer", "Networking", "Control Panel", or maybe Active Desktop), then you should be more specific, please.

By copy i specifically meant the appearance of specific GUI objects like the 3D borders framing the windows.

And if you implement a unique GUI, wouldn't it be difficult coming up with a unique design. I can imagine copying at least some elements of an existing GUI design to make things a bit easier on me. Then again, I probably shouldn't be talking here yet.

alexfru wrote:

no92 wrote:GUIs are pretty complex. It also gets really messy when doing it with C. Thus, not many out here have a OS with a running GUI.

Copying something else (in this case Win9x) is really boring, as we're creating our own OS. You'll see some fancy custom GUIs, but almost no copies.

And having utterly different and incompatible UIs in different OSes is all exciting and refreshing. Not.

"Creating our own operating systems is exciting and refreshing. Not."

Be careful what you say. We all have different passions.

SeanMc wrote:By copy i specifically meant the appearance of specific GUI objects like the 3D borders framing the windows.

And if you implement a unique GUI, wouldn't it be difficult coming up with a unique design. I can imagine copying at least some elements of an existing GUI design to make things a bit easier on me. Then again, I probably shouldn't be talking here yet.

I think there are times when we can't inevidably help but copy what is already done - maybe because that way is familiar, or it is actually a decent way of doing things.

I've been working on a tabbing/tiling window manager- where most windows can't overlap (like with a stacking window manager). I needed someway to 'grip' a window or dialog box (without clicking the contents inside of it), so my windows have a header tab that functions look and function like a title bar. I'm not trying to copy other GUIs, it's just the best way I could come up to represent what I was trying to do.

That is done through composition.

I AM USING C++ IN USERLAND -- IT IS TOO MESSY TO DO IN C

So this is how i do it in my OS.

You have "layers". If you'd done any Phoshopping, you probably know what I am talking about.
So basically every object on the screen that you can move is a layer.
A window is a layer, a text is a layer, a button is a layer, ...
And basically this is how this is done:
1. You make a structure to represent a layer (I use classes... I put every GUI stuff in userland)
2. You write algorithms to move the layers when they are overlapping. Every layer will have a parent, which can either be a parent or a Screen, the representative of the entire screen. The algorithms will figure out which pixels were overwritten by the layer in its parent buffer and "restore" those pixels that are "freed".
3. You take this structure (again, I am using classes as my compositor is a class library) and extend it into different things
For instance,
Layer --> Button
Layer --> Window

A window will have more stuffs added to it, like title header, bgcolor, exitevent, ... just don't go too wild on it.

So as I told you, a layer's parent could be another layer, in which case the layer is a "sub-layer", a layer bounded inside of a layer.
So a button will be a sub-layer of a window and so on... And when a layer is moved, all of its containing sub-layers must also be moved. (you don't want want a button to be stuck in a corner without the window after you move the window)

This is not the Win 9.x approach, I assume, but mine works quite fast and smoothly.

P.S. If you have userspace and executable loading procedures, I highly recommend you to NOT put ANY gui-compositing-related stuffs into the kernel. You should only keep low-level routines (like vm86 mode switching) in the kernel and pull all the high-level (things that can be implemented without hardware access) stuffs out to userland. I am using a library structure where apps will be dynamically linked against my window-compositing library.

Hope it was helpful!