Re: Microsoft and Trust Take 2



In VB it was expected that people would pretty much
stick to VB-digestible COM objects and stay away from
the API. In .Net it seems that breaking COM was a
way to discourage involvement with the Windows system
altogether and direct people toward sandboxed applets.

I don't think that's true because they've opened up support to a much
wider
range of options. You can now call a much lower level of com object. In VB
it wasn't possible to call directShow natively and it was difficult with a
typelib. In dot net it can call all of its interfaces directly. You need
to
use the interop namespace but that's just the name they chose, they could
have called it ComSupport or something and then it wouldn't be considered
interop.


They could have named it anything, but it still seems to
be an extra layer that was put there deliberately to
"deprecate" COM in .Net, just as they "deprecated" API
access in both VB and .Net. (Not that the horse didn't
get out of the barn in both cases, but it wasn't through MS's
encouragement.)

The gist of that seems to be a description of Microsoft's
long time threat/dream - to block actual 3rd-party programming
altogether, sending everything through a filter layer. (As though
there weren't enough layers already.)

It's not really that big a deal. They're still using the same old model of
having functions for you to call, they're just doing it through a
different
mechanism. To have everything available through a dot net interface would
be
pretty cool.

I understood the article to say that there would be an entirely
new API, which *might* be addressable directly via .Net code.
That means MS has an opportunity to enforce the "safe" code
idea, because only they - and close partners - would have
access to the underlying API. I don't think there's any
question that that's where they want to get to. 3rd-party
programmers have become awkward hangers-on at the
web services and entertainment-rental party.

When you think about it, though, the article is confusing.
It describes .Net as both legacy *and* possibly current in the
new scenario. Either your .Net code is writing to the wrapper
on top of the new API, or it's writing to the legacy wrapper
that's a wrapper on top of the new API. I don't see how it
can be both... It's enough to make one dizzy. :)


and
which is already partway to the services model (with MS
being the only true admin. on a Vista system). Then the
next thing is probably a closed services box. Looking at
it that way, the last thing I'm worried about is whether
VB will run on future Windows. It can do almost anything on
95-XP with no dependencies. That makes a lot of sense
to me.

After what you said (with regards to the next Windows) I'd be more nervous
than ever using VB6. You might be happy to run XP for ever but what about
your users?

Who said anything about running Xtra Problems? :)
It will probably come to that, but for now I prefer my
"'Ol Betsy" - the streamlined, spyware-free Win98,
which is also free of insecure, unnecessary network
services that can't be shut off.

Actually, though, XP hasn't really been so bad in terms
of writing software for others to use. Almost everyone
is running as Admin. And even though MS has tried to
set themselves up as an online shepherd with the new
"security" functions in IE post-SP2, (so that people get
dire security warnings and/or malfunctionality when trying
to download software installers) in my experience the vast
majority of people don't seem to notice Microsoft's attempts
very much. When most people see a security warning they
don't even read it. They just see another example of how
difficult and complex computers are, and their only focus
is on how to get past this latest confusing obstacle.

But what I meant in what I was saying was that I don't
consider what's coming - or rather what seems to be coming -
to be usable at all. MS is branching into advertising and web
services. They don't have much room left to focus on OSs
per se. And they've developed conflicting motives. They can't
make good OSs and good advertising venues at the same time.

I already consider Vista unusable and XP barely salvageable,
in terms of having an OS that I can use and control as I wish.
I don't know where things are going in the future. Maybe some
bright sky will appear from behind the gathering clouds of
pending corporate usurpation of the public Internet.

(A good example of those clouds was posted at the Washington
Post this week:
http://www.washingtonpost.com/wp-dyn/content/article/2008/04/03/AR2008040304
052.html
)

But the way I see it, .Net doesn't make any sense for
basic Windows software, and we wouldn't be talking
about this here at all if MS were not using .Net as part of
their strategy to recast the product as services and advertising.

To put that another way: Not only does MS want to switch
from the auto business to the taxi business. They also want
to force-drag their entire customer base along. I like to
write software for my "car", and I find it satisfying to write
software that might be useful to other people who drive
cars. But those people who are going to accept being pushed
into a taxi are on their own. I'm not going to write trinkets
like MyTaxiRidePlayListOrganizer for people who don't know any
better than to be passive cows in Microsoft's herd of
"consumers". (The word Bill Gates consistently likes to use
in referring to human beings. I find the word "consumer" to
be actually quite evocative of a cow. They're both viewed as
commodities that one can exploit for profit based on how much
they "eat".)

That's one of two big issues that seem to be very
difficult to clarify in these .Net debates. The one issue
is that .Net is a step toward programmers losing access
to the plaform - where Windows actually ceases to be
a platform at all, but rather becomes an appliance with
an SDK. The second big issue is the confusion that MS
so effectively created around the purpose of .Net (which
is actually related to the first issue). That's the confusion
about using .Net for Windows software. It befuddles me
that so many seemingly intelligent people could even begin
to take seriously Microsoft's notion of writing Windows
software with their bloated, heavily dependent, Java clone.
(I don't even have a JVM installed. I certainly don't need
a .Net framework installed.)

But I suspect the real issue is not that people like you
have been duped, but that you're in one of those areas
(like intranet applet writing or server-side components)
where .Net *can* make sense. For instance, Tom Shelton
happened to make a comment recently about how he has
control over the machines where his software runs. Maybe
..Net is handy in that scenario. Certainly the gigantic runtime
dependency wouldn't be an issue. But for those of us
writing software that's intended for use on any Windows
PC, there's nothing to talk about. .Net doesn't make sense
in a handful of ways, any more than Java does. (In fact,
even less so, because the idea of being cross-platform
is more than just a marketing scam with Java.)

So as far as I can see, the only reason for people like you
to keep debating this topic is because you want to help
ensure that VB.Net doesn't get dropped. But whether you
agree with my assessment of things or not, the fact still
stands that I, and I think many of us here, view your arguments
as no more relevant than a salespitch from a Java supporter.




.

Relevant Pages

  • Re: newbe about API
    ... Emne: Re: newbe about API ... > I found all these API-CALL strings are finally compiled to ... more than that...and Windows simply takes this to an extreme that this ... DLL, when a weak point is found (which, with Microsoft, is something ...
    (alt.lang.asm)
  • Re: In the Shallow End
    ... When a document claims how an API is supposed to be used and then gives the user examples that actually work, ... Vague in your instance means you have no context to VMS or UNIX of that era. ... Windows offers lots of this stuff. ... That's why Apple had to dump a whole paradigm to plunge ahead and take the lead. ...
    (comp.sys.mac.advocacy)
  • Re: What is the counterpart of javaxmail api in linux?
    ... > javaxmail api from java on Windows to java on Linux. ...
    (comp.lang.java.developer)
  • Re: Shortcomings in Win32 API docs
    ... Once on that question MSFT guys answer that when windows issued there were ... questions which language to use for Win API. ... hardly means that C is the only language supported for writing Windows ...
    (microsoft.public.win32.programmer.kernel)
  • Re: a pre-beginners question: what is the pros and cons of .net, compared to ++
    ... as the windows forms architecture wraps a number of activex ... and retains backwards compatibility with both COM and the classic Win32 api. ... C++ cannot inherently do video capture either, since you have to import COM. ... Outlook or Word or IM programs, each of which would run in managed code ...
    (microsoft.public.dotnet.general)