Fooling Around // Software Production Line

It is amazing how bugs go through versions and years. Visual Studio’s IDE dockable windows framework is cool, no doubt. But it was since 2005, if not earlier, that tool window undocked by a double click while application is running (debugging session active) is brought to wrong position and is tending to go out of screen area being re-shown.

This is exactly the behavior in 2008 version, regardless of reworked framework and fancy icons/hints/placeholders for the window being dragged. But just now it was even better. I double clicked “Find Results 1″ window to maximize the window… and it disappeared. After looking for it through menu and other GUI elements, I finally found it at the rightmost border of the secondary monitor:

The other day I “wrote some code” to workaround an extremely stupid hardware issues. The depth of idiocy is just incredible: to release a bunch of hardware that just don’t work, release a number of firmware updates that just don’t fix the simplest thing: HTTP compatibility. If there was a single little try to see how this piece of crap comminicates with any WinHTTP based application, an error 12152 ERROR_WINHTTP_INVALID_SERVER_RESPONSE on the first second of execution would imminently come up and demonstrate that someone has to be fired without any hesitation.

Things, however, definitely went a different way with hardware still on the shelves and no firmware upgrades available on the website. Our customer got into trouble having already recommended his customer the buggy thing in amount of X and forwarded us the question of getting everything working. As we decided to make a step towards, I needed to “write some code” to settle the problem.

However, the story was about a different thing. So in order to put a comment into code that explains what kind of problem we are dealing with, I copy/pasted a fragment of HTTP request/response content from Wireshark into source file being edited within MS Visual Studio .NET IDE. Wireshark copies text with some weird line endings, I knew that. I removed extra empty lines from pasted text and actually did not expect anything to go wrong. However who appeared to be wrong was me.

Initially there seemed to be no problem, I tried to compile code, fixed some compiler errors, even started application. I was somewhat confused that the application did not hit my breakpoint while it should. Then I noticed it did not even generate code for this line. As these things do happen with development environment, I re-opened IDE, deleting .NCB for the project and Rebuilt All. The problem however did not go. After further code modification, the compiler started giving errors and shown wrong lines in build output, which did not match source code line numbers.

This started being completely stupid: I was to look at wrong identifier, search through entire source file for occurrences, see if this particular occurrence might be actually a problem for compiler and so on. I made it compiled successffully but under debugger there were still wrong line numbers which made it impossible to debug and set breakpoints.

At this point I remembered Wireshark and line endings. Just removing the comments did not worked. And since visually everything was OK with the source, there should be an easy way found to normalize text. And what I did was the following: I started new message in Mozilla Thunderbird and copy/pasted entire source file content into Thunderbird’s editor. Then copy/pasted back into Visual Studio and finally got the things fixed.

It is amazing how it might come that Microsoft Forums‘ RSS feed appears broken on Google Reader with duplicated entries for each of the items.

Regardless of whose the bug is, it seems to me that it is the Microsoft’s one, both are sophisticated applications of a large scale while RSS thing is just nothing in comparison. Was it really difficult to make the darn thing work?

It seems that everything is buggy nowadays. Some things - more buggy, some are less. I did not expect Microsoft Forums website to be so… so… of so improper quality. Especially compared to variety of popular forum software, free phpbb, google news etc.

MS WYSIWYG post editor can stand no criticism at all, it is one entire bug under FireFox browser. What I recently start getting is a view of the forum which seems to exclude weeks of recent data:

Version 2008 (9.0) of Microsoft Visual Studio .NET 2008 Service Pack 1 development environment brings new annoyances in. It seems to be still freezing and crashing on certain source code files, just as previous versions did and additionally there is a new trick in:

A termination of debugged application quite often ends up with a crash. Once crashed, IDE is still alive (thanks, really) but no debugging session will ever start again. A restart of IDE is required. Posted a crash report once again, hopefully someone is receiving them on MS side and takes to consideration.

Visual Studio .NET 2005 Service Pack 1 started freezing on a solution it opened and compiled just recently. Deletion of *.ncb, *.aps, *.suo and intermediate/output files did not fix the problem, however what appeared to be a workaround was a rename of a subdirectory with a Cabinet (CAB) project .vdproj, which was one of the solution’s projects.

Installation of Visual Stuidio .NET 2008 might be the cause, but anyway I love this game <grrr>

Just recently there was a problem discovered in considered to be stable DirectShow component (the problem itself is not fatal - access violation while being used in improbable scenario - and thus it may appear it is even ignored), another “pleasant” thing came up with an API from another vendor.

The camera vendor is recognized in the industry and even considered to be among leaders, kind of “cheap for superior quality”. Their SDK/API has always been offered to reach several goals: the first was to cover product line with unified access method; the second was to embed implementation of a not so much popular TFTP protocol used for this type of hardware (rivals use more popular protocols: HTTP, RTSP). These not include regular things like to documented access to variety of features, availability for Win32 and Linux etc.

API documentation has always been not very much accurate as if it was given insufficient attention but luckily it was quite simple to figure things out. Another warning thing was that native software worked directly, without SDK: it was not very good for independent software vendors like us because there was a suspicion that SDK was something complimentary and was undertested. Fortunately however, the vendor decided to change this and their mainstream software started using the same SDK redistributables available for independent vendors also.

The first incident was recently when the vendor changed SDK implementation without changing published API and without giving any notice in documentation on one of the features. It did not break compilation or anything in our software, however it started working differently in production environment. We started receiving complaints and since we did not find any documentation changes, contacted the vendor’s support for comments and found out that implementation has been changed…

Now we got a new issue. As mentioned before, SDK’s advantage was to cover product line being constantly extended. New hardware from the product line appears to be quite sophisticated - a camera with multiple sensors. I believe this was not the thing foreseen when original SDK was designed so there was a kind of solution to workaround indexed access to individual sensor parameters in the API. However it appeared now that new products don’t support some of the older product features and SDK instead of returning a kind of “unsupported” error code to the requests, instead it messes other values. So it appeared that unified access to the product line was broken…

Everything was finally sorted out but in total it took a lot of time to. First of all, the problem due to its nature spread to production from where the dealer started receiving complaints from his client. The dealer in his turn forwarded the issue to us where we had problems investigating it because this particular piece of hardware is a kind of rare and expensive. When we gather sufficient data to think of the case as an SDK bug we forwarded the issue to the vendor.

Obviously the vendor responded with ridiculous suggestions assuming us to be complete lamers. Still we were in position to help our client and resolve the case, so spent some time to gather additional information to prove the supposition of an SDK bug. It took quite some time at our expense while finally we could work out a workaround for the problem and soon after receive a confirmation for a bug… Can we expect it to be fixed with next SDK update? “We will do this some time later”.

Why things happen this way? OK we are a small ISV with our own problems getting things work as expected. The vendor, however, is a high technology leader, well known and recognized throughout the industry, a subject of a completely different scale. Expensive hardware ans software is involved and we are still getting ridiculous problems at the output.