Forum: Offtopic DOS-Problem Schnittstelle bei Umstieg von w98 nach XP?


von andi (Gast)


Lesenswert?

habe seit dem umstieg von w98 auf xp ein problem: wenn ich den
epromsimulator am COM1 mit der alten DOS-exe beschreiben will, bricht
der Vorgang vor dem erreichen der 100% dateiübertragung ab (machmal bei
80%, oft schon bei 50% oder noch früher). Das Übertragen dauert auch
wesentlich länger (früher z.b. waren nach 10s schon 20% übertragen, das
dauert jetzt ne halbe minute). Trotz aller möglichen
einstellungsversuche (baud-geschwindigkeit,
speicherzuweisungsoptionen,
win95-komp-modus etc) war ich noch nicht erfolgreich.
Mit einer vorhandenen WIndowssoftware geht es so schnell wie gewohnt,
bloß kann ich die nicht in die batch einbinden.
vielleicht habt ihr eine idee oder kennt ein ähnliches verhalten und
wißt einen trick, dieses "DOS-Problem"unter XP zu lösen?

von Jens. (Gast)


Lesenswert?

das liegt an der emulierten com schnitstelle, win xp laesst keine
direkten zugriffe zu
ich meine aber das man das ungehen kann
such mal hier im forum ich mein da muesste es etwas zu finden geben

gruss Jens

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Zwar kann man in der Tat mit irgendwelchen Hacks (giveio.sys) direkte
Hardwarezugriffe auch für DOS-Programme ermöglichen, die unter Windows
laufen, das sollte man aber tunlichst sein lassen, wenn die Hardware
interruptgesteuert arbeitet, was bei der seriellen Schnittstelle
zumindest üblich ist.
Dann geht ein solcher Zugriff ganz ordentlich in die Hose und ein
Bluescreen ist die Folge.

Dieser "giveio"-Hack ist daher nur sinnvoll, wenn nicht
interruptauslösende Hardware verwendet wird, was für die
Parallelschnittstelle im Standard-Modus zutrifft.

Ein Grund für das teilweise erstaunlich schlechte Funktionieren von
DOS-Programmen, die mit der seriellen Schnittstelle hantieren, ist die
teilweise abenteuerlichste Ansteuerung der Schnittstelle durch das
DOS-Programm.
Da es für DOS keine verwendbaren Devicetreiber für serielle
Schnittstellen gab bzw. die wenigen Möglichkeiten (Fossil) kein
Programmierer nutzen wollte, hat jeder seine höchst individuelle
Variante der Ansteuerung implementiert. Mehr oder weniger brauchbar,
wie das bei verschiedenen Programmierern mit schwankenden
Hardwarekenntnissen und -Verständnis halt der Fall ist.

Und aus diesem Grund hat die nicht 100% perfekte Hardwareemulation der
VDM (das ist die virtuelle DOS-Emulation von Windows NT) so ihre
Probleme damit, mit all diesen Varianten der Programmierung
klarzukommen.

Eine letzte Möglichkeit bestünde darin, den ganzen Kram in einer
vollständig virtualisierten Umgebung wie VMWare laufen zu lassen ...

Sinnvoller erscheint mir hier die Entwicklung eines neuen
Download-Programmes, das als Win32-Konsolapplikation mit
Betriebssystemmethoden (CreateFile etc.) die serielle Schnittstelle
behandelt, was natürlich nur dann möglich ist, wenn das
Downloadprotokoll des EPROM-Simulators dokumentiert ist.

Wie auch immer: Viel Erfolg beim Finden einer Lösung.

von Benedikt (Gast)


Lesenswert?

Das mit den Abbrüchen habe ich auch, als ich meinen AVR Programmer (der
in QBasic geschrieben ist) auf XP laufen lies.
Das Problem ist folgendes:
Irgendwie puffert XP die COM Port Daten zwischen, zumindest hatte ich
mit einem kleines Maus Demo bis zu 10s Verzögerung zwischen
Mausbewegung und Anzeige ! Außerdem erkennt XP, dass die IO Zugriffe
versuchen Daten vom COM Port zu lesen. Ich hatte mal versucht (auf den
nicht vorhandenen COM2) zuzugreifen, über 0x2Fx glaube ich, und sofort
kam eine Meldung im Windows Fenster " ..versucht auf COM 2
zuzugreifen..."
Jedenfalls gehen bei hohen Datenraten oftmals Daten verloren, und daher
bleibt das Programm bei 50-100% stehen, da es nur einen Teil der Daten
bekommen hat.

Das ist eben auch eine Möglichkeit ein Betriebssystem sicherer zu
machen, indem man die Möglichkeiten des Benutzers begrenzt, ganz so
nach dem Prinzip
Wenn Autos nur geradeaus fahren können, gibts keine Unfälle beim
Abbiegen...

von Olaf Stieleke (Gast)


Lesenswert?

"Das ist eben auch eine Möglichkeit ein Betriebssystem sicherer zu
machen, indem man die Möglichkeiten des Benutzers begrenzt, ganz so
nach dem Prinzip"

Ich halte dagegen: Das ist eben eine Möglichkeit, ein BSys sicherer zu
machen, indem man den von Rufus bereits vortrefflich angemerkten Murks
vergangener Tage, der besonders bei der SIO um sich griff, unterbindet.
Eine Emulation ist nun mal eine Emulation.

Und ich bin froh, das XP so restriktiv und dadurch sehr stabil ist -
die Zeiten von W98 mit mehreren Reboots pro Tag möchte ich ungern
wieder zurückhaben.

von andi (Gast)


Lesenswert?

Soderle, Problem gelöst bzw. umgangen:
Habe zum Glück noch eine windows-version der ladesoftw. dabei gehabt,
auf die ich erst nicht umsteigen wollte weil ich das o.g. Ladeprogr.
auch weiterhin aus einer vorhandenen alten batchdatei aufrufen wollte.
Die win-version habe ich dann flott bekommen, da läuft die Übertragung
fix wie früher. Und zu meiner Begeisterung ließ sich diese win-exe auch
aus der Batch aufrufen. (Sonst kennt man ja eher die Antwort "Aufruf
nur unter win.. möglich").
Vielen Dank für Eure Mühe!!

Bitte 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
Noch kein Account? Hier anmelden.