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.
:
Verschoben durch Moderator
Susannah schrieb: > Dann hab ich mir Outbyte PC-Repair runter geladen, was diese DLL > angeblich ersetzen soll Besorg Dir die originale dll. Und lass die Finger von ominösen "Reparatur-Tools".
Susannah schrieb: > Dann hab ich mir Outbyte PC-Repair runter geladen, was diese DLL > angeblich ersetzen soll. Wird es nicht tun. Das Internet ist voll von Müll, der einem bei der Suche nach irgendwelchen DLLs angeboten wird. Nichts davon hilft. Die Datei vbrun300.dll ist die Laufzeitumgebung von Visual Basic 3.0 -- und das ist wirklich uralt, nämlich von 1993. https://en.wikipedia.org/wiki/Visual_Basic_(classic)#Timeline Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows 3.11 läuft.
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 Dann wird Dein Proggy laufen. mfg Lotta.
Susannah schrieb: > VBRUN300.DLL Das ist die Runtime-Library von Visual Basic 3.0, normalerweise sollte die bei der Anwendung mitgeliefert worden sein. Hier gibt es die ganze Entwicklungsumgebung, evtl. kannst Du damit auch nur die Runtime-Library installieren: https://archive.org/details/ms-vbpro-30 Ansonsten installieren, die DLL ins Verzeichnis der Anwendung packen und wieder deinstallieren. Susannah schrieb: > Outbyte PC-Repai Von solchen "Optimierungs-Tools" würde ich die Finger lassen. Susannah schrieb: > Der Prozedureneinsprungspunkt "GetTickCount64"wurde in der DLL > "kernel32.dll" nicht gefunden. Braucht ein neueres Windows.
Ich habe sie mal ausgezippt. Der uralte Explodierer kann das doch noch nicht. Oder? Ansonsten aber ein sehr huelfreicher Beitrag. :) > Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows > 3.11 läuft. Das ist so nicht vollstaendig. Ein Windows 10 32 bit ist dazu ganz ueberwiegend auch in der Lage.
Harald K. schrieb: > das ist wirklich uralt, nämlich von 1993. Nur ein Ur ist wirklich *uralt*: Zitat: Ur steht für: Auerochse, ein 1627 ausgestorbenes Wildrind Ur :-)
Harald meinte: > Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows > 3.11 läuft. Upps, wenn Dein Proggy so alt ist dann wird wohl das Proggy dann auch unter Win64 nicht funzen. Wie heißt denn Dein Programm? mfg Lotta.
Lotta . schrieb: > 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..;)
Ein feiner Thread!! So stell ich mir Hilfe im besten deutschsprachigen Hardware-Hackerboard vor!! Wenn wir nur endlich die oft gezeigte Häme ablegen könnten... mfg
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
:
Bearbeitet durch User
Lotta . schrieb: > Upps, wenn Dein Proggy so alt ist dann wird wohl das Proggy > dann auch unter Win64 nicht funzen. Das wohl nicht. Aber wenn es (nur) eine fehlende Library anmeckert, startet es ja zumindest. Evtl. fehlt aber noch mehr vom VB3.0. Wie ich bereits schrub, wuerde es wohl auf einem 32 bit Win 10 laufen. Das bringt die noetige Emulation mit.
Motopick schrieb: > Wie ich bereits schrub, wuerde es wohl auf einem 32 bit Win 10 laufen. > Das bringt die noetige Emulation mit. Genau. Deshalb hab ich auch ne VM mit Windows7 32 für solche Fälle. Das geht dan übrigens auch auf dem Mac. "Parallels" heißt der Zauberer. mfg
Lotta . schrieb: > 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.)
Motopick schrieb: >> Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows >> 3.11 läuft. > > Das ist so nicht vollstaendig. Ein Windows 10 32 bit ist dazu ganz > ueberwiegend auch in der Lage. Lern' doch einfach mal sinnerfassend zu lesen. Wo habe ich irgendwas zu Windows 10 geschrieben?
Harald K. schrieb: > 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.
Windows 10 ist vollkommen irrelevant: Susannah schrieb: > hab aber ein altes Programm, > was nur auf XP oder früheren Windows Versionen läuft..
Harald K. schrieb: > Windows 10 ist vollkommen irrelevant: 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.
Harald K. schrieb: > Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows > 3.11 läuft. 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. Motopick schrieb: >> Das ist übrigens auch noch 16-Bit-Code, d.h. Kram, der unter Windows >> 3.11 läuft. > > Das ist so nicht vollstaendig. Ein Windows 10 32 bit ist dazu ganz > ueberwiegend auch in der Lage. Hast Du noch dusseligere Ideen? W10-32 war ein Exot und wird seit mindestens 3 Jahren nicht mehr gepflegt. Lotta . schrieb: > Ich häng sie hier mal ran, entpacke das Zip mit Winzip > oder Winrar, und kopiere die DLL dann ins Windows\System Verzeichnis Es kann sein, dass die noch mit "regsvr32" registriert werden muß. Erster Versuch wäre bei mir, die ins Verzeichnis der Anwendung zu kopieren. Christoph db1uq K. schrieb: > Die vbrun300.dll hat meistens 398,4 KB aber unterschiedliche > Datumsangaben. Die bei mir gelagerte Version hat 398.416 Bytes und als Checksumme MD5:82aa757de7d80faff99179b457aa0fa0. Identisch mit den zwei aus diesem Thread. Ein komfortabler Vergleich geht damit: http://www.nirsoft.net/utils/hash_my_files.html Motopick schrieb: > Evtl. fehlt aber noch mehr vom VB3.0. Das kann man durchaus haben: Die fehlende Datei eingespielt, wird die nächste vermisst.
Manfred P. schrieb: > 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).
Schau mal hier https://winworldpc.com/product/microsoft-visual-bas/30 etwas runterblättern da gibts auch die deutsche Version.
oder nur das Runtime Modul bei Chip https://www.chip.de/downloads/Visual-Basic-3.0-Runtime-Module_12996635.html
Angehängte Dateien:
-
MC68HC05.PNG
9,9 KB
Manfred P. schrieb: > 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. :)
Motopick schrieb: > Sicher ist es ein Exot. Aber es laeuft ganz sicher auf aktuellerer > Hardware, als alle anderen dazu faehigen Windowsversionen. 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.
Susannah schrieb: > einen alten Rechner 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. ciao gustav
Karl B. schrieb: > 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.
Nee, Harald hat schon Recht. 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. mfg
Lotta . schrieb: > 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.
Harald K. schrieb: > Lotta . schrieb: >> 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? mfg
Lotta . schrieb: > 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.
> gestern hier angemeldet https://de.wikipedia.org/wiki/Oh!_Susanna_(Lied) with a banjo on my knee! bei dem Alter darf das schon noch etwas dauern.
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.
Heinz B. schrieb: > REGSVR32 Wird Dir bei einer 16-Bit-DLL nicht viel bringen. Heinz B. schrieb: > OCX und ActiveX Controls stammen meist von VisualBasic. Richtig, aber nicht von 16-Bit-VB, da hießen die Dinger noch VBX. Nochmal zum Mitmeisseln: Aus irgendeinem Grund soll hier ein mit einem über 30 Jahre altem VB-Compiler erzeugte 16-Bit-Programm betrieben werden.
Harald K. schrieb: > Motopick schrieb: >> 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.
Harald K. schrieb: > 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. ciao gustav
Karl B. schrieb: > Lass mich raten: Selbstgebastelte Buchhaltungsspoftware aus SAP > Raubkopien mit Borland und Delphi zusammengeschustert. Erklaere doch mal in einfacher deutscher Sprache, warum so etwas nach einer VBRUN300.DLL fragen sollte. Ich tippe eher auf eine Astrologie-Applikation. :)
Motopick schrieb: > Versuch das mal auf dieser Uraltversion. Ja, und? VB3 ist genauso alt. Was damit geschrieben wurde, läuft unter 3.11.
Harald K. schrieb: > Ja, und? VB3 ist genauso alt. Was damit geschrieben wurde, läuft unter > 3.11. Du wuerdest dafuer also auch ein Museum pluendern. "Keine weiteren Fragen."
Motopick schrieb: > 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.
Florian S. schrieb: > Das kann man auch auf einem x64-Windows. Nein, 64-Bit-Windows kann keinen 16-Bit-Code ausführen (außer mit Virtualisierung/Emulation à la DOSBox, VMware etc.).
Harald K. schrieb: > 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.
Manfred P. schrieb: > Ä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.
Motopick schrieb: > 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.
Rainer Z. schrieb: > 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.
Motopick schrieb: > Frag mal den Sucher des geringsten Misstrauens nach NTVDM64. Werde ich tun. Klingt bei Dir wie nach einer Möglichkeit, 16-Bit-Software in 64-Bit-Windows auszuführen? Kommt ggfls. für User meiner VBA-Progrämmchen in Betracht, die Office in der 64-Bit-Version installiert haben. Ich selber nutze eine 32-Bit-Version von Office. Hier bemerke ich keine Nachteile. Aber Danke für Deinen Hinweis. Ich lerne gerne dazu.
Rainer Z. schrieb: > 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. N.z.d.
Rainer Z. schrieb: > 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.
Hmmm schrieb: > 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.
Hmmm schrieb: > weil x86_64-CPUs im Long Mode (den 64-Bit-Betriebssysteme nutzen) keinen > Virtual 8086 Mode haben. (+1) https://de.wikipedia.org/wiki/Virtual_8086_Mode Hmmm schrieb: > um x86-Code auch auf > anderen unterstützten Plattformen (z.B. DEC Alpha) ausführen zu können DAS ist ja interessant(kannte ich gar nicht), da habe ich diese Seite als brauchbare Infoplattform gefunden: https://retrocomputing.stackexchange.com/questions/8971/did-windows-nt-4-emulate-x86-on-non-intel-platforms Dort verlinkt u.a.: https://www.usenix.org/legacy/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf
Motopick schrieb: > 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: https://en.wikipedia.org/wiki/SoftPC Motopick schrieb: > NTVDM ist ja in dem Sinne auch keine Emulation wie > DOSBox & Co, sondern eher/ueberwiegend ein API-Translator. Wenn die CPU das unterstützt (auf x86_64-CPUs nur im Legacy Mode, also unter 32-Bit-Windows), ja.
Man wird es wohl mal ausprobieren muessen. 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.
Manfred P. schrieb: > Ä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.
:
Bearbeitet durch User
Manfred P. schrieb: > 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) Motopick schrieb: > Gibt es vom "Clipper" oder vom Foxbasecompiler keine 32 bit Version? > Damit koennte man die guten alten Stuecke dann "kompatibel" verwursten. FoxPro ist ein 32-Bit-Programm, und das kann dBase-Code verdauen. Die Resultate laufen damit auch unter x64-Windows.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.