The Developer Journal

05 December 1999

Well, I can tell you that the weekend hasn't been uneventful :-) I released DarkStep 0.912 on Friday (the 3rd) late in the evening and it didn't hit the download sites till morning the next day. Now one of the private beta testers had told me that they had a color problem with specific settings on Chronos, LSXCommand and Popups but I had never been able to duplicate it on my machine even with his Step.Rc settings and I'd thought that it was an anomaly. I was proved wrong on Saturday as bug reports kept pouring in with the same error - color problems.

I spoke to a couple of users who had the problems and got their Step.Rc settings but wasn't able to identify any common factor among any of the people. I still couldn't duplicate the problem on my machine either. Then I realized something - I always run debug builds on my machine so that I can identify a problem if a crash occurrs while all the users were running release builds - could that be the problem? I switched to a release build and immediately ran into the color problem on Chronos! I was really surprised as I couldn't for the life of me understand why this should be ...

And as the problem wasn't there on the debug build, I couldn't run DarkStep through the debugger to identify the bug! So what was I going to do? I decided to use a MessageBox and see whether I could identify the bug that way but when I used the MessageBox function to print a warning message just before calling the GetRCColor function in my LSAPI wrapper, the bug disappeared and the correct color was read in! Now I was really mystified ... how was I to trap this elusive bug?

I then remembered a logging function that I had used when I was first coding the Hook.Dll for LiteStep. I couldn't find the original function and so, I decided to rewrite it again quickly. This is what I came up with:

void Log(LPCTSTR des, TCHAR *line){

	TCHAR tm[9];

	FILE *f = _tfopen(_T("C:\\DARKSTEP\\ERROR.LOG"), _T("a+"));

	_tstrtime(tm);

	if (f){

		_ftprintf(f, _T("%s - %s  %s\n"), tm, des, line);

		fclose(f);

	} else

		MessageBox(0, _T("Error Opening Log File!"), _T("Error"), MB_OK);

}

I called the above function to log what was going on in the LSAPI wrapper function GetRCColor and the function it was calling in the DSAPI - RCReadColor. I discovered that the problem seemed to be in the Tokenize function which RCReadColor calls to see whether a color value has one parameter (a hex value) or three (individual RGB values). For some reason, the Tokenize function was failing in certain cases and that too only when running the release build. I went ahead and tried a couple of variations on the Tokenize function till I got one that returned the correct value and that was that ... but I still don't perfectly understand why the bug would pop up only when running the release build ... Oh well ... :-)

On another note, I went ahead and did some updates to The Developer Journal today and revamped the Downloads page a bit so that you can download DarkStep, the DarkStep SDK and my module from there. I removed all the old LiteStep stuff except for my LS modules but the LS modules will not be updated any longer as I am porting them to DarkStep native format and continuing development for DarkStep ...

03 December 1999

Well, now that was a long time to be gone now, isn't it? Unfortunately, things have been so very hectic with DarkStep in the last month or so after I did the first private beta release that I just haven't had the time to keep this journal updated or to do anything else rather than to simply code, code and code some more :-)

Anyway, I am finally at a point where I can say "OK, I am satisfied with how DarkStep is shaping up, I can now take time and do things slowly while people play with what I've done so far" - and in addition to that, I have just completed work on the next release of DarkStep and so have a little time to play <vbg>

Anyway, DarkStep has been moving along pretty well and I am actually surprised by the enthusiastic reception the shell has received. I did want it to be sleek and fast and a lot of people seem to like that. So those are the two elements that I try to ensure remain constant through every new build. In fact, one of the reasons that I haven't released 0.912 yet is the fact that I wanted to make sure that neither resource utilization nor speed had been affected due to some of the major behind the scenes overhauling of the API that I had been doing recently.

So what is in the cards for DarkStep next? Well, it is a bit hard to say as I have discovered that I have to code a few modules as well and the next goal for DarkStep has changed considerably from what I envisioned for it originally when I started coding. I guess it really hasn't changed that much but I have added a lot more waypoints before we get where we are going :-) I had been trying to get multi-threaded functionality on DarkStep before I did the next release so that each module would be loaded into its own thread but discovered that I had some problems there because the API wasn't thread safe. So I have shelved that idea for a while though I might take it up again later on to see how it turns out ... but I do intend to either do two versions of DarkStep (multi-threaded and single-threaded) or drop the idea alltogether if resource usage goes up drastically on a multi-threaded version.

I have just completed the addition of several new features to DarkStep such as the ability to confirm whether to load each module in your [StartUp] section (sorry, no wharf module confirmation <g>) via a hotkey (F8) or a command-line option (-ask). I have also added a new !bang command called !BangList which lists all the !bang commands currently registered with DarkStep in a dialog - pretty handy as a reference work :-) I have also changed the Splash screen as Lapo has done a spiffy new logo and beautified the About dialog a bit ... Quite a few changes, huh? I guess it's about time I got that release out the door then ...

Once this release goes out the door, I intend to do some major overhauling on DSTasks to make it act more like Maduin's Systray.dll when you load it as a LoadModule. I also intend to add !bang command binding for the DarkStep version of desktop.dll and do some major theming enhancements to the console on DarkStep. That should keep me busy for a while ...

Subscribe to The Cyber Chronicle

Site Design by : Lowspirit