I work on my software in my free time, so I get around to stuff when I can, and my life is busy enough with work, family and friends. Fitting coding in is a acheivement in itself. So patience is required.

Because InScribe does, and who'd buy software if they could get it for free? Jeez it's not like it's expensive or anything.

I use C++ exclusively for executable code. On windows I use M$ Visual C++ 6 and on Linux I use the gcc installed with Gentoo.

My applications are targetted to run on Windows 2000 and XP. But I also try and support Windows 98 and ME. So generally they run the best on 2K/XP, and most features work on 98/ME, but some things might not work. If you are running 98/ME then it's a good move to install IE 5.5 or above even if you don't intent to use it so that it updates a lot of your OS's system DLL's which Scribe will assume are reasonably current.

I don't support Windows 95 at all, and I don't expect my programs to run in that environment and I don't provide support to users running '95. In general it's so different to '98/ME that it's a whole 3rd set of code that I'd have to write and support. On top of that lots of important functions that I need weren't added until Windows 98. According to Google's Zeitgeist only 3% of the computers used to access Google were running '95, which is not enough market share for it to be worth supporting another legacy platform. '98/ME is bad enough.

For production builds I always exe pack the .exe and .dll files to keep their size small. For betas and test builds sometimes I either forget or choose not to bother with packing the executables. After they're zipped the difference is small anyway. So don't be alarmed if the build your using is twice the size (unzipped) as the previous version, most likely it'll be back to normal in the next final release.

Yeah, here.

I do release debug builds, which you can use to help me fix crashes. If you want to run a debug build read this information to get started. If there is no current debug build for the application in question then ask me and I will provide one. You'll find them at the top of the history on the application's page.

These are my hints at what sort of quality I expect a release to have. They aren't garentees of anything and if I receive feedback to the contary I'll often change the tag on a release to reflect my current feeling.

"Stable" is obviously where I consider a release mature for everyday use without any nasty pitfalls.

"Unstable" is a release that I know has unfixed bugs or I suspect has problems. Generally you'd only download this to help with testing or if you want to try out some brand new feature not available in a Stable build.

"Alpha" releases are incomplete and buggy, and are only for the really adventurous. They require lots of patience and coxing to do anything really useful and a more than likely to crash just when you least want them to. Alpha is a bit like Unstable but only more so.

"Next" is the just information about where I'm up to with the next version. People find it helpful to know where things are at so they don't bug me about something I've already implemented or fixed. If there is a release marked Next then it's generally whatever is building on my machine at the time and is completely untested. Usually it's a test fix for an individual user.

Finally "Legacy" releases are old software that I no longer will support or improve, but I provide for those who may find some utility in using.

I'm not developing for BeOS any more. Although LGI's BeOS bindings (ie support) is still there and I'm not doing anything to invalidate them, I find using/developing for BeOS tiring and non-productive. I can't get work done in BeOS so I've stopped trying. If BlueEyedOS, NewOS, OpenBeOS, this or any other BeOS clone ever becomes reasonably usable and used then I will open up the 'BeOS' port again. Until then it's Win32 and Linux all the way.

Yes, I was working on an AtheOS port at one stage but the UI libraries are too immature to get anything working. There was also no debugger, which I have decided is a reasonable requirement for working on a port to a new operating system.