I do. We build a desktop app used by businesses around the world, including some mentioned regularly on hacker news :)
At the time we stared (1999), vb seemed like a great choice for desktop apps: It had a ton of built-in controls for building UIs, it was quick and easy to do so, and there were tons of dlls and ocxes we could tap into from a ton of different vendors.
The vb language was also appealing on a larger scale because you could take existing knowledge to other areas of the windows ecosystem: excel\outlook automation, classic asp if you need web stuff, windows automation\administration, and ie scripting.
MSDN was also an incredible learning resource
I attended a few small group sessions with microsoft in the early days of .net and we were planing on migrating ~100k lines based on what we were being shown. It looked awesome.
I managed to get hold of an early beta version and did the obligatory "hello world" and was gut punched. It took a few seconds to load took like 20ish mb of ram.
It seems laughable by today's standards, but in 2000 our target customers were still clinging to win98 and the pc's generally had garbage specs. IT people were livid we were wasting 4mb of their ram to run the vb6 version of our app. We lost sales and spent hours on the phone justifying our ram usage (fun times). A 5x increase in ram was completely unacceptable so we put it on hold in hopes that the release would improve things.
Things didn't improve so we put the plans on hold in hopes that vb7 would get released or they would reduce the runtime requirements.
Then something really strange happened: We almost lost a sale because the IT guy thought we were using .net and he refused to install the .net framework because it "used too much disk". I had to take 2 meetings with this guy and was literally screaming into the "WE DONT FUCKING USE THE .NET FRAMEWORK, DONT FUCKING INSTALL IT, WE DONT USE IT". And this wasn't the only incident. I'd get pulled into calls and would have to talk irate IT guys down from the ledge and assure them that no .net framework was required to run our program.
Today, things are much different, no one cares about using gigs of ram or hundreds of gigs of disk space. But there is a new set of problems trying to explain how a desktop app works to someone who only knows how to admin web apps.
And the .net framework eventually become ubiquitous via windows updates and other, more critical software, starting to require it. But the early days were really, really odd (at least for us and our customers).
We aren't complete luddites though. We do utilize some .net (asp.net\vb.net) on the server side for a few tools. We have a mobile app (xamarin\c#) that has some companion features, raspberry pi (python) for some "smart" displays, Arduino, and have started to look at blazor to the replace the desktop app.
I might still recommend vb6 for a desktop app with the caveat that it is a pain in the ass to install on later versions of windows.
tldr: vb6 mostly just works and is a great tool for desktop apps
At the time we stared (1999), vb seemed like a great choice for desktop apps: It had a ton of built-in controls for building UIs, it was quick and easy to do so, and there were tons of dlls and ocxes we could tap into from a ton of different vendors.
The vb language was also appealing on a larger scale because you could take existing knowledge to other areas of the windows ecosystem: excel\outlook automation, classic asp if you need web stuff, windows automation\administration, and ie scripting.
MSDN was also an incredible learning resource
I attended a few small group sessions with microsoft in the early days of .net and we were planing on migrating ~100k lines based on what we were being shown. It looked awesome.
I managed to get hold of an early beta version and did the obligatory "hello world" and was gut punched. It took a few seconds to load took like 20ish mb of ram.
It seems laughable by today's standards, but in 2000 our target customers were still clinging to win98 and the pc's generally had garbage specs. IT people were livid we were wasting 4mb of their ram to run the vb6 version of our app. We lost sales and spent hours on the phone justifying our ram usage (fun times). A 5x increase in ram was completely unacceptable so we put it on hold in hopes that the release would improve things.
Things didn't improve so we put the plans on hold in hopes that vb7 would get released or they would reduce the runtime requirements.
Then something really strange happened: We almost lost a sale because the IT guy thought we were using .net and he refused to install the .net framework because it "used too much disk". I had to take 2 meetings with this guy and was literally screaming into the "WE DONT FUCKING USE THE .NET FRAMEWORK, DONT FUCKING INSTALL IT, WE DONT USE IT". And this wasn't the only incident. I'd get pulled into calls and would have to talk irate IT guys down from the ledge and assure them that no .net framework was required to run our program.
Today, things are much different, no one cares about using gigs of ram or hundreds of gigs of disk space. But there is a new set of problems trying to explain how a desktop app works to someone who only knows how to admin web apps.
And the .net framework eventually become ubiquitous via windows updates and other, more critical software, starting to require it. But the early days were really, really odd (at least for us and our customers).
We aren't complete luddites though. We do utilize some .net (asp.net\vb.net) on the server side for a few tools. We have a mobile app (xamarin\c#) that has some companion features, raspberry pi (python) for some "smart" displays, Arduino, and have started to look at blazor to the replace the desktop app.
I might still recommend vb6 for a desktop app with the caveat that it is a pain in the ass to install on later versions of windows.
tldr: vb6 mostly just works and is a great tool for desktop apps