[GRLUG] Jenison Electrician

[Michael Mol]

On 1/27/2010 12:06 PM, Bob Kline wrote:
>
>
> On Wed, Jan 27, 2010 at 11:50 AM, Michael Mol <mikemol at gmail.com
> <mailto:mikemol at gmail.com>> wrote:
>
>     On 1/27/2010 11:34 AM, Bob Kline wrote:
>      >
>      >
>      > On Wed, Jan 27, 2010 at 10:59 AM, <mikemol at gmail.com
>     <mailto:mikemol at gmail.com>
>      > <mailto:mikemol at gmail.com <mailto:mikemol at gmail.com>>> wrote:
>      >
>      >     On Wed, Jan 27, 2010 at 10:45 AM, Bob Kline
>     <bob.kline at gmail.com <mailto:bob.kline at gmail.com>
>      > <mailto:bob.kline at gmail.com <mailto:bob.kline at gmail.com>>> wrote:
>      >
>      >
>      >
>      >         On Wed, Jan 27, 2010 at 10:36 AM, <mikemol at gmail.com
>     <mailto:mikemol at gmail.com>
>      > <mailto:mikemol at gmail.com <mailto:mikemol at gmail.com>>> wrote:
>      >
>      >
>      >             On Wed, Jan 27, 2010 at 9:30 AM, Casey DuBois
>      > <casey at grlug.org <mailto:casey at grlug.org> <mailto:casey at grlug.org
>     <mailto:casey at grlug.org>>> wrote:
>      >
>      >
>      >                 For something like that you need a real electrician,
>      >                 however I'm not
>      >                 sure how many if any have the thermal imager like
>     we've
>      >                 seen on TV.
>      >
>      >
>      >             Most of my day job involves writing software that
>     talks to
>      >             them, but the
>      >             hardware we talked to is danged expensive. That said,
>     we've
>      >             written software
>      >             specifically for folks who do property analysis using
>      >             thermal cameras.
>      >             (Windows-only, sorry; Driver support issue.) If anyone's
>      >             interested in
>      >             starting such a business in the area...
>      >
>      >             -
>      >
>      >
>      >         For people who want to sell you
>      >         information about how to better
>      >         insulate your abode?  Maybe
>      >         starting with triple pane windows?
>      >         Is that a hot (...) business in cash
>      >         strapped MI?
>      >             -- Bob
>      >
>      >
>      >     To a point, yeah, it's about replacing poor windows and adding
>      >     insulation. The nice thing a thermal camera can do for you is
>     help
>      >     you figure out which windows, doors, walls and areas of the
>     roof you
>      >     ought to shore up, and which you shouldn't bother with.
>      >
>      >     (Now, if I may deflect the subject into a personal rant)
>      >
>      >     What irritates me greatly is that the SDKs for talking to the
>     main
>      >     types of cameras we work with is only practically available for
>      >     Windows.  In one case, the manufacturer only provides an OCX
>     file.
>      >     In the other case, the manufacturer opted for a 3rd-party API
>     called
>      >     GigEVision, but the number of implementations of that API is
>      >     exceedingly small, and the group of companies controlling the
>     spec
>      >     manage it more tightly than the MPEG group; I'm not sure how one
>      >     could legally build a FL/OSS implementation.  There's one
>      >     non-Windows implementation, but you pay through the nose for
>     it, and
>      >     say Hello to system library version requirements.
>      >
>      >   It's still the case that many - most? -
>      > companies will only talk to M$ about
>      > their hardware.  Canon is notorious
>      > that way.  All an aid to keeping M$'s
>      > de facto monopoly intact.
>
>     Erm...Believe me, it's not in the their interest to keep a Microsoft "de
>     facto" monopoly intact. Most implementations for talking to GigEVision
>     devices are pure-hardware, now, without a trip through userland
>     software. I'd have to look into it again, but I believe most of the
>     companies in the group behind the API are also in the industry of
>     selling pure-hardware solutions.
>
>     Tell me where that helps Microsoft.
>
> That much doesn't.  But many companies
> don't want the expense and bother of
> supporting several platforms.  So they
> withhold information from anyone but M$,
> and that helps keep M$'s monopoly in
> place.

That's not how driver development on Windows works.  Microsoft isn't 
responsible for the development of others' drivers.  They'll write 
generic drivers to available standards, but they won't write a driver 
for some other company's hardware. (Well, I suppose if that other 
company offered to pay enough, they might.)

Driver development on Windows involves purchasing and downloading the 
DDK, and doing your own coding.  When you're ready, you pay Microsoft 
for WHQL certification; That's a quality control process where they 
hammer your driver through a testing process.  You don't *have* to get 
WHQL certification; Your driver will still load on most systems without 
the certification, but the user will see a warning saying that 
"such-and-such driver hasn't been WHQL-certified, and may cause your 
system to be unstable."  Most users will click through that. Some won't.

It's not Microsoft's choice whether companies develop products that work 
with non-Microsoft operating systems. There's only one major reason for 
it that I've seen...Visual Studio is a darned-good C/C++ IDE, better 
than anything else I've worked with extensively.

The closest thing to a contractual limitation I've seen is that one of 
the optional add-on packs for MFC has licensing clauses in it that are 
supposed to make you think twice about running your app under winelib. 
However, if you're using MFC as part of your drivers, you've got other 
problems, and they have more to do with competency...


You're right; Most hardware manufacturers don't want to bother with the 
expense of supporting multiple platforms, but they withhold the details 
needed to implement support from *everybody*, and do their own 
implementation. If Microsoft was no longer the majority target, and, 
say, Ubuntu was, then they'd do that single implementation for Ubuntu, 
and let Microsoft users twist in the wind.

The crux of the issue, though, is that a lot of the magic that makes or 
breaks a quality "hardware" device actually happens in software; it's 
just cheaper to patch and fix software than hardware. Users who buy a 
fast video card or quality-output printer are really paying for a device 
that the fancy, well-written drivers will talk to.  Things like color 
conversion and quality halftoning in printing, or shader path and data 
transfer optimizations in video cards, are largely handled in the 
drivers for consumer-grade hardware. Want a printer that does it in 
hardware? That's what Postscript is for. Video cards are still a bit tricky.

It's the behind-the-scenes in-software magic that the hardware 
manufacturers don't really want to open up; If they lose that, they lose 
the edge they have over their competitors.