#vb6 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #vb6, aggregated by home.social.
-
Ah, the #nostalgia of VB6! 🕰️ When #coding was as simple as your 1998 haircut. Now, modern .NET? It's like trading your trusty bicycle for a spaceship you can't pilot 🚀—sure, it does more, but good luck figuring it out!
https://evilgeniuslabs.ca/blog/vb6-modern-dotnet-question #VB6 #.NET #Transition #Memories #Technology #Humor #HackerNews #ngated -
BasicBox: x86 PC emulator written in Visual Basic 6 Running… Visual Basic 6 github.com/mikechambers... www.reddit.com/r/EmuDev/com... #retrodev #emulation #emudev #retrocomputing #programming #vb6
-
-
-
I know I'm very much reinventing the wheel here, especially because the wheel has been abandoned and whatever they're calling wheels these days require a supercar and a subscription at minimum to use and no one can build a wheel any more without a hundred people and a plan to burn money until a vulture swoops in to buy the burning husk for how bright it doth shine.
I *wish* this wasn't necessary, like I could just write some UI code and it'll run on any platform and it'll continue to do so forever no matter what new thing they add further down the line. Oh, wait, that already exists! It's called Visual Basic 6! I could write a GUI [to track the IP] in VB6 right now and it would run on Windows 95 through Windows 11 and via WINE on *nix.
Microsoft went on a bit of a bender in the 90s with COM, their object model, but they had the right idea if only lacking in execution (ActiveX...). If you want to embed a web-browser in your app you hook into the COM object and you're away. Different programming language? Doesn't matter. Different OS? Doesn't matter. Different *Endiness*!? Doesn't matter. Different physical location than the object? Doesn't matter, it works over the network!
Software is less modular than ever before; now "modular" just means the programmers used folders this time! Want to render a LibreOffice document inside your app? A PDF? A media player? How many years you got left?
-
I first wrote my own text editor around 2001 using Visual Basic 6 and I used that editor, on Windows, *until VSCode was released in 2016* because #VSCode was the first non-crap Windows editor, and that might seem like a weird thing to say nowadays but in the Before Times, the best text editors in the world were on #Mac because that was the only market where developers cared about software quality and people would actually pay money for it, at all.
Windows was known for piracy and open-source software was basically unusable on the platform. We really, really have come a long way. Remember Atom? They asked the question "what if we wrote a text-editor in JavaScript?" (even worse, coffescript) and the answer was, unsurprisingly, a text-editor slower and less responsive than a teletype. VSCode was literally the first text editor on Windows to successfully copy TextMate.
But even now, one reason I stuck to my editor for so long was because it's the only editor, before or since, where the list of folders and list of files are separate which prevents things jumping around like crazy all the time and it's a feature I still lament the loss of.
-
https://www.windows98.website
visual basic 6, faithfully recreated for the web
#vb #win98 #nostalgia #visualbasic #vb6 #windows #windows98 #vb6 #netart #demo #nerdlife -
Here is another old program of mine:
'Sound Buttons'You could click on one of the 120 buttons to play the file linked to it.
As a gag, I have simply integrated the XP 'WindowsMediaPlayer'.
All video and audio formats common at the time were compatible.It was also possible to create several files to assign to the buttons.
It was one of the few programs for which I have created a help file.
#programming #softwaredevelopment #VB6 #VisualBasic #WindowsMediaPlayer
-
On the left, #VSCode; this app is using ~470 MB of RAM. There's a lot going on in the background here, a web browser engine, a JavaScript engine and server backend. On the right is Visual Basic 6 (#VB6), with a very large project open, taking up 42 MB RAM. Now this isn't even to complain about bloat because VScode performs really well and is very extensible. It's the only editor I've enjoyed using since #TextMate on MacOS;
-
BTW Here’s a modern open-source, regularly updated, portable image editor written in Visual Basic 6 that runs on XP and up and outperforms GIMP: https://photodemon.org/
-
@babble_endanger #FreePascal runs on #MSDOS, 9x, XP and up, #PowerPC MacOS and lots more. Heck, VisualBasic 6 #VB6 runs on 9x thru Win11 and is more stable an ABI on #Linux via Wine than Linux apps have. #Rust ’s problem is a matter of will; a turning up of the nose of anything that isn’t “current” — a moniker they haven’t realised they don’t control; that’s in the hands of Microsoft, Apple, Google etc.
-
At this point, I could write a program in Visual Basic 6 and it'd be more portable than anything I could hope to do with #C.
Compiling suites have become these constantly moving, hulking behemoths that gain more bloat whilst dropping older platforms, making it practically impossible to compile modern code on retro platforms.
I just want to include a small binary in my repo that can compile a small #C89 program so that the user can get going on anything from a Penitum onwards without downloading gigabytes of dependencies that won't even run.
-
Ist das Eskapismus oder Altavismus?
-
Avalonia Visual Basic 6 - A recreation of the classic Visual Basic 6 IDE and language in C# with Avalonia UI.
https://github.com/BAndysc/AvaloniaVisualBasic6
#avalonia #xaml #csharp #vb6 #dotnet #mobiledev #windowsdev #webdev -
The Legacy Coder's Guide to .NET Conf 2024.
https://www.mobilize.net/blog/the-legacy-coders-guide-to-.net-conf-2024
#dotnetconf #dotnet #vb #vb6 #blazor #dotnet9 -
Anyone out there worked on updating a VB6 program recently? I (a structural/fire engineer, not a developer) have somehow ended up being put in charge of doing so for a legacy program we have at work. Someone who hasn't recently done so and willing to help with tips/tricks/etc. (for example, is it possible to find something to open the old .vbp project file? Should I look at trying an automated upgrade to .net tool? etc.) would be wonderful!
-
#PhotoDemon is a free, #opensource image-editor written in ... #VB6! Don't let the language fool you, it's seriously fast and capable, and still runs on Windows XP! https://photodemon.org/2024/07/11/photodemon-2024-7.html
-
#dotNET was a mistake. No, really. Putting aside quality of the C# language et al, nothing else did more to bifurcate Microsoft and derail any unified platform development on Windows ever before.
An insane number of different "official" UI frameworks scatter the landscape that Microsoft doesn't even use themselves when it comes to Window's own code. Choosing any one almost certainly means a guaranteed upgrade treadmill or painful future deprecation (remember UWP, Silverlight?).
And yet, here I am using #VB6 to tinker and it produces binaries that work from Windows 95 through to Windows 11 with no issue. That's almost 30 years of uninterrupted reliability.
-
For some reason there has been a lot of recent interest in a blog post I wrote about VB6 and XML 3 circa 2007.
I genuinely feel awful that somewhere in the world that kind of blog post is helpful in the year of our Lord 2024.
-
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
https://entwickler-gilde.de/2024/01/27/azure-devops-mag-vb6-nicht/
-
@juengling Ich bin da schon ne Zeit bei, obwohl ich aus der #VBA-Ecke kommen. Mit #VB6 habe ich nie gearbeitet. Es funktioniert schon einiges, aber es fehlt auch noch viel. Vor allem die IDE könnte für VB6 Enthusiasten eine Hürde sein. Lernkurve ist vorhanden.
-
-
I just completed "Spiral Memory" - Day 3 - Advent of Code 2017 https://adventofcode.com/2017/day/3 #AdventOfCode in #VB6 on the #Hand386
-
On the left, #VSCode; this app is using ~470 MB of RAM. There's a lot going on in the background here, a web browser engine, a JavaScript engine and server backend. On the right is Visual Basic 6 (#VB6), with a very large project open, taking up 42 MB RAM. Now this isn't even to complain about bloat because VScode performs really well and is very extensible. It's the only editor I've enjoyed using since #TextMate on MacOS;
-
On the left, #VSCode; this app is using ~470 MB of RAM. There's a lot going on in the background here, a web browser engine, a JavaScript engine and server backend. On the right is Visual Basic 6 (#VB6), with a very large project open, taking up 42 MB RAM. Now this isn't even to complain about bloat because VScode performs really well and is very extensible. It's the only editor I've enjoyed using since #TextMate on MacOS;
-
On the left, #VSCode; this app is using ~470 MB of RAM. There's a lot going on in the background here, a web browser engine, a JavaScript engine and server backend. On the right is Visual Basic 6 (#VB6), with a very large project open, taking up 42 MB RAM. Now this isn't even to complain about bloat because VScode performs really well and is very extensible. It's the only editor I've enjoyed using since #TextMate on MacOS;
-
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
https://entwickler-gilde.de/2024/01/27/azure-devops-mag-vb6-nicht/
-
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
https://entwickler-gilde.de/2024/01/27/azure-devops-mag-vb6-nicht/
-
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
https://entwickler-gilde.de/2024/01/27/azure-devops-mag-vb6-nicht/
-
Totgesagte leben (leider) länger
Es ist schon eine Weile her, dass ich VB6 in Jenkins habe kompilieren lassen. Auch die Beschreibung dazu ist schon viele Monate her. Dass es immer noch VB6 Projekte gibt, hat sich allerdings nicht geändert. Und jetzt habe ich festgestellt: Azure DevOps mag VB6 nicht!
Aktuell arbeite ich mit Azure DevOps als CI Umgebung. Und um Suchenden nicht unnötig Hoffnung zu machen: nein, VB6 und Azure DevOps vertragen sich bei uns nicht. Aber das heißt ja nicht, dass man manuell kompilieren muss.
Woran es hapert
Bei dem Versuch VB6 auch mit Azure DevOps zu kompilieren bin ich allerdings auf einige Hürden gestoßen. Und irgendwann ist die Entscheidung gefallen, dass der Aufwand den Nutzen übersteigen würde. Und somit habe ich die Versuche eingestellt.
Einer der Dealbreaker waren die Kompatibilitäten von eben VB6 und Azure DevOps Agents. Denn während unsere VB6 Entwicklungsumgebung auf einem Windows 2008er Terminal läuft, möchte der Azure DevOps Agent gerne eine etwas aktuellere Betriebssystem-Basis.
Nebenbei, auch git wollte nur in einer alten Version installiert werden.
Die Alternative – kleine Brötchen
Ich möchte die notwendigen Schritte zum Erstellen der Setups aber nicht manuell durchführen. Also bleibt der kleine Freund des Entwicklers, die Batch.
Im Projektordner liegt also eine „compile.bat“ Datei, in der all die wiederkehrenden Schritte durchgeführt werden.
- Ausgabeverzeichnis löschen
- Ausgabeverzeichnis neu erstellen
- Kompilieren des VB6 Projektes ins Ausgabeverzeichnis
- Kopieren weiterer Abhängigkeiten oder vorbereiteter Dateien ins Ausgabeverzeichnis
- Aufruf von InnoSetup mit dem vorbereiteten Script
- Kopieren der erzeugten Setup Datei an den Ablageort im Netzwerk
Ist man fertig mit seinen Anpassungen, dann schließt man die VB6 IDE und startet einfach die Batch. Im Vergleich zum vorherigen manuellen Kompilieren und Verteilen der Binaries ist das schon ein guter Fortschritt und pragmatisch gesehen völlig ausreichend.
Fazit
Ja, es geht immer noch schöner. Für unser Team ist so aber eine gute Balance von Aufwand und Nutzen entstanden. Die Ressourcen, um den Prozess noch einfacher zu gestalten, stecken wir lieber in die laufende Ablösung der VB6 Projekte. Entsprechend zählen hier für mich auch kaum mehr Faktoren wie Code-Qualität. Ein Build der Qualitätsparameter wird hier also nicht benötigt. Es geht rein um die Vereinfachung des Deployments. Und das Ziel ist wenigstens erreicht.
https://entwickler-gilde.de/2024/01/27/azure-devops-mag-vb6-nicht/
