Back to life

You might have noticed I didn't write much here recently (to tell the truth, last post was really long ago).

What happened back then? I entered and left another university, felt in love and broke up with another girlfriend, decided to rent an appartment alone, changed job twice and been to LVEE. I tried limiting my Kolibri-related activity to get real life going. One time I've even been depressed with all the world being a huge peace of shit. And believe it or not, I still love this OS.

Most of things I were interested in are now supervised by other community members whom I thankful for that. diamond is currently working on common libraries (libs-dev), hidnplayr and CleverMouse do great job on network stack improvements.

This year started with kernel diving. Seriously, I had too much free time and too less things to do so I couldn't stand it and got back to Kolibri. I've been there all this time, but sweared myself not to code for it anymore. What a pity.

Anyway, what I did is tried to prettify, comment and simplify GUI code. I wanted to do that before but were always failing to start properly. As a side-effect, I not only made code more readable but implemented functionality wanted so long: from now on (and I'm talking about trunk revision #1391), user is able to resize windows in five different directions by grabbing appropriate border or corner: west, south-west, south, south-east and east. Minimal width is restricted to 127px and minimal height the one windows would have in rolled-up state.

Codebase is huge and no one really wants to make global modifications leading to possible overall stability decrease. What we have now is mostly a mess of undocumented code with small time-to-time modifications made by different people with different coding styles and different professional level. Don't get me wrong: this is very, very good and that's probably one of things we all love about Kolibri, but it has to stop. Not in a way of me being the one to refactor all the kernel (moreover, I just can't do that because of lack of knowledge and time) but in a well-thought coding guidelines document all should follow. If you're interested, take part in discussion.

Network stack

Well I made some progress on improving the stack. It's not that huge. Now, there's no limit on how many sockets can one program open.
Also, I've added a check if the socket belongs to the program going to work with it. Since there's no big difference between processes and threads in Kolibri (I'd like to change that in next few days when I have time), this change also means that one program can't use the same socket in different threads.

Changing the process-thread architecture can negatively impose already present programs. What I want to do is separate "process id" and "thread id", giving all newly created threads the "process id" of the calling thread. This also means that when the "main" thread (the one where "process id" = "thread id") is quitting, all other threads are likely to also be killed (because in other way, process slot is being freed and another process with such PID could be created) which differs from current implementation.
That said, there could be another way - making process list dymanic (like I just did it with sockets). This would involve major internal kernel changes (not visible to the programs though) and could take some time to finish. And this, of course, will give us another step forward eliminating process count limit (does anybody need this?).
Oh well, I'm still thinking of this, who knows.

Libs-dev extension: libimg

I've recently started working on another cool library to make Kolibri programmers life easier. This one is called "libimg" and aims to provide functionality in some way similar to ImageMagick library (no code but some ideas are taken directly from there). Right now, it's alreayd possible to decode BMP and GIF files transparently i.e. you don't even need to specify which format does raw data represent. Of course, it's not always possible to determine image format, so API will be extended later to provide some optional parameters to functions.
Libimg not only allowes you to transparently decode (and later encode) images but also comes with some frequently used and simple to implement functions to operate on loaded images such as image flipping and rotation. More auxilary functions to come.

All the libraries along with libimg are available in SVN now: /programs/develop/libraries/libs-dev. Feel free to contribute.

Another fine port - KPACK

I got an e-mail from diamond saying that MTAPPACK isn't really used to pack Kolibri executables nowadays since kernel got support for KPACK-packed executables. This means that my MTAPPACK port is of no use :)
So now I ported KPACK. Links are kpack-bin.tar.bz2 (14K) and kpack-src.tar.bz2 (42K). Take'n'use, hope you like it ;)
There's one problem. I'm not sure it will work as-is on x86 CPUs since I have x86_64 myself. If you may check that, please mail me on results.

MTAPPACK - asm/libc Linux port - done!

OK, here we go. It was already done the day before yesterday, but I had a problem running it resulting in segmentation fault. The problem was that I didn't add a simple line into mtappack.asm which looks like "add esp, 16" (damn "C" call convension) and thought that was LZMA library causing the error. I figured out later that I defined "__stdcall" as nothing, which I then replaced with "__attribute__((stdcall))".
I think this port cannot be compiled with MASM anymore since I added "if"/"end if" and escaped some lines with "\" in mtappack.asm and not sure if MASM supports them. But it compiles with FASM quite fine (why would anyone use MASM? maybe its COFF files are incompatible with Microsoft's linker used on Win32). You are welcome to help me there.
Ported binaries along with source code are available from my site, but I've also mailed it to diamond so it may be further available from his site. Get them as mtappack-bin.tar.bz2 (17K) and mtappack-src.tar.bz2 (177K) archives respectively. I've also included APlib library into source package (which is not in the original MTAPPACK archive). Everything is under GPL, and copyrights holder of MTAPPACK, including this Linux port, is diamond.

I feel like I have to work on standard libraries now a bit more because I know they have some bugs and just need to be better.

MTAPPACK - asm/libc Linux port

I wasn't able to write anything within last month since I had no Internet connection at home but had much things to do at work. Now as everything is fine, I've also started to port MTAPPACK to my Gentoo box, to be able to execute it on kolibrios.org server and make it possible to release daily or weekly builds of Kolibri.
Work is partially done. Since I didn't want to hardly modify diamond's code, I decided to write wrappers to WinAPI functions, and I've succeded it this task quite enough. Let's see what I'll have tomorrow, maybe it'll work already.

Common libraries update

I'm working on new common libraries version. For now, there're already some changes and new features you might look at. That's what was changed recently:

• libio (v.2)
  
• file.truncate (renamed from file.seteof)
  
• libini (v.3)
  
• ini.enum_sections
• ini.enum_keys
  
• libgfx (v.1)
  
• gfx.open
• gfx.close
• gfx.pen.color
• gfx.brush.color
• gfx.pixel
• gfx.move.to
• gfx.line.to
• gfx.line
• gfx.polyline
• gfx.polyline.to
• gfx.fillrect
• gfx.fillrect.ex
• gfx.framerect
• gfx.framerect.ex
• gfx.rectangle
• gfx.rectangle.ex

If you want to test and probably take part in development, download them (http://mikedld.com/f/, libs-dev-3.*) and contact me for details. Believe me, there's plenty of work waiting for you.