CSDIL_PROGRAM_FILES in 32Bit/64Bit

[p80286]

Zitat von QuickAndDirty:

Zitat von p80286:

Zumindestens XP kann das noch.

Cool. Haben die ab Vista damit angefangen?

keine Ahnung, am Arbeistplatz hab ich noch XP.
Nein warte, ich hab da noch ein 32BitW7, muß mal schauen. Kann aber bis morgen dauern.

Zitat von QuickAndDirty:

Zitat von p80286:

Ich agiere manchmal auch als Admin, rate mal wie ich auf ein Comic als Installationsanweisung reagieren werde.

Du würdest dich getrieben von der Identifizierung mit dem Hauptcharackter durch die gesammte Anleitung lesen. Und das ansprechen der visiospatialen, den episodischen als auch phonologisch-lingualen Hirnfunktionen würde zu einer leichteren Aufnahme der Information führen. Du würdest dich über diese an die Fähigkeiten des Gehirns angepassten Vermitlungsweise freuen und dich fragen warum nicht das gesammte Programm noch eine Gamifizierung erfahren hat. Wenn du am Ende der Anleitung angekommen wärst, würdest du in Heureka-Rufe ausbrechen und tanzend über den Büroflur wirbeln.

Korrekt antizipiert?

OK, wir verstehen uns!

Gruß
K-H

[Zacherl]

Habe nicht alles durchgelesen, aber vielleicht hilft dir bei deiner Überprüfung im Hauptprogramm die Wow64DisableWow64FsRedirection API. Damit kannst du die WOW64 Redirection temporär für dein Programm deaktivieren.

[musicman56]

@QuickAndDirty

Vieles von dem was du schreibst kommt mir bekannt vor. Ein Grundproblem deiner Vorgehensweise beim Updaten von Clients über's Netzwerk liegt darin, dass die Clients Zugriffsrechte auf den Server brauchen. Ich hab das Problem vor etwa 10 Jahren schon gelöst, indem ich auf dem Server nach der Installation und nach jedem Internet-Update (das vom Server aus via FTP von meinem WEB-Server heruntergeladen wird) ALLE Programmdateien in eine Datenbank (in ein Blob-Feld) einlese, natürlich zusammen mit Datum und Größe in separaten Feldern. Der Client vergleicht dann einfach seine lokal vorhandenen Dateien mit denen in der Datenbank, und wenn eine älter ist, wird mit TBlobField.SaveToFile einfach die Datei aktualisiert. Mit jeder Haupversion ändere ich dann ein Datenfeld in der Datenbank-Struktur und damit verhindere ich dann sogar noch, dass sich Clients mit inkompatibler (älterer) Version im Netzwerk anmelden.

Einziger Nachteil: Ca. 150MB Speicherplatz für die Datenbank, aber ist das wirklich ein Nachteil?

[p80286]

Es sieht so aus, als dürften unter W7(Enterprise) auch Administratoren nicht an der Berechtigung von
C:\Programme drehen, das könnte allerdings auch an den Richtlinien liegen.

Da fehlen mir allerdings die notwendigen Infos.

Gruß
K-H

[QuickAndDirty]

Zitat von musicman56:

@QuickAndDirty

Vieles von dem was du schreibst kommt mir bekannt vor. Ein Grundproblem deiner Vorgehensweise beim Updaten von Clients über's Netzwerk liegt darin, dass die Clients Zugriffsrechte auf den Server brauchen. Ich hab das Problem vor etwa 10 Jahren schon gelöst, indem ich auf dem Server nach der Installation und nach jedem Internet-Update (das vom Server aus via FTP von meinem WEB-Server heruntergeladen wird) ALLE Programmdateien in eine Datenbank (in ein Blob-Feld) einlese, natürlich zusammen mit Datum und Größe in separaten Feldern. Der Client vergleicht dann einfach seine lokal vorhandenen Dateien mit denen in der Datenbank, und wenn eine älter ist, wird mit TBlobField.SaveToFile einfach die Datei aktualisiert. Mit jeder Haupversion ändere ich dann ein Datenfeld in der Datenbank-Struktur und damit verhindere ich dann sogar noch, dass sich Clients mit inkompatibler (älterer) Version im Netzwerk anmelden.

Einziger Nachteil: Ca. 150MB Speicherplatz für die Datenbank, aber ist das wirklich ein Nachteil?

Wir machen das bereits so mit Ausnahme des DB teils.
Garantiert wird es niemals passieren das wir alle Unsere Update relevanten dateien in die DB laden.
Aber einen Update Server wird es geben. Nur eben nicht jetzt.