Re: For the Windoze haters - VS2005

On Thu, 9 Feb 2006 08:41:58 -0800, "Joel Kolstad"
<JKolstad71HatesSpam@xxxxxxxxx> wrote:

"The Real Andy" <will_get_back_to_you_on_This@> wrote in message
news:dmtlu1hre24ke7qb27847dfg47cu3qtpau@xxxxxxxxxx
[The NT hardware abstraction layer]
I thought this was a good thing until today. I had to find a bug that
had been plaguing this business for ten years or so, back to the old
NT4 sp1 days. They had designed a PCI card and written a driver. This
is the single worst interface I have ever seen in my life. Sure MS
provides a defined interface to hardware, but these guys had
completely fucked it up. After seeing this, i wonder whether the whole
hardware abstraction thing works. My guess is it works fine for video
cards and the like, but custom/small time work is a different story.

It works fine for most all drivers if the programmers actually follow the
spec! In my experience, the biggest violations of the HAL "model" that still
results in -- mostly -- working drivers are: (1) no use of synchronization
objects (mutexes, etc.) when there should be... this will often work on
uniprocessor machines (even big companies that certainly have the resources to

Genuine multithreading is a big issue these days which very few
understand. I think MS has made a huge mistake by making this easily
avalaible to the standard 'i read a book now i can program' type
programmer. I despise powerbuilder, but by making multithreading hard
to access is probably the single best thing that product offers.

I read a paper a few months ago that said if you dont know why not to
use concurrency, then you should never use it.

"get it right" such as Creative Labs have released drivers that crapped out on
multiprocessor computers); indeed, there are a_great_ many programming errors
you can "get away with" on uniprocessor machines!, and (2) no use of the

I would laugh, but sadly i have been bitten by this very same
multiproc bug!!! In saying that, i have learned a great deal about
concurrency since then.

functions that translates "logical" addresses to "physical" addresses on,
e.g., a PCI bus... this works because, on x86 machines, they're often
identical values for the sake of efficiency. But this breaks drivers when
they're re-compiled for architectures (PowerPC, ARM... hmm... what does MS
even still support these days?) where that isn't true.

I have never really had the opportunity to write true cross platform
code. All my customers/employers have dictated what platform they wish
to use. In an embedded world, i think there is very little call for
cross platform. In a generic, consumer world it is a different story.
I have never mass prodeuced for a consumer market.


.

Quantcast