Unicode - what other issues?

[Mull5]

Regarding Paint.NET for Windows 9x:

In this forum's FAQs you say, as well as citing other reasons, that any Paint.NET version for 9x couldn't use Unicode-dependent features because 9x can't use it consistently. Actually, Unicode is a currently available download provide by Microsoft. The latest version is supposed to be stable.

So, could you spell out please a few of the other features that you would have to downgrade for, or otherwise have problems with in, a Windows 9x version of Paint.NET?

And is it true to suggest that accommodating 9x would necessarily degrade the program in any way for NT-based users (except insofar as you spent valuable time away from developing NT-only code)?

Can you counteract my suspicion that the lack of support for 9x systems reflects more a lack of will in the Paint.NET team and a corporate policy of 'OS lifespan and regular paid-for upgrades' in your sponsors, than any extra-ordinary hardship or burden that would be involved in taking the necessary steps to make Paint.net compatible with older Microsoft OS?

Without wanting to sound pushy: if you reply, I would be sincerely grateful if you would please answer my questions, and not avoid them by resorting to "Upgrade your browser!"-type replies.

Thanks (and good luck with Paint.NET 2.6).

[Rick Brewster]

Can you counteract my suspicion that the lack of support for 9x systems reflects more a lack of will in the Paint.NET team and a corporate policy of 'OS lifespan and regular paid-for upgrades' in your sponsors, than any extra-ordinary hardship or burden that would be involved in taking the necessary steps to make Paint.net compatible with older Microsoft OS?

It is 100% about "extra ordinary hardships". It is not a "lack of will", nor is it related to "corporate sponsorship." First off let me clear up that there is no "corporate sponsor" for Paint.NET. Yes, I work for Microsoft, but Paint.NET is neither sponsored nor directed by anyone other than myself. If I wanted to make Paint.NET support Windows 9x, then it would support Windows 9x. If for some reason I wanted to make it require BeOS, then it would require BeOS. Nobody has told me, "Rick this can only work on 2K or later. QED." Versions 1.0 and 1.1 only worked on XP, but enough people asked for 2K support that it was added for v2.0. However, the differences between 2K and XP are much smaller than the differences between 9x and 2K.

There are only 3 of us working on this project right now. Really, I'm the main one working on it on the code front, with Tom contributing really crazy things on occasion (the math and first-pass implementation behind Rotate/Zoom ... that was Tom). Dennis is what you might call our Localization Manager. We all work full time jobs in addition to our contributions to Paint.NET. Time is a very limited resource.

Let me enumerate why Paint.NET will never support Windows 98 or ME:

* I don't have the time or the patience to deal with supporting Windows 9x. I did it before on a previous project, one that was much simpler, and it was a burden that was not worth it. Each version of Windows does some things differently and you have to take those into account and test on every version that you support. Windows 9x consitutes something like 5% of the user base nowadays? The cost:benefit ratio is very small there.

* I don't have the equipment to do this. I don't have a copy of Windows 98 anymore, nor a test machine that represents what one might like to declare a "typical" Win98 machine. I don't have the time or the patience to track these down.

* I would have to rewrite large portions of our setup wizard. There would have to be a LOT of code written to walk around 9x's lack of a lot of things.

* Does WinVerifyTrust even exist on 9x? I don't know how or if certificates and code signing are handled on 9x. Does that require yet another package to be installed? I don't know. I'd rather not even deal with it. We require this functionality for our update manager.

* What about WinHTTP? Same thing. I don't know, and I don't want to bother.

* I would have to either have a really big installation package for everyone, or lead Win9x users by the hand for installing things such as the Unicode layer, the latest version of Windows Installer, etc. I do not want to spend my time doing tech support like this.

* I would have to rewrite portions of our SystemLayer DLL to work around functionality that Win9x does not provide. We use NT-only functionality for various purposes, and it would be a big pain to have to write 9x-compatible versions of these functions. Things are so much cleaner when you don't have to do an OS version check on every 5th line of code. I am not going to maintain two code bases.

So yes, we could support Windows 9x. But that would imply that everytime we want to add or change anything we have to find some 9x box and test it out to make sure something doesn't randomly break for some archaic reason. v2.5 essentially supports two platforms: Win2K, and WinXP/Server 2K3. There have been a few problems maintaining that compatibility, so I'd hate to imagine how bad it would be if we extended support to 9x.

v2.6 is going to support three platforms: Win2K, 32-bit WinXP/Server 2K3, and 64-bit WinXP and Server 2003, and it would just get worse then. What if I updated or amended some code somewhere and forgot to update the 9x code path? Oops. That would be a pain to track down.

It's just not worth it.