More on Visual J#.Net

[Gary Nelson]

max,

> I am having a hard time learning the .NET CL because the online help, MSDN
> is the best example of bloatware that I have ever come across.


MS has never been very good on documentation. I remember when they brought
out far strings with PDS 7.0, none of the samples on how to call assembler
worked. Not only did they not work, the whole philosophy was wrong. I took
me a couple of weeks to figure it out on my own.

Now I'm trying to get up to speed with XML and the documentation is
absolutely diabolical. Its as though they through bits and pieces of a giant
puzzle at you and you have to spend hours and hours trying to figure how
they all fit together.

Gary

[max caber]

Jason wrote,
"There are simply things that Microsoft needed to be able to do that traditional
VB and C++ programming could not touch."

What can .NET do, that could not be acomplished with ActiveX/COM components
written in C++ and callable from VB?
Max

[Joe \Nuke Me Xemu\ Foster]

"max caber" <maxcaber@yahoo.com> wrote in message <news:3bc87d7d$1@news.devx.com>...

> Jason wrote,
> "There are simply things that Microsoft needed to be able to do that traditional
> VB and C++ programming could not touch."
>
> What can .NET do, that could not be acomplished with ActiveX/COM components
> written in C++ and callable from VB?

Cut off Borland's air supply? If the timelines posted here are correct,
Delphi had finally acquired decent COM support when Microsoft decided on
a way to Cool them down.

--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Sean Scally]

Hey, and along those lines, what can ActiveX/COM components written in C++
and callable from VB do that could not be accomplished by several thousand
metric tons of Assembly??

Throw away that power screwdriver, boys!! I've got a penny!!

-Sean-

"max caber" <maxcaber@yahoo.com> wrote:
>What can .NET do, that could not be acomplished with ActiveX/COM components
>written in C++ and callable from VB?
>Max

[Jason]

>So how do you intend to convince the three million classic VB
>programmers to dump their religion overnight and become converted to
>another faith. For that's what it amounts to. You'd have more luck
>converting them to Pascal. Oh, wait a mo, that's what many are gonna
>be doing anyways!

It was already happening. VB6 is a good "hack" language, and believe me,
I am a "hard-core" VB programmer from way back. But when you try to do ANYTHING
with a statically-compiled language for server side code, you have to shut
down the web service to change the code! This is simply unacceptable. That
is why Java has made such huge inroads into server systems - it is dynamically
compiled, and a Java program (correctly written) can be upgraded in place
while the application is running. This is also possible with .NET.

I am not going to miss the VB3 menu editor, or the fact that I had to write
my own subclassing and hooking libraries, or the clumsy use of Longs as pointers,
or the treatment of arrays as "SafeArrays" or Variants, or the fact that
there is no straightforward way to tell if an array is initialized...

Okay, enough of that.

I think the reason you are enamored with VB6 is that you don't know how much
better the new stuff is going to be. The .NET runtime is just too different
from VB6 to do a good translation though. Well, I think that is true. VB6
has been long-in-the-tooth for some time now, and there are just too many
compromises in the language to even discuss.

What are the best things about VB6, the things that made it so successful
for so long?

Well, IMHO:

For the most part, no pointers - more stable code.
The GUI builder - comfortable and easy!
Lots of libraries for the users.

Now we are facing .NET. It has the same philosophy, no pointers, a great
GUI builder (looks like VB6 to me), and lots and lots and lots of libraries
for users. Only, this time it looks like they have gone many steps beyond
where VB is today, and even beyond the libraries available in Java (the GUI
libraries were always better, but the other libraries were badly needed).
They have also added garbage collection, which helps even more with preventing
memory leaks with little overhead.

Yeah, I think when VB programmers realize the advantages of the .NET platform,
they will be in a mad rush to learn the new stuff. VB6 is nice and all,
but there is a new God on the block. :-)

[Sean Scally]

I'm afraid that if you're trying to preach .NET to Mike, you're wasting your
time. He can't claim ignorance any more, as much as his opinions may prove
to the contrary. No, unfortunately, he knows all this and hates .NET anyways,
because nothing new is ever good.

-Sean-

"Jason" <jason@creative_nospam_corp.com> wrote:
>
>>So how do you intend to convince the three million classic VB
>>programmers to dump their religion overnight and become converted to
>>another faith. For that's what it amounts to. You'd have more luck
>>converting them to Pascal. Oh, wait a mo, that's what many are gonna
>>be doing anyways!
>
>It was already happening. VB6 is a good "hack" language, and believe me,
>I am a "hard-core" VB programmer from way back. But when you try to do
ANYTHING
>with a statically-compiled language for server side code, you have to shut
>down the web service to change the code! This is simply unacceptable.
That
>is why Java has made such huge inroads into server systems - it is dynamically
>compiled, and a Java program (correctly written) can be upgraded in place
>while the application is running. This is also possible with .NET.
>
>I am not going to miss the VB3 menu editor, or the fact that I had to write
>my own subclassing and hooking libraries, or the clumsy use of Longs as
pointers,
>or the treatment of arrays as "SafeArrays" or Variants, or the fact that
>there is no straightforward way to tell if an array is initialized...
>
>Okay, enough of that.
>
>I think the reason you are enamored with VB6 is that you don't know how
much
>better the new stuff is going to be. The .NET runtime is just too different
>from VB6 to do a good translation though. Well, I think that is true.
VB6
>has been long-in-the-tooth for some time now, and there are just too many
>compromises in the language to even discuss.
>
>What are the best things about VB6, the things that made it so successful
>for so long?
>
>Well, IMHO:
>
>For the most part, no pointers - more stable code.
>The GUI builder - comfortable and easy!
>Lots of libraries for the users.
>
>Now we are facing .NET. It has the same philosophy, no pointers, a great
>GUI builder (looks like VB6 to me), and lots and lots and lots of libraries
>for users. Only, this time it looks like they have gone many steps beyond
>where VB is today, and even beyond the libraries available in Java (the
GUI
>libraries were always better, but the other libraries were badly needed).
> They have also added garbage collection, which helps even more with preventing
>memory leaks with little overhead.
>
>Yeah, I think when VB programmers realize the advantages of the .NET platform,
>they will be in a mad rush to learn the new stuff. VB6 is nice and all,
>but there is a new God on the block. :-)

[Jason]

>Now I'm trying to get up to speed with XML and the documentation is
>absolutely diabolical. Its as though they through bits and pieces of a giant
>puzzle at you and you have to spend hours and hours trying to figure how
>they all fit together.

Don't blame Microsoft for this one! This is because of standards committees.
They wanted XML to be capable of replacing SGML, which is a whole lot more
complex and a lot slower to parse than XML. The result is a very complex
standard.

The good news is that for most things, you only need to use a small subset
of the complete standard. The SAX and DOM parsers take care of all the details
for you, so you don't have to write a parser from scratch.

The one thing that you will have to get a good grasp of is the concept of
"recursive-descendant" parsing. An XML document is a big tree, and you need
to understand some recursive programming in order to manipulate it.

Good luck!

[Jason]

>What can .NET do, that could not be acomplished with ActiveX/COM components
>written in C++ and callable from VB?
>Max

Well, what if you are calling a DLL from IIS, and you need to change the
behavior immediately because there is some bad bug, and you can't take down
the service which has a lock on the DLL...

.NET can do this. You can run two versions of the same assembly in the same
process space, and you can add new versions or entirely new assemblies without
shutting down the process. This is the TRUE meaning of a "zero-impact installation."

You can also have different versions of the same assembly running on the
same machine, where two different applications need the different versions.
COM makes this difficult because it relies on the registry. .NET makes
it really, really easy to do this.

These are things that you CANNOT do without a JIT-compiled language, and
they are absolutely essential to Microsoft unless they want to let Sun completely
dominate the web server and services marketspace.

Managed code is very important from the perspective of the web developer.
And heck, I have had more people complain over the last year that they had
to run an INSTALLATION program to upgrade their clients...that happens when
the guy is a SysAdmin and has to do this on 500 machines without SMS. If
I had .NET, I could EASILY make the program update itself from the web with
no intervention by anyone.

.NET is a BIG DEAL.

[Jason]

>Hey, and along those lines, what can ActiveX/COM components written in C++
>and callable from VB do that could not be accomplished by several thousand
>metric tons of Assembly??
>
>Throw away that power screwdriver, boys!! I've got a penny!!
>
>-Sean-
>
>"max caber" <maxcaber@yahoo.com> wrote:
>>What can .NET do, that could not be acomplished with ActiveX/COM components
>>written in C++ and callable from VB?
>>Max

No, really, Max's question was a valid one. VB6 is still a useful tool,
and will be for years down the road. I will be supporting a lot of VB6 code
I have written over the last couple of years, until customers are willing
to pay to have it rewritten (usually for business-logic reasons, not because
they want a new technology that does the same thing).

The thing is, the .NET platform can do a few things that SIMPLY CANNOT BE
DONE BY C++ OR VB. It's kind of like the difference between JScript and
C. In JScript, which is an interpreted language, you can create a string
that contains code and evaluate it directly. No muss, no fuss. In C, you
would have to write the code to a file, compile it, and then run it in a
new process, but your new process would not have access to all the variables
in the original process. If you have ever worked with TCL/TK, you have done
this sort of thing a lot!

Interpreted code can be a lot more expressive than a statically compiled
language is capable of being. The price you pay is that interpreted code
is 10 to 100 times slower than compiled code (depending on the language).

The idea of a JIT-compiler is revolutionary in this industry. It gives you
90% of the speed of a true optimizing compiler, but it also allows you to
bring in new code dynamically at run time like an interpreter. It may be
a little more involved in the current languages like VB.NET and C#, but it
does not have to be (.NET supports JITted JScript, after all!).

THICK CLIENT PROGRAMMERS, READ!

OKAY, think of this...

Remember VBA? You drop it into your application, and it lets programmers
use VB to customize a document. But it was kind of targeted to a certain
type of application, and you had to pay royalties...

So you use the Script control. That lets programmers use interpreted JScript
or VBScript to customize your app, but there is no design environment and
debugging is abysmal...

Now consider .NET. You allow your application to dynamically load .NET assemblies.
They can get into your application through a set of public interfaces that
you have defined explicitly for this purpose. You can also prevent them
from running "unsafe" code, so you know they won't be able to cause any GPFs.

Think of the advantages! Your program was written for .NET in C#, maybe.
Your users can use VS7 to create a customized assembly for your application,
so they can add whatever macros and wizards they want to. They might use
VB.NET or Cobol#, it does not matter to you. They can even use C#, the same
language you used to create the application, to write macros for the application!


Are you excited yet? VBA is a thing of the past! The Microsoft Script control
is a thing of the past! And all the macros are JIT-compiled, so they run
at the full speed of a compiled language!

Just by writing your application for .NET and providing the right hooks,
you can let users customize the application in any language .NET supports!
Now if that does not excite you, I really don't know what else I can say.
:-)

[Rob Teixeira]

"Jason" <jason@creative_nospam_corp.com> wrote:
>
>Are you excited yet? VBA is a thing of the past! The Microsoft Script
control
>is a thing of the past! And all the macros are JIT-compiled, so they run
>at the full speed of a compiled language!
>
>Just by writing your application for .NET and providing the right hooks,
>you can let users customize the application in any language .NET supports!
> Now if that does not excite you, I really don't know what else I can say.
> :-)
>

Actually, VBA is alive and kicking. You can download the beta for VSA.NET
(visual studio for applications - slight name change).
However, you are right that the script control is no longer necessary. The
code dom and generators are built into the framework bundle you get with
VS.NET. There are some nice samples in MSDN on how to hook into it.
Of course, VSA does have it's advanatages - like a really nice GUI and debugger.
The other nice thing is that you don't have to "provide the right hooks".
VSA will be able to utilize any CLR-compliant .NET class.

And lastly, yeah, it is exciting. Specially since you can also provide a
way for users to customize code running on a web application, in much the
same way they could write macros for Word or Excel - in addition to all the
great new features available to "macros", since they are now for all the
most part, not different from the actual development language product.

-Rob

[max caber]

"Jason" <jason@creative_nospam_corp.com> wrote:

"Well, what if you are calling a DLL from IIS, and you need to change the
behavior immediately because there is some bad bug, and you can't take down
the service which has a lock on the DLL..."

I am quite aware of this quirk with IIS and COM, and love Servlets/JSP for
that reason. But correct me if I am wrong, I think I remember getting around
that problem by running my .dlls in MTS.

However, since I have experienced the XML serialization with .NET and Chanels/Formatters
used for remoting, I am really starting to like .NET. Now if someone would
just develop a tree like object browser to document that big API, I would
really be sold.
Max

[Phil Weber]

> Now if someone would just develop a tree like object browser
> to document that big API, I would really be sold.

Max: Check this out:

http://www.gotdotnet.com/team/windowsforms/
WindowsFormsCodingHero3_11_01.aspx

(URL must be pasted into browser as single line.)
---
Phil Weber

[Gunnar Syren]

Hopefully the majority of them understands that it's not a religion, it's a
tool. And when a new tool comes out they'll look at it, actually try it, and
perhaps determine that it's a better tool and that it will help them do a
better job in the long run. Some will determine it's not, and will either
keep using their old tool as long as it's working, or move to another tool.
But a few will just plain whine and say "I won't try it because I don't like
it"...

/Gunnar

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3bc754a5.448161@news.devx.com...
> On 11 Oct 2001 15:46:35 -0700, "Jason"
> <jason@creative_nospam_corp.com> wrote:
>
> >There are simply things that Microsoft needed to be able to do that
traditional
> >VB and C++ programming could not touch. That is why .NET is here, that
is
> >why Microsoft bet the company on it, and that is why it will still be
here
> >when VB6 is a memory and C++ is only used by metalheads for ring 0
programming.
>
> So how do you intend to convince the three million classic VB
> programmers to dump their religion overnight and become converted to
> another faith. For that's what it amounts to. You'd have more luck
> converting them to Pascal. Oh, wait a mo, that's what many are gonna
> be doing anyways!
>
> MM

[Jason]

>Actually, VBA is alive and kicking. You can download the beta for VSA.NET
>(visual studio for applications - slight name change).
>However, you are right that the script control is no longer necessary. The
>code dom and generators are built into the framework bundle you get with
>VS.NET. There are some nice samples in MSDN on how to hook into it.
>Of course, VSA does have it's advanatages - like a really nice GUI and debugger.
>The other nice thing is that you don't have to "provide the right hooks".
>VSA will be able to utilize any CLR-compliant .NET class.
>
>And lastly, yeah, it is exciting. Specially since you can also provide a
>way for users to customize code running on a web application, in much the
>same way they could write macros for Word or Excel - in addition to all
the
>great new features available to "macros", since they are now for all the
>most part, not different from the actual development language product.
>
>-Rob


Yeah, I finally got a chance to read the latest Visual Studio Magazine last
night and saw the insert. Well, that solves the problem of having all your
users set up with Visual Studio! Of course, it is probably the exact same
code repackaged and with a different licensing agreement...

It's nice to see that Microsoft is already thinking about specific solutions
along this vein. However, if you are willing to do a little more programming,
all the tools are available in the .NET framework to compile and dynamically
load the classes yourself, without even using VSA!

[W.E. (Bill) Goodrich, PhD]

In article <3bcb6701$1@news.devx.com>,
"Jason" <jason@creative_nospam_corp.com> writes:

> >What can .NET do, that could not be acomplished with ActiveX/COM
> >components written in C++ and callable from VB?
> >Max

> Well, what if you are calling a DLL from IIS,

....which is more of an IIS issue than a VB6/VB.NET issue...

> and you need to change the behavior immediately because there is
> some bad bug, and you can't take down the service which has a lock
> on the DLL...

Why would you want to allow the bad bug to continue running through
the transition period?

> NET can do this. You can run two versions of the same assembly in
> the same process space, and you can add new versions or entirely
> new assemblies without shutting down the process. This is the TRUE
> meaning of a "zero-impact installation."

[...]

> If I had .NET, I could EASILY make the program update itself from
> the web with no intervention by anyone.

And it is also a very large problem, in that it creates both the
perception and the reality of a chance that somebody malicious can use
the same mechanism to induce a "bad bug". The perception is important
in the current (and forseeable) business climate, with worries about
cyberterrorism, sabotage, and the like. The reality is that password
protection is a limited barrier - one which Micro$oft has had problems
with in the past.

The big threat (perceived and real) is not the "crash immediately and
spectacularly" scenario (which is bad enough), but less obvious
changes to transactions and other business records. If undetected long
enough, such attacks can destroy even major corporations. Aside from
the more obvious fund diversions, there are such possibilities as
creating the "records" of illegal transactions, tax violations, etc.

The threat need not come over the internet (although the setup allows
it). Operatives and opportunists within the facilities (including
contractors, maintainence and security personnel, etc. as well as
disgruntled employees and the like) can use the mechanism with much
less risk of detection. The "take the system down to install"
requirement starts looking like a security measure in such a climate.

> NET is a BIG DEAL.

But not necessarily a good deal.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*