SQL Open-Source Tool: Windows-Anwendungen über den Accessibility Tree steuern (Rust)

[gabbercopter]

Moin zusammen,

ich habe ein kleines Open-Source Projekt entwickelt, das ich gerne teilen möchte: DirectShell.

Kurz gesagt: Es liest den Windows Accessibility Tree (die Schnittstelle die normalerweise für Screenreader gedacht
ist) und schreibt alle UI-Elemente einer Anwendung in eine SQLite-Datenbank. Damit kann man Programme per SQL abfragen
und auch Eingaben injizieren — oder als Proxy Abfangen und verändern. Es funktioniert soweit ich das sehe mit jeden Programm das WA nutzt was ~ +99% sein dürften.

Das Ganze ist in Rust geschrieben, ca. 1,2 MB groß, und läuft als Overlay das man auf beliebige Fenster "snapt".

Gedacht ist es vor allem als Baustein für Automatisierung und als Schnittstelle für KI-Agenten, aber auch für alle die
programmatisch mit Desktop-Anwendungen arbeiten wollen ohne auf OCR oder Pixel-Erkennung angewiesen zu sein.

Im Grunde ist es ein Primitivum das jedes X- Beliebige Programm Forked , Automatisch eine SQL Lite DB erstellt sowie weitere sub Dateien Generiert welche es :

• Jedweigen Scripten , Programmen , Code usw
• Sowie KI Modellen und Agenten

Ermöglicht Jedes Programm Nativ zu Lesen , Benutzen und zu Manipulieren.

Im Grunde ist es eine Automatisch entstehende art API unabhängig davon ob das Programm eine API besitzt. Es funktioniert also ebenfalls mit alter legecy Software oder Prioritären API Programmen.

Das wichtige ist dabei aber es " Hackt" nichts , ändert nichts , bricht ,keinerlei sicherheits Mechanismen und bricht damit keine TOS , AGB oder ein Gesetz.

und da die WA Schnitstelle in über 180 Ländern Rechtlich geschützt ist ist es auch nicht Patchbar.

Repo: https://github.com/IamLumae/DirectShell
Whitepaper: https://dev.to/tlrag/-directshell-i...niversal-app-interface-no-screenshots-no-2457 ( Volle Technische Version im Short Paper Verlinkt sowie ein Live Demo Video)
Lizenz: AGPL-3.0 also open source und free to use für alles und jeden der es nicht Kommerziell nutzen will.

Bin gespannt auf Feedback und Fragen. Ist natürlich noch Day 1 — es gibt genug Ecken und Kanten, aber die Grundlage
steht.

Grüße Martin

 

[madmax2010]

Kurz gesagt: Es liest den Windows Accessibility Tree (die Schnittstelle die normalerweise für Screenreader gedacht

bisschen witzig
Leider ist das etwas wo viel Software nicht gut drauf achtet, aber fue menschen die darauf angewiesen sind, ist das schon zwingend notwendig.

In der ganzen LLM Computer Use Diskussion über den den Sinn von UIs in einer Zeit von Agenten und Spracherkennung ging es ja das letzte Jahr viel um MCPs vs APIs - MCPs sehe ich noch nicht unbedingt,denn wir haben schon hervorragende API Formate. Es braucht nicht unbedingt was ganz neues.
Aber aus UI sicht (und darauf schauend wie du das tool gebaut hast) ist das ein weiterer sehr cooler Ansatz

 

[gabbercopter]

@madmax2010 Hey erstmal - 37.019 Beiträge ! Ich dachte ja immer ich bin schon gut dabei aber das?


Vielen Dank für dein Feedback — und dafür, dass du den Ansatz als interessant (und vielleicht auch ein wenig exotisch) anerkennst.

MCP Vs API ist tatsächlich ein spannendes Thema. Interessanterweise neigen KI-Agenten, wenn man sie fragt, dazu MCP als den überlegenen Ansatz zu bezeichnen — schlicht weil er für sie einfacher zu nutzen ist. Aber es gibt auch objektive technische Gründe, warum ich persönlich (in Bezug auf KI) MCP vorne sehe.

1. Standardisiertes Tool-Discovery: Bei klassischen APIs muss der Agent wissen welche Endpoints existieren und wie sie aufgebaut sind. MCP bietet ein einheitliches Discovery-Protokoll — der Agent fragt "Was kannst du?" und bekommt strukturierte Antworten. Kein Handbuch nötig.

2. Bidirektionale Kommunikation: APIs sind Request-Response. MCP erlaubt dem Server auch proaktiv Kontext zu liefern, Rückfragen zu stellen, oder den Agenten über Änderungen zu informieren.

3. Composability: Ein Agent kann mehrere MCP-Server gleichzeitig nutzen — Dateisystem, Datenbank, GUI-Steuerung — über ein einheitliches Protokoll. Bei APIs braucht jede Integration eigenen Glue-Code.

Aber das ist letztlich eine Protokoll-Frage und nicht der Kern von DirectShell. Zur Hauptfrage — nämlich ob ein neuer Ansatz überhaupt nötig ist. Hier würde ich gerne auf ein paar konkrete Punkte hinweisen, wenn wir darüber sprechen wie KI/Agenten derzeit mit Programmen und UI interagieren:

1. Tokenkosten: Vision vs. DirectShell

Jeder Screenshot-basierte Agent verbraucht pro Wahrnehmungsschritt:

• Screenshot (1080p): 1.200–1.800 Tokens
• Screenshot (1440p): 2.000–5.000 Tokens

( kann Model und Anbieter Spezifisch Variieren die versuchen da derzeit alle "ökonomischer" zu werden das hier sind erstmal die RAW werte für die base64 inline codierten Bilder. Und man Bedenke selbst einfache Aufgaben Produzieren gerne 5-10 Davon.

DirectShell:

• ".snap" Datei (alle bedienbaren Elemente): 50–200 Tokens
• SQL-Query (gezielte Frage): 10–50 Tokens
• Delta-Events (was hat sich geändert?): 20–50 Tokens

Bei einem 50-Schritt-Workflow: ~$0.60 in Vision-Tokens vs. ~$0.005 mit DirectShell. Faktor 120. ( Grobe werte müsste man mal exakt ausrechnen)

2. Nicht jedes Programm hat eine API

Das ist vielleicht der wichtigste Punkt. APIs und MCPs sind großartig — wenn sie existieren. Aber SAP GUI, DATEV, jede 20 Jahre alte Branchensoftware, jedes Spezial-Tool in der Buchhaltung: Da gibt es keinen REST-Endpoint. Da gibt es nur ein Fenster. DirectShell gibt diesen Programmen eine universelle Schnittstelle — ohne Zutun des Herstellers.

3. Latenz

Vision-basiert: Screenshot aufnehmen → Cloud-API → Vision Model Inference → Koordinaten schätzen → Klick simulieren → nächster Screenshot. 2–5 Sekunden pro Schritt.

DirectShell: Lokale SQLite-Abfrage in Mikrosekunden. Kein Cloud-Roundtrip. Kein Vision-Model nötig. Funktioniert komplett offline mit jedem lokalen LLM. das Intelligent genug ist.

4. Zuverlässigkeit und Erfolgsquote

Hier die aktuellen Benchmarks (OSWorld, NeurIPS 2024-2026 — der Industriestandard):

| Agent | Architektur | Erfolgsquote |
|-------|------------|:------------:|
| AskUI VisionAgent | Screenshot + Vision | 66,2% (Spitzenreiter) |
| OpenAI Operator (CUA o3) | Screenshot + GPT-4o | 42,9% |
| Claude Computer Use | Screenshot + Claude | 22–28% |
| Mensch | Augen + Hände | 72,4% |

Durchschnittliche Zeit pro Task: 10–20 Minuten für KI-Agenten. 30 Sekunden bis 2 Minuten für Menschen.

Was DirectShell an Tag 1 erreicht hat:

| Task | Zeit | Tokens |
|------|:----:|:------:|
| 360 Zellen in Google Sheets füllen (SOC Incident Log, 30x12) | ~90 Sek | ~150 |
| Komplette Claude.ai Konversation lesen | ~2 Sek | ~200 |
| Cross-App Kommunikation (CLI → Browser) | ~60 Sek | ~200 |

Keine Screenshots. Kein Vision-Model. Keine Koordinaten-Schätzung.

Und man muss hier noch Bedenken KI sind Pattern Matching Systeme. Nur für Directshell gibt es noch keine Erfahrung. Keine Trainingsdaten kein " wie geht das". Es fehlt an " config" datein für jedes programm das einmal von einer Ki " erforscht" wurde und die sagt " ah so sieht der Tree hier aus nutze es so" und dennoch haben wir hier bereits 100% Pass Raten - nach retry. Will sagen nein es funktioniert nicht immer schon alles beim ersten mal aber der Agent sieht sofort das Feedback , passt sich an und ist dann erfolgreich.

Der aktuelle Spitzenreiter scheitert bei jedem dritten Task und braucht 10–20 Minuten. DirectShell hat 360 Spreadsheet-Zellen in 90 Sekunden gefüllt — am ersten Tag seiner Existenz.

Zu finden hier im Demo Video :

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

Die Aussage "nicht zwingend nötig" ist per Definition richtig — aber das ist so als würde man sagen "zu Fuß kommt man auch zur Arbeit, ein Auto hätte es jetzt nicht gebraucht." Stimmt. Aber würde man das wollen?

Microsoft, OpenAI, Google und Anthropic haben in den letzten zwei Jahren rund 300 Milliarden Dollar in den Versuch investiert, KI das Sehen beizubringen. Ich habe ihr beigebracht, nicht sehen zu müssen. Und last but not least: Alles was sie erreicht haben funktioniert mit genau einem Browser. DirectShell funktioniert mit nahezu jedem Programm weltweit.

 

[Tornhoof]

Als jemand der sich eine zeitlang professionell mit WCAG ( https://www.w3.org/WAI/standards-guidelines/wcag/) Support auseinander setzen musste (für Behördenapplikationen gibt's da Vorschriften), kann ich nur sagen nahezu keine Software, die nicht explizit dafür ausgelegt wurde macht das richtig. Da ist dann alles dabei von einfach fehlerhaft, bis aktiv falsch, also Software die aus WCAG Sicht anders "aussieht" als in der normalen Darstellung. WCAG bezieht sich auf Webseiten, bei den üblichen Desktop-Applikationen die wir damals angeschaut hatten war es noch schlimmer.

Ich persönlich gehe davon aus, dass abseits von Standardsoftware ala Excel (die gewisse Anforderungen in der Richtung erfüllen muss) deine Idee nur rudimentär funktionieren wird.
Es wird schon Gründe haben, wieso nahezu alle Tools in der Richtung auf UIRenderingTree Ausgabe funktionieren.

Es gibt da ziemlich viel kommerzielle und kostenlose Software am Markt für die versucht sowas zu prüfen,
Zb
https://accessibilityinsights.io/

Ich würde dir persönlich empfehlen, deine Projekte ggf auf https://news.ycombinator.com/ da bekommst du im allgemeinen viel Feedback.
Nur ehrlich sein dass das alles vibe coded ist, sonst wird es gleich zerrissen.

 

[gabbercopter]

@Tornhoof Hey Moin und danke für das Feedback.

Das ich Vibe Coder bin ist Korrekt. Aber ich habe in /Dokumentation sehr Transparent die Gesamte Coding Session mit 453 kb hinterlegt. Die Ideen und Lösungen Stammen von mir - nicht von der Ki.

Anyway. Also Getestet habe ich bis jetzt : Opera , Chrome , Claude Destop , Discord , Calculator , Notepad , Editor , und Github Destop. Das ist natürlich nicht ansatzweise eine " Vollständige Andeckung" aber meines erachtens nach vergisst du eine Elementare sache die hier Extremst wichtig ist :

Deine Aussage mag auf Automatische Deterministische Verarbeitung zutreffen hier müsste man von Programm zu Programm mal schauen was raus kommt und ob einzelne configs nötig sind ABER woran du nicht Gedacht hast ist das ein Agent der damit verbunden wird den Tree Organisch und Autonom "erkundet" und sich zurecht findet. Bedeutet unabhängig davon wie gut oder schlecht der Tree beschrieben oder Sortiert ist : die KI schreibt in minuten die passende Config und kann es dann nutzen.

EInen Post auf HN hatte ich gestern Gepostet aber bis jetzt ist es da relativ Ruhig. um 09:00 Uhr Starte ich das ganze als Open Source Product Launch auf ProductHunt und werde dann hier den link dazu teilen.

 

[Quantität]

Aber ich habe in /Dokumentation sehr Transparent

Nobody cares! Also klar hat die Dokumentation einen Informationswert, aber das ist eben genau die Art die den Vibe-Codern vorgeworfen wird. Sie mischen sich unter herkömmliche Entwickler verschleiern die KI-Quelle, nutzen offensive Titel & Überschriften, und sind dann Kritik gegenüber sich selbst oder Ihrer Projekte super gut eingestellt!

Schön das es mal ein Video gibt, auch wenn es hier im Startbeitrag fehlt. Aber was soll diese Mucke bitte, hast du die Rechte von PP dafür erworben? Ich mein ok besser als nichts, aber es gibt da so Gründe warum man geschützte Mucke nicht in seinen Videos haben sollte. Ist dir bestimmt mal zu Ohren gekommen, aber ich will ja auch nicht nur meckern!

Du bist doch so ein großer KI-Freund. Generiere deine eigene Stimme zb mit https://voicebox.sh/.
Und damit generierst du dann Voice-Over-Erklär-Bär-Audiofiles. Immer schön kurz und übersichtlich, damit du Fehler leichter eliminieren kannst. und nicht ganze Buchseiten an Audio neu generieren musst. Bei so nem kurzem Demo-Video kann man das noch sauber selber zusammenwürfeln.

 

[gabbercopter]

@Quantität Ein Hochwertiges Erklärvideo wäre sicher mal eine Alternative und etwas das ich zu gegebener Zeit machen werde. Denke da brauche ich dann auch keine KI voice so in 5 Miniten Video Bekomme ich denke ich hin.

Zum Song es Handelt sich um einen " kleinen Underground" Rapper der den Großteil seiner Songs nicht Markenrechtlich schützt oder Kommerziell vertreibt. Über den geschmack lässt sich freilich Streiten

Danke nochmal für das Wertvolle Feedback

 

[gabbercopter]

So hier wie versprochen der ProductHunt link : https://www.producthunt.com/product...se-any-app?utm_source=other&utm_medium=social

falls einer von euch denkt Directshell hat als Open Source einen mehrwert und es keine umstände macht würde ich mich dort über einen Upvote und oder Kommentar freuen <3

 

[gabbercopter]

Blogpost 18.02.2026 — Tag 2: Wenn eine KI zum ersten Mal lernt, einen Browser zu bedienen

Es ist ein Tag voller Höhen und Tiefen. Tag 1 hat gezeigt: Das Konzept hinter DirectShell funktioniert. Erste Tests. Erste Programme. Erste Erfolge. 360 Zellen in Google Sheets, Cross-App Kommunikation, Notepad in Millisekunden. Alles ohne einen einzigen Screenshot.

Tag 2 lehrt mich nun etwas anderes — etwas, das ich so nicht auf dem Schirm hatte.

Einer KI Daten zu geben und Tools bereitzustellen ist das eine. Zu wissen, WIE sie diese Tools und Daten nutzt, ist das andere.

KI-Modelle sind auf Pattern Matching ausgelegt. Sie vervollständigen und replizieren, was sie aus ihren Trainingsdaten kennen. Das Problem: DirectShell und sein Konzept sind neu. Kein Training. Kein Vorwissen. Kein "wie mach ich das richtig." Es ist im wahrsten Sinne eine KI, die das erste Mal lernt, einen Browser wie ein Mensch zu bedienen. Mit Tastatur. Mit Maus. Und mit "shit, einmal zu oft Enter gedrückt."

Ich weiß was ihr denkt — eine KI kennt doch Browser und Tasten. Und ja, das grundsätzliche WIE kennt sie. Aber sie kennt APIs. Sie kennt Bilder. Was sie nicht kennt: In Google Sheets eine Tabelle mit Maus und Tastatur eintragen. Das ist ein Novum.

Was heute passiert ist:

Ich habe sie gebeten, eine Benchmark-Tabelle in Google Sheets zu erstellen. 3 Abschnitte, 8 Spalten, 25+ Zeilen. Was dann passierte:

- Erster Versuch: Alles landete in einer einzigen Zelle. Tab und Enter wurden als Textzeichen geschrieben statt als Tastaturbefehle ausgeführt. Der Übersetzer zwischen Absicht und Tastatureingabe fehlte.

- Zweiter Versuch: Tabs und Enter funktionierten — aber der Titel "blutete" in die Datenzeilen. Sheets springt nach Enter zurück zur Startspalte der letzten Selektion, nicht zu Spalte A. Das wusste die KI nicht.

- Dritter Versuch: Hälfte der Zeichen landete in Sheets, die andere Hälfte in meinem Terminal. Der Fokus wechselte zwischen den Fenstern.

- Vierter Versuch: Komplett non-blocking umgebaut — PostMessage direkt ans Fenster-Handle. Kein Fokus-Steal mehr. Dafür: Chromium ignoriert simple WM_CHAR Messages. Nichts kam an.

Klassische Trial-and-Error. Frustrierend und lehrreich zugleich.

Aber genau das hat mich einer Lösung näher gebracht. Denn ich habe erkannt: "Ich muss diese Trainingsdaten selbst schaffen."

Die Lösung: Organisches Lernen durch Learnings-Dateien

Ich habe folgende Mechanik in die MCP-Pipeline eingebaut: Für jede Anwendung und jeden Kontext (z.B. "Opera + Google Sheets") wird eine Learnings-Datei angelegt. Darin speichert die KI ihre Erkenntnisse — was funktioniert, was nicht, welche Eigenheiten ein Programm hat.

Beim nächsten Mal, wenn sie ds_update_view aufruft, bekommt sie nicht nur die Bildschirm-Analyse von Gemini zurück (dazu gleich mehr) , sondern auch eine Liste aller verfügbaren Learnings für diese App. Sie liest die relevante Datei, bevor sie handelt.

Das ist organisches Lernen: Versuch → Fehler → Erkenntnis → Speichern → Beim nächsten Mal besser.

Heute konnten wir dadurch das Sheets-Problem lösen. Sie weiß jetzt: Tab = nächste Zelle, Enter = nächste Zeile, keine Tabs in Leerzeilen, Titel-Zeilen mit Tabs auffüllen. Beim nächsten Mal wird sie es direkt richtig machen.

Und jetzt stellt euch vor: Wenn das 1 Million Nutzer mit 1 Million Programmen machen. Und es eine geteilte Datenbank gibt. Dann wird es fantastisch funktionieren. Jeder Fehler, den ein Nutzer einmal macht, wird zum Training für alle anderen.

Zweites Update: CDP — Wenn der Accessibility Tree nicht reicht

Wir haben festgestellt, dass einzelne Webseiten im Browser nicht alle interaktiven Elemente im Accessibility Tree ausgeben. Google Sheets zum Beispiel rendert im Canvas — der A11y-Tree zeigt exakt 0 bedienbare Elemente für die Tabelle selbst.

Die Erkenntnis: = Programme vs. Browser sind in einigen Aspekten grundverschieden. Der Accessibility Tree ist perfekt für native Programme — dort sehen wir Button, Textfeld, Menü. Bei Browsern hingegen gibt es eine zweite Datenquelle: das DOM.

Die Lösung: Wir haben Chrome DevTools Protocol (CDP) direkt in die DirectShell-EXE eingebaut. Beim Snappen auf einen Browser prüft DirectShell automatisch, ob CDP auf Port 9222 aktiv ist. Wenn nicht, zeigt es ein Popup, schließt den Browser und startet ihn mit den richtigen Flags neu (--remote-debugging-port=9222 --remote-allow-origins=*). Vollautomatisch, kein manuelles Gefummel.

Das Ergebnis: Wo der A11y-Tree 0 Elemente zeigte, liefert CDP jetzt 65+ bedienbare Tools — Menüs, Formatierungsbuttons, Schriftgrößen, alles. Und das Beste: Es integriert sich nahtlos. ds_update_view schickt jetzt A11y-Daten UND CDP-Daten an den Gemini-Übersetzer, der daraus eine einheitliche Tool-Liste baut.

Gleichzeitig habe ich das "ds_update_view" selbst dazu gebaut. Es sendet nun die a11y und a11y.snap datei sowie wie vorhanden den dom tree handle an ein günstiges schnelles gemeni flash 2.5 lite - dieses erstellt eine einzige antwort mit " was sehe ich hier und welche eingabefelder gibt es" diese antwort parse ich live wodurch on the fly eine aktuelle tool liste für das MCP besteht. Das ist eine minimale verschlechterung der "kosten" aber noch immer um größen ordnungen kleiner als 10-50 screenshots in ein vision Modell zu jagen.

Das sind zwei extrem wertvolle Learnings für mich:

1. KI braucht nicht nur Tools — sie braucht Erfahrung. Und wenn wir diese Erfahrung systematisch speichern und teilen, entsteht etwas Mächtiges.

2. Eine Datenquelle reicht nicht. Programme brauchen A11y. Browser brauchen A11y + DOM. Die Architektur muss flexibel genug sein, mehrere Quellen zu fusionieren.

Bis zum nächsten Update.
Martin

 

[gabbercopter]

Blog 19.02.26

Migräne , Stress und die suche nach der Nadel im Heuhaufen.


Es ist eine Interessante Situation. Auf der einen Seite Trudeln hier und da Interessante Kommentare ein :

Ozz
•Feb 18

This is absurdly cool! Fast as lightning. Managed to build a macOS version of it in an hour THANKS! I'm sure this is an idea that will not go back to the bag. would be cool to see how this gets integrated to "everything"... but for now it makes claude code so much smarter.

THANKS!

(Dev.to Kommentar)

Auf der anderen seite hat man das gefühl nichts bewegt sich. 100 Downloads. Einige Hundert Reads auf den Papern aber es scheint fast wie ein Kollektives " das ist interessant aber was machen wir jetzt damit zu sein"

Vielleicht liegt das einfach daran das noch effektiv die Anwendungen fehlen. Directshell verspricht fortschritt aber das ist natürlich erst dann greifbar wenn die ersten Anwendungen auf Basis von DS entstanden sind die auch Praktisch Funktionieren.

Ich selbst Fokussiere mich auf den KI-Agenten Usecase weil ich glaube das es einer der Vielversprechendsten ist aber man merkt auch einfach das man da plötzlich vor der Situation steht etwas zu Bauen zu dem es keine Referenz gibt. kein "mal kurz Googlen wie mache ich das" Keine best Practice. Reines Try and Error.

und ich kann euch das sagen das ist Ansträngend.

Wo stehe ich ?

Den gemini Ansatz der einige der roh daten in " Häppchen zerlegt" habe ich wieder eingestampft. Gestern gedacht es ist klug heute gemerkt : Nein , ich will Deterministische Lösungen auch wenn sie schwerer sind.

Ich habe nun also eine Mechanik in den MCP Server gebaut der die Relevanten daten aus dem CDM Port des Browser holt , aufbereitet und daraus automatisch die Notwendigen Tools Dynamisch abbildet.

Also : Kein zusätzlicher API Call. Keine weiteren kosten. Das ist gut.

Die größte ungelöste frage vor der ich nach wie vor stehe ist wie ich es Realisiere das lernfortschritte der KI direkt in einen Learning Loop gegossen werden können. Das Problem ist klar kannst du der Ki sagen merk dir das. Aber das ist nicht zuverlässig.

Es muss eine Methode her die Autonom , Deterministisch und zuverlässig Learnings extrahiert und diese wieder als permanenten Loop Kontext Bewusst in die KI zurück Subventioniert.

Ansonsten gabs einige coole PN´s und anfragen. Einige Meetings sind Geplant. aber noch nichts Konkretes.

In dem Sinne

Euch einen wunderschönen Donnerstag <3