Thoughts on Net verses VB7


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 5 123 ... LastLast
Results 1 to 15 of 72

Thread: Thoughts on Net verses VB7

  1. #1
    Don Jones Guest

    Thoughts on Net verses VB7


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

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

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

    was written in VB3 that has been upgraded to VB6.

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

    hopes that MS can cram Net down our throat.


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

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

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

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

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

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

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

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

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


  2. #2
    Sjoerd Verweij Guest

    Re: Thoughts on Net verses VB7

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


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




  3. #3
    Torsten Rienow Guest

    Re: Thoughts on Net verses VB7

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

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




  4. #4
    Sjoerd Verweij Guest

    Re: Thoughts on Net verses VB7

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


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



  5. #5
    Torsten Rienow Guest

    Re: Thoughts on Net verses VB7

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

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

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

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

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




  6. #6
    Rob Teixeira Guest

    Re: Thoughts on Net verses VB7


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


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

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

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


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

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

    Isn't that EASIER?

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

    -Rob

  7. #7
    Bob Butler Guest

    Re: Thoughts on Net verses VB7


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


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

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


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

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


    True, but VB wasn't.

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


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

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


    Maybe it shouldn't, but it does.

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


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

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


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




  8. #8
    Jonathan Allen Guest

    Re: Thoughts on Net verses VB7

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


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

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

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


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

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

    --
    Jonathan Allen


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




  9. #9
    Torsten Rienow Guest

    Re: Thoughts on Net verses VB7

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




  10. #10
    Torsten Rienow Guest

    Re: Thoughts on Net verses VB7

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



  11. #11
    Patrick Steele Guest

    Re: Thoughts on Net verses VB7

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


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

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

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

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

  12. #12
    Jonathan Allen Guest

    Re: Thoughts on Net verses VB7

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

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

    --
    Jonathan Allen


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




  13. #13
    Sjoerd Verweij Guest

    Re: Thoughts on Net verses VB7

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


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




  14. #14
    Jonathan Allen Guest

    Re: Thoughts on Net verses VB7

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

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

    --
    Jonathan Allen


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

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




  15. #15
    Sjoerd Verweij Guest

    Re: Thoughts on Net verses VB7

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


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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center