I was 17 when VB6 came out, working at a local computer store, and getting into programming but couldn't afford $500 to by the pro edition.
One day, I happened to read an article that said they were given a free copy of VB6 to review for the magazine.
My 17yo mind was blown! Hundreds of dollars worth of software given away for free? Just for writing an article?! I could do that!
Having nothing to lose, I called Microsoft's PR department and requested a copy. Told them I published a newsletter about computers and was based in Queens, NY. Their only question? Where should they send the software lol
It was literally that easy. A single phone call with zero verification about me, my newsletter, and my so-called publishing company.
And it was Enterprise edition which retailed for over $1,000. For little 17yo me!
Naturally, I kept calling for more software. Office, Windows 98/NT, Encarta... you name it.
I even started calling other companies and published a single edition of the newsletter, in case anyone asked for a copy but no one ever did. All they wanted to know was where they should send the software.
One of my favorite free items was course on VB which came on 6 VHS cassettes. The lessons I learned from those tapes built the foundation of my programming carrier.
Of course, older me understands the economics of sending people a few bits of plastic & paper in exchange for press coverage but the joy I felt getting that software in the mail still hasn't left my mind.
They still do this in a formal way and i promise i don't work for MS in any way; It's called Microsoft for startups and you sign up with vague details about a startup and they throw 5 enterprise visual studio keys and 5 full office subscriptions your way along with a few thousand dollars of azure hosting credits to get you hooked.
About 20 years ago the Microsoft for Startups program included the full MSDN subscription which was ~5 keys for every product they ever made. 5 keys of Windows XP, 5 keys for windows server, 5 keys for 2000, 5 keys for every variant of Office. Very popular at LAN parties and they never did recall any of those keys. Today it seems they just give you developer tools and office, not the OS.
I used it for the Azure credits. My "startup" only needed a single instance so I really didn't spend many of them. I tried to get into the longer program but the form was broken in typical Microsoft fashion and kept looping over business verification, telling me I had to input my DUNS number and incorporation letter, then forgetting and throwing it back to that step.
Back in the early 2000s the company I worked for was a small IT shop and MS software reseller and the MSDN subscription included everything. I remember setting up Windows 2000 advanced server as my home network's router.
One of the programs I enjoyed writing the most with VB6 was a telephony capable IM program. Over dial up!
The IM portion was simple logic but the real-time voice was a challenge back then because audio compression was in its infancy. The few real-time compression libraries that existed were expensive to license and some even required royalties. Way out of my league.
At the same time, writing a compression algorithm myself was beyond my abilities. There weren't any VHS courses on that topic yet haha.
My solution was to use the recording control that came with VB6. I couldn't set the audio bitrate with that control but, if I had the recorder append the recording to an existing file, it would use the bitrate defined in that existing file.
So I created a teeny tiny wave file with 0 seconds of audio, included it with the program binary, and used a copy of it to seed & set the bitrate of each conversation.
Since they weren't compressed, the file integrity was very forgiving. I was able to pull out a chunk of data from anywhere in the audio file, put it into its own file, and it would play the extracted chunk of audio just fine.
So, that's what I did. I used the VB6 recording control with my low bitrate seed file to record their voice, had my code grab 1 second chunks of audio from that file, "stream" it to the other end of the line, write the data to disk, and use another VB6 control to play it for the recipient.
Surprisingly, the sound wasn't choppy at all. The audio quality was low, since the bitrate was in the low dozens but the conveyer belt of 1 second wave files being played back to back to back was not noticeable at all.
The debugger. Still the best debugger I have ever used.
You could grab the program counter/execution pointer and drag it literally anywhere, rewrite the code and keep on stepping.
I would get into a loop, realize I made a mistake, drag the PC back up above it, make a change and step back into the loop without breaking flow to compile or some other such nonsense.
Alien technology compared to most development environments even today.
Wow! That sounds amazing. I know people often compliment the debuggers for Smalltalk (Squeak/Pharo today), Common Lisp (SLIME/Sly) and Clojure (FlowStorm). Could you tell me more about the VB debugger? Are there other amazing debuggers I do not know about?
The Excel VBA debugger isn't much different. I love the VBA debugger. It is so seamless to step through code - correct in place - continue stepping to be sure the code works (split screen to see the code and its impact in the worksheet with updating turned on).
Still Smalltalk, but Dolphin Smalltalk which runs on Windows.
It was the best Windows app development too. You can write native Windows programs and it worked even better than Visual Studio for COM and ActiveX stuff.
I second GP's sentiment. That debugger was amazing. I've never seen anything that can touch it to this day.
Tell you more: you could also just run code to do things like change variables in the immediate window while execution was paused, so e.g that example where you want to re-run some loop: first you drag the PC arrow back to above the loop as GP already described, then in the immediate window you can just run things like e.g:
someVariable="initial value"
To reset vars back to their initial values, or clean out buggy data, or whatever.
then you can just step through the code or resume execution.
I used to use it a LOT for handling edge cases on long-running, one-off things: run the code until it hits an error, fix the error by doing some stuff in the immediate window, resume the loop without re-processing the 100K items you've already processed.
The destruction of VB with no upgrade path (the advice was to "just" rewrite your perfectly-functional 100KLOC codebase) is what pushed me away from MS, first to delphi and then to FOSS. But that VB6 debugger was IMO probably the best thing MS has ever done.
I came here to say the same. Visiual Studio finally got this and it's called 'Edit and Continue'. IDEA can invoke a Java feature to reload classes and move the point of execution. Neither are as reliable as VB6 was.
I taught my daughter to program using VB6 -- long after it was already obsolete. It's very easy to get started and build a GUI application with very little ceremony. You can develop your entire UI without a single line of code and run it. Only then did you need to double-click on components and start adding functionality with code.
But actually using it for "real" development was not as enjoyable and I did it for years. If you only wanted to make a static fix-sized application then it's ideal. But if you wanted your application to adjust to the size of the window (and therefore the resolution of a monitor) you had to wire all that up yourself. Painting controls to specific pixel sizes is an obsolete concept.
> What do you find frustrating about modern .NET, C#, and Visual Studio that VB6 didn't make you fight?
C# is superior language to VB6 and WinForms is a superior way to do an equivalent style of UI development. While the VB6 designer was a smoother experience than the Visual Studio designer it was a much more limiting experience.
But if were to put my nostalgia glasses on, I think what is frustrating about .NET GUI development that never seemed frustrating in VB6 was just the ease of getting it do what you want. At the core, WPF/XAML/whatever is a better way to do a GUI layout -- Instead of pixels you place things in stacks, grids, and panels. You have margins and padding. But styling your GUI is so much more complicated and it descends into this overly complex impossible to understand system that makes HTML and CSS look good. This was not a problem in VB6. The GUI interaction with code is also more complicated with magic static property incantations that would never exist in VB6.
You open up the GUI editor, drag a button onto the screen from the toolbox, give it a name/id, and double click on it which takes you to the source code file where a “buttonId_click” handler is auto created for you. Super easy to create simple GUIs without much work while still wiring together the bits that need code.
There was certainly some rough edges and I don’t know how well the workflow would have adapted to responsive design but line of business apps in controlled environments it was so powerful. VB6 and Delphi were like nothing else we have today (at least that I’ve seen).
Windows Form Designer in Visual Studio still works in that same way? This was one of the least differentiated things, really; while XCode’s interface building tools have always been clunkier they also offer the same functionality too.
Honestly the biggest problem is the entire environment is very VCS hostile in a hard to crack way.
I've had some success getting a bunch of scripts to export MS Access database structures, but it takes over an hour to run and requires some post processing clean up so it's not really a great <feature> -> <commit> cycle.
Honestly I'd desperately like a similar experience for GTK development - a few things seem to exist, but they've never really got me building something as quickly as VB6 did.
EDIT: I mean thinking about it, the way people are using AI programming tools feels very much like a desire to actually get the VB6 - no data flow model or weird pipeline or whatever rendering BS, just "I want a control here and here's what it should do". I remain pretty sure that AI is a very expensive solution to the problem of we've been building the wrong tools and libraries for years.
The ability to rapidly build apps was amazing as a kid to learn, and I think Linux needs something similar so that small business applications can be built quickly and cheaply.
Making real, complex components, and drag dropping them into other components. Designing a UI with all your components and zero layout code, just positioning them visually. To anyone who grew up with VB6, web development feels like a serious regression.
Building the UI was superfast. Wiring the logic was somewhat painful but manageable. But you did not really need more than that to build CRUD apps. For everything else, you had C/C++ and the Win32 API.
I am a huge fan of keyboard-only navigation and you could achieve a large part of the extremely rapid data entry methodology of DOS UIs of the 80s and early 90s with considered key-handing. You never even had to look at the screen for the most part; only at the document in front of you.
Microsoft killed it with the move to DOTNET. VB.NET was a different beast, and C# was a superior language. But it was never the same. I moved to web-uis in the late 2000s. Painfully slow way of writing business apps, but the complexity can be managed if you can reuse templates/components.
I could type ~four lines and an alert box response from a visual form.
For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.
The amount of paperwork is controllable. It’s just that most programmers have a tendency to prefer more paperwork because they believe it is a better software architecture.
That said I also lament the death of WYSIWYG-style HTML authoring tools. This is I think the same affliction that caused programmers to prefer writing code to build UIs rather than drawing it interactively.
Interactive UI design tools are cool when you're not a programmer, an inexperienced programmer, or lack the imagination necessary to create new abstractions.
UI preview tools are incredibly useful, hot reloading when doing UI work is, again, incredibly useful.
What nobody needs in their life is to meticulously hand place elements and align them only for the auto-resizing logic to fuck things up.
You want good abstractions which let you easily and quickly define UI elements and to define new composable widgets. So that you can declare in your code details of how things should be aligned with respect to each other, and leave final layout to more code which, if you are lucky, you might not even need to write.
For an example, check out jetpack compose. It's not completely flawless, but it truly isn't bad.
Yeah this is the kind of programmer’s thinking that led to complexity that is present by default and sometimes not warranted.
> meticulously hand place elements and align them
You don’t need as much meticulousness as you imagine. Have you tried placing some text boxes in Keynote or PowerPoint and hand aligning them?
> for the auto-resizing logic to fuck things up.
Auto-resizing is often unnecessary during rapid prototyping. Even in prod, even if you are developing internal apps in an enterprise environment, it’s still not necessary. Make your window non-resizable if you are targeting native, and set a fixed viewport <meta> for web apps.
> define new composable widgets
The kind of people who are enjoying VB6 don’t need new widgets let alone composable widgets. Just use whatever widgets that are builtin.
Basically your entire comment is describing the kind of complexity that I said was not always necessary.
You don't need to be meticulous if you want your software to look like a 5 year old drew it, which maybe you don't care about.
But even so, hand placing 20 labels, editing them to say the right thing, then hand placing the entries, making sure the tab order is correct, you don't want to be doing that by hand. And it gets worse if you need to edit this in the future.
I am not saying this because I think it sounds stupid, I am saying this because I spent 4 years at an organization where this was the only method to do things and I _know_ for a fact that it is stupid and tedious. Given that we had the list of fields, if the language wasn't hot garbage, and the organization wasn't stuck in the past, we could have made it so 99% of fields on 99% of forms could have been placed automatically and cleanly saving literally months of development time in total.
We needed a complex UI for something which could not be done natively using this technology and I proved this to be true when I made a data driven UI in a fraction of the time it was taking to iterate on the legacy version which had 1/10 of the features.
It was amazingly easy to interact with other apps via OLE Automation (aka, COM Automation).
About 25 years ago I wrote a program that would look for requests (in the form of XML files) from the custom software on our Solaris system, then based on the contents of the request it would fire up Word, load up the appropriate letterhead and body template, fill in the required information (e.g., client name/address, caseworker name, etc), print two copies (one for the file, one with an envelope to send out), and store the completed document in the client's folder on the fileserver.
This program saved an incredible amount of time and let the office typing pool concentrate on typing dictated letters instead of filling out templates.
Without the magic of OLE Automation letting me use Word programmatically from my application, creating this would have been basically impossible.
Man, I wrote a lot of things that used OLE. Microsoft was heavy on building things like that. I wrote a program that would load up patient data and build referral letters for physicians and send them via electronic fax. It freed up like three admin staff that were dealing with that before and hating it.
The funny part was some of them must have been so seldom used that I'd run into problems and uncover bugs that were very quickly apparent, and I'd call MS support and they had never had them reported. I sometimes wondered if I was the only person that used them. WebDAV for Exchange was another on of those things.
I remember calling MS support, vaguely related to this project.
For example, if the Edmonton office needed to send a welcome letter to a new client, the flow might look like this:
1. Create a new file based on X:\Templates\EdmontonLetterhead.dot
2. Insert the contents of X:\Templates\A01-ClientOnboarding.doc
3. Fill in fields. Usually stuff like client name, caseworker name, etc.
4. Click the links in the file (e.g., there'd be a link to X:\Templates\EdmontonContactNumbers.doc), printing each document and deleting the link from the final document.
5. Save the file to the client's folder (e.g., S:\Clients\000123-Jane Smith).
6. Print a copy for the paper file, a copy to mail out, and an envelope.
We called Microsoft Support because when changes were made to the template documents it would update the links to relative paths. These don't work with our flow because the document either isn't saved, or is saved on a different network drive.
Microsoft Support wasn't able to help us. They understood exactly what we were doing, exactly what the problem is, but they weren't able to fix it. That's just how Word works, it didn't have a setting to force absolute links.
I ended up writing another VB6 program, using OLE Automation to get Word to do the work, which opened each document, saved it to a local drive (which turned the relative links into absolute links), then copied it back to the shared drive.
Indirectly introduced me to programming as my dad was obsessed with it growing up. He was a hobbyist with zero formal training, working a completely unrelated job, and still made a ton of money selling tailor made admin software to all kinds of small businesses. Really a testament to how good VB6 was.
In the windows of ecosystem for basic business apps, it was so way to build things. I know Microsoft made it, so it has an unfair advantage vs languages like Delphi, but compared to C++ it was so easy and fast to build basic working apps.
My favorite thing was to watch a guy who was in tech support and frustrated with our overly complicated process build something on his own that solved a major problem we had. This was by himself. It was amazing. Low barrier to entry, and he taught himself enough to fix his issue. The vp called me in to look at it and make sure it was ok, and I was like “a couple things here or there but it was more than good enough to function day to day.” Never would have happened with lower level languages.
There a good chance of this type of citizen developer coming back with AI. Google AI studio will automatically add a Firebase backend to vibe coded apps when needed.
VB6 was what sparked my interest in programming. My final project in my programming class was a menu based dungeon crawling game with turn based combat. I was obsessed with Diablo on PC at the time and I just wanted to make anything that remotely resembled it. So you had a town where you could buy equipment and magic spells and then you would go into the “dungeon” and you would fight a selection of random monsters until you got to the boss.
I’m sure I would recoil in terror at the code I wrote but I owe a lot to VB6.
My first job was VB6 and I really enjoyed working on it. It was pretty late in it's life - .NET had just come out when I started. The existing program I was working on was pretty complex though. I spent a year rewriting the database layer (well, it wasn't a layer when I started but it was by the end) from an old cursor / file based system to use SQL server. That extended the lifetime of the product by quite a margin as it had been struggling with bigger customers.
It was really stretching the VB6 runtime by the time I left - plenty of direct win32 calls to do various things - foggy on the details now but VB6 was single threaded and some of that was around keeping the interface going while it did more intensive tasks, drawing some complex controls around scheduling etc. I recall it got a bit unstable in development.
When you want a thing to move to the right, you just move it to the right. Why we'd need some sophisticated abstraction for such simple task these days ?
Nowadays it's what 4 esoteric css or html/div hacks or a rewrite then testing in at least 2 web browsers and various mobile devices to find that on chrome it's too far to the right. Why can't I we move it to the right!
I loved how you can 'paint' controls, and it generates functions for you to fill in based on events. I also liked the Wizard for creating apps.
They did a Java BASIC language Jabaco to work like VB6 and compile to Java files. https://www.jabaco.org/ I think someone should take it over and remove the technical debt.
Vb6 had a RAD/wysiwyg application designer. It was trivial to use, and extend. Basic applications were kilobytes. People didn't feel compelled to spend 100$ a month to vibe code a small application that is either stuck in the browser or consumes 2gb of RAM and has 10,000 supply chain vulnerabilities and an open port.
What don't I like about modern .NET. well I just don't like .NET. it's massive, the tools are confusing, etc. F# is the only language I actually enjoy there and it's just not great performance wise. I can write C# fine, but I don't like it.
Give me a rust RAD that runs cross platform. Make sure it has an easy way to draw to canvases or good chart/drawing libraries. I'd pay real money for that. I hate fiddling with front end but I hate not having a decent one more when visuals matter. Fine it could be Go or modern c++, I don't care that much but please no .NET
It had hot code editing and a hot code editing debugger. To me, these were the main features that were interesting about VB6 vs. Delphi. Delphi won in basically every other axis (databinding, real OO, visual inheritance, etc.).
Also, while it certainly had some sharp edges, the ActiveX / COM component system (ActiveX Controls) was pretty good; you could make reusable UI blocks as a first-class citizen in the IDE. You'd just pick an ActiveX Control as your product and the thing it produced was an OCX you could just drag onto another project, where it would spring forth as a full first-class item on your form (unless the initialization failed, which in fairness it frequently did). There was a good commercial ecosystem for buying stuff, too; charts, graphs, insanely complicated data tables, it was all there for some moderate price. This culture carried over to .NET to a good extent, but it never really reached the peak it did with Visual Studio 6.
What's funny is that we have all of these capabilities today, still, we haven't "forgotten" about "how to VB6," we've just decided we can't use them because:
* Screen sizes and DPI ratios are highly variable and so there is a high demand for dynamic layout, which is difficult to express in a visual editor.
* Source control is more popular than it was.
* More front-end code is built collaboratively, so not only do artifacts need to be controllable, they need to be diffable. Nobody has really managed a diffing solution that humans like that's not lines-of-code (and trust me, they've tried, I have years worth of Thoughts about this!), so this really means "the UI designer needs to decompose to human readable line oriented statements" - which is where we went from VB6 (and Interface Builder NIBs, and so on and so forth) to newer generation UI technologies or a preference towards layout-in-code like SwiftUI.
* Cross-platform compatibility is more important than it was, and every cross-platform non-web UI framework got extinguished in the early 2000s by a combination of security becoming a real concern and Steve Jobs, to be replaced by web-based frameworks today.
the original visual basic (probably VB1.0) demonstrated and organized event-driven programming in my mind. I just "got" it. The first version wasn't that deep, but it had a noticeable impact on me.
In comparison, I remember using one of the not-so-early apple xcode versions, and it sucked. it was a disorganized mess and I don't think it has ever gotten much better.
Note - I might be comparing a "sort-of-pure" first version of something to a watered-down-corporate 5th version.
It might also be like memorable 80's movies, where if I go back and actually watch it decades later, my glowing memories might be ruined by the reality check of slow pacing, overacting and bad hair. lol.
History of Visual Basic - Shell Construction Kit for Windows 3.0, never shipped, repurposed GUI with Basic for MS Access and its form designer. see https://retool.com/visual-basic (requires js)
The quality was generally crap. The code near unmaintainable. It usually wasn't written by experienced programmers. But it got the job done. I actually felt the push away from VB6 was not a customer based decision but one that came about to personal taste of various people working at MS. VB6 was left behind much to the dismay of everyone who built some bespoke business flow using it.
Fwiw though i wouldn't want anyone to try to recreate VB6 or any low/no code style environment at this point. That ships sailed and i'm seeing non-programmers do much more impressive automations with agents at this point.
> The quality was generally crap. The code near unmaintainable. It usually wasn't written by experienced programmers.
This has nothing to do with the language.
> any low/no code style environment
Did we use the same VB6? Are you referring to the optional GUI creation tool? QT has a similar designer. There are bunches of form designers out there on the MS side.
It was my first IDE and provided simplified abstractions that made me (somewhat) understand what software developers actually do. And then curiosity took over and I caught the bug... So it will forever hold a special place.
Its the first programming language that I use. I was a junior high school student at that time, and my first app was an app to solve trigonometry homework. Maybe back then it wasn't as beautiful as I thought it is now. Or maybe now I am weighted with responsibilites. So when I look back, the memories of looking at me smiling as my app compiles correctly and solved the homework, feels so beautiful without any weight. Just a kid discovering something.
So even when the world forgets about it. My heart would always find it dear.
The thriving ecosystem of dynamic libraries that you could just link and create a Windows Vista-esque UI (AKA Aero) in an IDE built in 1998, thanks to Win32 API.
That it was easy to use, and that I was able to get it for cheap when I was in school, as compared to today. Same with VB5 & VB4. I may have a VB4 CD still lying around, somewhere. Unfortunately, things changed drastically, complexity became the norm. Honestly, I've only found Rebol to be easier to use and learn, but that is dead too.
I could barely use VB, but as a ~14 year old, I made a dialogue box that announced the computer had been hacked, stuck it in the start-up, and pranked my Mum on April 1st.
ya, i made rage and nightmare, just shared them w/ some friends. the guys that made fate x went to a nearby high school funny enough but never knew them personally.
lol i def picked up some autocad and other things that way for friends of my family. i was fortunate enough to have a neighbor give me a copy of VB3 he got from work after i got back from a summer camp learning QBASIC. the simplicity of the form designer in VB was total magic. i spent so many nights up late reading/downloading sample projects to see how people made the controls work together.
Nostalgia, not an answer: my proudest moment from high school was coding a very primitive raycasting "engine" in VB6 (that's what we had in our programming class). I had no idea what I was doing and I used some sort of layout object to draw vertical columns.
GAMBAS is a free development environment and a full powerful object-oriented
language and development platform based on a Basic interpreter with optional
just-in-time compilation, as easy as Visual Basic™ was.
Thanks for sharing this. If it has a RAD I actually might try this. I don't care what HN says, sometimes I just need to display some data with like 4 buttons without the nightmare that is modern front end. Ya I can write front end sometimes I really don't want to.
Absolutely does provide a RAD front-end. It's actually a spectacularly well-provisioned development tool with which you can build Gnome/KDE/terminal apps, and even provides a web forms engine for deploying much the same apps via HTTP.
Its only real issue is that it's a great tool for client-side-first RAD development in an era when much of software development has moved to web-side-first.
I never shipped an app in VB6 (only dabbled extensively) but I did work professionally with a huge range of UI technologies, including vanilla HTML/JS, ColdFusion, Java Applets, AWT/Swing, C++/QT, Flex/ActionScript, Objective-C/iOS/Cocoa, React/React Native... but with each of them I would pine for the ease of doing things in VB6.
I mean, I understood technically why each framework had its complexities, especially when it came to dynamically scaling to various displays. But there were so many times, especially for very simple use-cases, I'd be like "LET ME JUST CLICK AND DRAG YOU TO THE CONFIGURATION I WANT YOU TO BE GODDAMMIT."
That it made it so easy to whip up UIs and access Windows APIs, having never done it before as a 10-11 year old playing with VB6...
...which I think promptly used as a younger teen to write a custom keylogger for a friend to try and steal RuneScape accounts. Good news is I didn't know how to send emails from it, so even though it worked, it couldn't hurt anyone in the end!
It taught me what "double buffering" was, because I was (ab)using it to try and build games, but didn't understand why I was getting this horrible white flash when I cleared everything!
I never used it. VB1.0 was buggy and incomplete, which soured me on Visual Basic and Microsoft. Then they had the gall to charge $60 for the update to VB1.1 despite VB1.0 being completely unusable. Switched to Linux and open source languages and haven't looked back.
Of course these days I would never trust a 1.0, but at the time I was young and naive.
I was 17 when VB6 came out, working at a local computer store, and getting into programming but couldn't afford $500 to by the pro edition.
One day, I happened to read an article that said they were given a free copy of VB6 to review for the magazine.
My 17yo mind was blown! Hundreds of dollars worth of software given away for free? Just for writing an article?! I could do that!
Having nothing to lose, I called Microsoft's PR department and requested a copy. Told them I published a newsletter about computers and was based in Queens, NY. Their only question? Where should they send the software lol
It was literally that easy. A single phone call with zero verification about me, my newsletter, and my so-called publishing company.
And it was Enterprise edition which retailed for over $1,000. For little 17yo me!
Naturally, I kept calling for more software. Office, Windows 98/NT, Encarta... you name it.
I even started calling other companies and published a single edition of the newsletter, in case anyone asked for a copy but no one ever did. All they wanted to know was where they should send the software.
One of my favorite free items was course on VB which came on 6 VHS cassettes. The lessons I learned from those tapes built the foundation of my programming carrier.
Of course, older me understands the economics of sending people a few bits of plastic & paper in exchange for press coverage but the joy I felt getting that software in the mail still hasn't left my mind.
Good times =D
They still do this in a formal way and i promise i don't work for MS in any way; It's called Microsoft for startups and you sign up with vague details about a startup and they throw 5 enterprise visual studio keys and 5 full office subscriptions your way along with a few thousand dollars of azure hosting credits to get you hooked.
About 20 years ago the Microsoft for Startups program included the full MSDN subscription which was ~5 keys for every product they ever made. 5 keys of Windows XP, 5 keys for windows server, 5 keys for 2000, 5 keys for every variant of Office. Very popular at LAN parties and they never did recall any of those keys. Today it seems they just give you developer tools and office, not the OS.
I used it for the Azure credits. My "startup" only needed a single instance so I really didn't spend many of them. I tried to get into the longer program but the form was broken in typical Microsoft fashion and kept looping over business verification, telling me I had to input my DUNS number and incorporation letter, then forgetting and throwing it back to that step.
Back in the early 2000s the company I worked for was a small IT shop and MS software reseller and the MSDN subscription included everything. I remember setting up Windows 2000 advanced server as my home network's router.
Yeah, that's a great program. I used it many years ago when I was creating websites with .NET and SQL Server.
One of the programs I enjoyed writing the most with VB6 was a telephony capable IM program. Over dial up!
The IM portion was simple logic but the real-time voice was a challenge back then because audio compression was in its infancy. The few real-time compression libraries that existed were expensive to license and some even required royalties. Way out of my league.
At the same time, writing a compression algorithm myself was beyond my abilities. There weren't any VHS courses on that topic yet haha.
My solution was to use the recording control that came with VB6. I couldn't set the audio bitrate with that control but, if I had the recorder append the recording to an existing file, it would use the bitrate defined in that existing file.
So I created a teeny tiny wave file with 0 seconds of audio, included it with the program binary, and used a copy of it to seed & set the bitrate of each conversation.
Since they weren't compressed, the file integrity was very forgiving. I was able to pull out a chunk of data from anywhere in the audio file, put it into its own file, and it would play the extracted chunk of audio just fine.
So, that's what I did. I used the VB6 recording control with my low bitrate seed file to record their voice, had my code grab 1 second chunks of audio from that file, "stream" it to the other end of the line, write the data to disk, and use another VB6 control to play it for the recipient.
Surprisingly, the sound wasn't choppy at all. The audio quality was low, since the bitrate was in the low dozens but the conveyer belt of 1 second wave files being played back to back to back was not noticeable at all.
Ended up selling a bunch of copies.
Fun times =D
The debugger. Still the best debugger I have ever used.
You could grab the program counter/execution pointer and drag it literally anywhere, rewrite the code and keep on stepping.
I would get into a loop, realize I made a mistake, drag the PC back up above it, make a change and step back into the loop without breaking flow to compile or some other such nonsense.
Alien technology compared to most development environments even today.
Wow! That sounds amazing. I know people often compliment the debuggers for Smalltalk (Squeak/Pharo today), Common Lisp (SLIME/Sly) and Clojure (FlowStorm). Could you tell me more about the VB debugger? Are there other amazing debuggers I do not know about?
The Excel VBA debugger isn't much different. I love the VBA debugger. It is so seamless to step through code - correct in place - continue stepping to be sure the code works (split screen to see the code and its impact in the worksheet with updating turned on).
Still Smalltalk, but Dolphin Smalltalk which runs on Windows.
It was the best Windows app development too. You can write native Windows programs and it worked even better than Visual Studio for COM and ActiveX stuff.
Also, back in the day, Digitalk Smalltalk/V Win and Smalltalk/V VSE.
I second GP's sentiment. That debugger was amazing. I've never seen anything that can touch it to this day.
Tell you more: you could also just run code to do things like change variables in the immediate window while execution was paused, so e.g that example where you want to re-run some loop: first you drag the PC arrow back to above the loop as GP already described, then in the immediate window you can just run things like e.g:
To reset vars back to their initial values, or clean out buggy data, or whatever.then you can just step through the code or resume execution.
I used to use it a LOT for handling edge cases on long-running, one-off things: run the code until it hits an error, fix the error by doing some stuff in the immediate window, resume the loop without re-processing the 100K items you've already processed.
The destruction of VB with no upgrade path (the advice was to "just" rewrite your perfectly-functional 100KLOC codebase) is what pushed me away from MS, first to delphi and then to FOSS. But that VB6 debugger was IMO probably the best thing MS has ever done.
IntelliJ IDEA team has “supported” this feature for a long time but it’s hidden behind an obscure plugin. It’s awesome when it works. YMMV.
https://plugins.jetbrains.com/plugin/14877-jump-to-line
man i just wish hotswap worked reliably on the JVM w/o me needing to set up some janky DCEVM or JBR or other such nonsense.
I came here to say the same. Visiual Studio finally got this and it's called 'Edit and Continue'. IDEA can invoke a Java feature to reload classes and move the point of execution. Neither are as reliable as VB6 was.
> What specifically did you love about VB6?
I taught my daughter to program using VB6 -- long after it was already obsolete. It's very easy to get started and build a GUI application with very little ceremony. You can develop your entire UI without a single line of code and run it. Only then did you need to double-click on components and start adding functionality with code.
But actually using it for "real" development was not as enjoyable and I did it for years. If you only wanted to make a static fix-sized application then it's ideal. But if you wanted your application to adjust to the size of the window (and therefore the resolution of a monitor) you had to wire all that up yourself. Painting controls to specific pixel sizes is an obsolete concept.
> What do you find frustrating about modern .NET, C#, and Visual Studio that VB6 didn't make you fight?
C# is superior language to VB6 and WinForms is a superior way to do an equivalent style of UI development. While the VB6 designer was a smoother experience than the Visual Studio designer it was a much more limiting experience.
But if were to put my nostalgia glasses on, I think what is frustrating about .NET GUI development that never seemed frustrating in VB6 was just the ease of getting it do what you want. At the core, WPF/XAML/whatever is a better way to do a GUI layout -- Instead of pixels you place things in stacks, grids, and panels. You have margins and padding. But styling your GUI is so much more complicated and it descends into this overly complex impossible to understand system that makes HTML and CSS look good. This was not a problem in VB6. The GUI interaction with code is also more complicated with magic static property incantations that would never exist in VB6.
Code-behind was the bee’s knees.
You open up the GUI editor, drag a button onto the screen from the toolbox, give it a name/id, and double click on it which takes you to the source code file where a “buttonId_click” handler is auto created for you. Super easy to create simple GUIs without much work while still wiring together the bits that need code.
There was certainly some rough edges and I don’t know how well the workflow would have adapted to responsive design but line of business apps in controlled environments it was so powerful. VB6 and Delphi were like nothing else we have today (at least that I’ve seen).
Windows Form Designer in Visual Studio still works in that same way? This was one of the least differentiated things, really; while XCode’s interface building tools have always been clunkier they also offer the same functionality too.
Honestly the biggest problem is the entire environment is very VCS hostile in a hard to crack way.
I've had some success getting a bunch of scripts to export MS Access database structures, but it takes over an hour to run and requires some post processing clean up so it's not really a great <feature> -> <commit> cycle.
Honestly I'd desperately like a similar experience for GTK development - a few things seem to exist, but they've never really got me building something as quickly as VB6 did.
EDIT: I mean thinking about it, the way people are using AI programming tools feels very much like a desire to actually get the VB6 - no data flow model or weird pipeline or whatever rendering BS, just "I want a control here and here's what it should do". I remain pretty sure that AI is a very expensive solution to the problem of we've been building the wrong tools and libraries for years.
The ability to rapidly build apps was amazing as a kid to learn, and I think Linux needs something similar so that small business applications can be built quickly and cheaply.
Making real, complex components, and drag dropping them into other components. Designing a UI with all your components and zero layout code, just positioning them visually. To anyone who grew up with VB6, web development feels like a serious regression.
I will probably die on this hill with you. Let me please complete a few bucket list items first though.
For the life of me I cannot figure out why we do not have a successful Windows Forms-like toolkit for the web that took off.
Building the UI was superfast. Wiring the logic was somewhat painful but manageable. But you did not really need more than that to build CRUD apps. For everything else, you had C/C++ and the Win32 API.
I am a huge fan of keyboard-only navigation and you could achieve a large part of the extremely rapid data entry methodology of DOS UIs of the 80s and early 90s with considered key-handing. You never even had to look at the screen for the most part; only at the document in front of you.
Microsoft killed it with the move to DOTNET. VB.NET was a different beast, and C# was a superior language. But it was never the same. I moved to web-uis in the late 2000s. Painfully slow way of writing business apps, but the complexity can be managed if you can reuse templates/components.
I could type ~four lines and an alert box response from a visual form.
For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.
That said I also lament the death of WYSIWYG-style HTML authoring tools. This is I think the same affliction that caused programmers to prefer writing code to build UIs rather than drawing it interactively.
Interactive UI design tools are cool when you're not a programmer, an inexperienced programmer, or lack the imagination necessary to create new abstractions.
UI preview tools are incredibly useful, hot reloading when doing UI work is, again, incredibly useful.
What nobody needs in their life is to meticulously hand place elements and align them only for the auto-resizing logic to fuck things up.
You want good abstractions which let you easily and quickly define UI elements and to define new composable widgets. So that you can declare in your code details of how things should be aligned with respect to each other, and leave final layout to more code which, if you are lucky, you might not even need to write.
For an example, check out jetpack compose. It's not completely flawless, but it truly isn't bad.
Yeah this is the kind of programmer’s thinking that led to complexity that is present by default and sometimes not warranted.
> meticulously hand place elements and align them
You don’t need as much meticulousness as you imagine. Have you tried placing some text boxes in Keynote or PowerPoint and hand aligning them?
> for the auto-resizing logic to fuck things up.
Auto-resizing is often unnecessary during rapid prototyping. Even in prod, even if you are developing internal apps in an enterprise environment, it’s still not necessary. Make your window non-resizable if you are targeting native, and set a fixed viewport <meta> for web apps.
> define new composable widgets
The kind of people who are enjoying VB6 don’t need new widgets let alone composable widgets. Just use whatever widgets that are builtin.
Basically your entire comment is describing the kind of complexity that I said was not always necessary.
You don't need to be meticulous if you want your software to look like a 5 year old drew it, which maybe you don't care about.
But even so, hand placing 20 labels, editing them to say the right thing, then hand placing the entries, making sure the tab order is correct, you don't want to be doing that by hand. And it gets worse if you need to edit this in the future.
I am not saying this because I think it sounds stupid, I am saying this because I spent 4 years at an organization where this was the only method to do things and I _know_ for a fact that it is stupid and tedious. Given that we had the list of fields, if the language wasn't hot garbage, and the organization wasn't stuck in the past, we could have made it so 99% of fields on 99% of forms could have been placed automatically and cleanly saving literally months of development time in total.
We needed a complex UI for something which could not be done natively using this technology and I proved this to be true when I made a data driven UI in a fraction of the time it was taking to iterate on the legacy version which had 1/10 of the features.
It was amazingly easy to interact with other apps via OLE Automation (aka, COM Automation).
About 25 years ago I wrote a program that would look for requests (in the form of XML files) from the custom software on our Solaris system, then based on the contents of the request it would fire up Word, load up the appropriate letterhead and body template, fill in the required information (e.g., client name/address, caseworker name, etc), print two copies (one for the file, one with an envelope to send out), and store the completed document in the client's folder on the fileserver.
This program saved an incredible amount of time and let the office typing pool concentrate on typing dictated letters instead of filling out templates.
Without the magic of OLE Automation letting me use Word programmatically from my application, creating this would have been basically impossible.
Man, I wrote a lot of things that used OLE. Microsoft was heavy on building things like that. I wrote a program that would load up patient data and build referral letters for physicians and send them via electronic fax. It freed up like three admin staff that were dealing with that before and hating it.
The funny part was some of them must have been so seldom used that I'd run into problems and uncover bugs that were very quickly apparent, and I'd call MS support and they had never had them reported. I sometimes wondered if I was the only person that used them. WebDAV for Exchange was another on of those things.
I remember calling MS support, vaguely related to this project.
For example, if the Edmonton office needed to send a welcome letter to a new client, the flow might look like this:
1. Create a new file based on X:\Templates\EdmontonLetterhead.dot
2. Insert the contents of X:\Templates\A01-ClientOnboarding.doc
3. Fill in fields. Usually stuff like client name, caseworker name, etc.
4. Click the links in the file (e.g., there'd be a link to X:\Templates\EdmontonContactNumbers.doc), printing each document and deleting the link from the final document.
5. Save the file to the client's folder (e.g., S:\Clients\000123-Jane Smith).
6. Print a copy for the paper file, a copy to mail out, and an envelope.
We called Microsoft Support because when changes were made to the template documents it would update the links to relative paths. These don't work with our flow because the document either isn't saved, or is saved on a different network drive.
Microsoft Support wasn't able to help us. They understood exactly what we were doing, exactly what the problem is, but they weren't able to fix it. That's just how Word works, it didn't have a setting to force absolute links.
I ended up writing another VB6 program, using OLE Automation to get Word to do the work, which opened each document, saved it to a local drive (which turned the relative links into absolute links), then copied it back to the shared drive.
Indirectly introduced me to programming as my dad was obsessed with it growing up. He was a hobbyist with zero formal training, working a completely unrelated job, and still made a ton of money selling tailor made admin software to all kinds of small businesses. Really a testament to how good VB6 was.
In the windows of ecosystem for basic business apps, it was so way to build things. I know Microsoft made it, so it has an unfair advantage vs languages like Delphi, but compared to C++ it was so easy and fast to build basic working apps.
My favorite thing was to watch a guy who was in tech support and frustrated with our overly complicated process build something on his own that solved a major problem we had. This was by himself. It was amazing. Low barrier to entry, and he taught himself enough to fix his issue. The vp called me in to look at it and make sure it was ok, and I was like “a couple things here or there but it was more than good enough to function day to day.” Never would have happened with lower level languages.
There a good chance of this type of citizen developer coming back with AI. Google AI studio will automatically add a Firebase backend to vibe coded apps when needed.
Some of the worst code I have ever seen was written in VB. Some of the best tools that solved awful business problems was written in VB.
VB6 was what sparked my interest in programming. My final project in my programming class was a menu based dungeon crawling game with turn based combat. I was obsessed with Diablo on PC at the time and I just wanted to make anything that remotely resembled it. So you had a town where you could buy equipment and magic spells and then you would go into the “dungeon” and you would fight a selection of random monsters until you got to the boss.
I’m sure I would recoil in terror at the code I wrote but I owe a lot to VB6.
My first job was VB6 and I really enjoyed working on it. It was pretty late in it's life - .NET had just come out when I started. The existing program I was working on was pretty complex though. I spent a year rewriting the database layer (well, it wasn't a layer when I started but it was by the end) from an old cursor / file based system to use SQL server. That extended the lifetime of the product by quite a margin as it had been struggling with bigger customers.
It was really stretching the VB6 runtime by the time I left - plenty of direct win32 calls to do various things - foggy on the details now but VB6 was single threaded and some of that was around keeping the interface going while it did more intensive tasks, drawing some complex controls around scheduling etc. I recall it got a bit unstable in development.
Website for the software is still there too not sure if its still used, I left in 2007. https://www.redrabbit.uk.com/oli/oli_overview.htm I drew those little pinball people in inkscape.
When you want a thing to move to the right, you just move it to the right. Why we'd need some sophisticated abstraction for such simple task these days ?
Nowadays it's what 4 esoteric css or html/div hacks or a rewrite then testing in at least 2 web browsers and various mobile devices to find that on chrome it's too far to the right. Why can't I we move it to the right!
I loved how you can 'paint' controls, and it generates functions for you to fill in based on events. I also liked the Wizard for creating apps.
They did a Java BASIC language Jabaco to work like VB6 and compile to Java files. https://www.jabaco.org/ I think someone should take it over and remove the technical debt.
Vb6 had a RAD/wysiwyg application designer. It was trivial to use, and extend. Basic applications were kilobytes. People didn't feel compelled to spend 100$ a month to vibe code a small application that is either stuck in the browser or consumes 2gb of RAM and has 10,000 supply chain vulnerabilities and an open port.
What don't I like about modern .NET. well I just don't like .NET. it's massive, the tools are confusing, etc. F# is the only language I actually enjoy there and it's just not great performance wise. I can write C# fine, but I don't like it.
Give me a rust RAD that runs cross platform. Make sure it has an easy way to draw to canvases or good chart/drawing libraries. I'd pay real money for that. I hate fiddling with front end but I hate not having a decent one more when visuals matter. Fine it could be Go or modern c++, I don't care that much but please no .NET
It had hot code editing and a hot code editing debugger. To me, these were the main features that were interesting about VB6 vs. Delphi. Delphi won in basically every other axis (databinding, real OO, visual inheritance, etc.).
Also, while it certainly had some sharp edges, the ActiveX / COM component system (ActiveX Controls) was pretty good; you could make reusable UI blocks as a first-class citizen in the IDE. You'd just pick an ActiveX Control as your product and the thing it produced was an OCX you could just drag onto another project, where it would spring forth as a full first-class item on your form (unless the initialization failed, which in fairness it frequently did). There was a good commercial ecosystem for buying stuff, too; charts, graphs, insanely complicated data tables, it was all there for some moderate price. This culture carried over to .NET to a good extent, but it never really reached the peak it did with Visual Studio 6.
What's funny is that we have all of these capabilities today, still, we haven't "forgotten" about "how to VB6," we've just decided we can't use them because:
* Screen sizes and DPI ratios are highly variable and so there is a high demand for dynamic layout, which is difficult to express in a visual editor.
* Source control is more popular than it was.
* More front-end code is built collaboratively, so not only do artifacts need to be controllable, they need to be diffable. Nobody has really managed a diffing solution that humans like that's not lines-of-code (and trust me, they've tried, I have years worth of Thoughts about this!), so this really means "the UI designer needs to decompose to human readable line oriented statements" - which is where we went from VB6 (and Interface Builder NIBs, and so on and so forth) to newer generation UI technologies or a preference towards layout-in-code like SwiftUI.
* Cross-platform compatibility is more important than it was, and every cross-platform non-web UI framework got extinguished in the early 2000s by a combination of security becoming a real concern and Steve Jobs, to be replaced by web-based frameworks today.
the original visual basic (probably VB1.0) demonstrated and organized event-driven programming in my mind. I just "got" it. The first version wasn't that deep, but it had a noticeable impact on me.
In comparison, I remember using one of the not-so-early apple xcode versions, and it sucked. it was a disorganized mess and I don't think it has ever gotten much better.
Note - I might be comparing a "sort-of-pure" first version of something to a watered-down-corporate 5th version.
It might also be like memorable 80's movies, where if I go back and actually watch it decades later, my glowing memories might be ruined by the reality check of slow pacing, overacting and bad hair. lol.
History of Visual Basic - Shell Construction Kit for Windows 3.0, never shipped, repurposed GUI with Basic for MS Access and its form designer. see https://retool.com/visual-basic (requires js)
The quality was generally crap. The code near unmaintainable. It usually wasn't written by experienced programmers. But it got the job done. I actually felt the push away from VB6 was not a customer based decision but one that came about to personal taste of various people working at MS. VB6 was left behind much to the dismay of everyone who built some bespoke business flow using it.
Fwiw though i wouldn't want anyone to try to recreate VB6 or any low/no code style environment at this point. That ships sailed and i'm seeing non-programmers do much more impressive automations with agents at this point.
> The quality was generally crap. The code near unmaintainable. It usually wasn't written by experienced programmers.
This has nothing to do with the language.
> any low/no code style environment
Did we use the same VB6? Are you referring to the optional GUI creation tool? QT has a similar designer. There are bunches of form designers out there on the MS side.
It was my first IDE and provided simplified abstractions that made me (somewhat) understand what software developers actually do. And then curiosity took over and I caught the bug... So it will forever hold a special place.
Its the first programming language that I use. I was a junior high school student at that time, and my first app was an app to solve trigonometry homework. Maybe back then it wasn't as beautiful as I thought it is now. Or maybe now I am weighted with responsibilites. So when I look back, the memories of looking at me smiling as my app compiles correctly and solved the homework, feels so beautiful without any weight. Just a kid discovering something.
So even when the world forgets about it. My heart would always find it dear.
The thriving ecosystem of dynamic libraries that you could just link and create a Windows Vista-esque UI (AKA Aero) in an IDE built in 1998, thanks to Win32 API.
That it was easy to use, and that I was able to get it for cheap when I was in school, as compared to today. Same with VB5 & VB4. I may have a VB4 CD still lying around, somewhere. Unfortunately, things changed drastically, complexity became the norm. Honestly, I've only found Rebol to be easier to use and learn, but that is dead too.
i loved making AOL 'hacking' tools as a kid in VB3/5/6. faders, stuff to scroll ascii art to chat rooms, etc.
I could barely use VB, but as a ~14 year old, I made a dialogue box that announced the computer had been hacked, stuck it in the start-up, and pranked my Mum on April 1st.
Fate X 3.0
ya, i made rage and nightmare, just shared them w/ some friends. the guys that made fate x went to a nearby high school funny enough but never knew them personally.
Amazing
So many fond memories of that time.
I remember getting VB3 in 300 emails from an AOL chat room.
lol i def picked up some autocad and other things that way for friends of my family. i was fortunate enough to have a neighbor give me a copy of VB3 he got from work after i got back from a summer camp learning QBASIC. the simplicity of the form designer in VB was total magic. i spent so many nights up late reading/downloading sample projects to see how people made the controls work together.
Nostalgia, not an answer: my proudest moment from high school was coding a very primitive raycasting "engine" in VB6 (that's what we had in our programming class). I had no idea what I was doing and I used some sort of layout object to draw vertical columns.
I did a lot of VBA, and the integration of the whole experience was unmatched.
From TFA: > Microsoft has launched seven UI frameworks since VB6. Why? Pick a horse and ride it.
That was my first love. Just so easy to get something working with a visual interface. Nothing has ever come close.
I can’t believe they ruined it.
building a UI was so easy.
VB6 was the original vibe coding! Drag a few GUI controls on a window panel, double click to write some basic code, boom
Wrote a time keeping/billing system in Foxbase. Converted to FoxPro when windows arrived. Eventually ported to VB.
1. It wasn’t the web
2. Visual designer
3. Encapsulated components, code on event driven
4. Common points of interaction, composition and extension.
5. It wasn’t the web
2.5. It wasn't the web
3.5. It wasn't the web
RENUMBER 1,1
LIST
Getting paid to write code in it.
Obligatory: if using Linux and want the open source equivalent:
https://gambaswiki.org/website/
GAMBAS is a free development environment and a full powerful object-oriented language and development platform based on a Basic interpreter with optional just-in-time compilation, as easy as Visual Basic™ was.
Thanks for sharing this. If it has a RAD I actually might try this. I don't care what HN says, sometimes I just need to display some data with like 4 buttons without the nightmare that is modern front end. Ya I can write front end sometimes I really don't want to.
Absolutely does provide a RAD front-end. It's actually a spectacularly well-provisioned development tool with which you can build Gnome/KDE/terminal apps, and even provides a web forms engine for deploying much the same apps via HTTP.
Its only real issue is that it's a great tool for client-side-first RAD development in an era when much of software development has moved to web-side-first.
Enjoy
I never shipped an app in VB6 (only dabbled extensively) but I did work professionally with a huge range of UI technologies, including vanilla HTML/JS, ColdFusion, Java Applets, AWT/Swing, C++/QT, Flex/ActionScript, Objective-C/iOS/Cocoa, React/React Native... but with each of them I would pine for the ease of doing things in VB6.
I mean, I understood technically why each framework had its complexities, especially when it came to dynamically scaling to various displays. But there were so many times, especially for very simple use-cases, I'd be like "LET ME JUST CLICK AND DRAG YOU TO THE CONFIGURATION I WANT YOU TO BE GODDAMMIT."
That it made it so easy to whip up UIs and access Windows APIs, having never done it before as a 10-11 year old playing with VB6...
...which I think promptly used as a younger teen to write a custom keylogger for a friend to try and steal RuneScape accounts. Good news is I didn't know how to send emails from it, so even though it worked, it couldn't hurt anyone in the end!
It taught me what "double buffering" was, because I was (ab)using it to try and build games, but didn't understand why I was getting this horrible white flash when I cleared everything!
I learned so much with VB6 haha
VBPJ, Wrox books, and VBA.
drag-and-drop gui builder sean greasley's video tutorials
I never used it. VB1.0 was buggy and incomplete, which soured me on Visual Basic and Microsoft. Then they had the gall to charge $60 for the update to VB1.1 despite VB1.0 being completely unusable. Switched to Linux and open source languages and haven't looked back.
Of course these days I would never trust a 1.0, but at the time I was young and naive.
Linux came out the same year. How was it better?
[dead]
[dead]