| Blog |
|
| Releases |
| One Less Proprietry Format | |
|---|---|
|
Date: 9/6/2004 | LgiRes, the resource editor for Lgi applications can now read and write directly to valid XML. This means that the "lr8" format that it has been using for the last year or so is going the way of the dodo. However it was pretty close to XML already, I just needed to make a few changes here and there to be fully compliant.
For those of you that edit the translations by hand it shouldn't make too much difference, but I'll have to update the translation instructions to talk about the differences required to conform to XML. The upside of course is that with the resource file being XML all sorts of tools can be applied to the data. I'm not sure what benifit that will be yet, but it sounds good in theory right! Just remember: Proprietry == Bad. |
| (0) Comments | Add Comment | |
| Mdi Windows On BeOS | |
|---|---|
|
Date: 7/6/2004 | On linux and windows, child views (HWND etc) can overlap and keep their internal order. This makes implementing Mdi window "Real Easy(tm)". On BeOS however overlapping child windows are not garenteed to paint in any order so you have to implement overlapped windows FROM SCRATCH!
ARRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGG!!!!!!!!! Yes, you have to map mouse, keyboard, painting and everything else into virtual windows. Oh boy I'm so not looking forward to getting that right. Update: I just found a class lib for doing MDI windows on BeOS. Which has given me some ideas on using real BViews. Which should make life a lot easier. I think by clipping the output of each MDI child and also remapping user input events by hand I can work around the problems with overlapping BViews. Rather than implement a virtual windowing system. |
| (0) Comments | Add Comment | |
| Why Windows Will Die | |
|---|---|
|
Date: 7/6/2004 | As a lot of geeks can atest to, keeping a family member or friends boxen running is just par for course. In the old days it involved helping them with hardware purchases, rebuilding after HD's die, installing applications for them and even do some basic computer training.
But in more recent times it's turned into configuring firewalls, getting rid of viruses, setting up secure email and update the virus definitions. However I'm finding out the hard way that Windows is so insecure that I'm basically going to HAVE to migrate all the computers I have to administer over to Linux simpily to survive. The internet is such a acidic environment for the baby skinned Windows that it doesn't stand a chance. I don't have time to be constantly fixing compromised machines anymore. There are software solutions for this, primarily software firewalls and av software but it's a moving target. And they don't always work as advertised. And in any case the av software is always out of date with the current batch of viruses. Where as Linux is secure out of the box and requires a great deal of very skilled knowledge to compromise. People won't go to Linux because they want to, they'll go to Linux because their tech friends get sick of re-build compromised Windows boxen. |
| (0) Comments | Add Comment | |
| Gdi Resources | |
|---|---|
|
Date: 2/6/2004 | The big problem with coding in general is tracking and debugging memory and resources. If you can be sure that an object is allocated and freed correctly, and then not accessed after it's freed you are a long way towards stability.
A long time ago someone mentioned on email that an Lgi application would eventually use up all the GDI resources and either crash or just display everything in black and white. So I decided to look into this and so I jumped on google and hunted around for some tool to track GDI resources and tell me where the leaks are. Anyway all of them were either too expensive or didn't work so that was a dead end. Well what self respecting coder can't "roll his own"? So I wrote a little tracker module that redirected all the GDI subsystem allocation and free calls through my own API. And then track the handles being used by the application. This took a few hours but this morning I got the results I needed. Indeed the application was leaking handles. And mostly because I was freeing a HDC before selecting the original brushes and pens back into it. So now Lgi has an optional module for tracking GDI handles. It works by tracking each handle during runtime, and then dumping out a list of unfreed handles with the file/line number of the allocating source when the program exits using the Visual C++ debug console. Runtime performance is mildly affected but it's still pretty fast, maybe 60% of full speed. Which is still very usable. I don't think this will affect the general stability of Scribe, but it should mean you can run it for longer and use less resources. I've also been leak testing the general memory usage as well, and thats showing a lot of improvement. On Linux I was seeing footprint size increases of 80MB an hour or so. Now it's growing by a few MB an hour instead. Still not perfect but a little more reasonable eh! |
| (0) Comments | Add Comment | |
| BeOS file handle state | |
|---|---|
|
Date: 1/6/2004 | I'm working on porting the process handler class of Lgi to BeOS and I'm wondering how to get state information out of the file handles that are connected to the stdin and stdout of the process that is spawned by the class. i.e.
int s[2], pid; pipe(s); if (!(pid = fork())) { // stdout -> Read close(1); dup(s[1]); close(s[0]); // setup read & write handles execv(Exe, Args); } while (!exited(pid)) { // read from pid's stdout... IF there is data // available. On linux you can use poll }Anyone know an equivilant way to find out whether there is data on the handle to read? If I can fix this I can get my Ide working on BeOS and be twice as productive. i.e. more BeOS releases sooner. |
| (0) Comments | Add Comment | |
| Blog UI | |
|---|---|
|
Date: 1/6/2004 | I've fixed the little calendar on the sidebar to actually have working navigation links. So that you can scroll through historical blog entries.
Yes when I get sick of C++ I play with PHP :) |
| (0) Comments | Add Comment | |