RAD Basic – Compatible with Visual Basic 6 projects
radbasic.dev
radbasic.dev
I know that many people are going to say I'm wrong and that VB6 was a cancer, but hear me out:
o Drag and drop GUI designer
o action oriented language
o surprisingly advanced integrated IDE
o It was easy, simple and reasonably fun to learn
I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them.
just give me drag and drop, and ideally a python backend
I always considered .NET a step backwards, versus doing something similar to what Borland was doing with Delphi/C++ Builder, meaning C# and VC++ should have provided better tooling based on COM, and then follow up with VB7.
Ironically, when they tried to actually do that, with WinRT, they messed up the whole execution.
I used it for decades when I was young, and I have never again used anything that was as good, as simple, as precise and as feature-complete. Debugging in VB6 was incredible. An incredible feat that I'm not sure has been repeated since? Perhaps the debugging capabilities of MSVC has caught up these days, in which case, kudos to them.
Maybe something exists today in the form of webdev? I wouldn't know as I'm stuck in the deep-end (backend).
I have used .NET the last few years. I made a full desktop application for someone, and I also wrote a map/level editor for a game in it. I have to say that I like C# a lot, but I don't like the editor, I don't like the graphical construction source file, because it's so easy to break your GUI. And I also hated the fact that drawing was slow on .NET no matter how hard I tried to make it fast.
Debugging in .NET is just as it used to be on VB6, not sure what you would still be missing from those days.
As for breaking the GUI, it wasn't as if frm files were foolproof.
Point is thought this was there out the box with VB.
Apparently last modified 8 days ago, with a history of infrequent but steady commits.
Caveat: Unfortunately only talks about Windows.
> just give me drag and drop, and ideally a python backend
There is Boa Constructor[0] which is a very Delphi/C++ Builder inspired IDE that uses Python and wxPython for the GUI. Sadly it seems to be abandoned with the last release being in 2005.
For a modern (or at least still under active development) approach i'd suggest Lazarus[1], which is essentially a cross platform (works on Windows, Linux, Mac and a bunch of other OSes with Win32, Gtk1/2/3, Carbon, Cocoa and even Amiga GUI backends) open source Delphi written in Free Pascal. To see it in action, here is a video i made with it 7 years ago, making a 2D tilemap editor (the IDE is mostly the same, there have been a couple of minor changes but not anything big)[2].
[0] http://boa-constructor.sourceforge.net/Screenshots/
However it severely missed multi threading. You could make things semi -multithreaded by making sure everything was event-based but there were still so many calls that would lock the UI.
But yeah DoEvents ftw.
VB.Net IMO was a step back.
VB wasn't some great language, but the entire system was very productive and worked well with other MS technology of the time like MSSQL and Access.
Or as I mention on another thread, .NET should have been what was later WinRT, by improving COM tooling and that was it, but now we are 20 years too late to fix that.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
However, there wouldn't have been much hope for a cross-platform .NET if it were COM based... and cross-platform is one of the things keeping .NET relevant - Personally, I was (reluctantly) about to ditch .net until that.
Also see MAUI versus Swing/Qt, one needs to go for Uno/Avalonia instead.
If I'm quickly knocking up a small GUI utility then the drag-drop building nature of a vb.net forms app is a real time saver - but in contrast you have more flexibility if you build controls via code like C# does.... horses for courses really.
Bizarrely, I've recently started exploring using C# as a CGI back-end via .NET core on Linux... for the simple reason that I can. Apparently it can be quite performant.
Roslyn for VB.NET still gets more love than F# across .NET workloads.
Now it is true that they could rename CLR into C# Language Runtime, given the extent of effort that C# gets, versus VB.NET, F# and C++/CLI.
I’ll always have an affinity for Objective-C but obviously a C-based language with pointers everywhere came with a learning curve. Swift could have solved this but the APIs were not stable at the time (I used it around 2.1) and the compiler sometimes would choke with somewhat hard to diagnose errors. It seems Interface Builder and Storyboards are getting replaced by SwiftUI these days (inspired by Elm/React).
But as another commenter mentioned, it declines with scale; this is why Facebook spent so much resources into trying to make webapps on mobile work, because their application size and compile times just got out of hand. It's possibly also a reason why they split off Messenger from the main app at some point.
:(
Last modified March 2014: https://github.com/rebol/rebol
And that's still just REBOL/Core, not REBOL/View.
The merge request will be a little challenging if someone dares to try : "This branch is 6513 commits ahead, 14 commits behind rebolsource/r3:master"
This is all I was trying to convey. Yes, it's not getting as much love and care as it deserves.
Yeah, I didn't know about regular expressions at the time.... (facepalm) ...I was really just writing these things in straight up VB.
I'm not knocking what you were doing; I'm sure you had the sense to use regex or something. I did not. lol
https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...
Also, modern Free Pascal has OOP classes and methods if you like these. If you run software made in Free Pascal like Cartes Du Ciel and them some Java one like Sweet Home 3D, the first one will run circles on snappiness and speed over the second one.
IDK how Java can be appreciated, most of its desktop software runs far worse than AMSN over TCL/TK in early/mid 00's under an Athlon.
The predecessors of Free Pascal had those since the 1980s, it isn't particularly a “modern Free Pascal” innovation.
FWIW AFAIK Free Pascal got its OOP stuff from Delphi (almost, but that is historical details) which in turn is an extension to Turbo Pascal's OOP stuff introduced in TP5.5 which in turn was based on Apple's Object Pascal extensions that (AFAIK) were designed with Niklaus Wirth's help during the late 80s. The OOP functionality Free Pascal has and mainly uses started with Delphi 1 though (which already had things like properties and reflection - this is how the form designer worked) in 1995.
Of course i wouldn't call those modern any more than i'd call structured programming elements like 'procedure' and 'while' modern in 1995 :-P.
1. the inconsistent padding around the focus rectangle (which even touches the outer border on one side!) on that toolbar button to the left in the screenshot,
2. that whoever redesigned the Metal theme some years ago decided to make the selected tab visually connect to the content by using the same background color (good idea, by itself) but apparently didn't notice that every application wraps the content in a widget that draws its own background, resulting in what you see on the screenshot: the tab color continuing for a few pixels into the content and then awkwardly bumping up against the content's background without a border.
Also, IntelliJ IDEA has to implement its own menu bar because Swing's built-in one can't do submenus properly.
[1] https://upload.wikimedia.org/wikipedia/commons/c/cc/Gui-widg...
I still think there is a really successful app ecosystem waiting to be built that is semantically similar to VB6 + Access but built with a more modern stack like SQLite + Electron + TypeScript.
When you consider the mainstream alternatives back then, by the time you've got the message-loop boilerplate working... in VB6 you've already created a functioning form with a database connection.
When you consider the mainstream alternatives back then
Folks always seemed to rave about Delphi. That seemed like the "grown up", "better" version of VB, though I never used it.
But yeh, Delphi was much better than VB (like how turbo pascal was better than QBasic), however it was more of a niche environment used mostly by independent vendors making consumer apps.
There is a reason why we still have Delphi conferences over here.
I think Angular has a way to intercept http calls but you would need to build a translation layer. None of this is obvious to someone picking this up for the first time.
The whole paradigm is a hack that requires a very experienced dev to navigate.
Maybe I'm missing something.
That part won't change AFAICT, but you can imagine a reasonable abstraction over it as part of a "batteries included" ecosystem in which events from the UI (button press, keyboard capture, scroll event, etc) are mapped seemlessly via configuration to user-defined functions that happen to run within the nodejs process with an SDK that allows developers to interact back w/ the UI in a similar manner. Resulting in a developer experience very similar to what you got with VB6.
It encouraged a load of professionals who, though talented in their own field, should never have been near an IDE, to "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this."
... in my experience.
Isn't a GUI mockup one of the best ways to come up with a consistent set of requirements for software? At least by making the mockup in VB rather than drawing it on paper, it can serve as a start for the actual GUI part of the program.
The people I'm referring to didn't realise that such esoteric things as "requirements" or "prototype GUIs" were a thing, and just handed over a ball of spaghetti for us to support.
[1] https://github.com/mhammond/pywin32/
[2] https://www.amazon.com/Python-Programming-Win32-Windows-Prog...
So he had this good idea of creating a simple application that would allow him to enter his data in the computer without having to move his eyes out of the microscope. He did this with a keyboard numpad and a quick VB6 prototype (which I finished the coding part for).
Those are the kind of great small programs that VB5/6 allowed people to do. And there were a lot of those small utilities all over the internet. No paywall, no ads, no subscriptions. I miss those days of creativity and sharing for the sake of it. Now the internet is all just SEO, ads and greed. What happened to kids/young Millenials and Zs?
There's a very intuitive drag-drop GUI designer for GTK+, namely Glade. Sadly, it was abandoned as GTK+ transitioned to 3.x and 4.x. So the only supported workflow now is laying out your GUI in code.
The intuitive "action-oriented" language should not be underestimated either. Though I assume it could be made idiomatic even in modern languages, by leveraging their support for the async programming model.
More like Gnome and RedHat. In the BSD-y world and people akin on GNU (Alpine, Hyperbola, Parabola...) people loves the CLI and some stuff like TCL/TK or even Perl/Tk / Perl/GTK2. And the tools work well and fast enough.
1. https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...
For example when you drag and drop toolbar items onto your form it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget so after a while just looking at the code you started to get Label1.Text = "blah". I seen that in just about every project and one I remember done by a Chinese dev with poor English he left all the controls with the boilerplate names and so it was impossible to reason about what was happening.
Componentisation was also a problem in that you tended to have all your code connected directly to the form. So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file.
Separation of concerns was a problem in that again the code was attached to a form so you found UI code mixed in with proper business logic. This becomes very messy over time and tends to create very large event handlers the more a project grows.
It was basically impossible to unit test which makes refactoring very risky. On large projects what generally happens then is that no one is willing to refactor anything as they don't really know all the scenarios. Over time this leads to code rot.
It only ran on windows, while I'm sure there are ways to make it run under linux the main support was for windows and most orgs stuck to that. This ties in with the fact that you had to install the thing on your P.C. businesses hated this and still do. Things like people uninstalling it or problems locally with permissions and suchlike were rampant. Similarly updating was a pain on large projects you have to have something central install and do the update.
Scalability was problematic on large projects especially since the forms app would often directly connect to the database. That meant the more user = more connections which on large project meant problems. The "solution" was some service or api which the app talked to but at that point it's no longer vb6 doing the heavy lifting and it's just become a UI.
Small little tools or prototype apps was were vb6 shined brightly.
Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent.
> it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget
The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome.
> Componentisation was also a problem in that you tended to have all your code connected directly to the form.
Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.
Just a small quibble - you would typically move shared-code into seperate module files.
The other biggest challenge we had was when trying to build a larger solution that worked with COM dependencies amongst multiple projects, you would occasionally have to do a clean-build which break binary compatibility (don't forget to do a registry cleanup!), and that mean "compiling" your tree manually, from the base level components upwards. That got much easier if you could get your hands on a Microsoft MCS tool called, VBBuilder. (I can't remember if it ever was available for open/free download)
If anything some aren't even issues but features - e.g. being able to have code attached directly to events speeds up development a lot and if you need to put it somewhere else (IME the case where this isn't necessary is more common than the case where it is) you can simply have your handler call some method in another file so you can keep those separate.
At least there's still Lazarus.
End project was to build a control/monitoring application for an electric motor.
Sure, there were some hard limitations compared to "modern" GUI design tools, but for the domain (industrial machines), these things worked just fine.
This is actually a funny use-case for .NET as anything low-level and hardware oriented tended to be harder to do without the libraries, which (if they existed) weren't .NET
Not sure what the hard limitations were that you refer to; VB.NET / C# where always the easiest way to get a windows GUI (WinForms) app running. For industrial computing solutions tended to use Windows CE and Windows XP with COM apps.
Motor - VFD - PLC - OPC server - OPC client
The .NET Application worked purely as a GUI read/write data from/to the PLC.
But of course there were other things involved, like database programming, API service, webdev. We made a very, very simple API in ASP.NET I think, and some website in PHP which would just plot the various motor values.
Then along came VB.NET, and I switched to Python. The big epiphany for me is that I no longer lay out GUI's. I let Tkinter lay them out for me. My realization is that anything I do deliberately other than just a simple vertical arrangement of widgets is likely to make things worse. What VB6 was letting me do, was to create GUIs that are no better than most industrial Crapware.
I've also learned for the simplest things, not to make a GUI at all. People can modify some entries at the top of a text script and run it in the interpreter. At first glance, you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software, whether it's something I wrote, or a professionally written app.
I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state.
People can modify some entries at the top of a text script and run it in the interpreter.
That is significantly harder for most people than just clicking on buttons.
That's certainly possible. My job has changed since then, so I'm no longer in a position to write that kind of stuff any more. My present "clientele" tolerates the Python ecosystem well enough.
This is an advantage that the Web browser has that is sadly under-appreciated and under-utilized (even from Web developers).
Many traditional desktop GUIs and modern Web applications would be better suited for their audience if they were instead executable SOPs. Think: a manual for how to use a given system, except at the point in the instructions where it's describing a certain feature, or where it calls for a certain step to be performed, there is some on-screen affordance that allows the reader to take care of it right there—right at the spot they're already looking at.
Some programming notebooks try to do something like this, but they usually get it wrong.
Raskin seemed to have the same epiphany (albeit pre-WWW) and wrote about GUIs being a "dead end".
`designer` does this. Instead of assuming Qt doesn't come with a RAD drag & drop, you could have spend two minutes to verify.
> python backend
Relevant: https://xkcd.com/1053/
All the good VB6 parts, plus a better language for any code needed.
Ditto database work.
The client/server paradigm is the corpus calloscotomy (split brain surgery) of our industry.
Begetting ORMs, LINQ, ActiveRecord, chaotic mutant query language templating system of the week, and other well-intentioned but ultimately detrimental efforts. All being unwitting attempts to regain what was lost.
Famously described by Ted Neward's "Vietnam of Computer Science" rant. http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... Though Neward somehow avoids identifying the root cause (client/server).
FWIW, I did a bunch of R:Base, dBase/FoxPro, Access, and FileMaker (ahem) projects, back in the day. Sadly never had an excuse to use Paradox in anger, which I understand was the pinnacle for "workgroup" apps (LAN-based, meaning shared access thru file locking).
That said, both Delphi and VB (and VC++ to some extent) were IMHO far superior tools for RAD building of GUI apps than any web-oriented tool that I've later seen. In web development we're still in Turbo Pascal and Quick Basic days, we've got good IDEs and helpers but you still have to write everything by hand.
No, that wasn't the timeline. Visual Basic came out in 1991. Borland Delphi was +4 years later in 1995. (Borland Turbo Pascal for Windows was 1991 but Microsoft VB's internal product development codename "Thunder" was already started in 1990.)
Visual Basic (especially the GUI forms IDE paradigm and VBX components) was built on earlier ideas in 1988 by Alan Cooper : https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic
https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef...
(Try an incognito window if Medium blocks you.)
That article has a few inaccuracies too, but as the events were over 30 years ago, this can be forgiven.
Read Alan's article and then come back for this followup.
Alan mentioned the "gizmos". He actually originally called them "waldos", named after these:
https://en.wikipedia.org/wiki/Remote_manipulator
I couldn't make sense of that name, so I suggested "gizmo", which seemed fun and more descriptive. That name stuck - for a while. Microsoft later renamed them to "controls". How boring!
I also developed the "gizmo interface", which Microsoft renamed to VBX. (They were really not into fun names at the time.)
It has sometimes been said that Bill Gates was the one who insisted that VB have an extension interface like this. The truth is more subtle. We had the gizmo interface all along. It was obvious that we would need it for our own gizmos, and that we should allow other developers to build their own gizmos.
Apparently, the Microsoft team that turned Ruby+Basic into VB was going to keep the gizmo interface private and only let Microsoft developers use it, at least at first to save time on the schedule. Bill quite rightly saw the power of exposing the interface to outside developers and decided to make it part of the product - just as we had planned all along.
And I built the "event arrows" that Alan mentioned. He originally called an event a "flimsy" (a British term for "lightweight paper used especially for multiple copies"). I couldn't make sense of that name either, so we kicked it around and settled on "event".
This left a problem of what to name the act of sending an event from one gizmo to another. I was familiar with the term "trigger" from SQL, but that didn't seem quite right, and we were into fun names. But I couldn't think of one!
At the time, when I got frustrated with a coding or naming problem, I had a habit of firing rubber bands at my IBM Monochrome Display to shake up my thinking. (Don't try this with a modern flat panel.)
That didn't give me any ideas.
So I decided to fire up a doobie and see if that would help.
As I flicked my lighter and looked at the fire, it all came together:
Fire a rubber band. Fire up a doobie. Fire an event!
AMA, and I will see if I can remember...
> Just WTF were those Microsoft guys smoking when they designed this shit?
<g>
Now, Tcl/Tk... which lets me just code up a GUI declaratively, feed it to a REPL, and get results that look... less like ass... that's a JATO bottle for UI productivity that's unmatched by anything.
When I was still in high school, I used to hack GUI projects and games in the evenings. The culmination of that was a full blown space shooter game using DirectX7 [0] (still runs on Linux) and a TCP/IP chat + canvas draw application that I had installed in the computer room at my school. Fun times.
I can see that the tooling might've been great and all, but the language is seriously just horrible. And as for VB.NET, my experience was that the bearable parts were the ones it inherited from the .NET and C#. It might've been fine for prototypes, but at least IME prototypes never stay that, they get swamped with features and a few years down the line you have a Frankenstein's monster of badly thought out features struggling to interact with each other... except with VB, all of that is mixed in a soup of On Error Resume Next. I don't really see how anyone would put up with that in 2022
[0] https://github.com/Soldat/polyworks/blob/37aaf471646fe4773e6...
The language wasn't that bad. Classes without inheritance -- that's the new hotness these days!
Since you lumped in VB.NET in there you're definitely past the prime era and oddly I agree that VB.NET is horrible while I still think VB, for the time, was perfectly reasonable. It certainly has less gotchas than JavaScript.
Considering that I spent (and still do spend) most of my afternoons with Haskell and F#, it was a bit of a shock and an experience that I don't remember fondly at all heh
One thing I would correct is that VB does not have extremely loose typing. VB is strongly typed with one exception: the variant type that could hold any other type (kinda like "object" in Java/C# but implemented like a union).
I think a harder part would be libraries/COM/extensions/whatever that access/modify the VB6 runtime internals.
As they say on Dragon's Den, "And for that reason I'm out."
I still won't use it for the project, though. Anything that involves trying to get my personal info is an automatic "no". There's just no point me wasting my time. There's no end of programming languages out there, I'm not going to mess around with this one.
$10/month is surprisingly high for temp-mail.org's service. Fastmail is $3-5/month paying monthly, and that includes full regular email service plus (at the $5/month level) your own domains, and on top of that they offer the disposable email address service. It seems like temp-mail's only extra feature is accepting cryptocurrency.
I think I blame living through the nineties for this feeling.
Maybe a little hard to fit all that on a toolbar-scaled icon. Just RB! in paint-splat neon green would go a long way to increasing the RAD FACTOR though. :)
I'd argue VB was worse because of it (and it's std lib) not being opensource at the time than because it was soooooo bad of a language... People cheer on HN for JS and PHP saying they are totally acceptable langs; then VB was (is) also totally acceptable.
But VB required a payment upfront and whenever you needed to upgrade tools. This is not how the world liked it: pretty much all mainstream langs have opensource tools/stdlib/ecosystems nowadays.
This project replaces proprietary with proprietary (as far as i can see); so to me it adds no value.
In this space (RAD tool) I'm more interested in: https://www.lazarus-ide.org
Visual designer, integrated IDE and debugger, basic language, very similar philosophy, cross platform (thanks to using the JVM as the compile target).
Unfortunately however you do need Windows to author which is not me these days.
As tools for making little apps or rapid prototyping it's quite decent.
very nice to have VB6 again.
Now it's black magic only approachable to $100/hr engineers.
Or are you saying that only midwits charge $100/hr, and that real engineers can and should charge much more, so anyone charging $100/hr is probably a hack?
In the case of the former, here's an anecdote: when I was a baby junior, I was working on an in-house enterprise Windows Forms CRM application.
We had a pricing manager that had taught himself enough C# to be dangerous. The code that the guy wrote was such a disaster that it conjured unspeakable horrors from the void. But because he understood the business domain at a level far deeper than anyone on the dev team, he could crank out forms and custom reports that turned misaligned curly-braces into cold, hard cash faster than any of us could say "DAMMIT MARK, YOU BROKE THE BUILD AGAIN".
The lesson I took from that: turning ideas into code that creates business value isn't the hard part. The hard part is doing it in such a way that you don't create an unmaintainable mess that makes it impossible for the business to adapt to change so that it can continue to make money.
In the case of the latter: I think I need to charge more.
So how did it all got so unnecessarily complicated?
You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input.
Database operations are often performed with no expectation of failure, the network is assumed to never have a problem, security policy is inconsistent, etc.
Perhaps some blame can be laid at the learning materials that emphasize the happy path and treat errors as a separate subject.
I hated VB and am so glad it is almost gone.
You are describing 1998 VB as much as 2022 html+javascript
VB6 (the last one) was 1998, same year as win98, which listed a 486+16M of ram as its system requirements. Which was a big step up from a W95 386 with 4M of ram. So one probably didn't want to run VB itself on those smaller machines, but the resulting apps definitely did, and those low end desktops were exactly what a lot of vb apps were running on.
VB and its ilk were used to write apps that were used in a very specific way. Many times companies wrote apps not just their business use cases, but literally with the expectation of the hardware their users had in the office, the network they were on and who would be maintaining the machines. Ultra rigid user experiences, but still somehow were bug prone.
Today its like, oh yeah, a user had an issue, they were searching our million record database on their smart toaster, one of the table columns weren't aligned correctly and it was slow to load.
Really? All you need is On Error Resume Next . Dead simple.
I believe a more serious answer would be: You could easily trap the error number and make it pop up in a MsgBox, then decide what to do with each type of error. Complex objects or functions would often each need their own custom error handling code, but it wasn't hard to do.
What would a non-developer do after seeing an error number? Click OK and carry on? Might as well just resume next
The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
So exactly like the current Javascript ecosystem then?
Private Sub cmdOk_Click()
On Error Resume Next
WInt = 0
HInt = 0
WInt = CInt(txtWidth.Text)
HInt = CInt(txtHeight.Text)
If CStr(WInt) <> txtWidth.Text Or CStr(HInt) <> txtHeight.Text Then
MsgBox "Invalid numeric values for the dimensions"
txtWidth.SetFocus
Exit Sub
End If
Tag = vbOK
Hide
End Sub
(in hindsight i should have also checked for negatives values but eh whatever)
At this moment it is support only Standard EXE projects.
In further versions, support for ActiveX Components (OCX), ActiveX EXE and ActiveX DLL will be added.
I think you just answered your own question.
On the upside msvbvm60.dll is still shipped with Windows 10 and 11, so a lot of VB6 apps will still just 'run'.
Sure, the compiled apps still run fine, so at this point developer experience suffers a lot more compared to user experience and some users don't understand how much harder every day it is to work on VB6 codebases. (It's a bit of a horror hidden from users.)
The VB6 IDE predates a lot of modern code navigation tools.
The VB6 IDE predates common deployment of the mouse scroll wheel and scroll wheel support is provided by a cranky extension to the IDE that stutters awfully.
I repeat: Scroll wheel support is broken by default in VB6 and there's an extension you can find on the web to install (if you can malware scan it and get it across your network isolation boundary to your XP VM) and it's still awful. Imagine trying to read thousands of lines ancient code without scroll wheel support. Might as well be on papyrus scrolls.
The last version of git that supported XP is now pretty ancient and showing its age.
Good luck setting up an XP build agent for VB6 IDE CI. Which it never supported anyway (the IDE never had a good CLI build tool).
Developer experience of maintaining VB6 IDE apps in 2022 is pretty horrible and morale destroying.
I imagine that's a problem many projects would face trying to use the RAD Basic IDE, too and I don't think it's possible for it to be "no migration", because there will be components that won't work, won't relicense, etc.
Unfortunately the biggest challenge will be third party components. I work with clients who want to migrate VB6 on a daily basis and I don't remember the last time I saw an application without multiple third party libraries. Many of these can no longer be installed in new versions of Windows and so clients are stuck on Windows XP/7 (Even though you can have VB6 installed on W11).
On Windows?
What platform stack is it
Sufficiently compatible with VB that I wrote some coursework on it for a teacher who only knew VB.
Then there was WordBasic, a Word-specific implementation of Visual Basic that really kicked ass. You could build full applications in the word processor, to do tons of things we take for granted today.