Re: vb6 -v- Net!

On Mar 29, 12:00 pm, "Robert Morley"
<rmor...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Any "managed" system is going to be slow. QuickBASIC, VB, Java, COM,
and now .NET.

Last I heard, no previous version of basic was a managed system. Perhaps in
the strictest sense, but not in any meaningful sense when compared with
VB.NET.

A history lesson programs on MS-DOS-Intel style system came in one of
two flavors. First was COM programs. The binary file that is a com
file is an exact memory image of the program. If the COM program is
16k then it would occupy 16k of memory. EXE programs in contrast has a
loader that reads the EXE formated problem and loads in the right
segments to begin execution. We can get more specific but that not why
I am explaining this.

C is often called a high level version of assembly. Just about
anything you can do in assembly you can do in a good C Complier. But
it was a lot more intelligible and in theory somewhat portable between
computer. This meant you can allocate and use memory in any damn way
wanted even in ways that well... would take down your computer and
program.

Hardware mapped into memory somewhere or hardware used interrupts or
ports that were accessed through make a specific function call and
reading the registers for the results. Again the reality was more
complex. The point is that C could access the lowest level of the
computer as readily as assembly.

However MS-BASIC in contrast managed it memory. It enforced variable
bounds and freed unused space. And it was running in a managed
environment, the interpreter. Later compliers were made that creaded
COMs and EXEs but even then you couldn't just jam any old piece data
where you liked. Of course it wasn't like the managed environments of
today. But back in the day interpreter was just as intrusive.

Eventually BASIC added specialized functions like PEEK, POKE, and the
ability to link to libraries written in C. Plus it gained a complier .
But a BASIC EXE still had garbage collection and all the memory
management that it had when running in the interpreter.

By the end of the MS-DOS era there was little you couldn't in BASIC
that you could do in C/Assembly. At the beginning there was a lot that
C/Assembly could do that BASIC couldn't do. But successive versions
closed the gap.

The exact same cycle repeated for Visual Basic 1 to 6. Plus it was
better now because with the introduction of ActiveX we can use C/C++/
Assembly to bolt on any missing capability to VB in a fairly standard
way. But the first VBXs and the first ActiveXs were really bad
compared to what came later. And it took a while for hardware device
oems (motion control, sensing, etc) to come up with Active Libraries
in addition the C libraries they offered before.

And the same thing is happening with VB.NET right now except a slower
rate of adoption. And the reason it is slower because

1) VB6 is a perfectly fine productive application for a lot of this
stuff and unlike the DOS to Windows transition, we are still on
windows and the apps look comparably the same.

2) Microsoft screwed the VB6 guys out of an upgrade path, and from
other report they are not keeping the hardware vendor very happy with
vista. Again the different between the DOS to Windows transition and
now is that Vista is EVOLUTIONARY while going from DOS to Windows was
an REVOLUTIONARY change. You could look at a DOS system and look at
Windows System and beyond looks say Windows is better. Or VB versus
PDS/QuickBASIC. That not the same with Vista or .NET.



The trick is to write a good wrapper around the
unmanaged bit.

Which in .NET implies that you MUST convert everything to C++ in order to
have an executable that works as fast as your old one did.

It depends, if you are talking hardware access, sure you better make
sure your .NET wrapper is as close to the hardware as it can get. If
you are using some form of .NET control wrapped around an ActiveX
control then you are going through two layers instead of one.

AFAIK, that's
the only language .NET supports unmanaged code in, and many VB programmers
will have neither the knowledge or time to go that route.

Most VB programmers don't do what you and I do. The vast majority of
VB Programmer make Database Frontend using Crystal Reports to generate
reports. And guess what the one VB6 upgrade path .NET supports?


Why is it invalid to expect that something that worked excellently in VB6
will slow by a factor of 50% or more (often significantly more) in what's
supposed to be an "upgrade" of that language?

It sucks an UPGRADE, doesn't mean it sucks as a environment. Visual
BASIC 1 sucked as an upgrade for a quickbasic program. You couldn't
just run most UI intensive QuickBASIC program out of the box. However
it saving grace was that the non-UI stuff ran pretty much as is with
some minor syntax fix up on file I/O. And the lost of READ...DATA
sucked as well..

With .NET microsoft has broken
compatibility with older VB and added performance hits to older COM
software.

That was a two-liner that I posted; I wasn't trying to re-hash every
argument that has ever been made in this debate, just a broad overview of
statements already made previously in the discussion.

The thing is bashing .NET as .NET will get VB Programmers nowhere. The
technology is here to stay and it what new stuff is being written for.
We need to convince Microsoft that they need to make a compilier and
environment that works for the syntax of VB6. In conjunction with that
they need to work on the framework to get the performance of its
components back to VB6 level days.


.

Relevant Pages

  • Re: Crashes and the Blue Screen of Death!
    ... but the most common cause is hardware failure. ... The most common cause of this is hardware memory corruption. ... are listed on the Windows 2000 Hardware Compatibility List. ... recommended that all users install them as they become available. ...
    (microsoft.public.win2000.general)
  • Re: error restarts intermittently
    ... A problem has been detected and windows has been shut down to prevent ... And text about newly installed hardware or software, ... Device manager is good. ... The system attempted to access pageable memory using a kernel process ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: Windows installation problem. Help.
    ... 2004 Windows MVP "Winny" Award ... tries to read the memory, can't find it, generates a processor fault, ... This Stop message usually occurs after the installation of faulty hardware ...
    (microsoft.public.windowsxp.general)
  • Re: BAD_POOL_HEADER blue screen of death
    ... The "pool" referred to is a memory pool. ... > Also, I installed no new hardware, except for some more memory. ... >> Here is a MSDN article with regard to this error in Windows 2000. ... >> the error reporting tool will get this for you. ...
    (microsoft.public.windowsxp.perform_maintain)
  • Re: [opensuse] 4GB computer slowdown
    ... What I experienced was correct Windows ... I agree with Carlos that LInux most probably uses hardware more ... memory check tool showed that memory was bad => computer to the IT ... That would depend on whether parity checking is enabled. ...
    (SuSE)