Re: VB6, VB2005, or Something Else?
- From: "Dan Barclay" <Dan@xxxxxxxx>
- Date: Tue, 4 Apr 2006 09:56:08 -0500
"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:%23bpqwx6VGHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
Dan Barclay wrote:
"Andre Kaufmann" <andre.kaufmann.bei@xxxxxxxxxxx> wrote in message
news:%23iIejytVGHA.1688@xxxxxxxxxxxxxxxxxxxxxxx
Gary Nelson wrote:
Paul,I once thought the same way, that Microsoft could have done better,
[...]
Someone here seems to have missed the point.
let's say like Borland did with Delphi. But after reading the following
article www.itwriting.com/frozenvb6.php I'm not sure about that anymore.
Should add: I'm not a VB expert to be able to 100% verify the statements
made in this article.
I didn't waste my time reading every word of the article. It was clear
within a minute that the author was interested in selling a point of view
rather than facts.
We had a discussion about the VB6 about a year ago and you made it clear
that the VB.NET changes have broken business/math code.
You referred (as an example) to the integer size changed, I have checked
it and the upgrade tool does upgrade the code correctly.
Don't get me wrong, I agree that too much has changed and not all changes
have been necessary. I also agree that the integer size changes breaks
code compatibility. Meaning you can't go back to VB6 or using just the
same code.
I'm just referring to the point that also core code (formulas) has been
broken so that you can't >upgrade<, which the article states that's not
the case.
I'm not that an VB6 expert to verify this statement, but would be glad if
you could give one.
The changes made in the VB language were by specific decision to "clean
up" the language rather than any requirement of the platform change. The
one exception to that was the loss of Deterministic Finalization.
OO and structure changes could easily have been added without breaking
existing language features.
They could have been added. But the current VB6 "object" model conflicts
with the "new" object model. They could have been implemented both, no
doubt, but that would have lead IMHO to a language monster.
I'm not making that up. That comes from MS.
May be, that the article has been paid or influenced by Microsoft. Though
the site seems to have articles from Borland too. I hadn't a look at them,
but will do so.
Actually I was trying to say that *my* information comes from MS. I don't
know where the article info comes from. It does sound a lot like a rehash
of the marketing info MS has been putting out.
I understand that you've got burned by the VB.NET changes, but what I
don't understand is that you are moving completely to Delphi.
This is a larger issue than just a few incompatibilities between versions.
Let me see if I can explain the "big picture", which is probably not evident
from current activity alone.
This isn't the first time. During the move to 32bit (VB4) MS changed
several things, including a fundamental data type (sound familiar). They
changed the $tring data type from single to double byte in a failed effort
to support UNICODE. UNICODE support is a good move, but in doing it the way
they did it they broke *all* code that handles binary data. Prior to VB4/32
the only way to handle binary data was in $trings (there was no byte data
type). Starting with VB4 the documentation explicitly said ""Note: When
passing binary data to a DLL procedure, pass a variable as an array of the
Byte data type, instead of a String variable. Strings are assumed to contain
characters, and binary data may not be properly read in external procedures
if passed as a String Variable". This phenom was dubbed "Unimess".
Check the first hit at http://www.google.com/search?hl=en&q=unimess
Prior to the VB4 problems there were other issues, particularly coming from
DOS compilers to VBWin, though in comparison I *now* consider them minor<g>.
In prior versions (DOS, CP/M, and TRSDOS) almost all code except platform
specific code could be moved without modification. During that time MS had
a fairly stable development team that loved the language.
After the VB4 faisco, MS brought 25 or so of us to Redmond to discuss the
issue. At that meeting they said they "got it" and wouldn't do language
breaking changes again. VB5 was a decent transition, as was VB6. They
convinced all of us (including me) that they were serious. MS assigned an
entirely new crew to VB for VB7 (VB.Net) and here we go again. Repeat after
me "A New Type of Data requires a New Data Type".
The issue of the changes themselves is bad enough, but the *core* problem is
that MS does not believe Basic is a real language for serious developers.
They would never consider (or tolerate) these kinds of changes for languages
they depend on themselves, yet they don't even assign heavy users of the
language to the team. The bottom line is that this has happened several
times in the past, this is just the worst, and it *will* happen again.
Don't get me wrong. I 'm using Delphi too and regarding language stability
it's a very good alternative. But yet you are restricted to a single
vendor. Why don't you move your internally business code to C++ ? That
shouldn't be a discussion about the vendor Borland or Microsoft nor do I
have anything against Borland (regarding Delphi).
Borland has a C++ compiler too and also other operating systems.
Wouldn't that be the natural move of a burned VB6 developer to move to C++
with the business code and use e.g. Delphi for the rest of it ?
We did look at C++, and may move in that direction on some of the code.
Using the Borland IDE that's pretty straightforward. Converstion to C++ has
that positive, but it doesn't let you use your code in .Net. A conversion
of our existing code is also much easier to Delphi (it's very VB-like). For
more discussion on this, which also mirrors your observations, see "So now
what?" in http://vb.mvps.org/tips/stability.asp
That paper was written in 2001. My opinion hasn't changed much, except that
I now know more about Delphi and have actually used it some. I've also
studied what it would take to rewrite our code in C++. For some, C++ will
be the right move.
Nearly *five years* after this issue came to light, even at the Ballmer
level, and the little they've done is to try some wizardry and marketeering.
It's not that they can't do something. They won't. One of the folks they
sent to resolve this said, on a public newsgroup, that "everybody will have
forgot about this in 9 months". I can't trust my code to that kind of
situation.
While Delphi is also "proprietary", there are other fairly compatible pascal
compilers, and I'm rewriting in a way that I could move to another language
(like C++) more easiliy at some point. I don't think it will come to that,
but at least there are alternate plans. One reason I have much more
confidence in Delphi is that they actually *use* Delphi internally. The
Delphi product is sustainable as a reasonably small team on its' own so it
is "business stable". It's also been around a while and has a loyal user
base.
The bottom line is that you just can't trust MS with anything that's
important, unless you do it in C++. The only reason you can trust them
with C++ is because they depend on it themselves.
Dan
.
- Follow-Ups:
- Re: VB6, VB2005, or Something Else?
- From: Andre Kaufmann
- Re: VB6, VB2005, or Something Else?
- References:
- Re: VB6, VB2005, or Something Else?
- From: Gary Nelson
- Re: VB6, VB2005, or Something Else?
- From: Andre Kaufmann
- Re: VB6, VB2005, or Something Else?
- From: Dan Barclay
- Re: VB6, VB2005, or Something Else?
- From: Andre Kaufmann
- Re: VB6, VB2005, or Something Else?
- Prev by Date: Re: Newbie question - calling a DLL function returns Type Mismatch error
- Next by Date: Re: VB6, VB2005, or Something Else?
- Previous by thread: Re: VB6, VB2005, or Something Else?
- Next by thread: Re: VB6, VB2005, or Something Else?
- Index(es):
Relevant Pages
|