<br><br><div class="gmail_quote">On Wed, Jan 27, 2010 at 12:32 PM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 1/27/2010 12:06 PM, Bob Kline wrote:<br>
><br>
><br>
> On Wed, Jan 27, 2010 at 11:50 AM, Michael Mol <<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>>> wrote:<br>
><br>
> On 1/27/2010 11:34 AM, Bob Kline wrote:<br>
> ><br>
> ><br>
> > On Wed, Jan 27, 2010 at 10:59 AM, <<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a><br>
> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>><br>
</div><div class="im">> > <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>>>> wrote:<br>
> ><br>
> > On Wed, Jan 27, 2010 at 10:45 AM, Bob Kline<br>
> <<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a> <mailto:<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>><br>
</div><div class="im">> > <mailto:<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a> <mailto:<a href="mailto:bob.kline@gmail.com">bob.kline@gmail.com</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Wed, Jan 27, 2010 at 10:36 AM, <<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a><br>
> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>><br>
</div><div class="im">> > <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a> <mailto:<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>>>> wrote:<br>
> ><br>
> ><br>
> > On Wed, Jan 27, 2010 at 9:30 AM, Casey DuBois<br>
</div>> > <<a href="mailto:casey@grlug.org">casey@grlug.org</a> <mailto:<a href="mailto:casey@grlug.org">casey@grlug.org</a>> <mailto:<a href="mailto:casey@grlug.org">casey@grlug.org</a><br>
<div><div></div><div class="h5">> <mailto:<a href="mailto:casey@grlug.org">casey@grlug.org</a>>>> wrote:<br>
> ><br>
> ><br>
> > For something like that you need a real electrician,<br>
> > however I'm not<br>
> > sure how many if any have the thermal imager like<br>
> we've<br>
> > seen on TV.<br>
> ><br>
> ><br>
> > Most of my day job involves writing software that<br>
> talks to<br>
> > them, but the<br>
> > hardware we talked to is danged expensive. That said,<br>
> we've<br>
> > written software<br>
> > specifically for folks who do property analysis using<br>
> > thermal cameras.<br>
> > (Windows-only, sorry; Driver support issue.) If anyone's<br>
> > interested in<br>
> > starting such a business in the area...<br>
> ><br>
> > -<br>
> ><br>
> ><br>
> > For people who want to sell you<br>
> > information about how to better<br>
> > insulate your abode? Maybe<br>
> > starting with triple pane windows?<br>
> > Is that a hot (...) business in cash<br>
> > strapped MI?<br>
> > -- Bob<br>
> ><br>
> ><br>
> > To a point, yeah, it's about replacing poor windows and adding<br>
> > insulation. The nice thing a thermal camera can do for you is<br>
> help<br>
> > you figure out which windows, doors, walls and areas of the<br>
> roof you<br>
> > ought to shore up, and which you shouldn't bother with.<br>
> ><br>
> > (Now, if I may deflect the subject into a personal rant)<br>
> ><br>
> > What irritates me greatly is that the SDKs for talking to the<br>
> main<br>
> > types of cameras we work with is only practically available for<br>
> > Windows. In one case, the manufacturer only provides an OCX<br>
> file.<br>
> > In the other case, the manufacturer opted for a 3rd-party API<br>
> called<br>
> > GigEVision, but the number of implementations of that API is<br>
> > exceedingly small, and the group of companies controlling the<br>
> spec<br>
> > manage it more tightly than the MPEG group; I'm not sure how one<br>
> > could legally build a FL/OSS implementation. There's one<br>
> > non-Windows implementation, but you pay through the nose for<br>
> it, and<br>
> > say Hello to system library version requirements.<br>
> ><br>
> > It's still the case that many - most? -<br>
> > companies will only talk to M$ about<br>
> > their hardware. Canon is notorious<br>
> > that way. All an aid to keeping M$'s<br>
> > de facto monopoly intact.<br>
><br>
> Erm...Believe me, it's not in the their interest to keep a Microsoft "de<br>
> facto" monopoly intact. Most implementations for talking to GigEVision<br>
> devices are pure-hardware, now, without a trip through userland<br>
> software. I'd have to look into it again, but I believe most of the<br>
> companies in the group behind the API are also in the industry of<br>
> selling pure-hardware solutions.<br>
><br>
> Tell me where that helps Microsoft.<br>
><br>
> That much doesn't. But many companies<br>
> don't want the expense and bother of<br>
> supporting several platforms. So they<br>
> withhold information from anyone but M$,<br>
> and that helps keep M$'s monopoly in<br>
> place.<br>
<br>
</div></div>That's not how driver development on Windows works. Microsoft isn't<br>
responsible for the development of others' drivers. They'll write<br>
generic drivers to available standards, but they won't write a driver<br>
for some other company's hardware. (Well, I suppose if that other<br>
company offered to pay enough, they might.)<br>
<br>
Driver development on Windows involves purchasing and downloading the<br>
DDK, and doing your own coding. When you're ready, you pay Microsoft<br>
for WHQL certification; That's a quality control process where they<br>
hammer your driver through a testing process. You don't *have* to get<br>
WHQL certification; Your driver will still load on most systems without<br>
the certification, but the user will see a warning saying that<br>
"such-and-such driver hasn't been WHQL-certified, and may cause your<br>
system to be unstable." Most users will click through that. Some won't.<br>
<br>
It's not Microsoft's choice whether companies develop products that work<br>
with non-Microsoft operating systems. There's only one major reason for<br>
it that I've seen...Visual Studio is a darned-good C/C++ IDE, better<br>
than anything else I've worked with extensively.<br>
<br>
The closest thing to a contractual limitation I've seen is that one of<br>
the optional add-on packs for MFC has licensing clauses in it that are<br>
supposed to make you think twice about running your app under winelib.<br>
However, if you're using MFC as part of your drivers, you've got other<br>
problems, and they have more to do with competency...<br>
<br>
<br>
You're right; Most hardware manufacturers don't want to bother with the<br>
expense of supporting multiple platforms, but they withhold the details<br>
needed to implement support from *everybody*, and do their own<br>
implementation. If Microsoft was no longer the majority target, and,<br>
say, Ubuntu was, then they'd do that single implementation for Ubuntu,<br>
and let Microsoft users twist in the wind.<br>
<br>
The crux of the issue, though, is that a lot of the magic that makes or<br>
breaks a quality "hardware" device actually happens in software; it's<br>
just cheaper to patch and fix software than hardware. Users who buy a<br>
fast video card or quality-output printer are really paying for a device<br>
that the fancy, well-written drivers will talk to. Things like color<br>
conversion and quality halftoning in printing, or shader path and data<br>
transfer optimizations in video cards, are largely handled in the<br>
drivers for consumer-grade hardware. Want a printer that does it in<br>
hardware? That's what Postscript is for. Video cards are still a bit tricky.<br>
<br>
It's the behind-the-scenes in-software magic that the hardware<br>
manufacturers don't really want to open up; If they lose that, they lose<br>
the edge they have over their competitors.<br>
<div><div></div><div class="h5"> </div></div></blockquote><div>I'll take that at face value, but it</div><div>certainly suggests to me that if </div><div>a vendor only supports windows</div><div>drivers then it is helping M$ stay</div>
<div>in the driver's seat.</div><div><br></div><div>I had the impression that M$ had</div><div>it's own in house driver software </div><div>people. How and when it writes a</div><div>driver I don't know - perhaps as </div>
<div>you suggest, for a fee.</div><div><br></div><div>But it brings up another issue. </div><div>If a company builds its products </div><div>using proprietary chips then it</div><div>can control the specs. Big companies</div>
<div>can do this. In general you'd think</div><div>the objective is to sell hardware.</div><div>So the more platforms that support</div><div>it, the better. It's possible that if</div><div>someone can figure out how your</div>
<div>hardware works, or what chips are</div><div>used, they will clone your gadget I </div><div>suppose. Years ago companies </div><div>went to the bother to black out the</div><div>parts ids so a potential repair person</div>
<div>didn't even know what chips to get.</div><div><br></div><div>I can only speculate that the</div><div>open versus proprietary wars are </div><div>not really over yet. There's a love-hate</div><div>relationship with standards. Many</div>
<div>companies would still like to have</div><div>proprietary approaches, with the </div><div>obvious goal of locking people in</div><div>to their products. Think FAX machines</div><div>before group 3 standards showed up.</div>
<div>You bought FAX machines in pairs, at</div><div>the least, and they cost $thousands.</div><div><br></div><div>So do you try to sell more hardware,</div><div>and allow OSes like Linux to play, or</div><div>do you stick with M$ and keep things</div>
<div>locked up? It strikes me the verdict</div><div>is not totally in on this.</div><div><br></div><div> -- Bob</div><div><br></div></div>