Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Wednesday, January 05, 2005

Ahh, the pleasures of deving on win32

Let's see how to put it nicely. Some UI designer once said "The more time user spends using your application is less time user doing whatever he actually wants to do.". The idea is that if your application gets in the way of the user, that's bad. I'm sure you can think of many examples of this (I'd bring few examples of my own, but I'm too zombie-state right now to be able to). So, for past two days, I'v been using M$ crap-Studio.

I could as well bang my head against the wall and still be more productive than trying to develop with that thing. I'v rambled about the crappyness of it before, so I won't go into details again, but bottom line is I decided the only way to be able to productivly develop is do it on linux - an OS that feels like it was designed from ground up for software development. So, I'm trying to push maximum amount of development to linux, to minimize the amount of time I need to spend with that crapstudio.

Enough ranting, here's what's going on. First - the roadmap. I reviewed the code per subsystem, and put together the list of things needed to be done - view roadmap. As you can notice, a large number of engine subsystems need improvements or complete replacements - that's pretty normal in current project state. First implementations rarely survive for longterm - "Plan to throw one away. You will, anyhow." - Fred Brooks, The Mythical Man-Month, Chapter 11. Or - to put it other way - "You don't fully understand the problem until the first time you implement a solution" - Eric Steven Raymond.

Starting from the top, the biggest issue right now is the partially upgraded event engine. While the new engine solved the first problem - multi-handler calling - by using Boost.Signals backend, the added syntactical improvements and de-coupling features of the new engine, while being a nice design touch, cannot be used afterall, due to the problems with win32 linker/dynamic loader. After numerous attempts to get past those issues, I can finally conclude that it is unfeasible to get the exports/imports right, at least with my current knowledge base, and thus I'll just have to go back to the original coupled system, and tie the EventTable with EventSource, most likely using macros, just as in original implementation. We still have the implementation benefits of the new engine, which is simpler and less error-prone, but we must drop the syntactical improvements. Today I'm too stoned to get that finished, but it should take a night or so to get it fully operational again.

Madcat, ZzZz

I have my own opinion about HN developing.
I want to have a completed core and ed2k module in the near future. I also want to have a completed HNSH that allows me to do anything useful with core (for example to see a download list or a upload list). All of this make a working HN. In this case we would be able to use HN in the near future. It will helps you to test the HN in the future.
This post has been removed by the author.
You could check out Dev-C++ for development on windows, it uses the MinGW gcc port and I quite like it:
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?