Move - done

Was up to 3:30am packing for the move. Woke up at 7am to finish. Movers arrived at 8:30. Finished moving me in at 1:25. Arrived at work for meeting at 1:50.

Will it blend?

Movers are booked for Thursday. It's kind of nice to think by the end of the week everything will be settled and my daily commute from Queens will be over.


An entire website dedicated to finding out how things react to being in a blender (with videos!)

http://www.willitblend.com/

I especially like the video on IT infrastructure

http://www.willitblend.com/videos.aspx?type=unsafe&video=novell

"If you find yourself fantasizing about putting your real end users in a blender: seek help. They're heavy."

Mashed potatos can be your friends...

Had this dream last night about this girl from tenth grade. She was smart, really pretty, and always talked to me before and after class. In retrospect, I think maybe she might have been a little sweet on me. I'm not sure which prospect is worse - that as I'm turning 30 I'm starting to distort my youth like Kevin Arnold from The Wonder Years, or that it takes me fifteen years to recognize that a girl likes me.

Marty loaned me the soundtrack to Transformers: The Movie, and now I have that Weird Al song "Dare to be Stupid" stuck in my head.

Found a couple more memory corruption bugs in Perl Core. Submitted a patch for one of them. Posted a question on perl5-porters regarding the other.

http://rt.perl.org/rt3/Public/Bug/Display.html?id=42648

In Philly this weekend. Plenty of work to do. At the coffee shop getting ready for a waffle and using the free Internet.

What does 483 square feet of flooring look like installed

Sawdust and magic numbers

Ah, the sweet smell of sawdust (and the annoying high-pitch whine of a mitre saw).... Floor being installed, finally.

Working from home. Continuing to debug my win32 heap corruption problem. Learned that the debug version of Microsoft's heap manager does do some memory poisoning under various condition to help assist in debugging corruption (think 0xDEADBEEF but for Win32)

Once again, Wikipedia to the rescue. Turns up the magic numbers are documented:

http://en.wikipedia.org/wiki/Magic_number_%28programming%29

TO summarize, here are the relevant constants for Win32:

0xABABABAB LocalAlloc() guard bytes
0xBAADF00D LocalAlloc() uninitialized allocated heap memory
0xCCCCCCCC Uninitialized stack memory (C++ runtime)
0xCDCDCDCD Uninitialized heap memory (C++ runtime)
0xFDFDFDFD C++ allocator guard bytes
0xFEEEFEEE HeapFree() poison

The next time you see a debug program crash, look for one of these constants and there's a good chance you can immediately tell the class of memory corruption.

What does 483 square feet of hardwood flooring look like?

Debugging heap corruption on Win32

So I have spent the last 28 hours in two days trying to debug a heap corruption problem on Win32. I have BoundsChecker, which is a great tool for finding certain classes of faults, but it turns up that when it comes to detecting accesses to free'd memory, all BoundsChecker can do is poison the memory on free(), which increases the chance of a crash on read (since the pattern is not a valid pointer). This is helpful in some cases, but in my case I have code actually **writing** to free'd memory, which prompts the debug CRT to panic the at some point in the future when it looks at the heap pool.

On UNIX/Linux, I would be using Electric Fence, a great tool written by Bruce Perens which takes advantage of the VM subsystem to put guard pages after allocated pages, and lock memory after free(). If only there were some equivalent for Win32....

Well, it turns up there is. It's called Pageheap.exe, and it was written by Microsoft.

http://support.microsoft.com/default.aspx?scid=kb;en-us;286470

It's an obscure and not well advertised tool which supposedly provides functionality equivalent to Electric Fence but on Win32. In the process of trying it out now.

More on Hauppauge

Writing an entry while I wait for boundschecker to do it's job... :-)

Heard back from two different support engineers from Hauppauge this afternoon:

From Bill V:

Hello and thank you for your message. Linux support will eventually become available as with most of our other TV card products, however it may take some time, as it would be a matter of the chipset manufacturers releasing the necessary information to the Linux community so the 3rd party developers are able to write the drivers to support the hardware.

Regards,

Bill V.
Technical Support
[email address redacted]
Hauppauge Computer Works
New York

and from Jerry Fox:

Hello,

Most of our PVR models have Linux support and going forward I am sure there will be support for the HVR1600, it just takes time for the manufacturers to decide what info they are willing to release to the public communities.

Regards,

Jerry Fox
[email address redacted]
Technical Support
Hauppauge Computer Works
New York

Polite, prompt, and unfortunately lacking in any real content. They did not answer the question as to whether they were doing anything to add Linux support, but were quick to note that their other models do have Linux support. Of course, it's worth noting that we have little thanks to offer to Hauppauge for this, since the existing support was done by the community reverse engineering their drivers without their help.

I sent them a reply, hoping that perhaps I was missing something -- after all perhaps they were doing some work themselves to release a driver:

Jerry, Bill,

Thank you both for getting back to me so promptly.

In the past Linux support for the current cards has come almost entirely as a result of the hard work of dedicated individuals willing to take the time to reverse engineer your products. It has not been a result of Hauppauge providing specifications or documentation that would normally be used to write such a driver.

Unfortunately, from the posts I mentioned in my previous email it would appear that the IVTV developers have grown tired of adding support for new Hauppauge products without any assistance and therefore have no plans to support the HVR-1600. While Hauppauge clearly reaps the benefits of increased sales due to Linux support, it does not appear to be willing to provide any of the information necessary to enable this.

If Hauppauge is taking actions to add support for the HVR-1600 then I would be thrilled to hear about them. If the expectation is that the IVTV developers are going to spend their time reverse engineering the CX23418 on their own as they did with previous products, then the Hauppauge support website is at best misleading.

So, the original question stands -- is Hauppauge taking any action towards adding support for the HVR-1600 on Linux? Are they taking any action to support the ivtv developers in adding support for the HVR-1600?

Thank you for your time,

Devin

the answer appears to be a resounding "We're not doing anything":

The tuner information would be necessary to be provided by the Hauppauge developers, as it was in the past with all of the PVR products. So in addition to the chipset information, the tuner information will also be necessary in order for the Linux developers to write the drivers.

It will come in time, however there is currently no time frame available.

Regards,

Bill V.
[email address redacted]
Technical Support
Hauppauge Computer Works
New York

In other words, their website is a flat out lie. The website states "Linux support is in process". They are not working on a driver. The community is not working on a driver. Who do they think is adding support? Magic fairies?

Typical Microsoft

Microsoft includes a compiler option "/Za" that disables Microsoft-specific extensions and turns on ANSI C and ANSI C++ compliance. Seems like a good idea if you're writing code that intends to be portable across multiple platforms.

http://msdn2.microsoft.com/en-us/library/0k0w269d(VS.80).aspx

The kicker? Guess what doesn't compile successfully:

#include <windows.h>

Here is the start of the output:

------ Build started: Project: Foo, Configuration: Debug Win32 ------

Compiling...
Foo.cpp
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinNT.h(477) : error C2467: illegal declaration of anonymous 'struct'
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinNT.h(495) : error C2467: illegal declaration of anonymous 'struct'

Yeah, Microsoft's main Platform SDK entry point isn't ANSI C compliant, which basically means there is no way to write a Windows application that doesn't require Microsoft compiler extensions.

Weekend

Went down to Jayden's birthday on Saturday. It was good to catch up with the family. He is getting so big. Pics to follow as soon as I can get them out of my camera.

Spent Sunday at the Manhattan apartment with Vikki. Went and saw Aqua Teen Hunger Force tonight. A silly/funny movie.

Back to work tomorrow... Floor is being installed on Tuesday so I have to work from home.

Hauppauge Linux support for HVR-1600?

Since I am about to move, I was thinking about picking up a new HVR-1600 so I could pick up over-the-air ATSC from the Empire State Building.

Hauppauge has updated their support site to state the following:

Linux support for the WinTV-HVR-1600 is in process. When the WinTV-HVR-1600 is added to the growing list of over 30 supported Hauppauge products with Linux open source drivers, an entry will be made in the LinuxTV.ORG Wiki.

They state that it "is in process". Are they saying that they are making drivers? Or is this clever language to suggest that once again they will just wait until the open source community reverse engineers the product, at which time they will just add a link to the IVTV website as they did in the past. It's really the best case scenario for them -- they don't have to do any work whatsoever and yet they reap the benefits of increased sales to Linux users.

Unfortunately, it looks like the IVTV people have no intent to do the reverse engineering:

http://www.gossamer-threads.com/lists/ivtv/devel/34608?do=post_view_flat#34608

Sent the following mail to Hauppauge Sales:

I am currently a very satisfied owner of five Hauppauge cards (two PVR-150's 2 PVR-250's and a PVR-350) and am considering the purchase of an HVR-1600. However, all of my currently owned cards are being used under Linux.

The Hauppauge support site indicates that work is in progress to support the HVR-1600 under Linux:

http://www.hauppauge.com/pages/support/support_hvr1600.html

However, the open source ivtv project has stated that they have no plans to support the card (largely due to Hauppauge's lack of providing any supporting datasheets or specifications).

http://ivtvdriver.org/index.php/Supported_hardware
http://www.gossamer-threads.com/lists/ivtv/devel/34608?do=post_view_flat#34608

Is there an ongoing effort inside of Hauppauge to provide the relevant drivers? If so then this is excellent news and should be made known to the ivtv project. Or are you basically saying that eventually the open source community will figure out how to reverse engineer our product without our help, at which time we will put a link on our website to the ivtv project?

I would love to purchase several of these cards. If you could please provide a summary of specifically what actions Hauppauge is taking to provide this support I would appreciate it.

Thank you,

Devin Heitmueller

Hopefully they might get the hint.

Moved stuff

Rented a van in New Jersey at 10am, drove it to New York City. Picked up my bed and dresser. Dropped off the bed in Philadelphia, dropped the dresser back in New Jersey. Got home by 6pm. Tired and achy.

Special thanks goes out to Dan, Vikki, Leah, and Greg who all helped me load/unload crap at various cities.

Now I'm hanging out with Lauren and Greg. We're making sugar cookies for Easter tomorrow. Christian rock is playing in the background.

Ick

Have come down with a pretty bad sinus infection which has left me with a sore throat and feeling pretty crappy.

Discovered another CPAN module where the original author decided to change the build behavior based on the presence of a ".svn" directory. The Params::Validate module has a tweak to the Makefile.PL that checks for the .svn directory and if it is there to change the CCFLAGS to "-Wall" (disregarding whatever flags were there before). Except he didn't consider the possibility that other people might want to keep the module under source control, and that they might not be using gcc. In my case, it took me half an hour to sort through 500 lines of output from MSVC before I realized that "-DWIN32" wasn't in the CCFLAGS).

I've seen this before in other modules and I understand the rational - the author happens to use source control and figures there should be extra testing or debugging code added that other users shouldn't see in a standard "perl Makefile.PL && make && make test && make install" from CPAN. In another such module, the author had a bunch of extra tests that were tied to his build environment. Unfortunately, using the presence of .svn as a means of detecting whether you are the upstream maintainer or just some guy who pulled the source from CPAN and stored it in Subversion is probably not such a good convention.

Perl pop quiz

What's wrong with this picture:

#!/app/clarity/perl/bin/perl

use strict;
use Error qw(:try);

my $result;
try
{
    print "setting result to abc\n";
    $result = "abc";
} catch Error with
{
    print "caught an error\n";
}

my $a = $result;
print "a=$a\n";
print "result=$result\n";

Check out the output:

[root@devin rtest]# ./quiz.pl
setting result to abc
a=
result=abc

When Dan pointed out the error after looking at it for a few minutes, I wanted to cry.

The answer, for those who might be interested, will be in tomorrow's edition of "Why Devin Hates Perl"