Bill Gates demonstrates Visual Basic (1991) [video]
youtube.com
youtube.com
Ruby was originally going to be a customizable shell/desktop for Windows 3.0, with pretty much what Bill was demoing but a more modest scripting language - and the ability to plug in other scripting languages as desired.
Microsoft decided to make Basic the scripting language and sell it as a standalone development system instead of being the Windows shell.
I guess my great claim to fame is the VBX (Visual Basic eXtension) interface, which I originally called the Gizmo API. I still think "gizmo" was a much better name than "control" as Microsoft later called them.
AMA.
Would the defaults be swappable without rewriting it all?
https://microsoft.fandom.com/wiki/MS-DOS_Executive
Alan's idea was that your desktop could be customized to your needs, either by yourself or by an IT group. Say you're rolling out machines to an accounting team: the Windows desktop would have tools right on it to make those team member's jobs easier.
Or you could make your own desktop tools with a few clicks and maybe a bit of scripting.
In the end, Microsoft decided to go with Program Manager and File Manager for the "shell" and turn Ruby into application development tool.
Microsoft: "I know! We'll let users create their own UI! What could possibly go wrong?"
That Ruby ended up the way it did was an example of what they call "cooler heads prevailing".
I've always wondered where the "Thunder" prefix for VB's window class names came from (ThunderForm, ThunderButton, ThunderListBox, etc). Do you know who came up with it and if there's any fun meaning behind the name?
"Thunder" was the code name that Microsoft adopted for Ruby/VB early on. Its tagline was "The Power to Crack Windows".
As you know, window class names existed in a global namespace, so you needed some kind of hopefully-unique prefix or something to avoid collisions.
Did you ever happen to see an early VB version with "GSK_" prefixes on window class names and such? My colleague Gary S. Kratkin developed much of the forms editor, so he used his initials as the disambiguator.
It was a tradition back then to use your initials like this. Mark Zbikowski may be the most famous example. To this day, every Windows EXE file begins with his initials.
https://en.wikipedia.org/wiki/DOS_MZ_executable
Here is an article from Scott Ferguson about Thunder:
https://www.forestmoon.com/birthofvb/birthofvb.html
And a great long-form article from Ryan Lucas of Retool:
https://retool.com/visual-basic
For the curious, that article has the origin story of "fire an event".
I also want to mention Frank Raab and Mark Merker, who both did a ton of work on Ruby, and of course Alan Cooper gets credit for coming up with the idea and developing his Tripod prototype.
Oh, then you should know that there are still VB6 apps in heavy use being actively maintained out in the world. I'm working on a treasury management system that is in use by 90+ banks in my country, where the bulk of the app is still VB-based (we're moving to C# but it will be many years still before we can say a complete goodbye to VB).
I learned VB4 or 5 at college in 98. The teacher did nothing while we sat through MS videos where a bearded man both poured water from one jug to another and taught me how to code. Magical stuff.
Thank you for this image :D
I am glad that VB served you well.
As ChatGPT said to me one day: happy hacking! :-)
Even today there is no WinUI3 GUI designer for C++.
Desktop computing era is over now :(
The VCL framework combined with the visual editor in C++ Builder[1] are way more advanced than anything Microsoft has made available for (regular[2]) C++ developers targeting the windows desktop.
[0] as long as you don't care about the fact it'll use some old versions of GUI controls, though a manifest resource can fix that
[1] and Delphi, where it really came from
[2] i do not count using Managed C++ or whatever .NET based, those are different beasts
> I developed an electronic mail gateway for the Macintosh, featuring scriptability in a FORTH-based language.
(Also How to Lie with Statistics is my favorite book!)
jaguar32 and master32, :) swapping bas files was the only way I could actually do difficult stuff in the beginning
I didn't have a computer so I wrote a lot of BASIC in composition books, instead. I never got to run any of that code.
Also DOS32.BAS represent! VB6 was all I wanted to do when I got my first PC. It took me like a month to download a warez copy overnight with a download resumer. My dad wouldn't let me use the phone line during the day.
I used vb6 to make about 15k in high school in a slightly unsavory way.
I'm learning rust now.
The game was called GORILLAS, but was in a source file GORILLA.BAS
Published in 1991, 32 years ago. Dang. It was pretty new source when I read it. At the time, I figured it was old.
And why didn't Bill ever include the VB runtime with Windows?
When I was a kid, I used to sneak off to the computer lab and just play with the form builder. I had no idea how to code at the time but it was fun making mockups
(https://www.youtube.com/watch?v=hkDD03yeLnU for the younguns)
The immediacy of feedback in these platforms was responsible for many of the enlightened and motivated faces in those classrooms.
Your contributions have global reach and we thank you for them.
Shout out to former VISBAS email list subscribers, that was a fun community.
Was it meant to compete with Norton Desktop? Norton Desktop had an extremely powerful built-in visual scripting language that resembled Visual Basic, so powerful it's strange that it wasn't a separate product. I learned about this from https://youtube.com/watch?v=iD7AezjG5YE&t=25m52s.
Visual Basic allowed people with minimal knowledge of computers to write useful applications that powered the economy. This is something we often forget nowadays in the flood of frameworks, programming paradigms, microservices etc. Computers exist to serve humans, we must never lose the connection with how useful our systems are.
That and Delphi, how I miss you.
Our site at the time was Active Server Pages, with a DCOM backend. We started out writing the DCOM components in C++, but way more than half of the C++ code was in just type conversions with the variant types that COM demanded.
We got tired of that really fast, and started building the COM components with VB5/6. That was SO MUCH faster.
The language was almost English like. The interface was so advanced for it's time. The drag and drop form designer.
XCode is nothing even Microsoft's own product line has nothing like that.
Edit: typo
For various reasons, we kind of lost that pragmatic approach when apps moved from the desktop to the web browser, and we've only just recently started to revisit it.
Some of us don't want to spend an hour rat wrestling to get a form up -- a form that won't even tolerate resizing very well. Tcl/Tk is pretty much the fastest way to go from zero to functional GUI I've ever seen -- especially if you already have some functionality that works from the command line and just need to wrap it. It's also available from Python as Tkinter, and is amenable to repl driven development.
[0] A for Almost as technically the program can compile with different GUI backends (Win32, Gtk, Qt, etc) :-P
VB6 was easier to get started with and learn though, but IMO that was because it didn't provide as many features and on that front the earlier VBs (up to VB4, before the new IDE was made) were even easier.
I left that company when it was clear their dreams of replacing it with a SaaS product wasn't headed in the right direction for me, but I sometimes wonder if that product is still going or whether they finally achieved their SaaS migration dream.
Over a weekend, I built a very useful application using only the `yad` [1] tool, sqlite3, and BASH scripts. Its a membership system with integrated Bluetooth, QR codes, Markdown for membership cards, and so on.
I was impressed with how quickly it all came together.
It was delightful to be programming forms, using BASH to validate the results, and then stuff things into a relational database - all with common tools available with ease on the newly installed Raspberry Pi.
I was struck with how pleasant it felt to be coding this way. Immediate forms, very rapid validation logic, and a great set of tools to do data mangling. I even managed to convince ChatGPT to give me a "randomized test data" script that populated my nascent database with acceptable data for the purposes of continued development. Suddenly, rendering Markdown from the .sqlite3 database was fun!
We've come a long way. I didn't have to fuss much to gain access to many of these tools. Of course it helps that I know a bit of `yad` to be dangerous, enough sqlite3 to be productive, and just enough BASH to tie it all together.
I couldn't help but feel, somehow, that there was a way to make a GUI for these three tools, though ..
We haven’t forgotten anything. MS Power Apps is the spiritual successor for Access.
Also, it’s the likely reason that startups like AirTable went unicorn, and if you look at Salesforce and ServiceNow they look a lot like enterprise versions of MS Access. Everything mentioned is a low code platform. I’m sure if you give me time I can name more major low code companies
What you’ve forgotten in your nostalgia is the instability and insecurity related to VB and everything that relies on it. It’s probably why MS is trying to kill it for Windows 12.
I am pretty sure that having access to all of the events in VB6, I would be able to implement a bug-free Autocomplete Textbox. [0]
In Power Apps, it is not possible to implement this exact UI, without major bugs - in 2023.
Something was definitely forgotten along the way.
[0] https://www.w3schools.com/howto/howto_js_autocomplete.asp
.. That’d completely fall apart at the first hint of anything vaguely nontrivial going on with input, whether due to the user’s language, accessibility tech, or autocorrect on a touch keyboard.
I remember being a non-Latin-script user in the age of localization patches and country-specific builds, and very much appreciate today’s “(try not to ruin) i18n first” approach (among other things implied by the above), but a simple input API absolutely was a casualty of that, even if you LoB app is completely fine being ASCII-only (however dubious a statement that is).
(No experience with Power Apps, but I don’t think there is a single modern platform where that’ll be easy.)
It was great for the time. I still don't see time travel debug in any of most modern IDEs.
Node.js for a modern take?
Too bad theres nothing as good an ubiquitous nowadays.
Qt has a visual designer that's less intuitive to use than VB was, but on the other hand you don't need to write all that resizing code by hand, or to be stuck with a fixed size window.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
VB forms were something that was very easy to get started with, and then took forever to actually polish. If you wanted to make things pretty you'd spend ages adjusting positions by hand.
If you want to make a fixed layout you still can with modern tools. The difference is that instead of painfully adjusting everything by hand because something is longer in Spanish and doesn't fit, you can just resize the window in the IDE and be done in 10 seconds.
All the VB-style development and developers moved to the web, but the web's layout paradigm is fundamentally reflowing-resizeable-document-based, not the drawable, draggable absolute positioning of dialog box controls.
Not to mention the fact that code was now split into three languages on the front end and one or two on the back end. You can't just write code to respond to a button click to read from the database, because now you need an API and authentication and all that...
I'm sure there are a few exceptions, but VB was never used for "traditional" app development in the first place -- you weren't going to write a Photoshop or Word in VB, or even something small like a CD ripper or a music player, since it was so cumbersome to access any of the Win32 API's -- and performance wasn't anywhere close to C/C++ either.
VB was used for business apps that connected to databases, and those apps really did just entirely move to the web. It was such a gigantic benefit that web apps were inherently cross-platform, didn't have to be installed or deal with different versions of binaries, and could add new features instantly for everyone.
And Microsoft inadvertently hastened the transition by making VB.NET backwards-incompatible with VB6, at just the time that web apps had become capable enough. Since all this software was going to need to be rewritten to some degree anyways, might as well rewrite it for the web sooner than later, and get all those new benefits.
There was no single language back then. Node.js wasn't even an idea at that point.
And regardless, you've still got to learn HTML and CSS and often SQL.
Or for really perverse IE only stuff, VBScript in ASP and VBScript in the browser.
Delphi had layout, so did Java (many of them). Resizable was always a thing, aside for the extremely lazy development with null layouts by some programmers.
VB used to be considered a lame/toy language with its "onerror resume next" paradigm.
Do you prefer more lines written by hand? Or more frameworks?
Because those are meant to offset each other.
I can't believe there's no browser-based point and click software that lets you build web apps in JS.
Prototyping for a dB backed app is extremely easy.
I'm fully aware of all it's drawbacks, but there's still nothing like it available today.
But yeah, both tools are great for in-house applications in my experience. It’s quite easy to provide actually useful features very quickly. It might not win you design awards, but often that’s not a problem in reality.
I’d rather have an inventory that is correct but maybe looks a bit homegrown than one that looks like it has been designed by Jony Ive but is wrong for example.
Much of your point seems debatable. I had a band director that was able to write a GUI app in 1992 on a 12MHz 80286 with a couple megabytes of memory. Put today's tooling in their hands and I don't think they'd be nearly as effective. Today's tools may be better by some definitions, but certainly not by all.
building a UI now with modern tools makes me lose sleep
If native app ecosystems had as much invested in them (monetarily and people-hours) as the web ecosystem has, it would easily blow away anything you can currently do with a browser, and it'd be much easier. But investment got steadily and increasingly redirected to the web, while simultaneously progress was being held back by the limitations of the web.
Native app ecosystems benefit from the fact that they are a singular computing and OS target. Web apps have to work on everything. It's the same reason gaming consoles tend to have a wider variety of AAA games than PCs. It's easier to optimize for the PS5 or Switch and call it a day, than it is to port a game to work on 6 year old video cards and get it to work on Mac (both ARM based and x86 based), Windows, and Linux. A web dev has to inherently target thousands of different devices, dozens of different operating systems, 3 or 4 browsers, and dozens of screen resolutions, and cannot make any assumptions about what type of input devices are available.
Oh, and they also have to assume an async programming environment with intermittent connectivity, and possible throttled connections as low as 100-200 kbps, so try to keep the bundle size under 100KB to keep time to first paint under 1s, mmkay?
Even Windows 95 apps could assume a few dozen MBs loaded in via disc, and count on cached assets being available on disk.
So maybe mobile phones are just not meant to be tools for actual work, despite of what marketing departments of phone manufacturers tell us?
As for running the software the platform has a proprietary license obviously but you can host your own Retool backend from which to serve the apps to your end users (check the docker repo). This is an alternative to the SaaS/cloud based app hosting at https://retool.com/.
There's a free tier to edit and run the apps but professional usage will have a license fee. This is not unlike making an app with VB which required buying VB and having end users buy and run Windows.
Many of us grew tired of being locked in to Microsoft's platform, their simple yet stifling assumptions and their hostile behavior.
Those who walked away from Microsoft's Omelas went in a thousand different directions. While some grew tired of being pioneers and returned or found new walled gardens, others refused to trade their freedom for comfort or simplicity.
I've worked in multiple C# shops with both WinForms and WPF. Everyone in the WinForms shop hated it due to the enforced designer usage, and everyone in the WPF shop only used the designer as a preview window and never directly used it to build anything.
I can't speak for the C++ side of things.
Also, I think I read a few times on other HN threads, somewhat recently, that the GUI development scene on Windows is a mess these days, because MS changes the recommended framework every now and then. Is that true?
[1] By framework, here, I mean the layer such as WinForms or WPF, that GUI developers program to.
Someone correct me if I'm wrong, I've been in WinForms land for a while (unfortunately).
Needless to say, we're watching the video of a VB demo, not a Realizer one :)
I can't find much online about the original Realizer, but there is a Wikipedia article for CA-Realizer, which was the version released after CA bought their company. CA-Realizer didn't really go anywhere and my dad eventually left CA as well. Very cool story though, and a large reason I chose to work at small companies fresh out of college too.
_Windows 3.0 for BASIC Programmers_ by Michael Hyman
which I learned a great deal from (and the Poker game of which kept me entertained quite a bit working nights).
I still have the glossy and manual for Realizer too.
> I personally believe that Visual Basic did more for programming than Object-Oriented Languages did. Yet people laugh at VB and say its a bad language, and they've been talking about OO languages for decades. And no, Visual Basic wasn't a great language, but I think the easy database interfaces in VB were fundamentally more important.
https://blog.codinghorror.com/linus-torvalds-visual-basic-fa...
Loved hitting up PlanetSourceCode to get scripts and reverse engineer other peoples code to learn.
I built so many fun programs - the best of which was a chat programs using UDP so we could chat over the schools local network.
I remember the feeling I had the day I learned about classes and functions, a true "wow" moment.
Unfortunately those text adventures died with the hard drive of the computer my parents had.
However some of the downsides included DLL hell and requiring 3rd party components for functions like TCP/IP (IP-Works) and more advanced UI elements and so on. I remember investing quite a lot in such components - I recall componentsource.com as being a key marketplace. I think one of the main issues was OS integration, hooking into Win32 required all kinds of incantations. Decompilers were also an issue.
It brings back memories of a much simpler time in terms of development, especially the UI editor - it was so fast to just draw a few forms and hook them up to code. I used it a lot for statistics type interfaces, and CRUD type systems, however I wrote a P2P communication tool back in 2000 that even had VOIP. I also recall writing a game that wrapped OpenGL and running it on my SGI520 Windows NT box. So much fun.
I transitioned to .NET and C# and didn't look back or bother with VBScript.
However I recall at the time feeling so abandoned by Microsoft, having to learn another complete system from scratch - existing projects didn't come across cleanly.
Anyhow... just a bit of a greybeard rant about the 'good old times'...
Just as an aside - after playing around with BBC Basic during covid, I was so impressed how OS calls were implemented in the language. If VB integrated with Win32 to the same level BBC basic integrates with RiscOS it would have been pretty much the perfect tool in my opinion.
[ asm_statements ]
That is, open square bracket, then write your assembly statements (one per line, as usual), then close square bracket.
That's it.
No assembly step required.
I installed and tried Gambas and it does have the VB6 feeling. A complied graphical Hello World was a matter of 5 clicks and `lblHello.Text = "Hello World!"`
I'll do a lot with this. Thanks again!
I still have 1 VB app on my resume from way back then, I refuse to remove it!
And boy do I miss just making stupid games really really fast, and making actual productive applications also really really fast. I had made an HTML editor with previews, syntax highlighting (lol, my own 'algorithm' haha), project management tools, and everything. I was so proud of that.
The base fond VB memories are the simple joy of starting a new project (before .NET called them Solutions) and making the thing I had in mind in like a couple hours. Really miss that.
https://www.folklore.org/StoryView.py?story=MacBasic.txt
(I bought a copy of Microsoft BASIC for Macintosh, and would have much rather had MacBasic)
tl;dr: VB started out as a project called "Tripod" (later "Ruby"), written by Alan Cooper (of "The Inmates are Running the Asylum" fame) and a small team of developers. It was originally a Windows shell construction set, but Alan sold it to Microsoft where it languished on the shelf for awhile.
Bill Gates eventually decided that he wanted to marry the visual UI building aspect with BASIC and handed the project off to Scott Ferguson and the Business Languages Group, who were maintaining Microsoft's QuickBASIC IDE, the BASIC compiler, and developing a new language engine (dubbed Embedded Basic) for inclusion in a relational database product codenamed Omega (which would go on to become Microsoft Access).
Microsoft even released VisualBasic for DOS which was QuickBasic with a text mode UI component.
Set aside the language syntax – the way that the IDE exposed all the UI properties to you was so enlightening. You couldn't help but learn how Windows expected controls to work.
Bill Gates demonstrates Visual Basic (1991) - https://news.ycombinator.com/item?id=24435217 - Sept 2020 (11 comments)
If you iterate long enough on your self developed backend/Frontend system to enable your BI department to work in their own with their data, it will eventually converge into something like a spreadsheet application with a custom DSL.
Or the database + SQL will be your converged application
It was a rough ride bringing VB to the web. There was VB Active Server Pages, then VB.NET Webforms, which did not always produce the most performant or secure UI code. It was like an ornery bronco in the age of industry.
The concept of Viewstate was interesting and probably looked great in demo applications, but it was ultimately not the best way to avoid writing JavaScript. Sometimes it could be tamed, but for the sly cowboy, ruby on rails was the king of RAD.
$99. I bought it instantly.
If you iterate long enough on your self developed backend/Frontend system to enable your BI department to work in their own with their data, it will eventually converge into something like a spreadsheet application with a custom DSL
But you will never see once again the same development speed you could achieve with Visual Basic 6.0 and earlier.
The UI was instantaneously responsive, and the language had very low cognitive load.
that app if done in react - would be so full of subtle bugs. and way slower too.
we really have regressed backwards as an industry.