Page 5 of 18 FirstFirst ... 234567815 ... LastLast
Results 161 to 200 of 695

Thread: Vb6 , the Future, and what I have discovered

  1. #161
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    - a simple RPC (Remote-Procedure-Call - to use this "old fashioned acronym" in favour of all these ever changing "marketing terms" one tries to cover that fact with

    Can VB6 perform such RPCs (over https) in a simple manner at the clientside?
    - of course it can (asynchronously and also synchronously - over a system-provided COM-object)

    Can VB6 be used to implement the serverside in such scenarios (e.g. implementing a modern, JSON-returning WebService)?
    - of course it can (over a native compiled, fast performing COM-lib, which runs behind MS-IIS - or behind other WebServer-architectures as e.g. FastCGI)
    Thanks very much, I'm using VB6 + RC5 + FastCGI to develop Web-App. For now, the effect is very good.
    Last edited by dreammanor; Jan 28th, 2018 at 08:52 AM.

  2. #162
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    A higher-level language doesn't need to support e.g. "inline ASM-snippets" - but it should (in addition to being able to compile COM-libs):
    - have a native compiler which allows easy access also to the systems flat-APIs
    - offers unmanaged access to "pointer-based stuff", if the need arises
    - and it should be able to link (as a higher-level-glue-language) also to the "first-level-class-wrappers atop the systems flat-API ==> COM)
    That's IMO as far as a higher-level language should go with regards to "bare metal" (if you want to write system-drivers, use C/C++).
    And VB6 to this day supports all of the above...

    BTW, what do you think e.g. UWP-stuff is based on? - right, it's normal COM-interfaces and -VTables.
    The "classic .NET-stuff" you're using, is a "once removed" - "third layer" atop of many of the systems COM-Interfaces and -Classes.
    (.NET core 2.0 is a bit more direct - especially in its Linux-version of course, where there "is no COM" - but that's a new -
    and still comparably small subset of the .NET you currently use).

    Olaf
    This argument makes zero sense since even with native compilation you're still sitting on top of a huge stack of subsystems. Those native API's you're so fond of isn't anywhere close to anything that could be described as "bare metal".

    If your definition of the bare metal is simply the Win32 API surface then this whole argument makes even less sense since VB6 has just as many abstractions between itself and that surface as the .Net Framework. The C compiler has historically been the closest to the Win32 API. If you really believed in all that you'd be programming in C. All Microsoft did when they introduced .Net was simply replaced the abstraction between the BASIC language and the Win32 API.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  3. #163
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Hi Niya, you are a loyal supporter of .NET, also should be a .NET expert. One thing I'm really interested in is: Could you list some features that only .NET can implement while VB6 does not? We'd like to see how Olaf implements these features with VB6 and RC5. Thank you.

    Edit:

    I would like to know what are the features of an application that .NET can implement, while VB6 cannot?
    Last edited by dreammanor; Jan 28th, 2018 at 10:37 AM.

  4. #164
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by dreammanor View Post
    Hi Niya, you are a loyal supporter of .NET, also should be a .NET expert. One thing I'm really interested in is: Could you list some features that only .NET can implement while VB6 does not? We'd like to see how Olaf implements these features with VB6 and RC5. Thank you.
    If we're talking about language features, here are some things that's available in VB.Net that are not in VB6:-

    • Class inheritance.
    • Reflection. (This one has more to do with the Framework than the language itself).
    • First class functions.
    • Higher order functions.
    • Anonymous types.
    • Type inference.
    • Delegates(strongly typed function pointers).
    • Method overloading.
    • Operator overloading.
    • 64 bit integer type. (This one has more to do with the Framework than the language itself).
    • Direct support for 64 bit pointers. (This one has more to do with the Framework than the language itself).
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  5. #165
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by dilettante View Post
    Struck a nerve I see.
    Poor arguments tend to do that.

    I respect the hell out of the depth of knowledge about VB6 you bring to any thread. It's always disappointing when you break the spell and try to talk about .NET. It's a thing you decided, long ago, was completely unworthy of your attention. So you, with appeals to your VB6 authority, display all the mastery of a casual Wikipedia reader when you construct your assessments.

    As an alternative analysis, I find your programming opinions and political opinions to be surprisingly parallel. You're quite prone to buying into conspiracy theories if they say what you want to hear. When challenged, you resort to insulting "young people" and insisting that if we had your vast knowledge, we'd agree with you too. This isn't always wrong. But you like to weave a hyperbolic tapestry such that when you are wrong, it's "scored a 99-yard safety" wrong. I wouldn't bat an eye if you told me you had seen solid proof Hejlsberg was forming a committee with Hillary Clinton to make the next version of VB a lesbian.

    You're still the C programmer who kicks sand in a VB developer's face. You just decided "some VB is OK".
    Last edited by Sitten Spynne; Jan 28th, 2018 at 09:17 AM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  6. #166
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    It's a thing you decided, long ago, was completely unworthy of your attention. So you, with appeals to your VB6 authority, display all the mastery of a casual Wikipedia reader when you construct your assessments.
    Believe it or not, I was exactly like this at one point, though I didn't have an account here at the time. I still cringe when I remember how ignorant I was.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  7. #167
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Vb6 , the Future, and what I have discovered

    Gluten intolerance at work.

  8. #168
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    You're still the C programmer who kicks sand in a VB developer's face. You just decided "some VB is OK".
    Interestingly enough, I have seen this. I mentioned before that I used to do a lot of Doom modding in my youth. While the community was made up of mostly artists and mappers, there were a share fair of programmers who wrote tools to help out. Nearly all of them were C/C++ programmers. Only I and one other wrote tools using VB6.

    Whenever language discussions came up....boy did VB get it. The C/C++ programmers had an extremely strong dislike for VB6 and didn't shy away from throwing everything from down-talking quips to venomous barbs at anyone who dared to talk as if it were a real language. A lot of the tools they wrote were amazing and while today I am capable of writing any of the tools they wrote, at the time they seemed like gods to me because of their knowledge so I didn't even bother entering discussions to defend why I liked VB6. Their discussions shed light on just how little I knew.

    In hindsight it was a good experience for me because it drove me to familiarize myself with C and other languages outside of BASIC. Up until that that time, all I had ever done was BASIC programming. From BASICA to VB6 and most flavors of Microsoft BASIC in between(VB2, VB4 etc). I had never attempted to write any code other than BASIC code until my experiences in that community. And while today I still prefer VB over all else, dipping my toes outside of the world of BASIC broadened my knowledge immensely. While I will never claim to be the best programmer or even a good one, it made me orders of magnitude better than I was.

    So yea, for every VB6 programmer like Dilettante who would shoot barbs at VB.Net programmers, there is a C/C++ programmer who would do the same to VB6 programmers. And there are ASM programmers who would do the same to C/C++ programmers(yes, I have seen this too but that's another story).

    At this point in my life I find it all to be ridiculous. If you like VB6, that's fine. You like C, VB.Net, ASM, or C# that's fine too. All this headache over MS abandoning VB6 is just plain stupid to be honest. People need to get over this and move on. Be angry at .Net all you want, it is here to stay. It is the direction that MS chose and we need to live with that. You have three choices, stay in VB6, learn VB.Net or learn something else. Complaining about VB6's glory days and trashing .Net is not helpful to anyone, especially not to the ones complaining and crying.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  9. #169
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,817

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    All this headache over MS abandoning VB6 is just plain stupid to be honest.
    ...
    Be angry at .Net all you want, it is here to stay.
    Niya, IMHO, you're sort of missing the point when you put those two thoughts together. They're not the same thing. I'm not angry at .NET, but I am angry that Microsoft abandoned a full stand-alone IDE supporting the COM architecture.

    Some people like to drive Lincoln Navigators and others like to drive Ford Shelby Mustangs. And yet others enjoy driving one for a while and then the other. Ford seems to be doing just fine marketing both, being smart enough to realize there's more than one niche market. Why is Microsoft so dense that they can't figure that out as well? And I'll let you figure out how the metaphor of my two cars maps onto .NET and VB6.

    Take Care,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  10. #170
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Vb6 , the Future, and what I have discovered

    If you want to use .Net just go ahead. By why stray out of the .Net ghetto forums here and come into the VB forums to proselytize? If people want to use it, they will.

  11. #171
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    3,034

    Re: Vb6 , the Future, and what I have discovered

    I was wondering when the .Net vs. VB6 fight would breakout


    @ to the Admins of this Forum

    why not add a Forum for Codesamples .Net / VB6 Code 1:1
    a) somebody Uploads a .Net or VB6 program
    b) either the .Net'er or VB6'er will try code that sample 1:1

    regards
    Chris
    Last edited by ChrisE; Jan 28th, 2018 at 10:19 AM.
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  12. #172
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,207

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    If your definition of the bare metal is simply the Win32 API surface then this whole argument makes even less sense
    since VB6 has just as many abstractions between itself and that surface as the .Net Framework.

    The C compiler has historically been the closest to the Win32 API.
    If you really believed in all that you'd be programming in C.
    All Microsoft did when they introduced .Net was simply replaced the abstraction between the BASIC language and the Win32
    It's astonishing to me, how much you don't know about the Class-library-stack you are using in your daily work.

    Besides, I thought I explained it well enough already (that I don't associate "C or ASM-coding" with "bare metal").

    I was talking about the library-stack of the Win-OS - mainly focusing on your misconceptions about COM, which never became:
    - "unnecessary" or "dead"
    - also COM never was "one of the reasons why .NET had to be invented" (as you tried to suggest)

    Sure - many of the .NET-classes (especially those in the System-Namespace) work directly against the flat-API -
    but a whole lot of them are wrappers around COM-implementations (e.g. the now dead "Indigo" you gave a link to further above, was wrapping parts of COM+, WPF is wrapping Direct2D etc...)...

    But let's look at something "current" instead:
    https://docs.microsoft.com/en-us/win...ing/httpclient

    Why do you think, that the catch-block in the above example was written this way:
    Code:
    catch (Exception ex)
    {
        httpResponseBody = "Error: " + ex.HResult.ToString("X") + " Message: " + ex.Message;
    }
    Right - the HResult is the Err-Message from the underlying COM-Object it wraps.

    So, back to the systems library-stack:
    When we call some existing "system-object" (as e.g. WinHttp.5.1) from a (COM-based) VB-Wrapper-Class, we can do that directly VTable-based:
    <OS-kernel>
    .... <Win32-flat-API> (e.g. winsock)
    .... .... <e.g. WinHttp.5.1 COM-instance>
    .... .... .... <VB6-Class which wants to perform a http-request>

    When you use .NET (referring to the above linked example), the stack looks somewhat more like:
    <OS-kernel>
    .... <Win32-flat-API> (e.g. winsock)
    .... .... <UWP COM-http-wrapper-instance>
    .... .... .... <.NET-VM-COM-call-Marshalling>
    .... .... .... .... <.NET-VM> (with garbage-collector)
    .... .... .... .... .... <.NET-Class which wants to perform a http-request>

    And of course these Extra-lndirections are causing a certain performance-overhead -
    but what I dislike the most in the whole .NET-concept is the Garbage-Collector which sits in-between.
    (To be precise - I dislike Garbage-Collection in any language - so that's not a ".NET-specific" thing).

    When a (RefCounting) COM-Class goes out of scope, it's internal Cleanups (e.g. in VB6 the Class_Terminate destructor) are executed immediately
    (so that all the handles it internally used from the given flat-API it wrapped, can be taken care of, as e.g. in our http-example proper disconnects and socket-handle-cleanups)

    Whilst with the .NET-VMs GargabeCollector - the whole "cleanup-story" becomes a mess.

    Hopefully that made it more clear, how I understood the "bare metal" thing.

    Olaf

  13. #173
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    If we're talking about language features, here are some things that's available in VB.Net that are not in VB6:-

    • Class inheritance.
    • Reflection. (This one has more to do with the Framework than the language itself).
    • First class functions.
    • Higher order functions.
    • Anonymous types.
    • Type inference.
    • Delegates(strongly typed function pointers).
    • Method overloading.
    • Operator overloading.
    • 64 bit integer type. (This one has more to do with the Framework than the language itself).
    • Direct support for 64 bit pointers. (This one has more to do with the Framework than the language itself).
    What you're talking about are just language-level features, and I want to understand the functionality at the application level. In other words, what are the features of an application that .NET can implement, while VB6 cannot?

  14. #174
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,817

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by dreammanor View Post
    What you're talking about are just language-level features, and I want to understand the functionality at the application level. In other words, what are the features of an application that .NET can implement, while VB6 cannot?
    Excellent point dreammanor.

    Or even more to the point, what are some functionalities that an enhanced VB6/VB7 couldn't do? Granted, we do most of them in VB6, but we do have to jump through a few hoops. Three things that immediately come to mind are full Unicode throughout, styling, and 64-bit. The first two, we've developed excellent work-around. The third one, that one is currently out of our reach.

    Take Care,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  15. #175
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by ChrisE View Post
    I was wondering when the .Net vs. VB6 fight would breakout


    @ to the Admins of this Forum

    why not add a Forum for Codesamples .Net / VB6 Code 1:1
    a) somebody Uploads a .Net or VB6 program
    b) either the .Net'er or VB6'er will try code that sample 1:1

    regards
    Chris
    Sorry, I'm not trying to discuss .NET vs VB6, I just wanted to discuss why we need to keep using VB6 and why Microsoft gave up VB6 is wrong and why we should use RC5.
    Last edited by dreammanor; Jan 28th, 2018 at 12:03 PM.

  16. #176
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Sorry, deleted my duplicated post.

  17. #177
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    3,034

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by dreammanor View Post
    Sorry, I'm not trying to discuss .NET vs VB6, I just wanted to discuss why we need to keep using VB6 and why Microsoft gave up VB6 is wrong.
    no need to be sorry, I think it would be interesting if there was such a subForum .Net-VB6 1:1 Codesamples

    regards
    Chris
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  18. #178
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Elroy View Post
    Or even more to the point, what are some functionalities that an enhanced VB6/VB7 couldn't do? Granted, we do most of them in VB6, but we do have to jump through a few hoops. Three things that immediately come to mind are full Unicode throughout, styling, and 64-bit. The first two, we've developed excellent work-around. The third one, that one is currently out of our reach.
    Agree. The third one (64-bit) is why I'm eagerly looking forward to Olaf's new compiler and IDE.

    Quote Originally Posted by ChrisE View Post
    I think it would be interesting if there was such a subForum .Net-VB6 1:1 Codesamples
    Great advice.

  19. #179
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,207

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    If we're talking about language features, here are some things that's available in VB.Net that are not in VB6:-

    • Class inheritance.
    • Reflection. (This one has more to do with the Framework than the language itself).
    • First class functions.
    • Higher order functions.
    • Anonymous types.
    • Type inference.
    • Delegates(strongly typed function pointers).
    • Method overloading.
    • Operator overloading.
    • 64 bit integer type. (This one has more to do with the Framework than the language itself).
    • Direct support for 64 bit pointers. (This one has more to do with the Framework than the language itself).
    Yep - as I thought you would, you are listing "language features" - (though not posting "an implementation of something useful").

    We had this kind of thing going on in other discussions already - and I still stand by what I wrote before:
    So far I have not seen a .NET example (which implements something useful), that was not doable efficiently in VB6 as well.

    The only (undeniable) advantage .NET has, is its "broad range of available compiler-targets" (VB6 being limited to producing only 32Bit-x86 PE-binaries currently).

    But that's one of the reasons why this discussion-thread came to be, wouldn't you say... -
    and I'd really much prefer to discuss "the future of VB6" and what *we* as the VB6-community can do about it,
    than to engage in pointless ".NET vs. VB6 comparisons" (again), which you so like to bring up, Niya.

    You brought, that we only had 3 choices: "stay in VB6, learn VB.Net or learn something else".

    And I'd really want to see a healthy discussion about that "something else" you mentioned, here in this very thread.

    I for my part would appreciate, when the VB6-community would recognize, that we *can* help ourselves,
    when we'd only get our "posterior up" - and "learn something else", which is not "an entirely different language" -
    but only involves "writing a new IDE and compiler, by using normal VB6 *.bas and *.cls modules".

    The end-result of what we could produce that way (doing "something else" entirely in VB6), would be able to:
    - compile to 64Bit-x86, as well as ARM-targets
    - would run on Linux and other OSes without larger porting-efforts in the new runtime-classes
    - and still use fully VB6-compatible code in *.bas and *.cls modules (including Declare-Statements to the Win32-API, when we talk about the Win-version of the new compiler)

    About 80% of the needed coding-efforts for that task, can be done with only an "average skill-level".

    Sadly the above "let's move on this way"-suggestion of mine, is met with a lot of "unexplainable resistance"
    (even active hindering-attempts) from a lot of the "big cannons in the VB6 camp"...

    Olaf

  20. #180
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Vb6 , the Future, and what I have discovered

    Well, I want to go two directions. But I'm pretty sure the second one gets dismissed easily so let's focus on the better one.

    Asking, "What can VB .NET do that VB6 can't?" sort of veers in a weird direction. It's the second direction I want to go. The elephant in the room is "Linux/Mac/Android/iOS". I don't think you care about that avenue so let's shut that door.

    What's really wrong with that question is language features aren't often what makes a language "able to do things". Niya maybe pointed one out in terms of 64-bit pointers, but you guys are clever and I bet you know a way around it. That's part of why VB6 isn't stupid: through its ability to integrate with COM you can enable things it wasn't designed to do.

    I'm not arguing that VB6 is a bad tool and .NET fixes it. They're both bad tools in certain circumstances, and that's not a productive argument. This isn't "using a screwdriver when you need a hammer" discussion.

    I'm asking you to think about why VB was created. Why wasn't C sufficient? What can't C do? We all know C can do more than VB. But its closeness to the metal means we have to think a lot harder about doing simple things. And our programs tend to be built out of lots of simple things. So we wanted a language that made the really common things simpler. If VB just simplified programming, it'd be limited. But since it is open to C and COM interop, VB6 faces very few limitations in a Windows context.

    So VB6 is a simpler version of C, that is where its value proposition lies.

    The "bad architectures" that are blamed on VB aren't unique to it. C developers wrote them too. But in C if you wrote code poorly you quickly got into states where nothing worked at all. VB let this kind of careless developer get a lot further than they could have when C was your only choice. This is a downside, but I think it was well worth it. A disciplined VB6 developer can juggle a large-scale program.

    "Discipline" takes thought. One nice side effect of having simpler ways to do simple things is we can make larger programs more easily. And entire classes of mistakes you can make in C aren't possible in VB6.

    So that's the two reasons VB needed to exist: to make simple things simple and hard things easier.

    The features Niya mentioned are things that have been added to VB .NET with that same spirit. They don't make you able to do things you couldn't do with VB6. They make it easier to do some things that were hard to do with VB6. When used properly, they might make you able to write larger programs more easily, and smaller programs more quickly.

    But that's very hard to gauge. If you are an expert in VB6, you're already used to the disciplines and rituals needed to do these things. I often find that a clumsy tool in the hands of an expert is better than a quality tool in the hands of a novice. So even if it's true that these features make new developers faster and more effective, we aren't new developers so the benefits can be dubious.

    We made COM because we decided large-scale application development in C was too hard. COM presents solutions to a lot of problems. C developers knew how to solve those problems. COM was made so they could quit writing their own solutions and use a standard one. I don't really know enough about COM to argue if I think it was a very good solution.

    The flaws I do know remind me of similar flaws in .NET. Memory management, in particular, is still clunky. It's a very hard problem we've been trying to "solve" with programming languages since ASM was the only choice. I could write an essay as large as this post about why I think the .NET memory paradigm stinks. It's even worse in JS, my new favorite application language. I have no clue how memory works in it at all!

    But I think that leaves me with the hill I'd rather die on: I'd rather talk about what a post-.NET framework that improves on both COM and .NET looks like. I think trying to build a new VB on .NET won't yield enough benefits to be worth the effort. I think throwing away VB .NET and continuing the VB6 line is insular and ignores two decades of software engineering ideas.

    I think any "modern VB" should crib very heavily from Swift. It's a language that blurs static and dynamic typing, object-oriented and functional programming, and even lets the developer opt between garbage-collected or manual memory management per-variable.

    I think most modern languages try to be completely disconnected from UI concerns. I'm suspicious if a modern VB ignores that convention and directly integrates with a UI framework, it'll kick the snot out of current soluitons in terms of simplicity and accessibility. That's the part of VB6 that .NET hurt the most for dropping: "Make the GUI system first-class".

    So overall I wish we'd look forward instead of backwards. It is simply not true that we solved application development in 1998. We can't build a language for 2025 if we believe we did. There's much more to application development than, "My language can do what yours does..." with suffixes like "...with fewer lines". That's just a peeing contest. The right question is, "Since this is a well-understood problem, how can we go about solving it more easily with a new tool?"
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  21. #181
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Vb6 , the Future, and what I have discovered

    I'm going to take one snipe at the thing that keeps getting parroted and bothers me the most, and in the meantime TL;DR my post.
    Quote Originally Posted by Schmidt View Post

    We had this kind of thing going on in other discussions already - and I still stand by what I wrote before:
    So far I have not seen a .NET example (which implements something useful), that was not doable efficiently in VB6 as well.
    "I've never seen a VB6 example (which implements something useful) that was not doable efficiently in C as well."

    C developers have frameworks and tools that take care of the boilerplate you'd call "inefficient". If we compare expert-to-expert it's scary what C developers are capable of.

    We probably won't get another leap in simplicity like what we got from C to VB. We certainly don't consider VB6 trash because it only incrementally improved upon VB5. This is what VB .NET intended to do: incrementally improve upon VB6. If I knew much more about the capabilities of VB6 I might be able to point out some areas that got a lot better. It doesn't matter, nor will you care to see them. I feel like the argument is, "Since .NET didn't do to COM what VB did to C, .NET is a failure." I don't think that's fair. COM was pretty good, if it wasn't we'd have all fled to .NET simultaneously. "Not COM" seems pretty good too: plenty of people never adopted it. .NET stinks in many of the same ways COM stinks. We need something better. We have no clue what that looks like.

    But I do know nobody bothered (in my knowledge) to port COM systems to Linux/Mac/iOS/Android. People did that with .NET for free. I actually have two different choices for execution engine on Mac/Linux, and at least three on Windows. I'm actually sort of disappointed we did this instead of building a post-.NET framework that tried to solve the problems a different way. But I have a feeling the people who put in these efforts would have chosen a COM infrastructure instead if they felt it presented a better value proposition. I don't know enough about COM to try and explain why they didn't. (My suspicion is its reliance on having a concept like the registry grossed everyone out. Yes, .NET has the GAC. We hate it, and no sane .NET professional uses it if they can avoid it.)

    Part of why this is difficult is concepts like versioning, deployment, and compatibility are runtime, not language concerns. Nothing about VB is really affiliated with those. So when we start talking nuts and bolts, either things "don't matter because that's not a language concern" or "don't matter because I can do that with a little effort in any general-purpose language". I like to worry about ALL of these, because I tend to have to worry about them all.

    We can't make things better if we insist we've already hit the summit. I don't think VB6 is the end of application development languages, and I think we still have a long way to go.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  22. #182
    PowerPoster
    Join Date
    Sep 2012
    Posts
    2,083

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    I for my part would appreciate, when the VB6-community would recognize, that we *can* help ourselves,
    when we'd only get our "posterior up" - and "learn something else", which is not "an entirely different language" -
    but only involves "writing a new IDE and compiler, by using normal VB6 *.bas and *.cls modules".

    The end-result of what we could produce that way (doing "something else" entirely in VB6), would be able to:
    - compile to 64Bit-x86, as well as ARM-targets
    - would run on Linux and other OSes without larger porting-efforts in the new runtime-classes
    - and still use fully VB6-compatible code in *.bas and *.cls modules (including Declare-Statements to the Win32-API, when we talk about the Win-version of the new compiler)

    About 80% of the needed coding-efforts for that task, can be done with only an "average skill-level".

    Sadly the above "let's move on this way"-suggestion of mine, is met with a lot of "unexplainable resistance"
    (even active hindering-attempts) from a lot of the "big cannons in the VB6 camp"...

    Olaf
    Olaf, I believe more and more people will understand and support your suggestions. What we can do now is to take more time to learn RC5, use RC5 and publicize RC5. If I had the opportunity to help write some demo examples in the future, I would be very honored.

  23. #183
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,987

    Re: Vb6 , the Future, and what I have discovered

    Hello Sitten,

    Quote Originally Posted by Sitten Spynne View Post
    We certainly don't consider VB6 trash because it only incrementally improved upon VB5. This is what VB .NET intended to do: incrementally improve upon VB6.
    You must be joking. "incremental"? Really?
    It is a new language, similar in some ways, different in others. They both share the BASIC (to some extent).
    But it is not an increment.

    From VB5, or even VB4, you had only to change a few things (if any) to make a program to load in VB6.

    And "improved". Improved in some ways may be, retrogressed in others.
    Because it is not simple, it doesn't follow the idiosyncrasy of VB6.

    Another thing: you say "we", "we did", "we could do"... Etc.

    Are you from Microsoft?

    Quote Originally Posted by Sitten Spynne View Post
    We can't make things better if we insist we've already hit the summit. I don't think VB6 is the end of application development languages, and I think we still have a long way to go.
    I don't think that either. I think that VB6 could be a good baseline to make something better, but with the idea of something easy (RAD -Rapid Application Development-) and at the same time powerful for the one that wants to go deeper.

  24. #184
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Vb6 , the Future, and what I have discovered

    "We" are a community. If we limit our focus for ideas to just some specific version of VB's community, we will have fewer good ideas. "We" have to look outwards at people who are succeeding and ask why they aren't choosing VB. If they have decent reasons, any attempt to revive VB has to address those.

    The people who made VB aren't gods from on high. They were other developers. They found a need, they filled it, they profited. Same with the people who made .NET. They were paid to find a solution, sure. The people who made Ruby, Python, and several other popular modern languages weren't. One individual created Ruby and it stole an entire generation of Windows client developers. We have power. But not if we consider people in other communities idiots with no sense.

    RE: incrementalism, please don't miss my broad point because I picked the wrong nuance out of ignorance. The VB5->VB6 transition was way before my time. I think you know what I meant.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  25. #185
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,401

    Re: Vb6 , the Future, and what I have discovered

    I think the time for more talk is over...those that can be convinced by words (and what RC5 currently has to offer) have been convinced, and those that have not, will not. What remains is to start work on the project and eventually (hopefully sooner rather than later) have something new and compelling to demonstrate. A "physical thing" for people to use (even if highly experimental) is perhaps the only way to inspire interest in the hardcore non-converts - or if not, then so be it, but at least those who are interested will have access to something tangible.

    Or we can continue spinning our wheels here. I think the effort would be better spent on the product now.

  26. #186
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,207

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    The elephant in the room is "Linux/Mac/Android/iOS". I don't think you care about that avenue so let's shut that door.
    Well, for my part - that's exactly the thing I would like to discuss in more detail here in this thread...
    I want "us" (the VB6-community) to recognize that platform-independency is a "good and important thing to have".

    There'd be absolutely no point in investing all our efforts into "writing a new IDE and compiler for a VB6-successor",
    when it would later depend (in its new, more powerful runtime- and gui-classes) on "too many MS-specific" libraries - as e.g.:
    - GDI+ or Direct2D for graphics-stuff ... or
    - the MS-CommonControls from comctl32.dll
    - or ADO/JET when we address these little "App-DBs" we so like to use currently in smaller and midsized solutions

    If we'd write this new "Visual-IDE" around the above mentioned MS-libs - then we'd have "burned all our man-hours" into something, which is now "very difficult to port to another platform" -
    and a "Visual IDE" for e.g. Linux would in all likelihood never see the light of day (most of the former VB6users being "comfortable again" already with the fact, that it now "at least works on Windows and produces 64Bit binaries").

    So - in this regard I absolutely agree with you...
    (any efforts the community undertakes in this regard, should aim for platform-independence - otherwise "just use VB6-further"-where is the point?)

    Quote Originally Posted by Sitten Spynne View Post
    The features Niya mentioned are things that have been added to VB .NET with that same spirit. They don't make you able to do things you couldn't do with VB6.
    They make it easier to do some things that were hard to do with VB6.
    And that's where I disagree with you.
    I can only encourage you (again) - to show me a "little example of something concrete and useful" which makes "good usage of all these enhanced features" of so called "modern languages".
    I guess you will be surprised, what a VB6-COM-based implementation of the same thing can look like.

    Quote Originally Posted by Sitten Spynne View Post
    We made COM because we decided large-scale application development in C was too hard.
    ...I don't really know enough about COM to argue if I think it was a very good solution.
    It is - otherwise MS wouldn't use it for its own stuff *to-this-day* (UWP was already mentioned).

    And yes, the COM-based Class-concept of VB6 is an advantage over "plain C" -
    and yes, COM *was* that "well-thought-out" already in the 90s, that it is apparently able to carry all the new MS-stuff to this day.

    Quote Originally Posted by Sitten Spynne View Post
    I think any "modern VB" should crib very heavily from Swift. It's a language that blurs static and dynamic typing, object-oriented and functional programming, and even lets the developer opt between garbage-collected or manual memory management per-variable.
    And no, the so called "modern language-features" are for the most part just another "emperors-clothes"-thing, since they offer very little on top of what VB6 and COM already do.
    VB6 already supports (free choice) static and dynamic typing - it is object-oriented (using COM) -
    and many of the concepts of "functional programming" can be replicated easily by passing "a Method-implementing Object" instead of "a function pointer" -
    or by using the "already built-in delegate- or signal/slot concept" by defining "standard COM-events" in an easy manner.

    Quote Originally Posted by Sitten Spynne View Post
    I think most modern languages try to be completely disconnected from UI concerns. I'm suspicious if a modern VB ignores that convention and directly integrates with a UI framework, it'll kick the snot out of current soluitons in terms of simplicity and accessibility. That's the part of VB6 that .NET hurt the most for dropping: "Make the GUI system first-class".
    Not sure, how you meant the above - would you *prefer* a "first-class GUI" (with tighter integration) -
    or do you think that a language with a more "loosely coupled GUI" would be more favourable in a "potential VB6-successor"?

    Olaf

  27. #187
    PowerPoster
    Join Date
    Feb 2017
    Posts
    4,987

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    "We" are a community.
    OK.

    Quote Originally Posted by Sitten Spynne View Post
    If we limit our focus for ideas to just some specific version of VB's community, we will have fewer good ideas. "We" have to look outwards at people who are succeeding and ask why they aren't choosing VB. If they have decent reasons, any attempt to revive VB has to address those.
    Why people is not choosing VB? Because MS abandoned it! (I mean VB6, why people is not choosing VB.NET I don't know).

    It is said that there were about 6 million VB6 developers at some point.
    So people were choosing VB.


    Quote Originally Posted by Sitten Spynne View Post
    The people who made VB aren't gods from on high. They were other developers. They found a need, they filled it, they profited. Same with the people who made .NET. They were paid to find a solution, sure. The people who made Ruby, Python, and several other popular modern languages weren't. One individual created Ruby and it stole an entire generation of Windows client developers. We have power. But not if we consider people in other communities idiots with no sense.
    I don't consider anybody an idiot because he prefers another language. The people that do that are arrogant.

    Quote Originally Posted by Sitten Spynne View Post
    RE: incrementalism, please don't miss my broad point because I picked the wrong nuance out of ignorance. The VB5->VB6 transition was way before my time. I think you know what I meant.
    Your point is that they tried to make something better.
    But I don't want to discuss their intentions.

    My point is:
    VB.NET is a different language. It is not possible to load a VB6 project in .NET.

  28. #188
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,207

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Sitten Spynne View Post
    I'm going to take one snipe at the thing that keeps getting parroted and bothers me the most, ...

    "I've never seen a VB6 example (which implements something useful) that was not doable efficiently in C as well."
    Nope - not true (it's a completely ill-choosen analogy).

    Ok, easy proof:
    - a team of skilled C-developers implemented (over dozens of accumulated man-years) e.g. GTK+ (a C-based framework, similar to the C++ based QT)
    - which implements "COM-like C-Struct-based Objects" over GLib and the ref-counting GObject as "the base", to make it easier for "the rest of the C-Code which is saddled on top"
    - to finally provide a framework, which supports Drawing- and GUI-encapsulations per libCairo... (along with a Form- and Widget-engine)
    - as well as other stuff (Encryption-, Hashing-, UniText-Codec-classes, Stream-, Filesystem-, Socket-, JSON-, XML-, SVG-, PDF- support, you name it...

    The binary size of a recent Windows-build of that framework is (compressed) 18.2MB.
    (as e.g. viewable here: http://www.tarnyko.net/?q=node/1 )

    A VB6-ClassFramework-implemenation of the same thing (including *all* of the stuff mentioned above - and also using cairo as the GUI-backend, and even including SQLite):
    - was developed by a single person, over accumulated "2-3 man-years", I guess (didn't write up my hours)
    - and its (zipped) download-size is about 2.7MB

    If that does not answer your questions about the "achievable efficiency" by using VB6 (compared to C), then I don't know...

    Olaf

  29. #189
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Schmidt View Post
    It's astonishing to me, how much you don't know about the Class-library-stack you are using in your daily work.

    Besides, I thought I explained it well enough already (that I don't associate "C or ASM-coding" with "bare metal").

    I was talking about the library-stack of the Win-OS - mainly focusing on your misconceptions about COM, which never became:
    - "unnecessary" or "dead"
    - also COM never was "one of the reasons why .NET had to be invented" (as you tried to suggest)
    I'm starting to think maybe you're the one that doesn't understand the tools he is using, namely COM.

    Your primary way of interacting with your PC is through the operating system, and as a programmer, you do this through the Win32 API. Every single thing that happens in Windows boils down to a call or calls to the Win32 API. As you may well know, this API is made up of C interfaces. Anything you want your computer to do, you must ask through Windows by using this API. However there is nothing stopping anyone from implementing a different interface into the OS for programmers to use by wrapping the Win32 API. COM is just a single example of such an alterative interface.

    Let's talk about what COM is and what it isn't. COM is a binary standard. Implementations of the COM standard sit on top of the Win32 API. You could even go so far as to call COM a protocol since like any protocol, there is a certain sequence of operations that must to respected when dealing with COM objects. For example, COM objects expect clients to create them using class factories, COM objects expect clients to call AddRef every time their interface pointer is copied and it's expects clients to call Release when an interface pointer is no longer needed. In this sense, COM is like a contract.

    Now if you come up with some great new component and you decide the world could benefit from your genius. Perhaps it's some kind of revolutionary XML parser or something to send WhatsApp messages. You could expose your component's functionality through COM interfaces, you could expose it through a .Net assembly or even simple C interfaces like the Win32 API. Hell you could expose it through all three. The only thing that would be common to all three is that on Windows, this component must interact with the Win32 API. It doesn't matter what kind of component you're writing or what it does, it's never ever going to absolutely require COM but it will always require the Win32 API to run on Windows. The point I'm trying to drive home here is that COM is not essential as far as Windows is concerned. It's just a standard on top of Win32 that a lot of people chose to adopt, including Microsoft themselves.

    Feel free to correct me on this part but it seems to me that you liked the fact that the VB6 compiler and to an extent, the language itself adhered to COM. You mentioned that the .Net Framework has many classes that are wrappers around COM classes. Thing is, a lot of stuff in Windows has been exposed through COM classes. They could have rewrote those classes to work against the flat API but that's not very productive. It's easier just to use the ones they already implemented as COM classes. Why re-invent the wheel?

    .Net, just like COM is based on a standard. COM however, is very old and pretty much set in stone. It no doubt has it's limitations and if they made another Visual Basic that adhered to that standard, they would effectively be limiting Visual Basic itself.

    For example, the COM standard has no notion of classes, it only cares about interfaces. Any language based on this would also be limited thus. You wouldn't be able to implement method overloading or inheritance. The standards upon which the .Net Framework is based is far more robust and as such any language or compiler that targets it will benefit greatly from this. This is why MS chose to carry Visual Basic in this direction.

    Now they could have included advanced features like inheritance or method overloading in a possible COM based VB7 but that would require the compiler to create some truly bizzare COM hacks which in turn would have wrought even more confusion when non-VB clients try to use these classes. This would have only created a huge mess in the long run. Creating a more robust standard than COM was the way to go.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  30. #190
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,943

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by ChrisE View Post
    I was wondering when the .Net vs. VB6 fight would breakout


    @ to the Admins of this Forum

    why not add a Forum for Codesamples .Net / VB6 Code 1:1
    a) somebody Uploads a .Net or VB6 program
    b) either the .Net'er or VB6'er will try code that sample 1:1

    regards
    Chris
    Even if we did we couldn't tell you, because the first rule of fight club is: You do not talk about Fight Club!

    That would be a forum dedicated solely to a pointless, soul-sucking, fight. The soundtrack could be a whine reminiscent of a thousand mosquitoes. It would be like mana for trolls.

    Nobody does comparisons like that unless they have an outcome they want to be true. There wouldn't be any academic curiosity, there'd be nothing but people trying to gather sufficient supporters to shout down any other opinions.

    I once wrote a program in VB6, then re-wrote it in .NET. That's the closest I've come to a head-to-head comparison, but it wasn't even close. I did this because somebody broke into my house and stole the computer that had the VB6 code. I only had a much older copy. The program would have been fairly ideal for a head-to-head comparison of performance, but I no longer had the good VB6 version, and when I re-wrote, I greatly improved the program in terms of features, so it wasn't much of a comparison anyways. The performance was essentially the same. Perhaps the .NET was a bit faster, but the comparison couldn't really be made for a few reasons. The VB6 program would take around 3 days to run, the .NET might have gotten down to 2 days, but that could be due entirely to algorithm improvements due to re-visiting a problem.

    Why would I ever bother doing such a thing again? Why would anybody bother doing such a thing if they didn't have an outcome they wanted?
    My usual boring signature: Nothing

  31. #191
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: Vb6 , the Future, and what I have discovered

    I agree, it would be pointless. It wouldn't change anyone's minds anyway.

  32. #192
    Frenzied Member
    Join Date
    Dec 2012
    Posts
    1,468

    Re: Vb6 , the Future, and what I have discovered

    I hate to get involved in these kind of discussions, but I can't hold back any longer. When .NET first came out, I was prepared to make the transition from VB6. But the length of time it took to develop in VB.NET (even after adjusting for the learning curve), and the fact that I could only convert about half of my utilities, led me to abandon the effort. Admittedly, it has probably vastly improved since then, but every time I get the urge to re-examine it, I simply look at the quality of code in the VB6 CodeBank as compared to the VB.net CodeBank.

    When someone comes out with a fast and efficient RAD environment that has lots of flexibility and looks like it is going to last, I will consider jumping on board.

    J.A. Coutts

  33. #193
    The Idiot
    Join Date
    Dec 2014
    Posts
    2,721

    Re: Vb6 , the Future, and what I have discovered

    if Olafs plan is to create a new IDE and RC5 is a part of that, it would be easier to have a subsection where we can discuss that,
    it would be easier for everyone and we would not get any RC5 suggestions here at all, we don't need to mix it.

    Right now theres a lot of discussion, but in the end of the day, what we need is something solid, that we can use, the RC5 we can use, the new IDE (if created) definitely we can use. Who is right or wrong doesn't matter.

    The thread is about "the future", not about COM this, C here, Linux that, its the future of VB6 that im interested with. This neverending "I Know Best" is not interesting to read, its out of topic.

  34. #194
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,817

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by couttsj View Post
    When .NET first came out, I was prepared to make the transition from VB6. But the length of time it took to develop in VB.NET (even after adjusting for the learning curve), and the fact that I could only convert about half of my utilities, led me to abandon the effort. Admittedly, it has probably vastly improved since then, but every time I get the urge to re-examine it, I simply look at the quality of code in the VB6 CodeBank as compared to the VB.net CodeBank.
    Precisely.
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  35. #195
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    9,817

    Re: Vb6 , the Future, and what I have discovered

    You know? Maybe I'm way off here, but I think there may be a USA vs the-rest-of-the-world distinction going on here.

    I keep seeing all this discussion about platform independence, and I'm like, "pfff whatever", I'm fine with Windows. I read things in the news like Barcelona and India going to all open source software (and, just FYI, I read Linux and Libre when I see that), and I go, "Hmmm, interesting", and then go on with my work.

    Sure, here in the U.S., we use Linux boxes for servers and other back-room functions, but you virtually never see a Linux box sitting on a secretary's desk or at the nurse's station in a hospital. Here in the U.S., Windows just absolutely owns that world, and I truly seriously doubt it'll be changing anytime soon. Microsoft would love to get more of a foothold in the OS for portables market, but they know their bread-and-butter is in desktop and full-power-laptops to facilitate those desktops.

    Sure, Microsoft is always pushing the envelope with their business model (gaming, portables, servers, etc), but their core is the front-lines desktop (especially in the U.S., and I suspect in many other places in the world).

    Having said that, that's also my world, maintaining and enhancing an application that serves a particular niche market in the desktop world. As such, I just never ever concern myself with any OS other than Windows. It's all just on another planet for me.

    There have been lots of discussions about trust, but those are just facts (and nothing I can do anything about).

    Best Regards,
    Elroy
    Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.

  36. #196
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    399

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    For example, the COM standard has no notion of classes, it only cares about interfaces. Any language based on this would also be limited thus. You wouldn't be able to implement method overloading or inheritance. The standards upon which the .Net Framework is based is far more robust and as such any language or compiler that targets it will benefit greatly from this.
    I absolutely disagree with this. COM stands for Component Object Model, and as I see it, an Object needs a Class that defines it and what it is able to do. In the case of COM, this functionality is exposed through Interfaces. I use Inheritance with VB6 COM objects everyday with my language, and could also use overloading but simply don't like it. I don't know about robustness, but dilettante already posted a clarifying image about that "glorified conquest".

    Quote Originally Posted by Niya View Post
    This is why MS chose to carry Visual Basic in this direction.
    I don't believe in this either. It was already pointed here that MS itself doesn't use that miraculous technology for their own serious stuff, still strongly relying on the so called "old and obsolete" COM.
    Carlos

  37. #197
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by couttsj View Post
    I simply look at the quality of code in the VB6 CodeBank as compared to the VB.net CodeBank.
    It is true that the VB6 CodeBank has a much higher quality of code than the VB.Net CodeBank when judged on merits of sheer technical expertise behind them. There is a reason for this and it's quite simple, it has to be that way if VB6 is to compete in this new world. The .Net Framework is so vast that pretty much everything is covered. When you have such a huge library to call on, you end up spending more time thinking about what you're writing rather than how to write it.

    I'll give an example. The last time this discussion came up, threading was mentioned. Olaf showed us a method of writing multithreaded code in VB6. I look at it and it was truly remarkable. It really was an amazing piece of code. You're never going to see such a thing in the VB.Net CodeBank simply because it's not needed. MS took care of all the nasty details and gave us a simple way to engage it.

    Windows and the computers they run on have changed considerably since VB6 came out. For VB6 to stay competitive in this day you must have guys like Olaf, Lavolpe, Dilettante and Krool pushing it to its limits. This is why the VB6 CodeBank has such high quality work.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  38. #198
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,943

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by couttsj View Post
    I hate to get involved in these kind of discussions, but I can't hold back any longer. When .NET first came out, I was prepared to make the transition from VB6. But the length of time it took to develop in VB.NET (even after adjusting for the learning curve), and the fact that I could only convert about half of my utilities, led me to abandon the effort. Admittedly, it has probably vastly improved since then, but every time I get the urge to re-examine it, I simply look at the quality of code in the VB6 CodeBank as compared to the VB.net CodeBank.

    When someone comes out with a fast and efficient RAD environment that has lots of flexibility and looks like it is going to last, I will consider jumping on board.

    J.A. Coutts
    I had the opposite experience. I went to .NET to write for PDAs, which existed at the time. The learning curve was trivial, and I found it quite appealing, so I simply switched over and never went back. It wasn't much of a decision, really. As far as I'm concerned, a programming language is just a tool. I really don't care about the color of the handle, just whether it does the job. That's why I curse JS, because it does...a job that could decidedly be improved upon. And it is, actually, so maybe one day it will be better.

    In biology, at the moment, there's a lot of momentum behind R. The language is designed for statistics and has lots of libraries to help out with that. However, to hear some of my non-programming colleagues talk about it, you'd think R was the only language that could handle statistics. It's math. Computers do nothing much OTHER than math. That tool might turn a certain style of screw a bit more easily than other languages, but it's hardly the only one that can turn the screw. Still, if I am asked to do something in R, I'll do something in R. I didn't realize anybody cared which tool they used until people started talking about VB6 vs VB.NET. Some folks, like axisdj, have made a good point: If your livelihood is centered around a large program that you have written in some language, anything that threatens the future life of that program is an existential threat to your career. Still, if you make the determination that you can't continue in the old language, you have to move on to something.
    My usual boring signature: Nothing

  39. #199
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,943

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Elroy View Post
    You know? Maybe I'm way off here, but I think there may be a USA vs the-rest-of-the-world distinction going on here.


    Sure, here in the U.S., we use Linux boxes for servers and other back-room functions, but you virtually never see a Linux box sitting on a secretary's desk or at the nurse's station in a hospital. Here in the U.S., Windows just absolutely owns that world, and I truly seriously doubt it'll be changing anytime soon. Microsoft would love to get more of a foothold in the OS for portables market, but they know their bread-and-butter is in desktop and full-power-laptops to facilitate those desktops.
    I used to think that, too, but now we seem to be going mobile. Somebody got it in their head that this would vastly improve something. I don't want to get into the reasoning behind that. Heck, I don't fully understand it. Still, that's what pushed it. I was told to buy a bunch of tablets and use them (seriously! Buy them, then figure out why!). At that point, you are off Windows...at this time. I've long held that this may not last, and it may not. The future is unclear. This may be the driver, though. Tablets are cheap. If certain places (even in the US) see this as the cheap way to go, it may well be the way we DO go.

    I'd also like to second something Niya just said: I'm impressed by the skill shown by some of the folks working in VB6. You've taken the language further than it was likely ever intended to go, and that's quite impressive. Multi-threading in VB6, fancy that! I remember when I first read a thread about that (started by WokaWidget, by the way, so I really DO still remember it). It was pretty impressive, and kind of convoluted. You won't see anything like that written for .NET, because why bother? You've got half a dozen different mechanisms for the same thing, just pick one and move on. Threads? Tasks? BGW? even Async stuff...and something else that I don't have a name for. A couple of those aren't even necessarily threads, unless it is advantageous to be.

    So, if you have to do more clever stuff to cover the same ground, then you're going to have more clever solutions. There are clever people out there, without a doubt.
    Last edited by Shaggy Hiker; Jan 28th, 2018 at 08:50 PM.
    My usual boring signature: Nothing

  40. #200
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,207

    Re: Vb6 , the Future, and what I have discovered

    Quote Originally Posted by Niya View Post
    I'm starting to think maybe you're the one that doesn't understand the tools he is using, namely COM.
    Niya, I'm in the process of writing a compiler for it - and thought that I've had COM-inheritance already explained to you in a recent thread.

    It is (as Carlos has already mentioned) indeed quite easy to remain COM-compatible - and at the same time still to offer
    true Inheritance over a new VB6-Compiler which hides the details of the VTable-arrangements when it tackles VB.Next-Classes.

    I've now made a Demo-Project especially for you, which shows (in a plain, straight-forward implementation of VB-Code),
    how this stuff works under the covers.

    Let's assume we have two Classes:
    - one base-class which is based on IMyClass (defining two Public Methods)
    - and one "derived Class", based on IMyInhClass (which inherits interface.wise from IMyClass, and then adds a single Method)

    A new compiler would then e.g. produce the following simple COM-interface-def, expressed in IDL:
    Code:
    [
      uuid(EF8B4155-A9B5-4008-8FDB-57D373B3C48A), version(1.0)
    ]
    library MyClassTypeLib
    {
        // TLib :     // TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}
        importlib("stdole2.tlb");
    
        // Forward declare all types defined in this typelib
        interface IMyClass;
        interface IMyInhClass;
    
        [
          odl, uuid(4BA4C1B8-EE48-4BE2-BB63-2648605BDB8E)
        ]
        interface IMyClass : IUnknown {
            HRESULT _stdcall AddTwoLongs([in] long L1, [in] long L2, [out, retval] long* retVal);
            HRESULT _stdcall SayHello([in] BSTR MsgPrefix);
        };
    
        [
          odl, uuid(BB2DECE9-1C2F-4409-9141-23D81E70FA8B)
        ]
        interface IMyInhClass : IMyClass {
            HRESULT _stdcall MulTwoLongs([in] long L1, [in] long L2, [out, retval] long* retVal);
        };
    };
    Note the Interface-Inheritance, which IDL (unsurprisingly) understands already
    - (especially as it is expressed at the end - and marked in magenta)
    - and of course another Interface-inheriting part is contained (marked in blue, but that "inheriting from IUnknown" is "required business as usual" with COM-interfaces)

    Now take a look at, what a new compiler would have to produce in addition (expressed in normal *.bas-modules, to underline the fact, that only equivalent C-Code is needed, not C++).

    Each (later compiler-generated) Class-Code comes in two parts (a Class-Definition-part for the VTable-def, and a ClassFactory-part for the Implementation (and later Creation).

    Code for the BaseClass-Def (conforming to the above IMyClass)
    Code:
    Option Explicit
    
    Public Type tMyClassVTable
      IUnk As tUnkVTable 'Space for the 3 Methods of IUnknown
     
      AddTwoLongs    As Long 'followed by Space for the two Function-Pointers of our two concrete Methods
      SayHello       As Long
    End Type
    
    Private mVTable As tMyClassVTable 'preallocated (static, non-Heap) Space for the VTable
    
    Private Sub InitVTable() 'this method will be called only once
      mVTable.IUnk = modIUnknownDef.VTableInherit
      mVTable.AddTwoLongs = FuncPtr(AddressOf modMyClassFactory.AddTwoLongs)
      mVTable.SayHello = FuncPtr(AddressOf modMyClassFactory.SayHello)
    End Sub
    
    Public Function VTablePtr() As Long 'the only Public Function here (later called from modMyClassFactory)
      If mVTable.AddTwoLongs = 0 Then InitVTable 'initializes only, when not already done
      VTablePtr = VarPtr(mVTable) 'just hand out the Pointer to the statically defined mVTable-Variable
    End Function
    
    Public Function VTableInherit() As tMyClassVTable
      If mVTable.AddTwoLongs = 0 Then InitVTable 'initializes only, when not already done
      VTableInherit = mVTable 'return a copy of the filled VTable-Struct
    End Function
    Code for the BaseClass-Factory (the true implementation of the stuff, we currently write into a VB6-*.cls Module):
    Code:
    Option Explicit
     
    Public Type tMyObject 'an Instances of this Object will occupy...
      oUnk As tUnkObject '<- 8Bytes needed for the VTable and the RefCounter (that's half the size of a Variant-Type)
      
      mSomeClassPrivateVariable As Double 'and by defining this (currently unused) dummy, 8Bytes more for the Double (total of 16Bytes)
    End Type
    
    'Constructor-Function to create and return a new Class-Instance of interface-type IMyClass
    Function CreateInstance(Optional ByVal SomeInitValue As Double) As IMyClass
      Dim This As tMyObject 'we use our UDT-based Object-Type in a Stack-Variable ...
          This.mSomeClassPrivateVariable = SomeInitValue 'for more convenience here, whilst "filling it"
          
      'assign a new initialized Object-Reference to the Constructor-Function-Result
      Assign CreateInstance, AllocateInstanceMemory(modMyClassDef.VTablePtr, This.oUnk, LenB(This))
    End Function
    
    'IMyClass-implementation (IMyClass only contains the following two methods)
    Function AddTwoLongs(This As tMyObject, ByVal L1 As Long, ByVal L2 As Long, Result As Long) As Long '<- HResult
      Result = L1 + L2 'note, that we set the Result ByRef-Parameter - not the Function-Result (which would be used for Error-Transport)
    End Function
    Function SayHello(This As tMyObject, ByVal MsgPrefix As String) As Long '<- HResult necessary here as well, although "Interface-wise" this is "a VB-Sub() which does not return anything"
      Debug.Print MsgPrefix & " from the implementation of MyClass"
    End Function

    Code for the DerivedClass-Def (conforming to the above IMyInhClass - and due to inheriting, a bit shorter than the above two Files)
    Code:
    Option Explicit
     
    Public Type tMyInhClassVTable
      MyClassVTable As tMyClassVTable 'this is the inheriting member
      MulTwoLongs As Long 'and this the only addition on top of the inherited class
    End Type
    
    Private mVTable As tMyInhClassVTable 'preallocated (static, non-Heap) Space for the VTable
    
    Private Sub InitVTable() 'this method will be called only once
      mVTable.MyClassVTable = modMyClassDef.VTableInherit
     
      mVTable.MulTwoLongs = FuncPtr(AddressOf modMyInhClassFactory.MulTwoLongs)
    End Sub
    
    Public Function VTablePtr() As Long 'the only Public Function here (later called from modMyClassFactory)
      If mVTable.MulTwoLongs = 0 Then InitVTable 'initializes only, when not already done
      VTablePtr = VarPtr(mVTable) 'just hand out the Pointer to the statically defined mVTable-Variable
    End Function
    
    Public Function VTableInherit() As tMyInhClassVTable
      If mVTable.MulTwoLongs = 0 Then InitVTable 'initializes only, when not already done
      VTableInherit = mVTable 'return a copy of the filled VTable-Struct
    End Function
    Code for the DerivedClass-Factory (the true implementation of the stuff, we later (with the new compiler) would have to write into a VB.NEXT-*.cls Module):
    Code:
    Option Explicit
     
    Public Type tMyInhObject 'an Instances of this Object will occupy...
      oMyObject As tMyObject 'the 8+8 = 16Bytes from the "Instance-Allocation" of the Object we inherit from
      
      mSomeOtherPrivateVar As Long '+ additional 4 Bytes for this (also currently not used) Private-Variable
    End Type
    
    'Constructor-Function to create and return a new Class-Instance of interface-type IMyInhClass
    Function CreateInstance(Optional ByVal SomeOtherInitParam As Long) As IMyInhClass
      Dim This As tMyInhObject 'we use our UDT-based Object-Type in a Stack-Variable ...
          This.mSomeOtherPrivateVar = SomeOtherInitParam 'for more convenience here, whilst "filling it"
          
      'assign a new initialized Object-Reference to the Constructor-Function-Result
      Assign CreateInstance, AllocateInstanceMemory(modMyInhClassDef.VTablePtr, This.oMyObject.oUnk, LenB(This))
    End Function
    
    'IMyInhClass-implementation (IMyInhClass only defines the following method - on top of what IMyClass defines)
    Function MulTwoLongs(This As tMyInhObject, ByVal L1 As Long, ByVal L2 As Long, Result As Long) As Long '<- HResult
      Result = L1 * L2 'note, that we set the Result ByRef-Parameter - not the Function-Result (which would be used for Error-Transport)
    End Function
    And that's it already, with regards to a short demo, how the new compiler will support COM-based inheritance.
    (overriding of inherited Methods, if so desired, is currently left out in the above snippets, but could easily be added as well into that VB6-based demo).

    Here a Demo.zip which includes the above as a working VB6-Project - as well as the needed *.tlb:
    InheritancePerCOM.zip

    Here the Debug-Output the Demo will produce, after clicking the form:
    Code:
    AddTwoLongs-Result: 3
    Hello from the implementation of MyClass
    ObjPtr of MyObj:  3607304 
    
    Output of the inheriting Class starts here:
    AddTwoLongs-Result: 5
    Hello from the implementation of MyClass
    MulTwoLongs-Result: 6
    ObjPtr of MyInhObj:  3627920
    Intellisense is doing as it should, too (showing the inherited Methods of IMyClass also in IMyInhClass).

    HTH

    Olaf
    Last edited by Schmidt; Jan 29th, 2018 at 12:58 AM.

Page 5 of 18 FirstFirst ... 234567815 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width