Re: vb6 -v- Net!

This, perhaps more than any other post, has given me a real insight into how
M$oft messed up so badly!

"Robert Conley" <robertsconley@xxxxxxxxx> wrote in message
news:1174567610.401581.290690@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 21, 7:56 pm, "Jim Carlock" <anonymous@localhost> wrote:

First some background.

A good deal of Visual Basic 4 to 6 is a thin wrapper around COM. One
point of Microsoft doing Visual Basic 4 to 6 was to be a simpler
gateway into the world of COM. The strengths and limitation of COM was
much of the strengths and limitations of VB 4 to 6.

Some of the point of COM was to both create additional markets for
programming tools and to enable Microsoft to have a standardized way
of releasing additional APIs particularly for database management.
Database access and management was probably the most common pre-
internet task that programmers dealt with.

Perhaps the main point of COM was the recognition that having
different parts of the program in a separate binary (DLL, COM DLL,
etc) instead of a single EXE helped programmers deal with complexity.
Note that this did not originated with Microsoft and COM but part of a
general trend of the time. Today it no longer revolutionary just one
of the many techniques that programmers have in their toolkit.

<g> Is that statement about it being like Java true? I mean Java is
decompilable, so bingo there, but Java used to come with the OS
until some of the later Microsoft OS

COM wasn't perfect and the big oops in its design was the central
registry concept. Originally Microsoft felt that space would continue
to be a premium along with multiple copies of DLLs with the same name
causing problems. Well the assumptions proved wrong and the
limitation of the central registry concept meant that COM had its own
DLL Hell.

Along come Java, which embodies another design for sharing and reusing
components of software. However due to how Java was created and
evolved there was many quirks in Java design (lack of properties,
specific idioms in how it dealt with object oriented programming. Plus
the capper was that Microsoft couldn't embrace and extend Java because
of Sun control over the language.

Anders Hejlsberg had a successful career working with Turbo Pascal,
Delphi and other Borland complier projects. He had a lot of respect
for create Delphi. Microsoft eventual hired him to work on J++
(Microsoft's version of Java) and the class library for J++, Windows
Foundation Class.

When the bottom fell out of working with Java for Microsoft. They
decided to create a new language that "fixed" Java's issues along with
a new class library.Along with that they were going to make a new
technology to replace COM. The two combined into what now is known
as .NET. Note that there is a compatibility mechanism in .NET to use
and be exposed to COM.

But Visual Basic was still welded to COM. (Other can tell this story
better than I). Due to Bill Gate and a dozen other reason Microsoft
wasn't about to abandon Basic as one of their supported language. But
of all the choices to make in updating Visual Basic they probably made
the worse possible one.

To fix this problem with VB 6, they handed the language to a sub team
of the whole .NET project. A team that really had no idea of the
history of Basic or the community behind it. Plus likely because it
competed with other sub project of the whole .NET development it had
limited resources to achieve its goal.

They basically started by creating a BASIC syntax for C#. There is
nearly a one for one correspondence between first version of VB.NET
and C#. Most VB function that could represented in a class library
they put in the Microsoft.VisualBasic hierarchy. And....

Well that was about it. Of course this throughly and utterly broke
backwards compatibility. And we lost important IDE features like edit
and continue (now since restored). And to cap it all off the entire
technology was new so we had to climb the learning curve on everything
from performance to installation scripts.

Of course the C++ guys didn't have to deal with this crap because they
made a mechanism for them to keep using the same old stuff while
allowing them to sprinkle in .NET stuff when they felt like it.

The excuse was "But it is runtime fault. To get its benefits you need
to make some sacrifices". Year later when alternative .NET compliers
came out, along with the second version of C++ .NET proved how much
bull*** that was. There are quirks (not limitations) that you have to
deal with in the .NET runtime. The heart of the process is your
complier. A theoretical .NET complier (or interpreter) is not more
limited in what it can do then on going to straight assembly code. The
difference is the IL is going to be run in the sandbox of the runtime
instead of directly on the CPU.

The lack of backwards compatibility and coupled with the fact that
VB.NET had some long requested improvement pissed off the majority of
VB programmers. And had the effect of destroying largest programming
customer base ever. Of course the Visual Basic Market was dwarfed by
Windows/Office so I guess it hasn't hurt Microsoft <sarcasm intended>


. I've not followed how .Net
works on other processors, so perhaps someone might be able to
enlighten me there.

.NET compliers make IL binaries. (Intermediate Langauge like assembly
or Java's byte codes) The IL binaries runs on the .NET runtime. To run
on a different system you need two things.

1) A runtime that can process IL binaries for that system
2) A framework that looks like the .NET Framework but is translating
to native calls instead of Win32 calls.

The Mono project does this for Win32 and Linux.

Rob Conley



.