Hi,
Yashas wrote:1)What do I need to develop a basic GUI?
First, make sure you've got all the basic stuff working (boot code, physical memory management, virtual memory management, SMP, scheduler, IPC). This all needs to work reliably.
Next start work on generic device management. Things like support for IRQs, PCI configuration space, etc. It should also include device detection and enumeration, and resource assignment (setting BARs, etc).
Once all that is working, stop programming. It's time to write formal specifications that describe the interface/s between device drivers and the OS. You'd need one for storage device drivers, one for "user input" devices (keyboard, mouse, etc) and one huge one for video. While you're at it you should also do something similar for file systems, and the VFS. You could do more at this point if you want - e.g. something for sound, font engine, etc.
Once that is out of the way, I'd probably start with an ATA or SATA/AHCI driver (that complies with the "storage device interface specification" you wrote). After that would be a very simple file system (FAT32?) and the VFS (mount/unmount, caching, etc). Once you can load files via. the VFS it's time to add support for executing files to your kernel; and after that you can modify your device detection/enumeration code so that it tries to load/start device drivers (from the VFS) for any detected hardware.
Next would be a few more device drivers - PS/2 keyboard and mouse, generic "VBE only" video driver, USB if you have to.
After all of this, you're almost ready to start working on the GUI. You need a secure login thing first though (e.g. username and password prompt). When a user logs in you check their configuration file to determine which executable to use for their GUI.
Next, you want write another formal specification that describes the interface between applications and the GUI.
Finally, after several years of hard work, start writing the GUI. This should be very easy to do, because you should already have everything you need written down in formal specifications and implemented (and tested) in drivers, etc. Mostly it's just gluing stuff that you've already done together.
Yashas wrote:2)How to get a higher resolution in protected mode in C?
You'd need to write a native video driver for your specific video card. An alternative would be using VBE in real mode in a mixture of C and assembly.
Yashas wrote:3)How to print a Character at the centre of the screen?(C only)
I'd create a little "comand list" that says "clear the canvas and draw the unicode string in the middle" and send it to my video driver. The video driver would execute the list of commands I sent (except it'd ask the font engine to convert the unicode string into bitmap data).
Yashas wrote:4)How to make a cursor move according to x and y of the mouse?(I have the x and y but I just 5)need a cursor on the screen)
Just upload a "cursor" texture into your video driver; then tell the video driver where to draw this texture whenever the mouse moves. Hopefully the video driver will support hardware cursors (but if it doesn't it'd need to do it in software).
Yashas wrote:6)How to check weather a mouse is connected or not?
USB device enumeration (for USB), or from its response to the "identify" command (for PS/2).
Yashas wrote:7)How to identify a Keyboard Layout?
This is one of the things that annoys me. The USB specs for keyboards (HID) include fields that should be used to describe keyboard layout, but keyboard manufacturers are assholes that ignore these fields and pretend everything is "US QWERTY" layout even when it's not. In some (rare) cases it might actually work correctly, but if the keyboard says it's "US QWERTY" you don't know if it is or not. For PS/2 it can't be done either (legacy stuff that never supported it); however, for some laptops you can cheat (e.g. use SMBIOS to determine which specific laptop, and use that to infer the type of the built-in keyboard).
Basically (except for rare cases) you have to ask the user. Of course the user won't know the difference between "US QWERTY" and "UK QWERTY" or whatever else (and then they'll complain that it doesn't work when they've set it wrong); so it's best to have a set of pictures and get them to select the picture that best represents their keyboard layout.
Also don't forget virtual keyboards (e.g. touchscreen where the user presses a picture of a keyboard) and things like
input method editors. I'd want to be fairly careful with security too (try to make keyloggers impossible).
Yashas wrote:8)How to dump the registers on the screen?(C Code)
Write an assembly language stub that stores the registers in a structure and passes the structure to C code.
Yashas wrote:9)How does an USB mouse work?
USB mouse works fairly well (almost as good as a PS/2 mouse, just a bit slower). My USB mouse is starting to get old though - the left mouse button has to be pressed "just right".
Yashas wrote:10)Important:
I enable A_20 through the keyboard.On few PC's they wont work so I want to combine all the methods ofenabling a_20 and try each of them until it is enabled.How to make such a code in C.
First, detect if A20 is already enabled and do nothing if you can. If A20 is disabled, start by trying the
BIOS function and test again. If that didn't work try the keyboard controller.
Cheers,
Brendan