if you require that information, OR the documentation is not up to
par OR the API is not up to par.
The documentation is good enough for most cases but there are many times
when it isn't. This was especially true in the early days of .net - it's
gotten a lot better.
I fail to see that. I mean: does it help you if you understand how
Win32's messaging works? It's an asynchronous architecture. .NET is not
(unless you use asynchronous routines). It's about concepts: what's a
thread, what's MTA, what's STA, how do threads communicate, what's the
difference between a thread and a process in windows terms (because on
Unix it's different). What's thread local storage etc. etc. If you
understand these concepts, you can pick up the .NET documentation and
check for implementations of these concepts. After that, use the
implementations on .NET. I don't see why it is important to understand how
it works below the surface. Ok, it's nice to know from a geeky point of
view, but for the rest I don't think it's important.
Some of its pure geek curiousity, but often it makes a practical difference.
For one, there's a lot of win32-isms in the System.Forms classes. There is
some behavior that can only be explained by knowing that behind the scenes a
bit of functionality was implemented by posting a message to a hidden
window.
I think the reasoning behind your point is that in win32 you were
forced to understand the concepts first, because it is a big giant api and
no namespaces/classes which group the functionality (ok, dll's perhaps,
but you start with the platform SDK, 1 big api doc).
Agreed. But I don't think .NET is all that different. I regard .NET as an
operating system, and to write non-trivial, effective code you have to
understand a lot. Sure, you can write a .NET HelloWorld in a flash, but I
can do that just as fast in MFC. You can't get far before you hit a wall
that you can't get beyond until you understand lots of other concepts.
In .NET it is easy to
run into a Thread class, oh what can it do? Oh that's nice, let's try...
*poof*. However if people understand the concepts, I don't think you need
to understand what win32 does below the surface.
Threads are interesting. You can get a lot done without knowing much about
win32, but even here you cannot get far or do a lot without needing to
understand what lies below the surface. Here's one example....why are .net
mutexes visible across processes on the same machine but .net events are
not? Another is that a thread must be in a runnable state before certain
operations will take affect (a ThreadAbort wont actually be delivered until
the thread is running).
Another aspect of threading that is directly related to win32 is the entire
topic of exception handling. This is built directly on top of the SEH
mechanism of win32, and if you want to understand why things happen as they
do you must understand win32 SEH. From what I've read of the exception
portion of the ECMA spec, it was written around some win32 assumptions.
In the original ROTOR sources, because the exception handling was built on
top of a UNIX model the actual delivery of some exception semantics is
subtly different.
true, however the knowledge of these limitations is also learned
from using .NET: 'it can't do this'. Why it can't do this is not
important, because you can't change it anyway
Hmmm. I agree in part. Quite often what I've found is that a rule is stated
as "Always do this" or "Never do that" but given sufficient understanding of
where those rules come from they should really be stated as "Almost always
do this" or "Almost never do that". It is knowing when it is allowable to
deviate, or when your circumstances are sufficiently different that you can
"do that" that makes all the difference. This can only come from a deep
understanding of the platform.
For one area I agree with you: COM+ / ServicedComponent.
I have the happy pleasure of never working with those
So I've skipped
over many of the COM problems (apartment models are just nuts).
