Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25
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!


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;
if (!(pid = fork()))
	// stdout -> Read

	// 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