[mdlug] Reverse-engineering data protocols

[Aaron Kulkis]

David McMillan wrote:
> On 3/1/2011 2:44 PM, Aaron Kulkis wrote:
>> Have you contacted the manufacturer?
>      Oh, yes.  First thing I did.  And I'm still working my contacts on 
> that end, but sometimes it seems like this manufacturer rolls 10D100 
> magic 8-balls in order to decide what data to share and what not to.  I 
> suspect a large number of departments with little or no unified policy 
> on proprietary-vs-open information.
>> It would probably be simpler for them to just write a small
>> bit of code to close the logging file, and start a new one
>> (with a different name), and send you a new file.
>      That I suspect won't happen, based on previous experience.  I'll 
> spare you the sordid details, but this particular supplier writes their 
> software the way *they* think it should be, customer feedback be hanged, 
> regardless of how big the customer is.  They keep getting business 
> because their stuff is *good,* no question -- I keep using it because 
> it's simply the best there is for what I'm doing -- but they seem to be 
> firmly convinced that they know better than the customer.  Although, 
> given my own experience with their largest customers, I can't entirely 
> blame them for that attitude...
>      I did in fact run the logging software through a reverse compiler 
> (the last few years, this vendor has been moving towards writing most of 
> their Windows-side applications in un-obfuscated .NET), but it didn't go 
> anywhere.  This particular app was probably written by a dept that is 
> still sticking to VB6.
>> And no, I don't like Windows at all -- but without feedback
>> from users, they'll never know that their logging software
>> is the pits.
>      To be fair, I really am using this piece of software in ways it 
> wasn't intended -- it wasn't intended as a tool that would see lots of 
> heavy constant use.

Sounds like this company is creating an IMMENSE
business opportunity for anyone who can create
decent test equipment AND

a) be responsive to customer requests
	OR
b) open-source the software
[After all, you're making money on the test
equipment, not the hardware drivers -- something
which massive numbers of hardware manufacturers
utterly fail to comprehend.]