| Blog |
|
| Releases |
| 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 | |
| i.Ftp ala Linux | |
|---|---|
|
Date: 28/5/2004 | Yes the unholy trinity is here! i.Ftp on Linux joins the Win32 and BeOS build's to make the first simultaneous release on 3 platforms!
Make your time! |
| (0) Comments | Add Comment | |
| i.Ftp v1.82.... BeOS-Zeta Release | |
|---|---|
|
Date: 27/5/2004 | Yes thine eyes do not deceive you, there is a new BeOS binary on MemeCode after all these years. The app that lived first on BeOS r5 now lives again. Behold i.Ftp for BeOS!
And shortly a Linux build will magically appear, completing for the first time in history a tri-platform release for MemeCode. Windows, Linux and BeOS. Oh happy day! |
| (0) Comments | Add Comment | |