.NOT My Views

[Abubakar]

We'll see how much sympathy the .NETheads get from those of us who knew

better *when* that moment comes.

many of the vbc ppl have written this about it happening to .net ppl when
there time comes. I've started feeling like making a time machine n going
into the future to see what really will happen!

-Ab.
http://joehacker.blogspot.com

 

[Paul Clement]

¤ >Oh, so you think that Microsoft was going to maintain a Classic and .NET
¤ >version of Visual Basic
¤ forever? <
¤
¤ Actually, no I don't.
¤
¤ I think at some point .NET is going to get the same shaft as VBC and leave
¤ another group of developers holding thousands of lines of useless code for
¤ the next self applyed "big thing."
¤
¤ We'll see how much sympathy the .NETheads get from those of us who knew
¤ better *when* that moment comes.
¤
¤ - Kev
¤

Well even if it does happen, which wouldn't be for a while anyway, my attitude will be the same as
it was when moving from Classic to .NET. No sympathy (or empathy) is required.

Just keep in mind that if they hose .NET, they hose C# developers as well.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Paul Clement]

Gary,

¤ > What about those who are now using Visual Basic.NET including those who
¤ > never even used Classic VB?
¤
¤ I don't have any statistics. But I do know that C# is the 'in' language with
¤ MS. Just try attending TechEd without a decent knowledge of C#.
¤

Well I don't attend TechEd so I guess I wouldn't know and I don't get as worked up about perceptions
as some do. ;-)

My only concern is what they're doing with Visual Basic and I don't have to attend TechEd or the PDC
for that type of information.

¤ > ¤ VB for .NET could have been much more compatible with VB6 if MS had
¤ > wanted.
¤ > ¤
¤ >
¤ > Some features yes, some no because the current implementations differed
¤ > from those in .NET. But this
¤ > issue has been debated endlessly.
¤
¤ The first three words in your last phrase are what have created endless
¤ debates. 'Some features yes'. All VB6 users are programmers. Some are very
¤ good. That means that we can take a look at what MS did and do a pretty good
¤ calculation of what was really necessary and what was not.
¤

Yes, but I still don't understand why some of the most insignificant changes are always at the
forefront of the complaints. Hey if you want to complain, complain about file i/o and not
While...Wend or GoSub.

¤ > Oh, so you think that Microsoft was going to maintain a Classic and .NET
¤ > version of Visual Basic
¤ > forever?
¤
¤ No, but I do believe that a much smoother transition could have been
¤ achieved.
¤

Could be. But alternative transitions are available, such as COM interop, which are being used
successfully to port over time as opposed to all at once.

¤ > ¤ I'm not looking for a job. The last time I looked for a job was over 20
¤ > ¤ years ago. There is a very good probability that we will be using VB6
¤ > until
¤ > ¤ it stops working.
¤ >
¤ > Hey, as long as it serves your needs and its obsolence does not dictate a
¤ > job change then you're all
¤ > set.
¤
¤ I wouldn't consider that having a Damocles' sword hanging over my head being
¤ 'all set'.
¤

We're all in the same boat. I guess it depends upon the type of investment you have but you can only
tread water for so long. No one is going to wait around forever to throw you a lifesaver.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Stefan Berglund]

On Wed, 19 Oct 2005 11:30:51 -0500, Paul Clement

We're all in the same boat. I guess it depends upon the type of investment you have but you can only
tread water for so long. No one is going to wait around forever to throw you a lifesaver.

No we're NOT all in the same boat. Sure, if you want to hang around and have
Microsoft figure out how next to stick it to you, then yes YOU're in the same
boat. Go ahead and invest in their future. They will be extremely grateful and
will gladly scoop up all the money you're willing to throw in their direction.

 

[Gary Nelson]

Paul,

Well I don't attend TechEd so I guess I wouldn't know and I don't get as
worked up about perceptions
as some do. ;-)

My only concern is what they're doing with Visual Basic and I don't have
to attend TechEd or the PDC
for that type of information.

Perhaps, but I do believe it is one of the best sources for 'that type of
information'.

Yes, but I still don't understand why some of the most insignificant
changes are always at the
forefront of the complaints. Hey if you want to complain, complain about
file i/o and not
While...Wend or GoSub.

The problem is that, insignificant or not, the changes break code. As an
example I have a very large and complex DLL which we have ported to VB.NET
(successfully). Now I find myself in the very unenviable situation of trying
to maintain the code in both DLLs. I can assure you that it is a royal pain.
I don't know about you, but if there is one thing I hate it is writing the
same code twice.

Could be. But alternative transitions are available, such as COM interop,
which are being used
successfully to port over time as opposed to all at once.

Have you actually used COM interop? I tried using it once in an ASP.NET
project and it makes a mess of the security settings. In the end I gave up.
I wouldn't recommend using unmanaged code in ASP.NET to anyone.

¤ I wouldn't consider that having a Damocles' sword hanging over my head
being
¤ 'all set'.
¤

We're all in the same boat. I guess it depends upon the type of investment
you have but you can only
tread water for so long. No one is going to wait around forever to throw
you a lifesaver.

I doubt very much that anyone is going to throw a lifesaver. On the other
hand, I don't see how MS can actually break VB6. After all, QB programs from
the 80's still run on Win2003. If MS ever brings out an operating system
that breaks COM I don't think anyone would buy it. And remember, an OS that
breaks VB6 code would also break all of those using COM interop.

Gary

 

[Jonathan West]

On the other hand, I don't see how MS can actually break VB6. After all,
QB programs from the 80's still run on Win2003. If MS ever brings out an
operating system that breaks COM I don't think anyone would buy it. And
remember, an OS that breaks VB6 code would also break all of those using
COM interop.

Oh, Microsoft has *already* managed to break VB6. It doesn't require
breaking the whole of COM to achieve that. Fortunately they decided to stick
it back together again. But for how much longer will Microsoft be willing to
fix breaks like this?


The Format() Function Gives Different Results in Windows XP Than in Windows
2000
http://support.microsoft.com/?kbid=321047

To break VB6 doesn't require that programs will no longer run - all that is
required is that they won't reliably continue to produce the same results.

As things are, the evil day will come when VB6 codebases will have to be
rewritten or abandoned.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Gary Nelson]

Jonathan,

To break VB6 doesn't require that programs will no longer run - all that
is required is that they won't reliably continue to produce the same
results.

As things are, the evil day will come when VB6 codebases will have to be
rewritten or abandoned.

I don't doubt that, but in the meantime I don't see any other solution than
to keep on developing in VB6.

Gary

 

[Paul Clement]

Gary,

¤ > Yes, but I still don't understand why some of the most insignificant
¤ > changes are always at the
¤ > forefront of the complaints. Hey if you want to complain, complain about
¤ > file i/o and not
¤ > While...Wend or GoSub.
¤
¤ The problem is that, insignificant or not, the changes break code. As an
¤ example I have a very large and complex DLL which we have ported to VB.NET
¤ (successfully). Now I find myself in the very unenviable situation of trying
¤ to maintain the code in both DLLs. I can assure you that it is a royal pain.
¤ I don't know about you, but if there is one thing I hate it is writing the
¤ same code twice.
¤

Actually change from Wend to End While does not break code. It is automatically converted.

Maintaining code in a DLL for each version of the product isn't necessarily unusual. I've had to do
this with 16 and 32-bit VB 4.0 in the past. It was necessitated by the platform.

¤ > Could be. But alternative transitions are available, such as COM interop,
¤ > which are being used
¤ > successfully to port over time as opposed to all at once.
¤
¤ Have you actually used COM interop? I tried using it once in an ASP.NET
¤ project and it makes a mess of the security settings. In the end I gave up.
¤ I wouldn't recommend using unmanaged code in ASP.NET to anyone.
¤

Yes, we have production COM components (which use ActiveReports) that have yet to be converted to
..NET. We've been using them seamlessly with our ASP.NET applications. We have some other COM
components that have been used in this capacity as well. It's no big deal.

¤ > ¤ I wouldn't consider that having a Damocles' sword hanging over my head
¤ > being
¤ > ¤ 'all set'.
¤ > ¤
¤ >
¤ > We're all in the same boat. I guess it depends upon the type of investment
¤ > you have but you can only
¤ > tread water for so long. No one is going to wait around forever to throw
¤ > you a lifesaver.
¤
¤ I doubt very much that anyone is going to throw a lifesaver. On the other
¤ hand, I don't see how MS can actually break VB6. After all, QB programs from
¤ the 80's still run on Win2003. If MS ever brings out an operating system
¤ that breaks COM I don't think anyone would buy it. And remember, an OS that
¤ breaks VB6 code would also break all of those using COM interop.

COM interop isn't a permanent solution. It's a path that enables you to either migrate your
application over time or sustain it until it's obsolete.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Stefan Berglund]

Jonathan,


I don't doubt that, but in the meantime I don't see any other solution than
to keep on developing in VB6.

Gary

I've felt pretty much that same feeling of helplessness and I'm sure that the
Microsoft marketeers consciously exploit said fear, but if you'd consider
dusting off your C/C++ skills you could possibly take some refuge in Qt.

 

[Stefan Berglund]

On Fri, 21 Oct 2005 11:06:36 -0500, Paul Clement

COM interop isn't a permanent solution. It's a path that enables you to either migrate your
application over time or sustain it until it's obsolete.


Paul
~~~~
Microsoft MVP (Visual Basic)

And you believe everything they tell you, don't you Paul?

 

[Paul Clement]

¤ >COM interop isn't a permanent solution. It's a path that enables you to either migrate your
¤ >application over time or sustain it until it's obsolete.
¤ >
¤ >
¤ >Paul
¤ >~~~~
¤ >Microsoft MVP (Visual Basic)
¤
¤
¤ And you believe everything they tell you, don't you Paul?
¤

Well those are my words Stefan and nobody had to tell me that ;-)


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Gary Nelson]

Paul,

Yes, we have production COM components (which use ActiveReports) that have
yet to be converted to
.NET. We've been using them seamlessly with our ASP.NET applications. We
have some other COM
components that have been used in this capacity as well. It's no big deal.

How did you get around the security issues?

Gary

 

[Paul Clement]

Gary,

¤ > Yes, we have production COM components (which use ActiveReports) that have
¤ > yet to be converted to
¤ > .NET. We've been using them seamlessly with our ASP.NET applications. We
¤ > have some other COM
¤ > components that have been used in this capacity as well. It's no big deal.
¤
¤ How did you get around the security issues?

What security issues are you referring to? We run some of our components in COM+ and some in the web
application process. The only additional item you need (with a .NET client) is the interop assembly.

I haven't encountered any security issues.


Paul
~~~~
Microsoft MVP (Visual Basic)