All this rhetoric is a little perplexing... - Page 11


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 11 of 26 FirstFirst ... 91011121321 ... LastLast
Results 151 to 165 of 384

Thread: All this rhetoric is a little perplexing...

  1. #151
    Phil Weber Guest

    Re: All this rhetoric is a little perplexing...

    > Fortunately, the CLR supports both types of transitions,
    > allowing both managed and native DLLs to coexist in a
    > single process and call from one DLL to another independent
    > of whether or not they are hosted inside the CLR


    Paulo: That's the approach I and others have been recommending for the past
    year: compile your existing VB6 code into ActiveX DLLs and call it from your
    new .NET apps. Or, create new functionality in .NET, and call it from your
    existing VB6 apps via COM interop. That's what Don Box is talking about in
    the article you cited, but this solution is unacceptable to Dan, Karl and
    others.
    ---
    Phil Weber



  2. #152
    Kunle Odutola Guest

    Re: All this rhetoric is a little perplexing...


    "Michael (michka) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote
    in message news:3c62b9fd$3@10.1.10.29...
    > "Bob" <no@spam.com> wrote...
    >
    > > Why in the world would I want to do that?

    >
    > You keep talking about how the conversion wixzard helps -- it does nothing
    > for new code you write in VB.Net, obviously.


    If you type Pascal, C++ or even old BASIC syntax into VB.NET who is to
    blame?.
    The conversion wizard or the milkman? <g>

    Kunle



  3. #153
    Dan Barclay Guest

    Re: All this rhetoric is a little perplexing...

    On Thu, 7 Feb 2002 20:55:22 -0000, "Paulo Costa" <pcosta@esagri.pt>
    wrote:

    >"Phil Weber" <pweber@nospam.fawcette.com> wrote:
    > > ..., I think if someone were able to develop a 100% reliable VB.NET
    >> preprocessor that could accept VB6 code and emit perfect VB.NET code at
    >> compile-time, people like Dan would probably be a lot less unhappy.

    >
    >Phil,
    >
    >I'm one of the *people like Dan* that would be happy if they allowed us to
    >make a smooth move, replacing gradually the existing code without such a
    >break.


    There are a bunch of us. Wait 'till the rest of the crew figures out
    what's happened.

    >In "Migrating Native Code to the .NET CLR", from the May 2001 issue of MSDN
    >Magazine, Don Box wrote:
    >
    ><QUOTE> ... Fortunately, the CLR supports both types of transitions,
    >allowing both managed and native DLLs to coexist in a single process and
    >call from one DLL to another independent of whether or not they are hosted
    >inside the CLR.... <UNQUOTE>


    Clever idea, except that it still leaves your core code library in win
    com objects.

    I suppose some folks think I shoulda left it in 16bit DLL's when
    that's where it was.

    If you're going to move to a new platform, you move to a new platform.
    Straddling two leaves you with the restrictions of both.

    Example: Does somebody think there will be a Classic VB that will let
    you make native 64bit DLL's? C/C++ yup. VB nope.

    >Vb.Net could have been implemented without losing Language Compatibility
    >with Vb6.


    Yup. They sure missed the boat. I guess billions of lines of
    application code don't mean much to .NET's success.

    Dan

    Language Stability is a *feature* I wish VB had!
    (#6)

  4. #154
    Mike Mitchell Guest

    Re: All this rhetoric is a little perplexing...

    On Thu, 7 Feb 2002 10:21:20 -0800, "Phil Weber"
    <pweber@nospam.fawcette.com> wrote:

    >That said, I think if someone were able to develop a 100% reliable VB.NET
    >preprocessor that could accept VB6 code and emit perfect VB.NET code at
    >compile-time, people like Dan would probably be a lot less unhappy.


    That's a pretty tall order. Not people's happiness or the lack of it
    (likely more of the latter now), but that any converter could be
    relied upon to produce 100% reliable, nay, perfect VB.NET code from
    VB6 code. How would you rely on it? You would need to run such
    exhaustive checks that it would be 2020 before VB.NET could ever see
    the light of day. The whole edifice underlying VB.NET is TOTALLY, and
    I mean TOTALLY, different from VB6 or what VB6 runs on top of. There
    is NOTHING under the hood that is even remotely the same. The entire
    VB.NET model is a so-called "managed" system; you've got garbage
    collection; there is no DF; memory is managed differently; the
    compiler/IL stage is utterly dfifferent; the whole thing has to run
    within the .NET framework.

    With everything UNDER THE HOOD totally different, let alone the very
    many differences inside the cabin, the changes we've heard about, any
    converter would itself be a very, very major product in its own right.
    And it would cost a fortune to produce something like that.

    Because such a 100% converter is not going to be available and the
    actual converter seems like it's just being provided so that they can
    say they're providing one, I have to say that I believe Microsoft's
    original brief was that classic VB programmers would have three
    choices: Rewrite in VB.NET; Rewrite in C#; Or bugger off.

    MM

  5. #155
    Mike Mitchell Guest

    Re: All this rhetoric is a little perplexing...

    On Thu, 7 Feb 2002 13:35:57 -0800, "Phil Weber"
    <pweber@nospam.fawcette.com> wrote:

    >Paulo: That's the approach I and others have been recommending for the past
    >year: compile your existing VB6 code into ActiveX DLLs and call it from your
    >new .NET apps. Or, create new functionality in .NET, and call it from your
    >existing VB6 apps via COM interop. That's what Don Box is talking about in
    >the article you cited, but this solution is unacceptable to Dan, Karl and
    >others.


    Hardly surprising. What you're saying sounds far too vague and
    simplistic. What about existing VB6 code that interacts with forms?
    Suppose an app has dozens of forms, how would it work? As for calling
    ..NET functionality from a VB6 app, why on earth would ANYone need to
    do that? Anything I want to do (and a lot more besides) I can do in
    VB6 with the aid of API calls and third-party controls already! Why
    would I *want* to complicate matters by introducing a complete
    unknown, namely .NET, into the equation?

    MM

  6. #156
    Mike Mitchell Guest

    Re: All this rhetoric is a little perplexing...

    X-Newsreader: Forte Free Agent 1.21/32.243
    NNTP-Posting-Host: 217.134.70.197
    X-Trace: 7 Feb 2002 17:31:49 -0800, 217.134.70.197
    Lines: 32
    Path: 10.1.10.29
    Xref: 10.1.10.29 vb.dotnet.discussion:35908

    On Thu, 07 Feb 2002 16:33:03 -0600, Dan Barclay <Dan@MVPs.org> wrote:

    >Yup. They sure missed the boat. I guess billions of lines of
    >application code don't mean much to .NET's success.


    What it finally, ultimately comes down to is this: Microsoft blew it.
    No, wait! They blew it, sure, in the lack of compatibility stuff, the
    changes, etc. But more importantly they blew it because their
    fundamental idea of how an average VB programmers would react was
    wrong. I reckon they thought that 95% at least of ALL VB
    programmers/users/non-programmers/etc would welcome VB.NET with all
    the enthusiasm of a horny football player on prom night. They DID NOT
    EXPECT to have to deal with anything more than a very minor grumble or
    two.

    I am as certain as can be that if they could turn the clock back now,
    they would NOT produce VB.NET as it exists today. I believe that even
    if VB.NET still was to work within the .NET framwork, they would have
    ensured much more backward compatibilty, edit & continue WOULD NOT
    have been DIScontinued, intellisense and autocomplete WOULD work in
    the same way it does already and in exactly the same windows under
    exactly the same conditions. I think they've realised by now that they
    did blow it; but it's too late to do anything about it because the
    whole .NET paradigm is kind of self-referential. It is all part of a
    whole, and the whole is a sum of its parts. They cannot admit to
    anything, because that would deny everything. Possibly, after the
    official release, they will be in a better position to row back on
    some things. I remember reading some comments a few weeks ago in these
    ngs that they could be planning some kind of simplified version of
    VB.NET. Perhaps this will happen, but it still won't be VB6.

    MM

  7. #157
    Mike Mitchell Guest

    Re: All this rhetoric is a little perplexing...

    On Thu, 7 Feb 2002 07:01:19 -0800, "Michael \(michka\) Kaplan"
    <former_mvp@nospam.trigeminal.spamless.com> wrote:

    >"Bob" <no@spam.com> wrote...
    >
    >> Does the conversion utility handle this problem?

    >
    >No, because you cannot run a utility on your mind that tells you how to do
    >something that you used to know how to do. Only time can give you that.


    That's if you can overcome the feelings of rage, frustration and
    betrayal, while learning the new language, continuing to support the
    superseded language, and still find enough time to buy the razor
    blades.

    MM

  8. #158
    John Butler Guest

    Re: All this rhetoric is a little perplexing...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:3c63282a.3450114@news.devx.com...
    > On Thu, 7 Feb 2002 13:35:57 -0800, "Phil Weber"
    > <pweber@nospam.fawcette.com> wrote:
    >
    > Hardly surprising. What you're saying sounds far too vague and
    > simplistic. What about existing VB6 code that interacts with forms?
    > Suppose an app has dozens of forms, how would it work?


    What about them? You're betraying your own ignorance...you can have forms in
    VB Dlls, you know.. I have one system in MS Access which happily
    instantiates VB dlls which contain forms.
    Is there some problem I'm supposed to be aware of? heck..the VB Wizard
    dialog add-in creates a DLL with forms in it, so what is the problem (beside
    COM Interop overhead, that is)...

    As for calling
    > .NET functionality from a VB6 app, why on earth would ANYone need to
    > do that? Anything I want to do (and a lot more besides) I can do in
    > VB6 with the aid of API calls and third-party controls already! Why
    > would I *want* to complicate matters by introducing a complete
    > unknown, namely .NET, into the equation?


    <Sigh> Mike...you _really_ owe it to yourself (and all of us) to play with
    DotNet a little first before you make statements like that. A lot of
    previously arcane API calls etc are SIMPLIFIED vastly because they're just
    part of the framework now.

    You know I'm not a zealot on DotNet...but geesh...you're not speaking from
    such a position of weakness here (in terms of your knowledge of DotNet) that
    I can't help butting into (this) rant...







  9. #159
    John Butler Guest

    Re: All this rhetoric is a little perplexing...


    "John Butler" <nospamjrbutler@btinternet.com> wrote in message
    news:3c632e8a$1@10.1.10.29...
    ....you're not speaking from such a position of weakness here (in terms of
    your knowledge of DotNet) that> I can't help butting into (this) rant...

    I meant: you ARE speaking from such a position of weakness here




  10. #160
    John Butler Guest

    Re: All this rhetoric is a little perplexing...


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:3c632d1d.4717276@news.devx.com...
    > That's if you can overcome the feelings of rage, frustration and
    > betrayal, while learning the new language, continuing to support the
    > superseded language, and still find enough time to buy the razor
    > blades.


    Hmmmm

    I've gotten over the rage, am learning the "new" language and still writing
    VB6 code every day...

    ....and Tesco on-line delivers razor blades <grin>


    hmmmm2: I did catch myself writing "Dim myVar as String = "foo" " in VB6
    today though...




  11. #161
    Karl E. Peterson Guest

    Re: All this rhetoric is a little perplexing...

    Hi Paulo --

    > You gave me a great idea, no registry or big runtimes!! That's what I was
    > asking for. Have you tested it? I'm going to do.


    Tested what? I routinely use VB3 to write AutoRun apps, yeah. Simple as could be.
    Just put the runtime in the same directory as the EXE.

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


    "Paulo Costa" <pcosta@esagri.pt> wrote in message news:3c625a5a@10.1.10.29...
    > Karl,
    >
    > > Yep! In Fact, VB3 is *still* the most straight-forward way to build a CD

    > AutoRun
    > > app. (Try that with VFred.) It's actually a little amusing, now that I

    > think about
    > > it -- just picture all those flashy new .NOT apps being distributed with

    > VBRUN300.DLL
    > > on the same CD! <LOL>

    >
    > You gave me a great idea, no registry or big runtimes!! That's what I was
    > asking for. Have you tested it? I'm going to do.
    >
    > Paulo Costa
    > ----------
    > Vb.Net could have been implemented without losing Language Compatibility
    > with Vb6.
    >
    >
    >
    >



  12. #162
    Karl E. Peterson Guest

    Re: All this rhetoric is a little perplexing...

    Hi Phil --

    > > Fortunately, the CLR supports both types of transitions,
    > > allowing both managed and native DLLs to coexist in a
    > > single process and call from one DLL to another independent
    > > of whether or not they are hosted inside the CLR

    >
    > Paulo: That's the approach I and others have been recommending for the past
    > year: compile your existing VB6 code into ActiveX DLLs and call it from your
    > new .NET apps. Or, create new functionality in .NET, and call it from your
    > existing VB6 apps via COM interop. That's what Don Box is talking about in
    > the article you cited, but this solution is unacceptable to Dan, Karl and
    > others.


    Since you feel qualified to speak on my behalf, I'd appreciate that you at least not
    make *too* sweeping of generalizations. Were that the only issue, it's likely
    something I could live with. Rather, the issues I'm concerned about are what brings
    this situation to the fore, not the situation itself. I'm *stunned* that identical
    code can produce two different results and they call it a single language. Anyway,
    your simplification is pretty gross, and certainly I'd expect more from you.

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


  13. #163
    Karl E. Peterson Guest

    Re: All this rhetoric is a little perplexing...

    Hi Bob --

    Why don't you get back to us after you've run a couple simple little samples through
    that so-called "conversion" wizard. Here's a few:
    http://www.mvps.org/vb/samples.htm -- Microsoft couldn't convert *any* of them using
    the wizard. Can you?

    Thanks... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


    "Bob" <no@spam.com> wrote in message news:MPG.16cc518425d269c2989684@news.devx.com...
    > In article <c7k36u8unk2v4b4b9mjbklf8bm7stbu3f6@4ax.com>, Dan@MVPs.org says...
    > > Bob,
    > >
    > > The issue here isn't whether I can write code that works. Rest
    > > assured that I can.
    > >
    > > The issue is whether code I've *already* written and tested will work.
    > >
    > > Having said that (yes Phil, there is a reason I'm not clipping this),
    > > READ through the mental exercise you just went through for a simple
    > > multiplication exercise.
    > >
    > > Now think of every place a "changed" syntax feature may be used in a
    > > large application. Get it now??
    > >
    > > Dan
    > >

    > Does the conversion utility handle this problem?
    >
    > Bob



  14. #164
    Gary Nelson Guest

    Re: All this rhetoric is a little perplexing...

    Phil,

    > That said, I think if someone were able to develop a 100% reliable VB.NET
    > preprocessor that could accept VB6 code and emit perfect VB.NET code at
    > compile-time, people like Dan would probably be a lot less unhappy.


    I'd vote for that. I don't even insist on a 100% conversion, I would be
    happy though with at least 95%.

    Gary



  15. #165
    Rob Teixeira Guest

    Re: All this rhetoric is a little perplexing...



    Now, I'm not trying to defend the wizard (since I've been saying all along
    it'll be the butt of many a joke anyway), but let's consider a few things
    as well:

    First of all, a large part of those samples are using techniques not native
    to core BASIC. A large number of them use undocumented functions. While I
    personally think the samples are all cool, since I practically made a career
    of writing tricky code in old VB, I think it's fair to assume that a conversion
    wizard would have trouble with that code due to its very nature.

    Secondly, this does nothing to address the issue that some of the code isn't
    even needed, so why bother converting. For example, your translucent sample
    (which again, is pretty cool), which is wrapped up in 10 kb of code in a
    sample with 14 files, can be accomplished simply with one form and setting
    the Opacity property to a percentage, or Transparency property to a color.

    Again, this isn't meant to get the wizard off the hook. I think the ideal
    is to have 100% usable code. However, it's the extreme approach of implying
    that all conversion is going to be the worst **** that i have a problem with.
    Rather, I'd like to discuss what are really going to be the real issues,
    and help people get around them - after all, VB.NET is released, there's
    no use crying over spilled milk. At the same time, I'd like to encourage
    people to assess the *real* effort involved with converting their code, since
    it will be relatively simple for some, and relatively painful for others,
    *depending on their code* - rather than just implying it all sucks.

    -Rob


    "Karl E. Peterson" <karl@mvps.org> wrote:
    >Hi Bob --
    >
    >Why don't you get back to us after you've run a couple simple little samples

    through
    >that so-called "conversion" wizard. Here's a few:
    >http://www.mvps.org/vb/samples.htm -- Microsoft couldn't convert *any* of

    them using
    >the wizard. Can you?
    >
    >Thanks... Karl
    >--
    >[Microsoft Basic: 1976-2001, RIP]
    >



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