so long, VB? (was Re: String Functions)

[Rob Jolt]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39afda85$1@news.devx.com...
> > The more I look, the more I think that MSFT is still
> > trying to straddle that fence of an easy tool to use and a powerful
> > developement tool. I don't think you can have it both ways.
>
> I think you can, and the fence straddling is the problem. Contradiction?
Nope.
> Sitting on a fence *hurts*, especially if you have one leg on each side.
There's no
> reason they can't have a full-blown, balls-out language that's still easy
to ramp up

VB6 was the last version of VB. VB.NET is a crippled version of C# with
different syntax. Without unmanaged code VB.NET is clearly NOT on the
"powerful" side of the fence, rather both feet firmly planted in the NET
quicksand. MS has decided it to be so and it's not going to change.

I see .NET being the beginning of the decline of VB. Since its inception VB
has been a marketing and political tool for MS to advance its more important
strategies. That appears to be continuing as they use it to force .NET upon
us. In the past we either learned to live with it or took up Delphi. (btw,
anyone else notice Borland has been notably silent about .NET -- possibly
ignoring it?) But .NET makes any language RAD, so assuming we swallow that
pill we now have choices.

Given the ease of intermixing modules of different languages I expect
advanced VB'ers to slowly move away from VB.NET and more into C# and others.
I certainly will. Losing its most competent supporters will be a catalyst in
the decline.

ooh, pretty serious stuff for a Friday. Well, I've been wrong before <g>

[Karl E. Peterson]

Hi Rob --

> VB6 was the last version of VB. VB.NET is a crippled version of C# with
> different syntax.

I gotta agree with you there. I don't think it's fair to saddle VB folks with this
..NET extension. It's most certainly not VB, and should've been given a new name, as
they did with C#.

> Without unmanaged code VB.NET is clearly NOT on the
> "powerful" side of the fence, rather both feet firmly planted in the NET
> quicksand.

Yep.

> MS has decided it to be so and it's not going to change.

Not necessarily! See:

http://discuss.develop.com/archives/wa.exe?A2=ind0008c&L=dotnet&F=&S=&P=6391

Alan Carter <alanc@MICROSOFT.COM>, Lead VB PM, said:

>The significant differences between the two languages in version one:
>(1) VB.NET does not support operator overloading. We would like to add
>support for operator overloading to VB.NET.
>(2) VB.NET does not support direct memory access (C# provides this via
>unsafe code blocks and C-style pointers. Support for direct access to
>memory in VB.NET will be considered if users decide that this is important
>for VB.NET to support.
>(3) C# does not support typeless - script type - programming

I jumped in, and tried drumming up some support for point #2, but was "flamed" by
folks like Jay for pounding sand -- basically being told that "there's a place" for
crippled languages, a place where newbies can be safe.

If everyone started providing the needed feedback, we *might* have a chance. But it
won't happen, if it doesn't happen soon!

> I see .NET being the beginning of the decline of VB.

A very strong possibility. If the current thought-tracks continue, a strong
liklihood.

> Since its inception VB
> has been a marketing and political tool for MS to advance its more important
> strategies. That appears to be continuing as they use it to force .NET upon
> us.

They can use it for that *and* give us unmanaged code. This isn't an either/or.

> Given the ease of intermixing modules of different languages I expect
> advanced VB'ers to slowly move away from VB.NET and more into C# and others.
> I certainly will. Losing its most competent supporters will be a catalyst in
> the decline.

The differences noted by Alan Carter <alanc@MICROSOFT.COM>, Lead VB PM, above are
certainly enough to drive a good number to C#. The simple fact that we can't
directly access memory is enough to move most of the folks who might be loosely
termed "leaders" in the field. The sheep will follow.

(And please, not to you Rob, but to others, let's not start with "but there's *still*
the API!" unless you can provide the answer to how exactly that's useful without the
*Ptr functions and, by implication, the impetus for their removal. As best I can
tell, this question remains vehemently unaddressed either on the DOTNET list or
elsewhere.)

> ooh, pretty serious stuff for a Friday. Well, I've been wrong before <g>

Heh, me too, but not about this. <g>

Later... Karl
--
http://www.mvps.org/vb

[Jay Glynn]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39affc70@news.devx.com...
> Hi Rob --
>
> > VB6 was the last version of VB. VB.NET is a crippled version of C# with
> > different syntax.
>
> I gotta agree with you there. I don't think it's fair to saddle VB folks
with this
> .NET extension. It's most certainly not VB, and should've been given a
new name, as
> they did with C#.
>

OK I'll play devils advocate. Is this change as big as from 3 to 4 or more
importantly from 3 to 5? We had to do a fair amount of work to get our 3
apps up and running in 5.

> > Without unmanaged code VB.NET is clearly NOT on the
> > "powerful" side of the fence, rather both feet firmly planted in the NET
> > quicksand.
>
> Yep.
>

OK, remember, I'm playing deveil's advocate here. How often do you
**really** need that functionality. How many strptr or varptr calls do you
**have** to make.

> > MS has decided it to be so and it's not going to change.
>
> Not necessarily! See:
>
>
http://discuss.develop.com/archives/wa.exe?A2=ind0008c&L=dotnet&F=&S=&P=6391
>
> Alan Carter <alanc@MICROSOFT.COM>, Lead VB PM, said:
>
> >The significant differences between the two languages in version one:
> >(1) VB.NET does not support operator overloading. We would like to add
> >support for operator overloading to VB.NET.
> >(2) VB.NET does not support direct memory access (C# provides this via
> >unsafe code blocks and C-style pointers. Support for direct access to
> >memory in VB.NET will be considered if users decide that this is
important
> >for VB.NET to support.
> >(3) C# does not support typeless - script type - programming
>
> I jumped in, and tried drumming up some support for point #2, but was
"flamed" by
> folks like Jay for pounding sand -- basically being told that "there's a
place" for
> crippled languages, a place where newbies can be safe.

OK, speaking for myself now, my view of this has been changing a little. C#
give the power to do practically anything that needs to be done. I have been
looking at this as someone who has done a fair amount of c/c++ and a little
java (ssshhh, don't tell anyone) code and the transition is fairly easy. In
looking around I see a few individuals that have not done any c/c++/java
code, and this would be a very tough transition. Learn a new development
model, as well as learn a new language (what are those curly braces for
anyway?). I was for making VB the *safe* place to play, but the more I think
about it the more I can see Karl's point, not everyone is going to be C#
literate (or want to) and it would seem that we are adding some great stuff
to VB, but at the same time limiting the potential.

>
> If everyone started providing the needed feedback, we *might* have a
chance. But it
> won't happen, if it doesn't happen soon!
>
> > I see .NET being the beginning of the decline of VB.
>
> A very strong possibility. If the current thought-tracks continue, a
strong
> liklihood.
>
> > Since its inception VB
> > has been a marketing and political tool for MS to advance its more
important
> > strategies. That appears to be continuing as they use it to force .NET
upon
> > us.
>
> They can use it for that *and* give us unmanaged code. This isn't an
either/or.
>
> > Given the ease of intermixing modules of different languages I expect
> > advanced VB'ers to slowly move away from VB.NET and more into C# and
others.
> > I certainly will. Losing its most competent supporters will be a
catalyst in
> > the decline.
>
> The differences noted by Alan Carter <alanc@MICROSOFT.COM>, Lead VB PM,
above are
> certainly enough to drive a good number to C#. The simple fact that we
can't
> directly access memory is enough to move most of the folks who might be
loosely
> termed "leaders" in the field. The sheep will follow.
>
> (And please, not to you Rob, but to others, let's not start with "but
there's *still*
> the API!" unless you can provide the answer to how exactly that's useful
without the
> *Ptr functions and, by implication, the impetus for their removal. As
best I can
> tell, this question remains vehemently unaddressed either on the DOTNET
list or
> elsewhere.)
>
> > ooh, pretty serious stuff for a Friday. Well, I've been wrong before <g>
>
> Heh, me too, but not about this. <g>
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>

I bailed on the DOTNET list for the reason you mentioned. I am not above
admitting when I that I may have been just a little incorrect on my previous
posts. Maybe just a little. The wonderful and wise Karl has allowed me to
see the light. Where's the petition, let me call my congressman, we want
direct memory access and we want it right now!

[j.irvine]

Just to stick in my $.02 ...

> > VB6 was the last version of VB. VB.NET is a crippled version of C#
with
> > different syntax.
> I gotta agree with you there. I don't think it's fair to saddle VB
folks with this
> .NET extension. It's most certainly not VB, and should've been given
a new name, as
> they did with C#.
> > Given the ease of intermixing modules of different languages I
expect
> > advanced VB'ers to slowly move away from VB.NET and more into C# and
others.
> > I certainly will. Losing its most competent supporters will be a
catalyst in
> > the decline.

I couldn't agree more. If Microsoft had to include VB.NET, they
should've just called it VB# or something and left VB7 alone. From the
way it looks right now, I'll be using C#. I just can't see the point of
learning the new "VB" syntax outside of curiosity to see what how well
VS.NET works with intermixed language modules.

You guys sure know how to liven up a dull Friday afternoon. Keep it up
:)

- j.irvine

[Karl E. Peterson]

Hi Jay --

> > > VB6 was the last version of VB. VB.NET is a crippled version of C# with
> > > different syntax.
> >
> > I gotta agree with you there. I don't think it's fair to saddle VB folks with
this
> > .NET extension. It's most certainly not VB, and should've been given a new name,
as
> > they did with C#.
>
> OK I'll play devils advocate.

Cool.

> Is this change as big as from 3 to 4 or more
> importantly from 3 to 5? We had to do a fair amount of work to get our 3
> apps up and running in 5.

I'd say quite a bit bigger! Moving to 32-bits, we had to go through and basically
switch Integer to Long -- **** near as simple as a global search and replace -- as
well as redeclare DLL calls. That was almost trivial. It got worse, lots worse in
some cases, if you were using String vars for binary data handling. This time, they
changed the fundamental definition yet more variable types, doubling the number of
bits again. But these changes are going to be far more subtle as to whether they'll
require reworking previously functional algorithms. Also, removal of *Ptr functions
will totally cripple entire websites full of functional code.

> > > Without unmanaged code VB.NET is clearly NOT on the
> > > "powerful" side of the fence, rather both feet firmly planted in the NET
> > > quicksand.
> >
> > Yep.
>
> OK, remember, I'm playing deveil's advocate here. How often do you
> **really** need that functionality. How many strptr or varptr calls do you
> **have** to make.

I honestly can't recall not using those functions in any project for years now.
(Have they provided access to the raw window message stream in VB.NET? I don't know,
but my hunch is not. Can't hook those without *Ptr functions.)

> > I jumped in, and tried drumming up some support for point #2, but was "flamed" by
> > folks like Jay for pounding sand -- basically being told that "there's a place"
for
> > crippled languages, a place where newbies can be safe.
>
> OK, speaking for myself now, my view of this has been changing a little. C#
> give the power to do practically anything that needs to be done. I have been
> looking at this as someone who has done a fair amount of c/c++ and a little
> java (ssshhh, don't tell anyone) code and the transition is fairly easy. In
> looking around I see a few individuals that have not done any c/c++/java
> code, and this would be a very tough transition. Learn a new development
> model, as well as learn a new language (what are those curly braces for
> anyway?). I was for making VB the *safe* place to play, but the more I think
> about it the more I can see Karl's point, not everyone is going to be C#
> literate (or want to) and it would seem that we are adding some great stuff
> to VB, but at the same time limiting the potential.

Very cool! I see we're turning folks around here. Will you be writing Alan today?
<g>

I don't see the problem with having an inherently *safe* place to play, as long as
you can unbuckle your seat belt when you find the need to, <ahem>adjust
yourself</ahem>, so to speak.

> I bailed on the DOTNET list for the reason you mentioned.

Hallelujah, you *will* be saved, my son! :-)

> I am not above
> admitting when I that I may have been just a little incorrect on my previous
> posts. Maybe just a little. The wonderful and wise Karl has allowed me to
> see the light. Where's the petition, let me call my congressman, we want
> direct memory access and we want it right now!

I'd start with Alan Carter <alanc@MICROSOFT.COM>, Lead VB PM, and move on up to
steveb and billg if you meet resistance. Ah, what the heck, CC them anyway just for
good cause! Bill's a BASIC-guy, from way back, dontcha know? :-)

Thanks... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Be sure to let Microsoft know how you feel! :-)
--
http://www.mvps.org/vb


"j.irvine" <reply@to.group> wrote in message news:39b00790@news.devx.com...
> Just to stick in my $.02 ...
>
> > > VB6 was the last version of VB. VB.NET is a crippled version of C#
> with
> > > different syntax.
> > I gotta agree with you there. I don't think it's fair to saddle VB
> folks with this
> > .NET extension. It's most certainly not VB, and should've been given
> a new name, as
> > they did with C#.
> > > Given the ease of intermixing modules of different languages I
> expect
> > > advanced VB'ers to slowly move away from VB.NET and more into C# and
> others.
> > > I certainly will. Losing its most competent supporters will be a
> catalyst in
> > > the decline.
>
> I couldn't agree more. If Microsoft had to include VB.NET, they
> should've just called it VB# or something and left VB7 alone. From the
> way it looks right now, I'll be using C#. I just can't see the point of
> learning the new "VB" syntax outside of curiosity to see what how well
> VS.NET works with intermixed language modules.
>
> You guys sure know how to liven up a dull Friday afternoon. Keep it up
> :)
>
> - j.irvine
>
>

[Michael \(michka\) Kaplan]

If they waited till Win64, they would be losing YAO (yet another oppotunity)
to kill backwards compatiblity.

The more I think about it, the more VB developers react toward this sort of
thing seems like battered wife syndrome.... we are abused, we are
mistreated, our lives are made difficult, but we think about how swell they
are when things are working well and the promise of the future and we
forgive them. Till the next time.

Does anyone else see the pattern here, with VB.Net just being the latest
example?

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:39b0248d@news.devx.com...
> "Karl E. Peterson" <karl@mvps.org> wrote
> > If everyone started providing the needed feedback, we *might* have a
chance. But it
> > won't happen, if it doesn't happen soon!
> >
> > > I see .NET being the beginning of the decline of VB.
> >
> > A very strong possibility. If the current thought-tracks continue, a
strong
> > liklihood.
> >
>
> I agree that we we need pointers to procedures as well as memory.
>
> The only trouble I can see with supplying support for pointers is when
some kid
> misuses them and crashes the system. If there are other reasons, I have
not
> read them yet, but I can not see how misuse could be a major point.
Unless
> misuse is going to start the computer on fire, we should be able to
reference
> memory, and share those references with our friends (other exe's). The
> 'professionals' will design/debug their programs so that misuse is not a
worry
> and the kids will still crash their programs if they do not use the
language
> correctly As I stated before they should be brought in with easy to
understand
> syntax:
>
> Public Sub SomeSub()
> Dim Data(10) As Byte
> Dim Ptr As Byte Pointer
>
> Ptr = Data
> Data(0) = 1
> Debug.Print Ptr^ ' 1
>
> Ptr = SomeSub
> Debug.Print Ptr^ ' 6238456
>
> I also thought MS should have held off the .Net transition until 64-bit
computing
> arrived. They dropped 16 bit support after 32 bit operating systems
arrived, and
> they could have left off support for 32 bit systems some time after 64.Net
arrives.
> With all the changes that it currently entails, why not go all the way and
trim down
> the entire language to a more consice form?
>
> I still hope they do hold off so they have ample time to tweek/focus the
..Net
> framework on the future, instead of the past. I know you stated it will
happen
> otherwise, I just wanted to re-iterate my concerns...
>
> LFS
>
>
>

[Larry Serflaten]

"Karl E. Peterson" <karl@mvps.org> wrote
> If everyone started providing the needed feedback, we *might* have a chance. But it
> won't happen, if it doesn't happen soon!
>
> > I see .NET being the beginning of the decline of VB.
>
> A very strong possibility. If the current thought-tracks continue, a strong
> liklihood.
>

I agree that we we need pointers to procedures as well as memory.

The only trouble I can see with supplying support for pointers is when some kid
misuses them and crashes the system. If there are other reasons, I have not
read them yet, but I can not see how misuse could be a major point. Unless
misuse is going to start the computer on fire, we should be able to reference
memory, and share those references with our friends (other exe's). The
'professionals' will design/debug their programs so that misuse is not a worry
and the kids will still crash their programs if they do not use the language
correctly As I stated before they should be brought in with easy to understand
syntax:

Public Sub SomeSub()
Dim Data(10) As Byte
Dim Ptr As Byte Pointer

Ptr = Data
Data(0) = 1
Debug.Print Ptr^ ' 1

Ptr = SomeSub
Debug.Print Ptr^ ' 6238456

I also thought MS should have held off the .Net transition until 64-bit computing
arrived. They dropped 16 bit support after 32 bit operating systems arrived, and
they could have left off support for 32 bit systems some time after 64.Net arrives.
With all the changes that it currently entails, why not go all the way and trim down
the entire language to a more consice form?

I still hope they do hold off so they have ample time to tweek/focus the .Net
framework on the future, instead of the past. I know you stated it will happen
otherwise, I just wanted to re-iterate my concerns...

LFS

[Larry Serflaten]

I got involved with the context and mucked up the contents.
I should have used two pointers:

> Public Sub SomeSub()
> Dim Data(10) As Byte
> Dim Ptr1 As Byte Pointer
> Dim Ptr2 As Long Pointer
>
> Ptr1 = Data
> Data(0) = 1
> Debug.Print Ptr1^ ' 1
>
> Ptr2 = SomeSub
> Debug.Print Ptr2^ ' 6238456

It would be nice if we can get it!

LFS

[Karl E. Peterson]

Hi Larry --

> > If everyone started providing the needed feedback, we *might* have a chance. But
it
> > won't happen, if it doesn't happen soon!
> >
> > > I see .NET being the beginning of the decline of VB.
> >
> > A very strong possibility. If the current thought-tracks continue, a strong
> > liklihood.
>
> I agree that we we need pointers to procedures as well as memory.

Have you told Microsoft that you feel that way?

> The only trouble I can see with supplying support for pointers is when some kid
> misuses them and crashes the system.

That's it. Right there. That's the end-all, be-all of "language safety." Po'
little Danny Applenam might stub is pointer on something when he wasn't looking.
It's for the _SAKE OF THE CHILDREN_ don't you know?

> If there are other reasons, I have not
> read them yet, but I can not see how misuse could be a major point. Unless
> misuse is going to start the computer on fire, we should be able to reference
> memory, and share those references with our friends (other exe's).

That'd be nice, but Win32 doesn't like sharing pointers -- VB isn't unique here.

> 'professionals' will design/debug their programs so that misuse is not a worry
> and the kids will still crash their programs if they do not use the language
> correctly

Yep. Have you told Microsoft that you feel that way?

> As I stated before they should be brought in with easy to understand
> syntax:

Cool by me. Maybe they could give Bob Zale a call?

> I also thought MS should have held off the .Net transition until 64-bit computing
> arrived. They dropped 16 bit support after 32 bit operating systems arrived, and
> they could have left off support for 32 bit systems some time after 64.Net arrives.

I'm ambivelent here.

> With all the changes that it currently entails, why not go all the way and trim
down
> the entire language to a more consice form?

Agreed.

Now, make your next action an email to Microsoft, okay? :-)

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Michka --

> Does anyone else see the pattern here, with VB.Net just being the latest
> example?

Yeah, we've been far too heavily influenced by the Fox group, haven't we? <g>

Later... Karl
--
http://www.mvps.org/vb


"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in
message news:39b02660@news.devx.com...
> If they waited till Win64, they would be losing YAO (yet another oppotunity)
> to kill backwards compatiblity.
>
> The more I think about it, the more VB developers react toward this sort of
> thing seems like battered wife syndrome.... we are abused, we are
> mistreated, our lives are made difficult, but we think about how swell they
> are when things are working well and the promise of the future and we
> forgive them. Till the next time.
>
> Does anyone else see the pattern here, with VB.Net just being the latest
> example?
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
> "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> news:39b0248d@news.devx.com...
> > "Karl E. Peterson" <karl@mvps.org> wrote
> > > If everyone started providing the needed feedback, we *might* have a
> chance. But it
> > > won't happen, if it doesn't happen soon!
> > >
> > > > I see .NET being the beginning of the decline of VB.
> > >
> > > A very strong possibility. If the current thought-tracks continue, a
> strong
> > > liklihood.
> > >
> >
> > I agree that we we need pointers to procedures as well as memory.
> >
> > The only trouble I can see with supplying support for pointers is when
> some kid
> > misuses them and crashes the system. If there are other reasons, I have
> not
> > read them yet, but I can not see how misuse could be a major point.
> Unless
> > misuse is going to start the computer on fire, we should be able to
> reference
> > memory, and share those references with our friends (other exe's). The
> > 'professionals' will design/debug their programs so that misuse is not a
> worry
> > and the kids will still crash their programs if they do not use the
> language
> > correctly As I stated before they should be brought in with easy to
> understand
> > syntax:
> >
> > Public Sub SomeSub()
> > Dim Data(10) As Byte
> > Dim Ptr As Byte Pointer
> >
> > Ptr = Data
> > Data(0) = 1
> > Debug.Print Ptr^ ' 1
> >
> > Ptr = SomeSub
> > Debug.Print Ptr^ ' 6238456
> >
> > I also thought MS should have held off the .Net transition until 64-bit
> computing
> > arrived. They dropped 16 bit support after 32 bit operating systems
> arrived, and
> > they could have left off support for 32 bit systems some time after 64.Net
> arrives.
> > With all the changes that it currently entails, why not go all the way and
> trim down
> > the entire language to a more consice form?
> >
> > I still hope they do hold off so they have ample time to tweek/focus the
> .Net
> > framework on the future, instead of the past. I know you stated it will
> happen
> > otherwise, I just wanted to re-iterate my concerns...
> >
> > LFS
> >
> >
> >
>
>

[Michael \(michka\) Kaplan]

Ok, so we can call if Battered Developer Syndrome, or BDS for short. :-)

I can see it in the clinical description: "VB developers are particularly
prone to BDS and it appears some of the only cure involve liberal use of
Java and C# to wean them off the "ease of use only in VB" myth.

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b0345a$1@news.devx.com...
> Hi Michka --
>
> > Does anyone else see the pattern here, with VB.Net just being the latest
> > example?
>
> Yeah, we've been far too heavily influenced by the Fox group, haven't we?
<g>
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>
> "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote in
> message news:39b02660@news.devx.com...
> > If they waited till Win64, they would be losing YAO (yet another
oppotunity)
> > to kill backwards compatiblity.
> >
> > The more I think about it, the more VB developers react toward this sort
of
> > thing seems like battered wife syndrome.... we are abused, we are
> > mistreated, our lives are made difficult, but we think about how swell
they
> > are when things are working well and the promise of the future and we
> > forgive them. Till the next time.
> >
> > Does anyone else see the pattern here, with VB.Net just being the latest
> > example?
> >
> > --
> > MichKa
> >
> > random junk of dubious value at the
> > multilingual http://www.trigeminal.com/ and
> > a new book on internationalization in VB at
> > http://www.i18nWithVB.com/
> >
> > "Larry Serflaten" <serflaten@usinternet.com> wrote in message
> > news:39b0248d@news.devx.com...
> > > "Karl E. Peterson" <karl@mvps.org> wrote
> > > > If everyone started providing the needed feedback, we *might* have a
> > chance. But it
> > > > won't happen, if it doesn't happen soon!
> > > >
> > > > > I see .NET being the beginning of the decline of VB.
> > > >
> > > > A very strong possibility. If the current thought-tracks continue,
a
> > strong
> > > > liklihood.
> > > >
> > >
> > > I agree that we we need pointers to procedures as well as memory.
> > >
> > > The only trouble I can see with supplying support for pointers is when
> > some kid
> > > misuses them and crashes the system. If there are other reasons, I
have
> > not
> > > read them yet, but I can not see how misuse could be a major point.
> > Unless
> > > misuse is going to start the computer on fire, we should be able to
> > reference
> > > memory, and share those references with our friends (other exe's).
The
> > > 'professionals' will design/debug their programs so that misuse is not
a
> > worry
> > > and the kids will still crash their programs if they do not use the
> > language
> > > correctly As I stated before they should be brought in with easy to
> > understand
> > > syntax:
> > >
> > > Public Sub SomeSub()
> > > Dim Data(10) As Byte
> > > Dim Ptr As Byte Pointer
> > >
> > > Ptr = Data
> > > Data(0) = 1
> > > Debug.Print Ptr^ ' 1
> > >
> > > Ptr = SomeSub
> > > Debug.Print Ptr^ ' 6238456
> > >
> > > I also thought MS should have held off the .Net transition until
64-bit
> > computing
> > > arrived. They dropped 16 bit support after 32 bit operating systems
> > arrived, and
> > > they could have left off support for 32 bit systems some time after
64.Net
> > arrives.
> > > With all the changes that it currently entails, why not go all the way
and
> > trim down
> > > the entire language to a more consice form?
> > >
> > > I still hope they do hold off so they have ample time to tweek/focus
the
> > .Net
> > > framework on the future, instead of the past. I know you stated it
will
> > happen
> > > otherwise, I just wanted to re-iterate my concerns...
> > >
> > > LFS
> > >
> > >
> > >
> >
> >
>
>

[Branco Medeiros]

Karl E. Peterson wrote:
> > VB6 was the last version of VB. VB.NET is a crippled version of C# with
> > different syntax.
>
> I gotta agree with you there. I don't think it's fair to saddle VB folks
with this
> .NET extension. It's most certainly not VB, and should've been given a
new name, as
> they did with C#.
>
Hey, VB doesn't stand for VisaulBasic!... Did you notice the musical
pattern, here? While C# stands for C-sharp, VB stands for V-flat (I just
keep wondering what the Z language would look like).
:-)

The worse thing in this sccenario is that picking VB as a language of choice
is not actually a testment to someone's lack of coding expertise, although
it seems that this is how the MSVB team seems to think of us, as under rated
coders... :-P

My choice for VB is rather a choice for a better syntax, a different way to
write code that seems (at least to me) way ahead of the counterpart
languages that still need arcane constructs like { } and begin/end to define
block scope. A good coder is a good coder, period. As some wise man said
once, if there's any kind of magic, it isn't in the language, but in the
programmer.

So, having this "magician" chosen VB instead of <argh style="outloud"> Java
</argh> or C/++/#, it's only reasonable for him/her to expect that things
"doable" in one language are also "doable" in this other one. This should be
more evident because all these .NET languages target the same environment,
thus enforcing the language choice as a stylistic choice, not more, not
less.
Under the shadow of this unified framework, why would a language be given a
fully loaded 12 bullets pistol while other must do with a one-bullet gun?
I'm really a calm person, but this kind of decision just pisses me off...

So, things I'd like the VBfolks@MS should consider building in a, say,
Microsoft.VisualBasic.Advanced namespace (and that would allow for IT
managers to keep their children from messing with):

a) Pointer as a first class data type
b) Conditional structures (a la C UNIONS)
c) Function/Sub/Property data types (commonly called "closures")
d) Custom data types (to access those out-of-reach "unsigned longs", and the
like)
e) Inline toggles (so IIF-like functions could be more eficient)
f) Shortcircuit boolean evaluation (ditto)
g) Control of the alignment of UDT data
h) The *full* set of bitwise operators

Just to name a few, in this rainy saturday afternoon.

Regards,

Branco.

[Michael \(michka\) Kaplan]

It is worth noting what many others who have been at Microsoft have
noted.... that most of the code it produces is in fact written in Visual
C++, using its latest compiler at the time. One recent exception to this is
the parts of VC being written in C#.

Note how although some minor wizards and add-ins are written in VB, that
none of the core products are. And when they are, they are apparently
written by third parties (note products such as VOLT), which suggests two
things:

1) Lack of expertise in using Visual Basic at MS (except the VB test team,
which is too busy trying to break VB to be writing components for others!)

2) Lack of interest in changing #1, possibly due to belief in its
limitations or possibly just lack of respect for it as a development
platform?

What I would like to see is for Microsoft to put its money where its mouth
is... and announce a MAJOR product that is going to be written in Visual
Basic. The proof that:

a) someone in Microsoft has confidence that VB is a platform of choice for a
project

b) the VB team is willing to provide the sort of support for such a product

THIS is what would prove that VB is a place one can be. Until then, it is
fair to say that VB's success is in SPITE of Microsoft. not because of it.

So, is anyone at Microsoft willing to take the plunge and put a product into
VB.Net? Note how even the VB team apparently chose C# as its C++ alternative
rather than VB (so far as we have been told)?

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Branco Medeiros" <branco_medeiros@yahoo.com> wrote in message
news:39b29bb2@news.devx.com...
> Karl E. Peterson wrote:
> > > VB6 was the last version of VB. VB.NET is a crippled version of C#
with
> > > different syntax.
> >
> > I gotta agree with you there. I don't think it's fair to saddle VB
folks
> with this
> > .NET extension. It's most certainly not VB, and should've been given a
> new name, as
> > they did with C#.
> >
> Hey, VB doesn't stand for VisaulBasic!... Did you notice the musical
> pattern, here? While C# stands for C-sharp, VB stands for V-flat (I just
> keep wondering what the Z language would look like).
> :-)
>
> The worse thing in this sccenario is that picking VB as a language of
choice
> is not actually a testment to someone's lack of coding expertise, although
> it seems that this is how the MSVB team seems to think of us, as under
rated
> coders... :-P
>
> My choice for VB is rather a choice for a better syntax, a different way
to
> write code that seems (at least to me) way ahead of the counterpart
> languages that still need arcane constructs like { } and begin/end to
define
> block scope. A good coder is a good coder, period. As some wise man said
> once, if there's any kind of magic, it isn't in the language, but in the
> programmer.
>
> So, having this "magician" chosen VB instead of <argh style="outloud">
Java
> </argh> or C/++/#, it's only reasonable for him/her to expect that things
> "doable" in one language are also "doable" in this other one. This should
be
> more evident because all these .NET languages target the same environment,
> thus enforcing the language choice as a stylistic choice, not more, not
> less.
> Under the shadow of this unified framework, why would a language be given
a
> fully loaded 12 bullets pistol while other must do with a one-bullet gun?
> I'm really a calm person, but this kind of decision just pisses me off...
>
> So, things I'd like the VBfolks@MS should consider building in a, say,
> Microsoft.VisualBasic.Advanced namespace (and that would allow for IT
> managers to keep their children from messing with):
>
> a) Pointer as a first class data type
> b) Conditional structures (a la C UNIONS)
> c) Function/Sub/Property data types (commonly called "closures")
> d) Custom data types (to access those out-of-reach "unsigned longs", and
the
> like)
> e) Inline toggles (so IIF-like functions could be more eficient)
> f) Shortcircuit boolean evaluation (ditto)
> g) Control of the alignment of UDT data
> h) The *full* set of bitwise operators
>
> Just to name a few, in this rainy saturday afternoon.
>
> Regards,
>
> Branco.
>
>

[Alessandro Coppo]

Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com> wrote in
message news:39b2e344@news.devx.com...
> It is worth noting what many others who have been at Microsoft have
> noted.... that most of the code it produces is in fact written in Visual
> C++, using its latest compiler at the time. One recent exception to this
is
> the parts of VC being written in C#.

Given the annoucements, ASP+ is written in C# plus some assembler (pardon,
VC++) and Visual Studio NET is going the same way. Nothing relevant is
written in VB7 (at least it is not advertised). I think that the writing on
the wall could not be more clear.

Bye!!!

[Michael \(michka\) Kaplan]

Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.

Yep, no core product in VB. Although there are some peripheral components
written in VB (espcially wizards!). It does prove *something*, IMHO.

Is there anyone else who would like MS to take up the challenge implied
here? To prove that the language is something that they believe is worth
developing in? It does not have to be part of the VS7 box (that might be
taking dogfood a bit to far) but it should be announced before VS hits the
street that "Product Y is being written in VB.Net, etc., etc."

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Alessandro Coppo" <a.coppo@iol.it> wrote in message
news:39b33a59@news.devx.com...
>
> Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com> wrote
in
> message news:39b2e344@news.devx.com...
> > It is worth noting what many others who have been at Microsoft have
> > noted.... that most of the code it produces is in fact written in Visual
> > C++, using its latest compiler at the time. One recent exception to this
> is
> > the parts of VC being written in C#.
>
> Given the annoucements, ASP+ is written in C# plus some assembler (pardon,
> VC++) and Visual Studio NET is going the same way. Nothing relevant is
> written in VB7 (at least it is not advertised). I think that the writing
on
> the wall could not be more clear.
>
> Bye!!!
>
>

[Kevin Westhead]

Yep, I agree. MS should take up the challenge you've described below.
However, I suspect they won't. <bg>

--
Kevin Westhead

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
in message news:39b374b4$1@news.devx.com...
> Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
>
> Yep, no core product in VB. Although there are some peripheral components
> written in VB (espcially wizards!). It does prove *something*, IMHO.
>
> Is there anyone else who would like MS to take up the challenge implied
> here? To prove that the language is something that they believe is worth
> developing in? It does not have to be part of the VS7 box (that might be
> taking dogfood a bit to far) but it should be announced before VS hits the
> street that "Product Y is being written in VB.Net, etc., etc."
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
> "Alessandro Coppo" <a.coppo@iol.it> wrote in message
> news:39b33a59@news.devx.com...
> >
> > Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> in
> > message news:39b2e344@news.devx.com...
> > > It is worth noting what many others who have been at Microsoft have
> > > noted.... that most of the code it produces is in fact written in
Visual
> > > C++, using its latest compiler at the time. One recent exception to
this
> > is
> > > the parts of VC being written in C#.
> >
> > Given the annoucements, ASP+ is written in C# plus some assembler
(pardon,
> > VC++) and Visual Studio NET is going the same way. Nothing relevant is
> > written in VB7 (at least it is not advertised). I think that the writing
> on
> > the wall could not be more clear.
> >
> > Bye!!!
> >
> >
>
>

[Mike]

Hmmmm... MS Money would be a good candidate for a VB only app. It's amazing
that not one of their commercial applications is a VB only app.

Mike

"Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote:
>Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
>
>Yep, no core product in VB. Although there are some peripheral components
>written in VB (espcially wizards!). It does prove *something*, IMHO.
>
>Is there anyone else who would like MS to take up the challenge implied
>here? To prove that the language is something that they believe is worth
>developing in? It does not have to be part of the VS7 box (that might be
>taking dogfood a bit to far) but it should be announced before VS hits the
>street that "Product Y is being written in VB.Net, etc., etc."
>
>--
>MichKa
>
>random junk of dubious value at the
>multilingual http://www.trigeminal.com/ and
>a new book on internationalization in VB at
>http://www.i18nWithVB.com/
>
>"Alessandro Coppo" <a.coppo@iol.it> wrote in message
>news:39b33a59@news.devx.com...
>>
>> Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com> wrote
>in
>> message news:39b2e344@news.devx.com...
>> > It is worth noting what many others who have been at Microsoft have
>> > noted.... that most of the code it produces is in fact written in Visual
>> > C++, using its latest compiler at the time. One recent exception to
this
>> is
>> > the parts of VC being written in C#.
>>
>> Given the annoucements, ASP+ is written in C# plus some assembler (pardon,
>> VC++) and Visual Studio NET is going the same way. Nothing relevant is
>> written in VB7 (at least it is not advertised). I think that the writing
>on
>> the wall could not be more clear.
>>
>> Bye!!!
>>
>>
>
>

[Karl E. Peterson]

Hi Branco --

> The worse thing in this sccenario is that picking VB as a language of choice
> is not actually a testment to someone's lack of coding expertise, although
> it seems that this is how the MSVB team seems to think of us, as under rated
> coders... :-P

That's exactly what's thought of us, yep. I tried raising a few points on the
DOTNET-L list, about how we *need* direct memory access, and was continually flamed
(with implicit MS support) for not being submissive enough. Mucking forons!

> My choice for VB is rather a choice for a better syntax, a different way to
> write code that seems (at least to me) way ahead of the counterpart
> languages that still need arcane constructs like { } and begin/end to define
> block scope. A good coder is a good coder, period. As some wise man said
> once, if there's any kind of magic, it isn't in the language, but in the
> programmer.

Heh, yep! Totally agree with all that.

> Under the shadow of this unified framework, why would a language be given a
> fully loaded 12 bullets pistol while other must do with a one-bullet gun?
> I'm really a calm person, but this kind of decision just pisses me off...

It's arbitrary and gratuitous crippling of the language. Nothing more than that.

> So, things I'd like the VBfolks@MS should consider building in a, say,
> Microsoft.VisualBasic.Advanced namespace (and that would allow for IT
> managers to keep their children from messing with):
>
> a) Pointer as a first class data type
> b) Conditional structures (a la C UNIONS)
> c) Function/Sub/Property data types (commonly called "closures")
> d) Custom data types (to access those out-of-reach "unsigned longs", and the
> like)
> e) Inline toggles (so IIF-like functions could be more eficient)
> f) Shortcircuit boolean evaluation (ditto)
> g) Control of the alignment of UDT data
> h) The *full* set of bitwise operators
>
> Just to name a few, in this rainy saturday afternoon.

Sounds good to me! Have you written Microsoft, today?

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

I think they should write *VB* in VB! Damnit!!!
--
http://www.mvps.org/vb


"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in
message news:39b374b4$1@news.devx.com...
> Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
>
> Yep, no core product in VB. Although there are some peripheral components
> written in VB (espcially wizards!). It does prove *something*, IMHO.
>
> Is there anyone else who would like MS to take up the challenge implied
> here? To prove that the language is something that they believe is worth
> developing in? It does not have to be part of the VS7 box (that might be
> taking dogfood a bit to far) but it should be announced before VS hits the
> street that "Product Y is being written in VB.Net, etc., etc."
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
> "Alessandro Coppo" <a.coppo@iol.it> wrote in message
> news:39b33a59@news.devx.com...
> >
> > Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com> wrote
> in
> > message news:39b2e344@news.devx.com...
> > > It is worth noting what many others who have been at Microsoft have
> > > noted.... that most of the code it produces is in fact written in Visual
> > > C++, using its latest compiler at the time. One recent exception to this
> > is
> > > the parts of VC being written in C#.
> >
> > Given the annoucements, ASP+ is written in C# plus some assembler (pardon,
> > VC++) and Visual Studio NET is going the same way. Nothing relevant is
> > written in VB7 (at least it is not advertised). I think that the writing
> on
> > the wall could not be more clear.
> >
> > Bye!!!
> >
> >
>
>

[Michael \(michka\) Kaplan]

Well, as far as I know, VOLT is the biggest one I have seen. It was easy to
tell that it was written in VB without even using SPY, you can tell by the
error msgs that come up (very poor runtime error handling!).

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Mike" <myob@nospam.com> wrote in message news:39b54073$1@news.devx.com...
>
> Hmmmm... MS Money would be a good candidate for a VB only app. It's
amazing
> that not one of their commercial applications is a VB only app.
>
> Mike
>
> "Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote:
> >Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
> >
> >Yep, no core product in VB. Although there are some peripheral components
> >written in VB (espcially wizards!). It does prove *something*, IMHO.
> >
> >Is there anyone else who would like MS to take up the challenge implied
> >here? To prove that the language is something that they believe is worth
> >developing in? It does not have to be part of the VS7 box (that might be
> >taking dogfood a bit to far) but it should be announced before VS hits
the
> >street that "Product Y is being written in VB.Net, etc., etc."
> >
> >--
> >MichKa
> >
> >random junk of dubious value at the
> >multilingual http://www.trigeminal.com/ and
> >a new book on internationalization in VB at
> >http://www.i18nWithVB.com/
> >
> >"Alessandro Coppo" <a.coppo@iol.it> wrote in message
> >news:39b33a59@news.devx.com...
> >>
> >> Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> >in
> >> message news:39b2e344@news.devx.com...
> >> > It is worth noting what many others who have been at Microsoft have
> >> > noted.... that most of the code it produces is in fact written in
Visual
> >> > C++, using its latest compiler at the time. One recent exception to
> this
> >> is
> >> > the parts of VC being written in C#.
> >>
> >> Given the annoucements, ASP+ is written in C# plus some assembler
(pardon,
> >> VC++) and Visual Studio NET is going the same way. Nothing relevant is
> >> written in VB7 (at least it is not advertised). I think that the
writing
> >on
> >> the wall could not be more clear.
> >>
> >> Bye!!!
> >>
> >>
> >
> >
>

[Michael \(michka\) Kaplan]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b547c5@news.devx.com...
> I think they should write *VB* in VB! Damnit!!!

I agree.

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

[Karl E. Peterson]

Yeah, where's mattcur when you _really_ need him? <g>
--
http://www.mvps.org/vb


"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in
message news:39b55388@news.devx.com...
> "Karl E. Peterson" <karl@mvps.org> wrote in message
> news:39b547c5@news.devx.com...
> > I think they should write *VB* in VB! Damnit!!!
>
> I agree.
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
>
>

[Patrick Troughton Patrick]

VOLT?

/Pat

"Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote:
>Well, as far as I know, VOLT is the biggest one I have seen. It was easy
to
>tell that it was written in VB without even using SPY, you can tell by the
>error msgs that come up (very poor runtime error handling!).
>
>--
>MichKa

[Michael \(michka\) Kaplan]

Well, I doubt *he* would want to write VB. But if he could be in charge of
the necessary language features to make it happen, I'll bet him and several
others would be interested.

It is guaranteed to CHANGE the focus of Visual Basic if they shipped a
version that had their own development in mind (it certainly has shaped the
C compiler).

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b554fe@news.devx.com...
> Yeah, where's mattcur when you _really_ need him? <g>
> --
> http://www.mvps.org/vb
>
>
> "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote in
> message news:39b55388@news.devx.com...
> > "Karl E. Peterson" <karl@mvps.org> wrote in message
> > news:39b547c5@news.devx.com...
> > > I think they should write *VB* in VB! Damnit!!!
> >
> > I agree.
> >
> > --
> > MichKa
> >
> > random junk of dubious value at the
> > multilingual http://www.trigeminal.com/ and
> > a new book on internationalization in VB at
> > http://www.i18nWithVB.com/
> >
> >
> >
>
>

[Michael \(michka\) Kaplan]

The Visual OpenType Layout Tool, used by typography geeks (I am a 5%
typography geek, mainly because of my international interests) who want to
add OpenType layout tables to fonts.

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

<Patrick Troughton Patrick> wrote in message
news:39b55d9a$1@news.devx.com...
>
> VOLT?
>
> /Pat
>
> "Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote:
> >Well, as far as I know, VOLT is the biggest one I have seen. It was easy
> to
> >tell that it was written in VB without even using SPY, you can tell by
the
> >error msgs that come up (very poor runtime error handling!).
> >
> >--
> >MichKa
>
>

[Michael \(michka\) Kaplan]

They probably won't. :-(

But that one move would do more for VB than all the marketing in the world
can do right now. It would show an underlying confidence in VB.Net as a
development platform. I wish it would happen, I really do. The fact that it
probably won't is something that the members of the jury can reasonable
consider in their deliberations on the fate of VB.Net.

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Kevin Westhead" <dekurver@wickstead.screaming.net> wrote in message
news:39b3e7e5@news.devx.com...
> Yep, I agree. MS should take up the challenge you've described below.
> However, I suspect they won't. <bg>
>
> --
> Kevin Westhead
>
> "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> in message news:39b374b4$1@news.devx.com...
> > Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
> >
> > Yep, no core product in VB. Although there are some peripheral
components
> > written in VB (espcially wizards!). It does prove *something*, IMHO.
> >
> > Is there anyone else who would like MS to take up the challenge implied
> > here? To prove that the language is something that they believe is worth
> > developing in? It does not have to be part of the VS7 box (that might be
> > taking dogfood a bit to far) but it should be announced before VS hits
the
> > street that "Product Y is being written in VB.Net, etc., etc."
> >
> > --
> > MichKa
> >
> > random junk of dubious value at the
> > multilingual http://www.trigeminal.com/ and
> > a new book on internationalization in VB at
> > http://www.i18nWithVB.com/
> >
> > "Alessandro Coppo" <a.coppo@iol.it> wrote in message
> > news:39b33a59@news.devx.com...
> > >
> > > Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
> wrote
> > in
> > > message news:39b2e344@news.devx.com...
> > > > It is worth noting what many others who have been at Microsoft have
> > > > noted.... that most of the code it produces is in fact written in
> Visual
> > > > C++, using its latest compiler at the time. One recent exception to
> this
> > > is
> > > > the parts of VC being written in C#.
> > >
> > > Given the annoucements, ASP+ is written in C# plus some assembler
> (pardon,
> > > VC++) and Visual Studio NET is going the same way. Nothing relevant is
> > > written in VB7 (at least it is not advertised). I think that the
writing
> > on
> > > the wall could not be more clear.
> > >
> > > Bye!!!
> > >
> > >
> >
> >
>
>

[Alan Carter [MSFT]]

The VB team has written the VB runtime functions (Left, PV, Dir, etc. etc.)
in VB.NET.

We strongly feel that the choice between C# and VB should be made based on
your experience -- if you are more comfortable writing in VB today then you
will be more confortable in using VB.NET when developing for the .NET
platform; if you are more comfortable writing in C++ today then you will be
more comfortable using C# when developing for the .NET platform. ASP+ was
written in C# because the developers were previously C++ programmers.

So with that said, we are very interested in reasons why, if you prefer
using VB today, why you think VB.NET will not be your preferred language in
the future. The reason raised in this thread is because VB.NET does not
currently have built-in support for direct memory access. Believe me, I'll
pass this on to other folks on our team and look for ways to fix this. We
definitely did not leave support for this out of the language because we
felt that VB programmers are not capable of using the feature. We know that
VarPtr and related functions are often used today and that free threaded can
be much more complex to use successfully than direct memory access.

Another comment expressed earlier is that we didn't do sufficient clean-up
of the language. Please let me know specifically what you think needs to be
cleaned up.

Thanks much for the feedback on VarPtr. I want to make sure that folks who
have preferences for VB can continue to use it in the future. If on the
other hand you prefer C-style syntax then you will certainly be happier with
C#.

Alan Carter
Microsoft

"Mike" <myob@nospam.com> wrote in message news:39b54073$1@news.devx.com...
>
> Hmmmm... MS Money would be a good candidate for a VB only app. It's
amazing
> that not one of their commercial applications is a VB only app.
>
> Mike
>
> "Michael \(michka\) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote:
> >Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
> >
> >Yep, no core product in VB. Although there are some peripheral components
> >written in VB (espcially wizards!). It does prove *something*, IMHO.
> >
> >Is there anyone else who would like MS to take up the challenge implied
> >here? To prove that the language is something that they believe is worth
> >developing in? It does not have to be part of the VS7 box (that might be
> >taking dogfood a bit to far) but it should be announced before VS hits
the
> >street that "Product Y is being written in VB.Net, etc., etc."
> >
> >--
> >MichKa
> >
> >random junk of dubious value at the
> >multilingual http://www.trigeminal.com/ and
> >a new book on internationalization in VB at
> >http://www.i18nWithVB.com/
> >
> >"Alessandro Coppo" <a.coppo@iol.it> wrote in message
> >news:39b33a59@news.devx.com...
> >>
> >> Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> >in
> >> message news:39b2e344@news.devx.com...
> >> > It is worth noting what many others who have been at Microsoft have
> >> > noted.... that most of the code it produces is in fact written in
Visual
> >> > C++, using its latest compiler at the time. One recent exception to
> this
> >> is
> >> > the parts of VC being written in C#.
> >>
> >> Given the annoucements, ASP+ is written in C# plus some assembler
(pardon,
> >> VC++) and Visual Studio NET is going the same way. Nothing relevant is
> >> written in VB7 (at least it is not advertised). I think that the
writing
> >on
> >> the wall could not be more clear.
> >>
> >> Bye!!!
> >>
> >>
> >
> >
>

[Zane Thomas]

On Tue, 5 Sep 2000 17:05:14 -0700, "Alan Carter [MSFT]"
<alanc@microsoft.com> wrote:

>The reason raised in this thread is because VB.NET does not
>currently have built-in support for direct memory access.

Don't add it - I can sell a component that does that. :-)



---
Z

You're just mad because the voices don't talk to you.

[Corrado Cavalli]

My opinion is that VB.NET will be a large shift from previous version, not
only from coding style but also from IDE manipulation, so the obvious dilemma
for a VB programmer would be: "Having to learn so much, can this be the occasion
for start learning a 'more complete language'? like C#" this, of course,in
the case that VB.NET will be, as previous versions were, a "productive but
never complete language".
I agree with previous posts, this is the 1st time Microsoft spend some time
listening to their tools users.

Regards
Corrado Cavalli
ALSTOM

[Rob Jolt]

"Alan Carter [MSFT]" <alanc@microsoft.com> wrote in message
news:39b58803@news.devx.com...
> So with that said, we are very interested in reasons why, if you prefer
> using VB today, why you think VB.NET will not be your preferred language
in
> the future. The reason raised in this thread is because VB.NET does not

We expected VB7 but what we're getting is C# with VB syntax, and a limited
version at that. Mixed up where we expected grown up. VB.NET is changing
fundamental aspects of VB6 that brings about almost as many issues as moving
to a new language would. If this is the case, why _not_ move on to the
new/cool/better C# or some respectable platform/language that doesn't
undergo a code-breaking overhaul every 3 versions?

Let's face it, VB is often perceived as not being a "real" language. If an
acceptable alternative were available many would have left long ago. So if
the choice now becomes one of preference, who wants to choose the one that
is looked down upon by the rest? People are disappointed that VB.NET wasn't
being called 'B#' only for hope of losing some of the 'VB' stigma. MS's
internal use of C# for almost all of .NET (and the support that implies)
doesn't exactly alleviate concerns of VB.NET's future.

So I have to retrain staff, rework code, distribute a larger runtime,
subject code to easy decompilation, lose capabilities, and become
"locked-in" to .NET just to keep the same old beginner language that is less
capable than the brand new one. Forgive me if I feel a little slighted and
pause to consider alternatives.

[James D. Foxall]

I think this is a GREAT idea MichKa.

By the way, make life easier on us all add that **** T to your name please!
<vbg>

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
in message news:39b374b4$1@news.devx.com...
> Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
>
> Yep, no core product in VB. Although there are some peripheral components
> written in VB (espcially wizards!). It does prove *something*, IMHO.
>
> Is there anyone else who would like MS to take up the challenge implied
> here? To prove that the language is something that they believe is worth
> developing in? It does not have to be part of the VS7 box (that might be
> taking dogfood a bit to far) but it should be announced before VS hits the
> street that "Product Y is being written in VB.Net, etc., etc."
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
> "Alessandro Coppo" <a.coppo@iol.it> wrote in message
> news:39b33a59@news.devx.com...
> >
> > Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> in
> > message news:39b2e344@news.devx.com...
> > > It is worth noting what many others who have been at Microsoft have
> > > noted.... that most of the code it produces is in fact written in
Visual
> > > C++, using its latest compiler at the time. One recent exception to
this
> > is
> > > the parts of VC being written in C#.
> >
> > Given the annoucements, ASP+ is written in C# plus some assembler
(pardon,
> > VC++) and Visual Studio NET is going the same way. Nothing relevant is
> > written in VB7 (at least it is not advertised). I think that the writing
> on
> > the wall could not be more clear.
> >
> > Bye!!!
> >
> >
>
>

[James D. Foxall]

Corrado has pretty much nailed it with this comment. I'm already getting
asked this question and I still don't feel comfortable answering it.

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

"Corrado Cavalli" <corradocavalli@tin.it> wrote in message
news:39b5e3f6$1@news.devx.com...
>
> My opinion is that VB.NET will be a large shift from previous version, not
> only from coding style but also from IDE manipulation, so the obvious
dilemma
> for a VB programmer would be: "Having to learn so much, can this be the
occasion
> for start learning a 'more complete language'? like C#" this, of course,in
> the case that VB.NET will be, as previous versions were, a "productive but
> never complete language".
> I agree with previous posts, this is the 1st time Microsoft spend some
time
> listening to their tools users.
>
> Regards
> Corrado Cavalli
> ALSTOM

[James D. Foxall]

I agree.

And gee Karl, I didn't know you were a Pink Floyd fan. ****, it will be
harder to argue with you know. :)

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com


"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b547c5@news.devx.com...
> I think they should write *VB* in VB! Damnit!!!
> --
> http://www.mvps.org/vb
>
>
> "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote in
> message news:39b374b4$1@news.devx.com...
> > Ah, sorry about the typo, I meant parts of VS, not VC, in that sentence.
> >
> > Yep, no core product in VB. Although there are some peripheral
components
> > written in VB (espcially wizards!). It does prove *something*, IMHO.
> >
> > Is there anyone else who would like MS to take up the challenge implied
> > here? To prove that the language is something that they believe is worth
> > developing in? It does not have to be part of the VS7 box (that might be
> > taking dogfood a bit to far) but it should be announced before VS hits
the
> > street that "Product Y is being written in VB.Net, etc., etc."
> >
> > --
> > MichKa
> >
> > random junk of dubious value at the
> > multilingual http://www.trigeminal.com/ and
> > a new book on internationalization in VB at
> > http://www.i18nWithVB.com/
> >
> > "Alessandro Coppo" <a.coppo@iol.it> wrote in message
> > news:39b33a59@news.devx.com...
> > >
> > > Michael (michka) Kaplan <former_mvp@spamfree.trigeminal.nospam.com>
wrote
> > in
> > > message news:39b2e344@news.devx.com...
> > > > It is worth noting what many others who have been at Microsoft have
> > > > noted.... that most of the code it produces is in fact written in
Visual
> > > > C++, using its latest compiler at the time. One recent exception to
this
> > > is
> > > > the parts of VC being written in C#.
> > >
> > > Given the annoucements, ASP+ is written in C# plus some assembler
(pardon,
> > > VC++) and Visual Studio NET is going the same way. Nothing relevant is
> > > written in VB7 (at least it is not advertised). I think that the
writing
> > on
> > > the wall could not be more clear.
> > >
> > > Bye!!!
> > >
> > >
> >
> >
>
>

[Karl E. Peterson]

Hi Michka --

Regarding MS writing a major app with VB.Net:

> But that one move would do more for VB than all the marketing in the world
> can do right now. It would show an underlying confidence in VB.Net as a
> development platform. I wish it would happen, I really do. The fact that it
> probably won't is something that the members of the jury can reasonable
> consider in their deliberations on the fate of VB.Net.

Of *course* it won't happen.

A) Microsoft *knows* that the language is scheduled to be completely hosed every
three versions or five years, whichever comes first.

B) Microsoft routinely relies on 10-year old code (try using the vbSystemModal
message box style in VB4/16 on Win98!).

Not even Microsoft can afford to invest in a language that isn't nominally stable.
Who could? <deep sigh>

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Zane --

> On Tue, 5 Sep 2000, "Alan Carter [MSFT]" <alanc@microsoft.com> wrote:
>
> >The reason raised in this thread is because VB.NET does not
> >currently have built-in support for direct memory access.
>
> Don't add it - I can sell a component that does that. :-)

And we could use the CharNext API to get a pointer as well. But that doesn't negate
the reason they removed these functions in the first place. Presumably, they're
shifting stuff around in memory, on the fly. I'd bet stashing an ObjPtr won't be a
wise idea in the future, unless Alan & Co. perform some major architectural tweaking.

Later... Karl

[Karl E. Peterson]

Hi James --

> > I think they should write *VB* in VB! Damnit!!!
>
> I agree.

Have you written Microsoft today? <g>

> And gee Karl, I didn't know you were a Pink Floyd fan. ****, it will be
> harder to argue with you know. :)

Heh, we *will* assimilate you. ;-)

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Alan --

> The VB team has written the VB runtime functions (Left, PV, Dir, etc. etc.)
> in VB.NET.

That's actually somewhat discouraging. Given you couldn't use pointers to fully
optimize them, the suspicion would have to be that the performance will be no where
near that of previous runtimes. That's certainly what other language
(C/Delphi/PowerBasic) proponents will be quick to point out, isn't it?

> We strongly feel that the choice between C# and VB should be made based on
> your experience -- if you are more comfortable writing in VB today then you
> will be more confortable in using VB.NET when developing for the .NET
> platform;

This is a good strategy and I'm happy you feel that way, but it's fundamentally
flawed in that VB.NET is seriously crippled when compared to VB5/6. IOW, it's a
major step down, besides being a new language (similarities aside).

> So with that said, we are very interested in reasons why, if you prefer
> using VB today, why you think VB.NET will not be your preferred language in
> the future.

On the philosophical side of this issue is the utter disrespect being shown on this
whole initiative. Microsoft is using VB developers as the pawns in their battle with
Sun. After watching VID fail miserably, and being pummeled in court over Java, the
decision was made to "just rewrite Java but call it VB.NET -- we can claim 4 million
developers overnight."

The technical issues are many. But what they all boil down to is the simple fact
that, once again, Microsoft is proving an investment in VB to be folly. That you're
willing to nonchalantly discard the billions and billions of lines of VB code, and
tell the millions of VB developers to "just start over" is mind-boggling. That
you're making the language *less* capable simultaneously only adds insult to injury.
If(!) the final result was a "real language", I submit we'd all swallow hard, and
move on. Sadly, that's not what you're offering us.

You _are_ perpetuating the myth that VB can't be used for serious development. And
it won't be, either. Not in the currently envisioned next incarnation. That's a
script-kiddies tool. It's an attempt to chase a passing fad. Business rules are
*not* fads, however. They have lasting value, and there's no excuse for telling
folks to rewrite them because they don't "look as good" (the final answer offered by
another 'Softie on why try/catch is better than On Error).

> The reason raised in this thread is because VB.NET does not
> currently have built-in support for direct memory access. Believe me, I'll
> pass this on to other folks on our team and look for ways to fix this.

Thank you!

> We
> definitely did not leave support for this out of the language because we
> felt that VB programmers are not capable of using the feature.

Has anyone articulated *why* it was dropped? We're reasonable people. Really. <g>
Tell us, and maybe we can at least be closer to seeing eye-to-eye on this insult.

> We know that
> VarPtr and related functions are often used today and that free threaded can
> be much more complex to use successfully than direct memory access.

Indeed. Other high-priority technical issues that will need to be addressed are:

* Deterministic finalization
* Redefinition of native variable types (bit doubling)

> Another comment expressed earlier is that we didn't do sufficient clean-up
> of the language. Please let me know specifically what you think needs to be
> cleaned up.

I think that's sarcasm running rampant again. When we hear that certain things were
kept to maintain "backward compatability", **** few options remain but to laugh
(given we're through the denial/grief stages, and crying is no longer appropriate).

So, you're pretty much hearing, "Hey! You wrote a new language and gave it an old
name! Why didn't you give it a new name, and totally remove the last vestiges of the
old language, rather than leave a token few to be snickered at by C# programmers in
the future?"

> Thanks much for the feedback on VarPtr. I want to make sure that folks who
> have preferences for VB can continue to use it in the future.

Thank _you_ very much! That sounds very sincere. "I want to believe." :-)

Thanks... Karl
--
http://www.mvps.org/vb

[Patrick Troughton Patrick]

"Karl E. Peterson" <karl@mvps.org> wrote:
>> Another comment expressed earlier is that we didn't do sufficient clean-up
>> of the language. Please let me know specifically what you think needs
to be
>> cleaned up.
>
>I think that's sarcasm running rampant again.

I disagree. I honestly believe that VB run will better off (especially in
the long run) if it is purified and simplified. For example, why have two
completely different syntaxes for returning a value in a function?

'syntax one (old style)
Function MyFunction() As Long
Dim lngResult As Long
...
...
...
MyFunction = lngResult
End Function

'syntax two (new style)
Function MyFunction() As Long
Dim lngResult As Long
...
...
...
Return lngResult
End Function

I see no advantage in having two completely different syntaxes for doing
the exact same thing. The only reason I can see to keep using syntax one
is for backwards compatibility BUT we've already lost that. Who are we kidding?
To me, the spirit of the BASIC language is simplicity. If we're all going
to have to rewrite our code anyway, let's go all the way and do it right.

/Pat

[Larry Serflaten]

"Karl E. Peterson" <karl@mvps.org> wrote in message news:39b6a01f@news.devx.com...

Good points Karl, but I keep hoping they will make changes to the language to
make it more robust.

> The technical issues are many. But what they all boil down to is the simple fact
> that, once again, Microsoft is proving an investment in VB to be folly. That you're
> willing to nonchalantly discard the billions and billions of lines of VB code, and
> tell the millions of VB developers to "just start over" is mind-boggling. That
> you're making the language *less* capable simultaneously only adds insult to injury.
> If(!) the final result was a "real language", I submit we'd all swallow hard, and
> move on. Sadly, that's not what you're offering us.

Will this not be similar to the shift from 16 to 32 bit API? Could there not be a
migration tool to assist in transposing the old code to the new format? (One which
leaves very litlle left 'ToDo')

The result I am looking for is the 'real language', I care less about how we get there.

LFS

[Zane Thomas]

On Wed, 6 Sep 2000 11:52:40 -0700, "Karl E. Peterson" <karl@mvps.org>
wrote:

>Presumably, they're
>shifting stuff around in memory, on the fly.

Depends what kind of g-c they're using. One which allows moving things
around on the fly would probably require double-indirection, which has
efficiency problems. One alternative is to have pools of various sizes,
things are allocated to an appropriate pool and when freed the slot
becomes available again. There are numerous other approaches. I knew a
lot about that stuff when I was doing scheme (lisp) implementations, but
that was a long long time ago. :-)





---
Z

You're just mad because the voices don't talk to you.

[Michael \(michka\) Kaplan]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b68f73$1@news.devx.com...
> Who could? <deep sigh>

Yes, the crux of it. but you know something? We can. We are the ones who buy
Word 95, or Access 95, or VB4, or Access 2000, or whatever crap is slung at
us.

We are not just sheep. We ARE lemmings.

<deeper sigh>

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

[Karl E. Peterson]

Hi Larry --

> Good points Karl, but I keep hoping they will make changes to the language to
> make it more robust.

<aol>Me too!</aol>

> > The technical issues are many. But what they all boil down to is the simple fact
> > that, once again, Microsoft is proving an investment in VB to be folly. That
you're
> > willing to nonchalantly discard the billions and billions of lines of VB code,
and
> > tell the millions of VB developers to "just start over" is mind-boggling. That
> > you're making the language *less* capable simultaneously only adds insult to
injury.
> > If(!) the final result was a "real language", I submit we'd all swallow hard, and
> > move on. Sadly, that's not what you're offering us.
>
> Will this not be similar to the shift from 16 to 32 bit API?

In some ways, sure. We'll need to rewrite everything. The main difference this time
is that the rewrite is necessitated by marketing purposes, not technical ones. That
doesn't sit well. No one argumed that moving to 32-bits was a silly thing. One is
well-justified in the argument that they shouldn't be used as a weapon in MS
legal/dominance battles.

> Could there not be a
> migration tool to assist in transposing the old code to the new format? (One which
> leaves very litlle left 'ToDo')

They're proposing one. No sane person who's actually compared functionally
equivalent code from VB5/6 and VB7 seriously believes this doable. Just as a
"little" example, how's this tool to cope with the loss of persistable ObjPtr's used
in subclassing notfications?

> The result I am looking for is the 'real language', I care less about how we get
there.

Agreed. I could toss all my "libraried" code, if I thought we'd get that in return.

Later... Karl

[Karl E. Peterson]

Hi Pat --

I _can_ see that side of it, too. Just trying to be nice about it. :-)

Later... Karl
--
http://www.mvps.org/vb


<Patrick Troughton Patrick> wrote in message news:39b6afe8$1@news.devx.com...
>
> "Karl E. Peterson" <karl@mvps.org> wrote:
> >> Another comment expressed earlier is that we didn't do sufficient clean-up
> >> of the language. Please let me know specifically what you think needs
> to be
> >> cleaned up.
> >
> >I think that's sarcasm running rampant again.
>
> I disagree. I honestly believe that VB run will better off (especially in
> the long run) if it is purified and simplified. For example, why have two
> completely different syntaxes for returning a value in a function?
>
> 'syntax one (old style)
> Function MyFunction() As Long
> Dim lngResult As Long
> ...
> ...
> ...
> MyFunction = lngResult
> End Function
>
> 'syntax two (new style)
> Function MyFunction() As Long
> Dim lngResult As Long
> ...
> ...
> ...
> Return lngResult
> End Function
>
> I see no advantage in having two completely different syntaxes for doing
> the exact same thing. The only reason I can see to keep using syntax one
> is for backwards compatibility BUT we've already lost that. Who are we kidding?
> To me, the spirit of the BASIC language is simplicity. If we're all going
> to have to rewrite our code anyway, let's go all the way and do it right.
>
> /Pat
>

[Karl E. Peterson]

Well, you and I personally get paid to help others do it, so we're more like lemming
sheperders, or something. <g>
--
http://www.mvps.org/vb



"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in
message news:39b6bc7a@news.devx.com...
> "Karl E. Peterson" <karl@mvps.org> wrote in message
> news:39b68f73$1@news.devx.com...
> > Who could? <deep sigh>
>
> Yes, the crux of it. but you know something? We can. We are the ones who buy
> Word 95, or Access 95, or VB4, or Access 2000, or whatever crap is slung at
> us.
>
> We are not just sheep. We ARE lemmings.
>
> <deeper sigh>
>
> --
> MichKa
>
> random junk of dubious value at the
> multilingual http://www.trigeminal.com/ and
> a new book on internationalization in VB at
> http://www.i18nWithVB.com/
>
>
>

[Karl E. Peterson]

Hi Zane --

> >Presumably, they're
> >shifting stuff around in memory, on the fly.
>
> Depends what kind of g-c they're using. One which allows moving things
> around on the fly would probably require double-indirection, which has
> efficiency problems. One alternative is to have pools of various sizes,
> things are allocated to an appropriate pool and when freed the slot
> becomes available again. There are numerous other approaches. I knew a
> lot about that stuff when I was doing scheme (lisp) implementations, but
> that was a long long time ago. :-)

Then, and now, you know far more about it than I! If it were as simple as
re-exposing the entry points, I think this discussion would've ended long ago.
There's either something A) architecturally, or B) politically, blocking the return
of the *Ptr functions. If B, your component idea would fly. I sense A, though.

Later... Karl
--
http://www.mvps.org/vb

[Kevin Westhead]

It would be nice to "know" rather than having to "sense". <g> How about
putting us out of our misery MS?

--
Kevin Westhead

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b6c114$1@news.devx.com...
> Hi Zane --
>
> > >Presumably, they're
> > >shifting stuff around in memory, on the fly.
> >
> > Depends what kind of g-c they're using. One which allows moving things
> > around on the fly would probably require double-indirection, which has
> > efficiency problems. One alternative is to have pools of various sizes,
> > things are allocated to an appropriate pool and when freed the slot
> > becomes available again. There are numerous other approaches. I knew a
> > lot about that stuff when I was doing scheme (lisp) implementations, but
> > that was a long long time ago. :-)
>
> Then, and now, you know far more about it than I! If it were as simple as
> re-exposing the entry points, I think this discussion would've ended long
ago.
> There's either something A) architecturally, or B) politically, blocking
the return
> of the *Ptr functions. If B, your component idea would fly. I sense A,
though.
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>
>
>
>

[Jeff Peil]

I don't necessarily agree here, that its pure marketing. MS really had 2
choices regarding .NET integration, either go the MC++ route and support
..NET with restrictions (code cannot be verified as safe, etc.) or take the
plunge completely. .NET does address some very real issues, such as
security, that aren't necessarily a huge deal for our code today, but will
be going forward.

So you have to ask yourself, would you prefer VB.NET to be a 2nd class .NET
citizen, or a 2nd class VB. Clearly MS believes that .NET is their future,
in that light, the VB team's choice makes a fair amount of sense (from their
perspective.)

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b6bcd2$1@news.devx.com...
[snip]
> In some ways, sure. We'll need to rewrite everything. The main
difference this time
> is that the rewrite is necessitated by marketing purposes, not technical
ones. That
> doesn't sit well. No one argumed that moving to 32-bits was a silly
thing. One is
> well-justified in the argument that they shouldn't be used as a weapon in
MS
> legal/dominance battles.
[snip]

[Zane Thomas]

On Wed, 6 Sep 2000 15:19:49 -0700, "Karl E. Peterson" <karl@mvps.org>
wrote:

>B) politically, blocking the return
>of the *Ptr functions

Bingo! :-)



---
Z

You're just mad because the voices don't talk to you.

[Michael \(michka\) Kaplan]

I prefer to cast myself as the one who shows them why they do not have to
jump.

And now I show them how to do it for the sake of people all over the world.
:-)

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b6c09c$1@news.devx.com...
> Well, you and I personally get paid to help others do it, so we're more
like lemming
> sheperders, or something. <g>
> --
> http://www.mvps.org/vb
>
>
>
> "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com>
wrote in
> message news:39b6bc7a@news.devx.com...
> > "Karl E. Peterson" <karl@mvps.org> wrote in message
> > news:39b68f73$1@news.devx.com...
> > > Who could? <deep sigh>
> >
> > Yes, the crux of it. but you know something? We can. We are the ones who
buy
> > Word 95, or Access 95, or VB4, or Access 2000, or whatever crap is slung
at
> > us.
> >
> > We are not just sheep. We ARE lemmings.
> >
> > <deeper sigh>
> >
> > --
> > MichKa
> >
> > random junk of dubious value at the
> > multilingual http://www.trigeminal.com/ and
> > a new book on internationalization in VB at
> > http://www.i18nWithVB.com/
> >
> >
> >
>
>

[Karl E. Peterson]

Hi Zane --

> >B) politically, blocking the return
> >of the *Ptr functions
>
> Bingo! :-)

Yeeeeee-owch!!!

Alan? Paul? Inquiring minds, y'know...

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Jeff --

> I don't necessarily agree here, that its pure marketing. MS really had 2
> choices regarding .NET integration, either go the MC++ route and support
> .NET with restrictions (code cannot be verified as safe, etc.) or take the
> plunge completely.

What's with this "verified as safe" business, anyway? Pointers aren't safe? I just
don't get that. I'd say the marketeers have you completely hoodwinked, if you're
tossing around terms like that.

> So you have to ask yourself, would you prefer VB.NET to be a 2nd class .NET
> citizen, or a 2nd class VB.

It's both, so I guess I miss your point?

> Clearly MS believes that .NET is their future,

Yep. Sell your stock now. <g>

Later... Karl
--
http://www.mvps.org/vb

[James D. Foxall]

I (hate to) think you're probably right. It doesn't make sense otherwise.

I also hate it when Microsoft pretty much says that choosing C# over VB.Net
really comes down to picking your flavor. In order for this to be true, they
MUST have the same capabilities. I can't believe that with the CLR and
common IDE (and many thanks to VB for all of the great IDE stuff) they're
still <deliberately> limiting the functionality of Visual Basic.

ARRRGH!

--

James D. Foxall

I can't code in C, only VB
so by golly,
stop picking on me!

I sure with MS would let me be a 'real' programmer for a change. <vbg>


"Zane Thomas" <zane@mabry.com> wrote in message
news:39d4fd36.514815886@news.devx.com...
> On Wed, 6 Sep 2000 15:19:49 -0700, "Karl E. Peterson" <karl@mvps.org>
> wrote:
>
> >B) politically, blocking the return
> >of the *Ptr functions
>
> Bingo! :-)
>
>
>
> ---
> Z
>
> You're just mad because the voices don't talk to you.

[Jeff Peil]

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b7f61b$1@news.devx.com...
> Hi Jeff --
>
> > I don't necessarily agree here, that its pure marketing. MS really had
2
> > choices regarding .NET integration, either go the MC++ route and support
> > .NET with restrictions (code cannot be verified as safe, etc.) or take
the
> > plunge completely.
>
> What's with this "verified as safe" business, anyway? Pointers aren't
safe? I just
> don't get that. I'd say the marketeers have you completely hoodwinked, if
you're
> tossing around terms like that.

Karl,

Fundamentally code that manipulates pointers can do things that will violate
the security model in .NET. I'm speaking at the IL level, there is a subset
of things that you can do that the runtime verifier can verify as safe
(security wise.) Perhaps you should actually read the specs on IL and the
EE before you accuse me of being hoodwinked.

[Jeff Peil]

Just to further clarify,

I wasn't saying that alot of it isn't marketing, nor was I saying that
VB.NET shouldn't have an equivilient to C#'s unsafe keyword, and pointers.

I should also add, I'm probably alot less emotionally involved in the
subject when it comes to lost functionality/backwards compatibility of
VB.NET as I personally am in the C++/C# camp, and I am not a heavy VB user.

I think people who have invested heavily in previous versions of VB have
every right to feel a bit upset and betrayed. That said, I do not think
that MS is intentionally out to hurt any VB customers.

As to the VB.NET being a 2nd class citizen, I disagree with you, MC++ is a
2nd class citizen in .NET, you cannot write a .NET assembly in MC++ that
will run without high trus permissions on the client, where both VB.NET and
C#.NET can.

If VB.NET was more compatible with VB6 (to the point no significant changes
would be needed to port legacy code) I think some people would be screaming
about the fact that VB.NET made generating interoperable code too difficult,
and even when you could generate interoperable code, the level of trust
required for vb assemblies was too high.

"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39b8377c$1@news.devx.com...
>
> "Karl E. Peterson" <karl@mvps.org> wrote in message
> news:39b7f61b$1@news.devx.com...
> > Hi Jeff --
> >
> > > I don't necessarily agree here, that its pure marketing. MS really
had
> 2
> > > choices regarding .NET integration, either go the MC++ route and
support
> > > .NET with restrictions (code cannot be verified as safe, etc.) or take
> the
> > > plunge completely.
> >
> > What's with this "verified as safe" business, anyway? Pointers aren't
> safe? I just
> > don't get that. I'd say the marketeers have you completely hoodwinked,
if
> you're
> > tossing around terms like that.
>
> Karl,
>
> Fundamentally code that manipulates pointers can do things that will
violate
> the security model in .NET. I'm speaking at the IL level, there is a
subset
> of things that you can do that the runtime verifier can verify as safe
> (security wise.) Perhaps you should actually read the specs on IL and the
> EE before you accuse me of being hoodwinked.
>
>

[Michael \(michka\) Kaplan]

I think this is a myth.

People are a LOT more interested in working with like things than unlike
things. Compatibility with C++ or COBOL of whatever is a LOT less
interesting that compatibility with what you have already done. People in VB
have NEVER asked for syntax compability or anything of that sort.... they
just wanted functional parity with other languages. Because if VB can do
everything other languages can, then they can just force people who claim
its a toy language to shut the **** up.

Well now, they will be too busy ramping up, dumping old code, and having to
relearn Visual Fred to be telling anyone to shut up.

--
MichKa

random junk of dubious value at the
multilingual http://www.trigeminal.com/ and
a new book on internationalization in VB at
http://www.i18nWithVB.com/

"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39b83b5c$1@news.devx.com...
> Just to further clarify,
>
> I wasn't saying that alot of it isn't marketing, nor was I saying that
> VB.NET shouldn't have an equivilient to C#'s unsafe keyword, and pointers.
>
> I should also add, I'm probably alot less emotionally involved in the
> subject when it comes to lost functionality/backwards compatibility of
> VB.NET as I personally am in the C++/C# camp, and I am not a heavy VB
user.
>
> I think people who have invested heavily in previous versions of VB have
> every right to feel a bit upset and betrayed. That said, I do not think
> that MS is intentionally out to hurt any VB customers.
>
> As to the VB.NET being a 2nd class citizen, I disagree with you, MC++ is a
> 2nd class citizen in .NET, you cannot write a .NET assembly in MC++ that
> will run without high trus permissions on the client, where both VB.NET
and
> C#.NET can.
>
> If VB.NET was more compatible with VB6 (to the point no significant
changes
> would be needed to port legacy code) I think some people would be
screaming
> about the fact that VB.NET made generating interoperable code too
difficult,
> and even when you could generate interoperable code, the level of trust
> required for vb assemblies was too high.
>
> "Jeff Peil" <jpeil@bigfoot.com> wrote in message
> news:39b8377c$1@news.devx.com...
> >
> > "Karl E. Peterson" <karl@mvps.org> wrote in message
> > news:39b7f61b$1@news.devx.com...
> > > Hi Jeff --
> > >
> > > > I don't necessarily agree here, that its pure marketing. MS really
> had
> > 2
> > > > choices regarding .NET integration, either go the MC++ route and
> support
> > > > .NET with restrictions (code cannot be verified as safe, etc.) or
take
> > the
> > > > plunge completely.
> > >
> > > What's with this "verified as safe" business, anyway? Pointers aren't
> > safe? I just
> > > don't get that. I'd say the marketeers have you completely
hoodwinked,
> if
> > you're
> > > tossing around terms like that.
> >
> > Karl,
> >
> > Fundamentally code that manipulates pointers can do things that will
> violate
> > the security model in .NET. I'm speaking at the IL level, there is a
> subset
> > of things that you can do that the runtime verifier can verify as safe
> > (security wise.) Perhaps you should actually read the specs on IL and
the
> > EE before you accuse me of being hoodwinked.
> >
> >
>
>

[Larry Serflaten]

How can they support pointers, and still provide a safe operating environment?
Lets say, (for example!) that location 0x0000 and 0x0001 point to the top of the VB
runtime stack. Then along comes Beetle Bailey declaring his pointer but forgeting
to initialize it before stuffing a value in the referenced address. Because (being a value
type variable) it is intialized to 0, Beetle has just changed VB runtime's pointer to its
own stack. Perhaps this will help clarify:

From http://msdn.microsoft.com/msdnmag/issues/1000/Framework2/Framework2.asp

"Type-safe programs reference only memory that has been allocated for their use and access objects only through their exposed
interfaces. From a security standpoint, referencing only designated memory allows multiple objects to safely share a single address
space. Accessing objects only through their exposed interfaces guarantees that security checks associated with specific interfaces
are not circumvented.
The common language runtime ensures type safety by combining strong typing in the metadata (parameters, members and array elements,
return values of methods, and static values) with strong typing in the MSIL (local variables and stack slots). This provides a basis
for automatically verifying the type safety of programs written in MSIL, independent of the language that produced them. By default,
all code loaded by the .NET common language runtime requires verification before it is allowed to run. "

This also addresses a later question about what is meant by 'verified' or 'unverified' code.

Somehow, a pointer is going to have to have limitations placed upon it to be
declared safe. Otherwise, any use of pointers would mean non-verifiable assemblies.
But if any part of your Basic program cannot be declared safe, then that goes against
one of the underlying design principles of having at least one 'safe' language to write
code from.

So again, I would introduce the notion that we need to let MS know that, yes
safety is important for a learner's edition/version, but we all desire a professional
language (including all the capabilities of the CLR and IL code) that has syntax
like Visual Basic.

LFS


"Karl E. Peterson" <karl@mvps.org> wrote in message news:39b7d995$1@news.devx.com...
> Hi Zane --
>
> > >B) politically, blocking the return
> > >of the *Ptr functions
> >
> > Bingo! :-)
>
> Yeeeeee-owch!!!
>
> Alan? Paul? Inquiring minds, y'know...
>
> Later... Karl

[Rob Jolt]

"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39b83b5c$1@news.devx.com...

> If VB.NET was more compatible with VB6 (to the point no significant
changes
> would be needed to port legacy code) I think some people would be
screaming
> about the fact that VB.NET made generating interoperable code too
difficult,
> and even when you could generate interoperable code, the level of trust
> required for vb assemblies was too high.

I certainly would be one of those screaming <g> given a single option, but
what about having both options like the C++/C# camp. Now I just have broken
code and Visual Fred. <sigh>

[Karl E. Peterson]

Hi Larry --

Feel the force, Larry. Don't let the Dark Side consume you. <deep sigh>

Safety is a marketing term. I don't accept it.

Later... Karl
--
http://www.mvps.org/vb


"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:39b89fc5@news.devx.com...
> How can they support pointers, and still provide a safe operating environment?
> Lets say, (for example!) that location 0x0000 and 0x0001 point to the top of the VB
> runtime stack. Then along comes Beetle Bailey declaring his pointer but forgeting
> to initialize it before stuffing a value in the referenced address. Because (being
a value
> type variable) it is intialized to 0, Beetle has just changed VB runtime's pointer
to its
> own stack. Perhaps this will help clarify:
>
> From http://msdn.microsoft.com/msdnmag/issues/1000/Framework2/Framework2.asp
>
> "Type-safe programs reference only memory that has been allocated for their use and
access objects only through their exposed
> interfaces. From a security standpoint, referencing only designated memory allows
multiple objects to safely share a single address
> space. Accessing objects only through their exposed interfaces guarantees that
security checks associated with specific interfaces
> are not circumvented.
> The common language runtime ensures type safety by combining strong typing in the
metadata (parameters, members and array elements,
> return values of methods, and static values) with strong typing in the MSIL (local
variables and stack slots). This provides a basis
> for automatically verifying the type safety of programs written in MSIL,
independent of the language that produced them. By default,
> all code loaded by the .NET common language runtime requires verification before it
is allowed to run. "
>
> This also addresses a later question about what is meant by 'verified' or
'unverified' code.
>
> Somehow, a pointer is going to have to have limitations placed upon it to be
> declared safe. Otherwise, any use of pointers would mean non-verifiable
assemblies.
> But if any part of your Basic program cannot be declared safe, then that goes
against
> one of the underlying design principles of having at least one 'safe' language to
write
> code from.
>
> So again, I would introduce the notion that we need to let MS know that, yes
> safety is important for a learner's edition/version, but we all desire a
professional
> language (including all the capabilities of the CLR and IL code) that has syntax
> like Visual Basic.
>
> LFS
>
>
> "Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b7d995$1@news.devx.com...
> > Hi Zane --
> >
> > > >B) politically, blocking the return
> > > >of the *Ptr functions
> > >
> > > Bingo! :-)
> >
> > Yeeeeee-owch!!!
> >
> > Alan? Paul? Inquiring minds, y'know...
> >
> > Later... Karl
>
>
>

[Karl E. Peterson]

Hi Jeff --

> Fundamentally code that manipulates pointers can do things that will violate
> the security model in .NET. I'm speaking at the IL level, there is a subset
> of things that you can do that the runtime verifier can verify as safe
> (security wise.)

Right. Screw *that*, too!

> Perhaps you should actually read the specs on IL and the
> EE before you accuse me of being hoodwinked.

I have, and I don't give a ****. That's script-kiddie, marketing bullsh!t, pure and
simple. You want to play in your little sandbox, fine! Just don't tell me I *have*
to play with you, okay?

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Jeff --

> I wasn't saying that alot of it isn't marketing, nor was I saying that
> VB.NET shouldn't have an equivilient to C#'s unsafe keyword, and pointers.

Your benevolence is appreciated, I'm sure. :-/

> I should also add, I'm probably alot less emotionally involved in the
> subject when it comes to lost functionality/backwards compatibility of
> VB.NET as I personally am in the C++/C# camp, and I am not a heavy VB user.

Okay, that puts some perspective on the 'tude, alright.

> I think people who have invested heavily in previous versions of VB have
> every right to feel a bit upset and betrayed.

**** straight!

> That said, I do not think
> that MS is intentionally out to hurt any VB customers.

No one's talking "intention" here, only the .net result, so to speak. And the result
stinks.

> As to the VB.NET being a 2nd class citizen, I disagree with you, MC++ is a
> 2nd class citizen in .NET, you cannot write a .NET assembly in MC++ that
> will run without high trus permissions on the client, where both VB.NET and
> C#.NET can.

Y'know what? Lots of us don't give two craps about "running on the client." There's
a *huge* freakin' world out there that's gonna remain peer-to-peer for a long time to
come.

> If VB.NET was more compatible with VB6 (to the point no significant changes
> would be needed to port legacy code) I think some people would be screaming
> about the fact that VB.NET made generating interoperable code too difficult,
> and even when you could generate interoperable code, the level of trust
> required for vb assemblies was too high.

What Michka said.

Later... Karl
--
http://www.mvps.org/vb

[Phil Weber]

> Beetle has just changed VB runtime's pointer to its own stack.

Larry: Why couldn't the VB.NET compiler perform optional "safety checking"
on direct memory access, just as it currently does with array bounds?
---
Phil Weber

[Larry Serflaten]

I'm not sure what you mean, (and I am not a C++ coder), but this might help:

If I have a pointer, and I apply a little arithmetic:

For i = 0 to 1000
ptrVar = ptrVar * 2
Next

How will the complier catch that? It is a runtime error, is it not?

So after some other round of calculations, I then use the pointer to load
memory, how will the compiler know the memory pointed to is out of bounds,
until the actual attempt is made?

LFS


"Phil Weber" <pweber@devx.com> wrote in message news:39b9b967@news.devx.com...
> > Beetle has just changed VB runtime's pointer to its own stack.
>
> Larry: Why couldn't the VB.NET compiler perform optional "safety checking"
> on direct memory access, just as it currently does with array bounds?
> ---
> Phil Weber
>
>

[Phil Weber]

> How will the compiler know the memory pointed to
> is out of bounds, until the actual attempt is made?

Larry: Poor wording on my part. The compiler obviously can't know, but it
can insert runtime checks into the compiled code to check the target address
when a write is attempted to ensure that the address "belongs" to the app.
It's the same thing that happens now when you access an array: how do you
think VB knows that a "subscript [is] out of range" or that a value will
overflow a certain variable?

Note that these checks have been optional since VB5. This is a good thing;
if such checks are included in VB.NET, we should be able to turn them off,
at the expense of having our code not labeled "safe."
---
Phil Weber

[Jeff Peil]

Karl,

I'm not a proponent of staying inside the sandbox entirely, but I do believe
it does have a place. I'm not saying anyone should be restricted to the
sandbox by choice of language alone, however I personally think the security
model in .NET is far better then the previous option Microsoft went with -
ActiveX controls being marked as either safe for scripting or unsafe.

Looking forward I just see more and more interapplication communication and
more and more code being integrated with things like email. In a world like
that, having degrees of trust based on code will be important. I'm not
saying it applies today, and I'm not saying it will apply everywhere later,
but I do think this is important going forward.

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39b93229$3@news.devx.com...
> Hi Jeff --
>
> > Fundamentally code that manipulates pointers can do things that will
violate
> > the security model in .NET. I'm speaking at the IL level, there is a
subset
> > of things that you can do that the runtime verifier can verify as safe
> > (security wise.)
>
> Right. Screw *that*, too!
>
> > Perhaps you should actually read the specs on IL and the
> > EE before you accuse me of being hoodwinked.
>
> I have, and I don't give a ****. That's script-kiddie, marketing
bullsh!t, pure and
> simple. You want to play in your little sandbox, fine! Just don't tell
me I *have*
> to play with you, okay?
>
> Later... Karl
> --
> http://www.mvps.org/vb
>
>
>

[Bill McCarthy]

Hi Jeff,

As far as I can tell, the issue of system safety has absolutely nothing to
do with the terminology "unsafe" code. My reading of it is that the term
"UnSafe" refers to type safety, not system safety. I think this is a real
furphy that is being propogated by an in appropiate naming for
non-gc-moveable variables.

Now, if you want to talk aout system safety, have a look at what is
currently being proposed. VBScript is no more, so supposedly no more "I love
you" attachments ? Think again. Nothing is stopping a "Safe" VB.NET from
calling the FSO !!

The current plan seems to be to integrate VB.NET as one of the new scripting
languages (WSH stuff). Which ever way that goes, you can still inherit a C#
class from VB.NET. In both JScript.NET and C#.NET you can have "UnSafe"
blocks. The removal of pointers from VB, the removal of fixed memory
locations for VB variables has nothing what so-ever to do with system
safety.



"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39b9e860$1@news.devx.com...
> Karl,
>
> I'm not a proponent of staying inside the sandbox entirely, but I do
believe
> it does have a place. I'm not saying anyone should be restricted to the
> sandbox by choice of language alone, however I personally think the
security
> model in .NET is far better then the previous option Microsoft went with -
> ActiveX controls being marked as either safe for scripting or unsafe.
>
> Looking forward I just see more and more interapplication communication
and
> more and more code being integrated with things like email. In a world
like
> that, having degrees of trust based on code will be important. I'm not
> saying it applies today, and I'm not saying it will apply everywhere
later,
> but I do think this is important going forward.
>

[Jeff Peil]

Bill,

See below, inline

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:39b9eb88@news.devx.com...
> Hi Jeff,
>
> As far as I can tell, the issue of system safety has absolutely nothing to
> do with the terminology "unsafe" code. My reading of it is that the term
> "UnSafe" refers to type safety, not system safety. I think this is a real
> furphy that is being propogated by an in appropiate naming for
> non-gc-moveable variables.

It has alot to do with system safety because type safety at the runtime
level has alot to do with system safety, not necessarily the language level
(nothing would prevent a language from being type unsafe at the language
level and letting the users of the language rely on the runtime to catch
their violations.) Once you can violate type safety you can do nasty things
like falsify credentials (make assertions that you are allowed to do
something you shouldn't be allowed) on the stack, bypassing all of the
security in .NET (mind you there is still a OS level of security, but that
too is rather vulnerable, .)

> Now, if you want to talk aout system safety, have a look at what is
> currently being proposed. VBScript is no more, so supposedly no more "I
love
> you" attachments ? Think again. Nothing is stopping a "Safe" VB.NET from
> calling the FSO !!

Sure there is, untrusted VB.NET code (or any CLR based code) isn't going to
be allowed to call com objects or win32 api calls directly, and whatever
wrappers are provided *should* build upon the extensible security system in
..NET to provide apropriate protections (such as checking to see if rights
are asserted, if not providing the user with a choice, and after a user
confirm then asserting rights for the current set of calls, etc.)

> The current plan seems to be to integrate VB.NET as one of the new
scripting
> languages (WSH stuff). Which ever way that goes, you can still inherit a
C#
> class from VB.NET. In both JScript.NET and C#.NET you can have "UnSafe"
> blocks. The removal of pointers from VB, the removal of fixed memory
> locations for VB variables has nothing what so-ever to do with system
> safety.

I don't think anyone is saying that VB.NET shouldn't have the ability to
make unsafe blocks, however I do think its a bit unfair to compare that with
the removal of pointers. The way pointers have to work under the CLR is a
bit different from how they worked in VB6, so I don't think it was merely a
case of "lets chop this feature because we can" it was a case of "VB6's
pointers can't work here" they then decided that providing CLR style
pointers and unsafe code blocks in VB.NET wasn't a high enough priority to
make version 1. I don't work at Microsoft so I can't know what they felt
was more important to fit in for V1 , but I will say that if they cut unsafe
code out of C# to provide something else important (forcing people to write
it in MC++ or JScript.NET when needed) I wouldn't see it as a serious
problem for C#. Pointers aren't nearly as important in .NET as they were
traditionally, with many of the other facilities being provided there are
uses for them, they're just not quite as important.

[Larry Serflaten]

I have to speculate here, also be aware that (for most of my needs) I never
really thought it necessary to 'look under the hood' of VB. So, let me suggest
this:

VB uses internal definitions to describe the data types we used, an Internally
Defined Type, so to speak (BSTR, SAFEARRAY, etc) When you went to
find the UBound of an array, or the Length of a string, VB would peek into
these types to either return a member containing the value, or may have used
a couple members to calculate the requested value. Now before allowing
access to that data type's memory, VB's runtime could have (optionally)
performed a lookup of the upper and lower bounds to check to see that
the index value used in the request was valid. This happened at runtime,
dynamically and invisibly, and finally, at your option.

In the CLR, there are no 'Internally Defined Types'. Every type of data
is a derivitive of an Object class that exposes methods, functions, properties,
implmenting interfaces for various duties. To access the individual elements,
we will be using functions of the (Array) object:

MyArray.GetValue(2)

And for a variable we use an equals function, perhaps something similar to:

If Var1.Equals(Var2) Then DoThis

Now, as you have probably already been doing in your own classes,
when you encounter an error, you raise an exception, and it is no
different with these classes. So, (more guesswork here) the compiler
cannot check to see that your indices are within bounds, as pointed out
previously, in fact the 'safety factor' of your index might not be known
until it is passed to the GetValue function and attempted to be used.
If no error is 'thrown', you get back the value

There are methods to get the upper and lower bounds of an array,
which could be used (I suppose) By VB.Net to ensure your indices
are within bounds, before attempting to use your 'out of bounds' index.
I don't know which method they are actually using, try and ignore
error, or check bounds then get it, but at the fundamental level, they
do not need to check the bounds before attempting to use your
wild index. The GetValue function of the Array object will not
allow such an attempt to succeed. (Perhaps using the Length
function to determine if your indexed element is available).

So, speculating on a pointer object, the question is, exactly what
memory should you be allowed to point to? Obviously you can't
alter memory holding the executable commands of your assembly,
or at least should not be allowed for obvious reasons. Would you
then want to point to one of your own data structures? If so, what
will you do, that you can't get done using the methods already
provided through that data object? Would you want to point to
some completely other assembly?

How all our code is going to be laid out, is something I have not
gotten into (I'm still reading). But as was mentioned before, the
GC may pop up (another, as yet unkown, mystery) and shuffle
things about so that what you thought you were pointing to, is now
somewhere else.

What I wanted, something akin to memory mapped files (which
I wanted, but never really persued) was a means to reserve memory
and be able to share that memory with a second or third executable.
I could then design my applications as multiple exe's for those
ocassions where I wanted multiple threads. Another use, which
would be more icing than substance, would be to be able to point
directly to a device's memory (picture box for instance) and be
allowed to manipulate that memory directly.

I can think of some obvious reasons for pointers (sorting for one)
What would you use pointers for?

LFS

"Phil Weber" <pweber@devx.com> wrote in message news:39b9d366$1@news.devx.com...
> > How will the compiler know the memory pointed to
> > is out of bounds, until the actual attempt is made?
>
> Larry: Poor wording on my part. The compiler obviously can't know, but it
> can insert runtime checks into the compiled code to check the target address
> when a write is attempted to ensure that the address "belongs" to the app.
> It's the same thing that happens now when you access an array: how do you
> think VB knows that a "subscript [is] out of range" or that a value will
> overflow a certain variable?
>
> Note that these checks have been optional since VB5. This is a good thing;
> if such checks are included in VB.NET, we should be able to turn them off,
> at the expense of having our code not labeled "safe."
> ---
> Phil Weber
>
>

[Bill McCarthy]

Jeff,

"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39ba12b8$1@news.devx.com...
>
> It has alot to do with system safety because type safety at the runtime
> level has alot to do with system safety, not necessarily the language
level
> (nothing would prevent a language from being type unsafe at the language
> level and letting the users of the language rely on the runtime to catch
> their violations.) Once you can violate type safety you can do nasty
things
> like falsify credentials (make assertions that you are allowed to do
> something you shouldn't be allowed) on the stack, bypassing all of the
> security in .NET (mind you there is still a OS level of security, but that
> too is rather vulnerable, .)
>

Just as you can by using API or COM. The simple fact that C# can have UnSafe
code, proves that the .NET safety model can handle this. Either that or C#
is very very gangerous and should never be trusted. (IOW: still a complete
furphy)


>
> Sure there is, untrusted VB.NET code (or any CLR based code) isn't going
to
> be allowed to call com objects or win32 api calls directly, and whatever
> wrappers are provided *should* build upon the extensible security system
in
> .NET to provide apropriate protections (such as checking to see if rights
> are asserted, if not providing the user with a choice, and after a user
> confirm then asserting rights for the current set of calls, etc.)
>

Oh, please elaborate on this one. Are you saying that no .NET program can
run as "Safe" if it calls on COM or API ? If so, then obviously that "safety
model" suits using the "UnSafe" blocks as well. Or are you sating that all
of windows is hosed too... ???


>
> I don't think anyone is saying that VB.NET shouldn't have the ability to
> make unsafe blocks, however I do think its a bit unfair to compare that
with
> the removal of pointers. The way pointers have to work under the CLR is a
> bit different from how they worked in VB6, so I don't think it was merely
a
> case of "lets chop this feature because we can" it was a case of "VB6's
> pointers can't work here" they then decided that providing CLR style
> pointers and unsafe code blocks in VB.NET wasn't a high enough priority to
> make version 1.

Are you kidding ? First how hard is it to implement sysalloc ? C# has been
able to do it easily before they even got to pre-beta !

Have you even seen a straight answer on this yet ? The best I've seen in the
newsgroups from MS is that they are "looking at it". The whole thing
*stinks* of politics.



> I don't work at Microsoft so I can't know what they felt
> was more important to fit in for V1 , but I will say that if they cut
unsafe
> code out of C# to provide something else important (forcing people to
write
> it in MC++ or JScript.NET when needed) I wouldn't see it as a serious
> problem for C#.

Well you might not, but just as they are many VBers dissed about it, I can
assure you there would be plenty of others who would be screaming !


> Pointers aren't nearly as important in .NET as they were
> traditionally, with many of the other facilities being provided there are
> uses for them, they're just not quite as important.
>

Hello... I think you seem to be forgetting "WINDOWS". Yes, VB programmers
write programs for Windows. All this Internet "Sales" is great, but in the
mean while there is real operating systems and real clients who need real
apps. The reality is this includes Window's applications. You're saying that
COM and API don't fit into the .NET safety model. You are claiming that
pointers are not an important means of sharing a block of memory between COM
objects, ****, it sounds like you're telling me if it isn't streaming down
the wire into a browser then it doesn't matter.

[David Bayley]

Bill,

> Just as you can by using API or COM. The simple fact that C# can have
UnSafe
> code, proves that the .NET safety model can handle this. Either that or C#
> is very very gangerous and should never be trusted. (IOW: still a complete
> furphy)

The .NET safety model can NOT handle C# Unsafe code. Even if you include
the smallest of Unsafe blocks, the code is unverifiable and requires a high
level of trust to execute.

C# is only "gangerous" (was that intentional:-), if you use Unsafe code.

> > Sure there is, untrusted VB.NET code (or any CLR based code) isn't going
> to
> > be allowed to call com objects or win32 api calls directly, and whatever
> > wrappers are provided *should* build upon the extensible security system
> in
> > .NET to provide apropriate protections (such as checking to see if
rights
> > are asserted, if not providing the user with a choice, and after a user
> > confirm then asserting rights for the current set of calls, etc.)
>
> Oh, please elaborate on this one. Are you saying that no .NET program can
> run as "Safe" if it calls on COM or API ? If so, then obviously that
"safety
> model" suits using the "UnSafe" blocks as well. Or are you sating that all
> of windows is hosed too... ???

I've been wondering about this myself, and it does seem to be the inevitable
conclusion. Perhaps the security system will flag certain API calls as
safe, but that's about it.

I wouldn't say the Safety model is just marketing spin. In complex apps
it's going to be a long time before the whole code base can be marked safe,
but for small widgets that get downloaded over the web (like Java applets),
there could be immediate benefits. In the long term, COM components will
get alternative safe/unsafe .NET components to use instead.

> >
> > I don't think anyone is saying that VB.NET shouldn't have the ability to
> > make unsafe blocks, however I do think its a bit unfair to compare that
> with
> > the removal of pointers. The way pointers have to work under the CLR is
a
> > bit different from how they worked in VB6, so I don't think it was
merely
> a
> > case of "lets chop this feature because we can" it was a case of "VB6's
> > pointers can't work here" they then decided that providing CLR style
> > pointers and unsafe code blocks in VB.NET wasn't a high enough priority
to
> > make version 1.
>
> Are you kidding ? First how hard is it to implement sysalloc ? C# has
been
> able to do it easily before they even got to pre-beta !
>

I agree with Jeff. The implementation of ObjPtr in VB.NET would be far more
complicated and totally different to the one in VB6.

They could just take a chunk out of C# sharp compiler, and put it in the VB
compiler to allow the same Unsafe blocks, but then all the syntax parsing
might be intermingled, so I really don't know how practical this would be.

> Have you even seen a straight answer on this yet ? The best I've seen in
the
> newsgroups from MS is that they are "looking at it". The whole thing
> *stinks* of politics.

The C# team had VJ++ to build from, whilst the VB team had to start from
scratch, so I'm kind'a sympathetic. They're loaded with dosh, so not that
sympathetic, just trying to point out that politics might not be the only
reason.

>
> > I don't work at Microsoft so I can't know what they felt
> > was more important to fit in for V1 , but I will say that if they cut
> unsafe
> > code out of C# to provide something else important (forcing people to
> write
> > it in MC++ or JScript.NET when needed) I wouldn't see it as a serious
> > problem for C#.
>
> Well you might not, but just as they are many VBers dissed about it, I can
> assure you there would be plenty of others who would be screaming !
>

Yep, that's why C# got it, presumably at considerable expense, and why
VB.NET should get it too.

In the long term though, IMHO, we should be looking to eliminate the use of
pointers, and instead be pressing for features in the .NET runtime that
enable us to do that.

>
> > Pointers aren't nearly as important in .NET as they were
> > traditionally, with many of the other facilities being provided there
are
> > uses for them, they're just not quite as important.
> >
>
> Hello... I think you seem to be forgetting "WINDOWS". Yes, VB programmers
> write programs for Windows. All this Internet "Sales" is great, but in the
> mean while there is real operating systems and real clients who need real
> apps. The reality is this includes Window's applications. You're saying
that
> COM and API don't fit into the .NET safety model. You are claiming that
> pointers are not an important means of sharing a block of memory between
COM
> objects, ****, it sounds like you're telling me if it isn't streaming down
> the wire into a browser then it doesn't matter.
>

Unsafe was a really bad choice of words. Unverifiable would've been better.
All existing Windows apps are "Unsafe", and there's nothing wrong with
continuing to write Unsafe code for these traditional "highly-trusted" apps
both in the short term and long term.

In the Internet world, where ActiveX has proven completely inadequate, a
better security model is required, and that is what the .NET security model
is trying to address. Time will tell whether they can pull it off without
too many embarassing holes.

Just the way I see it so far.
--
David.

[Bill McCarthy]

Hi David,

"David Bayley" <dbayley@aebacus.com> wrote in message
news:39ba65ae@news.devx.com...
>
> The .NET safety model can NOT handle C# Unsafe code. Even if you include
> the smallest of Unsafe blocks, the code is unverifiable and requires a
high
> level of trust to execute.
>

By handle, I mean the JIT (or wherver) says that that code is marked as
requiring a greater level of trust. The *point* being that if C# can fit
into the .NET security model, and it's security "rating" is based on whether
or not it calls "unsafe" code blocks then the same would apply for ANY .NET
application including a VB.NET app that inherits that C# class. That's why I
believe the issue of "safety" is a complete furphy as far as including
"unsafe" code blocks in VB.NET goes.


> C# is only "gangerous" (was that intentional:-), if you use Unsafe code.
>

<g> Freudian typo <g>

>
> I've been wondering about this myself, and it does seem to be the
inevitable
> conclusion. Perhaps the security system will flag certain API calls as
> safe, but that's about it.
>

Hmm.. interesting thought. Kind-of blows that cross platform theory out of
the water too though doesn't it ?


> I wouldn't say the Safety model is just marketing spin. In complex apps
> it's going to be a long time before the whole code base can be marked
safe,
> but for small widgets that get downloaded over the web (like Java
applets),
> there could be immediate benefits. In the long term, COM components will
> get alternative safe/unsafe .NET components to use instead.
>

Bingo !! IMO, the whole "UnSafe" thing is just a marketing spin. Reality is
that developers will be using COM components in .NET for year(s) after the
official release.
I personally would rather just deal with companies I trust, that put my
trust in some JIT security model. Ooops, I've got to re-boot now, just
downloaded the latest MS JVM updates <bgd&r>



> >
> > Are you kidding ? First how hard is it to implement sysalloc ? C# has
> been
> > able to do it easily before they even got to pre-beta !
> >
>
> I agree with Jeff. The implementation of ObjPtr in VB.NET would be far
more
> complicated and totally different to the one in VB6.
>

I wasn't really talking about ObjPtr, as I was more interested in VarPtr.
(after all ObjPtr is justVarPtr under the wraps). In VB.NET, you won't need
ObjPtr anywhere near as much as VB6. The GC's weak references, the ability
to have AddressOf in class modules really tackles the main uses I've seen
for ObjPtr. Being able to do fast data manipulation, to do bit shifting, to
share global memory blocks with other applications in async, being able to
point two diferent types of variables to the same data block, being able to
manipulate graphics in memory, being able to work with the industrial
computers etc.. These are the main reasons I would like to see pointers
maintained in VB, but I would be just as happy if VB has the built in
"fixed" and "sysalloc" as C# does, (and the unsigned data types and bit
shifting functions would be bloody handy)


> The C# team had VJ++ to build from, whilst the VB team had to start from
> scratch, so I'm kind'a sympathetic. They're loaded with dosh, so not
that
> sympathetic, just trying to point out that politics might not be the only
> reason.
>

Don't know. We'll have to wait and see what they say. In the meantime we can
only speculate.


>
> Yep, that's why C# got it, presumably at considerable expense, and why
> VB.NET should get it too.
>
> In the long term though, IMHO, we should be looking to eliminate the use
of
> pointers, and instead be pressing for features in the .NET runtime that
> enable us to do that.
>

Yes and no. Having the .NET platform include everything that windows does,
well you can imagine the bloat. Letting developers write code for Windows
apps in the language of their choice without excessive overhead I think
would be preferable than all those wrapper objects. Eventually when .NET
becomes a stand alone platform, then yes, I would expect .NET to expose all
those features to the languages that use it. But I don't see that happening
for at least another 5 years. (and guessing 5 years ahead these days is real
crystal ball stuff)

>
> Unsafe was a really bad choice of words. Unverifiable would've been
better.
> All existing Windows apps are "Unsafe", and there's nothing wrong with
> continuing to write Unsafe code for these traditional "highly-trusted"
apps
> both in the short term and long term.
>

And do we trust those apps because of "veri-sign" or similar, or because of
whom they are from.

> In the Internet world, where ActiveX has proven completely inadequate, a
> better security model is required, and that is what the .NET security
model
> is trying to address. Time will tell whether they can pull it off without
> too many embarassing holes.
>

I honestly can't see it being much better than the VJM we currently have as
far as security goes.

> Just the way I see it so far.
> --

Yep, tend to agree with you on most of it too...

[David Bayley]

Bill McCarthy <Bill_McC@iprimus.com.au> wrote in message
news:39ba9e31@news.devx.com...
> Hi David,
>
> "David Bayley" <dbayley@aebacus.com> wrote in message
> news:39ba65ae@news.devx.com...
> >
> By handle, I mean the JIT (or wherver) says that that code is marked as
> requiring a greater level of trust. The *point* being that if C# can fit
> into the .NET security model, and it's security "rating" is based on
whether
> or not it calls "unsafe" code blocks then the same would apply for ANY
..NET
> application including a VB.NET app that inherits that C# class. That's why
I
> believe the issue of "safety" is a complete furphy as far as including
> "unsafe" code blocks in VB.NET goes.
>
Misunderstood you on the "handle" bit. Still don't know what "furphy"
means, but I'm guessing something like "politically motivated omission".

It would be easy to check all the dependancies of a VB.NET app, and mark it
unsafe if any of the dependancies are unsafe. But this is a different issue
from the VB compiler being able to compile unsafe code blocks, or have I
misunderstood again?


> > C# is only "gangerous" (was that intentional:-), if you use Unsafe code.
>
> <g> Freudian typo <g>

The best ones often are. It might catch on<g>.


> > I've been wondering about this myself, and it does seem to be the
> inevitable
> > conclusion. Perhaps the security system will flag certain API calls as
> > safe, but that's about it.
>
> Hmm.. interesting thought. Kind-of blows that cross platform theory out of
> the water too though doesn't it ?

True. But they're not claiming that verifiable code will (some time in the
not so distant future) be cross-platform, or perhaps they are? If so, then
we're back to no API calls allowed.


> > I wouldn't say the Safety model is just marketing spin. In complex apps
> > it's going to be a long time before the whole code base can be marked
> safe,
> > but for small widgets that get downloaded over the web (like Java
> applets),
> > there could be immediate benefits. In the long term, COM components
will
> > get alternative safe/unsafe .NET components to use instead.
>
> Bingo !! IMO, the whole "UnSafe" thing is just a marketing spin. Reality
is
> that developers will be using COM components in .NET for year(s) after the
> official release.
> I personally would rather just deal with companies I trust, that put my
> trust in some JIT security model. Ooops, I've got to re-boot now, just
> downloaded the latest MS JVM updates <bgd&r>

They have clearly stated that this is a long term strategy, and with all the
work that needs to be done, this seems reasonable. Maybe you're right and
the security models will never be good enough (this is MS!). But I think
that is truly what they are trying to achieve, so "spinning" is a bit harsh,
and "dreaming" might be better ;-)


> I wasn't really talking about ObjPtr, as I was more interested in VarPtr.
> (after all ObjPtr is justVarPtr under the wraps). In VB.NET, you won't
need
> ObjPtr anywhere near as much as VB6. The GC's weak references, the ability
> to have AddressOf in class modules really tackles the main uses I've seen
> for ObjPtr. Being able to do fast data manipulation, to do bit shifting,
to
> share global memory blocks with other applications in async, being able to
> point two diferent types of variables to the same data block, being able
to
> manipulate graphics in memory, being able to work with the industrial
> computers etc.. These are the main reasons I would like to see pointers
> maintained in VB, but I would be just as happy if VB has the built in
> "fixed" and "sysalloc" as C# does, (and the unsigned data types and bit
> shifting functions would be bloody handy)

You undertand these issues far better the me. "fixed" is something VB
doesn't currently have, and I really don't know how much work would be
required to add it with the GC moving memory around at will, but it is extra
work. I was just re-inforcing Jeff's point that they didn't just "drop" the
existing *ptr functions.


> Yes and no. Having the .NET platform include everything that windows does,
> well you can imagine the bloat. Letting developers write code for Windows
> apps in the language of their choice without excessive overhead I think
> would be preferable than all those wrapper objects. Eventually when .NET
> becomes a stand alone platform, then yes, I would expect .NET to expose
all
> those features to the languages that use it. But I don't see that
happening
> for at least another 5 years. (and guessing 5 years ahead these days is
real
> crystal ball stuff)

And when has bloat ever stopped MS<g>. Wrappers already work well in VB
without effecting performance, using .NET wrappers whenever they are
available seems the sensible choice. The question should be do those
wrappers provide access to all the underlying features of the OS, which in
VB as we know to well, they don't. From what I've seen of the framework so
far, they've covered everything, or are at least trying to.


> > All existing Windows apps are "Unsafe", and there's nothing wrong with
> > continuing to write Unsafe code for these traditional "highly-trusted"
> apps
> > both in the short term and long term.
>
> And do we trust those apps because of "veri-sign" or similar, or because
of
> whom they are from.

Not sure I understand. Verisign prooves who they're from, and does it very
well. Firewalls aside, users are happy and safe downloading ActiveX
components from MS.

Having verifiable code in addition to authenticated code, might be the
ticket. It's interesting that Java recently added authentication, and now
MS is adding verifiability. Many businesses will continue to block such
things, but they've been doing that before the internet. Home users are far
more willing to take risks, and if running through a trusted portal, oh I
don't know, say DevX, will be able to enjoy rich-client websites.


> > In the Internet world, where ActiveX has proven completely inadequate, a
> > better security model is required, and that is what the .NET security
> model
> > is trying to address. Time will tell whether they can pull it off
without
> > too many embarassing holes.
>
> I honestly can't see it being much better than the VJM we currently have
as
> far as security goes.

Is the JVM that bad for loading applets into your TV's set top box? "Just
press the reset button Gran", the kids shout from the bedroom. And, it can
only get better.

--
David.

[Robert Scoble]

> Home users are far
> more willing to take risks, and if running through a trusted portal, oh I
> don't know, say DevX, will be able to enjoy rich-client websites.

Heheh. Trust no one. That's my new motto.

Robert Scoble
http://www.devx.com/dotnet/

###

[Phil Weber]

> What would you use pointers for?

Larry: I'm not really a vocal proponent of pointers, I'm just wondering why
VB.NET makes them any less practical than previous versions of BASIC, which
could also move variables around in memory. People like Matt Curland and
Bill Storage and Francesco Balena use them for some truly slimy hacks, and
Karl uses them for advanced API techniques like memory-mapped files. The
only thing I typically use them for is copying an API-allocated block of
memory into a VB variable so I can manipulate it. If VB.NET will let me do
that without pointers, I'll have little reason to complain.
---
Phil Weber

[Bill McCarthy]

"David Bayley" <dbayley@aebacus.com> wrote in message
news:39bac3a8@news.devx.com...
> >
> Misunderstood you on the "handle" bit. Still don't know what "furphy"
> means, but I'm guessing something like "politically motivated omission".
>

See the problems we have using similar but different languages in the one
interface <bg>
Actually pretty hard to find an on-line reference for this one, although it
definetly is in the chambers dictionary. This definition is probably
closest:
http://dictionary.cambridge.org/define.asp?key=furphy*1%2B0



> It would be easy to check all the dependancies of a VB.NET app, and mark
it
> unsafe if any of the dependancies are unsafe. But this is a different
issue
> from the VB compiler being able to compile unsafe code blocks, or have I
> misunderstood again?
>

Well if I write a VB app that calls on a C# class that is unsafe, then that
security level should propogate to the app level, yes ? Likewise if I call
win32 api or COM components then once again the security rating should
propogate up to the app level, and where the rating can't be verified,
in-trusted would have to be presumed. So a VB.NET app must currently be able
to set it's security rating as untrusted. So clearly security setting is not
the issue.

The issue is as you have pointed out, is whether or not the VB compiler
supports all of the .NET classes and definitions. If I can inherit a C#
class that has unsafe code in it, then either that class will be useless in
VB.NET or VB.NET does have that under-lying capabilities.
So, if VB.NET is, as has been claimed, to have full support for the .NET
technologies, then unsafe code, which as Hejlsberg has stated, is an
integrated part of the platform, and unsigned int, long etc, should be
exposed to us. They have already changed our intrinsic data types, so why
not go for full conformance now, rather than change it again later.


> > <g> Freudian typo <g>
>
> The best ones often are. It might catch on<g>.
>

;-)

>
> True. But they're not claiming that verifiable code will (some time in
the
> not so distant future) be cross-platform, or perhaps they are? If so,
then
> we're back to no API calls allowed.
>

Yeh, but then the worse question arises.. what about the future of VB for
Win32 development ?


>
> They have clearly stated that this is a long term strategy, and with all
the
> work that needs to be done, this seems reasonable. Maybe you're right and
> the security models will never be good enough (this is MS!). But I think
> that is truly what they are trying to achieve, so "spinning" is a bit
harsh,
> and "dreaming" might be better ;-)
>

Yeh, okay, I settle on "dreaming" <bg>

>
> You undertand these issues far better the me. "fixed" is something VB
> doesn't currently have, and I really don't know how much work would be
> required to add it with the GC moving memory around at will, but it is
extra
> work. I was just re-inforcing Jeff's point that they didn't just "drop"
the
> existing *ptr functions.
>

No, this is the issue as to is VB second class on the .NET platform. Those
quotes Larry provided from Hejlsberg, I think sum it up pretty well. Fixed
is an integral part of the .NET technologies, but it is being left out of
VB. AFAIK, the issue of ObjPtr is moot, but the issue of VarPtr and "fixed"
and "sysalloc" will make VB.NET limited to what's inside the VB.NET wrappers
instead of the limits of .NET and/or win32.


>
> And when has bloat ever stopped MS<g>. Wrappers already work well in VB
> without effecting performance, using .NET wrappers whenever they are
> available seems the sensible choice. The question should be do those
> wrappers provide access to all the underlying features of the OS, which in
> VB as we know to well, they don't. From what I've seen of the framework
so
> far, they've covered everything, or are at least trying to.
>

Well hang-on there for a moment. First, even if .NET wraps it all up for us,
that doesn't mean it will be exposedto us in VB.NET. Currently they aren't
exposing "fixed", "sysalloc", "unsafe", uint, ulong, ushort, sbyte etc. If
we can't get them to expose the fully functionality at this stage, whathope
do we have for the future. They are laying down the foundation stones, now
either VB.NET is going to have to go through another change in it's
intrinsic types further down the path, or we will always be stuck to a
subset of the .NET platform.

For me, this is important for two distinct reasons. One, I want to be able
ot continue to write fully functional win32 apps using VB.NET., and two, in
the future I see .NET becoming the platform rather than a platform on a
platform. When that happens, I want VB.NET to be there without having it's
hands tied behind it's back.


>
> Not sure I understand. Verisign prooves who they're from, and does it
very
> well. Firewalls aside, users are happy and safe downloading ActiveX
> components from MS.

Just meant, that I tend to trust based on who they are, not any code
signing.

> Having verifiable code in addition to authenticated code, might be the
> ticket. It's interesting that Java recently added authentication, and now
> MS is adding verifiability. Many businesses will continue to block such
> things, but they've been doing that before the internet. Home users are
far
> more willing to take risks, and if running through a trusted portal, oh I
> don't know, say DevX, will be able to enjoy rich-client websites.
>

<g> well then there's blokes like me, who still won't enable Java on their
machines <bg>


>
> Is the JVM that bad for loading applets into your TV's set top box? "Just
> press the reset button Gran", the kids shout from the bedroom. And, it
can
> only get better.
>

LOL ! Just hope it doesn't come down to : "have you guys got enough fuel to
circle while we reboot"

[Jeff Peil]

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:39bb34b8@news.devx.com...
> Well if I write a VB app that calls on a C# class that is unsafe, then
that
> security level should propogate to the app level, yes ? Likewise if I call
> win32 api or COM components then once again the security rating should
> propogate up to the app level, and where the rating can't be verified,
> in-trusted would have to be presumed. So a VB.NET app must currently be
able
> to set it's security rating as untrusted. So clearly security setting is
not
> the issue.

Here's a simplified version of how it works, every assembly has a given
level of trust on a system (based on a lot of factors such as where the
assembly is located, what its manifest says about permissions to deny and
grant, who its signed by, and how the caspol tool has been used to configure
the system and user security settings.) When someone calls a method that
requires a security check, the EE walks up the stack looking for three
things

(1) any function on the stack from an assembly that does not have the
permission
(2) an assertion that the specific permission required is safe/unsafe to use
anywhere deeper in the call stack
(3) the top of the call stack

When walking up the stack if it finds item (1) or (2) it will stop looking
(having either concluded the call is safe and allowing it or finding it to
be unsafe to grant that permission in the current context and throwing an
exception.)

Assertions can be made based on the security of the assembly (so a function
in a highly trusted assembly can assert that it is safe from its current
context to call into a com object or win32 function) Usually this means
that highly trusted assemblies need to be responsible when asserting, for
example, the file io functions are in a highly trusted assembly, and will
assert that it is safe for them to call the win32 file io functions, but
then they extend the security permission set to add their own permissions
specifically about file io (so while the code calling them may not need
permission to call win32 code directly, it will need appropriate permissions
to do file io.)

> The issue is as you have pointed out, is whether or not the VB compiler
> supports all of the .NET classes and definitions. If I can inherit a C#
> class that has unsafe code in it, then either that class will be useless
in
> VB.NET or VB.NET does have that under-lying capabilities.
> So, if VB.NET is, as has been claimed, to have full support for the .NET
> technologies, then unsafe code, which as Hejlsberg has stated, is an
> integrated part of the platform, and unsigned int, long etc, should be
> exposed to us. They have already changed our intrinsic data types, so why
> not go for full conformance now, rather than change it again later.

C# does not support all .NET features available at the IL level, and I
believe (though I've had no reason to try) that it is possible to write a
managed C++ class that C# could not completely handle (not that C# should be
changed, imo.) I do agree with you that it doesn't make much sense to me
that VB.NET is lacking unsigned types, and bitwise operators, particularly
when these are features that I would expect to see used commonly in C#, and
thus while not required in the CLS interop spec, they will be a point of
contention when trying to interop.

> Yeh, but then the worse question arises.. what about the future of VB for
> Win32 development ?

Personally I think Win32 is going to become legacy, more and more, in
Microsoft's eyes. While with VS7 in C++ we do get some very cool updates to
ATL, I don't think we're going to see alot done for people working outside
..NET in any language anytime soon. Then again, while I would really like a
more compliant C++ compiler for Win32, I must say I don't, on a day to day
basis, have any problem using the current version. I'm admittedly not a big
user of VB, so I can't really say how badly VB6 is in need of a update for
Win32 development.

> Yeh, okay, I settle on "dreaming" <bg>

Huzzah! We've found common ground <G>. I don't think that the new security
will be truely secure, but I do think it will come alot closer (and it is a
solid framework for security so fixing what problems are found should be
more elegant and involve fewer hacks.)

> No, this is the issue as to is VB second class on the .NET platform. Those
> quotes Larry provided from Hejlsberg, I think sum it up pretty well. Fixed
> is an integral part of the .NET technologies, but it is being left out of
> VB. AFAIK, the issue of ObjPtr is moot, but the issue of VarPtr and
"fixed"
> and "sysalloc" will make VB.NET limited to what's inside the VB.NET
wrappers
> instead of the limits of .NET and/or win32.

VarPtr doesn't fit in .NET either. Basically you *can* temporarily fix an
object and take a pointer to it, but you can only hold that pointer within a
fixed block of code (so the pointer can only exist within the context of the
current function.) I'm not sure what you mean by sysalloc in C# can can use
stackalloc in unsafe blocks (allowing you to allocate memory on the stack,
not the heap.) There is nothing built into C# to allow you to allocate
memory from a heap (however, that's not to say there is nothing built into
..NET, see the System.Runtime.InteropServices.Marshal class, which is usable
from VB.NET I would add)

> Well hang-on there for a moment. First, even if .NET wraps it all up for
us,
> that doesn't mean it will be exposedto us in VB.NET. Currently they aren't
> exposing "fixed", "sysalloc", "unsafe", uint, ulong, ushort, sbyte etc. If
> we can't get them to expose the fully functionality at this stage,
whathope
> do we have for the future. They are laying down the foundation stones, now
> either VB.NET is going to have to go through another change in it's
> intrinsic types further down the path, or we will always be stuck to a
> subset of the .NET platform.

Anyone not hand coding IL is stuck with a subset of the EE, its just a
matter of what that subset is. C#, MC++, and VB.NET are all limited in this
way.

> For me, this is important for two distinct reasons. One, I want to be able
> ot continue to write fully functional win32 apps using VB.NET., and two,
in
> the future I see .NET becoming the platform rather than a platform on a
> platform. When that happens, I want VB.NET to be there without having it's
> hands tied behind it's back.

If you think VB.NET has it bad, trust me, MC++ has it worse. You can't even
write verifiable code with MC++, this is a huge limitation, looking forward.
I don't think most library/framework vendors will be put out high level
libraries using any MC++ at all (as they want to target the widest audiance
possible, and this means that if they can do something without writing
unverifiable code, they had best do it that way, or their library audience
will be limited to people writing code for a highly trusted environment.)

> Just meant, that I tend to trust based on who they are, not any code
> signing.

Me too, but I do think the age of running code from untrusted people is
coming. We need a very solid sandbox before that happens, but I do think it
will happen.

> <g> well then there's blokes like me, who still won't enable Java on their
> machines <bg>

Right now, I don't think there are many good reasons for you to have it on,
but in 5-10 years I forsee a very different landscape.

> LOL ! Just hope it doesn't come down to : "have you guys got enough fuel
to
> circle while we reboot"

Better that then having the autopilot on, something goes wrong the plane
goes into a nose drive, you try to disengage the autopilot, but operation is
currently suspended because the system GC is still running, and no other
threads are allowed to operate until the GC completes collecting <G>

[Bill McCarthy]

Hi Jeff,

"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:39bb5bd9@news.devx.com...
>
<huge snip>
>
> (however, that's not to say there is nothing built into
> .NET, see the System.Runtime.InteropServices.Marshal class, which is
usable
> from VB.NET I would add)
>

Ah ! Very interesting. Now we're starting to get somewhere <g>

So, let's say I wanted to pass a pointer to an object and then get back a
reference to the object, say from a callback's lParam, I could : (pseudo
code untested)


intPntObj = GetPinnedHandle(MyObject)

then pass intPntObj out, then get a reference back to the object using :
MyObject = GetPinnedObject(lParam)

and then finally release the object so as the GC can move it and or delete
it:
FreePinnedHandle(intPntObj)

If so, then only two questions remain. Are VB.NET's intrinsic types an array
of primitive types, and why hasn't someone else mentioned this before <bg>


-----------------------------------
BTW: this still doesn't change the fact that VB.NET doesn't have the
unsigned data types etc, bit shifting or working with pointers. And, as far
as I can tell, there is no way in VB.NET, to modify a variable's pointer
such as to point to a shared block of memory etc. (which you can do in VB6
!)

[Jeff Peil]

Actually,

I have mentioned the Marshal class before.

As to the lParam thing, while you could do that, I think that what you are
after for callbacks can be better achieved with delegates. In this case my
reference to the Marshal class was to point at the AllocCoTaskMem and
AllocHGlobal members.

As to intrinic types, that depends on what you consider to be a intrinsic
type. If you consider strings and arrays as intrinsics they're also a
regular object, while Integer, Byte, Char, etc, are all value-types
(structures.) If you want more details on this, just let me know.

Regarding the lack of bitwise operators, and unsigned datatypes, I think its
pretty sad that these aren't in VB.NET. As to pointing at shared memory
there isn't a elegant way to work with shared memory directly from managed
code that I'm aware of, period. I expect someone will throw together a MC++
assembly specifically to make working with shared memory fairly clean, at
some point (which should then provide a CLS interop compliant interface to
anyone who needs to work with memory mapped files.) I've also said before I
don't see any reason why VB shouldn't have unsafe blocks and access to
pointers within them, but I don't consider unsafe blocks and pointers a high
priority for VB.NET or C# (there are very few situations where you should
resort to pointers within the .NET framework, imo, usually there is a better
approach to what you need to do.)

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:39bb7aff@news.devx.com...
> Hi Jeff,
>
> "Jeff Peil" <jpeil@bigfoot.com> wrote in message
> news:39bb5bd9@news.devx.com...
> >
> <huge snip>
> >
> > (however, that's not to say there is nothing built into
> > .NET, see the System.Runtime.InteropServices.Marshal class, which is
> usable
> > from VB.NET I would add)
> >
>
> Ah ! Very interesting. Now we're starting to get somewhere <g>
>
> So, let's say I wanted to pass a pointer to an object and then get back a
> reference to the object, say from a callback's lParam, I could : (pseudo
> code untested)
>
>
> intPntObj = GetPinnedHandle(MyObject)
>
> then pass intPntObj out, then get a reference back to the object using :
> MyObject = GetPinnedObject(lParam)
>
> and then finally release the object so as the GC can move it and or delete
> it:
> FreePinnedHandle(intPntObj)
>
> If so, then only two questions remain. Are VB.NET's intrinsic types an
array
> of primitive types, and why hasn't someone else mentioned this before <bg>
>
>
> -----------------------------------
> BTW: this still doesn't change the fact that VB.NET doesn't have the
> unsigned data types etc, bit shifting or working with pointers. And, as
far
> as I can tell, there is no way in VB.NET, to modify a variable's pointer
> such as to point to a shared block of memory etc. (which you can do in VB6
> !)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[Karl E. Peterson]

Hi Phil --

> > What would you use pointers for?
>
> Larry: I'm not really a vocal proponent of pointers, I'm just wondering why
> VB.NET makes them any less practical than previous versions of BASIC, which
> could also move variables around in memory. People like Matt Curland and
> Bill Storage and Francesco Balena use them for some truly slimy hacks, and
> Karl uses them for advanced API techniques like memory-mapped files. The
> only thing I typically use them for is copying an API-allocated block of
> memory into a VB variable so I can manipulate it. If VB.NET will let me do
> that without pointers, I'll have little reason to complain.

There does appear to be runtime support for certain types of memory access. What you
don't get is unlimited/unfettered access, nor do you have the ultimate freedom to
"express yourself." By making pointers offlimits to VB, MS *is* shutting doors.
They may be doors we aren't even aware of yet. The decision is arbitrary and
insulting. "Don't run with scissors."

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Jeff --

Yours is the marketeering-induced utopian view that simply cannot and will not come
to pass. You're not to be blamed for this, as the pressure to conform has been
immense. Struggle to resist.

Thanks... Karl
--
http://www.mvps.org/vb



"Jeff Peil" <jpeil@bigfoot.com> wrote in message news:39b9e860$1@news.devx.com...
> Karl,
>
> I'm not a proponent of staying inside the sandbox entirely, but I do believe
> it does have a place. I'm not saying anyone should be restricted to the
> sandbox by choice of language alone, however I personally think the security
> model in .NET is far better then the previous option Microsoft went with -
> ActiveX controls being marked as either safe for scripting or unsafe.
>
> Looking forward I just see more and more interapplication communication and
> more and more code being integrated with things like email. In a world like
> that, having degrees of trust based on code will be important. I'm not
> saying it applies today, and I'm not saying it will apply everywhere later,
> but I do think this is important going forward.
>
> "Karl E. Peterson" <karl@mvps.org> wrote in message
> news:39b93229$3@news.devx.com...
> > Hi Jeff --
> >
> > > Fundamentally code that manipulates pointers can do things that will
> violate
> > > the security model in .NET. I'm speaking at the IL level, there is a
> subset
> > > of things that you can do that the runtime verifier can verify as safe
> > > (security wise.)
> >
> > Right. Screw *that*, too!
> >
> > > Perhaps you should actually read the specs on IL and the
> > > EE before you accuse me of being hoodwinked.
> >
> > I have, and I don't give a ****. That's script-kiddie, marketing
> bullsh!t, pure and
> > simple. You want to play in your little sandbox, fine! Just don't tell
> me I *have*
> > to play with you, okay?
> >
> > Later... Karl
> > --
> > http://www.mvps.org/vb
> >
> >
> >
>
>

[Karl E. Peterson]

Scoble! This post, or a variant thereof, needs to be on the FAQ. :-)
--
http://www.mvps.org/vb


"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:39bb7aff@news.devx.com...
> Hi Jeff,
>
> "Jeff Peil" <jpeil@bigfoot.com> wrote in message
> news:39bb5bd9@news.devx.com...
> >
> <huge snip>
> >
> > (however, that's not to say there is nothing built into
> > .NET, see the System.Runtime.InteropServices.Marshal class, which is
> usable
> > from VB.NET I would add)
> >
>
> Ah ! Very interesting. Now we're starting to get somewhere <g>
>
> So, let's say I wanted to pass a pointer to an object and then get back a
> reference to the object, say from a callback's lParam, I could : (pseudo
> code untested)
>
>
> intPntObj = GetPinnedHandle(MyObject)
>
> then pass intPntObj out, then get a reference back to the object using :
> MyObject = GetPinnedObject(lParam)
>
> and then finally release the object so as the GC can move it and or delete
> it:
> FreePinnedHandle(intPntObj)
>
> If so, then only two questions remain. Are VB.NET's intrinsic types an array
> of primitive types, and why hasn't someone else mentioned this before <bg>
>
>
> -----------------------------------
> BTW: this still doesn't change the fact that VB.NET doesn't have the
> unsigned data types etc, bit shifting or working with pointers. And, as far
> as I can tell, there is no way in VB.NET, to modify a variable's pointer
> such as to point to a shared block of memory etc. (which you can do in VB6
> !)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

[James D. Foxall]

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:39ba232e@news.devx.com...
> Hello... I think you seem to be forgetting "WINDOWS". Yes, VB programmers
> write programs for Windows. All this Internet "Sales" is great, but in the
> mean while there is real operating systems and real clients who need real
> apps. The reality is this includes Window's applications. You're saying
that
> COM and API don't fit into the .NET safety model. You are claiming that
> pointers are not an important means of sharing a block of memory between
COM
> objects, ****, it sounds like you're telling me if it isn't streaming down
> the wire into a browser then it doesn't matter.

Hi Bill,

I agree with you here. We have almost 1,300 clients right now, and I don't
see them as 'fast movers', as in I can't imagine most of them implementing
their own Internet/Intranet servers anytime soon. Heck, a lot of them still
use Novel rather than NT (Jet 3.x is more stable on a Novel server, believe
it or not). Although I'm very excited about features of .Net, I anticipate
spending 98%+ writing 'traditional' applications. I think there are a LOT of
people that will still be writing traditional applications vs. .Net
applications.

--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com

[Robert Scoble]

> Scoble! This post, or a variant thereof, needs to be on the FAQ. :-)

Working on it. Thanks!

Robert

[Bill McCarthy]

That code should be:

Imports System.Runtime.InteropServices


Dim h As GCHandle = GCHandle.Alloc(MyVar, GCHandleType.Pinned)
Dim p As Integer = h.AddrOfPinnedObject()

......' work with p the pointer here
......'then free the GCHandle so as the GC can delete/move the object
h.Free


The above was taken from a sample by Paul Vick and "BHarry" from the dotnet
list.

Sure looks like equivalent of VarPtr (ObjPtr et.al.)



"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39bd2428$1@news.devx.com...
> Scoble! This post, or a variant thereof, needs to be on the FAQ. :-)
> --
> http://www.mvps.org/vb
>
>
> "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
> news:39bb7aff@news.devx.com...
> > Hi Jeff,
> >
> > "Jeff Peil" <jpeil@bigfoot.com> wrote in message
> > news:39bb5bd9@news.devx.com...
> > >
> > <huge snip>
> > >
> > > (however, that's not to say there is nothing built into
> > > .NET, see the System.Runtime.InteropServices.Marshal class, which is
> > usable
> > > from VB.NET I would add)
> > >
> >
> > Ah ! Very interesting. Now we're starting to get somewhere <g>
> >
> > So, let's say I wanted to pass a pointer to an object and then get back
a
> > reference to the object, say from a callback's lParam, I could : (pseudo
> > code untested)
> >
> >
> > intPntObj = GetPinnedHandle(MyObject)
> >
> > then pass intPntObj out, then get a reference back to the object using :
> > MyObject = GetPinnedObject(lParam)
> >
> > and then finally release the object so as the GC can move it and or
delete
> > it:
> > FreePinnedHandle(intPntObj)
> >
> > If so, then only two questions remain. Are VB.NET's intrinsic types an
array
> > of primitive types, and why hasn't someone else mentioned this before
<bg>
> >
> >
> > -----------------------------------
> > BTW: this still doesn't change the fact that VB.NET doesn't have the
> > unsigned data types etc, bit shifting or working with pointers. And, as
far
> > as I can tell, there is no way in VB.NET, to modify a variable's pointer
> > such as to point to a shared block of memory etc. (which you can do in
VB6
> > !)
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

[Jeff Peil]

What utopian view?

Personally I'm a pessimist, I believe that we're looking at a security
nightmare, in reality. However I don't think that is enough to stop
consumer demand from pushing this sort of thing forward. In 10 years we'll
see who was more right <G>

"Karl E. Peterson" <karl@mvps.org> wrote in message
news:39bd1a57@news.devx.com...
> Hi Jeff --
>
> Yours is the marketeering-induced utopian view that simply cannot and will
not come
> to pass. You're not to be blamed for this, as the pressure to conform has
been
> immense. Struggle to resist.
>
> Thanks... Karl
> --
> http://www.mvps.org/vb

[Karl E. Peterson]

Hi Jeff --

> > Yours is the marketeering-induced utopian view that simply cannot and will not
come
> > to pass. You're not to be blamed for this, as the pressure to conform has been
> > immense. Struggle to resist.
>
> What utopian view?
>
> Personally I'm a pessimist, I believe that we're looking at a security
> nightmare, in reality. However I don't think that is enough to stop
> consumer demand from pushing this sort of thing forward. In 10 years we'll
> see who was more right <G>

Sorry, it seemed you believed MS had solved the security woes of the world, if only
everyone might adapt DOTNET as their savior. ;-)

I don't believe "degrees of trust" will solve anything. I get a big kick out of the
folks who're ponderously inveighing the almost laughable unliklihood of pointers
being used to defraud security measures should VB be so endowed. As *if* there were
that much time in the day, huh? <g>

Later... Karl
--
http://www.mvps.org/vb