Upgrading older VB programs (sans Project Files) to VB.NET

Discussion in 'Microsoft VB .NET' started by Ubiquitous, Jan 4, 2012.

  1. Ubiquitous

    Ubiquitous Guest

    I have some old Visual Basic programs I'd like to upgrade to .NET because
    they currently require obsolete drivers like "VBRUN300.DLL" to run. I
    attempted to use the upgrade wizard but it appears it requires a project
    file and I only have .FRM, .FRX, and Make files, like this one:

    >VERSION 2.00
    >Begin Form Form1
    > BackColor = &H00C0C0C0&
    > BorderStyle = 1 'Fixed Single
    > Caption = "Dice roller"
    > ClientHeight = 1950
    > ClientLeft = 1230
    > ClientTop = 2625
    > ClientWidth = 2295
    > Height = 2355
    > Icon = SRDICE01.FRX:0000
    > Left = 1170
    > LinkTopic = "Form1"
    > MaxButton = 0 'False
    > ScaleHeight = 1950
    > ScaleWidth = 2295
    > Top = 2280
    > Width = 2415
    > Begin TextBox Text3
    > BackColor = &H00000000&
    > ForeColor = &H00FFFFFF&
    > Height = 285
    > Left = 1200
    > TabIndex = 7
    > Text = "0"
    > Top = 1560
    > Width = 975
    > End
    > Begin TextBox Text2
    > Height = 285
    > Left = 1560
    > TabIndex = 2
    > Text = "4"
    > Top = 480
    > Width = 615
    > End
    > Begin ListBox List1
    > Columns = 3
    > Height = 1005
    > Left = 120
    > Sorted = -1 'True
    > TabIndex = 4
    > Top = 840
    > Width = 975
    > End
    > Begin CommandButton Command1
    > BackColor = &H00C0C0C0&
    > Caption = "&Roll"
    > Default = -1 'True
    > Height = 375
    > Left = 1200
    > TabIndex = 3
    > Top = 840
    > Width = 975
    > End
    > Begin TextBox Text1
    > Height = 285
    > Left = 1560
    > TabIndex = 1
    > Text = "1"
    > Top = 120
    > Width = 615
    > End
    > Begin Label Label1
    > BackColor = &H00C0C0C0&
    > Caption = "Successes"
    > Height = 255
    > Index = 2
    > Left = 1200
    > TabIndex = 6
    > Top = 1320
    > Width = 975
    > End
    > Begin Label Label1
    > BackColor = &H00C0C0C0&
    > Caption = "&Target number"
    > Height = 255
    > Index = 1
    > Left = 120
    > TabIndex = 5
    > Top = 480
    > Width = 1335
    > End
    > Begin Label Label1
    > BackColor = &H00C0C0C0&
    > Caption = "&Number of dice"
    > Height = 255
    > Index = 0
    > Left = 120
    > TabIndex = 0
    > Top = 120
    > Width = 1335
    > End
    >End
    >
    >Sub Command1_Click ()
    >
    > list1.Clear
    > nsucc = 0
    > For i = 1 To Val(text1.Text)
    > v = 0
    >reloop:
    > v = v + Int(Rnd(6) * 6 + 1)
    > If v Mod 6 = 0 Then GoTo reloop
    > If v >= Val(text2.Text) Then nsucc = nsucc + 1
    > list1.AddItem Format$(v, "00")
    > Next
    > text3.Text = Format$(nsucc)
    >
    >End Sub


    I have a feeling these pre-date VB 6 but wondered if there is a way to
    systematically perform the upgrade without a project file instead of
    making them from scratch.
     
    Ubiquitous, Jan 4, 2012
    #1
    1. Advertisements

  2. Ubiquitous

    Mayayana Guest

    You've posted to a ridiculous number of groups, some of which
    are VB and some of which are VB.Net. VB and VB.Net are very
    different things that share only a similar appearance. VB is for
    Windows compiled software and is COM-centric. VB.Net is a Java
    clone using a VM, designed to compete with Java in RAD server-
    side software.

    Your question should be posted only to .Net groups -- whis would
    be the last 2 groups in your list. If you don't get an answer there,
    you can try the online forums. Microsoft has discontinued
    support for their own newsgroups and any MVP who wants to
    keep a gold star on his/her forehead sticks to the online forums.
    The forums are web-based. hard to use, moderated, and really
    little more than a marketing device... but they're all that's left
    in terms of Microsoft-supported discussion. You can find listings
    here:

    http://social.microsoft.com/Forums/en-US/categories
    http://social.technet.microsoft.com/forums/en-US/categories/
    http://social.msdn.microsoft.com/Forums/en/categories/
     
    Mayayana, Jan 5, 2012
    #2
    1. Advertisements

  3. Ubiquitous <> schrieb im Beitrag
    <je49ej$37u$>...
    > I have some old Visual Basic programs I'd like to upgrade to .NET because


    > they currently require obsolete drivers like "VBRUN300.DLL" to run. I
    > attempted to use the upgrade wizard but it appears it requires a project
    > file and I only have .FRM, .FRX, and Make files, like this one:


    Those files you are naming "make files" in fact are _the project files_. 16
    bit VB (in your case VB 3.0) used the extension ".MAK" for project files.
    It is rather unlikely that the upgrade wizard accepts project files from a
    16 bit version of VB.

    --
    Thorsten Albers

    gudea at gmx.de
     
    Thorsten Albers, Jan 5, 2012
    #3
  4. Ubiquitous

    mcnews Guest

    plus if you do get to a point where you can convert it will use a VB library/namespace so you wouldn't truly be converting. vb.net is not hard to learn and google is your friend.
     
    mcnews, Jan 5, 2012
    #4
  5. Ubiquitous stellte die Frage:
    > I have some old Visual Basic programs I'd like to upgrade to .NET because
    > they currently require obsolete drivers like "VBRUN300.DLL" to run. I
    > attempted to use the upgrade wizard but it appears it requires a project
    > file and I only have .FRM, .FRX, and Make files, like this one:
    >
    >> VERSION 2.00
    >> Begin Form Form1


    [...]

    >> End
    >>
    >> Sub Command1_Click ()
    >>
    >> list1.Clear
    >> nsucc = 0
    >> For i = 1 To Val(text1.Text)
    >> v = 0
    >> reloop:
    >> v = v + Int(Rnd(6) * 6 + 1)
    >> If v Mod 6 = 0 Then GoTo reloop
    >> If v >= Val(text2.Text) Then nsucc = nsucc + 1
    >> list1.AddItem Format$(v, "00")
    >> Next
    >> text3.Text = Format$(nsucc)
    >>
    >> End Sub

    >
    > I have a feeling these pre-date VB 6 but wondered if there is a way to
    > systematically perform the upgrade without a project file instead of
    > making them from scratch.


    This is a 16-bit VB3 project. It's project file is the .MAK file.
    You are lucky, because the .FRM and .BAS files were saved as text
    (default was Binary).
    But you still must first upgrade the projects to 32-bit (VB5 or VB6),
    then you can try the upgrade wizard to .net.

    Any as binaries saved VB3 projects can't be opened by VB5/6, you must
    open those project again in VB3 and select the option "save as text"
    before saving.

    Having said all this, I think it's better to begin all these old programs
    from scratch in VB.NET.
    If it's a small program, it's still probably faster.
    If it's a large project, the upgrade wizzard will produce code that
    needs much work to get it running and the code will still be a mess.

    Helmut.
     
    Helmut_Meukel, Jan 5, 2012
    #5
  6. Ubiquitous

    Auric__ Guest

    Helmut_Meukel wrote:

    > Having said all this, I think it's better to begin all these old programs
    > from scratch in VB.NET.
    > If it's a small program, it's still probably faster.
    > If it's a large project, the upgrade wizzard will produce code that
    > needs much work to get it running and the code will still be a mess.


    Very much agreed. Restarting from scratch is likely to give you an overall
    better program than importing, IMO.

    --
    The more you say, the less I understand.
     
    Auric__, Jan 6, 2012
    #6
  7. Ubiquitous

    Tony Toews Guest

    On Wed, 04 Jan 2012 18:23:10 -0500, Ubiquitous <>
    wrote:

    >I have some old Visual Basic programs I'd like to upgrade to .NET because
    >they currently require obsolete drivers like "VBRUN300.DLL" to run.


    Or upgrade them to VB6 as the VB6 runtime is part of the OS from
    Windows 2000 to Windows 8. If you can locate the VB6 IDE/compiler
    for a decent price on Ebay then that may be all that is required.
    Unless third party controls are involved but there likely are
    replacements available.

    I do see several on eBay for about $140 and up. Sort by price to get
    the books out of the way.

    Note that the eBay item "Microsoft MSDN Library Visual Studio 6 6.0
    Basic Help" is just the help for VB6/VS6 and does not contain the
    actual IDE/compiler.

    (Sheesh, why would you be selling a VB6 certification exam guide on
    eBay?)

    Tony
    --
    Tony Toews, Microsoft Access MVP
    Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
    Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
    For a convenient utility to keep your users FEs and other files
    updated see http://www.autofeupdater.com/
     
    Tony Toews, Jan 10, 2012
    #7
  8. Ubiquitous

    Mayayana Guest

    | Or upgrade them to VB6 as the VB6 runtime is part of the OS from
    | Windows 2000 to Windows 8.

    Indeed. One wonders about the relevance of .Net going forward.
    Especially on the Desktop. (Presumably it will still be relevant
    on corporate servers.) As I understand it, Windows 8 will have
    Metro apps, which will be little more than scripted webpages, must
    be approved by MS, and MS gets a cut of any sales income.

    Win8 is still expected to have normal compiled software, which
    will not suffer the restrictions and control of Metro apps, but will
    be cast as fuddy duddy technology.

    VB is still relevant for compiled software. Javascript is increasingly
    relevant for $2 trinket software and games. .Net is not optimized
    for either. It's hard to find a clear, complete story on Win8 and
    Metro, but it sounds like .Net will be "repurposed" as a javascript
    IDE.
     
    Mayayana, Jan 10, 2012
    #8
  9. Ubiquitous

    Tom Shelton Guest

    Mayayana formulated the question :
    >> Or upgrade them to VB6 as the VB6 runtime is part of the OS from
    >> Windows 2000 to Windows 8.

    >
    > Indeed. One wonders about the relevance of .Net going forward.
    > Especially on the Desktop. (Presumably it will still be relevant
    > on corporate servers.) As I understand it, Windows 8 will have
    > Metro apps, which will be little more than scripted webpages, must
    > be approved by MS, and MS gets a cut of any sales income.
    >
    > Win8 is still expected to have normal compiled software, which
    > will not suffer the restrictions and control of Metro apps, but will
    > be cast as fuddy duddy technology.
    >
    > VB is still relevant for compiled software. Javascript is
    > increasingly relevant for $2 trinket software and games. .Net is not
    > optimized for either. It's hard to find a clear, complete story on
    > Win8 and Metro, but it sounds like .Net will be "repurposed" as a
    > javascript IDE.


    You seriously don't know what your talking about... .NET is a BIG part
    of windows 8 and metro. HTML/JavaScript is just one way to create
    limited functionality metro apps. Most apps will be C#/VB or C++ using
    wpf as the front end. Some parts of the .net runtime will be mapped to
    winrt - but, .net is not dead.

    --
    Tom Shelton
     
    Tom Shelton, Jan 10, 2012
    #9
  10. Ubiquitous

    Mayayana Guest

    | You seriously don't know what your talking about... .NET is a BIG part
    | of windows 8 and metro.

    We'll see. From what I read WinRT is as much of
    a wrapper-pretending-to-be-an-API as .Net is. May
    as well script it.

    Geez, it's taking a lot to rouse you
    out of the woodwork these days, Tom. :)

    | HTML/JavaScript is just one way to create
    | limited functionality metro apps. Most apps will be C#/VB or C++ using
    | wpf as the front end. Some parts of the .net runtime will be mapped to
    | winrt - but, .net is not dead.
    |
    | --
    | Tom Shelton
    |
    |
     
    Mayayana, Jan 10, 2012
    #10
  11. Ubiquitous

    Schmidt Guest

    Am 10.01.2012 18:14, schrieb Tom Shelton:

    > ... but, .net is not dead.


    It's now in the same way "not dead", as VB6 is...
    Welcome to the club!

    Really funny, that we are back now, to the combination
    of 'C++ and COM' as the only recommended way to develop
    serious and new "native Desktop-Apps" (because any other
    (MS-)tools cannot be considered "future-proof" or
    "safe with regards to line-of-code-investments").

    IIRC we had this C++/COM combination already some 15 years ago,
    followed up by VB5/6-RAD to "develop COM-Apps even faster".
    So VB6 is yet a good tool, working "directly on top" of
    the current "state of the art tech".

    That much to selling us .NET as "technologic innovation"
    and urging us "to move on".
    Seems that the serious code-bases will always be C/C++ (as the
    best compromise, to abstract a language from the hardware).

    All the rest on top of it is (at least in MS' Book)
    apparently considered "throw-away software".

    The invention of COM, as a kind of objectoriented,
    (class-hosting and selfdescribing) library-format
    seems at least a well-surviving idea. As was VB-classic,
    as a glue-language for COMponents as well. It does
    its job even today, and will do so also on Win8.

    Aside from, that the new RAD-kid on the "blog" is now
    apparently the HTML/JS combination (and accompanying new
    IDEs, to "glue stuff together this way", including
    automatic uploads into the great new world of App-Stores).

    Let's see, how this works out - and what VB6/COM-based
    Apps on the Win8-Desktop are good for in the long run.

    Olaf
     
    Schmidt, Jan 11, 2012
    #11
  12. Ubiquitous

    Henning Guest

    "Schmidt" <> skrev i meddelandet
    news:jekpsc$e1c$...
    > Am 10.01.2012 18:14, schrieb Tom Shelton:
    >
    >> ... but, .net is not dead.

    >
    > It's now in the same way "not dead", as VB6 is...
    > Welcome to the club!
    >
    > Really funny, that we are back now, to the combination
    > of 'C++ and COM' as the only recommended way to develop
    > serious and new "native Desktop-Apps" (because any other
    > (MS-)tools cannot be considered "future-proof" or
    > "safe with regards to line-of-code-investments").
    >
    > IIRC we had this C++/COM combination already some 15 years ago,
    > followed up by VB5/6-RAD to "develop COM-Apps even faster".
    > So VB6 is yet a good tool, working "directly on top" of
    > the current "state of the art tech".
    >
    > That much to selling us .NET as "technologic innovation"
    > and urging us "to move on".
    > Seems that the serious code-bases will always be C/C++ (as the
    > best compromise, to abstract a language from the hardware).
    >
    > All the rest on top of it is (at least in MS' Book)
    > apparently considered "throw-away software".
    >
    > The invention of COM, as a kind of objectoriented,
    > (class-hosting and selfdescribing) library-format
    > seems at least a well-surviving idea. As was VB-classic,
    > as a glue-language for COMponents as well. It does
    > its job even today, and will do so also on Win8.
    >
    > Aside from, that the new RAD-kid on the "blog" is now
    > apparently the HTML/JS combination (and accompanying new
    > IDEs, to "glue stuff together this way", including
    > automatic uploads into the great new world of App-Stores).
    >
    > Let's see, how this works out - and what VB6/COM-based
    > Apps on the Win8-Desktop are good for in the long run.
    >
    > Olaf
    >


    Also code safety:
    Your .NET decompiler alternative has arrived! Telerik JustDecompile is a
    powerful yet free-of-charge tool, which enables you to effortlessly explore
    and analyze compiled .NET assemblies at the click of a button.

    /Henning
     
    Henning, Jan 12, 2012
    #12
  13. Ubiquitous

    Tom Shelton Guest

    Schmidt expressed precisely :
    > Am 10.01.2012 18:14, schrieb Tom Shelton:
    >
    >> ... but, .net is not dead.

    >
    > It's now in the same way "not dead", as VB6 is...
    > Welcome to the club!
    >


    VB6 has been deprecated - .NET has not. It is still being actively
    developed. New capabilities, new technologies being added, and new
    versions being produced. So, I fail to see how .NET is anything like
    VB6. Sure, there will be some changes comming. It's 10 year old tech
    - of course it's going to change, and I expect at some point it will be
    deprecated...

    > Really funny, that we are back now, to the combination
    > of 'C++ and COM' as the only recommended way to develop
    > serious and new "native Desktop-Apps" (because any other
    > (MS-)tools cannot be considered "future-proof" or
    > "safe with regards to line-of-code-investments").
    >


    What I want to know is where you got that C++ and COM is the only
    recommended way to develop metro apps. Have you even loaded VS11? I
    guarentee you that VB and C# are there.

    > IIRC we had this C++/COM combination already some 15 years ago,
    > followed up by VB5/6-RAD to "develop COM-Apps even faster".
    > So VB6 is yet a good tool, working "directly on top" of
    > the current "state of the art tech".


    I think it's more like C++/WinRT - COM is part of winrt, but asfict
    it's not out in the forefront. Just like COM is part of .NET - but,
    it's pretty much invisible for the most part.

    > That much to selling us .NET as "technologic innovation"
    > and urging us "to move on".
    > Seems that the serious code-bases will always be C/C++ (as the
    > best compromise, to abstract a language from the hardware).
    >
    > All the rest on top of it is (at least in MS' Book)
    > apparently considered "throw-away software".
    >
    > The invention of COM, as a kind of objectoriented,
    > (class-hosting and selfdescribing) library-format
    > seems at least a well-surviving idea. As was VB-classic,
    > as a glue-language for COMponents as well. It does
    > its job even today, and will do so also on Win8.
    >
    > Aside from, that the new RAD-kid on the "blog" is now
    > apparently the HTML/JS combination (and accompanying new
    > IDEs, to "glue stuff together this way", including
    > automatic uploads into the great new world of App-Stores).
    >
    > Let's see, how this works out - and what VB6/COM-based
    > Apps on the Win8-Desktop are good for in the long run.
    >
    > Olaf


    You are living in some sort of dream world, where all tech is good
    forever. Doesn't happen. And, I seriously don't see how my .net code
    base is in anyway threatend going forward at this time. Might have to
    do some new UI's - but, since all of my real code is in libraries, I
    really don't see this as a huge deal.

    --
    Tom Shelton
     
    Tom Shelton, Jan 12, 2012
    #13
  14. Ubiquitous

    GS Guest

    Henning submitted this idea :
    > "Schmidt" <> skrev i meddelandet
    > news:jekpsc$e1c$...
    >> Am 10.01.2012 18:14, schrieb Tom Shelton:
    >>
    >>> ... but, .net is not dead.

    >>
    >> It's now in the same way "not dead", as VB6 is...
    >> Welcome to the club!
    >>
    >> Really funny, that we are back now, to the combination
    >> of 'C++ and COM' as the only recommended way to develop
    >> serious and new "native Desktop-Apps" (because any other
    >> (MS-)tools cannot be considered "future-proof" or
    >> "safe with regards to line-of-code-investments").
    >>
    >> IIRC we had this C++/COM combination already some 15 years ago,
    >> followed up by VB5/6-RAD to "develop COM-Apps even faster".
    >> So VB6 is yet a good tool, working "directly on top" of
    >> the current "state of the art tech".
    >>
    >> That much to selling us .NET as "technologic innovation"
    >> and urging us "to move on".
    >> Seems that the serious code-bases will always be C/C++ (as the
    >> best compromise, to abstract a language from the hardware).
    >>
    >> All the rest on top of it is (at least in MS' Book)
    >> apparently considered "throw-away software".
    >>
    >> The invention of COM, as a kind of objectoriented,
    >> (class-hosting and selfdescribing) library-format
    >> seems at least a well-surviving idea. As was VB-classic,
    >> as a glue-language for COMponents as well. It does
    >> its job even today, and will do so also on Win8.
    >>
    >> Aside from, that the new RAD-kid on the "blog" is now
    >> apparently the HTML/JS combination (and accompanying new
    >> IDEs, to "glue stuff together this way", including
    >> automatic uploads into the great new world of App-Stores).
    >>
    >> Let's see, how this works out - and what VB6/COM-based
    >> Apps on the Win8-Desktop are good for in the long run.
    >>
    >> Olaf
    >>

    >
    > Also code safety:
    > Your .NET decompiler alternative has arrived! Telerik JustDecompile is a
    > powerful yet free-of-charge tool, which enables you to effortlessly explore
    > and analyze compiled .NET assemblies at the click of a button.
    >
    > /Henning


    This is why LogicNP has available Crypto Obfuscator to thwart
    decompiling .Net apps.

    --
    Garry

    Free usenet access at http://www.eternal-september.org
    ClassicVB Users Regroup! comp.lang.basic.visual.misc
     
    GS, Jan 13, 2012
    #14
  15. Ubiquitous

    Schmidt Guest

    Am 12.01.2012 17:34, schrieb Tom Shelton:
    > Schmidt expressed precisely :
    >> Am 10.01.2012 18:14, schrieb Tom Shelton:
    >>
    >>> ... but, .net is not dead.

    >>
    >> It's now in the same way "not dead", as VB6 is...
    >> Welcome to the club!
    >>

    >
    > VB6 has been deprecated - .NET has not.

    The VB6-IDE is not *supported* anymore - the essential
    technology under the covers (an underlying C/C++ compiler
    and COM is by no means deprecated).

    On the other hand, Winforms are deprecated in
    the meantime, as is the usage of Silverlight...
    (more to come, just wait).

    >> Really funny, that we are back now, to the combination
    >> of 'C++ and COM' as the only recommended way to develop
    >> serious and new "native Desktop-Apps" (because any other
    >> (MS-)tools cannot be considered "future-proof" or
    >> "safe with regards to line-of-code-investments").
    >>

    >
    > What I want to know is where you got that C++ and COM is
    > the only recommended way to develop metro apps.


    I was not talking about "Metro-Apps" - I was talking
    about "native Desktop-Apps" - and the only secure
    way (the word "recommended" was not that well-choosen)
    in terms of code-investments is apparently C/C++
    (33 year old "technology" in the meantime).


    > You are living in some sort of dream world, where all
    > tech is good forever. Doesn't happen.

    That's what you try to sell us for years now.
    I say, tech *can* be "good forever", when there's not
    much left to optimize (just look at "the wheel" <g>).

    And apparently C/C++ is such a wheel.
    Everything on top of it (in case you want to
    construct a bicycle for example) - is just
    different shortcuts (e.g. if you use different
    frames (aka frameworks/libraries) in combination
    with a highlevel-language, to be able to
    build "customized cycles" a little bit faster).

    And the VBClassic-runtime-lib (in conjunction with
    the VBClassic language) does its job just fine
    at the moment - as well as in the near future.

    And it is "less far" from the current base-tech
    (C/C++ and COM) than .NET is - that's my whole point.

    It remains to be seen (I'd say, let's talk about it again
    in 10 years or so), whether a thin runtime-layer on top
    of C/C++ - or a bloated VM, will better survive over time.

    From my point of view, it is you who's living in a
    dream world, not acknowledging, that both approaches
    (from MS' point of view) were only temporary cash-cows,
    sold to "crowds of RAD-believers".

    The difference between .NET- and "still VB6"-users is,
    that the latter ones recognized "the pattern" much
    earlier (fool me once) - and didn't invest that much
    time again into "the next distraction".

    Olaf
     
    Schmidt, Jan 13, 2012
    #15
  16. Ubiquitous

    GS Guest

    Schmidt has brought this to us :
    > Am 12.01.2012 17:34, schrieb Tom Shelton:
    >> Schmidt expressed precisely :
    >>> Am 10.01.2012 18:14, schrieb Tom Shelton:
    >>>
    >>>> ... but, .net is not dead.
    >>>
    >>> It's now in the same way "not dead", as VB6 is...
    >>> Welcome to the club!
    >>>

    >>
    >> VB6 has been deprecated - .NET has not.

    > The VB6-IDE is not *supported* anymore - the essential
    > technology under the covers (an underlying C/C++ compiler
    > and COM is by no means deprecated).
    >
    > On the other hand, Winforms are deprecated in
    > the meantime, as is the usage of Silverlight...
    > (more to come, just wait).
    >
    >>> Really funny, that we are back now, to the combination
    >>> of 'C++ and COM' as the only recommended way to develop
    >>> serious and new "native Desktop-Apps" (because any other
    >>> (MS-)tools cannot be considered "future-proof" or
    >>> "safe with regards to line-of-code-investments").
    >>>

    >>
    >> What I want to know is where you got that C++ and COM is
    >> the only recommended way to develop metro apps.

    >
    > I was not talking about "Metro-Apps" - I was talking
    > about "native Desktop-Apps" - and the only secure
    > way (the word "recommended" was not that well-choosen)
    > in terms of code-investments is apparently C/C++
    > (33 year old "technology" in the meantime).
    >
    >
    >> You are living in some sort of dream world, where all
    >> tech is good forever. Doesn't happen.

    > That's what you try to sell us for years now.
    > I say, tech *can* be "good forever", when there's not
    > much left to optimize (just look at "the wheel" <g>).
    >
    > And apparently C/C++ is such a wheel.
    > Everything on top of it (in case you want to
    > construct a bicycle for example) - is just
    > different shortcuts (e.g. if you use different
    > frames (aka frameworks/libraries) in combination
    > with a highlevel-language, to be able to
    > build "customized cycles" a little bit faster).
    >
    > And the VBClassic-runtime-lib (in conjunction with
    > the VBClassic language) does its job just fine
    > at the moment - as well as in the near future.
    >
    > And it is "less far" from the current base-tech
    > (C/C++ and COM) than .NET is - that's my whole point.
    >
    > It remains to be seen (I'd say, let's talk about it again
    > in 10 years or so), whether a thin runtime-layer on top
    > of C/C++ - or a bloated VM, will better survive over time.
    >
    > From my point of view, it is you who's living in a
    > dream world, not acknowledging, that both approaches
    > (from MS' point of view) were only temporary cash-cows,
    > sold to "crowds of RAD-believers".
    >
    > The difference between .NET- and "still VB6"-users is,
    > that the latter ones recognized "the pattern" much
    > earlier (fool me once) - and didn't invest that much
    > time again into "the next distraction".
    >
    > Olaf


    Very well said!

    --
    Garry

    Free usenet access at http://www.eternal-september.org
    ClassicVB Users Regroup! comp.lang.basic.visual.misc
     
    GS, Jan 13, 2012
    #16
  17. Ubiquitous

    Tom Shelton Guest

    Schmidt was thinking very hard :
    > Am 12.01.2012 17:34, schrieb Tom Shelton:
    >> Schmidt expressed precisely :
    >>> Am 10.01.2012 18:14, schrieb Tom Shelton:
    >>>
    >>>> ... but, .net is not dead.
    >>>
    >>> It's now in the same way "not dead", as VB6 is...
    >>> Welcome to the club!
    >>>

    >>
    >> VB6 has been deprecated - .NET has not.

    > The VB6-IDE is not *supported* anymore - the essential
    > technology under the covers (an underlying C/C++ compiler
    > and COM is by no means deprecated).
    >
    > On the other hand, Winforms are deprecated in
    > the meantime, as is the usage of Silverlight...
    > (more to come, just wait).
    >


    I don't know if youv'e been paying attention... Win32 is pretty much
    deprecated.

    >>> Really funny, that we are back now, to the combination
    >>> of 'C++ and COM' as the only recommended way to develop
    >>> serious and new "native Desktop-Apps" (because any other
    >>> (MS-)tools cannot be considered "future-proof" or
    >>> "safe with regards to line-of-code-investments").
    >>>

    >>
    >> What I want to know is where you got that C++ and COM is
    >> the only recommended way to develop metro apps.

    >
    > I was not talking about "Metro-Apps" - I was talking
    > about "native Desktop-Apps" - and the only secure
    > way (the word "recommended" was not that well-choosen)
    > in terms of code-investments is apparently C/C++
    > (33 year old "technology" in the meantime).
    >
    >


    Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
    the api. Win32 and the old dekstop are legacy.

    I still fail to see your point... Winforms/silverlight and all .net
    apps will continue to run and function just as they always have on the
    legacy desktop. What is it that you are trying to get at here?

    >> You are living in some sort of dream world, where all
    >> tech is good forever. Doesn't happen.

    > That's what you try to sell us for years now.
    > I say, tech *can* be "good forever", when there's not
    > much left to optimize (just look at "the wheel" <g>).
    >


    Sorry - but, if that was the case we would all still be using COBOL and
    Fortran.

    > And apparently C/C++ is such a wheel.


    C/C++ are fairly close to the metal - and I love them both. But, even
    they have evolved over the years. Have you been looking at the new
    standards? Lots of features we have in C# being added - lambdas, etc.

    > Everything on top of it (in case you want to
    > construct a bicycle for example) - is just
    > different shortcuts (e.g. if you use different
    > frames (aka frameworks/libraries) in combination
    > with a highlevel-language, to be able to
    > build "customized cycles" a little bit faster).
    >


    C++ are just layers on top of assembly. So what?

    > And the VBClassic-runtime-lib (in conjunction with
    > the VBClassic language) does its job just fine
    > at the moment - as well as in the near future.
    >


    Not in the new desktop. And, not on ARM. VB6 will continue to work on
    the legacy desktop, which we know will be phased out in the not to many
    versions hence.

    In other words - the end is nigh.

    > And it is "less far" from the current base-tech
    > (C/C++ and COM) than .NET is - that's my whole point.
    >


    C/C++ will not be using COM directly in the new paradigm. They, along
    with C#/VB/JavaScript will be using WinRT. WinRT does use COM - in
    fact, it's very important for the internals of WinRT, but the average
    C++ dev developing for the new desktop is not going to care about that.

    > It remains to be seen (I'd say, let's talk about it again
    > in 10 years or so), whether a thin runtime-layer on top
    > of C/C++ - or a bloated VM, will better survive over time.
    >


    You guys and your bloated VM thing are really getting tiresome.

    First off - the runtime is not a thin layer over c/c++. It is a layer
    over the win32 api - but, that is native code, ie machine code. It is
    irrelavent that a lot of it was done in C (and I mean straigth C).

    The framework, is a set of libraries - that is all. It doesn't all get
    loaded at runtime. They don't all get used by any single application.
    The size on disk and the download time of said framework is pretty much
    irrelavent give modern broadband and disk sizes. Both, of which are
    mostly irrelavent - since, like the VB6 runtimes - it is part of the
    base OS install now.

    You act as if I have some problem with C/C++? I do not. In fact, I
    love C++. It was my first programming language - I still do stuff in
    it on occasion. It's the love for C++ and C style syntax, that made me
    move to C# when I had to move to .NET.

    > From my point of view, it is you who's living in a
    > dream world, not acknowledging, that both approaches
    > (from MS' point of view) were only temporary cash-cows,
    > sold to "crowds of RAD-believers".
    >
    > The difference between .NET- and "still VB6"-users is,
    > that the latter ones recognized "the pattern" much
    > earlier (fool me once) - and didn't invest that much
    > time again into "the next distraction".


    That is simply the most ridiculous bunch of rubbish I have ever read.
    VB6 is simply irrelavent - and about to fade completely into the foot
    notes of history. If you can't see that, than you simply aren't paying
    attention. Smart tv's, smart camera's, tablets, phones, etc - they are
    becomming the center of the computing industry. Which, basically means
    even MS is struggling to stay relavent right now, against the on
    slaught of Android/iOS. And that means, java or C (well, objective-c
    for ios :) ). At least, with C# there are tools for targeting android
    and even ios. Haven't seen any for VB6... And, worse case - it's not
    that difficult to port my C# libraries to Java (the major programming
    environment in the android echo system).

    The fact, is the world has moved on and left you behind.

    --
    Tom Shelton
     
    Tom Shelton, Jan 13, 2012
    #17
  18. Ubiquitous

    Mayayana Guest

    |
    | I don't know if youv'e been paying attention... Win32 is pretty much
    | deprecated.
    |

    It's the basis of WinRT.
    http://tirania.org/blog/archive/2011/Sep-15.html

    http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
    "most if not all WinRT APIs are wrappers on top of existing functionality in
    Win32 or COM components."

    If you search on WinRT and API you find lots of
    people saying that WinRT is "finally replacing the
    old, decrepit API". And you'll find a few people, like
    the links above, pointing out that WinRT, like .Net
    before it, is no more than a [bloated] sandboxing
    wrapper on top of the basic OS.

    | Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
    | the api. Win32 and the old dekstop are legacy.
    | ..... VB6 will continue to work on
    | the legacy desktop, which we know will be phased out in the not to many
    | versions hence.
    |

    Legacy... legacy... PCs are legacy. Mouse and keyboard
    are legacy. The Win API is legacy. VB is legacy. Desktops
    and file systems are legacy. Whatever "legacy" is, it sounds
    rather useful and comnprehensive.
     
    Mayayana, Jan 13, 2012
    #18
  19. Ubiquitous

    Tom Shelton Guest

    Mayayana used his keyboard to write :
    >>
    >> I don't know if youv'e been paying attention... Win32 is pretty
    >> much deprecated.
    >>

    >
    > It's the basis of WinRT.
    > http://tirania.org/blog/archive/2011/Sep-15.html
    >
    > http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
    > "most if not all WinRT APIs are wrappers on top of existing
    > functionality in Win32 or COM components."
    >
    > If you search on WinRT and API you find lots of
    > people saying that WinRT is "finally replacing the
    > old, decrepit API". And you'll find a few people, like
    > the links above, pointing out that WinRT, like .Net
    > before it, is no more than a [bloated] sandboxing
    > wrapper on top of the basic OS.
    >


    You can not access Win32 functions directly in a metro app. For all
    practicle purposes, it is dead to the a developer targeting the metro
    interface. Period. To think that WinRT does not make use of Win32 at
    this point would be naive at best.

    >> Well, in windows 8 and beyond - Metro is the native desktop. WinRT
    >> is the api. Win32 and the old dekstop are legacy.
    >> ..... VB6 will continue to work on
    >> the legacy desktop, which we know will be phased out in the not to
    >> many versions hence.
    >>

    >
    > Legacy... legacy... PCs are legacy. Mouse and keyboard
    > are legacy. The Win API is legacy. VB is legacy. Desktops
    > and file systems are legacy. Whatever "legacy" is, it sounds
    > rather useful and comnprehensive.


    Keep saying that when you want your apps to run on Windows 8 arm
    devices...

    --
    Tom Shelton
     
    Tom Shelton, Jan 13, 2012
    #19
  20. Ubiquitous

    Schmidt Guest

    Am 13.01.2012 21:22, schrieb Tom Shelton:

    >> On the other hand, Winforms are deprecated in
    >> the meantime, as is the usage of Silverlight...
    >> (more to come, just wait).
    >>

    >
    > I don't know if youv'e been paying attention...
    > Win32 is pretty much deprecated.


    That's misinformation, because MS cannot afford,
    to throw out the Win32-API-layer any time soon.
    The relation of Win32-Apps/Win64-Apps is currently
    about 80/20 I'd say - a long way for MS, to be
    able to pull the plug there.

    > Well, in windows 8 and beyond - Metro is the
    > native desktop.

    Not in my book - Metro/WinRT is foremost
    only "an attempt to support a trend" (touch-
    screens and non-x86 CPUs).

    BTW, I've recently sold Desktop-Systems, which offered
    (at request) both, a TouchScreen-interface and
    alternatively "classic input" over Mouse/Keyboard.
    What happened after a few weeks of playing around
    is, that on my last visit everybody was back
    using the Mouse exclusively.

    So (IMO) there's just no need, to offer Touch-Interfaces
    for "normal Desktop-Work" with classic Notebooks
    or PC/TFT combinations.

    Touchscreens make sense on devices without a Mouse
    (Tablets and Phones - or large presentation-screens) -
    nowhere else.

    And there's rumors, that the real Desktop (running
    on the classic Win32/64-API) will be made the default
    (at least in Win8-company-versions, analogous to Win7).


    > I still fail to see your point...
    > Winforms/silverlight and all .net apps will continue
    > to run and function just as they always have on the legacy
    > desktop. What is it that you are trying to get at here?

    I'm repeating myself... they are in the same way
    "dead, deprecated, whatever" as VB6 is - so let me
    retype your above sentence:

    "VB6 and VB6-apps will continue to run and function
    just as they always have on the legacy desktop.
    What is it that you are trying to get at here?"
    <g>


    >> And the VBClassic-runtime-lib (in conjunction with
    >> the VBClassic language) does its job just fine
    >> at the moment - as well as in the near future.
    >>

    >
    > Not in the new desktop.


    What exactly *is* the "new desktop"?
    These Touch-Interface-optimized Entry-Screen-Tiles,
    nobody who does serious Desktop-work will use
    in the end?

    Aside from that, it should not be that hard,
    to bring a native VB6-App into this Tile-Upstarter.
    And since WinRT is COM, it should also not be that
    hard, to address it from VB6 - I'm sure this topic
    will be "investigated" here in the community,
    as soon as Win8 is out.


    > And, not on ARM.

    WTFuzz - here you come again, armed with the ARM-argument.
    If one wants to address 95% of all Tablet- and Phone-
    Users, he writes his App with either the Android- or
    the Apple-Tools (Java or Objective-C).

    And just in case I want to address the poor souls,
    who indeed bought a Win8/ARM-device, then
    Speaking for myself, I would write small HTML/JS-Apps
    for devices like that. This way I could even address
    the poor souls, who accidentally bought Win8/ARM-gadgets.

    In either case, the applications which run on these
    devices are not the classical, complex branch-solutions
    which were/are the main-field of VB6-Devs. These new
    mobile Apps are usually small, handling only a small
    volume of data, not that many "screens to code" -
    so the implementation-language does not matter that much.
    The larger, complex Apps which are used on these
    devices (Google-Maps or stuff like that), usually run
    online anyways (in the Mobile-Browsers), so what you
    need for development in these complex cases is an environment,
    which can create WebApps - and for that there's loads
    of alternatives to MS-stuff.


    > VB6 will continue to work on the legacy desktop,
    > which we know will be phased out in the not to many
    > versions hence.


    "Which we know will be phased out..." - where can
    I want to read more about that - do you have a
    link or something?

    Your so called "legacy Desktop" is still, also in
    Win8, the main-workhorse for all kind of productive
    labour - as I wrote further above already - the users
    just "don't touch" the new stuff, as soon as a Mouse
    is in reach.

    Maybe we see a kind of "Vista-Effekt" for the new
    Tile-Desktop (at least in productive environments).

    > In other words - the end is nigh.


    That is true of course, always was - for all of us...;-)


    >> And it is "less far" from the current base-tech
    >> (C/C++ and COM) than .NET is - that's my whole point.
    >> ...

    >
    > First off - the runtime is not a thin layer over c/c++.


    I didn't wrote that.
    Oh - you mean the WinRT (not the VBClassic-Runtime-lib)?
    In this case I have to tell you, that the C/C++ guys
    are very happy with WinRT, because they can bypass
    any "intermediate .NET-layer" (you know, the "bloated
    VM" I wrote about earlier <g>), to get access to the
    system much more directly.
    And of course the WinRT sits atop of C/C++ libs
    (currently the classic Win-API on x86-machines) -
    but on top of the WinAPI and WinRT comes the consuming
    Application-Code, which (if you don't want bloat) should be
    written also in C/C++. So, the "thin layer thingy"
    works both ways of course...

    Here the happy statement of a C++-developer -
    at the end of the article (in the chapter 'Conclusion') on:
    http://www.codeproject.com/KB/cpp/WinRTVisualCppIntro.aspx

    "...But for faster applications with smaller memory footprints
    where performance is the key focal point, using C++ to write
    Metro apps is the way to go because when you do that it's
    metal on metal! The renaissance is here, finally."

    > You act as if I have some problem with C/C++?

    How do you come to this conclusion? I'm pretty
    sure, I've done more work (manifested in megabytes
    of VBclassic-adapted binaries) in C/C++ than you.

    > I do not. In fact, I love C++.

    Then go on, use it - there's even better suited
    Newsgroups to talk about your love or C++ and all that.

    >> From my point of view, it is you who's living in a
    >> dream world, not acknowledging, that both approaches
    >> (from MS' point of view) were only temporary cash-cows,
    >> sold to "crowds of RAD-believers".
    >>
    >> The difference between .NET- and "still VB6"-users is,
    >> that the latter ones recognized "the pattern" much
    >> earlier (fool me once) - and didn't invest that much
    >> time again into "the next distraction".

    >
    > That is simply the most ridiculous bunch of rubbish
    > I have ever read. VB6 is simply irrelavent -


    If you say so - but again, in the same way as .NET is
    becoming more and more irrelevant.

    > and about to fade completely into the foot
    > notes of history.

    In the same way as .NET does.

    > If you can't see that, than you simply aren't paying
    > attention. Smart tv's, smart camera's, tablets, phones, etc

    Yeah, sure.
    Smart anything - as well as "i like" or "fast and fluent"
    or other marketing-rubbish you apparently are fond of...

    > they are becomming the center of the computing industry.

    Prebuilt devices with prebuilt vendor-apps, accompanied
    by already saturated "App-markets". That's what the
    "new developer-generation" has to struggle with
    (to get their feets in).

    What remains (for existing small software-companies
    and selfemployed devs with a bit of a business-background)
    is more or less (still) the branch-applications,
    which wants to be run on a normal Desktop, on a
    normal PC (with mouse and keyboard).

    > Which, basically means even MS is struggling to stay relavent
    > right now, against the on slaught of Android/iOS.
    > And that means, java or C (well, objective-c for ios :)

    Glad you admit that.
    It's an important point - and BTW the base of my assumption,
    that my statement ".NET is becoming more and more irrelevant too"
    is becoming a true one.


    > At least, with C# there are tools for targeting android and even ios.


    Yes, as I wrote above, the few percent which are left
    for MS in this tv/table/phone consumer-market can be addressed
    either with C#/VB.NET/C++ or with just simple HTML/JS.
    And as said, should I ever be inconvenienced with the
    requirement, to write a (probably then accompanying a larger DeskApp)
    small application for a tablet or phone-device, then I'd
    do it in HTML/JS - since all these platforms come with a
    mobile-browser. There's even jQuery-abstraction-classes
    for the touch-interface-events for most of them.

    > Haven't seen any for VB6...

    As said, not needed - for Desktop-stuff VBClassic is more
    than enough - for "fun- and simple consumer-stuff" HTML/JS
    should be sufficient too.

    > And, worse case - it's not that difficult to port my C#
    > libraries to Java (the major programming environment in the
    > android echo system).

    What are these libraries, if I may ask that?
    What sense do they make, ported to a small-screen-device?
    Aside from that, wouldn't it be better, to leave them
    "as is" and just put their functionality at the serverside
    and just show the computed (HTML/JSON) results on these small
    screens (in a few WebPages), hmm?

    You see, why I ask that - do you? Because exactly
    the same way is open for any COM-library, written
    in VBClassic (to put them into place behind a WebServer).

    > The fact, is the world has moved on and left you behind.

    Coming from you I can live with that, I think... ;-)


    Olaf
     
    Schmidt, Jan 13, 2012
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Oenone

    Upgrading a VB6 ActivityX EXE project

    Oenone, Feb 25, 2005, in forum: Microsoft VB .NET
    Replies:
    1
    Views:
    173
    Ken Tucker [MVP]
    Feb 25, 2005
  2. Adrian Game
    Replies:
    0
    Views:
    215
    Adrian Game
    Mar 10, 2005
  3. Adrian Game
    Replies:
    0
    Views:
    328
    Adrian Game
    Mar 10, 2005
  4. Guest
    Replies:
    0
    Views:
    161
    Guest
    Aug 24, 2005
  5. Robinson

    Upgrading a project, "Invalid Image" exception?

    Robinson, Oct 19, 2006, in forum: Microsoft VB .NET
    Replies:
    1
    Views:
    145
    Glenn Palomar
    Oct 20, 2006
Loading...

Share This Page