What if there was a NEW vb6

[dilettante]

So why can't a VB6 fan, no matter how misguided, have a discussion thread here about a "new VB6" or "VB6 alternatives aside from VB.Net" that the usual suspects don't come in and crap all over?

The evidence is clear: every time anyone has tried to have one the malicious behavior begins and goes unchallenged aside from faint and ineffective protests that are never backed up with action.

The real answer is that the taint here isn't going away. People need to move to another site far less hostile than this one.

[dilettante]

I'm also tired of the unchallenged personal attacks:

The only real fanatic i see here is you with your fanatical Anti Microsoft slant!

[FunkyDexter]

If you have a problem with the modding then PM me and I'll be happy to discuss it.

[dilettante]

*Sigh*

It looks like we can't even escape this by posting in the VB forum, since this thread got moved here fairly quickly after it was started.

Time for the Great Migration after all I guess.

[techgnome]

So why can't a VB6 fan, no matter how misguided, have a discussion thread here about a "new VB6" or "VB6 alternatives aside from VB.Net" that the usual suspects don't come in and crap all over?

The evidence is clear: every time anyone has tried to have one the malicious behavior begins and goes unchallenged aside from faint and ineffective protests that are never backed up with action.

The real answer is that the taint here isn't going away. People need to move to another site far less hostile than this one.

so start a thread with .netters need not respond. Fact of the matter is that there's mixed opinions here, whether you agree with it or not, so you're going to get replies from both camps. Plain and simple as that. It's only personal if you allow it to be. If i got my t1's in a bunch every time someone offended me here, the internet would choke on itself. So let it go.

VB6 works for you, so use it. who gives a fig what the rest of us think. If it works, great. It's just another tool. It doesn't work for me, so I use a different tool. Doesn't make you right any more than it makes me right.

-tg

[FunkyDexter]

It was moved because it wasn't suitable in the main VB forum. The description for that forum reads: This forum is for all your Visual Basic (versions 3, 4, 5, & 6) coding questions. This is not a coding question. From the first post this thread was discussive in it's nature and this forum is therefore a more suitable home for it.

[SJWhiteley]

With all due respect SJ I submit it depends on what you are doing with a laptop. We do high end solid modeling. Every few years someone get a bug to buy a high end laptop of (According to the specs) equivalent power to our engineering desktops.
A costly high end vector graphics video card is ordered with the laptop. Faster hard drive, Gobs of memory, etc... They always pale in speed and graphics to our desktops when used for the same purpose.

If all you are talking about is running Office, VS or a browsing session then I agree it makes little difference for mid-range laptops.

Sorry if this is off topic FD. I try not to get sucked into VB6 vs VB.NET conversations.
Bowing out.

That's OK. I would say, though, that High end sold modeling will demand more power than even an 8 core desktop could muster. I.e. you have an application that requires more than workstation power, and scales with power.

If I was doing that sort of thing then, yes, there's no substitute for desktop, er, workstation. Essentially, you are edging into the realm of specialized hardware, which almost always requires a desktop. Are you using Visual Basic - of any flavor - to do your modeling, though?

[SJWhiteley]

You (in general) also have to realize that a huge number of VB.NET programmers did not start out with .NET but VB6 and probably a whole host of other languages (Borland C, oh.my.god.don't.go.there). And a whole bunch of them probably still have a beloved (sic) CD set with VB6 on it, with a CD-R with SP6a along side it - just in case.

Suffice to say, we aren't hostile against VB6; we know it had its time and place, and wouldn't have wanted anything else, but that time has gone. There are, quite simply, better tools.

[Tanner_H]

Suffice to say, we aren't hostile against VB6; we know it had its time and place, and wouldn't have wanted anything else, but that time has gone. There are, quite simply, better tools.

I know we're going in circles here (but that's the way this thread works, right??). But I have to keep pointing out that the exact same thing can be said about VB.Net. There are, quite simply, better tools.

I don't keep bringing this up to start a pissing match, but to keep reminding VB.NET users that VB6 isn't the enemy. It does reek of insecurity that *some* VB.NET users are so threatened by people still working in VB6, or - heaven forbid - discussing a future for VB6 development. Same goes for VB6 users threatened by VB.NET, but at least in that case, it's somewhat understandable given the history of the two languages. (Although 15 years is a long time to hold a grudge )

It's also unfortunate for a tech-savvy crowd to outright dismiss ideas like Kickstarters for new programming tools, while saying things like "it's delusional that one man could create [insert complex piece of software here]." Users of this site should be way more supportive of hobby projects and initiatives to create better VB code and tools. Good VB6 code doesn't hurt VB.Net any more than good VB.Net code hurts VB6.

I always find myself going back to the same points: there's a dearth of good code written in VB, period. VB and VB6 are meaningless in the open-source world. Aside from a few niche products, they're pretty meaningless in the corporate sphere, too, and they may as well not exist in the consumer, web, or mobile worlds.

Dilettante and I argue over a lot of things, but he is dead-on about the hostility of these forums. Aside from a few cliques, there's a shocking amount of disdain for people who bring any enthusiasm to the table. Instead of pissing all over that enthusiasm, why not try to help enthusiastic people redirect it to something productive, instead of just mocking them?

The coding world needs more enthusiastic people, and if that means a little delusion, hey - that's great, too. I'd happily take that over a bunch of cynics.

[Niya]

This thread is quite simply a troll thread. We can spit back and forth as much as we want but we all know what really inspires threads like this even though many don't want to admit it. This thread isn't about how great VB6 was and how bad VB.Net is. It isn't about bringing back VB6, it isn't about all the great software that was created in VB6. This thread and threads like it are nothing more than childish pouting. MS decided to change direction with their VB product line and certain people got mad and instead of acting like adults and making decisions based on what they have been dealt, they make threads like this to cry like children. I for one am annoyed by it, particularly because they pretend its a proper discussion. I see right through this and its annoying. I didn't like it either when they abandoned VB6 but guess what, I didn't go to forums to ***** and moan like some crybaby, I made up my mind, like an adult to give this new thing a chance and it so happened that I was pleased. If I wasn't pleased, I still wouldn't waste my energy trying to promote pipe-dreams. There are dozens of other tools I could use, I'm sure of them would have pleased me.

[FunkyDexter]

This thread is quite simply a troll thread.

Maybe, maybe not.

The thing is, though, that folks are free to create whatever threads they wish, expressing whatever opinions they wish, and other folks are free to respond with agreement or disagreement. Folks are free to offer up alternatives, even if it's an alternative the OP has and will dismiss, or they are free to simply reinforce the OP's views. The one thing they are not free to do is to behave aggressively toward each other.

Something I will say in AxisDJ's favour: when engaged politely and reasonably he responds politely and reasonably. Indeed, when some of the VB6 fans were becoming aggressive and "trolly" a while back (not so much in this thread but you don't have to look far to find them) his has been one of loudest voices telling them to stop, not just in this forum but also in the user voice forums and on his own blog. We may not owe him our agreement but we do owe him our courtesy.

For the record I don't think AxisDJ is anything less than 100% serious in his efforts. I think he's wrong, but he's allowed to be. And at the end of the day, if he is wrong, then he will own the consequences.

[Tanner_H]

This thread is quite simply a troll thread. We can spit back and forth as much as we want but we all know what really inspires threads like this even though many don't want to admit it. This thread isn't about how great VB6 was and how bad VB.Net is. It isn't about bringing back VB6, it isn't about all the great software that was created in VB6. This thread and threads like it are nothing more than childish pouting. MS decided to change direction with their VB product line and certain people got mad and instead of acting like adults and making decisions based on what they have been dealt, they make threads like this to cry like children. I for one am annoyed by it, particularly because they pretend its a proper discussion. I see right through this and its annoying. I didn't like it either when they abandoned VB6 but guess what, I didn't go to forums to ***** and moan like some crybaby, I made up my mind, like an adult to give this new thing a chance and it so happened that I was pleased. If I wasn't pleased, I still wouldn't waste my energy trying to promote pipe-dreams. There are dozens of other tools I could use, I'm sure of them would have pleased me.

Obligatory xkcd

If you think it's a troll thread, why not do the obvious thing and just ignore it? Because it seems a tad hypocritical to call other people in this thread childish after your multi-post rant about reviving obsolete tech.

(Also, if discussions like this bother you so much, why perpetuate it by jumping in with both feet? That's Obvious Internet Behavior 101.)

Maybe, maybe not.

The thing is, though, that folks are free to create whatever threads they wish, expressing whatever opinions they wish, and other folks are free to respond with agreement or disagreement. Folks are free to offer up alternatives, even if it's an alternative the OP has and will dismiss, or they are free to simply reinforce the OP's views. The one thing they are not free to do is to behave aggressively toward each other.

Something I will say in AxisDJ's favour: when engaged politely and reasonably he responds politely and reasonably. Indeed, when some of the VB6 fans were becoming aggressive and "trolly" a while back (not so much in this thread but you don't have to look far to find them) his has been one of loudest voices telling them to stop, not just in this forum but also in the user voice forums and on his own blog. We may not owe him our agreement but we do owe him our courtesy.

For the record I don't think AxisDJ is anything less than 100% serious in his efforts. I think he's wrong, but he's allowed to be. And at the end of the day, if he is wrong, then he will own the consequences.

At the risk of sounding like a sycophant, I just wanted to say that your posts in this thread have been consistently great. I really appreciate your efforts to bring civility and rational thought to heated discussions like this.

[FunkyDexter]

A bit of sycophancy never goes amiss

One thing I would ask, though: can folks stop debating who's trolling who and just get back to the technical side of things? I do appreciate people are trying to be helpful but it's better to hit the report button or send a mod to a pm. Otherwise this is in danger of becoming not just a troll thread but a meta-troll thread.

AxisDJ, I have to say I'm surprised at the support your project is getting. You do look like falling short of your goal in the time limit at the moment but I was expecting this to be a flat out bust and you are getting some pretty substantial endorsements. You may prove us wrong yet.

[dilettante]

I wonder whether AxisDJ and friends have considered existing efforts.

For example, there is the language formerly known as KBasic that is supposed to accept conventional VB6 syntax as well as having its own language extensions.

I doubt it imports existing VB6 Projects, but then I doubt any Olaf effort would either since I was pretty sure the goal there was to build on top of his Cairo wrapper for the user interface.

They claim it compiles to native code, though I wouldn't be surprised if it actually generates p-code wrapped into an EXE along with an interpreter. But it has been years since I've even looked at it. Since it targets Mac and Linux as well as Windows it probably isn't going to be quite as native as VB6, for example it may not have any COM support at all even on Windows.

Pooling efforts or jumping onto pre-existing coattails is probably the only way to grow a decent sized community though.

[Niya]

If you think it's a troll thread, why not do the obvious thing and just ignore it? Because it seems a tad hypocritical to call other people in this thread childish after your multi-post rant about reviving obsolete tech.

(Also, if discussions like this bother you so much, why perpetuate it by jumping in with both feet? That's Obvious Internet Behavior 101.)

Because people are going to come here and actually believe their nonsense. It happened to me.

I stayed in VB6 far longer than I was supposed to because of idiotic threads like this. The reason I know for a fact that this is a troll thread is because I know EXACTLY how axisdj and other like him felt. I used to spout all the same nonsense, maybe not on forums but I had conversations deriding VB.Net when I was still a huge VB6 fan. I used to talk about non-native compilation and how slow and bloated it was.

Everything started to change when Windows Vista had just become prominent with Windows 7 still in its infancy in terms of adoption. XP was starting to wane. More and more I was seeing Vista and that's when things started falling apart. The Visual Studio IDE was giving tonnes of trouble, whether it be installing it or how it worked. My VB6 apps started to malfunction a bit, libraries were missing and so on. It started to feel like an up-hill battle. I had to spend a lot of effort just to keep some apps working. I didn't like this and pondered for quite a while on what I should do.

I started doing a lot of searching on topics related to VB6, mostly to help me fix some of my issues and some articles and posts about the future of VB6. I found quite a lot of threads and blog posts like this with people touting how great VB6 was and what utter garbage VB.Net was and I agreed. I had never touched VB.Net and I was a staunch die-hard VB6 fan. A lot of people who I thought sounded authoritative said that MS is going to realize their mistake with VB.Net and revive work on VB6. I was relieved. I figured all I had to do was wait and MS would improve support for VB6 apps and maybe give us a modern version. I was already being told by that time to try out VB.Net and I refused to touch that bloated garbage. I mean all these hundreds of people online with their fancy blog posts and such can't be wrong, right ? So I waited for MS to come to their senses like all these people on forums and blogs said they would. Vista passed and Windows 7 was the new thing. So I finally abandoned XP, which was the last OS where all my VB6 apps ran flawlessly(or at least the way I expected them to).

So there I was, installing Visual Studio 6 on Windows 7. It installed no problems. Everything looked good so far. I open VS and there it was, my first problem. The VS6 Form designer was extremely sluggish. Spreading controls on a Form was a nightmare. It wasn't smooth like it was in Windows XP. I tried for a while and realized I couldn't live with this. It was too difficult to use the VS6 designer on Windows 7. Fine tuning a GUI using such a sluggish designer was impossible. There I was all defeated, resigned to the fact that I'm going to have to write apps in this malfunctioning piece of software. My other choice was to go back to XP but I was already loving Windows 7 so that was out of the question.

I started searching again on VB6 only to find a bunch of results about .Net this and .Net that which I totally ignored. And after I failed to get another app to work on Windows 7, it was the last straw. There I was, ready to go back and re-install XP. All of these people who I thought were smarter than me said VB6 would make a comeback and yet I wasn't seeing this. Every other week there was some announcement from MS about all the great new features coming to .Net.

Then BOOM! It was like a nuclear explosion went off inside my head and I had a great realization. All this hate and resistance I had towards VB.Net was never really my own. I realized that I hated something I never even tried. I remember all the arguments I had when I was told to try it and realized that I can't actually justify my resistance because I never actually used the product. I was a staunch VB6 fan and I allowed myself to be encouraged by people in threads like this to resist .Net and wait for a "new VB6". Hell, I even parroted some of the nonsense I read like .Net being bloatware but I was realizing that I was being stupid. I never used .Net so why should anyone listen to me. I was just regurgitating butthurt garbage I saw in blogs and forums.

I had a copy of VS2008 Pro lying around which I never tried for a couple years and decided I would try it. I was expecting to be disappointed. Still I believed in what the many voices of VB6 fandom were saying. First thing I noticed ? The IDE's designer wasn't sluggish. That was a good start. I started making small programs with it in an attempt to justify my hatred of it. And it was then I started realizing that I couldn't. It did every damn thing I was able to do in VB6. One of the first thing that really impressed me was the ability to dynamically wire event handlers purely from code. And the best part, I could wire as many objects, even objects of varying types to the same handler!. This was something I wanted very badly in VB6. Control arrays were to only way to do this in VB6 and there was no way I know of to do this if the objects weren't controls. The lack of this feature hindered me several times in VB6, I worked around it but I always wanted it. I also loved the fact that controls were themed by default. No more manifests and hacking around with InitControls and having to always use Common Controls 5.

From there I started researching all the new features VB.Net had and I started loving the language. After a couple months, using VB6 again was painful. I remember regretting not embracing VB.Net sooner, and it was all because of my own stupidity and threads like this.

I listened to all the garbage people said and I made a bad choice. I was mislead. The reason I am so vocal in threads like this is because there was no one like me when I used to believe in them. There was no one to tell me that these guys talking about a VB6 revival was full of ****. I wish to all the heavens there was someone like me when I was looking for guidance on my decision with regards to my future with VB6. If there are people out there looking thinking about switching or people thinking about starting programming and VB comes up. I would like for them to get the whole truth. Threads like this are based on emotions, not truth. I too once hated the idea of leaving VB6 so I know exactly what threads like these are, an emotional dumping ground.

[Schmidt]

I wonder whether AxisDJ and friends have considered existing efforts.

Don't know, but I already did study existing projects - extensively (FreeBasic-, KBasic- and O2Basic- Compilers).

None of them has true VB6-compatibility at the compiler-level (e.g. not using SafeArrays, or Variants, or
StdCall - or COM-Calling-conventions with regards to the Arguments-Lists, no Optional Parameters,
no Event-Concept as wont in VBClassic).

- KBasic (QT-Basic) compiles to intermediate C++-Code - and from there native (either per MingW or VS2008)...
.. tightly interwoven with the QT-Framework - and thus a good set of BaseWidgets is available -
.. though adapting existing Widgets - or writing your own entirely - that's a nightmare
.. it is huge (zipped IDE-Download-Size = 183MB) - even the smallest deployed App will require the entire QT-stack (~18MB zipped).

- The O2-Basic native-compiler is quite nice (smallest codebase by far, very clever developer) -
.. but already the language-syntax is not really "VB-ish" enough (although being "nice and sparse") -
.. I contacted him about 1.5 years ago - to join forces with the goal to make the whole thing "VBish" -
.. but he had no interest...

- FreeBasic does have a quite large codebase for the compiler (not easy maintainable) - but otherwise the most
.. "complete" and stable of the 3 (although - as O2-Basic - missing a Visual-IDE and an integrated Widget-Framework)

... I doubt any Olaf effort would either since I was pretty sure the goal there was to build on top of his Cairo wrapper for the user interface.

Sure, but the vbRichClient is not only a "cairo-wrapper" (since that implies, that only "nice-drawing" is available) -
on top of that it already contains a UserControl- and Form-engine which is quite compatible (regarding
the available Events) with the UserControl- and Form-Engine we have in VB6 - and it is already usable today,
including a "device-independent Pixel-concept at 96dpi" (as is standard in e.g. WPF and Direct2D too) - and
allows (along with its Zooming-capabilities, which work across all Widgets on a cWidgetForm) to write
Unicode- and DPI-aware Applications.
And that independent of any CommonControls, or other MS-GUI-stuff (aside from the needed TopLevel-hWnds
for the "final Flip of the cairo-OffScreenBuffer").

As it is currently, this engine supports far more options (GUI-wise) than what is available in QTBasic(former KBasic).

As for VB6-compatibility - writing a VB5/6-Form-Importer wouldn't be that difficult, as long as one only
plans to "map" the VB6-intrinsic Controls to their pendants which are already contained in vbWidgets.dll.

Writing Property-, Method - and Event-compatible Widgets for the more complex controls (as e.g.
ListView or TreeView or FlexGrid) would be possible too - but as I've already explained in the other
thread (which was started by Jacob Roman) - I'm (personally) not interested to write those
"1:1 mappable, more complex Widgets" myself - others might do that though.
Doesn't mean, that there isn't a TreeView or ListView in vbWidgets - but both Widgets are "virtual ones",
which allows for far greater flexibility, since the Data can remain outside the Control (and rendered
any way you like in the scrolling container).

My priority for the compiler would be 1:1 Code-compatiblity (as well as Type-compatibility with regards
to SafeArrays, Variants, (V)BStrings etc.) when importing and compiling *.cls and *.bas modules only.

And that is doable quite easily (compared to my efforts which were going into the GUI-framework
which is already alive and kicking in vbRichClient so far). Since the vbRichClient itself (as well as the
code for the new Widget-stack in vbWidgets.dll) consists only of *.bas and *.cls modules, this new
"accompanying visual and non-visual Class-Runtime" would be easy translatable as well (and it would
be statically linkable into ones own Apps too).

So, given a new IDE, in case it is written only using the RichClient-Widgets (in VB6) - the whole
"stack" (new, extended Class-Runtime and IDE) would be translatable as soon as the new compiler
achieves this goal: *.cls and *.bas - compatibility.

@FunkyDexter, who wrote:

He's also already demonstrated a complete lack of interest in undertaking such a project in the "VB Classic (a true VB7)" project. He overtook JR's project, made a lot of noise, announced that it wouldn't support porting from VB6 (your key criteria) and then produced... nothing, as far as I can see ...

As seems often the case here, ones own misunderstanding of things is later on stated as "fact".
So let me clear a few things up for you:

I was far from "demonstrating a lack of interest" in that thread you mentioned, instead I cleared-up quite
a lot of things I thought ... (for Jacob Roman, who - sorry to be that frank - didn't have the slightest clue,
how to write a compiler at all - as well as for others, who didn't understand what is lacking in all the existing
Basic-compilers and why it is difficult to simply "saddle on" (when the goal is, to write a truly VB6-code-
compatible Compiler, which is tightly integrated with "GUI-stuff" and interwoven in the IDE itself per:
Edit&Continue, PCode concept, intermediate C-Code for native compilations.

As for the claim: "a single developer is never capable to write such a thing" - you are mistaken -
all the existing compilers I listed above, were written by single developers.

So, the compiler itself (as well as the IDE) is (compared to, say - a decent Widget- and Class-Framework)
the *much* smaller part.

The funny thing is, that this existing framework is only slowly adopted by the VBClassic-community.
Especially by the more experienced members in the VB6-Forum, who apparently have a hard time
embracing it - unwilling to understand (or support) the larger concept behind it.

@dilettante again:
You wrote, that you'd be happy with an "extended vbRuntime 6.1" (either statically liked into -
or shipped with your Exe).

Well, you have that already today - the 3 vbRichClient5-libs will add only 2.3MB zipped (or 1.6MB
when 7zipped) to your deployment - and the whole thing doesn't even need to be registered
on the target-machine due to "built-in regfree COM").

In case the compiler sees the light of day, then you could link this stuff into your Exe statically too
(and in this case, only the Classes you made use of, so a "standalone Exe-size" of < 1MB - in case
you didn't make use of the SQLite-DBengine-Classes for example - is quite possible).

Olaf

[Schmidt]

Because people are going to come here and actually believe their nonsense. It happened to me.

I stayed in VB6 far longer than I was supposed to because of idiotic threads like this...

We can stop right here.

As I read this recently in another thread (and it's matching quite well)...

- You left VB6 (as a Toddler)
- then learnt to properly walk (in a different language, using different companion-libs)
- and now blame the tool (VB6, in retrospect) for "being a Toddler once"

The professionals who still use VB6 to this day (usually self-employed guys,
who were not forced to "jump ship" because their employer said so) can
develop modern, well-structured Desktop-Apps for all current Win-OSes.

That's it already in terms of "arguing" - since there's nothing really to argue-over.

You don't use it anymore - so how dare you tell (e.g. me), that I don't know
what I'm doing - since I certainly know quite well, why I never switched to .NET.

And no, in this discussion I don't even have to tell you my reasons, because that's
entirely beside the point - the point in this discussion is a (potential) "New VB6" -
so there are enthusiastic developers, who speculate about this or that - fine -
why do you care - it's a language you don't use (or don't like, whatever) - so
what about just ignoring this discussion on your end?

Olaf

[Niya]

You don't use it anymore - so how dare you tell (e.g. me), that I don't know
what I'm doing - since I certainly know quite well, why I never switched to .NET.

This is exactly what you guys are doing. When some guy comes along and listen to how you guys take a **** on .Net, what's he going to do ? He is probably going to side with you since he probably came here expecting to hear from people who knows better than him and you're not giving him a fair assessment. He's gonna listen to you rant and rave all day and conclude that he should go with VB6 despite there being a better alternative. You're taking advantage of his lack of knowledge and/or experience to influence his choice. He doesn't know any better. You are forcing him. I was that guy and I hate guys like you for what you did, filled my head with a bunch of nonsense that I eventually found out on my own, carries no weight.

[Niya]

why do you care - it's a language you don't use (or don't like, whatever) - so
what about just ignoring this discussion on your end?

I don't care. I only care that you deliberately mislead people because of your own broken hearts. Yall want to write your new VB6, go right ahead. You have my support 100%. In fact, I'd love to see this get underway. But please don't come here to slander .Net to feed your own vicious need for some kind of feeling of revenge. Its not fair to the newbies And its childish.

[Schmidt]

I don't care. I only care that you deliberately mislead people because of your own broken hearts.

As for "broken hearts" - I can ensure you, that it's mostly technical reasons, why I prefer VB6
(native compilation, deterministic behaviour of the lifetime of Class-instances, fast IDE,
fast compile-times, compiled Apps deployable from XP to Win10 unchanged and with
relative low footprint - even as portable Apps (using regfree COM).

So, when I tell you (again), that a clean, well-structured code-base is only a question
of ones own professionalism, not dependent on the tool one is using - and doable
with the VB6-compiler and -IDE quite fine - how on earth is that "misleading people"?

But please don't come here to slander .Net to feed your own vicious need for some kind of feeling of revenge.

What the... - where on earth did I "slander .NET" - what I said was:
"Don't blame the tool for your own shortcomings".

Over in the VB6-forum you recently give me replies as:
"Oh, nice - didn't know that" (along with Rep-points) -
and now I'm suddenly "misleading Newbies"?

I can only repeat - in case you switched at a still lower level (on your own VB6-learning-curve)
to a different language (how else shall I interpret your comments on my posts over there),
then why selling this, let's say - "early abortion in mastering a given development-tool"
now as "failure of the tool itself"?

Olaf

[dee-u]

This is exactly what you guys are doing. When some guy comes along and listen to how you guys take a **** on .Net, what's he going to do ?

I don't know but it looks to me Olaf just didn't switch to .Net but perhaps that does not mean .Net is weaker than VB6, only he just prefers using VB6.

[Niya]

I tend to lump all the VB6 fans together. Tanner_H is probably the only exception. He's extremely reasonable for a VB6 supporter.

Olaf in particular may not have slandered .Net but I do see it all the time from others, especially dilettante.

[dee-u]

Dilletante brings the spice to this forum, otherwise it'd be so boring. Cheer up guys!

You guys should go out and meet new people and be happy.

[Niya]

So, when I tell you (again), that a clean, well-structured code-base is only a question
of ones own professionalism, not dependent on the tool one is using - and doable
with the VB6-compiler and -IDE quite fine - how on earth is that "misleading people"?

I'm sure someone can write PhotoShop in pure ASM with a "clean, well-structured code-base" and good "professionalism". Doesn't mean its better to write it in ASM than C/C++.

As for "broken hearts" - I can ensure you, that it's mostly technical reasons, why I prefer VB6
(native compilation, deterministic behaviour of the lifetime of Class-instances....

These are the only sensible reasons in this entire quote....

..., fast IDE,
fast compile-times, compiled Apps deployable from XP to Win10 unchanged and with
relative low footprint - even as portable Apps (using regfree COM).

QuickBasic has an even faster IDE and almost instantaneous compile time. Why aren't you using QuickBasic ? I'm pretty sure with your knowledge you can rig up ways to call the Windows API from QuickBasic.

What the... - where on earth did I "slander .NET" - what I said was:
"Don't blame the tool for your own shortcomings".

I don't blame VB6 for anything. Its a good language/IDE but the modern ones are far better.

Over in the VB6-forum you recently give me replies as:
"Oh, nice - didn't know that" (along with Rep-points) -
and now I'm suddenly "misleading Newbies"?

Ignoring context is a specialty of yours I see. You are one of the most talented programmers I have ever seen and you certainly deserve praise for that but you don't do justice when speaking on this topic. You always omit or otherwise twist things up to support your own bias which is unfair to the readership. They aren't getting the full facts, only a distorted view.

I can only repeat - in case you switched at a still lower level (on your own VB6-learning-curve)
to a different language (how else shall I interpret your comments on my posts over there),
then why selling this, let's say - "early abortion in mastering a given development-tool"
now as "failure of the tool itself"?

Olaf

Again here you go twisting things up. VB6 never failed at what it was supposed to do. What I'm saying is that now we have a tool that does practically everything better. Saying something failed isn't the same as saying there is something that surpassed it.

Now in case you were talking about what I said in my long post about my VB6 apps breaking when Vista was introduced, are you saying that "mastering" it involved fighting up-hill battles after MS clearly advised against it ? If that's the case then that would make me foolish. Yes I could have hunkered down and fight to get my broken apps to function correctly, that is true but why would I do that ? So I can brag about how clever I am ? You tell me. I have a couple of apps that didn't function correctly when I ran them on Windows 7.

I had two choices. One, I could have stayed in VB6 and start digging up into the OS and whatever docs I could find to hack my way to a solution. Two, rewrite it in a modern version of the same language that promises none of these headaches. I chose the second way and re-wrote them in VB.Net. Now you tell me, why was that a bad choice. I'd love to hear your answer to this one.

[Niya]

Dilletante brings the spice to this forum, otherwise it'd be so boring. Cheer up guys!

You guys should go out and meet new people and be happy.

I am happy.

See ?

[dee-u]

Aww, that's a cute one!

[NeedSomeAnswers]

I tend to lump all the VB6 fans together. Tanner_H is probably the only exception. He's extremely reasonable for a VB6 supporter.

Olaf in particular may not have slandered .Net but I do see it all the time from others, especially dilettante.

Yes Tanner_H, Olaf, and AxisDJ are all as far as i see it basically good posters. there are a few others also. Save your wrath Niya for those that deserve it

Dilettante does protest to much, including accusing me of doing exactly what he does in these threads, when i pointed out his behaviour!!

Which is a pity as he is obviously knowledgeable but seems to delight in being the VB6 voice to bash .Net in his eyes to counter all the VB6 bashing form .Netters (his word not mine)

[FunkyDexter]

Olaf, my point was that I don't believe the project you were proposing will meet AxisDJ's requirements. Perhaps I've misunderstood your proposal and perhaps not so to remove doubt lets get down to the actual user requirement. AxisDJ's kick starter contains the following:-

It will only succeed if at least 99% of the vb6 code is importable and a programmer can import his/her vb6 project and re-compile it in a few hours.

So the question is: will your proposed solution allow the import of a complete VB6 project, replete with forms, user controls, frm and frx files, code behind, and third party components (.dlls, .coms ActiveX etc, both compiled and as source) and "just work" on a simple recompile?

If the answer to that question is an unqualified "yes", then I take it back, you have the potential to close a wide gap that a lot of people clearly want closed. If you need to qualify that "Yes" in anyway then that's a real danger sign that the your proposal and AxisDJ's requirement don't truly marry up. If my reading of your comment in that thread is correct (and it may not be) you were saying that at least one of those elements won't be supported. Indeed, you've already got a qualification in your post in this thread: "My priority for the compiler would be 1:1 Code-compatiblity (as well as Type-compatibility with regards to SafeArrays, Variants, (V)BStrings etc.) when importing and compiling *.cls and *.bas modules only."

AxisDJ is talking about giving $150, 000 dollars of other people's money. Before that happens you both have a moral responsibility to put any gaps between their expectations and what you propose to deliver right up front. Don't get bogged down in justifying your approach or explaining why those gaps are necessary or unavoidable, just show them the gaps in plain and simple terms.

[FunkyDexter]

Can we not now turn this into a Dilletante bashing thread Again, I disagree with a lot that he says, but the correct response is to offer up reasoned counter arguments rather than calling him a fanatic. He gets to have and express his opinions the same as everyone else does (though, Dillietante, don't expect them to go unchallenged).

[Tanner_H]

One thing I like about dilettante's posting style is that he often shares URLs to back up his position.

We can argue over the quality of those links (which is half the fun, really), but I really appreciate that he brings actual data to the discussion. That is infinitely more useful then people arguing with nothing more than personal experience, half-baked opinions, or - as is often the case - just making **** up.

Love or hate his opinion on the future of .NET, at least he's done a lot of research to back up his points. That's more than I can say for most people (including myself).

[Schmidt]

So the question is: will your proposed solution allow the import of a complete VB6 project, replete with forms, user controls, frm and frx files, code behind, and third party components (.dlls, .coms ActiveX etc, both compiled and as source) and "just work" on a simple recompile?

The *.frm (as well as *.ctl) Files have the same format (with regards to a Parser, which
goes through them -> ChildControl- and Menu-definitions first, followed by "normal VB-Code")

Those are quite easy to parse (making a list of ChildControls, their Positions and Property-Settings) -
*.frx and *.ctx contain Property-Content which was not "easy to encode as a String, directly in *.frm or *.ctl".

For those "extended Property-Bags", Parsers already exist too (I think I read something from LaVolpe which covered that).

So, making a List of Child-Controls shouldn't be that hard - the question is, what
Control-Class needs to be instantiated (to be properly positioned and filled with the
parsed Property-Values).

If (as I already wrote) - for each and every Child-Control-ClassInstance (described in *.frm and *.ctl)
we have a "Property and Behaviour-compatible WidgetClass at hand" - then we can just use that
"Mapped, new Control-Instance" in the siting process of such an imported Form or Control-Definition.

Third party-COMponents (and Controls), for which we don't (yet) have 1:1 matching Properties and behaviour
in a mimicking replacement, would need to be instantiated (sited) per COM directly - and then managed on
the Parent-Container in question over their COM-interface (as VB6 currently does generally).

For the intrinsic Controls, such "nearly identical Replacment-Widgets" exist - for the more complex
Controls such Replacements would need to be implemented - or general COM-support would need
to be considered (similar to how things work in e.g. Delphi or Lazarus with COM-support).

If you need to qualify that "Yes" in anyway then that's a real danger sign that the your proposal and AxisDJ's requirement don't truly marry up.

"Danger" sounds so negative - it's just work (among other work-load which needs to be done) -
and work I didn't want to "burden myself with" - at least not at first - it's just "further down on
my priority-list" - but that list will hopefully become a "community-list" over time (when the
compiler-sources are open) - and some of those tasks (as e.g. such a *.frm-importer and
writing 1:1 compatible WIdgets) are splittable at an early time (not dependent on something
"to be finished first" at the compiler/debugging or IDE-front). In fact they can be started today.

If my reading of your comment in that thread is correct (and it may not be) you were saying that at least one of those elements won't be supported.

As said, *anything* can be supported - it's a matter of the available time-frame and the priority-list,
what has to come first.

Indeed, you've already got a qualification in your post in this thread: "My priority for the compiler would be 1:1 Code-compatiblity (as well as Type-compatibility with regards to SafeArrays, Variants, (V)BStrings etc.) when importing and compiling *.cls and *.bas modules only."

And if that goal is reached, we have something no other compiler out there is currently capable of.
Together with the fact, that a decent Framework would be available (and translatable) when that
goal is reached, we can work our way from there to about anything.

AxisDJ is talking about giving $150, 000 dollars of other people's money. Before that happens you both have a moral responsibility to put any gaps between their expectations and what you propose to deliver right up front. Don't get bogged down in justifying your approach or explaining why those gaps are necessary or unavoidable, just show them the gaps in plain and simple terms.

That would be up to AxisDJ - and to be clear about it - his activities and projects are his own...
He asked me about the compiler-stuff per mail - one year ago or so - and what I said there was basically, that:

Yes, I will continously work further on it - in my own pace (about 1-2h per day on average -
same way as I've always done on the vbRichClient-project over the last 10 years) -
and yes, I did say that it would go faster when I'd work "4-6h per day on it" (or even fulltime) -
but that this would need funding "from somewhere or someone" - he mentioned kickstarter
or similar platforms for that - I had a few doubts ("...but if you think you can manage it, go on") -
but that was it basically - as said - already quite some time ago...

I'd have wished that a few more names would have been mentioned (as "the ones capable and willing
to work on that") - and that the 99%-compatibility we've just discussed would have been lowered
a bit - or set into context with a few time-frames and a priority-list - but I wasn't shown the text
of the proposal which is now online.

I'm as surprised as everyone else, that he really "did it" now (as well as, that there's indeed money
coming in so far).

Olaf

[FunkyDexter]

With this paragraph you just shot up in my estimation:-

I'd have wished that a few more names would have been mentioned (as "the ones capable and willing
to work on that") - and that the 99%-compatibility we've just discussed would have been lowered
a bit - or set into context with a few time-frames and a priority-list - but I wasn't shown the text
of the proposal which is now online.

The problem (and I appreciate it's not one of your creation) is that you and your tool are being held up as being the way for forward for VB, including simple migration of, basically, any VB6 app, regardless of it's components. Essentially, promises are being made on your behalf. You didn't make them and I don't believe you have any intention to keeping them, at least, not within the sort of timescales that will be expected off the back of this. Perhaps if AxisDJ was laying out a timeline and project plan that you felt could be achieved this would be less important but he hasn't. He's promised a lot and I'm willing to bet that most punters will expect it to be delivered yesterday.

It was that discrepancy that I wanted to highlight when I said that you do not represent the lifeline they're looking for. You've certainly expressed an interest in some project. However, the qualifications (and I believe they're sensible ones) that you've offered in both this and the "VB7" thread lead me to stand by my original statement: You have not expressed an interest in undertaking this project (by which I mean the one that AxisDJ is actually offering). You've actually set out quite clearly what it is that you intend to produce, but it isn't what it's currently being sold as.

[axisdj]

You guys are making me feel like a politician...

I can change the 99% to what is more comfortable for everyone, but I really do not know how we will have a sure answer unless we actually do it.

Remember that vbRichClient is only one of the options here... I really think that is the way to go, but if the funds do arrive and I talk to Olaf and he tells me that he can't / won't do it that is fine. We will look at other options. If all options are not feasible all the money will be returned to the original contributors.

The only way a viable vb6 project will come to pass is if money is involved, one way or another. Time has shown us that no other options have worked.

This project is a huge risk.. but I am driven to give it a chance, If I/we fail, I'm ok with it, at least I tried. Too many people live with the fear of failing and never accomplish the things they could.

So Funky, your fear that I am over promising happens with every r&d project that has ever come to pass, and unless the goal is set, which I was brave enough to do, it will never come to pass.

WP

[Niya]

Which is a pity as he is obviously knowledgeable but seems to delight in being the VB6 voice to bash .Net in his eyes to counter all the VB6 bashing form .Netters (his word not mine)

Saying that VB.Net is better is not bashing VB6. This is what the VB6 camp doesn't get that and always take offense to it.

Olaf's comment about needing deterministic object disposal makes sense. That reason is the most sensible justification for choosing VB6 over VB.Net. He does a lot of low level stuff which is a lot easier to manage when you have a lot of deterministic behavior. Even so, it makes me wonder why he just doesn't use C++, which I believe outshine all flavors of VB in every way except RAD(Rapid Application Development). C++ gives you complete control over object disposal. C++ is also far better at authoring COM classes.

Anyways, most people aren't authoring stuff like Cairo wrappers or creating frameworks like vbRichClient. Most people want to write apps, whether its a POS application, a file downloader, a file manager, some kind of Windows service, whatever. VB.Net can do these things a whole lot better. Not to mention you can create and even consume web services very very easily. You can rig up something to use a web service in less than a minute using VB.Net. Trying doing that in VB6. Console applications ? Powershell applications ? Windows services ? Can VB6 author these things easily ?

Hell VB.Net can even write games:-






The above game is called Bloodmasters and its written in C#. Given that C# and VB.Net are interchangeable, it means that VB.Net can author it as well. Also, the person that wrote that was a VB6 programmer too and a very very good one(I learned how to use GDI from watching his source code). He wasted no time in jumping ship when .Net had reasonably matured and I'm pretty sure he didn't cry and complain when MS ended support for VB6. He's like 40% of the reason I left VB6 for VB.Net.

He also wrote this:-


Thought I can't find the source code for this, its entirely possible he wrote this in C# too. He codes in C++ as well so it could have been written in that, I'm not sure.

Though this may not seem relevant to this discussion, I remind you, he was also a VB6 programmer, one of the best I've ever seen. His knowledge and skill with VB6 is on par with Tanner_H, Olaf and dilettante and he didn't hesitate to start coding in C# when VB6 was long in the tooth. Take that as an endorsement if you like. Like I said, he was almost half the reason I was able to give .Net a chance. I was still being stubborn about it at the time.

[dilettante]

Better is in the eye of the beholder though.

There is no question that .Net languages suffer just like Java and other p-code/bytecode or scripting languages from easy decompilation and reverse engineering even when obfuscated. That's an issue for some and less of an issue for most programmers.

There is also the performance hit and erratic operation you risk from languages that are a mix of interpreted and JITted code at runtime, along with the hit you take for non-deterministic garbage collection schemes.

Then you have the "broken interpreter" issue. .Net's in particular is subject to breaking, and in later versions of Windows several of these come preinstalled. This makes them non-repairable, forcing a user to reinstall Windows to make your programs ever work again.

VB6 remains immune to all of these issues. Nothing says its runtime can't break too, but I have never heard a case of it just happening without a discernable reason. .Net on the other hand seems to be able to break for reasons nobody has ever tracked down.

How to repair the .NET Framework 2.0 and 3.0 on Windows Vista describes the limited things you can try that might repair it in some cases, but ends up punting and telling people to reinstall Windows. As noted there the problem extends to Windows 7, but it also occurs in Win8 and Win8.1 and will probably rear its head just as often in Win10.

[Niya]

I've been using .Net for quite a while now and I've never seen it break. I even have apps running on a wide variety of Windows flavors and the only problems I experience come from my own program's bugs.

My VB6 apps on the other hand, are breaking left and right. I don't even bother to try and fix them anymore. I just replace them with a .Net version and all my troubles go away. I would really like to know what alternate reality you're living in dilettante.

[Niya]

There is also the performance hit and erratic operation you risk from languages that are a mix of interpreted and JITted code at runtime.

This is what I was talking about when I said the VB6 camp make misleading claims. There is NEVER any kind of interpretation by the CLR. All executing code is native code compiled by the JIT. Can you cite a source for your claim ?

[Schmidt]

Saying that VB.Net is better is not bashing VB6.

I can certainly do quite some things in VB6, which you will have a real hard time to replicate in .NET.
I don't say though, that "VB6 is therefore better than VB.NET".

On the other hand, one can certainly do (a few) things, where one needs less efforts in .NET than in VB6.
Is it therefore "better" than VB6?
Big fat NO - (just applying the same logic or "rule" from above).

It's just different (with a different set of helper-libs or -classes, stuff you have to learn to accomplish things efficiently).

Most people want to write apps, whether its a POS application, a file downloader, a file manager, some kind of Windows service, whatever. VB.Net can do these things a whole lot better.

POS-applications:
- Bread and Butter-stuff for both RAD-tools

a "File-Downloader":
- are you serious? (seems you never used the AsyncDownload-capabilities of a VB6-Usercontrol)

a "file manager":
- no clue what you mean - the umpteenths reincarnation of a "Norton-Commander-Clone" or something?

some kind of Windows-Service
- wrote and maintain a lot of them (for over a decade now using two drop-in *.bas modules from Sergey Merzlykin)
..(for those who can live with a COM-dependency, there's an OCX from MS for that)

you can create and even consume web services very very easily.
- can do that too - and not even touching the "dying" SOAP-protocol
..(recent example: authenticated JSON-based access to the Bitfinex-WebAPI, in case you watched the VB6-forum the last days)

can rig up something to use a web service in less than a minute using VB.Net.
- well I needed two <g> - a small Nwind-DB-SQL-Requester is now available on vbRichClient.com
- in case you want to try it out (needs only a default-named MSHFlexGrid1 on a VB-Form, then click the Form

Option Explicit

Private Sub Form_Click()
  On Error GoTo 1
    Set MSHFlexGrid1.DataSource = PerformNwindRequest("Select * From Customers")
1 If Err Then MsgBox Err.Description
End Sub

Function PerformNwindRequest(SQL As String) As Object
    Dim Req As Object, B() As Byte
    Set Req = CreateObject("Winhttp.WinHttpRequest.5.1")
        Req.Open "POST", "http://vbRichClient.com/asp/ADODBTest.asp", False
        Req.SetRequestHeader "Content-Type", "application/json"
        Req.Send "{""DBName"": ""/data/NWind.mdb"", ""SQL"": """ & SQL & """}"
    B = Req.ResponseBody
    If B(0) = 123 Then Err.Raise vbObjectError, , StrConv(B, vbUnicode)
    Set PerformNwindRequest = GetRsFromByteContent(B)
End Function

Function GetRsFromByteContent(Data) As Object
   Dim Stream As Object
   Set Stream = CreateObject("ADODB.Stream")
       Stream.Type = 1 '<- 1 = adTypeBinary
       Stream.Open
       Stream.Write Data
       Stream.Position = 0
   Set GetRsFromByteContent = CreateObject("ADODB.Recordset")
       GetRsFromByteContent.Open Stream
End Function

Console applications
possible (there's classes for it, but please bring an example, what you use this for)

Powershell applications
- not sure what you mean with a "PowerShell-Application" (perhaps .NET-code, triggered by it)
- but it's equally easy to run (native compiled) VB6-code from the Powershell-Prompt

VB.Net can even write games:-
- sure - and here I thought it's developers who write them...
- and no, especially in that area, there's always "frameworks you work with"
- for VB6 that would be e.g. DirectX-9 on current systems for 3D-stuff (or e.g. vbRichClient+PhysicsEngine for 2D-stuff)

It's really tiring what you do here, but I thought a short "busting of all the wrong claims you made" was needed.

Since you seem so fond of games, maybe try a really tiny example
(only about 150 lines of code in total, across 3 classes, a module and a form, clear code)
http://www.vbforums.com/showthread.p...or-Starters%29

Try re-implement that in .NET (I mean, it's really just a small Demo, not a full game),
then come back and show us your .NET result.

In case you have a small example too (100-200 lines of code total), I'd try my best to
present you with a VB6-solution in return.

Fair enough?

Olaf

[Tanner_H]

Console applications ? Powershell applications ? Windows services ? Can VB6 author these things easily ?

You can't take a few small use-cases and use them to judge an entire language. That's like me saying, "I write portable software, and .NET can't do it, therefore it unilaterally sucks."

None of us are saying VB6 is better at everything. What we're saying is that there are situations where it's competitive with .NET, and maybe even a few (very limited) situations where it's better.

Obviously, .NET has tons of situations where it's a better choice, too. Some of us even use VB6 AND .Net (GASP!), sometimes even on the same project (GASP!). Sometimes that's a better solution than doggedly sticking to one or the other.

Hell VB.Net can even write games:-

The above game is called Bloodmasters and its written in C#. Given that C# and VB.Net are interchangeable, it means that VB.Net can author it as well.

This is as ridiculous as some of the worst VB6 defenses in this thread.

No, C# and VB.Net are *not* interchangeable. C# has way more third-party libraries, way more source code samples, a much larger development community, and a number of features VB.Net lacks.

I don't know if that singular project makes use of any of those, but you can't hold up C# projects as a defense of VB.Net.

Also, the person that wrote that was a VB6 programmer too and a very very good one(I learned how to use GDI from watching his source code). He wasted no time in jumping ship when .Net had reasonably matured and I'm pretty sure he didn't cry and complain when MS ended support for VB6.

Though this may not seem relevant to this discussion, I remind you, he was also a VB6 programmer, one of the best I've ever seen. His knowledge and skill with VB6 is on par with Tanner_H, Olaf and dilettante and he didn't hesitate to start coding in C# when VB6 was long in the tooth. Take that as an endorsement if you like. Like I said, he was almost half the reason I was able to give .Net a chance. I was still being stubborn about it at the time.

Don't go down this road, please. There's no point cherry-picking individuals in either community, and using them as a benchmark for the community as a whole.

Lots of C++ developers have jumped ship to C# and Java. That doesn't mean C++ has zero use-cases.

Part of the reason I working on a VB6 photo editor in my spare time is to make the point that everything the C# poster child in that arena does, I can do in VB6, too. This isn't because VB6 is magical (I could probably do any ancient language, if I hated myself enough to try), but because a lot of modern developers write slow, sloppy code, and just rely on modern compilers to clean it up for them.

I think the constraints of an older language are awesome for promoting thinking outside the box. Prototyping with VB6 keeps my mind fresh, and forces me to think about writing the absolute best single-threaded code I can. I really identify with guys like John Carmack, who often speaks of the frustration with rapid hardware improvements, because it's resulted in a generation of developers who don't know anything about code optimization outside of clicking a box in their IDE that says "magically make my code faster".

Again, none of this is to say that VB6 is somehow the pinnacle of code creation. But I think a lot of developers would find it worthwhile to play with an older language every now and again - VB6 or otherwise - to not just help them appreciate the niceties of modern development, but also to force themselves to write better code with those tools.

[Tanner_H]

This is what I was talking about when I said the VB6 camp make misleading claims. There is NEVER any kind of interpretation by the CLR. All executing code is native code compiled by the JIT. Can you cite a source for your claim ?

Er, based on this and previous posts, I think you have confusion about how the CLR works. The CIL Wiki page is a great place to start.

To quote:

"Languages which target a CLI-compatible runtime environment compile to CIL, which is assembled into an object code that has a bytecode-style format. CIL is an object-oriented assembly language, and is entirely stack-based. Its bytecode is translated into native code or — most commonly — executed by a virtual machine.

...During compilation of CLI programming languages, the source code is translated into CIL code rather than into platform- or processor-specific object code. CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the Common Language Infrastructure,[3] such as the .NET runtime on Windows, or the cross-platform Mono runtime."

And from the link Olaf already provided:

The Common Language Runtime (CLR), the virtual machine component of Microsoft's .NET framework, manages the execution of .NET programs. A process known as just-in-time compilation converts compiled code into machine instructions which the computer's CPU then executes.[1] The CLR provides additional services including memory management, type safety, exception handling, garbage collection, security and thread management. All programs written for the .NET framework, regardless of programming language, are executed by the CLR.

None of this is bad, but it does bring a performance hit. (If it didn't, Microsoft wouldn't write whole articles about the performance benefits of .NET Native, would they?) Whether that performance hit is meaningful is totally dependent on the project, but the CLR most definitely performs interpretive tasks.