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.

"About rights and files" © Alver

OK, I was finally sent down from the university since haven't passed Math exam in time. This is not something I'm gonna cry to death, but this is sad. Remind me not to be such an idiot next time ;)

There's a topic titled like the post you're reading now on Russian Kolibri board, and despite it's in "Offtopic" forum I'd like to comment on it a bit. The topic is about files security issues in Kolibri and how could we have solved them. Mother God! Guys, are you all serious? Kolibri is not a multi-user OS and I can't even say when it will become such. Files access restrictions are not something we need since we have no one to hide anything from except ourselves.
But OK, suppose you'll make that happen. What is this all about, these directories names are all 3-chars length. It's not DOS time anymore and even back then I don't remember having any feeling to be limited in folders naming. Why not giving directories self-explanatory names instead of writing "slb [system dll]" which I can't understand. Try to think about users who'll use this system. They don't need complexity, they need small but powerful enough system, not the beast you're trying to suggest.

Well, yeah, this all is about offtopic, but stupid ideas are always more attractive :)

About Tinypad future

As mouse scroll is to be supported thanks to k@sTIg@r efforts (read more), it's going to be one of major Tinypad 4.0.5 changes along with INI files based configuration and several not previously supported functions such as 'go-to-position' and 'smart-tabulation'. I'm also going to refactor code even more than in 4.0.4 to make things easier to understand and modify, and add more comments to functions. Probably, but not for sure, I'll separate UI controls into some library to make interface more customizable, and to make overall situation with UI libraries better.