OSDev.org

Shirk wrote:

Bender wrote:I am just wondering whether that's 80x25 mode or some VBE Magic.

Nope, that's regular 80x25 BIOS font but I would guess Roman (just like me) is working on a rMBP.
With retina / HiDPI displays you get huge screenshots like that one without intention..
If it's displayed as 320x240 on your screen it'll create a screenshot of 640x480 and so on.
I fell for that too the first few times when I was new to retina resolutions

Yes, I use MacBook Pro Retina too. Also will make next screenshots in a smaller resolution.

Hi everyone,

This is my WindowsManager going crazy.
I've tried to only update the changed surface, but something went wrong. Only random refresh ...

@Dju:
Cool. I like the font. Which font is that?

@Bender

Thank you. I use the Open Sans font for titles and chrono (http://www.google.com/fonts/specimen/Open+Sans), and Consolas for the shell.
Fonts are pre-rendered with freetype, but the result looks too bold.
From my experiences, the final render is better when you use use this formula on the grayscale values (with floating values between 0 and 1) : gray = pow(gray, 0.75f)
Fonts are then rendered thiner and better.

If Intel/AMD can develop "Long Mode", So can I!
Btw this is pure VGA (not VESA/Any BIOS crap involved), It was my attempt on switching to 720x480x16 mode, but something crazzzy happened. It became so looong that my 1366x768 screen couldn't handle it. I messed up the registers I guess. Anyways it's a fun exercise to keep messing up VGA regs, and discover new modes (in QEMU).
What should I call this? VGA Stretch Mode? Limousine Mode ?
Loooooooong Mode sounds nice.

Send a copy of the code to apple. I think they will need it in the near(maybe not that near but who knows) future http://media.techeblog.com/images/futur ... amsung.jpg

Normally, the most funky images appear when I do stuff on real hardware, but this time it was the emulator's turn to show me something quite charming. Here's the result of bringing over 300 new lines of code live for the first time:


Don't worry, I already know how to get rid of all but one of these bugs

Just wondering, why would real hardware and emulators be that different? Shouldn't they be more or less the same (Besides maybe the emulator doing more stuff for you)

hometue wrote:Just wondering, why would real hardware and emulators be that different? Shouldn't they be more or less the same (Besides maybe the emulator doing more stuff for you)

I can think of three main reasons.

First, performance. Some things are very expensive to emulate/virtualize exactly as real hardware. So, you end up implementing the most important stuff the best you can and drop the ball here and there.

Second, some things are overly complex/complicated and you either decide not to support them in your emulator or you outright don't understand what should be done in some situations and as a result some things simply don't work. You may eventually understand them, but it may be too late, well past the shipping date.

Finally, there can be and often are bugs. Guess why the list of supported guest OSes in Microsoft Hyper-V is relatively short and skewed towards Windows? That's where the main interest has been and that's what Hyper-V is good enough for. To properly support much more than that one would need to add a bunch of missing things, fix a bunch of broken things and do lots of additional testing. I've contributed to finding and fixing some of Hyper-V bugs, so I know it from first-hand experience.

hometue wrote:Just wondering, why would real hardware and emulators be that different? Shouldn't they be more or less the same (Besides maybe the emulator doing more stuff for you)

Because half of my graphics driver code isn't even meant to work on emulators?

Not to mention that even memory isn't in a perfect condition on real hardware, I have wasted some of energy facepalmming and some hours when running code on one of my computers......

I had a bit of fun looking into the upcoming GCC 4.9.0 release by rebasing my OS-specific toolchain on the 4.9.0 release candidate. In particular, I noticed it had implemented some features originally from clang such as -fsanitize=undefined that adds runtime-checks to the code trapping undefined behaviour. I realized this could be pretty useful in operating system's development where mysterious kernel bugs are occasionally caused by simple undefined behavior. Investigating into this feature, I noticed that it unfortunately required runtime support from a special runtime library called libubsan that comes with GCC and this library is part of the libsanitizer suite that isn't readily portable to new platforms. Or rather, while libubsan is pretty portable itself, it relies on unportable practices in supporting code such as raw Linux system calls - which made it unusable in a kernel for instance. After a half-assed attempt porting it to my operating system, I gave up on that front. Instead, I looked into the libubsan ABI and noticed it was pretty simple, so I reimplemented it in my libc in a manner where it was pretty minimal and knew about my kernel panicf function. I was thus able to build and run my entire operating system with -fsanitize=undefined.

Interestingly, my x86-64 port booted in the first attempt, so I had to add in some fake undefined behaviour to user-space programs and then kernel to verify it works:



Later it turned out my 32-bit port had a single issue of undefined behaviour that prevented it from booting, but the above screenshot was more interesting.

I'm in the process of replacing my old window compositor (which was a proof of concept written during crunchtime for a hackathon) with a new, more robust one that features damage rects (aka update regions, dirty regions, etc.). When drawing with damage rects, it's important to update not only the new position of an object, but also its old position, or this happens:

I had a bit of fun looking into the upcoming GCC 4.9.0 release by rebasing my OS-specific toolchain on the 4.9.0 release candidate. In particular, I noticed it had implemented some features originally from clang such as -fsanitize=undefined that adds runtime-checks to the code trapping undefined behaviour. I realized this could be pretty useful in operating system's development where mysterious kernel bugs are occasionally caused by simple undefined behavior. Investigating into this feature, I noticed that it .................................................

Good to see people still having VGA Consoles.

hometue wrote:Just wondering, why would real hardware and emulators be that different? Shouldn't they be more or less the same (Besides maybe the emulator doing more stuff for you)

Well, this difference between an emulated and a real 8086 is a bit odd: VirtualBox does not set bit 1 of the FLAGS register. I'm pretty sure it is not caused by a bug in my code because Virtual PC works as expected.