What does your OS look like? (Screen Shots..)

[Ch4ozz]

After all I decided to give user an option to choose any resolution he wants. My current implementation supports any resolution.

That's how it should be. My OS is entirely resolution-independent as well. I also plan to let the user choose resolution he wants, as long it is supported by the BIOS/monitor combination. EDID is too much work for something that means so little, and I plan to use the same approach used by Windows (Click OK within 15 seconds to confirm current screen resolution.)

Actually it took me roughly half an hour to get EDID to work.
The annoying thing is, it only works on my real hardware and NONE of my vms ever responded to EDID.
If you need the implementation just hit me up, its really nothing big.

That seems fair. I don't have V8086 monitor at the moment. I am currently using BGA for everything, but that does not matter since frame buffers are fully compatible.
Window did a nice job of managing all those resolution and different settings.

You dont need Virtual8086 mode, there is a nice implementation of the int32 call for protected mode which changes to realmode and back by Napalm.
You only have to add some lines to disable paging while being in real mode

[BrightLight]

That seems fair. I don't have V8086 monitor at the moment. I am currently using BGA for everything, but that does not matter since frame buffers are fully compatible.

I don't have a v8086 monitor, either. I set VBE mode in real mode, before protected mode (my kernel has a 16-bit stub program before it that does stuff that depend on BIOS.) For mode switching during normal execution, I will return to real mode temporarily, not write a v8086 monitor because that will fail on many real hardware: because the BIOSes switch to protected mode temporarily to access MMIO registers in the end of the 32-bit address space.
But this is too off-topic, so here's a screenshot of my OS with a new window theme. Still trying to decide what colors look best, and whether the cursor by default should be white or black.
EDIT: Forgot to say this; the thing I'm most proud of here is that the OS has booted natively from a SATA drive.

transparency 2.png (10.33 KiB) Viewed 5276 times

[Octacone]

That seems fair. I don't have V8086 monitor at the moment. I am currently using BGA for everything, but that does not matter since frame buffers are fully compatible.

I don't have a v8086 monitor, either. I set VBE mode in real mode, before protected mode (my kernel has a 16-bit stub program before it that does stuff that depend on BIOS.) For mode switching during normal execution, I will return to real mode temporarily, not write a v8086 monitor because that will fail on many real hardware: because the BIOSes switch to protected mode temporarily to access MMIO registers in the end of the 32-bit address space.
But this is too off-topic, so here's a screenshot of my OS with a new window theme. Still trying to decide what colors look best, and whether the cursor by default should be white or black.
EDIT: Forgot to say this; the thing I'm most proud of here is that the OS has booted natively from a SATA drive.

transparency 2.png

Transparency amazes me, don't ever remove it. Transparency make every OS look 100 times better. I think you should keep the white cursor, why does it look deformed. If you want I can give you my bitmap that is pixel perfect so to say. What about GRUB and setting VBE mode. I have a chunk of assembly code that sets protected mode. So I should set VBE mode before I enter protected mode or I should use VBE 3.0 that supports protected mode. I can not find any VBE real/protected mode tutorials, every one I find uses a V8086 monitor.

[BrightLight]

The specs are easy enough to understand. This walkthrough I've written makes it even easier. In general, the sequence goes something like this:

• Ask the BIOS to return an array of supported modes.
• Query the information of each mode from the supported mode array and search for the mode you want to use.
• Ask the BIOS to set that mode for you.

[Octacone]

The specs are easy enough to understand. This walkthrough I've written makes it even easier. In general, the sequence goes something like this:

• Ask the BIOS to return an array of supported modes.
• Query the information of each mode from the supported mode array and search for the mode you want to use.
• Ask the BIOS to set that mode for you.

Your tutorial is meant for 16 bit real mode. What about those people who want to enter VBE from protected mode. (using VBE 3.0)

[BrightLight]

Your tutorial is meant for 16 bit real mode. What about those people who want to enter VBE from protected mode. (using VBE 3.0)

I don't know much about it, TBH.

[Octacone]

Your tutorial is meant for 16 bit real mode. What about those people who want to enter VBE from protected mode. (using VBE 3.0)

I don't know much about it, TBH.

I guess I could enter VBE mode before I switch to protected mode. Does that mean that the mode I set is the mode I have to use?
Virtual 8086 is one of the options, but that requires stuff I currently don't have implemented.
Other way is to get back to 16 bit mode, but what about my kernel that was running in protected mode, where does that code go. Like if I have running apps, how would they perform in 16bit mode??? Then I would have to go back to protected mode, enabled paging and GDT again right??

[BrightLight]

I guess I could enter VBE mode before I switch to protected mode. Does that mean that the mode I set is the mode I have to use?
Virtual 8086 is one of the options, but that requires stuff I currently don't have implemented.
Other way is to get back to 16 bit mode, but what about my kernel that was running in protected mode, where does that code go. Like if I have running apps, how would they perform in 16bit mode??? Then I would have to go back to protected mode, enabled paging and GDT again right??

It'd be nice if moderators split this into a VBE discussion thread.
Anyway, v8086 is indeed one of the options, but it won't work on most current hardware because the BIOS goes to protected mode without informing you. This is to access MMIO registers in high memory (3-4 GB) to configure the graphics card.
Going back to 16-bit mode is an option, and calling the BIOS from there will work and then you return to protected mode. What do you mean where does your code go? It doesn't go anywhere; it stays in memory, just inaccessible to real mode because it's most likely above 1 MB. If you have running apps, you'd disable multitasking and paging before going back to real mode. Your scheduler will definitely save the application state before disabling multitasking. Then, when returning to protected mode, you'll restore all the system state. Nothing in the system will even be aware of the change that occurred.
So to make a long story short: v8086 is a better solution in theory, but in practice, using real mode is better for better hardware compatibility.
EDIT: If you want to use VBE 3.0 and don't know how it works, consider reading official specs. Reading documentation is much easier than it sounds, really, and you're going to need to know how to read them one way or another (for example, the Wiki lacks a lot of info on long mode, which I got from Intel's manuals, and it also lacks a lot of info on ACPI, which I also got from ACPI specs.)

[Roman]

If you have running apps, you'd disable multitasking and paging before going back to real mode. Your scheduler will definitely save the application state before disabling multitasking. Then, when returning to protected mode, you'll restore all the system state.

I guess, it should even be possible to make the scheduler ignore a single CPU core and then switch that core to real mode.

[BrightLight]

If you have running apps, you'd disable multitasking and paging before going back to real mode. Your scheduler will definitely save the application state before disabling multitasking. Then, when returning to protected mode, you'll restore all the system state.

I guess, it should even be possible to make the scheduler ignore a single CPU core and then switch that core to real mode.

Yes it's definitely possible, but you shouldn't depend on the system having more than a single CPU.

[max]

I guess I could enter VBE mode before I switch to protected mode. Does that mean that the mode I set is the mode I have to use?
Virtual 8086 is one of the options, but that requires stuff I currently don't have implemented.
Other way is to get back to 16 bit mode, but what about my kernel that was running in protected mode, where does that code go. Like if I have running apps, how would they perform in 16bit mode??? Then I would have to go back to protected mode, enabled paging and GDT again right??

They wouldn't perform at all, you just don't switch tasks while you're in 16 bit mode. Your options are switching to 16bit, writing a VM86 monitor or writing a "real driver". A vm86 monitor is not that terrible to implement.

[Octacone]

Oh god. So many replies. I am lost... Tried to quote you guys, but no success. Sorry for getting off-topic.

@max
Writing my own driver is not really an option since it is nearly impossible. Temporarily entering a real mode sound easier in my opinion. I don't have a sufficient framework to build a v86 monitor on top of. Do you need to have a working TSS??

@Roman
I can only disable paging, can't disable multitasking because I don't have one.

@omarrx024
VBE 3.0 manual has some code examples with in and out commands. I think refers to a virtual 8068 monitor since the code is in C and full of those commands. Again don't have a multitasking/scheduler yet. So you are saying that a v86 monitor is not compatible with todays hardware? Entering 16bit protected mode is a thing, I read about that somewhere.

This is not really a discussion topic. Post some screenshots to keep the current going.

[mac]

Using basic BIOS routines:



I'm still getting the hang of ASM x86. I might be getting too hot for my experience.
I appreciate any tips, and I'll post the code anytime.

[alexfru]

I'm still getting the hang of ASM x86. I might be getting too hot for my experience.

Yay!

[mac]

I'm still getting the hang of ASM x86. I might be getting too hot for my experience.

Yay!

I accidentally threw away the source code, though.