OSDev.org

seuti wrote: So you have an image with all of the characters and then you draw imaginary lines every 32 (or whatever character width you want) pixels, each space inside the grid is a sprite; you put all of the characters in your font there.

Thanks for information. But I do not want to implement them soon (being too lazy ). I don't know why but now I think my font is also looks good.

omarrx024 wrote:Nice new font, thanks to muazzam!

You're welcome. Are you doing it with BIOS interrupts (with uploading fonts to graphics card)?

muazzam wrote:You're welcome. Are you doing it with BIOS interrupts (with uploading fonts to graphics card)?

Yes. I'm using BIOS INT 0x10 AX = 0x1100.

As long as you keep sticking to bitmap fonts like those, you're holding on to one specific resolution and quite commonly ASCII as well. Also, taking an existing font and rendering it down into an image means you should be following the license of the source font as well. The technically correct way is to use a truetype library and find some fonts that are actually open for use and distribution.

Otherwise, the VGA font provided by the hardware is both free of copyright and readily available. If you need a prepared bitmap font, this is legal to use as well (free of ASCII limitations, but it doesn't currently cover arabic, unfortunately)

Combuster wrote: Also, taking an existing font and rendering it down into an image means you should be following the license of the source font as well. The technically correct way is to use a truetype library and find some fonts that are actually open for use and distribution.

I don't took an existing font. All characters are made exclusively by myself.

A long time ago, I had broken "support" for writing in ext2 (creating files, etc.). When I moved my ext2 driver to a loadable module, I rewrote most of it from scratch and disabled the write support. That was over a year ago. Now, finally, after some late night hacking, write support is working again in ext2. There are still a number of things that aren't done (mostly related to removing and truncating files), but it's enough to build a binary with gcc that survives a reboot.



And after (closing vim and) rebooting:

Looking good Klange. Nice work!

klange: Your OS will always be my inspiration and encouragement!

Working on a scripting language that is embedded as part of the kernel itself and can be invoked using a system call.
Here's the script running: And the source code of that script:

Got dlmalloc working (yay! ) for Calcium's kmalloc() and kfree(). Now I can get working on mmap() and munmap(), then I think I'll work on SMP. In the screenshot the VMM shows the sbrk() calls made to it by dlmalloc, which I though was kind of interesting. I've also done some work with VBE, and now have DejaVu Mono as the font. I still need to figure out how font licensing works...

-bace

omarrx024 wrote:Working on a scripting language that is embedded as part of the kernel itself and can be invoked using a system call.

A whole scripting language through a system call..? Wow - that's cool. I'd probably do that, but my OS is going to need a lot of work first...

-bace

bace wrote:I've also done some work with VBE, and now have DejaVu Mono as the font.

Do you have TrueType font support?

bace wrote:A whole scripting language through a system call..?

Yes. The scripting language is embedded as part of the kernel itself. It is also portable; if my OS is ever ported to other platforms (non x86), the scripts can still run.

bace wrote:I'd probably do that, but my OS is going to need a lot of work first...

There's no rush. Your OS is coming along nicely, seeing how little time it has been and how much you've achieved. You can focus on the system itself, and then work on scripting languages and stuff.

omarrx024 wrote: It is also portable; if my OS is ever ported to other platforms (non x86), the scripts can still run.

As it is in assembly, you'll have to rewrite the "whole" OS to port to non-x86 architecture.

muazzam wrote:

omarrx024 wrote: It is also portable; if my OS is ever ported to other platforms (non x86), the scripts can still run.

As it is in assembly, you'll have to rewrite the "whole" OS to port to non-x86 architecture.

Of course I know that. I clearly said the scripts are portable.

omarrx024 wrote:Working on a scripting language that is embedded as part of the kernel itself and can be invoked using a system call.

Does your OS have separate user- and kernel space? If so, why would you want to let scripts run in kernel space instead of userspace and therefore loose userspace security aspects?

Also having it in kernel space *can* make it hard to add non-scripted functionality to scripts. For example, userspace programs might want to register native functions as script functions; are you planning to allow this (if yes, how?) or are there no binary programs & only scripts allowed at all?