Beiträge von Andy

    Hi!

    Für WinRM existiert eine API, https://docs.microsoft.com/en-us/windows/win32/winrm/portal

    Zugriff dort gestaltet sich über Interfaces https://docs.microsoft.com/de-de/windows/win32/api/_winrm/

    Wsmandisp.h header - Win32 apps
    docs.microsoft.com


    Vom Thema habe ich wenig bis keine Ahnung, allerdings hatte ich mich im letzten halben Jahr intensivst mit Interfaces und deren Nutzung mit AutoIt beschäftigt.

    Der Einstieg ist sicherlich nicht simpel, lohnt sich aber m.E.

    - Wenn ich "nur so rumbrowse" dann mache ich das im Inkognito-Fenster, denn wenn ich das schließe, sind auch alle Cookies wieder gelöscht.

    - Bei meinen "Standard-Seiten", die ich besuche habe ich mir tatsächlich die Mühe gemacht, alles einzeln abzuwählen, so wie Bugfix es beschrieben hat.

    Genau SO mache ich das auch, in Opera ist das der Modus "Neues privates Fenster".

    Die Werbung entsorgt Pi-Hole nebenbei auf einem RasPi für alle Rechner und auch Smartphones im gesamten Netzwerk. Einige Webseiten, die ich unterstützen möchte und die auf Werbung angewiesen sind, werden gewhitelistet, der Rest wird geblockt.

    BugFix,

    du bist einer der wenigen "Programmierer" (aka Menschen überhaupt) die ich kenne, die ihren Arbeitsablauf rekapitulieren, analysieren, nach Verbesserungen suchen und diese umzusetzen versuchen.

    Ich versuche das jedenfalls auch immer...

    Das von dir beschriebene "Problem" ist sowohl job- als auch generationenübergreifend, und tritt in der Programmiererei besonders extrem zutage.

    Woher diese/unsere "lösungsorientierte" Eigenschaft/Fähigkeit kommt, kann ich mir auch nicht erklären, bin aber permanent auf der Suche nach Mitarbeitern, welche diese Anforderung erfüllen können.

    Leider habe ich in den letzten ca. 50 Jahren nur sehr wenige dieser außergewöhnlichen Exemplare kennenlernen dürfen.

    Ich habe aber das Gefühl, das diese Spezies langsam aber sicher ausstirbt.....oder ich liege falsch und eine mir unbekannte Macht führt diese Menschen auf direktem Weg in das Unternehmen und somit auch in das Leben ihrer Träume.

    Mehr zum Thema WebP API kann hier eingesehen werden: https://developers.google.com/speed/webp/docs/api.

    ....3 Sekunden gescrollt....und schon Krämpfe bekommen....

    KLUGSCHEISSMODUS ON


    KATASTROPHE!!!!

    So etwas passiert, wenn derjenige, der eine Dokumentation schreibt, keine oder nur unzureichende Ahnung hat, von dem was er dort tut!


    Das sog. "Padding" beschreibt "aufzufüllende" Bytes am Ende einer Zeile, wenn die Länge der Zeile in Bytes nicht ganzzahlig (meist durch 4 geteilt) in das einlesende Format (meist 4 Bytes =>DWORD) passt.

    Beispiel: Format BGR oder RGB (24BitPerPixel BBP): In der Zeile sind 3 Pixel, multipliziert mit 3 Byte per Pixel ergibt 9 Bytes. Damit diese Zeile in DWORDs eingelesen werden kann, muss auf die nächste durch 4 teilbare Zahl an Bytes, also in diesem Fall 12 Bytes, aufgefüllt werden. Man hängt also an die 9 Bytes "Pixel" noch 3 (idR Null-)Bytes an!


    Ein sowieso durch 4 Bytes teilbares Format, (hier 32 Bit/4 Bytes) BGRA oder RGBA hat NIEMALS padding Bytes!

    Erstens setzt die Beschreibung vorraus, dass man sich den "Teiler" zur Ermittlung des Padding, also die in Bitmaps (idR verwendeten 4 oder welche Zahl auch immer) Bytes als Teiler der Zeilenlänge aus den Fingern zieht, in der Dokumentation steht dazu jedenfalls nichts!

    Zweitens ist die Darstellung in Tabellenform schlicht falsch, "padding bytes" sind nur bei den Formaten RGB/BGR erforderlich....


    Da ich aber davon ausgehe, dass diese API ausschliesslich von Leuten verwendet wird, die wissen, was sie dort tun, stelle ich mir einfach nur das kurze Grinsen derjenigen vor, die diesen "Fail" auch bemerkt haben :klatschen:


    KLUGSCHEISSMODUS OFF


    Habe auch mal in den Source-Code geguckt...ist natürlich vom allerfeinsten^^




    UEZ

    Klasse Arbeit!! :thumbup:

    Hast du die *.h-Files nach Freebasic transferiert und dann mit den *.lib Dateien gelinkt?


    Da ja sämtliche ausführbaren Dateien als Kommandozeilenversion vorliegen, könnte man über eine schicke AutoIt-GUI nachdenken...incl. Vorschaufunktion ggf. per UEZ´s UDF...

    Ich hab etwa 2000 Zeilen Spaghetticode fabriziert

    ...willkommen im Club....

    Ich bin durch eine Augen-OP seit einigen Wochen ziemlich eingeschränkt, daher weiß ich nicht, ob ich überhaupt bis zum Termin fertig werde. Aber die 50% habe ich schon (halbwegs locker) geknackt, sogar bei (*.unkomprimierteEXE-Binärdateien)

    Hi,


    auf https://steamcommunity.com/dev erhälst du Zugriff auf die Steam-API (aktuell HIER).

    Dort kannst du über die Funktion GetOwnedGames sowohl die Userdaten, als auch das/die vom User bei Steam registrierten Spiele erhalten. Da diese Daten bei Steam abgefragt werden und nicht lokal (wie es die Spiele aufgrund des Offline-Modus machen müssen) bekommst du reale Daten. Der User muss zwangsläufig, wenigstens für die Abfrage bei Steam, online sein.

    Ich hatte auch erst anfangs Probleme mit dem Entpacken. Ich schaue per "Doppelklick" in die Zip-Datei, markiere dort die für mich interessanten Dateien, und kopiere sie in das von mir verwendete Verzeichnis.

    Das hat nicht funktioniert. Sehr seltsam...

    Was aber problemlos funktionierte war, die Dateien aus der Zip in das Downloadverzeichnis zu entpacken und von dort zu kopieren.


    AspirinJunkie

    Ich konnte die Ergebnisse von dir verifizieren, plus minus 10-20% in den Zeiten sehe ich bei diesen Laufzeiten der Scripte bei AutoIt einfach mal als "gleich" an^^

    Einzig die Datenbank/SQL-Scripte liefen bei mir ca. Faktor 30 schneller ab?!

    Welche Umgebung/Prozessor/Version nutzt du?


    Was als "Essenz" zu Maps eigentlich übrig bleibt, ist das es (wie so vieles andere in den "neumodischen" Programmiersprachen auch) überflüssig ist wie ein Kropf!

    Es gibt gegenüber den etablierten Methoden/Funktionen/Objekten Array und Dictionary(s) keinerlei Vorteile!

    Und so wie ich das sehe, weiß das Jos sehr wohl! Daher auch genau der "inoffizielle" Status in der aktuellen AutoIt-Version...

    Maps, kann man haben, muss man aber nicht!

    Hi AspirinJunkie!

    Du hast dich in dieses Thema ja "damals" voll reingekniet. Respekt jedenfalls dafür!

    Hat sich seit dem bzgl. Geschwindigkeit/Ansprechverhalten/Usability etwas gravierend geändert?

    Assoziatives Array als 2D-Array mit binärer Suche hinzugefügt - interessantes Ergebnis da dies bei großen Datenmengen auch Map und Dictionary überholt.

    Ist das immer noch so?

    Aktuell läuft bei mir ja alles in der 3.3.14.5. Ich warte da vielleicht noch etwas.

    Ich warte SICHER noch etwas...und zwar idR bis zur nächsten Version. Um dann auf die "alte" (für mich neue) umzusteigen. Das hat in den letzten Jahren gut funktioniert, da üblicherweise in den Wochen/Monaten nach Release der neuen Version reichlich Bugs gemeldet wurden, welche dann wiederum gefixt (oder aber auch nicht!) wurden....

    Wenn dann wirklich "stable" angesagt ist, drängen die User dann schon wieder auf eine "neue" Version, die dann auch bald erscheint...und der Kreis schließt sich, das Rad / die Mühle fängt sich wieder an zu drehen... :theke:

    Da VBA standardmäßig dazu gehört - eigentlich doch.

    Wobei sich mir immer wieder die Frage stellt, wieso man nicht direkt VBA nutzt statt AutoIt. Irgendwer muss ja die ganzen Excelsheets füllen, oder machen das die Leute alle "von Hand"? Und ja, das ist eine rhetorische Frage, 99% alle Excel-User tippern die Daten von Papierzetteln ab, oder kopieren oder schreiben aus andern Tabellen ab... :Face:

    Ein typisches XY-Problem:"...ich bekomm es in Excel nicht hin, also frag ich mal im Autoit-Forum, wie die das machen würden."

    Ich schätze diejenigen Excel.au3-Anwender, die die Daten aus Excel in anderen Programmen (NICHT AutoIt(!)) verwenden, auf unter 1%.

    Bei mir ist das genau umgekehrt, ich nutze in Excel zu 99% VBA und AutoIt nur, wenn Daten aus Excel in andere Software "eingetragen" werden muss. Aber selbst diese Scripte werden dann von VBA gesteuert.

    Ist also technisch gesehen ein Pastebin-Upload der zu "komprimierenden" Daten und das Ausgeben der ID (8 Zeichen) eine valide Methode? :party1:

    Warum nicht?!

    Jetzt höre ich schon das Geheule! Und genau dieses Geheule kommt von den Leuten, die Nervenzusammenbrüche bekommen, wenn sie, mit welchem Gerät auch immer, NICHT online sind :Face:

    Aber mal ohne Witz, ob man heutzutage eine Textdatei mit einer Größe von einigen Kilobytes versendet, oder nur 40% von einigen Kilobytes, das ist bei der Menge an Müll, der heutzutage das Internetz flutet, völlig unerheblich ;)

    Wahrscheinlich sehe ich das so locker, weil ich bei keinem einzigen dieser "sozialen" Medien einen Account habe und deshalb zwangsläufig online sein MUSS. Was nicht bedeutet, dass ich nicht für sämtliche Internetfähigen gadgeds Software erstelle. Bei denen auch des öfteren Komprimierungsalgorithmen verwendet werden :rock:

    Das wäre dann wieder soetwas wie: Ich habe das Wörterbuch nicht in den Komprimierten Daten, und ohne das Wörterbuch sind die komprimierten Daten keine valide Beschreibung der unkomprimierten Daten...

    Aber das ist doch genau der Punkt! Ähnliches hatte ich bereits in #31 gepostet.

    Ab wann tut denn das Wörterbuch im Script/Programm "weh"?! Genau DAS ist das Problem!

    Der aktuelle Download von 7-Zip ist entpackt auf der Platte etwas über 5MB, davon Programm und DLL zusammen 2.5 MB.

    Ein vom allerfeinsten C(++)-Compiler erstelltes Kompressions-Programm, dessen "Packcode" auf eine DIN-A4 Seiten passt?!

    Im Leben nicht..... ^^

    "Natürlich" ist der eigentliche Packcode Pillepalle, das wirklich Aufwendige ist die Analyse und die "optimale" Auswahl eines der dutzenden von Verfahren um "eine Handvoll Bytes" einzusparen.


    Wenn ich ein compiliertes AutoItscript mit 500KB =O ansetze, dann blieben mir, um mit der Dateigröße von 7-Zip mitzuhalten, also 2MB an "Daten" die ich in der Datei unterbringen könnte!

    2MB an verschiedensten "Wörterbüchern" oder neuronalen Netzen oder was auch immer.....


    Und btw.: der Kollege Lambdax könnte das von ihm benötigte "Wörterbuch" unkomprimiert 300x nacheinander in seine EXE schreiben und die Datei wäre immer noch kleiner als 7-Zip und würde besser komprimieren! Soviel zum "Problem"! :theke:

    Hmmmmmm, interessanter Ansatz, den ich mir auch schon überlegt hatte! 8o

    Nirgendwo ist die maximale Größe des Scriptes definiert.

    Wenn ich also bspw. die Wortliste des Openthesaurus (Größe ca 2 MB und soviel ist das garnicht, die könnte man nämlich vorher komprimieren :rofl: ) in mein Script includiere, dann damit einen "optimalen" Baum aufspanne und dann einfach nur "dröge" ersetze, dann ist das ziemlich nah am Optimum!

    Aber wie bereits oben von mir gesagt.....reine Fingerübung und daher völlig außen vor, jedenfalls bei mir.


    Hier geht es darum, sich selbst ein Verfahren zu überlegen, also einen Algorithmus umzusetzen.

    Hehe, böse betrachtet könnte man ja die Scriptgröße * Kompressionsrate bewerten.... :Face:

    PS: Da geht aber noch was... Benutze deine Fantasie :P

    (auch wenn es verlockend ist, Algorithmen zu nutzen die weit verbreitet und erprobt sind. Wir sind hier ein Forschungsteam, wir brauchen den neuen Stuff

    GENAU SO sehe ich das auch....

    Den Code von den entsprechenden Webseiten abklimpern oder Verfahren "kopieren" das sollen Leute machen, die Fingerübungen brauchen, denn mehr ist das imho nicht.

    Ich habe vor langer Zeit mal etwas gebastelt (ein adaptiver Huffman Codierer mit coolem Tree der sich dynamisch anpasst), der läuft aber mit ca. 1 BYTE pro Sekunde^^ Also vermute ich, dass der Algorithmus in nativem AutoIt (ohne Dllcalls) mit sagen wir mal: 128+Byte/s klarkommen muss

    So etwas will ich hier sehen! :thumbup:

    Übrigens ist es sehr produktiv, solche Gespräche in einer Kneipe zu führen und dabei die "dynamischen Bäume" hinten auf Bierdeckel zu kritzeln...das wäre übrigens mal wieder fällig :party:



    Ich bin aktuell schon bei ziemlich guten Kompressionsraten von Textdateien, einiges hatte ich allerdings schon im Deskstream-Script und auch in der Steganographie erstellt.

    7-Bit-ASCII, Lauflängenkodierung und ein etwas abgefahrener "Baum" und natürlich wieder mal Gequetsche von mehr als 12 Bits in ein Byte :rock:, das ist mein aktueller Stand. Bei Textdateien liege ich "ziemlich gut" im Rennen, wenn auch langsam....aber wie üblich, habe ich, sobald alles läuft, auch eine Assemblerversion (SSE und AVX512)

    Das aufwendigste ist aktuell, die Bits zusammenzuquetschen, d.h. an Bitadressen zu schreiben/zu lesen und nicht an Byteadressen!

    In Assembler ist das ziemlich einfach und auch schnell. Naja, vielleicht schreibe ich in AutoIt die Bits einfach als 1 und 0-Char nacheinander in eine Bytestruct und lese von dort dann in 32er Paketen über eine LUT die DWORDS aus....schaumamal.


    Wenn man das alles macht schätze ich, dass locker 50%+ drin sind

    Da ist jetzt schon wesentlich mehr drin^^ 8o

    Aber in dem Dilemma stecke ich aktuell auch fest: Gebe ich den (dynamischen) Baum mit in den komprimierten String, dann tun bei kleinen Strings die 256/512 Bytes so richtig weh....bei sehr großen Strings fällt das dagegen kaum auf.

    Das blöde dabei ist, dass bei großen Textdateien der statische Baum völlig ausreichend ist und ich nur ein Bit im komprimierten String brauche, um diesen zu aktivieren.

    Wobei ich auch bei Nicht-Textdateien (*.EXE Bilddateien usw.) mittlerweile schon unter 50% gelandet bin (bei Verwendung von dynamisch erstelltem Baum)

    Ja, ich dachte ich komme an Algebra vorbei, denn das in AutoIt umzusetzen ist ja wie o. g. von AspirilJunkie u. Andy ein Aufwand den ich noch nicht ganz nachvollziehen kann.

    Das was AspirinJunkie und ich als Scripte gezeigt haben ist ein mathematisches Verfahren zur Lösung linearer Gleichungen. Also Stoff aus dem Mathe-Untericht 9. Klasse (auch in Dänemark^^)

    Wenn du x Gleichungen mit x Unbekannten hast, dann ist dieses System IMMER lösbar!

    Ich habe versucht eine eigene Formel zu erstellen:

    Was du nicht brauchst, denn wenn du x Gleichungen hast mit x Unbekannten, dann kannst du das auch lösen!


    Ich brauche die Lösung für dieses Problem, da ich etwas größeres vorhabe. Ich möchte was codieren.
    Klartext: Passwort
    Codiert 1: 2072674714768072


    Den Code sollte man nämlich nicht so einfach "knacken" können. Oder?

    Wenn du auf der Grundlage linearer Gleichungen eine "Verschlüsselung" machen willst, bekommst du definitiv Probleme bei der Sicherheit, wenn du "normale" Zahlen verwendest.

    Das Problem ist, dass du anhand des Ergebnisses IMMER die Faktoren bestimmen kannst!

    Um dein Gleichungssystem und deine Verschlüsselung zu "knacken" brauchst du also nur eine bestimmte Anzahl Klartexte und die daraus kodierten Passwörter.


    In der Kryptologie gibt es viele Verfahren die eben genau deswegen NICHT (so einfach) umkehrbar sind. Beispielsweise werden dort SEHR große Zahlen durch die Multiplikation von ebenfalls SEHR großen Primzahlen erzeugt. Umgekehrt dauert es auch mit heutigen Rechnern extrem lange, diese großen Zahlen wieder in ihre Primfaktoren zu zerlegen.


    Aber ich glaube sowieso, dass du eher im Bereich einer kryptografischen HASHfunktion suchen solltest!

    Eine HASHfunktion erzeugt aus einem Klartext einen entsprechenden Ausgabewert. Das gute an der Hashfunktion ist, dass selbst wenn sich in der Eingabe nur EIN BIT (!) ändert, sich der Ausgabewert komplett ändert. Man kann auch nie vom Ausgabewert auf den Eingabewert rückschließen bzw. diesen "einfach" berechnen. Beispiele sind MD4 oder MD5 oder SHA...die kennst du sicher oder hast schon mal etwas davon gehört!

    Der Sinn ist, Passwörter NIE direkt abspeichern zu müssen, sondern NUR den Hashwert.

    Wenn du also dein Passwort eingibst, dann wird daraus der Hashwert berechnet und NUR DER wird im Programm/Datenbank mit den Zugangsdaten abgeglichen.

    Ein Hashwert ist in der Regel auch immer gleich lang, egal wie lang der Eingabewert ist! Man kann also nicht aus der Länge des Hashwertes auf die Länge des Passwortes schließen.


    Ich selbst habe schon mehrere Hash-"Generatoren" geschrieben bzw. selbst ausgedacht und in Programmen eingesetzt, im Prinzip ist das nur Bitschieben- oder rotieren, bzw Bitmanipulation. Zusätzlich noch einige Bits "einstreuen" (ähnlich SALT) dann bist du fertig.

    Wichtig ist nur, dass die Funktionen nicht umkehrbar sein dürfen! Und eine GUTE selbstgeschriebene (und für andere bis dato unbekannte) Hashfunktion ist immer besser als eine der bekannten, wie bspw. MD5 oder SHA-1!

    Hi,

    lineare Gleichungen lösen....da hatte ich vor Jahrzehnten mal was gebastelt, sogar mit GUI^^

    Seitdem wird dieses Script immer wieder mal von mir benutzt, wer Spass hat, kann ja die GUI auf "schön" umfunktionieren.

    Und btw. es wird das Gaußsche Eliminationsverfahren verwendet.

    wird autoit sowas wie ein Bool False in String "False" umwandeln was buggs hervorrufen könnte.

    "Bugs" sind das nicht! Jedenfalls nicht, solange der "Programmierer" weiß, was er da tut. Ein Bug ist ein Fehler in einem Programm wo der Programmierer eben genau an dieser Stelle NICHT gewußt hat, was er da tut oder "davon ausgegangen ist" das das richtig war was er getan hat.

    Wenn der Inhalt der Variablen und deren Typ klar sind, und auch nachvollzogen werden können, dann ist es schwer, "Bugs" zu erzeugen.

    Daher gibt es in AutoIt/Scite in den Tools ja auch die Menge an Debugging-Funktionen, die imho viel zu wenig genutzt werden...