Meine eigenen Versuche auf einem Core i der 6. Generation haben schon gezeigt, dass eine VM in der VM als schnarchlangsam bezeichnet werden kann, der primäre Hyper-V Host hatte 32GB RAM und eine PCIe SSD. Praktisch gefühlt genau so schnell wie auf den primären Host war jedoch eine vApp in der geschachtelten VM statt einer kompletten VM - das war mein eigentliches Ziel des Versuches. Um das mit mehreren vApps machen zu können, braucht man allerdings einen Terminalserver, also mehrere parallele RDP Sessions.
Das ganze Gegenteil im beruflichen Umfeld. Die beiden VMs in VirtualBox die auf einer Windows Server VM unter VMWare auf Multiprozessor Hosts und mit einem SAN im Rechenzentrum liefen, kein Unterschied zu einer direkt virtualisierten VM durch den Anwender "fühlbar".
So gewaltig muss man die Unterscheide gar nicht ansetzen, siehe oben.
Didn't find your answer? Ask the community — no account required.
M
Michael Landenberger
"Leo Baumann" schrieb am 12.10.2025 um 01:52:32:
Ich habe 1992 für Borland Turbo Pascal 1.0 für Windows 450 DM bezahlt.
Das hat mich allerdings nicht davon abgehalten, das Programm schon vor Jahrzehnten (!) rückstandslos zu entsorgen und durch den Nachfolger Delphi zu ersetzen. Inzwischen bin ich bei Delphi 12 angelangt. Turbo Pascal 1.0 könnte ich auf 64bit-Betriebssystemen noch nicht einmal installieren. Aber selbst wenn ich das könnte, wäre mit damit erstellten Programmen kein Blumentopf mehr zu gewinnen. Also habe ich mich lange vor der Jahrtausendwende relativ leichten Herzens davon getrennt. Ich käme auch nie auf die Idee, heute noch eine VM extra dafür aufzusetzen, um Turbo Pascal 1.0 weiter benutzen zu können. Warum auch? Delphi 12 läuft unter Windows 11 ohne VM.
Wenn gar keine VM gestartet werden muss, geht das noch schneller.
Gruß
Michael
L
Leo Baumann
Am 13.10.2025 um 01:10 schrieb Michael Landenberger:
ok - Ich have auch in Delphi programmiert. Woher bekommt man denn Delphi
12, doch nicht von Borland?
Grüße
E
Eric Bruecklmeier
Am 13.10.2025 um 01:10 schrieb Michael Landenberger:
Seinerzeit hat der Nantucket Clipper einen Braunen gekostet und die Tools nochmal. Trotzdem käme ich nicht auf die Idee... ;-)
A
Axel Berger
Und wenn es keinen Nachfolger gibt?
In den Neunzigern gab es allein für den Atari drei bis fünf verschiedene Datenbankprogramme. Heute kenne ich nur das dysfunktionale Modul in Open Office und Access, das in den nur noch teuer zu mietenden Officepaketen von Microsoft in den Standardversionen nicht einmal mehr enthalten ist und dessen Benutzung sich für mich unzumutbar darstellt.
Ich verwende weiter 1st-Base in einem Emulator und das fast täglich.
Ja, ich kenne Mysql. Das ist ein sehr leistungsfähiges Backend. Was es nicht mehr gibt, oder was ich mindestns nicht kenne, ist eine einfach bedienbare Oberfläche für Alltagsaufgaben.
H
Hergen Lehmann
Am 13.10.25 um 09:55 schrieb Axel Berger:
Dann sollte man sich rechtzeitig Gedanken machen, wie man wertvolle Daten auf eine aktuelle Plattform portiert bekommt, bevor sich die alten Datenträger und/oder Dateiformate gar nicht mehr lesen lassen. Je mehr Zeit man verstreichen lässt, desto schwieriger wird es, noch Konverter und KnowHow aufzutreiben.
Für KlickiBunti-Datenbanken wie MS Access&Co gibt es in der heutigen Welt einfach keine sinnvollen Anwendungsfälle mehr.
Im gewerblichen Umfeld sollen praktisch immer mehrere Anwender auf den selben Datenbestand zugreifen. Dabei willst du tunlichst nicht, das diese an den rohen Datensätzen herum spielen, sondern eine anwendungsspezifische Oberfläche programmieren, welche die Eingaben validiert, sensible Daten bereits auf dem Server vor unbefugtem Zugriff schützt und einen bestimmten Workflow vorgibt.
Im privaten Bereich sind Standardanwendungen wie Haushaltsbuch, Kontoverwaltung, etc. durch zahlreiche fertige Apps mit mehr oder weniger Dau-tauglicher UX abgedeckt.
Individuelle Aufgabenstellungen, bei denen große Datenmengen strukturiert erfasst werden müssen, sind im privaten Umfeld extrem selten (und in Kombination mit dem nötigen KnowHow, solche Daten sinnvoll zu strukturieren, noch seltener). Das ist weder für ein kommerzielles Softwarehaus noch für einen OSS-Entwickler eine hinreichend große Zielgruppe.
Fazit: Benutze für kleine Datenbestände eine Notiz-App oder die Tabellenkalkulation, lerne für große Datenbestände eine geeignete Programmiersprache, um dir dein Frontend selbst zu programmieren,
M
Michael Landenberger
"Leo Baumann" schrieb am 13.10.2025 um 01:27:35:
Borland-Produkte werden inzwischen von Embarcadero vertrieben. Delphi 12 gibt es dort in einer Community Edition für private Anwender und kleine Unternehmen sogar kostenlos:
formatting link
Gruß
Michael
L
Leo Baumann
Am 13.10.2025 um 11:27 schrieb Michael Landenberger:
danke!
M
Michael Landenberger
"Axel Berger" schrieb am 13.10.2025 um 09:55:22:
Ich habe mit Datenbanken eigentlich nur im Zusammenhang mit Content Management Systemen zu tun. Bei denen läuft MySQL auf dem jeweiligen Server (einer dieser Server steht hier bei mir zuhause). Verwaltet werden die Datenbanken dann mit PHPMyAdmin. VMs oder Emulatoren brauche ich dafür nicht.
Gruß
Michael
A
Axel Berger
Eben. Zwanzig verschiedene Oberflächen und Benutzungskonzepte, alle anders und alle schlecht. Früher hat man sich das für den eigenen Bedarf genau so, wie man es haben sollte, selbst gebaut. Das war für einfache und normale Anwendungen schneller und einfacher, als die idiosynkratischen Vorstellungen anderer lernen zu müssen. Und eben deshalb benutze ich es heute noch.
Was im Emulator verlorenging: 1st-Base hat als ein Ausgabemedium einen Tastaturtreiber. Damit konnte man über eigene Skripte direkt in die Fenster anderer Programme schreiben. Benutzt habe ich es vor allem für Banking- und Faxsoftware und im Editor als Rahmen für Briefe.
Aber wozu, wenn ich eine wesentlich bessere Lösung längst habe und Übung und Erfahrung damit obendrein?
H
Hergen Lehmann
Am 13.10.25 um 12:23 schrieb Axel Berger:
Das ist jetzt aber ein sehr hoher Anspruch, das jemand etwas programmieren soll, das exakt DEINEN (offenbar stark von Mainstream abweichenden) Vorstellungen entspricht.
Warum nicht auch heute?
MySQL als Backend existiert (incl. Alternativen), Delphi/Java/etc. sind Oldtimer-konform und werden durch den Hersteller noch unterstützt, Neueinsteiger werden vielleicht lieber zu etwas NodeJS oder Python für die serverseitige Logik sowie einem Webfrontend greifen.
Tastatureingaben nach Belieben in fremde Applikationen injizieren? Klingt nach einem Traum für Cyberkriminelle.
Wenn die Lösung noch durch den Hersteller und/oder eine aktive Community unterstützt wird - klar, warum nicht.
Wenn es jedoch ein schon vor Jahrzehnten abgekündigter Exot ist, wie gesagt: Dann sollte man sich rechtzeitig Gedanken machen, wie man wertvolle Daten auf eine aktuelle Plattform portiert bekommt, bevor sich die alten Datenträger und/oder Dateiformate gar nicht mehr lesen lassen. Je mehr Zeit man verstreichen lässt, desto schwieriger wird es, noch Konverter und KnowHow aufzutreiben.
A
Axel Berger
Sag mal, was genau verstehst Du nicht? In den Neunzigern gab es Dutzende universeller Datenbankprogramme, in denen man auf einfache Weise seine eigene Oberfläche für den gewünschten Zweck bauen konnte. Es war ein Programm für alle diese Spezialanwendungen, das und dessen Bedienung man deshalb auch nur einmal lernen mußte. Ich halte ständig die Augen offen, aber solange es gleichwertiges für aktuelle OS nicht gibt, verwende ich das Gute und Bewährte weiter.
Den Unterschied dazwischen, ein Programm von Grund auf neu zu schreiben und ein vorhandenes, gutes Programm in seiner Benutzeroberfläche individuell zu konfigurieren, kennst Du aber schon?
Welchen Vorteil soll das bieten? Den emulierten Oldtimer verwende ich aus der Not, weil es für das aktuelle OS etwas gleichwertiges nicht gibt.
Welche Datenträger? Es liegt alles auf neuen Platten und einer, genauer mehreren, aktuellen recht neuen Maschine. Gute Datenformate sind asciibasiert und gut dokumentiert, die werde ich immer lesen können. Das ist einer der Vorteile gute Software.
Ja, genau das hört man immer von Leuten, die Deinem Rezept folgen und jeder Mode nachlaufen.
H
Hergen Lehmann
Am 13.10.25 um 17:56 schrieb Axel Berger:
Offenkundig hat sich diese Idee nicht bewährt, denn derartige Anwendungen wurden nach einer kurzen Blüteperiode durchweg nicht mehr weiterentwickelt oder sogar aus ihrem Mutterprodukt entfernt.
Die Gründe liegen auf der Hand: Für das gewerbliche Umfeld fehlen Multiuser-Fähigkeit, Skalierbarkeit, Datenintegrität und Datenschutz. Im privaten Umfeld ist die Lernkurve für die weit überwiegende Mehrzahl der Nutzer immer noch viel zu steil.
Beide Wege erfordern eine mehr oder weniger steile Lernkurve.
Der eine Weg endet nach SingleUser-Anwendungen mit trivialem Funktionsumfang und kleinen Datenmengen in einer Sackgasse.
Der andere Weg ermöglicht beliebig komplexe Fachanwendungen, die sich ggf. auch publizieren lassen. Und öffnet je nach Alter des Lernenden vielleicht sogar die Perspektive auf eine berufliche Laufbahn.
Geringerer Lernaufwand für Usenet-Rentner.
Ich dachte wir reden hier von Datenbanken? ASCII scheitert schon an Datenbank-Kernanforderungen wie "strukturiert", "konsistent", "redundanzarmut" und "potenziell große Datenmenge". Und an der deutschen Sprache. :-P
Ich laufe gewiss keiner Mode nach.
"Mein" berufliches Hauptprojekt basiert immer noch auf einem überwiegend in C++11 (nur teilweise "schon" C++17) geschriebenen Backend, einer proprietären Scriptsprache vom Anfang des Jahrtausends für die UI-Logik, sowie einem auf serverseitig erzeugtem HTML und etwas jQuery basierenden Frontend. Versuche, das beizeiten zu modernisieren, scheiterten am Personalmangel.
Weil ich mich damit notgedrungen auskenne und sich gerade Datenbankoberflächen damit recht flott programmieren lassen, mache ich damit auch meine privaten Sachen.
... aber spätestens, wenn die verwendeten Werkzeuge gar keinen Support mehr erhalten (wenigstens in Form von Sicherheitspatches und Lauffähigkeit unter aktuellen Betriebssystemen), ist einfach das Ende der Fahnenstange erreicht. Emulationen und VMs können die Umstellungsperiode überbrücken, aber keinen dauerhaften Betrieb garantieren.
A
Axel Berger
Für Privatanwender. 1st-Base ist relational. Amazon könnte damit nicht seine Produkt- und Kundendaten verwalten.
Ich habe derzeit 12500 Zeitschriftenartikel, meist mit Abstracts, und
550 Bücher. So wenige, weil ich spät angefangen habe und fast nur das Gebiet Archäologie erfaßt ist. Als Privatperson reichen mir 850 Adressen mit allen bekannten Personendaten. Die Hörspiele umfassen 7500 Einträge. Bei den Kochrezepten sind 1250. Daneben etwas Kleinkram mit unter 100 Einträgen.
Die schnelle und einfache Konfigurierbarkeit und gute Importfunktion erlaubt es, sie für manche "mal eben" Auswertung zu verwenden, die mit anderen Werkzeugen mühsamer wäre. Die sehr mächtige Funktion für Ausgabereports, mehr oder weniger ein komplettes BASIC, ermöglicht es, Dateien im Format fast jedes anderen Programms zu schreiben, wenn es nur dokumentiert oder entschlüsselbar ist.
Und ein Universalwerkzeug für vieles, das ich seit Jahrzehnten verwende, kenne ich aus dem FF und komme fast immer zum Ziel. Ich bin noch nicht senil genug für lernunfähig, aber 30 Jahre Erfahrung erwerbe ich mit einem neuen Programm nicht in einem Monat.
Es muß nicht einmal meine Restlebenszeit abdecken, nur solange ich noch geistig fit genug für den Rechner bleibe. Und ich mache immer noch in kürzester Zeit Sachen, die die Jugend mit ihrer Klickibunti-Maushandarbeit zum Staunen bringen.
S
Sieghard Schicktanz
Hallo Hergen,
Du schriebst am Mon, 13 Oct 2025 11:07:08 +0200:
Na, da wüßte ich schon ein paar recht häufige private Anwendungen, wo sowas sinnvoll sein könnte. Dazu gehört vor allem die ganze Haustechnik, die heute durchaus rechjt komplex daherkommt, mit Heizung, PV-Anlage, ggfs. Wallbox, und auch mal von dynamischem Strompreis abhängige Bezugssteuerung. Das wird halt jetzt mehr oder weniger alles mehr oder weniger von mehr oder wenigeren Hersteller-Web-"Portalen" mehr oder weniger nutzerfreundlich abgedeckt, was für den Nutzer dann in ein buntes Durcheinander (bis Chaos) von bunten und unübersichtlichen Web-Oberflächen ausartet, die der "durchschnittliche Nutzer" nicht mehr durch- und überblickt und die er daher kaum nutzt und (weiterhin) alles "dem Lauf der Dinge", aka der Willkür der Hersteller seiner Geräte, überläßt.
Es ist für die meisten potentiellen Nutzer (in Usanien gern als "couch potatoes" bezeichnet) einfach zu komplex geworden, und diese Komplexität bedingt(e) halt einen Aufwand, der auch für kommerzielle Softwarehäuser, und erst recht für jeden OSS-Entwickler, eine recht hohe Einstiegshürde darstellt.
Das ist dann das daraus resultierende Fazit, und auch dazu sind nur wenige besonders interessierte Nutzer überhaupt in der Lage...
S
Sieghard Schicktanz
Hallo Axel,
Du schriebst am Mon, 13 Oct 2025 17:56:06 +0200:
Vielleicht solltest Du Dir mal "SQLite" anschauen, ein Datenbanksystem für einfache Anwendungen, für das es Dutzende von "Front-End"-Programmen gibt, die Dir unmittelbaren Zugriff auf die Daten erlauben und die auch manipulieren können. SQLite ist AFAIK auch skript-fähig, und es gibt viele (Skript-) Programmiersprachen, die es unterstützen. Du benutzt es übrigens schon, wenn Du auf einer Deiner Maschinen einen "neueren" Firefox benutzt. SQLite stammt zwar aus der "Unix-Welt", aber ist (AFAIK) genauso unter Windows verfügbar, wie auch z.B. Python als Skript-Sprache. (Nein, ich benutze das nicht vornehmlich, aber ich brauche für mein Finanzprogramm auch das "etwas schergewichtigere" PostgreSQL.)
K
Kay Martinen
Das könnte schon vorher eng werden weil m.W. jeder Hypervisor die Virtuelle Platte als eine Datei verwaltet. Wenn man das jetzt kaskadieren will dann muß die Virtuelle Platte neben dem Gast-OS und dem Hypervisor dazu auch die Virtuelle Platte enthalten für das darin befindliche OS. Heißt: Mit jeder Virtualisierungs-stufe nach außen (zum Host) muß die Virtuelle Platte immer größer werden um die anderen Platten enthalten zu können.
Und der Zugriffsgeschwindigkeit der VM ist so was auch nicht zuträglich.
Und irgendwann ist die Platte voll und zugriffe auf VM6 tröpfelt nur. Was braucht ein Windows 11 noch mal an Minimalem Platz... Und dabei sind Experimente z.b. mit Virtuellen RAID Platten noch nicht mit gerechnet. Das Passthrough von Geräten (PCI, FDD o.a.) über mehrere Ebenen hinweg könnte auch... spannend werden - wenn man es brauchte.
Bye/ /Kay
A
Axel Berger
Danke. Sollte ich wohl wirklich.
-- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069 X in | D-50829 Köln-Ossendorf
formatting link
\ Mail | -- No unannounced, large, binary attachments, please! --
R
Ralph Aichinger
Wobei SQLite halt auch kein GUI-basierter Datenbankdesigner ist, sondern eine Datenbanklösung hauptsächlich zum einbauen in eigene Programme, die ohne einen externen SQL-Serverprozess auskommt.
Ich hab das Gefühl diese einfachen "all in one"-Datenbanken (Designer, Backend, Abfrage-Gui alles in einem) sind auch deswegen ausgestorben, weil die komplizierteren Szenarien das alles auf mehrere spezialisierte Komponenten auftrennen und die einfachsten Lösungen von Endusern halt typischerweise sowas wie "Wir tippen das in eine Tabelle untereinander in Excel, da kann man auch filtern und suchen" sind.
/ralph
H
Hergen Lehmann
Am 13.10.25 um 22:47 schrieb Sieghard Schicktanz:
Ja, bei großen Gebäudekomplexen kann es zu einer recht umfangreichen Datenbank ausarten, welche Komponenten von welchem Typ wo montiert wurden, welche Wartungsanforderungen haben, wann zuletzt gewartet wurden, durch welche Fehlerszenarien aufgefallen sind, etc. Dafür gibt es dann auch entsprechende Fachanwendungen fertig zu kaufen.
Privat wird es da aber weniger um eine strukturierte Erfassung des Datenbestands (=Datenbank) gehen, sondern eher um die einheitliche Bedienung, also um die UI-Programmierung.
Was seitens der Hersteller vollauf beabsichtigt ist. Zum einem, um einen Vendor-Lockin zu erreichen ("wenn du willst, das das zusammenspielt, musst du alles bei uns kaufen"), zum anderen, um über die meist Cloud-basierten Oberflächen eine Kontrolle darüber auszuüben, wann der Kunde eigentlich funktionierende Komponenten trotzdem ersetzen muss (Planned Obsolescence).
Es gibt OSS-Projekte, welche das Problem zu lösen versuchen, aber oft an nicht offengelegten Schnittstellen scheitern und leider auch nicht wirklich leicht zu konfigurieren sind.
Solange man auf einem freien Markt besteht, ist das Problem der Komplexität wohl auch nicht lösbar. Die Konzepte der Produkte sind einfach zu unterschiedlich und wenn man auch nur ansatzweise eine einheitliche Bedienung will, ist man sofort bei komplexen Konfigurationsvorgängen oder gar individuellem Scripting.
Ich bin in einem verwandten Bereich (Sicherheitstechnik) beruflich tätig, ich kenne das Dilemma nur zu gut.
So isses.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.