No troll. What are the (legitimate) reasons people are still using VB6 ?

I professionally used VB6 in around 1998.
I kept using it as a hobbyist into the early 2000s.

This forum is very active.
I'm very curious who is still coding with VB6 .....20 years later.
Novelty or production programming fixes?

Most places I worked for were obsessed with rewriting the code base.
Are you guys working for firms that are the opposite?
They refuse to budget for a rewrite, and your supporting 20 year old code?

Quote:

---

Originally Posted by RipVoidWinkle

I professionally used VB6 in around 1998.
I kept using it as a hobbyist into the early 2000s.

This forum is very active.
I'm very curious who is still coding with VB6 .....20 years later.
Novelty or production programming fixes?

Most places I worked for were obsessed with rewriting the code base.
Are you guys working for firms that are the opposite?
They refuse to budget for a rewrite, and your supporting 20 year old code?

---

I guess the answer is because we are professional and career programmers and not casual programmers.
To be professional in the sense I'm saying takes many years (let's say 10 or more) with a single language.

And about the focus of you question, I suspect that here we are mainly independant developers or developers working in small companies.
The big companies, I guess mostly already migrated to some other language. For them it is just a matter of some numbers (spending some money).

But we, as developers can't "migrate" 10 or 20 years of knowdge in a couple of months. We would lose our capital that is our knoledge.
And on other hand, VB6 works just fine, there are not unsolvable problems that could force us to move to something else.

Edit: and also because we like VB6 and there is nothing similar to replace it.

here are my reasons:

1. I can accomplishing everything in VB6 needed to stay competitive with my software products
2. I have met with many consultants on making the move from vb6, many have cautioned me that they have seen companies fail because they underestimate the work required for a conversion
3. The extra layer that .net creates slows performance, and makes de-compiling easier ( mention this becuase it would be the fastest port from vb6)
4. I am the only dev, I just dont have time if I continue to work on my current projects to keep them competitive
5. I am extremely effective in vb6, as soon as I move to another language/ide the my performance is so slow and it becomes very discouraging


Having said all that I am continuously looking for an way to evolve mainly for the reason of cross-platform options.

1. COM/ActiveX-oriented language;
2. High RADness;
3. Code-edition at runtime;
4. Native-compiler.

I am much more familiar with VB6. It can do most of the things I need to do and I can do most of them faster in VB6 than in other languages, partly because of the language itself and partly because I already know exactly how to do it in VB6. I do use other languages as well but have been using VB5/6 since the release of VB5 and still use it more than any other language.

Quote:

---

Originally Posted by RipVoidWinkle

They refuse to budget for a rewrite, and your supporting 20 year old code?

---

That's certainly a big part of the reason I still use it. Many of the other things mentioned are also sound reasons. The only distant limitation is the 2Gig (possibly 4Gig) memory limitation. However, that has never affected me in any significant way, and my primary project is very large.

Also, something else I didn't see mentioned is its ability to just execute (no installation needed) on any Windows system since XP. And, even with OCX controls, the SxS technology works quite well. As opposed to the 16 (count them, 16) .NET frameworks, VB6 is an incredibly stable language.

Actually VB.Net apps are more likely to be just execute than are VB6 apps.
Most of the apps I have written in VB.Net did not require an installer. VB6 apps usually do due to usage of one or more OCX controls that need to be installed with the app. Lots of my VB6 apps make use of Winsock and/or MSComm. The apps in VB.Net do not need an installer.

im using it because i like it, the best language i know and even if its old, it can do almost anything other languages can do, in windows of course.
because of the typelibs i can now work with direct2d (thanks for The trick) and doing 60fps games that runs smoothly.
im not working with computers or gaining money from it. i like doing it on my spare time.

Microsoft never launched an upgrade to VB6. We wanted and expected one. Had they done so we would have moved to a VB7 and whatever followed it.
If Microsoft bring out an update to VB6 now, we would move to it.

Asking why people are still using VB6 is the wrong question. You should be asking why Microsoft refuse to update VB6.

There seems to be an assumption that people who write and maintain VB6 programs do not use anything else. While that might be true of a few hobbyists it certainly isn't all programmers.


VB6 has a number of things going for it that help keep it as popular as it is. One of the most valuable and unique things is the long-term stability that falls out of its "at the end of its family tree" status.

As long as you followed the rules of the road many VB6 programs written 20 years ago will still run without changes. If you take the trouble to make minor changes to comply with the evolving Windows ecosystem since then... even more VB6 programs can be made to run today at a very low cost.

Many of the changes that can be expensive to adapt to in VB6 like High DPI aren't much easier using most of the alternative languages and language ecosystems you might port to instead.


You can always name kinds of problems that VB6 was never targeted at. Sure, it can be hard to use VB6 for those. So what?

You can find people demanding "an updated VB6" who don't understand they'd be in far worse shape if that had ever occurred. Just ignore them. Soon they'll move on to a new hula hoop anyway, then come back here and ask us why everyone hasn't followed them.

Most of the programs I write are utility programs that I build for myself and anyone else that is interested. I tend to shy away from heavily graphic oriented programs because they are too time consuming. I started with machine code on early Accounting machines, moved to Fortran and Basic on mainframe computers, then moved to Assembler and Basic on early desktops. From there I moved to Visual Basic on PC's. Early versions of Visual Basic were very challenging in order to do the things that needed to get done, but gradually the versions improved to the point where VB6 was fast and easy to put programs together. I have taken a stab at "C", but that is only one step better than Assembler. VB.NET is far too slow and obese for my liking, and script based languages are far too restrictive. If someone can come up with a RAD language that produces tight compiled code, I would go for it. But until that happens, and as long as Windows remains the desktop of choice, I will stick with VB6.

J.A. Coutts

I have a few projects (two of them are large projects) which I need to maintain!
VB6 just works!

I am using other languages but not as heavy as VB6.

[...]

Here's a "no troll" question in the other direction:

What are the (legitimate) reasons I should NOT still be using VB6?

I'm working on a large VB6 code base that still pays the bills 20 years on. I've extended it into the 21st century and the Web, while taking advantage of most of my existing code base thanks to projects like vbRichClient5 and vbFcgi. While I'm not 100% coding in VB6, it's still quick and effective use my existing knowledge and 20 years of battle-tested "helper" libraries to continue to develop new software in VB6. So the better question is "why not?"

Even Microsoft haven't really moved away from classic VB.

VB6 is still supported https://docs.microsoft.com/en-us/pre...support-policy and Microsoft have recently extended that support to include Windows Server 2019

And VB6's sister language VBA is still used in Microsoft Office despite several attempts to replace it.

Thanks for the replies.

I can understand not wanting to migrate a massive legacy VB6 code base to newer versions of VB.
This could become very complex, time consuming, costly, and can result in errors.
Not a good cost/benefit for little upside from the user standpoint.
If it ain't broke, don't fix it!

But, who are the users of your apps? In-house business use? Customers of packaged software?
How do you release updates? Do you have them download a new setup.EXE ?
This seems somewhat outdated. Everything has gone web enabled. And Windows versions have moved on.
Maybe your legacy programs do not have frequent updates?

Are you still developing on Win 98 or Win XP developer machines?
However, I am surprised VB6 stuff still works on Win 8 and Win10.
Not the client side .EXE, but the VB6 IDE dev.

It has been many years ago, but I was forced to upgrade away from VB6 b/c I ran into compatibility issues on Win 8.
Either my programs did not run, or the VB6 IDE simply did not run. I can't recall. But, VB6 would not work anymore.
Maybe I lost the installation file? Whatever it was, I was no longer able to run VB6 programs at work. Either the VB6 did not work, or the apps did not work.
Otherwise, I would have stuck with VB6 myself. But I was forced to migrate, b/c stuff stopped working on newer PCs.
I've moved my projects up to VB.net 2005, 2008, 2010, 2013, 2015, 2017, and now VB.net Community.
For one or two migration, I had to make some code edits, but mostly, it was just opening the same code in the newer version and re-saving it.
So, I edited my projects (about a dozen or so, and they were small) and I have been using VB.NET ever since.

As for upside, I imagine there are probably many new features to VB.NET 2018.
The reasons for staying with VB6 b/c it's fast and easy all apply to the 2018 VB.NET.
It can do anything VB6 can do, as it is basically still the same thing, 20 years later.

Quote:

---

Originally Posted by RipVoidWinkle

As for upside, I imagine there are probably many new features to VB.NET 2018.
The reasons for staying with VB6 b/c it's fast and easy all apply to the 2018 VB.NET.

---

I can only give you the standard-response, we always give at this occasion:

Please write a small application, which makes use of "a few of these cool new VB.NET-2018 features, VB6 allegedly does not have".
Then post this VB.NET 2018 solution (in a Zip or on your homepage, or whatever you had in mind regarding "Web-Enabled" solution...)

Many of us here should be able to replicate what you did in your solution, with VB6:
- in probably less time
- and probably less code
- and probably better load-times and/or execution-speed
- the VB6-solution then running (without needing a setup) on W2K, XP, Vista, Win7, Win8, Win10 (which would not be true for your VB.NET solution)

<shrug>
Hint: ... most of the .NET-users who made claims similar to yours (as cited above), bail out at this point -
and I suspect that we'll see you doing the same...

In other words - "don't make wild claims which you cannot back up with code".

Olaf

Just because someone does not write an app for you to look at does not mean the points are invalid. I have written numerous apps in VB.Net that can not be done in VB6 which is largely the reason I used VB.Net to do them. Of course I am not going to take the time to create one just to prove a point you can believe it or not but it is a fact. VB6 can do a lot for sure and it is possible to create apps that can run without install though some of them require a lot more time and code to do so. To date I have not had a case where I needed to create an installer for a VB.Net program, this is partly because I am using an older version and the required framework is already present on pretty much all target devices. One of the things I do a lot of is TCP. In VB6 I use the winsock control and need to create an installer. In VB.Net I use the sockets class and do not need to create an installer. Of course it is possible to get around the winsock control but writing code to use the dll instead but the winsock control is quick, easy and works well and I really do not mind creating an installer I generally do so for every project whether it needs it or not.

As to the part in post #16 mentioning troubles with Windows 7 and VB6 there really is not a problem. There are a few things to be aware of. The desktop composition if on causes some issues in the IDE so it should be turned off when VB6 is running, that is an option on the shortcut. The IDE needs to be ran elevated. If both of these are true it works just fine. As for the apps created in VB6 the only issue I have saw is apps where they make use of app.path for files that need to be written to. On Vista and later program files is read only and the program will fail if it is trying to write to this directory tree. As long as you obey the rules the resulting exes work just fine up through the latest version of Windows.

I am currently using a Windows 7 box for most of my development and Windows 10 for some. Have not experienced any issues other than the initial install process.

Does anyone here use VB6 on Win8 or Win10 ?
What version of Windows does VB6 no longer work with?

Now I remember why I was forced to upgrade from VB6
I could not install VB6 anymore on Win8 machine.
All machines at work went to Win8. Game over for VB6.
Almost positive that was the reason.

So, I moved to VB 2005 and had to make a few code tweaks.
Everything in VB.NET is OOP.
Once I did that, I just kept migrating to 2008 –> 2010 –> 2013 –>2015 –>2017
which was a matter of Open/Save in each new version.

I get the whole “it works for my needs, leave it”
but am glad I don't have to jump through hoops to keep using a 20 year old IDE.
For example, like not being able to run anything past Win7, which is now a 9 year old OS.

Quote:

---

Originally Posted by DataMiser

Just because someone does not write an app for you to look at does not mean the points are invalid.

---

Well, to be precise - it also does not mean, that the points were valid ones (unless there is proof).

Quote:

---

Originally Posted by DataMiser

I have written numerous apps in VB.Net that can not be done in VB6 ...

---

Again - I don't believe that your claim is true (because - so far - I've never seen a VB.NET App which could not be done in VB6 as well).

So, if no proof is forthcoming, the problem remains at the usual "your word against mine" - state.

Note, that I did not claim, that one cannot replicate the same functionality of a VB6-App also in VB.NET.
(so, it's not me, who has to provide proof - for a claim that was never made).

So, "until further notice" (to be on the safe side) one should assume, that your claim was bogus (because evidence to the contrary does not exist).
It really is that easy (with the "show code" thingy).

As for "having to make a setup" (when a VB6-App is using the Winsock.ocx) -
that's just another one of your assumptions, where you make a claim which does not hold up to reality.

Olaf

It's not just a matter of VB6 vs. .NET
Aren't you are stuck using an outdated OS in order to run VB6 ?
That is why I migrated.

What if you want to use some feature of Win8?
Like using WiDi to project your screen to a Wifi projector?
Are you going to be the dinosaur using a 50 foot VGA cable in 2018 ?

How do you convince your employer that you must stick to Win 7?
Do they keep old Win7 images Ghost just for your build?

I guess it all sorts naturally.
Anyone who has run into these issues will have migrated.
Anyone who is still left on VB6 has not run into a use case problem.
What is most likely reflects is that the person using VB6 in 2018 is basically living in a time capsule
and is doing the exact same work for the last 20 years, in a time capsule environment.
Nothing wrong with that!

Quote:

---

I have written numerous apps in VB.Net that can not be done in VB6 which is largely the reason I used VB.Net to do them. Of course I am not going to take the time to create one just to prove a point you can believe it or not but it is a fact.

---

Rephrase you. Just because you can't do it doesn't mean the points are valid.

Quote:

---

As for the apps created in VB6 the only issue I have saw is apps where they make use of app.path for files that need to be written to.

---

Don't other non-VB6 apps have the same problem?

I think one should use the instrument which fits the task. I consider nobody selects VB.NET (that's impossible) or VB6 to write a kernel-mode driver for practical usage, the most of us select C/C++. Few of us select VB.NET/VB6 to write a VST plugin, most of us will use C/C++. I wrote the points i like that tool nor VB.NET nor others have all of them.

Quote:

---

Originally Posted by RipVoidWinkle

Are you still developing on Win 98...

---

Quote:

---

Originally Posted by RipVoidWinkle

Does anyone here use VB6 on Win8 or Win10 ?

---

Quote:

---

Originally Posted by RipVoidWinkle

but am glad I don't have to jump through hoops to keep using a 20 year old IDE.

---

Quote:

---

Originally Posted by RipVoidWinkle

For example, like not being able to run anything past Win7, which is now a 9 year old OS.

---

It is hard to believe that you are not trolling, but if you say so...

Vb6 !

I would say there are two possibilies.

1. trolling

2. RipVoidWinkle your projects are extremely small and for internal use only

WP

Quote:

---

Originally Posted by Eduardo-

It is hard to believe that you are not trolling, but if you say so...

---

You can call me a troll, or you can actually answer which OS you are running?
Question is still open. What version of Windows did VB6 stop working with ?
I think it was Win 8. Does that mean everyone here is running Win 7 at work ?
Real question. How does the IT dept allow for that ? Security issues, deployment issues, etc.

Yes, my projects are small and I made it clear that I understand the complexity of migrating legacy code.
For me, it came down to having to use Win8 at work, so I had to move to VB 2005 many years ago.

But, if you think VB6 can do everything .NET can ....you are missing the OOP paradigm.

Quote:

---

Originally Posted by RipVoidWinkle

You can call me a troll, or you can actually answer which OS you are running?
Question is still open. What version of Windows did VB6 stop working with ?
I think it was Win 8. Does that mean everyone here is running Win 7 at work ?
Real question. How does the IT dept allow for that ? Security issues, deployment issues, etc.

---

Windows 3.11 for WorkGroup

Quote:

---

Originally Posted by RipVoidWinkle

You can call me a troll, or you can actually answer which OS you are running?
Question is still open. What version of Windows did VB6 stop working with ?
I think it was Win 8. Does that mean everyone here is running Win 7 at work ?
Real question. How does the IT dept allow for that ? Security issues, deployment issues, etc.

---

I use VB6 with XP or Win7, alot of people here also use VB6 with Win 8 or 10

The chances that this would not turn into a troll thread were pretty nearly zero right from the start. I don't think anybody should be too surprised to see this turn into more emotion than anything else. After all, as Olaf alluded to, as long as you have a sufficiently capable language, there is pretty much nothing that can't be written in one if it can be written in another. Any mainstream language is sufficiently capable that it is possible for a person to say, "If I can't do it in this language, then I won't do it at all." Essentially, even if there IS something that you can't do in that language, there are so many other things you CAN do that you can spend an entire career without ever venturing into that small set that you can't do. That means that any sufficiently capable language is a good enough choice for a career, and that's ultimately all that matters. Beyond that, people get emotional attachments. I feel that such attachments are good, but only if they are not too strong. After all, it's just a language.

One of the points about VB6 is that it isn't changing. If you knew it in 98, it's still the same today. That can be powerfully useful. The .NET language is pretty nearly slowing it's rate of change, too. I don't feel that much truly useful has been added since 4.0 (VS2010), but a whole lot HAS been added, so if a person really likes one of those new features....that's up to them. I guess I could pretty much say that all the way back to 2.0, but I'll stick with 4.0. That may all be changing, now. Every modern browser will run WASM, and there is now a tool to write .NET for that. I'm not sure how I feel about that, at this point. While I like the idea of a far more functional web, it also muddies the water in some ways.

That's my ultimate point: VB6 is what it is. If you love it, that's great, cause it is likely to stay as it is for a pretty long time. If you have a current career, and are middle aged, you may well make it to retirement before that particular rug gets pulled out from under you. However, it also isn't changing, and the world is. There's a comfort in that...and a cost. There will probably never be a WASM compiler for VB6, as there already is for .NET. Does that matter? Well.....that's the problem with change, you just never quite know....

Quote:

---

Originally Posted by RipVoidWinkle

It's not just a matter of VB6 vs. .NET
Aren't you are stuck using an outdated OS in order to run VB6 ?

---

No - most of the professional VB6-users of this forum (who are developing and maintaining VB6 Apps to this day "at work"),
are using the VB6-IDE directly on a Win10-OS.

Did you not read the replies, which already told you that?

And (as already mentioned too in this thread) - the compiled VB6-Apps one deploys, are working on Win10 as well
(without any Setup, as true portable Apps, when one is using the appropriate regfree-instantiation-techniques).

Quote:

---

Originally Posted by RipVoidWinkle

Anyone who is still left on VB6 has not run into a use case problem.

---

That might be due to the fact, that MS is still officially supporting the VB6-Runtime even on their latest Desktop- and Server-OSes
(Win10 and Windows-Server 2019).

Quote:

---

Originally Posted by RipVoidWinkle

What is most likely reflects is that the person using VB6 in 2018 is basically living in a time capsule
and is doing the exact same work for the last 20 years, in a time capsule environment.

---

Hmm - for "not trolling" - that reply of yours comes pretty close IMO.

As already said - you are "bailing out" - not providing us with any examples of "your modern work in VB.NET 2018" -
(which would put us - who allegedly "live in a time-capsule" - to shame).

Until you do so, your claim is to be dismissed as "just another wrong assumption from somebody who does not know enough (yet)".

Olaf

My project on Win10 in IDE:
https://i.ibb.co/WDRpgkZ/trickcomposer-dev.png

Quote:

---

What if you want to use some feature of Win8?

---

What if you want to use some feature of Win8 in pure-C?

Quote:

---

Originally Posted by RipVoidWinkle

You can call me a troll, or you can actually answer which OS you are running?
Question is still open. What version of Windows did VB6 stop working with ?
I think it was Win 8. Does that mean everyone here is running Win 7 at work ?
Real question. How does the IT dept allow for that ? Security issues, deployment issues, etc.

---

VB6 works fine on Windows 10, just as it did on all versions back to Windows 95.
So you have to go back to, as Eduardo says, Windows 3.11 to find a version of Windows that VB6 doesn't run on.

That applies to both VB6 applications and the VB6 IDE.

https://docs.microsoft.com/en-gb/pre...support-policy

Quote:

---

Originally Posted by Schmidt

As already said - you are "bailing out" - not providing us with any examples of "your modern work in VB.NET 2018" -
(which would put us - who allegedly "live in a time-capsule" - to shame).

---

Every one of my .NET projects is OOP.
It is a paradigm that can not be done in VB6.

Quote:

---

Originally Posted by RipVoidWinkle

Vb6 !

---

You changed your post where you agreed to play :)

You posted a small program which draws 1000 circles dynamically in random positions on the screen and it was lengthy compared to whatever VB6 equivalent and performance was poor too according to the video/animated GIF you posted along with the VB.NET code snippet!

I was going to post a VB6 (Native VB6 and another one with one API) but never mind :)

I had to stop using VB6 for some reason and I can't recall anymore.
Otherwise, I probably would not have bothered upgrading from VB6.

If VB6 can run on Win8 and Win10, then the OS was not it.

I wish I could remember the roadblock I had
Maybe I lost the VB6 installation disks? Or the license key?

Something made me realize, screw it, I will just move up to Visual Basic Express 2005.
Since 2005 had a migration tool. I had to clean up some of the weird translation migration.
After that, I was able to Open/Save in 2008 and 2010.
Then I was current, and I never looked back.

I do agree the stuff I do can also be coded in VB6.
But, I vastly prefer the modern IDE and OOP.

Yea, that was not a good example.
I tried to think of what aspects of the code I had to migrate to .NET.
The graphics was one, but was simple enough to also be done in VB6.
Mostly it was compliance to OOP that had to be corrected. Forget the details.
Once I moved to 2005, I never had to tweak again.

RipVoidWinkle:

in my opinion

if you are still a committed disciple of academia based OOP then you will one day realize you may have been wrong.

https://medium.com/@cscalfani/goodby...g-a59cda4c0e53

Object composition or interfaces can be used instead of inheritance and results in easier to understand code.

Even without inheritance, this does not limit functionality on any front.


WP

Quote:

---

Originally Posted by RipVoidWinkle

Yea, that was not a good example.
I tried to think of what aspects of the code I had to migrate to .NET.
The graphics was one, but was simple enough to also be done in VB6.
Mostly it was compliance to OOP that had to be corrected. Forget the details.
Once I moved to 2005, I never had to tweak again.

---

No problem.

Quote:

---

Originally Posted by RipVoidWinkle

Every one of my .NET projects is OOP.

---

So, you do have some of those "modern projects" available on disk - ready to just zip-up and post here, do you?

Quote:

---

Originally Posted by RipVoidWinkle

It is a paradigm that can not be done in VB6.

---

You err again in that assumption - nearly all OOP-patterns can be done also in VB6
(including inheritance, if you use typelibs in conjunction with lightweight COM-objects).

Again - post code for a great VB.NET Demo-App, which shows us the advantages of OOP (as you understand it) to the full extent.

Olaf

Quote:

---

Originally Posted by RipVoidWinkle

Yes, my projects are small and I made it clear that I understand the complexity of migrating legacy code.
For me, it came down to having to use Win8 at work, so I had to move to VB 2005 many years ago.

But, if you think VB6 can do everything .NET can ....you are missing the OOP paradigm.

---

I'm not really sure you know what that means in this context. No offense. You had thought that VB6 didn't run on newer OS. This is absolutely false. You simply didn't uncheck the additional options during setup, and that caused installation to fail, for you.

Expert programmers will be utilizing the most efficient tool to do the job, whether that is VB6 or VB.NET. There is no room to polarize one way or the other, when efficiency for the individual is the dominant factor.

VB6 is an underutilized OOP language, however there may be web related features in vb.net that supercede VB6's web features.

In fact, there are things that VB6 can do that VB.NET cannot do, ever. For example, when making an unattended OS CD a VB6 application will "just work" early before the .NET framework has had a chance to install. In general over time, VB6 has been more robust with a close relationship to VBA and VBscript. This direct relationship with VBA and Office is another reason why VB6 will not die anytime soon.

Speed is also a factor that VB.NET cannot duplicate, and as it turns out this can cause security issues in the application if designed in VB.NET, while the same application designed in VB6 does not have the same delay issues that cause this type of vulnerability.

My main concerns with .NET languages are:
- Poor performance (Although they claim that JIT (Just In Time) compiler is much better now and rivals native compilation!!!)
- Decomplie to the source is a breeze even when using the most sophisticated obfuscation tool.

One feature of VB.NET that I like is the entire Collections class. Lists and Dictionaries, for example.
Sure one mimic that functionality by redimming multiple arrays or whatever, but that's just messy, even if it works.

One can also ride to work on a unicycle, that does not mean it is a preferred method.

The implementation inheritance isn't used in COM (and VB6 too). COM provides the other methods of code reusing. You can use containment/delegation from "out-of-box". The aggregation is implicitly used in the UserControls but you can implement it using the Lightweight-objects (as Olaf mentioned).

Let's see to C. It has no OOP at all but Windows and Linux kernels is written on C and they are object-based kernels, work and are supported/improvemented without the problems.

I don't think there is a true advantage to one over the other. I prefer OOP as it is found in .NET (I agree there can be other flavors, and even VB6 has an optional flavor), and it sounds like the OP does, as well. That's just how it is. I've met people who can't understand OOP, or take a long time to learn it, and people who take to it like a fish to water. That's just differences between people. I didn't realize anybody cared about languages until axisdj started posting about it in General Developer (MANY years ago, by now). As far as I was concerned, they were just tools with different colored handles. I might have a preference for color (blue....no, yellow!...(actually, neither one, but whenever you mention color preference...)), but not enough to really care.

However, I'd like to second what axisdj just posted. I wasn't fully into interfaces until recently. Sure, I used them, and always understood them, but I just recently came to understand how truly useful they are. However, I still have found nobody who can really articulate that usefulness, and I'm certainly one who can't. Heck, I'm so unable to articulate the value that I can't even tell whether axisdj is even talking about the same thing, though he probably is. I don't think interfaces matter for small programs, but for anything larger, every class (aside from those used ONLY inside another class) should have an interface. Where that interface should be defined is a whole different matter, though, which depends on the project.

Whether or not that really has anything to say about OO, I can't quite say. You can do effective runtime polymorphism with interfaces, though you may not gain any value from doing so. Still, OO may be the path that people use to get to interfaces, and OO has value in those small, disposable, LOB apps where interfaces don't have much value.

Quote:

---

Originally Posted by RipVoidWinkle

One feature of VB.NET that I like is the entire Collections class. Lists and Dictionaries, for example.
Sure one mimic that functionality by redimming multiple arrays or whatever, but that's just messy, even if it works.

One can also ride to work on a unicycle, that does not mean it is a preferred method.

---

I wouldn't talk about the Collections class. The key is generics.

@Olaf: If you want to try something out for comparison, write a List(of T) for VB6. People would likely LOVE it if you got that. I wouldn't put it in with anything else (in case you already have written such a thing), because people would want it without any other strings attached. Once the List(of T) was added to .NET in 2005, it probably became the most widely used addition. I doubt there are many programs much larger than Hello World that don't make use of a List(of T). Furthermore, you don't need anybody else to make the first move, cause MS already did. So, come up with a good VB6 version of List(of T), make it a stand-alone addition, and people will likely be thrilled. You can then compare the performance of your List(of T) to the one in .NET and talk up the advantages. Everybody wins.

Quote:

---

Originally Posted by Shaggy Hiker

The key is generics.

@Olaf: If you want to try something out for comparison, write a List(of T) for VB6.

---

I don't have to (write anything) - because "a List of specific Types" can be implemented and used in VB6 in dozens of different ways...:
- some with very sparse code - suitable for 95% of the cases, where performance is not of importance (because the lists are short)
- and some with very good performance - but more implementation-code (but then probably outperforming an equivalent .NET-solution).

Again - it's you who seems to be of the opinion, that a "List(of T)" is (somehow) "badly needed - and hard to do in VB6" (whereas we do know, how to implement the concept) -
so I can (again) only encourage you, to provide a practical example which makes use of it to the utmost - and then wait for the (functional identical) VB6-implementation.

See - there is one existing "big App" which does utilize the .NET-framework with "all bells and whistles" (one, which I have in daily use) -
and it's the SMS (SQLServer-Magagement-Studio) - and this App (which once was "flying" a few years ago ... at the time its implementation was still COM-based),
is now just a "daily annoyance" to me, everytime I have to start it up.

So, what I see there (in this .NET-App) is apparently "usage of List(of T's)" in abundance - and the result is very dissatisfying to me.

Guess the ball is in your field again... ;)

Olaf

Quote:

---

Originally Posted by Schmidt

I don't have to (write anything) - because "a List of specific Types" can be implemented and used in VB6 in dozens of different ways...:

---

Of course it CAN be implemented. I wasn't suggesting that it couldn't be. I was suggesting that you should create a class that works like the List(of T), where you can supply the type and get all that functionality. After all, you could write that functionality in .NET without using the List(of T), but nobody does because the List(of T) is there to be used. What I am suggesting is that you write that component for VB6.

The reason would be multiple. For one, if somebody can reference your component, then write these lines:

dim someList As New OlafsList(of Integer)
dim someOtherList As New OlafsList(of SomeOtherType)

with syntax like that, or reasonably similar, then they'd likely be quite happy with that. As it stands, doing the same kinds of things, such as Add, Insert, Remove, RemoveAt, Sort, and so on, along with efficient memory usage, then people would probably be thrilled to use it, just as the List(of T) is so ubiquitous in .NET once it was added.

Quote:

---

- some with very sparse code - suitable for 95% of the cases, where performance is not of importance (because the lists are short)

---

The length of code in the component doesn't matter. What people want to do is to be able to write it in one line, as shown.

Quote:

---

- and some with very good performance - but more implementation-code (but then probably outperforming an equivalent .NET-solution).

---

And that's the other reason, since you really care about that. Nobody is all that interested in spending the time to write some significant piece of code for the sole purpose of "creating something that can't be created in VB6". That sounds like creating "records to break record players": It's only worth doing in theory, not in practice. But you've asked for this kind of a challenge repeatedly, so create your own challenge. Here's a component that would be valuable, write your own and see how the performance compares. For example, you could write something that replicates something simple like this:

Code:

---

Dim someList As New List(of Integer)

For x = 0 To 100000
 someList.Add(x Mod 3)
Next

someList.RemoveAt(4000)

someList.Sort()

---

Then you could compare the performance between your version and the .NET version. You'd have your challenge, and nobody would have to have spent more time (aside from my time writing this, but I'm just goofing off).

Quote:

---

Again - it's you who seems to be of the opinion, that a "List(of T)" is (somehow) "badly needed - and hard to do in VB6" (whereas we do know, how to implement the concept) -
so I can (again) only encourage you, to provide a practical example which makes use of it to the utmost - and then wait for the (functional identical) VB6-implementation.

---

Why did you use the quotes? Who were you quoting? I have no idea what is "badly needed" in VB6, and I really don't know whether or not a List(of T) would be hard to do. Everything other than the "of T" part could take some significant code, but is entirely tractable. I'm not sure if the "of T" part is possible or not.

As for me supplying something....I've got enough time to write a few posts, but I can't imagine writing a useful piece of code solely to provide a challenge. I've never participated in the coding challenges on this forum. I suppose I could supply some kind of working code, but there isn't much point in writing a LOB application that is solely existing to be difficult to replicate. Most useful code is pretty simple for ANY language. When it comes to comparing performance, that's always an interesting subject, but while comparing simple things is easy, comparing non-trivial tasks is really not. For example, I wrote a genetic algorithm in both VB6 then again in VB.NET. That's not a very big thing, but it isn't trivial, and both run long enough to meaningfully measure. The programs weren't really the same, as the .NET version used classes, while the VB6 version did not. There was no noticeable difference in generation time, but the two were only similar, so I wouldn't say that it mattered.

Quote:

---

Guess the ball is in your field again... ;)

---

The ball has never been in my field. You have your challenge, you just can't get anybody else to care. You've been trying to get people to write something you can compare to for years, if I remember right. You now have that snippet of code. Write something in VB6 that does what that snippet does, compare the performance....and then try to get somebody to care. After all, I have the same objection to LINQ. It's demonstrably slower, so why do people use it? They use it because they can write one line that does what takes me six lines. Those six lines are faster, but modern computers spend most of their time waiting for us to take action, so the performance difference is technically 0 in most situations, at which point, it's hard to argue that the one line is worse than the six.

What prompted this thread anyway?

Boredom? That fading status of VB.Net? The rapidly approaching deprecation of .Net as a whole?

Quote:

---

Originally Posted by RipVoidWinkle

You can call me a troll, or you can actually answer which OS you are running?
Question is still open. What version of Windows did VB6 stop working with ?
I think it was Win 8. Does that mean everyone here is running Win 7 at work ?
Real question. How does the IT dept allow for that ? Security issues, deployment issues, etc.

---

Sorry Rip guy, this sentence just proves you don't know what you are talking about. Enough said :rolleyes:

Quote:

---

Originally Posted by Shaggy Hiker

But you've asked for this kind of a challenge repeatedly, so create your own challenge.

---

Why should I create "my own challenge" - when I did these comparisons already (years ago).
You seem to be under the impression, that I did not do thorough tests with .NET when it came out -
(or that I don't know the concept behind generics)... or that I'm a "single language guy".

It's you .NETers who seem to think, that VB6 is missing anything (other than "assured long-term-support" from the vendor).
Your mentioning of "List(of T's)" is a good example for that.

Vb6 does have support for that (if you use the right helper-lib, or the right implementation-approach).

Quote:

---

Originally Posted by Shaggy Hiker

For example, you could write something that replicates something simple like this:

Code:

---

Dim someList As New List(of Integer)

For x = 0 To 100000
 someList.Add(x Mod 3)
Next

someList.RemoveAt(4000)

someList.Sort()

---

---

Ok - finally something - and here's the VB6-version.

Code:

---

  Set someList = New_c.ArrayList(vbLong)
 
  For x = 0 To 100000
    someList.Add x Mod 3
  Next
 
  someList.Remove 4000
  someList.Sort

---

Nice, isn't it.

Quote:

---

Originally Posted by Shaggy Hiker

As for me supplying something....I've got enough time to write a few posts, but I can't imagine writing a useful piece of code solely to provide a challenge.

---

That's not my (or our) problem then - because in this case - you'll just have to let my reply to you stand as it is (without being any wiser).

Which was, that VB6 has enough stuff "on board" (or in free available helper-libs), to address all problems, your List of T's are helping to solve in .NET.

Again, it's not us who have to prove anything.
We just have to tell you, that your claims of ".NET-superiority" (in case you make them) are wrong - nothing more ...
(leaving the issue "hanging", so to say).

You want to convince us, that we are "delusional"? ... then you provide the example to underline your claim.
It really is that easy.

Olaf

Quote:

---

Originally Posted by Schmidt

Why should I create "my own challenge" - when I did these comparisons already (years ago).
You seem to be under the impression, that I did not do thorough tests with .NET when it came out -
(or that I don't know the concept behind generics)... or that I'm a "single language guy".

---

I'm under no such impression. I can't say I ever really cared. Still, why did you do thorough tests with .NET? Was that back in 2002? What were you testing for? What kinds of tests? What did you conclude from the tests? Have you looked again (a comparison prior to 2005 is...probably misleading)?

Quote:

---

It's you .NETers who seem to think, that VB6 is missing anything (other than "assured long-term-support" from the vendor).
Your mentioning of "List(of T's)" is a good example for that.

Vb6 does have support for that (if you use the right helper-lib, or the right implementation-approach).

---

Well, I certainly don't pay attention to what is in the language and what isn't. Still, since you mention it, which library adds a List(of T)? I don't really care about other generics, as they are so infrequently used.

Quote:

---

Ok - finally something - and here's the VB6-version.

Code:

---

  Set someList = New_c.ArrayList(vbLong)
 
  For x = 0 To 100000
    someList.Add x Mod 3
  Next
 
  someList.Remove 4000
  someList.Sort

---

Nice, isn't it.

---

What is c, in that code? There were ArrayLists in early .NET. They are still around, they just shouldn't be used. I don't remember them being in VB6, but then again, you appear to be using something different. I can't really look it up, as it stands, without knowing what c is.

Quote:

---

You want to convince us, that we are "delusional"? ... then you provide the example to underline your claim.
It really is that easy.

Olaf

---

Actually, nobody needs to. You quoted a few things that nobody had said, now you added that bit about

Quote:

---

your claims of ".NET-superiority" (in case you make them)

---

, and this part about me (or us, since "You" is ambiguous") wanting to convince you that you are delusional.

I suppose you could just call that defensive, rather than delusional. It's not a good position to stand on. Nobody should care which language they use. There's a right choice for each person in each situation, and that's the one you should use, whatever it is. However, the threat of threads like this is that the term "trolling" came from fishing, not from the idea of a troll. It was about casting bait into the water in hopes of getting a bite. If everybody ignored the bait...the fisherman would leave.

Quote:

---

Originally Posted by Shaggy Hiker

...why did you do thorough tests with .NET?

---

To find out, if we were missing something... ;)

Quote:

---

Originally Posted by Shaggy Hiker

What kinds of tests?

---

All kinds (performance - ease of implementation - Debugging things - Form-Designer-usage).

Quote:

---

Originally Posted by Shaggy Hiker

What did you conclude from the tests?

---

That potential porting-efforts to an (identical) .NET-based version of our Main-VB6-App would be a waste of development-time.

Now, that "the Web is the new thing to port to" - we are quite happy we did not waste any money and resources on .NET in a pointless "intermediate step".

Quote:

---

Originally Posted by Shaggy Hiker

Still, since you mention it, which library adds a List(of T)?

---

The New_c.ArrayList thingy you've seen in my VB6-code, is part of the vbRichClient5-COM-lib.
(though in the VB6-codebank, there's comparable Class-wrappers for stuff like that).

Quote:

---

Originally Posted by Shaggy Hiker

Nobody should care which language they use...

---

Then what exactly did motivate you, to bring up generics and "List of T" into the discussion here?
(if not to point out something, that might serve as a "hard to beat advantage of .NET over VB6")?

We are in a VB6-forum here - of course we are "kind of defensive" when alleged advantages of other (primarily Desktop-)languages are brought up. <g>
Just for the record - it was not me, who entered a discussion in the VB.NET forum - suggesting that "VB6 can do things .NET could never do".

Let's just have our bit of fun, maahn... ;)

Olaf

Quote:

---

Originally Posted by Schmidt

Well, to be precise - it also does not mean, that the points were valid ones (unless there is proof).


Again - I don't believe that your claim is true (because - so far - I've never seen a VB.NET App which could not be done in VB6 as well).

---

Ok so how hard do you think it would be to write a VB6 app that allows for data collection and transmitting via TCP from a WCE4 based device? WCE5? WCE6? WCE7? Windows Mobile any version? This is some of the new and exciting stuff that was added to VB.Net early on. I have written dozens of these. Unfortunately they removed this support after VB2008 so the newer versions of VB.Net can not do it either.

As for PC based apps I generally use VB6 though I have opted for VB.net on a few as they were more simple to write in VB.Net than they would have been in VB6. I'm sure they could have been completed in VB6 but would have taken a lot longer to develop this is not the case with most projects but is with some.

Quote:

---

Originally Posted by RipVoidWinkle

Does anyone here use VB6 on Win8 or Win10 ?
What version of Windows does VB6 no longer work with?

Now I remember why I was forced to upgrade from VB6
I could not install VB6 anymore on Win8 machine.
All machines at work went to Win8. Game over for VB6.
Almost positive that was the reason.

So, I moved to VB 2005 and had to make a few code tweaks.
Everything in VB.NET is OOP.
Once I did that, I just kept migrating to 2008 –> 2010 –> 2013 –>2015 –>2017
which was a matter of Open/Save in each new version.

I get the whole “it works for my needs, leave it”
but am glad I don't have to jump through hoops to keep using a 20 year old IDE.
For example, like not being able to run anything past Win7, which is now a 9 year old OS.

---

I have installed it under Windows 8 and 10 and have used it under 10. I ditched 8 right away, never liked it.

Anyway it is fairly simple to get VB6 to install under 8 or 10 but requires a little different method than on the older versions of Windows. Once properly installed it works fine and programs built in VB6 work fine under all versions of Windows from 95 to present and who knows how far into the future.

Quote:

---

Originally Posted by Schmidt

Now, that "the Web is the new thing to port to" - we are quite happy we did not waste any money and resources on .NET in a pointless "intermediate step".

---

I don't agree with that. "The Web is the new thing" is kind of like "Linux is the new thing". There are things that make sense on the web and things that don't make sense on the web. I don't expect that to change, as much as some folks are pushing it. However, even in the web, I've always felt that JS was half-baked. It arose in the early days, and has issues. WASM is essentially the replacement I always expected, but whether or not it lives up to that promise remains to be seen. After all, it may just lead to WASM performance for a JS engine, or not. Furthermore, it may be .NET in WASM, which is currently possible, but will be even more so, is a future. I'll be moving all my non-UI dlls over to .NET Core (no framework needed, no IL, etc.), which positions me for WASM down the road. You never can tell, but since that's not an MS-driven thing, they can't very well walk away from it (or, at least it wouldn't matter if they did).

Quote:

---

The New_c.ArrayList thingy you've seen in my VB6-code, is part of the vbRichClient5-COM-lib.
(though in the VB6-codebank, there's comparable Class-wrappers for stuff like that).

---

Ah, I thought it might be, but I'm not familiar with that. Can you pass in classes as arguments along with the VB constant you used in the example?

Quote:

---

Then what exactly did motivate you, to bring up generics and "List of T" into the discussion here?
(if not to point out something, that might serve as a "hard to beat advantage of .NET over VB6")?

---

You wanted a challenge. You've been asking for one for years. I don't believe anybody other than you is all that interested, so I tossed up something simple to describe, yet useful. Looks like you already took that one on, so it wasn't that good. Perhaps you could take on Tasks? It wouldn't be nearly as useful, but it would be a challenge. They aren't threads, remember. I wouldn't suggest LINQ, because I don't like LINQ.

Quote:

---

We are in a VB6-forum here - of course we are "kind of defensive" when alleged advantages of other (primarily Desktop-)languages are brought up. <g>
Just for the record - it was not me, who entered a discussion in the VB.NET forum - suggesting that "VB6 can do things .NET could never do".

Let's just have our bit of fun, maahn... ;)

Olaf

---

I'm not sure what that discussion in the VB.NET forum is about. If there was one, I don't remember it. There were some in General Developer and Chit-Chat, but I may be misunderstanding you, too.

It is certainly entertaining, which can be seen in the fact that the threads go on for so long compared to more serious threads. Somebodies feelings often end up getting hurt over something or other, eventually. Seemed to be going in that direction this time, too, though it's pulled back, perhaps for good.

The same kind of debate went on between VB.NET and C#, though at a much cooler level, up through 2005. It pretty much died out after that, once MS declared that the feature sets would converge. It'll be interesting to see whether or not it flares back up now that MS has stated that the feature sets will diverge again.

Anyways, it took over half an hour to write this due to a whole lot of cooking going on. It's a stressful time of year. I'm out for the night.

vbForums may be able to launch such a challenge: Use VB6 to re-implement all famous commercial software developed with dotNet.

Maybe most people think this is a joke or crazy idea, but I think it is possible.

Quote:

---

Originally Posted by DataMiser

I have installed it under Windows 8 and 10 and have used it under 10. I ditched 8 right away, never liked it.

Anyway it is fairly simple to get VB6 to install under 8 or 10 but requires a little different method than on the older versions of Windows. Once properly installed it works fine and programs built in VB6 work fine under all versions of Windows from 95 to present and who knows how far into the future.

---

Same for me.
Agree 100%.

- At home I use Windows 10 Home (1809)
- At work I use Windows 7 Pro SP1; also I use different virtual machines (VirtualBox/VMWare) each with different Windows versions to test my programs.

No problem, for me.

The future could be Flutter: Flutter on desktop, a real competitor to Electron.

Not that I'm convinced.

What is the special trick to correctly install VB6 on Win8+ ?
I don't recall the error I came across anymore.
Also,