Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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.
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)
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
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.
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
Attachments
"for example, turning off the system’s power through the movement of a large red switch" - the Advanced Configuration and Power Interface Specification
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
"for example, turning off the system’s power through the movement of a large red switch" - the Advanced Configuration and Power Interface Specification
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.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
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?