Rick Brewster

Paint.NET isn't tested on Windows Server. It isn't really officially supported, except as "you're on your own".

Run the disk cleanup utility (I forget where it is in XP). Make sure temporary files are set to be deleted. Hopefully that might knock out the %TEMP% directory. Mind you this just a hunch... Also make sure you aren't triple-clicking the installer EXE. Try clicking it one time, then press Enter on the keyboard. If the installer launches twice, sometimes things don't go well.

GDI+ in the Text tool wasn't removed for performance reasons. It was crash happy. The dancing ants aren't something I can just "make an option for". First, there's no options dialog. Second, I'm not adding an options dialog for the sake of 1 option. Third, the animation involved a lot of extra state that complicated things and made the code a little messy. Fourth, it was very slow and ate a ton of battery power. Fifth, the only reason the animation was there was to ensure contrast regardless of the image's contents -- and that was solved by using a stippled XOR pattern. Back to the text. Going forward, I simply can't justify doing features or a lot of work for the sake of XP. It's an ancient operating system that is quickly losing tons of market share to Win7. Hopefully someday soon you'll have a system with Vista or Win7 on it. And Win7 will give you a lot more in return that just "a better font handling experience." It's way better than XP.

Updated.

Run PdnRepair. Looks like your version of SharpZipLib is off.

Aha, I see. Will probably be easy to debug. Big target and all.

Confirmed. Thanks, I've filed a bug.

If you've exited Paint.NET, then all its memory is released. Same as if you killed it from Task Manager; the OS kernel itself does that. If it crashes then, then you've got another issue and I have no idea what it could be.

I haven't done any planning for 3.5.2 yet.

Actually it does look like there's a memory leak of some kind here. I've filed a bug. Should be easy to get a fix out with a v3.5.2 update or something. Sometimes with a .NET app you end up with what appears to be a memory leak, but it's just the GC (garbage collector) deferring stuff until later. Paint.NET always forces a full GC pass anytime something is done with the History (any action, or undo, or redo), so it's easy to tell if something is a "real" memory leak by just doing a small stroke with the pencil or paintbrush. Usually if a small 16mb allocation fails, it is because of VA fragmentation. Or some sad bloke is trying to run on a Celeron with 128MB RAM .....

Oh, I'm not saying it's desired behavior. I gave you the explanation though (VA fragmentation), and a solution (64-bit OS). There isn't anything more that anyone can do right now.

It's not available. See: [rule=7]rule #7[/rule] and [rule=8]rule #8[/rule].

Please remember to post in the correct section of the forum. Moved to Troubleshooting

A value is not overflowing. You are not being lied to. Things are not silly. See my post above. Virtual Address Space Fragmentation is not the same thing as a memory leak.

Looks like typical fragmentation of virtual addressing range. Long story short, if you install a 64-bit edition of Windows then all your problems will go away.

You're on XP. Your media player is using something called hardware overlay to get the video onto the screen with certain performance characteristics. This bypasses the frame buffer and is invisible to Print+Screen. This is not a bug -- it's not a bug in Paint.NET, and it's not a bug in Windows. Everything is behaving exactly as it was designed and intended to.

v3.36 allowed you to install to a removable drive, e.g. USB stick. This actually ends up being a very bad thing, so it is no longer allowed. The upgrade path for v3.36 -> v3.5* on removable media probably won't work, as you've seen.

But not if you've manually moved Paint.NET after you installed it.

Wow. Someone's been drinking crazy juice. Buggy? No, it isn't. Everything you listed is just you being irrationally mad and refusing to get used to some of the small changes in the new version. With what? A phone call? There's the release notes that details everything in the update.

Correct. The list of blocked plugins was not changed.

No. I looked at it for about an hour, but couldn't pin down what the specific problem in the code was. Since the other fixes were very important, I decided to release 3.5.1 now with them, and wait for another release to fix the issue you brought up.

Does your code really really really really need this much optimization? I'd shoot for correctness first. Paint.NET is already multithreading the thing; your biggest performance gains are going to be from dual core (+100% performance), and improvements to .NET's code generation (not in your hands). This stuff you're looking at will probably only net you a few %. I just am not convinced that it's worth it.

Moved to Troubleshooting Please remember to post in the correct section of the forum.

If you're inside of a critical section then you won't need to use volatile. You only really need to use volatile if you're writing lock-free code and you know exactly what you're doing (which excludes almost every situation, and everyone (including me)).

Mozilla makes $100 million+ per year on Firefox. Making money by giving stuff away for free is a profitable business model for many. Paint.NET does indeed make me money, via donations and website ads. Do you think I would tolerate the spiteful and moronic comments over at http://blog.getpaint.net/2009/11/06/a-n ... ntnet-v35/ if I weren't? But yeah, charging for a plugin is no big deal. He won't get any preferential treatment though -- e.g., if I start getting lots of crash reports, then it'll be blocked in the next update just like any other plugin would be.