Stuff

§¶Just because it is not your fault does not mean it is not your problem

asf asks:

I don't understand why you would change the reg key to workaround AV, it's their problem, and they need to fix it, you should not bend over for idiot AV vendors.

The answer is that it's my users that are affected and I'm the one getting the complaints.

Here's the problem: It's in the interests of the antivirus vendors to have their products as visible as possible to the user. To the extent this means a higher chance of detecting threats, that's good. The problem is in the rise in false positives, fueled by the increasing difficulty of detecting malware, as well as the addition of detection heuristics. Some of these are pretty sketchy. In addition to the lousy Registry check for Software/Freeware, some AVs used to flag VirtualDub as a trojan simply because it used the UPX executable compressor. The result is that I get complaints from users asking me why VirtualDub is a virus.

The frustrating part about this is that I don't actually have a way to tell the AV vendors that their software is screwing up. I'm not their customer and don't have one of every AV installed, and they don't exactly put an easy to find "tell us we &#*$ed up" link on their website. About the best I can do, then, is request that the user click the quarantine or "send us a sample" button in their AV. Unfortunately, that assumes they have the ability to do so. Locked down corporate setups are especially frustrating because they're often locked down and set to delete on sight. The result is that I have an annoyed user who can't run my program at all, and there's nothing I can do about it. The antivirus vendor might not even be able to anything, because they may have already fixed the problem and the installation may be old!

This isn't to say that I'm against antivirus software entirely. I've seen havoc caused by viruses back in my Amiga days, and I've seen how AV can affect the spread of Conflicker through a network. What bothers me is the way that antivirus programs now regularly make false accusations against third parties without recourse. VirtualDub's only been flagged a few times, as far as I know, but some vendors have had their software marked so many times that they have a frighteningly long list of false AV detections on their website. It's also wonderful dealing with bugs that turn out to be because of AV interference, such as files being locked in ways that are impossible according to Win32 semantics. Guess who gets blamed for the problems.

In the end, when writing software, you have to choose which goals you pursue, and in this case, there is an opposition between principles and user experience. Sure, I've done nothing wrong and I shouldn't have to code in workarounds for broken AVs, but this does nothing to help the user who is having trouble running my software. Just because the problem isn't your fault doesn't mean you don't have to implement a solution.

This release has been delayed a bit for various personal reasons, but a new experimental release is now out (1.9.1). This release contains a number of new features as well as a bunch of bug fixes.

1.9.1 contains a bunch of improvements to the video filter subsystem. The new V14 API now supports 16-byte alignment for vectorized code, and more importantly, now supports multiple source frames per output frame. This makes windowed filters easier to write and faster to execute, as in-filter buffering is no longer required. Several new filters have been added to take advantage of this, such as a frame rate interpolator (interpolate) and a filter to convert fields into frames (interlace). The deinterlacer has also been partially rewritten -- it now supports the popular Yadif algorithm and can upsample to field rate as well as output frame rate. The Plugin SDK has also been updated to V1.1 to cover the new changes in the V14 API (see sidebar link).

There are a couple of breaking changes in this version, hopefully none too annoying. One of them is that the blend curves now work in the frame numbers of the attached filter, since the existing behavior wasn't workable with generalized frame fetching. IVTC is now a video filter, which should generally be easier to work with and more flexible, but that means that the timeline now works in post-IVTC frames. Finally, for those who are poking Registry keys directly, VirtualDub's Registry key has moved from HKCUSoftwareFreewareVirtualDub to HKCUSoftwareVirtualDub.orgVirtualDub. I had to make this change to work around stupid virus scanners that reported any key with SoftwareFreeware in the name as coming from a dialer trojan.

I apologize for the lack of updates recently -- I have a bunch of stuff in the pipeline, but it isn't ready for release yet, and in the last couple of days, I haven't been in much of a mood to work on VirtualDub. When that happens, I usually try to find something else to work on, and this weekend, that ended up being my Atari 8-bit system emulator instead. Specifically, there were some reports of compatibility problems in the video emulation which I wanted to check out.

Well, about ten minutes into that process, I ended up hitting a bad bug in the thunk allocator in VirtualDub's system library, which I had to fix and integrate from Altirra over to the VirtualDub 1.9.x branch. Sigh. So much for getting away completely.

About two hours into the process, I still had sufficiently little information about what was happening in the real Atari hardware that I ended having to reverse engineer it from the specs. Thanks to the folks from the Atari Historical Society (now called the Atari History Museum, I believe), PDF scans of the original GTIA and POKEY specifications are now available, including gate level diagrams. (I haven't been able to find a document for ANTIC. If someone knows of one, let me know.) The problem with these scans is that they're very low quality and hard to read, so it takes a lot of head scratching to figure out what's going on. I'm not a chip designer, either, so basically I have to wing it with what I know about basic digital logic and try to match it up with what I know about the hardware. This can be a bit difficult and frustrating when the logic is encoded in three layers of NOR gates and the scan isn't good enough to indicate whether a signal is active high or active low.

Anyway, I'm definitely a bit late in learning about the details of the Atari 8-bit's GTIA chip, but I learned enough in the process that I couldn't find anywhere else -- or, at least, not in one place -- that I figured I'd just dump it all here in case anyone's interested. There are an amazing number of nuances to trying to emulate a chip exactly, far beyond what you'd get from reading the official documentation.