Rainloop webmail

Posted by pulkomandy on Thu Jan 30 16:14:57 2014  •  Comments (0)  • 

Pendant des années j'ai utilisé Roundcube comme webmail. Mais je n'en ai jamais été vraiement satisfait..

Et aujourd'hui, j'ai installé Rainloop sur mon serveur. C'est propre, c'est beau, c'est facile à installer, ça marche tout seul, et on a même pas besoin d'avoir les mails sur le même serveur car tout passe par de l'IMAP et du SMTP. Adopté!

Website mirroring

Posted by root on Mon Nov 25 10:53:36 2013  •  Comments (0)  • 

Personnal message to whoever uses IP your mirroring of the website using WebReaper was using 100% CPU because most pages are dynamically generated. I have more useful things to do with my server, so WebReaper is now banned. If you want a mirror of the website, I can send you an archive.

You probably won't use everything I have online here, anyway, and you are wasting my internt bandwith. I host this server at home and use the internet connection for you know, web surfing and stuff.

Some projects

Posted by pulkomandy on Fri Nov 8 12:56:42 2013  •  Comments (0)  • 

Some time ago I set up a trac install on my server to put all my running stuff. As I ended up using the provided wiki for tech documents, there is nothing visible on this website. This article list all these projects so they are linked from somewhere, maybe this way Google will index them better.

Also, there's more on my github page, where I plan to migrate most of the stuff above, someday (because git is better, github is more visible, and Trac in fastCGI mode has a very annoying memory leak making it the first source of problems on my homeserver). There's also my Google Code Prject Hosting page, which I plan on not using anymore but there are some projects to migrate, still.

Reverse Engineering notes for ATJ227x

Posted by pulkomandy on Wed Oct 30 22:12:24 2013  •  Comments (0)  • 

This weekend I wanted to relax a bit and stop coding, so I decided to resume work on reverse engineering the ATJ227x gadgets.

You may remember I was involved in hacking with the older Actions Semiconductors MP3 players in the S1MP3 project. This never got anywhere, with more powerful hardware now being just as cheap and Rockbox being a more appropriate solution for it. Anyway, Actions Semi is not dead, and they still do some weird system-on-chip stuff. The new iteration is called G1000 and powers some cheap handheld consoles. I can name the JXD 3000, the Kulala K803, the KO W5000 and W6000, and the Juyou A320+ and S430. Never heard of them ? Well you should go buy one of those now. The cost around 30 euros, which is quite cheap, and they all share most of the same hardware: ATJ2279B system-on-chip, 480x272 LCD, USB (they act as mass storage devices), SD card connector audio out (and some of them even have video and HDMI), and a touchscreen.

As usual, besides the very cheap plastic (what did you expect at such a low price? they even added metal weights inside the case so it doesn't feel too light and crappy!), the problem with this devices is the low-quality firmware they are running. This time, instead of a completely homegrown system, Actions Semiconductor went with µC/OS II (no, this is not compatible with Linux nor Android). Anyway, when I got my Kulala K803, there was very few information available on these devices. Now they have spread out a bit more and, more importantly, Juyou made available the firmware update tool and their firmware files. I risked breaking my different console installing that, and, well, it worked. The Juyou firmware is much better than the Kulala one. I think I lost the radio support and maybe some other features in the process, but well, at least I have an useable user interface now (it's PSP-like). I can use this as a MP3 player (Ogg doesn't work with the Juyou firmware it seems), which is already a good thing, and the thing also runs GBA, SNES, Playstation games (slowly).

More important than that, I now have a firmware file to play with! Let's throw binwalk (don't use the Debian package, it's outdated) at it and see what it finds! Well... nothing. Some invalid gzip headers, no strings, no known compression format, just nothing. Not very good, but I know the firmware files for the older z80 devices from Actions were encrypted in some way. So let's try a different approach to this.

It turns out the firmware is encrypted, but fortunately still using the same system as the previous chips. Using the atjboottool done by the RockBox project allows to decode this. Binwalk is much more happy with the result, turns out is it an sqlite database. It stores some metadata, and more interesting, the firmware files. Good thing: I can spot the well-known ELF header in there. The combination of SQLite and ELF makes things much easier to understand. That's nice from Actions. It should also make it much easier to rebuild a firmware file for updating the device, should that be needed. I think it's better to look for the possibility of adding an homebrew loader like this one done for the JXD 3000. I heard the OS structure is different in each firmware version, but maybe there are some ideas I can reuse. It seems the trick to read libs from the mass storage on boot may be JXD-specific, as other consoles (at least the Juyou upgrade guide I've found) use the ADFU firmware upgrade tool over USB instead.

So let's run binwalk again on that interesting img file. Inside there seem to be a lot of ELF files, GIF and PNG pictures, as well as... another sqlite database. The "matrioshka" option in binwalk is starting to make sense. It's a plain FAT32 partition (mount on linux with -t vfat -o loop), however, the partition size is 90MB, yet the file is only 60MB. I can imagine this will create problems if you try to write to it. The structure is quite simple, there is an APP folder with the applications, and a LIB folder with the libs. The other sqlite database is actually for the english/chinese dictionnary app, so it's not very useful for us.

Each application is made of an "app" file which is actually just ELF. Some of them have resources (in res format), a stylesheet (.sty), and sometimes other resources (for example the boot logo app has two animated gif and a startup sound). The RES-file format may be similar to what Actions used on older console, so the code in s1res may be of some use. I have no idea about the STY files, however. There are also "desktop" files which are just lists of strings in different languages for the application name.

In the lib folder, there are only 4 files: applib, style, fusion, and commonui. They are all rather small (less than 500K). A quick look at "readelf -s" shows that there are some source file names information left there. I don't have a MIPS toolchain yet to look at the disassembly and start extracting actual function prototypes, however I can already tell you that fusion seems to be some 2D drawing framework (with rotations, blits, and all that stuff), applib is some kind of system lib (timers, watchdogs, ...), and style is for the UI theming, but seems to export some file I/O functions (fopen, lseek, ...). Commonui seems to be a mix of UI widgets, system stuff, and some of the emulator code (gba_* functions ?). So, no libc or other standard OS stuff here, it seems this is all linked into the apps statically.

The OS itself isn't part of that hidden image. It seems to be built from the other files in the SQLite database. init.exe seems to be interesting, and the best place to look for hooks where to insert the homebrew loader. It's an ELF file again, like all the .so (libs) and .ko (kernel modules). There are also some configuration files in there, which may allow to turn some features on or off (HDMI output, camera input, etc.). I suspect the config is used to pick the right kernel modules and leave the others out. The init.exe has no symbols, so readelf can't tell much about it. It has the usual sections for a C program built with gcc, however, but the complete lack of symbols is strange. I'd expect at least an entry point. That being said, there is a .init section which makes a good entry point as well. strings give a good indication of what it does: initializing low-level stuff (RTC, vram, ...), mounting disks, loading some libs and kernel modules, then running manager.app to run the actual application code. Interesting note: there is a kernel module loaded from /mnt/sdisk, this should be the SD card. Others are run from diska, which may be either the hidden system partition or internal memory. Running strings on the manager.app also gives a fairly good idea of what it does. mnt/sdisk is added to the path so dropping a custom app there may be enough to get it executed in place of the system ones. /mnt/remotedisk sounds useful for development, as well.

The syscfg.sys file is actually where the syscall handlers are. It's NOT an ELF file this time (this seems to be the actual kernel code?) but has helpful strings all over the place. Uli already did the work of analyzing this but he noticed JXD firmware he worked from had different numbers from the others, so I'll have to check if any of this matches mine, and else, find a way to generate the syscall file from any firmware.

If you want to play with this, I have setup a mirror of relevant files. This includes datasheets, Juyou firmware, and update tool (windows only), and I'll add more as I make progress.


Posted by pulkomandy on Tue Sep 24 16:08:56 2013  •  Comments (0)  • 

The downtime is over, all services should now be running again. Ping me if something is broken.

Amelie, a filesystem for 8-bit computers

Posted by pulkomandy on Sat Jun 8 23:23:19 2013  •  Comments (0)  • 

This is a project I've worked on and off for the past year. It all started with the MO5SD project by Daniel Coulom (French page). The idea of this is to use an SD card plugged to the tape port of the french Thomson MO5 computer, which happens to use TTL logic levels.

I reused the ideas from MO5SD to build a similar interface for the Amstrad CPC printer port. However, the Amstrad operating system has better capabilities than the MO5 one and is friendly to expansion ROMs. This makes it possible to run a full-blown filesystem rather than a simple bootloader like the MO5 version does.

Getting the SD card read/write code working was the easy part. After spending some time (with help from SyX and Cloudstrife) optimizing the z80 assembler code for SPI bit banging, I started looking for a suitable filesystem. The most common floppy disc ROMs for the CPC are AMSDOS (the one that shipped with the machine) and Parados, which improves support for dual side, 80 tracks floppy drives from PC. None of them easily allow to reroute disk access to anything else than the floppy controller. I heard that RODOS, a less known disk ROM, has such a capability, and that it also has directories, permissions, and some other nice features. However, close inspection of the RODOS ROM showed that there is actually no way to redirect disk access to anything else than the FDC (if you know a way...)

Moreover, the RODOS filesystem design looked like it would be slow. My bit-bang access to the SD card doesn't go very fast, and jumping around between several sectors isn't a good thing. I wanted to keep files without too much fragmentation so I could load them fast. RODOS is also limited to 20MB volumes, which sounded huge in the 1980s but felt ridiculous for my 4GB SD card. Finally, RODOS requires some RAM, and any ROM that does that on the CPC reduces compatibility with some software.

So, I decided to design my own filesystems. The goals are simple:

  • Use as few RAM as possible. AMSDOS allocates a 2K buffer, that should be the only space we are allowed to use (and some stack, of course).
  • Limit access to the storage medium whenever possible. Try to not read the same sector multiple times.
  • Allow the use of big drives. This requires directories, and also some other tricks.
  • Be z80-friendly. No 32-bit math is ever done.
I worked on a C++ version first. This allowed me to keep the code readable while I experimented with various things. I did all the testing on PC and will start converting the whole stuff to z80 code only when I'm fairly sure there won't be big changes to it again.

An SD card can hold up to 4GB of data. I decided to split this into 256 volumes that map to the CPC notion of "users". On an AMSDOS floppy, each file belongs to a single user and can't be seen by others. This limits each user to 16 megabytes of data. Since the files are allocated on 512-byte sectors, these can all be addressed with a 16-bit offset. I also limited the number of files and directories to fit them on a 16-bit counter.

The filesystem uses a block map with sector granularity (the 16 first sectors are used for that), and a file/directory list based on extents. When the filesystem is not fragmented, a directory will use just 16 bytes of space (including the 11 character name and up to 256 entries), and a file will use a 16 bytes header to store up to 128K of data. These entries can be extended, so directories have unlimited number of entries, and files have unlimited size.

You can read more about the data structures in the filesystem readme, and also check the source code. They are both available at CPCSDK. The C++ code makes use of some C++ features such as vector, but this could easily be converted into plain C. You will also find a WIP ROM code for the z80 version, mostly done by SyX. I'll start filling it with actual disk access code someday, for now it's just managing the patching of AMSDOS code and forwarding the access to floppy drives.

GuideML AmigaGuide converter for Haiku

Posted by pulkomandy on Tue May 28 18:22:36 2013  •  Comments (2)  • 

I'm currently porting some Amiga software (namely, the ACE CPC Emulator). As usual with Amiga software, the user documentations are written in AmigaGuide. I wanted to convert it to a more usual format for Haiku users. I found some tools, but they all run only on Amiga systems. Fortunately, one of them is written in C and open source.

You can get GuideML for Haiku sourcecode at my GitHub account.

The interesting part (development-wise) of this is that I used a set of wrapper header that convert the Amiga API calls into Haiku ones. The Amiga API is based on BCPL, which predates C and has differences such as using FPutC instead of fputc, it also has extra stuff such as support for lists, and a different way to allocate and free memory (where you have to tell FreeVec() the size of the block you're freeing).

This set of header allowed me to make very few changes to the core code of GuideML. I'm also using these headers for the port of ACE, where I could getthe emulator core running quite easily in a short time.

I'm still refining these headers to remove warnings, make them C++ safe (as my user interface for ACE is written in C++) and make them behave as close as possible to the original system. I even reused parts of AROS, an open source rewrite of the Amiga OS, which aims for source-level compatibility. Their ReadArgs implementation was not too hard to port to Haiku, and now my software can use just the same smart argument parsing as on Amiga. I still have to get something similar to icon tooltypes working, however, but that shouldn't be too hard as ReadArgs can parse strings from a file, instead of the command line.

Gravis Interface Protocol

Posted by pulkomandy on Tue Nov 27 22:36:08 2012  •  Comments (0)  • 

Ever heard of the Gravis Gamepad Pro ? It's a gamepad using the old-fashioned PC gameport. It looks quite like the original Playstation controller and has a very solid build quality.

Those of you who know about the gameport limitations will quickly notice that there must be something non-standard about it: there are 10 buttons, while the gameport only allows 4. Even better, you can actually use 2 gamepads at the same time on a single port.

There are several modes accessible with a switch under the gamepad. These are 1-player, 2-player, and GrIP. In 1 player mode, you get 2 axis and 4 buttons. In 2 player mode, you get 2 axis and 2 buttons, and you can use 2 gamepads. In GrIP mode, each gamepad can use all 10 buttons, but this is not compatible with the games expecting a standard joystick.

I have some of these gamepads around, but my PC don't have a gamepad anymore. Since I'm not very happy with replacement hardware (I tried the Logitech Precision USB gamepad, but it doesn't look as nice and colourful), I'm thinking about building an adapter for these gamepads to plug them on an USB port. Of course, without opening and rewiring them. Not only this would void the long expired warranty, but I may still want to plug these gamepads to the system they were intended for (my 1995 Pentium 166 MMX).

There is some information on the internet about the protocol, but it's not easy to find. Heer is what I could get : a textfile with some info and the Linux driver for these joysticks. Since the textfile does not say everything the driver does, here are some notes that duplicate the text file and add the info from the driver.

First, the gameport pinout. It's a SUB-E 15 connector. The following pins are relevant:

  • 1,8,9,15: 5V power
  • 4,5,12: GND
  • 2,7,10,14: buttons 0,1,2,3
(the other pins are axis 0, 1, 2, 3, they are not used in GrIP mode).

When you use only one gamepad, buttons 0 and 1 are used as data lines. Button 0 is a 20kHz clock. On each rising edge of this, you can read the state of button 1. Frames are 24 bits long and holmd data as follows:

0 1      1     1      1    1
0 Select Start R2     Blue
0 L2     Green Yellow Red
0 L1     R1    Down   Up
0 Left   Right
The frame starts with a start bit, then 5 bits set high. Since the button data is split in 4-bit words with a 0 interleaved, there can't possibly be 5 set bits anywhere else, this makes it possible to detect the start of a frame.

Transmitting a full frame at 20KHz will take exactly 1.2ms. This is more than fast enough. It's likely that Gravis drivers on windows only polled the gameport only 20 or 25 times per second (or even less), and waited up to 2ms for a frame start. This was the only way for them, because these gameport buttons are not triggering interrupts.

When there are 2 joysticks connected, the second one uses buttons 2 and 3 exactly the same way. The Gamepad Pro has a pass through connector that swaps buttons 2 and 3 with 0 and 1 for the second device, like any Y-doubler joystick cable does.

My plan is to use a Stellaris Launchpad LM4F120 as an adapter. Why ? Because I have one and want to try playing with it. More interesting, this board has 4 SSI/SPI channels and they can be configured for up to 16 bit frames (where an AVR can only do 8 bits). Since our frames are actually 24 bits here, we'll have to cheat a bit. The plan is to use 2 12-bit frames. Another problem is since the bits come in in a continuous flow, there's a risk of getting out of sync. What I will try is configuring the SSI, reading 2 frames, and see if one of them starts with 0111110. If so, the system is in sync and should stay so forever. Else, wait for 1/20ms, reset the SSI and try again. This should shift by one bit until we get it right. If this approach fails, I'll have to revert to using GPIO and external interrupts. At 20kHz I think the Launchpad can handle it, even with 4 gamepads plugged in. Since the USB is handled in hardware I shouldn't run into as much problems as my amiga keyboard to USB adapter.

Discovering the STM32F3 Discovery

Posted by pulkomandy on Thu Sep 27 18:05:21 2012  •  Comments (5)  • 

So I just got this STM32F3 Discovery board. This is a development board from ST with a Cortex M4 chip, the mandatory leds and buttons, and some accelerometers and sensors.

The main problem is, as often, ST only offers code samples for commercial development environments. And I'm more of an open-source kind of guy. So let's setup some toolchain with free software.

First of all, get the files, this will be more convenient. This archive has the OpenOCD config file, the linker script, startup code, Makefile, and a stupid C code to show it all works (not even blinking a LED!).

Programming the board

That's the easy part. The STM32F3 Discovery has an embedded STLink/V2 interface. A nice thing about it is there are jumpers that allow to use the STLink part to program another device. However, there's a catch: the STLink can only be use to program STM32 and STM8 chips. It's not as flexible as other JTAG adapters.

Unfortunately, STM32F3 support is not part of OpenOCD sources yet. They have a patch set waiting, however:

Do not use OpenOCD 0.6.0 release packages, they don't have these patches in. You will need to get the sources from git and apply the patches above. Then, building OpenOCD is a rather straight-forward process (at least under Linux):

./configure --enable-maintainer-mode --use-stlink
sudo make install
you need to enable access to the STLink hardware for openocd. Create the file /etc/udev/rules.d/99-stlink.rules and add :
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0666"
Then test everything is allright. We use the config file for the STM32F4 since OpenOCD doesn't provide one yet for the STM32F3 discovery. They are close enough for this small test, but we'll need a more specific one later on.

Enter the following commands:

openocd -f /usr/local/share/openocd/scripts/board/stm32f4discovery.cfg &
telnet localhost 4444
reset init
reset run
When you enter 'reset init', the STLink should reset the CPU and the ledswill stop blinking. 'reset run' will make it run again and the led should resume blinking. If everything is ok, you're (almost) ready to debug!


The Cortex M4 chip is some kind of ARM CPU, so you need an ARM toolchain. There are several to chose from: Linaro, Sourcery CodeBench Lite, a plain vanilla gcc, and so on. I used Sourcery Codebench, because I already have it installed. But it shouldn't matter anyway: we're not going to use their linker scripts or standard library at all. Just make sure you have some arm-none-eabi-gcc or similar compiler available in your PATH.

Linker script

To make it easier to use different toolchains, it's better to use our own linker script. I derived one from here.

The linker script tells the linker about several things. It defines the memory areas available in the chip, then tells where each section generated by the compiler must go. For example, all code sections are usually allocated in flash memory, while the variables are put in the RAM alongside the stack. Reset vectors usually need to be put at the start of the flash so the CPU knows what to do when booting.

Writing a linker script is not as hard as some toolchain-provided ones make it sound. If you only want to write plain C code, you can get away with something very simple. I plan to use C++ as well, but that doesn't add that much more stuff. I added comments to the linker script, so you should understand what's going on.

Startup code

An usual C program starts with a main() function. However, when working with microcontrollers, there are some things to do before you can reach it. These tasks are performed by the boot code, usually in a function named _start or something similar. This includes setting up some things required by the C language:

  • Setup some hardware so the C code can be used at all (on more complex devices this could include initializing SDRAM controllers or so, on CortexM3 there shouldn't be much to do)
  • A stack, so we can call functions, pass parameters and return (on Cortex M this is done by the CPU hardware as part of the reset handling)
  • Initialize all the global and static variables (so you thought that was done magically?)
  • For C++, call global constructors so the global objects (if any) are in a coherent state,
  • And finally call the main() function, eventually with the argc and argv parameters (but most of the time you don't need that)

Check everything is ok

With a fairly simple program it's easy to look at the final elf file using the

arm-none-eabi-objdump -d
command. This will dump a complete disassembly of the code, so you can check the reset vectors are at the right place as well as the startup code.

The code should start with _start, which will point first to the stack (somewhere in RAM), then to the reset vector which is stored right after it. See the startup.s file to see how that's made.


We'll be using OpenOCD again. While we used the TCL interface to quickly try it out before, OpenOCD is really meant to be used together with gdb. This way, it's possible to debug your code on the chip just like youwould debug any unix application on your PC. How nice is that ?

So, let's load our executable now !

openocd -f /usr/local/share/openocd/scripts/board/stm32f3discovery.cfg &
telnet localhost 4444
reset halt

flash erase_sectors 0 0 127
flash write a.out 0x8000000

So, the first step is to reset the CPU and halt it to make sure it isn't runnning code from the flash while we're erasing it. Then, we erase the flash, bank 0, sectors 0 to 127 (that's the whole flash of this chip). Finally, we write our new code. Notice the 0x8000000 offset: while the code is executed from address 0, the flash must be written from address 0x8000000. This is related to the way the STM32 chip can boot. Depending on the state of the BOOT0 and BOOT1 pins, the address 0 will be mapped to eitehr the flash, the SRAM, or the system ROM holding ST bootloader. But writing can only occur at the "e;real"e; flash address.

Now that our program is flashed, let's attempt to debug it. Exit the openOCD telnet prompt, but leave OpenOCD runnning. Now connect to it with GDB:

target remote localhost 3333
file a.out
break main
First we connect to the OpenOCD server through the GDB port. Then, we load the file to get the debugging symbols from it. The first stepi command is to sync gdb with OpenOCD. From then on, we can set breakpoints, and run/debug the program as usual. Happy hacking!

Back from BeGeistert

Posted by pulkomandy on Sat Jul 28 19:20:10 2012  •  Comments (0)  • 

I'm heading home from the BeGeistert event that just ended today.

For those who don't know, BeGeistert is the european meeting of all Haiku (and BeOS) developpers and enthusiasts. This year, Haiku has seen its third alpha release, and we feel that R1 shouldn't be too far.

So, what happened there ? Over the weekend we had multiple conferences. The first one on saturday morning was a discussion on Haiku's release process and roadmap for the future. We didn't have time to solve all the problems, but at least one important decision was taken : after delaying the switch to git to after alpha3, then after gsoc, we finally decided it was about time to actually flip the swith. This is scheduled for the 12th of November.

Speaking of Git, Oliver Tappe made a talk about how to use it and the main differences with the current Subversion, and presented the work done so that Haiku developpers don't get lost.

Then, there were talks from Ingo and Oliver about package management, with an impressive demo of the current status It's working, but there are some problems with it like deskbar replicants not working anymore because of the readonly nature of packages (that was solved later during the coding sprint).

Stippi presented us the layout API and some examples on how to use it. The Layout API is an extention to the interface kit that allows much more easier design of window layouts.

François Revol presented us a proposal for UXA, an unified extended attribute scheme to efficiently share attributes between different OSes. While many filesystems and OS now support attributes like Haiku (NTFS, ReiserFS, ...), they all use their ownscheme and the conversion from one to another isn't always a reversible process.

We also had a presentation of an application called VOPTOP, which is a nice peer-to-peer VoIP chat application. The main feature is it uses peer to peer routing to make the communication. This makes it needed to use encryption to make sure one pf the peers doesn't spy the communication.

Finally, Matt Madia told us about the status of Haiku, Inc. Besides helping with the funding of BeGeistert, they are paying mmlr for a full-time year working on Haiku, which is likely to bring us much nearer to R1. The donated amount to Haiku, Inc. this year was rather impressive, which makes it possible to think about more contracts for Haiku developpers, but also things such as giving Haiku shirts to people showing out Haiku at various free software conferences (to strenghten the image of the project).

Axel proposed a patch hour on sunday. An ongoing problem in Haiku is the unability to handle patches submitted by users on Trac. Our policy is to review the patch, and ask the author to improve it. Quite often several rounds of improvements are needed, and people don't react too fast or give up on the amout of work needed to get the patch in. So, the patches tend to accumulate in trac and never get commited. They get out of sync with svn trunk, and it is not possible to apply them anymore. So, Axel took the list of 144 patches waiting on Trac, and wrote the ticket id of each of them on a piece of paper. Each of us was given 5 tickets to look at and make a decision. Either cleanup and apply the patch, or reject it if it doesn't work. At the end of the hour, about 40 tickets were closed. Some of us continued looking at the list over the week, and now there is less than 80 patches left, so the list has decreased by half.

As the weekend was over, the coding sprint started. 9 developpers were present this year : Matt Madia, François Revol, me, Olivier Coursiere, Ingo Weinhold, Michael Lotz, Oliver Tappe, and Rene Gollent. With the imminent switch to Git, Matt worked on getting a buildbot running with it to replace Build-O-Matic that only does SVN. However, he ran into some weird problems with building the now 10 years old gcc2 on FreeBSD, so not everything is working yet. François worked on bringing the 68k port of Haiku back in compiling state, as it was broken by some architecture changes. This was a success, as we can now run KDL on the aranym emulator. The work stopped at needing a build of the ICU package, which is a bit painful to do for platforms other than x86. Olivier worked on Lazarus, a Qt-based Delphi clone that now mostly runs in Haiku. He also made some stress testing of Haiku by copying the OpenOffice sourcecode around. Eventually, he found a bug in DiskUsage and fixed it. Michael and Ingo started tracking a memory corruption bug that may be the cause for the few remaining cases of FS corruption. But this ended up in writing KDL tools for tracking memory use, which will come in useful to track memory leaks, looking at pages owners and similar stuff. Oliver worked on fixing our wchar_t support. He got it working but needs to test compatibility with BeOS applications. The change involves the compiler support for wchar_t, and any application using that needs to be rebuilt. If we can't get it working in a way compatible with BeOS, it's likely that only gcc4 built parts of the system will get the fix. Rene Gollent worked on some TODOs for the debugger. One part was saving and resoring the view layout of Debugger accross sessions. The other was starting to add a CLI mode. When both are done, Debugger will replace GDB as the default debugger for the system. The CLI mode is needed mostly to debug app_server crashes. I worked on various areas of the system, but most notably reworked (again) the notification windows (I'm now rather happy with the result), and fixed bugs in the game sound API which now seems to be working fine.

Overall this coding sprint week was very productive, with several hundred commits improving the Haiku codebase. This also apparently boosted donations to Haiku, Inc. quite a bit. I'm ready to attend the next one.

Address change

Posted by pulkomandy on Tue May 10 22:42:41 2011  •  Comments (4)  • 

Following some problems with my router and DynDNS settings, the site is now available at http://pulkomandy.lexinfo.fr . Please update your bookmarks.

Site launched

Posted by pulkomandy on Wed Aug 19 18:19:49 2009  •  Comments (0)  • 

C'est maintenant officiel : ceci est le nouveau site web de la pulkoteam!

Voil, c'est tout... bonne visite

Ah oui, je ne savais pas trop o mettre ma vieille page avec des logos divers vectoriss... donc voil a c'est fait.

Hello World

Posted by pulkomandy on Fri Jun 26 17:42:56 2009  •  Comments (4)  • 

This is the new server of the PulkoTeam! Enjoy your stay here.

Everything is still work in progress, so please be patient.

Warning: this site looks simple, but it uses css3 features and some other things that require a modern browser. It was tested with Opera 10, Firefox 3, Internet Explorer 8 and Chrome 3. Anything older may not work. Don't complain, upgrade your browser or disable css.