Inoffizielles deutsches Xbase-Forum

Hi,
es wurde schon des öfteren darüber geschrieben hier, aber ich meine niemals wirklich zusammengefasst erklärt.
Es gibt ja unter manchen Konfigurationen die Möglichkeit eine laufende EXE oder in Benutzung befindliche DLL umzubenennen und dann gegen eine neue auszutauschen (oder eben nicht). In dem Fall würde mich aber die Möglichkeit interessieren, die es erlaubt. Was passiert da eigentlich? Die Datei kann während der Nutzung nicht gelöscht überschrieben werden, aber umbenannt und dann mit Originalnamen ersetzt werden.
Läuft der geöffnete Betrieb unbehelligt weiter, oder ist so ein Vorgang nicht empfehlenswert als Standardlösung? Ich meine Hubert hätte mal vor eingier Zeit erwähnt, Windows würde mit dem Dateihandle arbeiten und somit wäre es dem OS egal, wie die Datei letztendlich heißen würde, nachdem sie gestartet wurde.

Manfred,

Alaska hatte mal irgendwo geschrieben, das die mit der 2.0 eine Änderung eingeführt haben. Damit soll das alles im Netzwerk performanter und stabiler laufen. Die zieht sich die exe (und eventuelle dll) komplett in den Speicher, und arbeitet dann nur noch damit.

das würde eher für die Möglichkeit der Umbenennung sprechen.

Ich kann aber nur noch einmal meine Erfahrungen damit wiederholen: Ich bekomme das unter keinen von mir ausprobierten Szenarien hin. Das gibt immer eine Rückmeldung, die Datei sei gerade anderweitig geöffnet, und könne daher weder gelöscht noch umbenannt werden.

Mich würde auch brennend interessieren, wie man das doch hinbekommen könnte. Gerade für Updateprozesse wäre das ja ideal.

Jan

Hi Jan,
ich weiß, wir hatten das Thema schon mehrmals. Ich kann nur für den einen Fall hier sprechen und das ist ein Windows Server 2012R2 mit Active Directory über RDP. Da klappt es.
Auf unserem Vereinsserver auch ein 2012R2 aber ohne Active Directory, klappt es auch. (habe ich gerade mit der Verwaltungssoftware für die Anmeldungen probiert.)
Ich weiß auch nicht was bei dem von Dir gemeinten Server anders ist. Oder bei denen, bei denen es klappt.

Manfred,

ich hab das getestet auf Server 2003, 2012R2, 2016. Immer mit AD, ohne RDP. Und auch lokal. in keinem der Fälle hat das funktioniert.

Eventuell wäre das ja mal eine Anfrage an Alaska wert? Denn wir können hier ja nur spekulieren. Da wir auch den Mechanismus, den Alaska da genau eingebaut hat, nicht kennen.

Jan

Also ich habe hier ja "nur" normale Windows Rechner.
Wenn ich als Standarduser angemeldet bin habe ich das Recht eine Datei umzubenennen.
Kleiner Test ... LinePrinter.EXE ... aus unserem Thread mit dem set printer to objekt ...
1. EXE starten *** nicht in einem geschützten Pfad *** !
2. EXE zeigt scharzen CRT Bildschirm und die Druckerauswahl an.
3. Im Explorer suche ich nach der EXE und gehe auf umbenennen ...
4. Ich hänge eine 1 (als Beispiel) an den Namen vor dem Punkt an.
5. Die Datei ist nun unter LinePrinter1.EXE auf der Platte sichtbar und wartet immer noch auf die Druckerauswahl.

Bei Updates würde ich das natürlich in CMD mit rename oder in Xbase++ mit Funktionen machen.

Ich mache das regelmäßig. Umbenennung der laufenden EXE-Datei, Einspielen der neuen Version des Programmes mit dem Originalnamen und Hinweis an die Benutzer, das Programm zu beenden und erneut zu starten. Funktioniert unter Windows Server 2012 und Windows Server 2012 R2 ohne Probleme.

Hallo Leon und die anderen Renamer

Leon hat geschrieben: ↑Do, 05. Apr 2018 9:59Ich mache das regelmäßig. Umbenennung der laufenden EXE-Datei, Einspielen der neuen Version des Programmes mit dem Originalnamen...

Sprechen wir immer nur über EXE und DLL von Xbase++ oder generell über Beliebige?

generell über beliebige - geprüft mit EXE von PowerBasic ... geht genauso.

Ich kann mir nicht vorstellen, dass der Compiler Hersteller hier viel zu melden hat.
Windows öffnet eine Datei mit dem Namen XYZ, aber danach wird diese immer über ein Dateihandle angesprochen (LONG oder DWORD Variable).
Unter Clipper konnte man einstellen, dass Overlay-Dateien benutzt wurden um RAM zu sparen, aber moderne Systeme kümmern sich selbst darum.

Ich kann die EXE nicht löschen, da diese in Benutzung ist, also wird die EXE offen gehalten, vermutlich auch die DLL.
Ich meine gelesen zu haben, dass Windows die DLLs komplett in den RAM einliest und mangelnden Speicher über die Swap-Datei regelt.
Ob das bei EXE Dateien auch so ist weiß ich nicht, aber es wird immer der File Handle benutzt.

Dass manche ihre EXE nicht umbenennen können, muss an den Rechten (Gruppenrichtlinien, Benutzer-Rechten etc.) liegen.
Ich kann mir schon vorstellen, dass je nach Betriebssystem sowas nur dem Admin erlaubt ist.

Leon hat geschrieben: ↑Do, 05. Apr 2018 9:59 Ich mache das regelmäßig. Umbenennung der laufenden EXE-Datei, Einspielen der neuen Version des Programmes mit dem Originalnamen und Hinweis an die Benutzer, das Programm zu beenden und erneut zu starten. Funktioniert unter Windows Server 2012 und Windows Server 2012 R2 ohne Probleme.

Wer so was macht, riskiert sehr, sehr viel. Da muss nur einmal etwas nachgeladen werden und es crasht. Weiter haben laufende Antivirenprogramme gehörig etwas (hier zurecht) dagegen. Und was denn, wenn User A im alt geladenen Programm arbeitet und User B im nachgeladenen? Je nach dem nicht so gut.
Also: Wenn möglich Finger weg und ordentlich Updates planen und entsprechend installieren.
(In Windev kann man elegante Patches dazugeben, welche dieses Problem professionell umgehen).

Herbert hat geschrieben: ↑Fr, 06. Apr 2018 16:10Wer so was macht, riskiert sehr, sehr viel...

Genau!
Über die Sache gibt es doch schon mindestens ein Thema an anderer Stelle im Forum - weiß nur nicht wo...

was ich heute interessanterweise festgetellt habe ist, es scheint nicht immer zu klappen.. Warum es heute schief ging weiß ich nicht, aber es ging schief. Das Programm mußte dieses Mal komplett verlassen werden. Es kan aber auch sein, das es Überschneidungen gab. Also zu dem zeitpunkt in dem ich umbenannt habe, hat jemand versucht es zu öffenen, oder so.
Also auf jeden FAll scheint es mit Vorsicht behandelt werden müssen und kein Tipp für immer und jede Gelegenheit zu sein und evtl. die Erklärung dafür, warum es bei edm einen klappt und bei edm anderen nicht.

DelUser01 hat geschrieben: ↑Fr, 06. Apr 2018 17:50

Herbert hat geschrieben: ↑Fr, 06. Apr 2018 16:10Wer so was macht, riskiert sehr, sehr viel...

Genau!
Über die Sache gibt es doch schon mindestens ein Thema an anderer Stelle im Forum - weiß nur nicht wo...

lasst mal die Kirche im Dorf !

Natürlich muss man wissen was man macht.

Wenn man Software für Terminalserver an einen Kunden ausliefert, der einen eigenen Admin / Systembetreuer hat, liefert man selbst verständlich eine Installationsdatei.
Die fahren Abends das System runter und installieren neue Software, so ist das heute auch bei uns so.

Als ich das machte, war ich Admin und habe über den Server (OS/2 Server, nicht terminal Server) die EXE / DLL ausgetauscht.
Über eine Flag-Datei wurden alle laufenden Programme informiert, dass sie beenden sollten, was intern nach jedem Read bzw. in der Anzeigeschleife geprüft wurde, die EXE hat sich dann verabschiedet.
Einige hatten allerdings die EXE einfach nur laufen und zeigten keine Daten an (z.B. in der eingebauten Hilfe (memoread)), so konnte es passieren dass eine EXE eben nicht geschlossen wurde.
Umbenennen und reinkopieren war die einzige Chance.
Selbst wenn er in einem READ gestanden hätte und so rausgeflogen wäre, hätte das bei uns keine Rolle gespielt, da wir nur Bestandsdaten bearbeitet haben, er hätte eventuell die Eingaben wiederholen müssen.

Etwas früher haben wir die EXE noch lokal vorgehalten (Clipper und Dos /Windows NT) und auf die zentralen Daten zugegriffen.
Damals wurde die EXE über eine Batch gestartet und hat als erstes aus einer Datei auf dem Server die neueste Version ermittelt und mit dem eigenen Stand abgeglichen.
Je nach Ergebnis hat sich die EXE mit ERRORLEVEL selbst beendet und die sie startende Batchdatei hat dann den Update von DLL / EXE (je nach Notwendigkeit) ausgeführt.
Das hat damals wunderbar geklappt und enorm Arbeit gespart (wir hatten im WAN nur 2x128 KBit Leitungen für alle). Heute macht man das anders (mit Terminal Server).

Hubert
NEIN!

Das .EXE sollte eigentlich blockiert sein, falls jemand dieses aktiv aufgerufen hat. Alles andere ist fahrlässig.
Entweder wie erwähnt Patches installieren oder warten, bis alle aus dem Programm sind.

ist es aber nicht, deshalb ja mein Thread hier nochmal zur Zusammenfassung. Was möglich ist und was es evtl.für Folgen haben könnte. Das man es kann, dafür kannst Du Dich bei M$ beschweren. Ob man es machen sollte, das ist eine andere Sache. Wenn ich der Meinuing bin, es ist nicht gefährlich bei genau einem/diesem Programm/Dll, dann entscheide ich ob ich es tue oder nicht.

Ich hab gerade eine ganz böse Falle gehabt in dem Zusammenhang.

Auf dem Server sollte eine neue Version der exe gespeichert werden. Also Programm beendet, exe kopiert, Nachfrage nach Überschreiben bestätigt, exe gestartet. Und obwohl in der Titelleiste wie gefordert das Datum und die Uhrzeit der aktuellen exe angezeigt wurden, wurde der alte Code ausgeführt!

Ich habe alles möglich getestet, ausprobiert. Projekt neu aufgebaut. Alte obj und exe gelöscht. Alles nichts genützt.

Ich war schon kurz davor, den Server neu zu starten. Da hab ich mal im Taskmanager nachgeschaut. Da war die exe ca. 20x drin aufgeführt in der Rubrik "Hintergrundprozesse". Alle liefen mit 0% CPU-Leistung. Da konnte ich also die alte exe überschreiben, aber irgend welche Bestandteile liefen noch im RAM. Und gaben mir in der Ausführung Teile des neuen und Teile des alten Codes zurück.

Nur mal so meine Erfahrungen mit "laufende exe überschreiben"...

Jan

Manfred hat geschrieben: ↑Di, 10. Apr 2018 17:49 ist es aber nicht, deshalb ja mein Thread hier nochmal zur Zusammenfassung. Was möglich ist und was es evtl.für Folgen haben könnte. Das man es kann, dafür kannst Du Dich bei M$ beschweren. Ob man es machen sollte, das ist eine andere Sache. Wenn ich der Meinuing bin, es ist nicht gefährlich bei genau einem/diesem Programm/Dll, dann entscheide ich ob ich es tue oder nicht.

Manfred, das ist einfach nicht professionell.

DLL heisst dynamic link library. Wie der Name sagt, sehr dynamisch. Eine .DLL kann übrigens auch von mehreren Programmen benutzt werden. Diese enthalten Code und Daten. Ein Modul daraus wird nur dann geladen, wenn es benötigt wird. Als Nebeneffekt steigert das die Ladezeit eines Programms. Wird ein Modul bei Start des Programms verwendet, spricht man von Load-Time dynamic Linking, wird dieses erst bei Laufzeit verwendet, nennt man dies Run-time Linking. Windows nutzt dazu den LoadLibrary-Befehl. Wird das Modul nicht mehr verwendet, was dann? Es kann in einem Puffer liegen. Wird dieses wieder verlangt, wird es nachgeladen. Von wo? Eventuell aus dem Puffer, evenuell erneut aus der .dll.
Bei Multithreading wird das Ganze noch komplizierter. Jeder Thread verwendet seinen privaten Speicher, wenn dies nicht anders definiert wird, heisst, ein Modul kann auch innerhalb derselben Applikation mehrmals geladen sein.

Während der Laufzeit eine .dll zu ersetzen ist daher unweise.
Ich jedenfalls kann mir solche Spiele nicht leisten und will das auch nicht riskieren.