hi, habe hier ein kleines Problem mit dem Starten von DBase III+, das ist eine Uralt Software, die unter DOS läuft. Beim Versuch, DBase zu starten, bekomme ich mitgeteilt, dass ich keine Zugriffsrechte habe. So weit, so gut, DBase.exe mit WinFile.exe markiert, Dateirechte abfragen, Admin, ich und Gäste haben Vollzugriff. Die Datei selbst ist es eher nicht, alte Kopien starten ebensowenig. Unter MSDOS gebootetem Rechner alles problemlos, DBase startet. Verwaltet XP Zugriffsrechte noch in irgendeiner supergeheimen Datei, die jetzt aus unnachvollziehgbaren Gründen das Starten von DBase verhindert? Grüssens, harry
Gast
#2724815
das Problem sind nicht die dateirechte. Vermutlich hast du eine der vielen OptimierungsProgramm mal laufen lassen. http://www.windowspage.de/frame.php?http://www.windowspage.de/tipps/021597.html
hi, danke, aber das trifft so nicht zu. Optimierungsprogramme kenne ich keine, hab' ich bislang auch nicht benötigt (hoffe ich), wegen never touch a running system... Dein Link verweist auf eine Einstellung, die das Starten des MSDOS Modus gestattet oder eben nicht, das ist nicht das Problem, MSDOS läuft ja anstandslos im kleinen schwarzen Fensterchen. Alle DOS Befehle funktionieren, am, System liegt's demnach eher weniger. Nur und ausschliesslich DBase lässt sich nicht starten: >Zugriff verweigert< Also nochmal: Dateifehler (DBase.exe) kann ich ausschließen -> DBase lässt sich problemlos starten, wenn mit MSDOS gebootet wurde. Nur in Anwendungen unter WIN XP (dazu gehört ja wohl auch der MSDOS Modus als Prozess unter XP) lässt sich DBase nicht mehr starten. Noch jemand eine Idee?
Gast
#2724843
Harry Up schrieb: > Alle DOS Befehle funktionieren, am, System liegt's demnach eher weniger. > Nur und ausschliesslich DBase lässt sich nicht starten: >Zugriff > verweigert< nein, das was du unter DOS meinst ist eine 32bit commandshell. Dos ist eine 16bit emulation. Diese meldung kommt also dann wenn es nicht erlaubt ist eine 16bit anwendung zu starten. Hast du mal nachgeschaut ob der wert gesetzt ist?
Die Kommandoumgebung unter WinXp ist eben keine 100%ige DOS-Emulation. Installier DOS-Box und probiers damit. http://www.dosbox.com/
hi, na sicher hab ich nachgesehen, ob der Schlüssel und Wert gesetzt ist. Die Schlüssel waren noch nicht da, hab die dann nach Anweisung erzeugt und neu gebootet, das hat aber keine Änderung ergeben. Die Nummer mit DosBox ist ja schon spassig, für alle, die es interessiert: DosBox startet mit einem virtuellen Laufwerk Z: Physikalische Laufwerke können wie bei Unix, Linux oder älteren Apple-Systemen gemounted werden. (mount c c:\Test macht c:\Test zum Laufwerk c) Aber: will ich die ganze Platte c: mounten, meckert das Teil, es sei nicht recommended, only subdirectories... Mounte ich dann c c:\DBase als c habe ich die ganze Platte c: als Laufwerk c gemounted und vollen Zugriff darauf. Scheint noch ein wenig überhoilungsbedürftig zu sein, aber schön: Ausführung von DBase kein Problem, kann also wieder damit arbeiten. Dennoch bleibt die Frage: Was verhindert das Starten von DBase unter XP und dessen Sub-Derivate? Erstmal vielen Dank, Sache funtzt ja, Grüssens, harry Tante EDIT: Rückwärtsgang -> bissl zurück Es wird lediglich empfohlen, nicht das komplette LW zu mounten, der Befehl wird dennoch klaglos ausgeführt, also mounten von ganzen LWs kein Problem.
Harry Up schrieb: > Dennoch bleibt die Frage: Was verhindert das Starten von DBase unter XP > und dessen Sub-Derivate? Das weiß ich auch nicht genau. Vermutung, unter DOS gibt es jede Menge Software-Interrupts, die u.a. für Dateioperationen genutzt werden. Möglicherweise wurden da nicht alle in die CMD-Umgebung von XP übernommen. Die "Eingabeaufforderung" ist wie schon gesagt kein vollwertiger DOS-Ersatz. Und noch ein Hinweis. Ich kann mich dunkel erinnern, daß ich in den 90ern einen Fall hatte, wo dBase mit merkwürdigen Fehlermeldungen ausstieg (disk full), nachdem neue Serverhardware angeschafft wurde. Am OS konnte es nicht liegen, das blieb das gleiche (Novell 3.12). Nach einiger Zeit der Fehlersuche ergab sich des Rätsels Lösung. Der neue Server hatte natürlich mehr Festplattenplatz, welcher auch genutzt wurde. dBase (ich glaube V4 wars) kam aber nicht mit Volumegrößen über 2GB zurecht. Nachdem extra eine kleinere Partition angelegt wurde, lief es wieder tadellos.
Auf genau welche Art und Weise wird das DOS-Programm hier aufgerufen?
Durch Doppelklick im Explorer oder "von Hand" in einem Konsolenfenster
("Eingabeaufforderung", oft fälschlich "DOS-Fenster" genannt)?
@ Icke: die Problematik der zu großen Laufwerke kenne ich allzu gut, die 4er Version hatte bei mir nur ein kleines Gastspiel, die war ja seelische Grausamkeit, bin noch immer bei der guten ollen III+, stabil und ohne Ballast. Compiliert habe ich dann später mit Clipper, da war dann auch das LW Problem gemeistert, außerdem sehr viel 'netzwerkfreundlicher' als DBase. @ Rufus: ob Doppelklick auf eine DBase-Datei oder diskret im Fensterchen von Hand spielt dabei keine Rolle, überall keinen Zugriff. Ulkigerweise nur DBase, andere DOS Programme marschieren ohne Tadel, das bringt mich schon auf die Idee einer 'Forbidden-Tabelle'. Unter Linux könnte man den ganzen Vorgang mitloggen, da wäre der Übeltäter schnell gefunden, aber da tritt so'n Mist ja auch nicht auf. Grüssens, harry
Harry Up schrieb: > Unter Linux könnte man den > ganzen Vorgang mitloggen, da wäre der Übeltäter schnell gefunden, aber > da tritt so'n Mist ja auch nicht auf. Da laufen DOS-Programme gar nicht, stimmt. Mit FileMon oder ProcMon kann man den Kram auch unter Windows näher untersuchen, der hierbei zu beobachtende Prozess ist allerdings ntvdm.exe
Mh.. DBase? Versuch doch mal: Die CONFIG.NT unter %Systemroot% bearbeiten und FILES und BUFFERs auf 100 hochsetzen.
Gast
#2725423
Es gab Fälle, wo Programme bei Rechnern über 500MHz ein Laufzeitproblem bekamen. Sollte Dein DBase III+ auch dazu gehören? http://de.wikipedia.org/wiki/DBASE Man könnte notfalls die dbf-Daten importieren und mit einem neueren Programm bearbeiten?
Das Laufzeitproblem sollte sich aber anders äußern als in "Zugriff verweigert". Wie exakt sieht die Fehlermeldung aus? Screenshot?
na denn, ProcMon gestartet, Prozess ntvdm.exe per Filter includiert, dbase gestartet, nix Zugriff, ProcMon gestoppt, nach Prozess gefiltert, hm, nix... Taucht nich in der Liste auf, schönes Spielzeug, aber wohl falscher Prozess Da laufen zig Sachen ab, nur kann ich meinen Prozess nicht finden, weil DBase im ProcessName nicht auftaucht, klar, läuft ja auch nicht... Files und Buffers hochsetzen? Das klingt jetzt schon nach UrDos Tricks, um bissl mehr TSR-Prozesse zum Laufen zu bekommen, aus der Ecke würde ich das Problem jetzt nicht vermuten. Das Bearbeiten der DBase Dateien ist kein Problem, unter DosBox klappt's ja, also alles im grünen Bereich. Mich interessiert halt, was da blöd spielt.
Angehängte Dateien:
-
unter_DosBox_OK.PNG
(22 KB)
-
unter_Prompt.PNG
(29 KB)
-
unter_Win.PNG
(36 KB)
Gast
#2725477
Ich glaube immer noch das bei dir die ntvdm.exe komplett deaktiviert ist. du kannst auf denem System vermutlich gar keine 16bit programm starten, es wird immer diese Meldung kommen. Suche mal in der Registry nach VDMDisallowed eventuell steht es ja noch woanders drin.
In Deinem dritten Screenshot ist zu sehen, daß neben "db.exe" auch eine "db.pif" existiert. Sieh Dir mal deren Eigenschaften näher an, bzw. benenne die mal um. *.pif-Dateien werden von Windows verwendet, um Einstellungen für DOS-Programme vornehmen zu können. Möglicherweise ist die hier ja kaputt. Wenn sie funktionieren, können sie anstelle des zugehörigen DOS-Programmes aufgerufen werden.
jepp, die ganze Registry verfügt nur über diesen einen Schlüssel, den ich heute vormittag angelegt habe, der steht, wie er soll, auf 0. Wenn ich das richtig verstanden habe, dürfte bei einem Wert von 1 aber die Konsole nicht mehr ausgeführt werden, richtig? Oder nur Prozesse, die innerhalb dieser Konsole ablaufen, tun sie aber alle, bis auf db.exe. Jetzt auch klar, dass im Procmon ntvdm.exe nicht auftaucht, wird ja aus Windoof erst garnicht gestartet, wenn ich auf db.exe doppelklicke. Ist ja zum Mäusemelken, ntvdm wird auch nicht als laufender Prozess angezeigt, wenn die Konsole gerade am Laufen ist... sehr seltsam, ist alles gruselig komplex und undurchsichtig. Wie schön war's doch, als die Erde noch 'ne Scheibe war...
Angehängte Dateien:
-
ntvdm_kein_Eintrag.png
(36 KB)
Gast
#2725510
Harry Up schrieb: > Ist ja zum Mäusemelken, ntvdm wird auch nicht als laufender Prozess > angezeigt, wenn die Konsole gerade am Laufen ist... sehr seltsam, nein absolut normal, das was du als console sieht hat nicht mit dem DOS zu tun. Das ist eine normale 32bit eingabeaufforderung.
die PIF ist nur 'ne Verknüpfung zu db.exe, hat auch jeder alle Rechte. Umbennennen führt zum selben Ergebnis - you have lost all rights to your file...
Harry Up schrieb: > Ist ja zum Mäusemelken, ntvdm wird auch nicht als laufender Prozess > angezeigt, wenn die Konsole gerade am Laufen ist... sehr seltsam, ist > alles gruselig komplex und undurchsichtig. Lies nochmal durch, was oben geschrieben wurde: Die "Konsole" ist ein 32-Bit Windows-Prozess. Du willst einen 16-Bit DOS-Prozess ausführen. Beides hat nicht viel miteinander zu tun. Du musst dein Windows dazu bringen, den 16-Bit-DOS-Emulator laufen zu lassen. Oder halt einen anderen Dos-Emulator (DOSbox) benutzen.
Gast
#2725527
starte mal bitte in deiner cmd "edit" dann sollte sich der 16bit editor öffnet (keine ahnung warum der bei XP noch dabei ist)
@ Ernst, tu ich ja, DosBox marschiert ja klaglos... nu haut's mich um: EDIT - Zugriff verweigert xcopy blabla kein Problem, wird ausgeführt
ok, vllt. begriffen das nette schwarze Fensterchen ist ein User Interface, welches unter Win als hundsordinärer Prozess abläuft und je nach Eingabe erst den DOS Emulator mitsamt den übergebenen Parametern startet, right? Ergo klappt die Nummer mit DosBox, einem (richtigen?) 16Bit Emulator, weil der noch nicht 'kastriert' wurde wie der Win-eigene Dos-Emulator. Kommt das so hin?
Hab mal einen Screenshot angehängt: Hinteres Fenster, "Start -> ausführen -> cmd" ist die 32-Bit Windows Eingabeauforderung. Meldet sich mit "Windows XP...." Vorderes Fenster, "Start -> ausführen -> command" beherbergt die 16-Bit "command.com", die sich auch mit "Windows DOS" meldet. Und keine langen Dateinamen versteht. Solange dieses Fenster offen ist, gibts auch eine ntvdm im Taskmanager. Versuch also mal so "command.com" zu starten, und wenn das geht, in diesem Fenster dein DBase auszuführen... Ich hab meins übrigens erst neulich entsorgt... Die Papiertonne war voll mit den Handbüchern.
Angehängte Dateien:
-
CMD_vs_command.png
(12 KB)
Gast
#2725551
Harry Up schrieb: > EDIT - Zugriff verweigert klar ist ja 16bit xcopy blabla kein Problem, wird ausgeführt auch klar, ist 32bit bei dir ist also das 16bit subsystem abgeschaltet, warum auch immer.
na so ganz langsam lichtet sich's... Okay, Ausführen -> Command: Zugriff verweigert nettes schwarzes Fensterchen starten, kein Problem also 2 völlig verschiedene Prozesse, die sich recht ähnlich sehen, wie unglaublich sinnreich ist das denn? Gut, mein 16Bit System ist kastriert, DosBox läuft, alles ok. Aber die Frage nach dem Warum bleibt schon stehen... So, Feierabend, bis neulich und vielen Dank bis dahin... Grüssens, harry
Was genau ist das für ein Windows? Etwa eine 64-Bit-Version? > Rather than update the NTVDM to correctly work on 64bit > versions of Windows, Microsoft choose to no longer include > it thus versions of Windows NT for 64-bit architectures > (x86-64 and IA-64) are unable to run DOS or 16-bit Windows > applications. The only possibility to run them is to use > Windows XP Mode or other virtualization software. Quelle: http://en.wikipedia.org/wiki/Virtual_DOS_machine
Harry Up schrieb: > also 2 völlig verschiedene Prozesse, die sich recht ähnlich sehen, wie > unglaublich sinnreich ist das denn? Wie schon bemerkt wurde, die "Eingabeaufforderung" (cmd.exe) ist lediglich die Kommandozeilen-Shell von Windows. Wer lieber tippt statt klickt, kann hier vieles per Befehl erledigen (macht für bestimmte administrative Aufgaben durchaus Sinn). Die command.com ist dagegen der 16-Bit Kommandointerpreter, für den Windows eine 16-Bit-Umgebung emulieren muß (und der eben nicht 100% kompatibel zu DOS ist). Auch wenn die schwarzen Fenster gleich aussehen, es stecken verschiedene Programme dahinter. Rufus Τ. Firefly schrieb: > Was genau ist das für ein Windows? Etwa eine 64-Bit-Version? Unwahrscheinlich, XP Home gibt es nicht in 64-Bit.
Hier schon mal gelesen? http://support.microsoft.com/kb/314106/de
Gast
#2725656
Wenn ich mich dunkel entsinne, wird das 16-bit-Subsystem von einem Mickrigsoftschem Sicherheitsupdate abgeschaltet. Aber keine Ahnung wie man es wieder ankriegt.
Harry Up schrieb: > jepp, die ganze Registry verfügt nur über diesen einen Schlüssel, den > ich heute vormittag angelegt habe, der steht, wie er soll, auf 0. Schau mal hier: http://www.winfaq.de/faq_html/Content/tip1500/onlinefaq.php?h=tip1918.htm Stehen beide Werte, im User- UND Machinezweig auf 0?
jepp, der war's, stand in dem Pfad des Links auf 1. Dubios, habe ich nicht gestern nach allen VDMDisallowed suchen lassen und nur meinen erstellten Eintrag gefunden, der auf 0 stand. Naja, ich muss die unendlichen Tiefen des Windoof nicht in allen Aspekten in- und auswendig kennen, ist aber fein, dass es hier Leuts gibt, die das offensichtlich tun. Problem gelöst, wie's dazu kam weiss kein Mensch, immerhin habe ich ja jahrelang damit gearbeitet, bis dann irgendwann... Leuts, habt vielen Dank, bis neulich, harry
Gast
#2726329
Harry Up schrieb: > Dubios, habe ich nicht gestern nach allen VDMDisallowed suchen lassen > und nur meinen erstellten Eintrag gefunden, der auf 0 stand. prima, schon im 2. Betrag hatte ich also genau die richtige lösung geschrieben. Extra noch mal nach dem eintrag suchen lassen.