Denn wer es wirklich nötig hätte, könnte aus dem bestehenden es leicht umschreiben.
Die die es nötig haben, sind (wie auch unser ehenmaliger Verteidigungsminister) C&P-Künstler, die genau wie dieser eben NICHT "leicht umschreiben" können^^.
Wzbw...
BTT: Bugreports und weitere Ideen sind natürlich gerne gesehen^^
Auch wenn schon einige gefragt haben, NEIN, eine Tastaturübertragung egal in welche Richtung wird NICHT implementiert. Wer Interesse und reichlich Kleingeld hat, kann diese bei mir anfragen. Ich behalte mir wie üblich vor, Angebote in welcher Höhe auch immer, abzulehnen.
Naja, da kann man ja die Bildschirmtastatur verwenden 
Naja, da kann man ja die Bildschirmtastatur verwenden
kaum versucht man, die Botkiddies erfolgreich davon zu überzeugen dass es nicht geht, kommt wieder so ein crack daher und verpetzt die versteckten Features 
Naja, wenigstens hast du nicht das Tastaturkürzel verraten, daran scheitern dann wieder 98,7% 
Tastaturkürzel? Bildschirmtastatur? Keine Übertragung von Tasten?
@MatthiasG: Bestimmt ist irgendwo ein Tastenkürzel im Deskstream-Quellcode versteckt 
....ganz bestimmt!
Habe eben mal mit 2 Rechnern bei mir im Netzwerk gestestet.
Wenn ich mit dem Mausrad zoomen will, dann funzt das nur wenn man das in Zeitlupe macht. Das zoomen wird nicht richtig an den Server weitergeleitet.
Bei einem Mausklick im Client wird nicht an der entsprechenden Position im Server geklickt.
Meistens spinnt dann die Clientanzeige vollkommen rum und das Bild wird invertiert.
Habe es auf 2 Rechnern mit Win7 Ultimate 64 im Gigabit Netzwerk am laufen.
Meistens spinnt dann die Clientanzeige vollkommen rum und das Bild wird invertiert.
Das passiert wenn _LZNTDeCompress einen Fehler veruhrsacht. Meißtens sieht man das nur als Pixel ausfall im Bild oder wie bei dir indem sich der betroffende Teil einfach Invertiert.
Leider haben wir bis jetzt nur die Huffmann Komprimierung gefunden als würdigen Ersatz in bezug auf Schnelligkeit und Komprimierungsstärke.
Das mit dem Anzeigefehler schein daran gelegen zu haben, das ich beide Scripte aus Scite heraus am laufen hatte.
Wenn ich beide Sripte compiliere dann kommen die Grafikfehler nicht mehr und ein Mausklick wird mit ca 2-5 Sekunden Verzögerung weitergeleitet.
Irgendwie wird der Mausklick viel zu spät verarbeitet.
Das Zoomproblem bleibt weiterhin. Wenn man das Scrollrad schnell dreht, dann hat der Zoomfaktor was von Glücksrad spielen. 
Irgendwas wird schon gesetzt nur nicht der Im Client angezeigte Zoomfaktor 
Das passiert wenn _LZNTDeCompress einen Fehler veruhrsacht. Meißtens sieht man das nur als Pixel ausfall im Bild oder wie bei dir indem sich der betroffende Teil einfach Invertiert.
Leider haben wir bis jetzt nur die Huffmann Komprimierung gefunden als würdigen Ersatz in bezug auf Schnelligkeit und Komprimierungsstärke.
Naja, die LZ-Familie und Huffmann sind zur Zeit wohl die Algorithmen, bei denen man den besten Kompromiss zwischen Komprimierung und Geschwindigkeit finden kann.
Nur so nebenbei: habt ihr euch schon zlib / LZ77 angeschaut?
Meistens spinnt dann die Clientanzeige vollkommen rum und das Bild wird invertiert.
Das invertierte Bild war das feedback für ein komplett neues Frame im Falle fehlerhaft übertragener Daten (lost Packets). Das kann aber auch im Script durch Austausch von SRCINVERT in SRCCOPY in ein "normales" Bild abgeändert werden.
Mausklick wird mit ca 2-5 Sekunden Verzögerung weitergeleitet.
Das "Hauptproblem" ist das inzwischen abgeänderte Protokoll der Datenübertragung.
Wenn nicht gerade Videos übertragen werden, werden ca. 40-50x pro Sekunde einige Handvoll Bytes (jeweils nur die veränderten Daten und die auch noch komprimiert) übertragen. Da macht es dann garnichts aus, wenn mal Fehler bei der Übertragung auftreten, das nächste Frame gleicht das in Sekundenbruchteilen aus.
Bei Video sieht das dann ganz anders aus. Das Datenpaket ist dann unter Umständen einige hundert kB gross, und dann tritt bei fehlerhafter Übertragung folgendes Procedere auf: Um sicherzustellen, dass der TCP-Puffer definitiv leer ist, habe ich eine Wartezeit von bis zu 2 Sekunden (oder 500ms) eingebaut.
Habe so etwas ähnliches wie einen Handshake eingebaut, aber in der neuesten Version nicht mehr Geschwindigkeitsoptimiert.
Das Ganze schreit natürlich nach kleinen Blockgrößen, schaumal....
Nur so nebenbei: habt ihr euch schon zlib / LZ77 angeschaut?
Ich hatte Huffmann als AutoIt-Script laufen (langsam^^), um das Einsparpotenzial herauszufinden. Ehrlich gesagt, lohnt für mich der Aufwand gegenüber der von uns verwendeten Komprimierungsfunktion nicht, welche aus der Windows-API entliehen ist.
Unsere "billige" Lauflängenkodierung und bissl Bitgeschiebe bringen zzt. schon Komprimierungsraten, die ohne größeren Aufwand nicht mehr weiter zu toppen sind. Habe auch testweise einige dll´s ausprobiert, aber ehrlich gesagt halte ich es nicht für nötig, etliche Kilobytes an externer dll anzuhängen, um einige Bytes einzusparen! Wer Videos übertragen will/muss, soll sich dementsprechende Software anschaffen^^
Jedenfalls bleibt noch reichlich zu tun, ich würde gerne den ASM-Teil auf 64 Bit bringen, damit man in Abhängigkeit vom System auch damit compilieren kann.
Das "Mausrad"-Problem ist auch schon in Mache, genau deswegen hab ich das gesamte Protokoll (Handshake usw) umgestrickt.
Sorry, aber war mein Fehler, ich hab seit Ende Februar diese Version und dachte, ich hätte diese damals an Sprenger120 geschickt. Das war nicht so, irgendwie hab ich einen dicken c&p-Fehler verzapft....
Heute hab ich dann zufällig diese "alte" Version runtergeladen und ausprobiert und nicht schlecht geguckt als ich den MIST sah!
Deshalb kam mir Raupis Posting auch so komisch vor, das war zu diesem Zeitpunkt bei mir nämlich längst erledigt^^.
Viel Spass mit dem "richtigen" DeskStream!
Das ist wirklich gut geworden. Ich wünsche mir nur noch, dass das Seitenverhältnis erhalten bleibt.
Das ist wirklich gut geworden.
wir betrachten uns als geehrt 
Ich wünsche mir nur noch, dass das Seitenverhältnis erhalten bleibt.
Ok, gute Idee! Das heisst, man würde im Client nur noch die Breite des Fensters angeben, und die Höhe würde automatisch an das Seitenverhältnis auf Serverseite angepasst werden....
Ok, gute Idee! Das heisst, man würde im Client nur noch die Breite des Fensters angeben, und die Höhe würde automatisch an das Seitenverhältnis auf Serverseite angepasst werden....
Ja, so ungefähr. Ich würde die maximale Größe eventuell noch durch die Bildschirmauflösung des Clienten beschränken und falls ihr Lust darauf habt, könntet ihr das Seitenverhältnis auch dynamisch anpassen, falls die Auflösung des Servers geändert wird.
Ich habe mir euer DeskStream2 nun auch einmal angesehen. Für Autoit nicht übel !
Ich würde mir eine Verbesserung wünschen, die bisher in allen Remote-Tools nicht möglich war:
Ich möchte nur 1 Fenster sehen, welches auf dem Zielrechner läuft. Könnte man euer Tool dahingehend umbauen, das man einen Fenstertitel (-teil) des Servers mitgibt, und man dann im Client nur den Inhalt dieses Fensters bekommt, wenn es vorhanden ist ?
Dadurch würde sich auch die Menge der übertragenden Bildinformationen deutlich verringern und man bekäme für dieses eine Fenster eine schnellere Darstellung.
Ich würde mir eine Verbesserung wünschen, die bisher in allen Remote-Tools nicht möglich war:
Ich möchte nur 1 Fenster sehen, welches auf dem Zielrechner läuft. Könnte man euer Tool dahingehend umbauen, das man einen Fenstertitel (-teil) des Servers mitgibt, und man dann im Client nur den Inhalt dieses Fensters bekommt, wenn es vorhanden ist ?
Micha_he: TeamViewer kann das 
