OSDev.org

New version uploaded (link in the first post).

Finally gotten around for a test run on real hardware. Without success unfortunately:

Warning: Cannot switch to the graphic mode specified in the configuration
file. Use 800x600x16 by default.
Error: Cannot switch to graphic mode.
Press any key to restart your computer.

The machine is Amalthea, and the ATI card in there can very well do 800x600x16...

Combuster wrote:Finally gotten around for a test run on real hardware. Without success unfortunately:

Warning: Cannot switch to the graphic mode specified in the configuration
file. Use 800x600x16 by default.
Error: Cannot switch to graphic mode.
Press any key to restart your computer.

The machine is Amalthea, and the ATI card in there can very well do 800x600x16...

This is really strange, I scan the modes list in the VESA block for 800x600x16 mode, by checking its attributes
after a INT 0x10, AH=0x4F01.

0.0.251: the mouse is broken in VirtualBox again; had been working since the version after the original original post.

Also: I really liked the Lavender look and feel; also, are there plans to have windows only movable by title bar? If a window can be moved by just dragging any part of it, it may become annoying to the user if they tried to click an icon but missed.

Cool job there.

Tested under VPC.

Hangin10 wrote: 0.0.251: the mouse is broken in VirtualBox again; had been working since the version after the original original post.

Ouch!

Hangin10 wrote: Also: I really liked the Lavender look and feel;

Lavender is the color shceme of the very first releases of Hydrogen OS. I kept it because I love him too.

Hangin10 wrote: also, are there plans to have windows only movable by title bar? If a window can be moved by just dragging any part of it, it may become annoying to the user if they tried to click an icon but missed.

This problem will be fixed in the next release.

EDIT: fixed in 0.0.252

Nice OS you have here.
The xwindow system is pretty complete aside from some minor bugs.

- Sometimes they won't minimize unless you maximize?

The biggest problem is the lag,
In Boch I gave it 256 MB of RAM and it ran at 0FPS...

VPC is much better runs at 30-60FPS without any programs open.
With all available programs open it runs at 31FPS solid.

I know that it's not really your fault cause VESA is pretty slow in the first place but I'd go and try to optimize your VESA driver as much as possible.

But nicely done. Good luck. ^-^

Did another try with the current version - graphics now works , but I now get a PS/2 mouse driver initialisation failed on real hardware...

Won't boot on my Pentium D E5200 with P5QL CM motherboard, the OS hangs on the PS/2 mouse driver initialization, which makes sense as this motherboard has no PS/2 port for the mouse.

Ferrarius wrote:which makes sense as this motherboard has no PS/2 port for the mouse.

Read on the OSDev Wiki: A USB mouse generally emulates a PS2 mouse, except that it generates IRQs from the USB bus, and not IRQ 12.
So, even if you haven't any PS/2 port on your motherboard, a PS/2 mouse driver works.

But I agree, my mouse driver needs some fixes...

Tommy wrote:...
Read on the OSDev Wiki: A USB mouse generally emulates a PS2 mouse, except that it generates IRQs from the USB bus, and not IRQ 12.
So, even if you haven't any PS/2 port on your motherboard, a PS/2 mouse driver works....

Well, then "The Wiki" is wrong. Even in the part that it is corect it is still misleading and partly wrong.

This kind of partial and misleading information is not uncommon for Wiki's.

You probably do need a timeout for the mouse initialization routines

bontanu wrote: Well, then "The Wiki" is wrong. Even in the part that it is corect it is still misleading and partly wrong.
This kind of partial and misleading information is not uncommon for Wiki's.

Whether true or false, my OS works fine on my laptop, and I use an USB mouse.

bontanu wrote: You probably do need a timeout for the mouse initialization routines

I use timeout during mouse initialization. And I want to understand why my driver does not work
on some PCs. It is very difficult, especially when everything works well on its hardware.

Tommy wrote: Whether true or false, my OS works fine on my laptop, and I use an USB mouse.

My PS/2 driver also works on my laptop with an USB mouse until I enable USB host controller. However this does not make the statements in the Wiki true. It just looks like that but the errors are still there (multiple errors mixed with one single true statement).

To point you at one of the errors: there are many motherboards/BIOS that do NOT support PS/2 mouse emulation for an USB mouse. On such motherboards a PS/2 mouse driver will not work at all... period.

I am vague because I do not intend to correct the other errors in the Wiki since I dislike the Wiki ... apparently for good reasons. And people here have a tendency to copy what is said in forum threads as absolute truth for the Wiki.

Tommy wrote: I use timeout during mouse initialization. And I want to understand why my driver does not work
on some PCs. It is very difficult, especially when everything works well on its hardware.

Good to hear that you use a timeout. Then the OS should not hang/crash if the PS/2 mouse hardware is not present and not emulated?

Yes this "works on my PC" kind of problem is a part of OS Dev and programming in general. For OS Dev you must test on multiple hardware. Testing on a single PC or laptop is not enough.

I had such problems with the mouse on a P2@400Mhz that was not visible on other testing hardware. It was a bug in my driver that was hidden by the bigger speed and/or layout of the other test machines.

You must program "defensively". This means avoiding hacks, avoiding optimizations and special features until you are sure they will also work on "whatever" other hardware the "user" has...

BTW I was testing your OS in VPC

It works but it is kind of slow. However I do not think that being slow is a problem for now unless there is some wrong concept involved.

IMHO a greater problem is that your OS is also very unreliable on mouse clicks.

Many times I can not minimize, maximize or close a window when I drag the mouse involuntarily during the click and/or the mouse remains in a wrong state (clicked when in fact it is not, etc). Maybe the mouse event handler code/logic needs a revision.

Overall it is a good start.

bontanu wrote: BTW I was testing your OS in VPC

Thanks for testing. But, on my laptop, HyOS works fast on VPC, probably through hardware virtualization.

bontanu wrote: IMHO a greater problem is that your OS is also very unreliable on mouse clicks.

Many times I can not minimize, maximize or close a window when I drag the mouse involuntarily during the click and/or the mouse remains in a wrong state (clicked when in fact it is not, etc). Maybe the mouse event handler code/logic needs a revision.

That's right. My GUI (and the entire OS) needs some simplication and optimizations.

I like the Sol_OS design: "simple inside and simple outside". I'm trying to make my OS more simple. I like also Sol_OS GUI. For a
while, I wanted my GUI looks a bit like that Sol_OS (the windows, the blue buttons, etc), then I changed my mind.

Tommy wrote: Thanks for testing. But, on my laptop, HyOS works fast on VPC, probably through hardware virtualization.

Hmm, it depends how you define "fast" ... I was comparing with Sol_OS GUI of course...

Tommy wrote: That's right. My GUI (and the entire OS) needs some simplication and optimizations.

I do not know how you have designed your GUI internally but I GUESS that you do not need optimizations now. You can not optimize until you do not get a real grasp of the concepts involved and this comes with experience during development.

One of the greatest mistakes of novice is to do a full re-design of some module once he start to dislike some parts or to optimize early. Wait a little until you have a more clear view of what needs to be done... mainly in relations with the other modules/drivers/applications.

Otherwise you will be always in confusion and re-designing and optimizing a falling construction.

I like the Sol_OS design: "simple inside and simple outside". I'm trying to make my OS more simple.

Good to hear that because I also like this "simplicity" concept.

However be aware that it is not very liked by the "mind device". The human mind does like complexity by education and it is hard to teach it otherwise. Hence it can say "I like simplicity" and THEN bring back in complexity and optimizations and killer features -- on the back door with a different disguise.

Simplicity also means that many (or a majority of) users and programmers will not like your OS. Are you ready for this?

Tommy wrote: I like also Sol_OS GUI, for a
while, I wanted my GUI looks a bit like that of Sol_OS (the windows, the blue buttons, etc), then I changed my mind.

Well thank you for your appreciation on the Solar_OS GUI "looks".

However the way a GUI looks (esp in the early development phases) is kind of irrelevant. It is more important what it can do than how it looks.

And I mean: events handling, child/parents relationships, callbacks, drag and drop, re-size, auto position, flicker free, controls available, simple and clear API, etc

You can change 1001 "looks" or skins until "the end" with ease BUT a change in those API concepts will NOT be so easy once it inter-relates to many other API concepts.