Thoughts on Net verses VB7

[Don Jones]

The Chester Group was involved in Basic even before Windows. We were one

of the developers of True Basic. We have been using VB since it's
inception. We are also competent C, C++,C# developers. We see no reason

for VB to become C or any other language. We have application code that

was written in VB3 that has been upgraded to VB6.

A release of a language that does not build on the previous releases of
the language and provide a reasonable migration path is not an upgrade
but a new language. I think these changes represent through us a bone in

hopes that MS can cram Net down our throat.


As near as I can figure out releasing our applications in Net is the same

as emailing our source code to our competitors. If push comes to shove I

would rather see us port our apps to C than go down the Net path. So far

Net looks like a reasonable solution for a small segment of the development
world. If Microsoft thinks that we have reached the end of shrink-wrap

distribution they need to talk with there own marketing people. The only

good thing about Net I can see is that Microsoft is creating a vacuum that

could force the emergence of a real operating system and language
combination.

It baffles me that after creating a universal language for all its
applications and the web, developing a faithful user base and a large
installed code base, why would Microsoft rear back and shoot it in the
foot. How hard could it be to integrate inheritance, better threading,
and structured error handling in the present framework?

A very disappointed VB user;
Don Jones
President
The Chester Group don@chestergroup.com

[Sjoerd Verweij]

> How hard could it be to integrate inheritance, better threading,
> and structured error handling in the present framework?

Nearly impossible without a full re-write, I imagine. Especially threading.

[Torsten Rienow]

vb5 sp4 allowed the use of the threading api without
crashing the app in runtime.
you could not debug your threading vb5 app in ide
but that was a topic that could be handled.

threading api means the API CALL CreateThread(...)

[Sjoerd Verweij]

> vb5 sp4 allowed the use of the threading api without
> crashing the app in runtime.
> threading api means the API CALL CreateThread(...)

I think "allowing to call Win32 to hack threading" is something other than
"natively supports free threading". IIRC, the VB6 runtime isn't
free-threaded...

[Torsten Rienow]

why is anything done in vb a hack, if it uses
pointers, threadings or similar things.
can't you accept that there are vb programmers,
who knows how it works generally and want
to take advantage of it in there apps.

what is so uncommon to run a function in a
seperate thread. hey, we are talking about windows.
windows was made to allow running several
processes at the same time and running different
code at the same time in the same process.

i think the much more interesting question is, why
do we need .net to make things work with vb.

the usage of os-capabilties should not depend on
the language used to access them.
that means i should be able to access the os
in any programming language.

the different languages may have different ways to do
some non os-related stuff like math etc., but the
underlying os, should be full accessible through any
programming language.

[Rob Teixeira]

"Torsten Rienow" <torsten.rienow@bcf.de> wrote:
>vb5 sp4 allowed the use of the threading api without
>crashing the app in runtime.
>you could not debug your threading vb5 app in ide
>but that was a topic that could be handled.

Read Matt Curland's book. He explains the situation with threading in VB5
very well. You are not supposed to be able to use it, becuase most of the
internal VB runtime code, and compiler-generated code is not thread-safe.
Also, the apartment model doesn't support free threading. Your code wasn't
crashing only through pure good luck.

VB 6 removed the ability to do this as a safety precaution, because that's
what VB 5 should have done in the first place.

>threading api means the API CALL CreateThread(...)

But why would I need to call the API when I have the ability to create a
thread natively in VB.NET without the API?

Dim T As System.Threading.Thread
T = New Thread(AddressOf MyThreadStartFunction)
T.Start()
...
T.Sleep(1000)
...
T.Suspend()
...
T.Resume()

Isn't that EASIER?

I even have the ability to work with thread data slots, which is much like
the old Thread Local Storage. Let's see you do that with VB5/6.

-Rob

[Bob Butler]

"Torsten Rienow" <torsten.rienow@bcf.de> wrote in message
news:3ad5ea8a@news.devx.com...
> why is anything done in vb a hack, if it uses
> pointers, threadings or similar things.

Perhaps because through VB6 they are not supported? "Hack" is not always a
perjorative as far as I'm concerned. Sometimes they are the best solution
but they almost always have consequences. One of those consequences is that
changes in the next version of the language may make the hack inoperative.

> can't you accept that there are vb programmers,
> who knows how it works generally and want
> to take advantage of it in there apps.

Definitely. I have myself as have many others. They are still hacks.

> what is so uncommon to run a function in a
> seperate thread. hey, we are talking about windows.
> windows was made to allow running several
> processes at the same time and running different
> code at the same time in the same process.

True, but VB wasn't.

> i think the much more interesting question is, why
> do we need .net to make things work with vb.

VB.Net does support threading, VB6 does not. Pointers aren't directly
supported in either and because of the framework differences the ways you
deal with situations that use pointers differ. Hacks from VB6 are unlikely
to work in VB.Net. VB.Net has some supported options, as has already been
described in great detail, but they tend to look very non-VB-like.

> the usage of os-capabilties should not depend on
> the language used to access them.

Maybe it shouldn't, but it does.

> that means i should be able to access the os
> in any programming language.

Maybe you should, but if you try it from a language that doesn't support it
you have to use some sort of hack.

> the different languages may have different ways to do
> some non os-related stuff like math etc., but the
> underlying os, should be full accessible through any
> programming language.

Again, maybe it should, but it isn't.

[Jonathan Allen]

> why is anything done in vb a hack, if it uses
> pointers, threadings or similar things.

Threading itself is not a hack, just they way you had to do it in VB. The
fact that it only works on a particular service pack of a pervious edition
is a very bad sign.

As for pointers, it tends to makes a program less robust. As long as you
don't use pointers and API calls, VB is very robust. It is downright hard to
generate a GPF, while in VC++ it is an everyday occurrence.

> the usage of os-capabilties should not depend on
> the language used to access them.

That is goal of .Net. In the past you had to deal with things like pointers
to talk to the OS API. Then there are various flavors of COM, each with it's
own rules on where the type info is to be stored.

With .Net providing a common ground, you can use a safe language like VB,
Java, or JScript, and still access the OS API. The .Net framework does not
include all of the Win32's, but it is just a matter of time.

--
Jonathan Allen


"Torsten Rienow" <torsten.rienow@bcf.de> wrote in message
news:3ad5ea8a@news.devx.com...
> why is anything done in vb a hack, if it uses
> pointers, threadings or similar things.
> can't you accept that there are vb programmers,
> who knows how it works generally and want
> to take advantage of it in there apps.
>
> what is so uncommon to run a function in a
> seperate thread. hey, we are talking about windows.
> windows was made to allow running several
> processes at the same time and running different
> code at the same time in the same process.
>
> i think the much more interesting question is, why
> do we need .net to make things work with vb.
>
> the usage of os-capabilties should not depend on
> the language used to access them.
> that means i should be able to access the os
> in any programming language.
>
> the different languages may have different ways to do
> some non os-related stuff like math etc., but the
> underlying os, should be full accessible through any
> programming language.
>
>
>

[Torsten Rienow]

i thing there is only one question needs to be answered.
do we need the il. what are the benefits against native
compiled code.
i do not see any advantage for me and my apps.

[Torsten Rienow]

btw, i know some java coders who code something in
java, compile it, discompile it to get the much better
sourcecode than they wrote originally.

[Patrick Steele]

In article <3ad603fe@news.devx.com> (from Torsten Rienow
<torsten.rienow@bcf.de>),
> i thing there is only one question needs to be answered.
> do we need the il. what are the benefits against native
> compiled code.

When you compile to native code, you must tell the compiler *right then*
what optimizations can be used (based on your target platform). If your
app needs to target an original Pentium 1, you can't use any Pentium
II/III specific instructions that may give your app a boost.

With IL and JIT (just-in-time compile), your IL code is compiled right
on the target machine. If it's a P1, the compiler will compile for a
P1. If it's a PIII, the compiler can take advantage of this. The
result is that the code that is running is highly optimized for the
machine it's running on.

Unlike Java VM byte-code interpreter, the JIT compiles a procedure at a
time as it is needed. The first time a procedure is called, it's
compiled to native machine code. The next time that procedure is
called, it's native code is immediately executed.

--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect
Image Process Design

[Jonathan Allen]

Do you want to be able to write apps for 64-bit windows? How about Windows
CE?

Without IL, you have to compile several versions for each machine language.
And if you are really serious about performance, that also means separate
compilations for each of the various Intel and AMD processors.

--
Jonathan Allen


"Torsten Rienow" <torsten.rienow@bcf.de> wrote in message
news:3ad603fe@news.devx.com...
> i thing there is only one question needs to be answered.
> do we need the il. what are the benefits against native
> compiled code.
> i do not see any advantage for me and my apps.
>
>
>

[Sjoerd Verweij]

> As for pointers, it tends to makes a program less robust. As long as you
> don't use pointers and API calls, VB is very robust.

Hogwash. One circular reference and VB dies every time you click "Stop".

[Jonathan Allen]

> Hogwash. One circular reference and VB dies every time you click "Stop".

That proves nothing, the VB6 IDE dies when I use ctrl-click to select
multiple controls. Considering that it was created in VC++, it actually
supports my position.

--
Jonathan Allen


"Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
news:3ad61c3a$1@news.devx.com...
> > As for pointers, it tends to makes a program less robust. As long as you
> > don't use pointers and API calls, VB is very robust.
>
> Hogwash. One circular reference and VB dies every time you click "Stop".
>
>
>

[Sjoerd Verweij]

> That proves nothing, the VB6 IDE dies when I use ctrl-click to select
> multiple controls. Considering that it was created in VC++, it actually
> supports my position.

Sorry for assuming you meant the IDE -- if you stay away from some things,
VB executables are stable, indeed.