Hallo, mal wieder :) ...ich hoffe, Ihr hattet ein schönes Jahr. :blush:

Ich bin bisher (wie bisher immer) nicht dazu gekommen, die bereits 2008 geplanten Features umzusetzen.

SuRun 1.2.1.0 hat einige Unzulänglichkeiten, besonders mit Windows 8.
Deshalb habe ich versucht, diese zu beseitigen und nenne das SuRun 1.2.1.1b2:

SuRun 1.2.1.1b2 - 2012-11-12
* FIX: In Windows 8 hat der IAT-Hook unzureichend funktioniert, da die API-Sets jetzt durch DLLs mit Namen "api-ms-win-*-l1-1-1.dll" (statt "api-ms-win-*-l1-1-0.dll" in Windows 7) implementiert sind
* FIX: Mit SuRun als Administrator gestartete Programme wurden in der Taskbar von Windows 7 und Windows 8 nicht der Jumpliste zugeordnet.
* FIX: Der ShellExecute-Hook wollte "file.exe" als administrator ausführen, when "file.exe.ext" normal gestartet werden sollte. Z.B. Wenn in einem Ordner "SetupApp.exe" und "SetupApp.exe.txt" sind und man im Explorer "SetupApp.exe.txt" doppelklickt, fragte SuRun 1.2.1.0 (und älter), ob "SetupApp.exe" administrativ gestartet werden soll.
* FIX: Das Benutzer-Bild hat auf Bestätigungs- und "Ausführen als"-Dialogen gefehlt
* FIX: Sehr lange Kommandozeilen wurden auf SuRuns Bestätigungs-Dialogen sehr unschön dargestellt

[EDIT:]
SuRun 1.2.1.1 wurde freigegeben.
Die aktuelle Version ist 1.2.1.1b8.
7 Tage später
Ich habe mich soeben einem gaaaanz alten Problem angenommen.

SuRun's Hooks konnten nicht so richtig mit x86<->x64 Szenarien umgehen.

Wenn ein x64 Hook einen Aufruf aus einem 32 Bit Prozess abfing, schmierte dieser ab und zu ab.

Ich hab's gefunden und war selbst Schuld. :blush: :'(
Die PROCESS_INFORMATION-Struktur ist in x86 (mit 16 Bytes) und x64 (mit 24 Bytes) verschieden groß. SuRun hat aber diese Struktur zur Übergabe der Prozess- und Thread-ID an den Client benutzt. So wurde im 32 Bit Client Speicher überschrieben und das konnte evtl. zu Schutzverletzungen führen. Auf jeden Fall aber wurde dem 32 Bit Prozess die Prozess-ID nie übergeben und Windows (7) selbst meckerte ab und zu über fehlerhafte Rückgabe-Werte.

Bei x64 Clients wurde der Zeiger auf den "Speicher zu Übergabe der Prozess-ID" nur 32-Bittig an den SuRun-Dienst übergeben... Das konnte nicht funktionieren.

Ich bin erstaunt, dass diese Fehler auch bei mir selbst nur selten auftraten. Jetzt sind sie weg. :-D

SuRun 1.2.1.1b3 - 2012-11-19
* FIX: Auf allen x64 Systemen hat SuRun bisher nie eine gültige Prozess-ID oder ein gültiges Prozess-Handle zurückgegeben.
* FIX: Auf x64 Systemen hat das Zusammenspiel der 32Bit Hooks mit dem 64 Bit Service nie richtig funktioniert. (Was zum selben Fehler, wie in vorigem Fix führte)
@SimooZ:
Ich habe Deine Beiträge in ein neues Thema hier hin verschoben.
6 Tage später
SuRun 1.2.1.1b4 - 2012-11-27
* FIX: SimooZ hat's entdeckt. Wenn man bei SuRun's "Ausführen als..." alle Buchstaben des Benutzernamens gelöscht hat, hat SuRun (blöder Weise!) den kompletten Registrierungszweig "HKLM\Security\SuRun" entfernt.
[indent]Die SuRun-Einstellungen aller Benutzer (Programmlisten, Kennwörter etc.) gingen verloren.
Alle Mitglieder von "SuRunners" bekamen deshalb vollen Zugriff auf das System.[/indent]

...bin nur froh, dass das noch keinem vorher aufgefallen ist... :blush:
Hallo Kay! Gute, von Ihnen zu hören. Ich hoffe, dass Google translate nicht geschlachtet meine Botschaft an Sie. :-)
16 Tage später
SuRun 1.2.1.1b5 - 2012-12-12
* Wenn SuRun in der Form "SuRun.exe <TypeYourStringHere>/irgendwas" gestartet wurde, <irgendwas> keine Dateiendung hatte und ein Registry-Eintrag für <irgendwas.[lnk|cmd|bat|com|pif]> unter "[HKCU|HKLM]\Software\Microsoft\Windows\CurrentVersion\App Paths" vorhanden war, dann hat SuRun irrtümlich angenommen, dass <PfadZu><irgendwas>.<ext> als Administrator gestartet werden soll.
[indent]Beispiel: Wenn Defraggler installiert ist, legt er einen Eintrag in "HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\Defraggler" an, damit das Kommando "Defraggler" ohne Erweiterung das Programm startet. Wenn der Benutzer nun "http://www.piriform.com/Defraggler" ausgeführt hat, nahm SuRun an, dass "C:\Program Files\Defraggler\Defraggler64.exe" ausgeführt werden soll[/indent]
* FIX: In allen x64 Windows Versionen haben SuRun's 32Bit Hooks "SuRun32.bin /TestAA" gestartet anstatt SuRun.exe. SuRun32.bin hing dann scheinbar für 240s und blockierte das "gehookte" Programm.
* CHG: Ein Bug in Online Armor verursacht einen Crash in allen Programmen, die sich mit einem Rückgabewert von (~GetCurrentProcessId()) beenden.
[INDENT]Beispiel: 
#include <windows.h>
#include <Shellapi.h>

int APIENTRY WinMain(HINSTANCE,HINSTANCE,LPSTR,int)
{
  return ~(GetCurrentProcessId());
}
SuRun umgeht das jetzt.
[/INDENT]
* CHG: Der IAT-Hook hängt sich in die ShellExecute(Ex)-Familie rein. Das ist notwendig, weil Windows im IShellExecuteHook-Interface das Flag SEE_MASK_NOCLOSEPROCESS nicht respektiert. Der Start der Online Armor Installation meldete so immer einen Fehler.
* CHG: Die Option "Kennwort speichern" im "Ausführen als.."-Dialog wird ausgegraut, wenn "Benutzer-Kennwort abfragen" ohne Wartezeit aktiviert ist
Hi!

Ich probiere gerade die 1.2.1.1b2 unter Win7 (64-Bit, SP1, englische Version) aus und mir fällt auf, daß seit der Installation der nützliche Shortcut Strg+Shift+Klick auf Icon der Startleiste nicht mehr funktioniert. Der sollte eigentlich das entsprechende Programm mit vollen Rechten starten bringt jetzt aber den Fehler, der für Verknüpfungen mit ungültigem Ziel üblich ist:
Can't open this item

It might have been moved, renamed, or deleted. Do you want to remove this item?
Hi,

ich habe die Meldung gerade nachvollziehen können. Es hängt mit der SuRun-Option "Ersetze Windows 'Ausführen als...' durch SuRuns 'Ausführen als...'" zusammen.
Ich suche mal, was da passiert.

Kay
Hallo Kay

Danke für die neue Version. Ich habe gehofft, dass sich mein Problem mit den Korrekturen gleich erledigt. Leider ist dem nicht so.

http://forum.kay-bruns.de/post/3848

Sonst funktioniert bisher alles wie es sollte.
Kay wrote: Es hängt mit der SuRun-Option "Ersetze Windows 'Ausführen als...' durch SuRuns 'Ausführen als...'" zusammen.
Stimmt, kann ich jetzt bestätigen. Die muß dann voreingestellt sein, denn verändert habe das eigentlich nicht. Ich habe sie vorläufig abgeschaltet, da ich "Ausführen als..." ohnehin nicht nutze. Danke für den schnellen Hinweis!


Übrigens stimmt die neue Versionsangabe im ersten Posting nicht. Da steht "Die aktuelle Version ist 1.1.2.1b5.", richtig ist aber SuRun 1.2.1.1b5. Ich hatte mich über die merkwürdige Versionierung gewundert ;-)
@SimooZ:
Bin noch nicht dazu gekommen, das mit der Gruppe zu untersuchen.
Wird aber vor Weihnachten noch näher untersucht ;-)
Niffleskin wrote: Übrigens stimmt die neue Versionsangabe im ersten Posting nicht.
Whoops. Hab's behoben.
Hallo Kay,

ich kann bestätigen, dass mit deiner Umgehung des Online-Armor-Fehlers in SuRun1211b5 auch hier die Surun-Fehler in der Ereignisanzeige von Win7 32-bit nicht mehr auftauchen.

Danke für deine Arbeit!

Ciao Franklin
2 Monate später
Vorab: Hier ebenfalls unter XP SP3 sehe ich keine Probleme dieser Art (mit keiner der bislang erschienenen Betas 1.2.1.1.
fraschi wrote:Von den rd. 50 per Autostart normalerweise startenden Programmen waren dann selbst nach etlicher Wartezeit höchstens eine Handvoll gestartet.
Von der überdurchschnittlichen Menge an Autostart-Programmen mal abgesehen: Ich frage mich, ob diese Programme ganz normal im Benutzerkontext gestartet werden oder über Surun mit erhöhten Rechten? Und unter den 50 (abzüglich der Handvoll) werden doch auch ein paar Programme dabei sein, die halbwegs bekannt sind und wo man bei Nennung etwas dazu sagen könnte.

Bedenke auch, daß in dem Fall, daß das ein generelles Problem wäre, Meldungen dieser Art hier in Massen aufgetaucht wären. Denn noch immer ist XP das am zweithäufigsten eingesetzte Betriebssystem.
Cosmo wrote: Vorab: Hier ebenfalls unter XP SP3 sehe ich keine Probleme dieser Art (mit keiner der bislang erschienenen Betas 1.2.1.1.
Deswegen sagte ich ja, dass es vermutlich nur hier an meiner Umgebung liegt und Kay es nicht weiter verfolgen muss.
fraschi wrote:Von den rd. 50 per Autostart normalerweise startenden Programmen waren dann selbst nach etlicher Wartezeit höchstens eine Handvoll gestartet.
Cosmo wrote: Von der überdurchschnittlichen Menge an Autostart-Programmen mal abgesehen:
Nun ja, auf dem Rechner wird halt mit vielerlei Helferproggis sehr effektiv gearbeitet, so dass ich Sachen in Minuten erledigt habe, wofür andere in ihrer Standard-Umgebung halt Stunden brauchten ... ;-) Aber es stimmt schon, damit die Menge an Autostart-Programmen mir nicht gleich nach einem Neuboot den Rechner von Anfang an blockiert, verwende ich für einen sukzessiven Start auch StartupDelayer. Und da ich die Kiste möglichst lange nicht boote, am besten nur einmal monatlich zu den MS-Updates, kann ich mit dieser langen Bootzeit auch ganz gut leben ... Ja, ich weiß, irgendwann ist mal aktuellere Hardware fällig ... ;-)

Momentan sind auf dem Laptop übrigens 131 Prozesse aktiv ...
Cosmo wrote: Ich frage mich, ob diese Programme ganz normal im Benutzerkontext gestartet werden oder über Surun mit erhöhten Rechten?
Teil, teils ...
Cosmo wrote: Und unter den 50 (abzüglich der Handvoll) werden doch auch ein paar Programme dabei sein, die halbwegs bekannt sind und wo man bei Nennung etwas dazu sagen könnte.
Wie gesagt, nachdem es nahezu alle betrifft - aber vielleicht würde ja nach Stunden Wartezeit auch noch das eine oder andere der genannten starten - ist ein Arbeiten mit dem Rechner (hier) so einfach nicht möglich. Aber gerne eine kleine Auswahl:

- Online Armor
- AlwaysMouseWheel
- BoxCryptor
- ClickOff
- Dropbox
- Locate32
- MyPhoneExplorer
- PerfMon
- ProcessHacker
- ProcessTamer
- STunnel
- SuRun
- SystemExplorer
- TClockEx
- WinSize2
- Avast5
- Ditto
- FindAndRunRobot
- GPGtray
- LibreOffice
- MagicDisc
- Microtek Scanner Finder
- sipgate X-Lite
- TioRes
- Taekwindow
- Taskix
- WinFlip
- YankyClipper
- Unlocker Assistant
- MoveME
- Printers
- PrintKey
und so weiter ... reicht das als kleine Kostprobe?
Cosmo wrote: Bedenke auch, daß in dem Fall, daß das ein generelles Problem wäre, Meldungen dieser Art hier in Massen aufgetaucht wären. Denn noch immer ist XP das am zweithäufigsten eingesetzte Betriebssystem.
Deswegen sagte ich ja, dass es vermutlich nur hier an meiner Umgebung liegt und Kay es nicht weiter verfolgen muss.

Franklin
Nachträglich gesundes Neues. :-)

SuRun 1.2.1.1b6 - 2013-01-05
* FIX: Der Kontextmenüeintrag "SuRun: Papierkorb leeren" wurde bei der Deinstallation von SuRun nicht gelöscht
* FIX: Der Kommandozeilenparameter "/SWITCHTO" hat in Windows XP x86 nicht funktioniert
* CHG: Bei aktivem "Ersetze Windows 'Ausführen als...' durch SuRuns 'Ausführen als...'" lässt SuRun in Windows Vista und neuer den Kontextmenüeintrag "Als Administrator ausführen", wie er ist. Das ermöglicht den direkten Start von Programmen mit gehobenen Rechten per <Strg>+<Shift><LKlick> in der Taskleiste von Explorer.
Kay wrote: Nachträglich gesundes Neues. :-)

SuRun 1.2.1.1b6 - 2013-01-05
* FIX: Der Kommandozeilenparameter "/SWITCHTO" hat in Windows XP x86 nicht funktioniert
Ersterem schließe ich mich an.

Zweiteres funktioniert wieder.
Es gibt ein Problem:

Der Aufruf von 
surun /switchto Benutzername
führt zu einem Absturz von Surun ("hat ein Problem und muß beendet werden"). Dabei spielt es keine Rolle, ob ich von einem Admin-Konto in ein Benutzerkonto wechseln will oder umgekehrt, ebensowenig, ob das Zielkonto bereits angemeldet ist oder nicht.

Beobachtet unter XP mit der aktuellen Beta 5 (wobei ich nicht weiß, ob die vorherigen Betas ebenfalls betroffen sind, ich habe es erst jetzt beobachtet). Mit 1.2.1.0 funktionierte es in derselben Maschine.
Hab's gefunden und behoben. Danke!

Nach den Feiertagen kommt die nächste Beta.
2 Monate später
Also, ich wollte nur mal mitteilen, dass ich mit dieser SuRun-Version (1.2.1.1.b6) auf meinem XP SP3-Laptop nicht arbeiten kann. Beim ersten Install-Versuch dachte ich noch, dass es an den gleichzeitigen MS-Updates (vom letzten Monat) lag, hab dann mühsam das letzte Backup zurückgespielt und die MS-Updates alle einzeln installiert (ohne dass dieser Zustand wieder auftrat).

Heute nun kam ich endlich zu einem erneuten Versuch mit der SuRun-Beta, der allerdings mit dem gleichen Desaster endete: Ich kann mich zwar in meinem eingeschränkten User-Account anmelden, aber es laufen nur einige wenige Programme ... bei etlichen Programmstart-Versuchen bekomme ich nur die Meldung, dass der Zugriff verweigert sei, ich womöglich keine ausreichenden Rechte hätte ... :-( Im Admin-Account ist von all' dem natürlich nichts zu merken und auf dem Win7-Rechner funktioniert diese Beta ja auch von Anfang an wie gewohnt.

Dummerweise dauert der Shutdown und der Neustart dieses alten Laptops jedes Mal mind. eine halbe Stunde, so dass ich (diesmal) keine große Lust auf weitere systematische Eingrenzungs-Versuche habe. Ich war jetzt rd. drei Stunden lang damit beschäftigt, den alten Zustand wieder herzustellen, weil sich die V 1.2.1.0 (mit der neuen Beta im Hintergrund) natürlich auch nicht einfach installieren ließ und das Löschen der Surun-Dateien natürlich auch nur mit Unlocker-Hilfe, Prozesstöten und Neustarten möglich war.

Ich bin daher am Überlegen, ob ich nicht auf meinem XP-Rechner einfach mit der 1.2.1.0 auf Dauer weiter fahren soll, weil ich ansonsten nämlich mit der Version auch soweit zufrieden bin.

Herzliche Grüße
Franklin
Impressum, Datenschutz