Chris said:
Excuse me? Microsoft has done a great job of ensuring that it's
possible for third parties to write CLR compliant execution engines
and compilers by publishing the specifications used in the framework.
Did I deny that? All I am saying is that Microsoft are *not* doing it
themselves. There has to be a reason for that.
But tell me why do you think Microsoft put information about the *exact*
version of the framework libraries in the manifest of an assembly. Then tell
me why the assembly fails to load when another version of the .NET framework
tries to load that assembly. Explain to me how this fits in with the idea of
..NET being used across platforms?
It's true that MS's Win Forms are the most platform specific parts of
the framework, and that it's unlikely that those would be fully
supported or even included in other versions of the framework, but
command-line tools, no matter how complex they are, could conceivably
(and do in fact) run on alternate versions of the framework happily.
NAnt, for example, runs on Mono and MS's framework, to my knowledge.
So what? Do this: take a process assembly build on mono and try to run in
under the Microsoft runtime (or vice versa).
Besides this, providing a method to access audio devices in the
framework would have more benefits than cross-platform capability. It
I agree with that, and another poster mentioned the facilities in DirectX to
do this (which has a managed interface).
would mean full object-orientation, as opposed to importing native
function calls. It would mean consistency. It would mean more ease of
I agree with that too, but unfortunately whole swathes of the framework
library are mere wrappers around Win32 and your comments about object
orientation have been ignored (OOP is more than just adding static methods
to a class said:
use. It would mean strongly typed exceptions. Let's not forget that
the _main_ benefits of the .NET runtime environment.
Security. Security is the *main* benefit of the framework. Anything else is
mere icing on the cake.
Well, it's already happened. Microsoft realizes that standards-based
systems garner more support from the develper community at large (as
well as the business community) than completely proprietary systems
that lock users and developers in to the same technology. While what
you say is true for many or most of MS's technology (WMA, VBS,
Office), and while Microsoft dominates .NET technology, and will do
so for a good deal of time, I think MS picks its fights carefully. It
realizes that it needs the support from developers that results from
a programming environment that isn't completely proprietary.
And again I agree, in part. Indeed, the Visual C++ team learned this many
years ago and so now Visual C++ is the most compliant compiler you're able
to buy (assuming you don't have a silly-money budget).
But let's take a closer look at standards. Web Services are a standard, but
when you look closer you'll see that SOAP was a standard driven by Microsoft
(at the time only one of the original architects, Don Box, didn't work for
Microsoft - but now Don works for Microsoft). Its great for companies to
agree on standards, but its interesting to see what becomes a 'standard'
because the biggest company says it should be <g>.
Microsoft has been bitten by being perceived as providing proprietry code. I
say 'perceived' because I don't think that it matters that Microsoft
produces proprietry code; the majority of machines are Windows machines
anyway, so whatever runs on Windows is by default a 'standard'. IMO
Microsoft also take this point of view and thus produces 'standards' out of
their proprietry code. Look at C# and the CLI, they've become standards, but
explain to me how much of the specs were changed by the standards committee?
(Were they rubber-stamping committees, existing merely to stamp their
approval?) IMO the only difference between VB6 and C# in this respect is
that Microsoft provide a reference implementation of C# in the SSCLI (which
is great), and yet VB6 was very much a 'standard' before .NET appeared, it
just didn't have the rubber stamp of a standards committee.
I prefer to take the cynics approach.
Richard
