Hallo,
ich hab so gar keine Ahnung von PC's und hab aber ein altes Programm, was nur auf XP oder früheren Windows Versionen läuft.... jetzt hab ich mir einen alten Rechner gekauft, um das Programm wieder nutzen zu können und wenn ich es starten will, bekomme ich immer die Meldung:
Folgende Datei kann nicht gefunden werden: VBRUN300.DLL
Dann hab ich mir Outbyte PC-Repair runter geladen, was diese DLL angeblich ersetzen soll. Wenn ich das starte kommt die Rückmeldung:
Der Prozedureneinsprungspunkt "GetTickCount64"wurde in der DLL "kernel32.dll" nicht gefunden.
Ich kann mit alledem überhaupt nichts anfangen und hoffe einfach, dass mir hier jemand helfen kann.
Die Dll gehört zu nem Programm, was in alten Visualbasic
geschrieben wurde.
Ich häng sie hier mal ran, entpacke das Zip mit Winzip
oder Winrar, und kopiere die DLL dann ins Windows\System Verzeichnis
Upps, wenn Dein Proggy so alt ist dann wird wohl das Proggy
dann auch unter Win64 nicht funzen.
Naja, aus dem Stand nicht - aber man kann selber einen Emulator oder eine VM bemühen.
32-Bit Windowse sind ziemlich Multi-Emulator fähig.
Die Frage wäre auch eher, welches Windows ist auf welchem alten PC drauf.
Wenn der "PC" ein Apple ist, wird es ja auch schwierig..;)
Ich schaue gerade nach wie oft ich diese DLL auf der Platte habe. Es gibt auch noch vbrun100.dll und vbrun200.dll
Die vbrun300.dll hat meistens 398,4 KB aber unterschiedliche Datumsangaben.
12 mal hier vorhanden.
Die älteste ist vom 29.7.1991, dann noch 12.5.1993, 12.12.1994, 27.9.1995, 3.9.1996, die anderen 2.1.2002. Eine davon hat 4 KB weniger, seltsam.
die vbrun100 und vbrun200 sind auch vom 2.1.2002, 271,3 KB und 357.0 KB
meine alten Festplatten habe ich alle auf die große Terabyte gerettet, schon seit Win3.1
Das geht dan übrigens auch auf dem Mac.
"Parallels" heißt der Zauberer.
Zwar OT, aber: Das ist wohl eher eine komplette Virtualisierung.
Das NTVDM-Subsystem vom 32 bit Windows macht ja nur eine "Uebersetzung"
der alten API-Calls.
Deshalb hab ich auch ne VM mit Windows7 32 für
solche Fälle.
Mit einem nativen W7 32 bit koenntest du auch Virtual PC benutzen,
und Uralt-DOSen/Windowse/Unixe/Linuexe darin virtualisieren.
Oder ein Windows 11. :) (Hab ich aber noch nicht probiert.)
Lern' doch einfach mal sinnerfassend zu lesen. Wo habe ich irgendwas zu
Windows 10 geschrieben?
Sinnerfassend gelesen, fehlt der Hinweis der Lauffaehigkeit auf einem
Windows 10 32-bit.
Lern doch mal eine Aussage umfassend zu beantworten.
Und lass den (unueblichen) Apostrophen mal weg.
Deine Meinung ist bei der Faktenlage vollkommen irrelevant.
hab aber ein altes Programm,
was nur auf XP oder früheren Windows Versionen läuft..
Die 16 bit entweder nativ oder wie bei XP ueber die NTVDM-Umgebung.
Und letztere gibt es eben in Windows 10 32 bit auch.
Fuer Susannah macht das den Unterschied, eben auch alte Hardware
und alte (Betriebs-)Software erwerben zu muessen.
Im Bereich der Billignotebooks finden sich heute viele, die ein
Windows 10 32 bit installiert haben. Typisch 32 GB eMMC und 2 GB RAM.
Die ziehen zwar keinen Elefanten vom Kuechentisch, sind aber u.U.
nuetzlicher als so altes Schnarpelzeug.
Evtl. haette sie die 32 bit Version auch parallel auf bereits
vorhandener Hardware installieren koennen.
Lesen kannst Du? oh-susannah schrieb Win_XP. Hier läuft sämtlicher alter
Kram sogar noch mit Win7-32, aber nicht mehr mit Win7-64.
Auch Du scheinst Probleme mit dem Leseverständnis zu haben, bekommst aber immerhin in Sachen Windows 10 gerade noch so die Kurve (deren 32-Bit-Version ist ein Exot, in der Tat).
Hast Du noch dusseligere Ideen? W10-32 war ein Exot und wird seit
mindestens 3 Jahren nicht mehr gepflegt.
Sicher ist es ein Exot. Aber es laeuft ganz sicher auf aktuellerer
Hardware, als alle anderen dazu faehigen Windowsversionen.
Besonders komfortabel ist die Situation, wenn auch noch eine echte
serielle und parallele Schnittstelle vorhanden sind.
Siehe Bild.
Es kann sein, dass die noch mit "regsvr32" registriert werden muß.
Erster Versuch wäre bei mir, die ins Verzeichnis der Anwendung zu
kopieren.
+++
Evtl. fehlt aber noch mehr vom VB3.0.
Das kann man durchaus haben: Die fehlende Datei eingespielt, wird die
nächste vermisst.
Das hat man bei haendisch installierten Linuxpaketen ja auch oefter. :)
Insoweit kann der Vorschlag, die VB3 IDE komplett zu installieren
durchaus sinnvoll sein.
Bei einem W10/32 scheitert schon die Installation von VB6 mit dem
Verweis auf ein fehlendes NT4 Servicepack :) und man muss einen
alternativen Installer bemuehen.
Man kann es also benutzen, aber eigentlich nicht installieren. :)
Den AT AMD K6 233 MHz mit Multimediaanwendung 32 MB RAM und Win 3.11 habe ich letztes Jahr weggeworfen. Der hatte auch eine VBrun200.dll drauf. Und ein Floppy 5 ein Viertel Zoll.
Tipp: Schmeiß den Scheiß endlich weg.
Alles andere ist unnötige Zeitverschwendung.
Tipp: Schmeiß den Scheiß endlich weg.
Alles andere ist unnötige Zeitverschwendung.
Das ist ein idiotischer "Ratschlag", wenn es darum geht, eine spezielle Software am Leben zu erhalten, die für den Threadstarter wichtige Dinge tut und (offenbar) nicht durch was neueres ersetzt werden kann.
Viele Proggys sind so spezial und einmalig, etwa
ein Chipkarten-Glitcher oder ein AVR-Entfusifizierer
und andere selbstgeschriebe Spezialsoft, so das frau
um Klimmzüge nicht herumkommt.
Ich hatte zum Beispiel unteranderem mal ein Proggy, das
Programme im Punktcode auf Papier ausdrucken konnte,
etwa um in Zeitschriften ein Programmaustausch zu ermöglichen
ohne die Hexzahlen abtippen zu müssen.
Das gab es dann nur einmal und nie wieder!
@Susannah
Kopier die DLL mit in das Vereichnis, wo die Exe Deines
Proggy's drinne ist. Dann läuft es auch ohne Registrierung,
da die Exe die DLL zuerst im eigenen Verzeichnis sucht.
Dann läuft es auch ohne Registrierung,
da die Exe die DLL zuerst im eigenen Verzeichnis sucht.
Nee, das hat nichts mit "Registrierung" zu tun. Nutzt die DLL eine COM-Schnittstelle ("common object model", keine serielle Schnittstelle), dann muss sie mit regsvr registriert werden, damit das Betriebssystem die COM-Aufrufe entsprechend auflösen kann.
Vorformen bzw. Verwandte von COM waren auch OLE und ActiveX.
Dann läuft es auch ohne Registrierung,
da die Exe die DLL zuerst im eigenen Verzeichnis sucht.
Nee, das hat nichts mit "Registrierung" zu tun. Nutzt die DLL eine
COM-Schnittstelle ("common object model", keine serielle Schnittstelle),
dann muss sie mit regsvr registriert werden, damit das Betriebssystem
die COM-Aufrufe entsprechend auflösen kann.
Vorformen bzw. Verwandte von COM waren auch OLE und ActiveX.
OLE gab es bereits zu 16-Bit-Zeiten.
Huch!?!
COM kenne ich, OLE und ActiveX ein Glück weniger.
Ich hab ja mit Automatisierungsserver/Client experimentiert.
Nun war 16 bit ja vor "meiner Zeit" modern.
Es ist ja klar, frau lernt nie aus!
Aber ist ne Laufzeitumgebung damals OLE oder COM gewesen?
Aber ist ne Laufzeitumgebung damals OLE oder COM gewesen?
Muss nicht, kann aber. Ich beschrieb das ganze nur, weil so etwas der Grund dafür ist, daß DLLs "registriert" werden müssen.
Ob das bei der steinalten 16-Bit-DLL von VB 3.0 der Fall ist, weiß ich nicht, aber man kann es nicht vollständig ausschließen.
Da aber, wenn ich das richtig mitbekommen habe, jemand weiter oben auch den Installer für die VB3-Laufzeitumgebung verlinkt hat, muss man sich nicht weiter um das Thema kümmern. Der macht, was auch immer nötig ist.
Solange sich "Susannah" nicht wieder meldet, muss man sich mit dem Thema nicht weiter beschäftigen.
"Susannah" hat sich gestern hier angemeldet und genau einen Beitrag geschrieben.
REGSVR32
Register or unregister OLE controls, such as DLLs and ActiveX controls in the Windows Registry.
OCX und ActiveX Controls stammen meist von VisualBasic. OLE ist ja mittlerweile Teil des BS. Eigene und zusammengesetzte Controls (z.b.
spez.Editfelder mit Listboxen), die es so noch nicht in Windows gab,
konnten damit registriert und angemeldet werden.
Das war, wie damals das .NET, das bis vor ein einigen Jahren nicht
zur Standardinstallation von Window gehörte und nachinstalliert
werden mußte, sofern man es brauchte. Da gab es ja auch noch mehr,
wie bspw. ODBC und SQL.
Es gibt ja heute immer noch einige Nischen-Sprachen, die keine Anbindung
bzw. Zugang zu .NET bereitstellen, bzw. unterstützen. Die können dann auch
nur die Controls, die Windows in der USER32.DLL bereitstellt. Und bestenfalls
über Klimmzüge noch ein paar OLE- Objekte, die die OLE32.DLL bereitstellt
(z.b. Thumbnails).
Bestes Beispiel dafür dürfte wohl die seit ein paar Jahren neuen Windows
Ribbon-Controls, die Windows in seinen Office-Programmen einsetzt, sein.
Sicher ist es ein Exot. Aber es laeuft ganz sicher auf aktuellerer
Hardware, als alle anderen dazu faehigen Windowsversionen.
Zu den Versionen die ein VB3(-EXE) Programm ausfuehren koennen,
zaehlen natuerlich auch die 32 bit Varianten von Windows 7 und
(moeglicherweise, nicht getestet) Windows Vista.
Da es nach W10 32 bit nichts mehr Neues in 32 bit gab, bleibt die
Aussage "auf aktuellerer Hardware" eben richtig.
Auch wenn das scheinbar manchen nicht passt.
Auf einem W10 32 bit kann man ganz nebenbei, auch noch die 32 bit
Version des aktuellen(!) Firefox installieren und betreiben.
Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows
3.11 läuft.
Versuch das mal auf dieser Uraltversion.
Es läuft aber auch auf ganz viel aktueller und älterer Hardware nicht
mehr, weil die weder 32-Bit-UEFI noch ein CSM haben.
So ausgestattet (bzw. nicht ausgestattet) sind etliche PCs schon seit
zehn Jahren unterwegs, beispielsweise die NUC-Reihe von Intel.
Was geht mich dein Elend an?
Da aber, wenn ich das richtig mitbekommen habe, jemand weiter oben auch
den Installer für die VB3-Laufzeitumgebung verlinkt hat, muss man sich
nicht weiter um das Thema kümmern. Der macht, was auch immer nötig ist.
Die Chancen, dass genau der Installer ueberhaupt nichts installiert,
stehen recht gut. Was natuerlich schlecht ist. :) Dann muss man das
Installationspaket "entpacken" und haendisch installieren.
Die Anschaffung musealer Technik haette sich Susanne aber sparen koennen.
die für den Threadstarter wichtige Dinge
tut und (offenbar) nicht durch was neueres ersetzt werden kann.
Es gibt nichts, was KI heute an Schrottprogrammen nicht auch ersetzen kann. Es sei denn, es sind Lizenzsperren drin.
Lass mich raten: Selbstgebastelte Buchhaltungsspoftware aus SAP Raubkopien mit Borland und Delphi zusammengeschustert. Da müssen aber Speicherbereiche in Autoexec.bat dediziert noch zugewiesen werden, was gerade heute von modernen OS aus Virenschutzgründen eben nicht gemacht werden soll, damit es Angreifer nicht so leicht haben.
BTW: Vielleicht verrät uns der TO, welche Software er da nutzen will und warum nicht mit virtual machines aufgesetzt auf modernere OS.
Da es nach W10 32 bit nichts mehr Neues in 32 bit gab, bleibt die
Aussage "auf aktuellerer Hardware" eben richtig.
Auch wenn das scheinbar manchen nicht passt.
Auf einem W10 32 bit kann man ganz nebenbei, auch noch die 32 bit
Version des aktuellen(!) Firefox installieren und betreiben.
Das kann man auch auf einem x64-Windows. Es ist ja nicht so, dass man das WOW64-Subsystem entfernt hat und nur noch 64-bit (Long Mode) Programme ausführen kann. Der einzige Unterschied bei Windows 11 ist, dass es kein reines 32-bit System mehr gibt, trotzdem müssen alle Systemkomponenten weiterhin in der x86-Variante "mitgeschleppt" werden, solange 32-bit-Programme existieren und Microsoft es für wichtig erachtet, dass diese ausgeführt werden können.
Nein, 64-Bit-Windows kann keinen 16-Bit-Code ausführen
Ja leider. Ich habe früher, wohl WfW311, gerne den SemWare-Editor benutzt, E.exe - läuft mit W7-32, aber nicht mehr unter W7-64. Müsste so Baujahr 1994 sein.
Ärgerlicher ist, dass auch dBase_III_plus auf 64-bit-Windows nicht mehr geht, damit habe ich ein paar Programme, die ich noch heute nutze.
Gibt es vom "Clipper" oder vom Foxbasecompiler keine 32 bit Version?
Damit koennte man die guten alten Stuecke dann "kompatibel" verwursten.
Deswegen auf ich auf dem 64-Bit-Windows eine 32-Bit-Version von Office installiert. Damit funktioniert auch VBA, also Visual Basic for Applications mit seinen gesamten OCX-Objekten.
So schließt sich an dieser Stelle der Themenkreis des Threads.
So schließt sich an dieser Stelle der Themenkreis des Threads.
Nicht ganz. :)
Frag mal den Sucher des geringsten Misstrauens nach NTVDM64.
Mann sollte das aber wirklich mit Bedacht(!) benutzen,
und nicht die Sammlung von Altsoftware auf seinem aktuellem
produktiven System nach Farben sortieren wollen.
OT-P.S.:
Google Maps kann Routen praesentieren, die an Werbekunden von
Google vorbeifuehren. Das sollte einem doch zu denken geben.
Werde ich tun. Klingt bei Dir wie nach einer Möglichkeit,
16-Bit-Software in 64-Bit-Windows auszuführen?
Richtig. War fuer mich auch neu. :)
Kommt ggfls. für User meiner VBA-Progrämmchen in Betracht, die Office in
der 64-Bit-Version installiert haben.
Dafuer taugt es wohl eher nicht. Wie waere es dass "Zeug" mit VB
zu kompilieren? Die entstehenden (32 bit) Executables, wuerden ja
im 32 bit Subsystem laufen. Ich kenne mich mit VB/VBA aber eigentlich
nicht aus. :)
Ich selber nutze eine 32-Bit-Version von Office. Hier bemerke ich keine
Nachteile.
Ich benutze Office am liebsten gar nicht. Und wenns unbedingt muss,
dann vllt Office 2000. Fuer Schriftgut/Dokumentationen/etc. bleibe
ich lieber bei meiner gewohnten DTP-Software. Die kenne ich seit der
Version 2.0. Gegenwaertig ist wohl Version 2020 aktuell...
Aber Danke für Deinen Hinweis. Ich lerne gerne dazu.
Klingt bei Dir wie nach einer Möglichkeit,
16-Bit-Software in 64-Bit-Windows auszuführen?
Eine davon, aber genau wie in DOSBox & Co. ist das nur eine Emulation, weil x86_64-CPUs im Long Mode (den 64-Bit-Betriebssysteme nutzen) keinen Virtual 8086 Mode haben.
Rechtlich ist das übrigens dunkelgrau, das basiert auf gestohlenem NT-Source-Code, in dem eine Emulation steckte, um x86-Code auch auf anderen unterstützten Plattformen (z.B. DEC Alpha) ausführen zu können. Bisher scheint es Microsoft aber nicht gestört zu haben, ist halt altes Zeug.
Eine davon, aber genau wie in DOSBox & Co. ist das nur eine Emulation,
weil x86_64-CPUs im Long Mode (den 64-Bit-Betriebssysteme nutzen) keinen
Virtual 8086 Mode haben.
So wie ich es verstanden habe, wird das 32 bit Subsystem dafuer
eingespannt. NTVDM ist ja in dem Sinne auch keine Emulation wie
DOSBox & Co, sondern eher/ueberwiegend ein API-Translator.
Was auch einen deutlichen Einfluss auf die Performance hat.
So wie ich es verstanden habe, wird das 32 bit Subsystem dafuer
eingespannt.
Gut möglich, das ist halt alter 32-Bit-Code. Aber das bedeutet nicht, dass man deshalb den Virtual 8086 Mode der CPU nutzen könnte - die CPU läuft im Long Mode, wenn ein 64-Bit-OS läuft.
Eingekauft haben sie das damals bei Insignia, bekannt durch SoftPC:
Mit NTVDM laeuft ja auch timing kritische Software (Audio/Midi)
recht problemlos. Gelegentlich verbleibt ein NTVDM-Serviceprozess
als Zombie, den man dann haendisch entsorgen muss.
Wenn bei NTVDM64 eine komplette CPU-Emulation anfaellt, wird man
das wohl unmittelbar an der Performance feststellen koennen.
Das mag fuer manche Anwendungsfaelle reichen, und fuer manche
dann auch nicht.
Ärgerlicher ist, dass auch dBase_III_plus auf 64-bit-Windows nicht mehr
geht, damit habe ich ein paar Programme, die ich noch heute nutze.
Lade dir die Freeware-Version von Profan11.a von XProfan.com herunter
und installiere sie. Installation ist ziemlich klein. Profan kann noch
mit dBase III umgehen, da der Autor die Funktionen mit einer Delphi-Unit
in seine Programmiersprache integriert hat. Steht auch alles dazu in
der dt. Hilfe.
Die Syntax Ist ziemlich einfach zu erlernen und somit kannst du dir
deine eigenen Programme schreiben. Aber halt nur 32 Bit.
Ja leider. Ich habe früher, wohl WfW311, gerne den SemWare-Editor
benutzt, E.exe - läuft mit W7-32, aber nicht mehr unter W7-64. Müsste so
Baujahr 1994 sein.
Warum will man einen Editor verwenden, der noch nicht mal Dateinamen kennt?
(Nein, die 8.3-Kürzel aus 16-Bit-Zeiten sind keine Dateinamen)
Wird ja wohl auch kein Problem sein, einen Online-Konverter
(z.B. AnyConv o.ä.), der dann ins gewünschte Datenformat konvertiert,
zu bemühen.
Wenn natürlich laufend noch Daten vom alten Programm hinzu kommen,
ist es eher hinderlich.
