Re: VB.NET 2008 not backward compatable?

If you want to see the code, then just say so. I still have it, well at
leat
I'm 95% sure I do :)


It doesn't matter to me. That code was for a
DotNetter. It was a question posted here. I posted
a link to VB code, and said I wasn't sure whether .Net
could do it. You then "took up the gauntlet" that you
imagined I'd thrown down and posted a VBScript example.
But the OP never got .Net code.

Personally I'm not against .Net any more than I'm
against Java. I just find it uninteresting and irrelevant
for my purposes. I don't feel any inclination to have
a competition between VB and VB.Net because I see
them as different tools for different things.

But the VBers are not free to just be disinterested.
There's pressure from MS to go along. And the people
who've hitched their wagon to MS reinforce that. There
are also a surprising number of people who just seem to
worship MS and will speak up for any MS party line.
Thus we have to deal with a steady stream of DotNetters,
including you, who deliberately go to the VB group only
to sell .Net -- out of their own devotion and/or insecurity.

Microsoft wants to herd Windows programmers away
from native code to sandboxed "cloud" applets. Is it
to compete with Java? Is it because they've milked their
sham software updates as much as they can and now
want to jump on the software rental bandwagon? It
seems to be both of those reasons and more. It appears
to me that, at root, the people at the top in MS really
don't know for sure what they're planning. They're just
trying to follow their basic business plan that always worked
in the past: "Aim the corporate vacuum cleaner at the
biggest pile of moola and suck." :)
Unfortunately for people who want to write compiled
"fat client" software to run on Windows, Microsoft has
decided to deliberately thwart that, because it could
interfere with Microsoft's attempt to milk the cloud fad.

The latest news is that Win7 Pro. will come with a
free option to have WinXP in a VM. So if you want to
spend $300 for their new software, and hundreds more
for newer hardware, you'll be able to run the 2001 version
of Windows that you already paid for, and which is clearly
the version that most businesses *want* to run. :)
As the saying goes, you couldn't make this stuff up. :)

The corporate ship of MS has lost their rudder altogether.
They don't have an income model apart from milking the
Windows/Office monopoly. And the cloud fad has actually
been a bad idea in the background ever since 1999 and the
failure of "thin clients". The cloud is an idea to increase
profits. It's never been an idea for better software. So it's
hardly a surprise that Microsoft's most devoted groupies are
"overcompensating" in their dedication to the Microsoft
product: Microsoft's former and future plans are both falling
apart.
I just wish they groupies would stick to this group to play
out their pep rallies, and leave the VBers in peace.

We all know, of course, that .Net is not suitable
for writing shell extensions, but it may be possible for
.Net to at least access the ShellFolderView of folders. :)

Hmmmm... The explanation I see for it implies that VB6
would be out as well -
for largely the same reason, one runtime instance per process.


I don't follow that logic. At this moment I have an Explorer
Bar showing in an open folder, a program open, and an ActiveX
EXE running from a script to resolve the IP addresses of my server
logs -- all written in VB6. There's no problem. I don't see why
I couldn't have a second bar, band, or other shell extension
running. And in fact I've had both the Explorer Bar and a Property
*** Handler, both VB6, running. I also have no problem opening
a FileOpen dialogue as mentioned here:
http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx

The reason not to do Shell extensions in .Net, as
I understand it, is because of the problem noted in that
link, and also because there could be a "race to be first" --
if two shell extensions are written on different .Net
runtimes then only one can load. The VB6 runtime, as you
know, is just a DLL, not a "framework". But either way, it's
not an issue of loading multiple runtimes. It's an issue of
loading multiple versions.


.