Discussion:
Windows 95 und NET TIME
(zu alt für eine Antwort)
Volker Englisch
2020-03-24 15:59:45 UTC
Permalink
Hallo!

Windows 95 müsste eigentlich schon alt genug sein, um hier On Topic zu
sein. Falls nein, bitte umleiten...

Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.

Auf dem Windows 95-Recher ergibt ein NET TIME \\SERVER folgende
Fehlermeldung:

Fehler 51: Der angegebene Computer empfängt keine Amforderungen.
Stellen Sie sicher, daß der angegebene Computername richtig ist, oder
wiederholen Sie den Vorgang später, sobald der Remote-Computer
verfügbar ist.

Auf dem Server findet sich im Log:

smbd: in openpam_read_chain(): /etc/pam.d/samba(2): invalid control
flag 'require'

Soweit ich mich erinnere, hat das "früher" mal funktioniert. Braucht
NET TIME unbedingt ein erfolgreiches Login auf dem Samba-Server? Den
bekommt das Windows 95 natürlich nicht, von wegen encrypted passwords.

Windows (95) kann die Uhrzeit nicht direkt über NTP abfragen!?

P.S.: Das alte Win95 ist ausser aus Nostalgiegründen nur wegen eines
alten Spiels im Dienst...
Wolf gang P u f f e
2020-03-24 17:23:33 UTC
Permalink
Post by Volker Englisch
Windows (95) kann die Uhrzeit nicht direkt über NTP abfragen!?
Ich hatte unter der WinME ein separates Programm Namens SWITIME.
http://www.sw4you.de/switime.php
Wolf gang P u f f e
2020-03-24 17:25:28 UTC
Permalink
Post by Wolf gang P u f f e
Post by Volker Englisch
Windows (95) kann die Uhrzeit nicht direkt über NTP abfragen!?
Ich hatte unter der WinME ein separates Programm Namens SWITIME.
http://www.sw4you.de/switime.php
Scheinar hat der Erfinder auf seiner englischen Seite (.com) noch eine
ältere Version, wo auch Win95 genannt wird.
http://www.sw4you.com/switime.php
Volker Englisch
2020-03-25 14:24:40 UTC
Permalink
Arno Welzel
2020-03-24 18:59:18 UTC
Permalink
Post by Volker Englisch
Windows 95 müsste eigentlich schon alt genug sein, um hier On Topic zu
sein. Falls nein, bitte umleiten...
[...]
Post by Volker Englisch
Soweit ich mich erinnere, hat das "früher" mal funktioniert. Braucht
NET TIME unbedingt ein erfolgreiches Login auf dem Samba-Server? Den
bekommt das Windows 95 natürlich nicht, von wegen encrypted passwords.
Windows (95) kann die Uhrzeit nicht direkt über NTP abfragen!?
Korrekt. Dafür braucht man einen NTP-Client, z.B. das hier:

<http://www.timesynctool.com/>
--
Arno Welzel
https://arnowelzel.de
Volker Englisch
2020-03-25 14:26:56 UTC
Permalink
Volker Englisch
2020-03-25 18:11:18 UTC
Permalink
Ralf Kiefer
2020-03-25 16:35:10 UTC
Permalink
Post by Volker Englisch
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Der Dienst, den man üblicherweise mit NTP bezeichnet, läuft über IP. Und
mit dem hatte Windows 95 so seine Probleme, AFAIK.

Zu den vorgeschlagenen NTP-Diensten habe ich einen weiteren anzumerken:
Automachron. Als typischer 8-Punkt-3-Name heißt das z.B. achron5. Ich
mußte mich vor langer Zeit mit der Zeitsynchronisation von PCs aus der
NT-, Embedded-NT- und 2000-Zeit herumplagen, weil das eingebaute Zeug
nicht mal ansatzweise reproduzier- und überwachbar funktioniert. Ob's
unter 95 läuft, weiß ich nicht.

Bei Automachron gefiel mir, daß es einstellbar ist und eine Logdatei
schreiben kann, die man mit Laufwerksfreigabe sogar von außen lesen
kann, so daß ein ganzer Rechnerzoo überwachbar wurde.

Gruß, Ralf
w
Fritz
2020-03-25 16:44:26 UTC
Permalink
Post by Ralf Kiefer
Bei Automachron gefiel mir, daß es einstellbar ist und eine Logdatei
schreiben kann, die man mit Laufwerksfreigabe sogar von außen lesen
kann, so daß ein ganzer Rechnerzoo überwachbar wurde.
Gruß, Ralf
w
... automachron hatte ich damals auch

https://web.archive.org/web/20000816063611/http://www.oneguycoding.com/automachron/

--
Volker Englisch
2020-03-26 07:56:41 UTC
Permalink
Post by Fritz
Post by Ralf Kiefer
Bei Automachron gefiel mir, daß es einstellbar ist und eine Logdatei
schreiben kann, die man mit Laufwerksfreigabe sogar von außen lesen
kann, so daß ein ganzer Rechnerzoo überwachbar wurde.
... automachron hatte ich damals auch
https://web.archive.org/web/20000816063611/http://www.oneguycoding.com/automachron/
Danke für den Link!
Volker Englisch
2020-03-26 07:56:10 UTC
Permalink
Post by Ralf Kiefer
Post by Volker Englisch
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Der Dienst, den man üblicherweise mit NTP bezeichnet, läuft über IP. Und
mit dem hatte Windows 95 so seine Probleme, AFAIK.
Automachron. Als typischer 8-Punkt-3-Name heißt das z.B. achron5. Ich
mußte mich vor langer Zeit mit der Zeitsynchronisation von PCs aus der
NT-, Embedded-NT- und 2000-Zeit herumplagen, weil das eingebaute Zeug
nicht mal ansatzweise reproduzier- und überwachbar funktioniert. Ob's
unter 95 läuft, weiß ich nicht.
Danke für den Tipp. Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel... Schade, sonst macht das Tool einen guten
Eindruck.
Peter Heitzer
2020-03-26 11:08:23 UTC
Permalink
Post by Volker Englisch
Post by Ralf Kiefer
Post by Volker Englisch
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Der Dienst, den man üblicherweise mit NTP bezeichnet, läuft über IP. Und
mit dem hatte Windows 95 so seine Probleme, AFAIK.
Automachron. Als typischer 8-Punkt-3-Name heißt das z.B. achron5. Ich
mußte mich vor langer Zeit mit der Zeitsynchronisation von PCs aus der
NT-, Embedded-NT- und 2000-Zeit herumplagen, weil das eingebaute Zeug
nicht mal ansatzweise reproduzier- und überwachbar funktioniert. Ob's
unter 95 läuft, weiß ich nicht.
Danke für den Tipp. Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel... Schade, sonst macht das Tool einen guten
Eindruck.
Du musst halt die letzte gültige Zeit auf Platte zurückschreiben und
dann beim Booten erst den letzten Wert setzen, bevor du mit ntp
synchronisierst.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Enrik Berkhan
2020-03-26 13:04:26 UTC
Permalink
Post by Peter Heitzer
Post by Volker Englisch
Danke für den Tipp. Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel... Schade, sonst macht das Tool einen guten
Eindruck.
Du musst halt die letzte gültige Zeit auf Platte zurückschreiben und
dann beim Booten erst den letzten Wert setzen, bevor du mit ntp
synchronisierst.
Oder fest z.B. auf den 1.1.2020, ist einfacher.

Viele Grüße,
Enrik
Ralf Kiefer
2020-03-26 16:23:29 UTC
Permalink
Post by Enrik Berkhan
Post by Peter Heitzer
Du musst halt die letzte gültige Zeit auf Platte zurückschreiben und
dann beim Booten erst den letzten Wert setzen, bevor du mit ntp
synchronisierst.
Oder fest z.B. auf den 1.1.2020, ist einfacher.
Das könnte beides nicht optimal sein. Z.B. Raspbian auf dem Raspberry Pi
verhält sich mit dieser Taktik genauso unkooperativ, wo ich das recht
unschön finde.

Man gönnt dem Betriebssystem ein paar Wochen Pause, dann geht's beim
Neustart nicht und die Zeit bleibt in der Vergangenheit. Oder im 2.Fall
muß man das Shell-Kommando alle paar Wochen nachbessern, wenn die
Distanz zu groß geworden ist.

Gruß, Ralf
Volker Englisch
2020-03-26 18:24:25 UTC
Permalink
Post by Peter Heitzer
Post by Volker Englisch
Post by Ralf Kiefer
Post by Volker Englisch
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Der Dienst, den man üblicherweise mit NTP bezeichnet, läuft über IP. Und
mit dem hatte Windows 95 so seine Probleme, AFAIK.
Automachron. Als typischer 8-Punkt-3-Name heißt das z.B. achron5. Ich
mußte mich vor langer Zeit mit der Zeitsynchronisation von PCs aus der
NT-, Embedded-NT- und 2000-Zeit herumplagen, weil das eingebaute Zeug
nicht mal ansatzweise reproduzier- und überwachbar funktioniert. Ob's
unter 95 läuft, weiß ich nicht.
Danke für den Tipp. Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel... Schade, sonst macht das Tool einen guten
Eindruck.
Du musst halt die letzte gültige Zeit auf Platte zurückschreiben und
dann beim Booten erst den letzten Wert setzen, bevor du mit ntp
synchronisierst.
Da NetTime einwandfrei funktioniert, ist die Frage eigentlich eher
philosophischer Natur:

Wie macht man das unter DOS? Ein "DATE > datum.txt" geht schon mal
nicht, weil DATE eine Eingabe erwartet. Wenn ich eine Datei mit
Datumsinhalt hätte, könnte ich die per "TYPE datum.txt | DATE" an DATE
erfolgreich verfüttern?

DOS ist für mich zu lange her, als daß ich mich an evtl. Tricks erinnern
könnte.
Wolf gang P u f f e
2020-03-28 08:55:35 UTC
Permalink
Post by Volker Englisch
Post by Peter Heitzer
Post by Volker Englisch
Post by Ralf Kiefer
Post by Volker Englisch
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Der Dienst, den man üblicherweise mit NTP bezeichnet, läuft über IP. Und
mit dem hatte Windows 95 so seine Probleme, AFAIK.
Automachron. Als typischer 8-Punkt-3-Name heißt das z.B. achron5. Ich
mußte mich vor langer Zeit mit der Zeitsynchronisation von PCs aus der
NT-, Embedded-NT- und 2000-Zeit herumplagen, weil das eingebaute Zeug
nicht mal ansatzweise reproduzier- und überwachbar funktioniert. Ob's
unter 95 läuft, weiß ich nicht.
Danke für den Tipp. Da die Hardware-Uhr auf dem uralten Mainboard
nicht mehr funktioniert, muss das zu verwendende Tool die Zeit nach
dem Booten um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist
Automachron als maximale Differenz zu viel... Schade, sonst macht das
Tool einen guten Eindruck.
Du musst halt die letzte gültige Zeit auf Platte zurückschreiben und
dann beim Booten erst den letzten Wert setzen, bevor du mit ntp
synchronisierst.
Da NetTime einwandfrei funktioniert, ist die Frage eigentlich eher
Wie macht man das unter DOS? Ein "DATE > datum.txt" geht schon mal
nicht, weil DATE eine Eingabe erwartet. Wenn ich eine Datei mit
Datumsinhalt hätte, könnte ich die per "TYPE datum.txt | DATE" an DATE
erfolgreich verfüttern?
DOS ist für mich zu lange her, als daß ich mich an evtl. Tricks erinnern
könnte.
Ja, ist zu lange her um konkreter zu helfen.
Ich hatte so um 1999 herum ein Batch-Tool gebastelt, mit dem ich eine
zeitlich beschränkte Shareware am Leben erhalten konnte.
Aus der Erinnerung heraus:
Zum Starten wurde eine Batch-Datei angeklickt, die das aktuelle Datum
auslaß und in eine temporäre Datei schrieb, das Datum dann auf einen
fixen Tag X zurücksetzte, das Sharewarerprogramm startete, und dann
wieder das aktuelle Datum aus der Temp-Datei zurückholte und setzte.
Und alles mit normalen Batchbefehlen, oder einem kleinen in QBASIC
kompiliertem Progrämmchen.

W.
Volker Englisch
2020-03-28 17:33:33 UTC
Permalink
Post by Wolf gang P u f f e
Post by Volker Englisch
Wie macht man das unter DOS? Ein "DATE > datum.txt" geht schon mal
nicht, weil DATE eine Eingabe erwartet. Wenn ich eine Datei mit
Datumsinhalt hätte, könnte ich die per "TYPE datum.txt | DATE" an DATE
erfolgreich verfüttern?
DOS ist für mich zu lange her, als daß ich mich an evtl. Tricks erinnern
könnte.
Und alles mit normalen Batchbefehlen, oder einem kleinen in QBASIC
kompiliertem Progrämmchen.
Die DOS-Batchbefehle sind bei mir inzwischen, glaube ich, aus dem
Langzeitgedächtnis gelöscht. QBASIC ist mir aber noch recht geläufig -
allerdings nur in interpretierter Form. Wie hast Du die Progrämmchen
kompiliert bekommen?
Wolf gang P u f f e
2020-03-29 07:26:03 UTC
Permalink
Volker Englisch
2020-03-29 20:25:03 UTC
Permalink
Post by Volker Englisch
Post by Wolf gang P u f f e
Post by Volker Englisch
Wie macht man das unter DOS? Ein "DATE > datum.txt" geht schon mal
nicht, weil DATE eine Eingabe erwartet. Wenn ich eine Datei mit
Datumsinhalt hätte, könnte ich die per "TYPE datum.txt | DATE" an DATE
erfolgreich verfüttern?
DOS ist für mich zu lange her, als daß ich mich an evtl. Tricks erinnern
könnte.
Und alles mit normalen Batchbefehlen, oder einem kleinen in QBASIC
kompiliertem Progrämmchen.
Die DOS-Batchbefehle sind bei mir inzwischen, glaube ich, aus dem
Langzeitgedächtnis gelöscht. QBASIC ist mir aber noch recht geläufig -
allerdings nur in interpretierter Form. Wie hast Du die Progrämmchen
kompiliert bekommen?
Mit QB4.5, QuickBASIC Version 4.5.
Das war ein Compiler für das QBasic von MSDOS.
Ich war überzeugt davon, dass das ein Interpreter war.
OPEN "C:\GERBDATE.DAT" FOR OUTPUT AS #1
PRINT #1, a$
CLOSE
So macht es auf jeden Fall Sinn. Das wäre eine Lösung auch für mein
"Problem", wenn es nicht inzwischen gelöst wäre.

Ralf Kiefer
2020-03-26 11:08:39 UTC
Permalink
Post by Volker Englisch
Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel...
Argl! Irgendwas ist ja immer ;-) Diesen Anwendungsfall hatte ich
definitiv nicht. Die Rechner, auf denen ich das eingerichtet hatte,
liefen üblicherweise nicht am Wochenende und für ein paar Tage mehr
nicht an den Feiertagen zum Jahreswechsel. Da zu diesen Zeiten zudem die
Temperatur in den Räumen abgesenkt war, konnte ich schön erkennen, wie
schlecht einzelne Quarze für Uhrenchips sind. Da haben einzelne sogar
schon nach einem Wochenende die tolerierte Abweichung von 2sec gerissen.

Gruß, Ralf
Volker Englisch
2020-03-26 17:09:16 UTC
Permalink
Post by Ralf Kiefer
Post by Volker Englisch
Da die Hardware-Uhr auf dem uralten Mainboard nicht
mehr funktioniert, muss das zu verwendende Tool die Zeit nach dem Booten
um gut 30 Jahre ändern. Das in Sekunden umgerechnet ist Automachron als
maximale Differenz zu viel...
Argl! Irgendwas ist ja immer ;-) Diesen Anwendungsfall hatte ich
definitiv nicht. Die Rechner, auf denen ich das eingerichtet hatte,
liefen üblicherweise nicht am Wochenende und für ein paar Tage mehr
nicht an den Feiertagen zum Jahreswechsel. Da zu diesen Zeiten zudem die
Temperatur in den Räumen abgesenkt war, konnte ich schön erkennen, wie
schlecht einzelne Quarze für Uhrenchips sind. Da haben einzelne sogar
schon nach einem Wochenende die tolerierte Abweichung von 2sec gerissen.
Ist ja auch ein bisschen krass, das Datum um 30 Jahre verändern zu
müssen. Zugegeben, ich hatte es auch nicht erwähnt. Und nicht daran
gedacht, unter Unices darf die Abweichung ja auch nicht zu groß sein.

Hattest Du mal mit Funkgeräten zu tun, die die Frequenz mittels
Schwingquarzen erzeugen? Deren Qualität merkt man bei größeren
Termperaturunterschieden durchaus auch ;-)
Andreas Fenner
2020-03-28 07:54:07 UTC
Permalink
Post by Volker Englisch
Hallo!
Windows 95 müsste eigentlich schon alt genug sein, um hier On Topic zu
sein. Falls nein, bitte umleiten...
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
...
Schau dich mal hier um:
https://www.meinberg.de/german/sw/ntp.htm#ntp_stable_nt

Da hatte ich "damals" meinen NTP-Client her.

Andreas
Olaf Schmitt
2020-03-29 13:14:35 UTC
Permalink
Post by Volker Englisch
Hallo!
Windows 95 müsste eigentlich schon alt genug sein, um hier On Topic zu
sein. Falls nein, bitte umleiten...
Auf meinem Server läuft ein NTP-Dienst. Ein NET TIME \\SERVER
funktioniert von moderneren Windows-Clients aus einwandfrei.
Auf dem Windows 95-Recher ergibt ein NET TIME \\SERVER folgende
Fehler 51: Der angegebene Computer empfängt keine Amforderungen.
Stellen Sie sicher, daß der angegebene Computername richtig ist, oder
wiederholen Sie den Vorgang später, sobald der Remote-Computer
verfügbar ist.
smbd: in openpam_read_chain(): /etc/pam.d/samba(2): invalid control
flag 'require'
Soweit ich mich erinnere, hat das "früher" mal funktioniert. Braucht
NET TIME unbedingt ein erfolgreiches Login auf dem Samba-Server? Den
bekommt das Windows 95 natürlich nicht, von wegen encrypted passwords.
Windows (95) kann die Uhrzeit nicht direkt über NTP abfragen!?
P.S.: Das alte Win95 ist ausser aus Nostalgiegründen nur wegen eines
alten Spiels im Dienst...
Vielleicht hilft dir das:
https://www.brutman.com/mTCP/mTCP_Sntp.html

Olaf
Loading...