Nachrichten

1

Lowlevel-Coding / Re: FAR-Jump in NASM

« am: 02. March 2017, 15:30 »

Bin zwar etwas spät dran aber es gibt ja auch immer noch den trick segment + adresse auf den stack zu legen und dann über retf zu springen.

Code: [Auswählen]

push bx
push es
retf

2

Lowlevel-Coding / Re: Keine VBE-Infos per Multiboot (GRUB4DOS)

« am: 29. October 2014, 20:09 »

Hat leider nichts geändert. Ich schätze was Brendan im OSDev Forum geschrieben hat wird wohl leider zutreffen.

3

Lowlevel-Coding / Keine VBE-Infos per Multiboot (GRUB4DOS)

« am: 29. October 2014, 10:41 »

Hallo,

Woher kommt es dass GRUB4DOS keine VBE Infos im Multiboot struct ablegt?
Ich benutze QEMU und in der GRUB console listet er mir auch einige VBE-Modes auf wenn ich "probevbe" eingebe.

Muss ich da was spezielles einstellen oder was ist das Problem?

(Crosspost: http://forum.osdev.org/viewtopic.php?t=28669 )

4

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 16:32 »

Öh. Also bei mir funktioniert das so nicht. Auf keinen Fall für jedes beliebige Fenster.

5

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 16:02 »

Genug. Controls in Java-Anwendungen haben soweit ich weiß prinzipiell keine Handles. Dann bin ich ja Pascal/Delphi Programmierer... TImage und TLabel haben z.B. auch beide keine Handles. Aber das sind nur mal 2. Alle Controls in Delphi die von TGraphicControl abgeleitet sind besitzen kein Handle. Etc. Also die Liste ist beliebig lang.

6

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 15:12 »

Also die Lösung dafür ist schon allein darum hässlich, weil du mit "Maus nach oben rechts werfen" nicht mehr das X in der Titelleiste triffst. Das tötet den Durchschnittsuser, weil der die Maus nicht mehr findet und außerdem weiß er nicht, woher das Problem kommt. Tu es nicht.

Doch dafür habe ich eignebaut, dass die Maus an die korrekte Stelle "teleportiert" wird, wenn er den bereich des Fensters mit der Maus verlässt. Die Maus-Verwirrung bekomme ich also in den Griff.

Ich würde wahrscheinlich benutzerdefinierte Timings vorschlagen, die einfach die Auflösung in beide Richtungen halbieren. Wenn man das geschickt macht, dann kann das jeder Monitor darstellen (z.B. 1920x1080 wird zu 960x540 bei identischem Timing). Allerdings ist das wieder ein Rumgepfusche am Grafiktreiber, setzt Adminrechte voraus und ist für den normalen Benutzer nicht machbar...

Problem ist, dass ja nur einzelne Fenster skaliert werden sollen und nicht die komplette Anzeige.

Ansonsten gibt es für mich nur zwei Möglichkeiten, den Desktop zu erweitern... (a) mehrere Bildschirme an einer Grafikkarte (b) mehrere Bildschirme an mehreren Grafikkarten.

Naja ich kann demjenigen der mein Programm nutzen will nicht sagen: "Bitte kauf dir noch einen weiteren Bildschirm, aber schalte ihn nicht an, weil du sollst nicht sehen was mein Programm da für Sachen macht." 

Jetzt habe ich beim Spielen mit der Windows Bildschirmlupe auf "Speichern" geklickt und den Post abgesendet. Dabei wollte ich nur vorschlagen die auch mal anzugucken (insbesondere API-Imports für Inspiration )

Naja für die Bildschirmlupe braucht man ja nicht viel mehr als StretchBlt o.ä. Man kann ja nur "gucken" und kann die vergrößerten Teile ja nicht bedienen. (Man hat ja schon die Lupe "in der Hand" ^^)

Ich wollte auch die DWM-Funktionen für die Darstellung vorschlagen (statt StretchBlt), aber das ist ja auch nicht das wirkliche Problem.

Jo könnte ich mir mal anschauen, aber das ist ja wie gesagt eher nebensächlich und kein wirkliches Problem.

Eine Idee zur Positionierung des Original-Fensters: Die vergrößerte Variante ist ja immer größer als das Original. Vielleicht kann man das dann einfach dahinter verstecken. Dann müsste es immer auf dem Desktop sein. Sieht aber optisch vielleicht nicht bei jeder Software schön aus (insbesondere welche, die immer im Vordergrund sein will)

Ansonsten würde ich auch überprüfen, ob das wirklich ein Problem ist, wenn du das Fenster einfach ganz nach rechts unten verschiebst. Die Messages musst du ja eh via SendMessage schicken, die kommen ja gar nicht mehr direkt von der Maus.

Du scheinst mein Prinzip nicht 100%ig verstanden zu haben. Die Weiterleitung von Messages an das Originalfenster fällt weg, weil es unter anderem eben auch Controls gibt die keine Handles besitzen. Um mal 1 Hürde genannt zu haben...
Momentan ist es also so, dass der benutzer TATSÄCHLICH das Originalfenster bedient. Mit seinen original Maus- und Tastatureingaben. Alles was ich mache ist momentan, dass mein Programm die ganze "Szene" vergrößert darstellt. Und zwar inklusive Mauszeiger. D.h. wenn der Benutzer jetzt auf mein "Video" guckt, dann sieht es (nur) so aus, als würde er eine größere Version davon bedienen. Aber das reicht ja auch aus. Und jegliche Verwirrungen bzgl der Maus (die ja in Wirklichkeit nicht da ist, wo mein Programm es vortäuscht) werden durch ein paar Abfragen und "Tricks" verhindert.

(wobei ich in meiner aktuellen Demo nur grob einige Sachen abfange.. Ist ja nur zum Testen und wäre auch nicht mein Hauptproblem).

Im Klartext heißt das: Ich kann mein Original-Fenster nicht unter meinem skalierten verstecken, weils dann nicht mehr funktioniert.... (weswegen das halt z.B. auch alles etwas hässlich ist -.-)

7

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 13:58 »

OK...

Also. Es soll ein Programm werden was beliebige Fenster skaliert.
Z.B. von 100x100 auf 200x200. Der Inhalt wird dann (als wäre es ein Bild) entsprechend gestrecht. So wie bei der Bildschirmlupe. Nur eben, dass das Fenster natürlich dann in diesem Zustand auch bedienbar sein soll.

Das eigentliche Fenster tatsächlich zu skalieren ist kaum machbar. Aus vielen Gründen. Allein weil man eben alle Controls entsprechend vergrößern müsste, was schonmal bei Controls ohne Handle fehlschlägt.

Mein zweiter Ansatz war das Zielfenster per StretchBlt auf mein eigenes zu zeichnen und alle Maus- & Tastatureingaben auf das Originalfenster umzuleiten. Das hat in Ansätzen funktioniert, war aber irgendwie nicht zufriedenstellend.

Mein momentaner Stand ist, dass ich wie bei Version 2 das Zielfenster per StretchBlt auf mein Fenster zeichne. Allerdings wird der Input nicht weitergeleitet, sondern der ich Zeichne zusätzlich noch die Maus auf mein Formular. Die Maus selbst ist allerdings immernoch beim Originalfenster. Der Benutzer hat so den Eindruck, dass das Fenster vergrößert wurde und er dieses auch bedienen kann.

Das einzige Problem bei dieser Sache ist, dass das Original-Fenster sichtbar (!) und nicht minimiert bzw. von einem anderen Fenster überdeckt sein darf. Ich würde das Orignal-Fenster am liebsten außerhalb des sichtbaren Desktop-Bereichs schieben, aber dann kommt die Maus nicht mehr dran.
Also hatte ich die Idee, dass ich die Original-Fenster auf eine Art virtuellen Monitor verschiebe auf dem der Benutzer das Original-Fenster nicht sieht, aber wo die Maus trotzdem hin kann und mein Programm auch weiterhin funktioniert.

Wenn ihr jetzt sagt: "Das ist ja alles nur blödes rumgepfusche!".. dann habt ihr Recht. So 100%ig schön & elegant ist auch mein momentaner Ansatz nicht. Auch nicht wenn ich den virtuellen Monitor hinbekäme. Aber soweit ich das Überblicke gibt es einfach keine (andere) schöne Lösung für dieses Problem. Zumindest bin ich mit meinem Latein am Ende.

Wenn irgendjemand von euch eine alternative/bessere/schönere Lösung hat, dann immer her damit!

PS: Ich bin mir nicht 100%ig sicher, ob man verstehen konnte was ich da vor hab^^ Wenn Bedarf besteht, kann ich mal ein kleines Demo-Programm hochladen. Ist dann aber nur hingerotzt, weil ich momentan einfach nur auf der Suche nach einer guten Lösung bin. Die saubere Umsetzung erfolgt dann danach.

8

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 13:29 »

Den Link habe ich mir angeschaut. Allerdings verstehe ich den Sinn dieses Programms nicht. Hab da ein Fenster dem ich einen Hintergrund oder eine Hintergrundfarbe zuweise kann und wo alle meine geöffneten Fenster als Icon (wie in der Taskleiste nur ohne Text) aufgelistet sind.

Wenn ich auf die Icons klicke dann werden die entsprechenden Fenster in den Vordergrund gebracht.

?!

Hat soweit ich das sehe nichts mit meinem Problem (oder dessen Lösung) zu tun. Abgesehen davon, dass ich den Sinn des Programms überhaupt nicht verstehe^^
Es sei denn ich habe das Programm so wenig verstanden, dass es doch einen Sinn hat und dass es vielleicht doch eine Lösung meines Problems ist

9

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 12:58 »

@Svenska: Naja wenn ein Großteil aller Graphiktreiber das unterstützen, dann wär das ja schonmal gut. Allerdings... Ich würde das Feature gerne mit einer selbst geschriebenen Anwendung aktivieren. Ne Ahnung wie ich das machen kann? Ist halt die Frage. Vor allem schätze ich, dass ich es dann für jeden Treiber extra implementieren müsste oder?

Ansonsten wäre halt immer noch die Frage ob man sowas im Prinzip und mit vertretbarem Aufwand selbst machen kann.

Links zu Seiten über Treiberprogrammierung (unter Windows) und Foren dazu sind weiterhin auch sehr erwünscht^^


@DeepDancer: Das Problem ist NICHT mit einem Scrollbalken zu lösen  Wäre ja etwas krank, wenn ich einen Treiber schreiben wollen würde für ein Problem was sich mit einem Scrollbalken lösen liese xD

Ich brauche nicht nur Platz, sondern "unsichtbaren", d.h. vom Benutzer nicht direkt wahrnehmbaren Platz. Der genaue Grund ist mal nicht so wichtig, sonst kommen wir vom Thema ab

10

Lowlevel-Coding / Re:Windows Treiberprogrammierung - Virtueller Monitor

« am: 16. December 2010, 00:04 »

Worum es mir geht:

Angenommen ich habe 1 Monitor an meinem PC angeschlossen. Wenn ich jetzt mit der Maus ganz rechts an den Desktop/Bildschirmrand gehe, dann geht es dort nicht mehr weiter. Ist ja auch logisch bzw. sinnvoll.

Für ein bestimmtes Usermode-Programm von mir wäre es allerdings praktisch bzw. eigentlich sogar notwendig, dass es da (z.B.) rechts "weiter geht". Und zwar ohne dass dort ein weiterer physischer Monitor angeschlossen ist.

So gesehen, soll sich der virtuelle Monitor genauso verhalten als würde ich jetzt einen 2. Monitor an meinen PC anschließen und den Desktop so auf einer Seite erweitern. Nur mit dem Unterschied, dass der Benutzer vor dem PC davon nichts sieht, weil dieser Monitor eben nicht tatsächlich existiert.

Sicherlich wäre es schön wenn man das auf dem virtuellen Monitor (theoretisch) Sichtbare dann über den Treiber bzw. in einer DLL gekapselt in einem User-Mode Programm (Fenster/Panel/WasAuchImmer) darstellen könnte. Aber ich denke das wäre dann wahrscheinlich auch nicht so das Problem.
Allerdings wäre das auch nicht so wichtig und kein Must-Have.

Hoffe ich konnte das halbwegs verständlich erklären.

11

Lowlevel-Coding / Windows Treiberprogrammierung - Virtueller Monitor

« am: 15. December 2010, 14:41 »

Hallo,

Ich nutze es grad mal etwas aus, dass wir ja offiziell ein "Lowlevel" Forum sind und explizit nicht nur ein Betriebssystem-Forum 

Ich weiß, dass die meisten von euch Linux haben/benutzen. Hoffe jedoch vllt. doch ein bisschen weiter zu kommen. Was ich prinzipiell machen will/müsste wäre einen Treiber für einen virtuellen Monitor zu schreiben. Ich hab allerdings nicht mal ne Ahnung ob sowas überhaupt möglich ist.

Abgesehen davon, wüsste ich gerne ob es ein Forum rund um (Windows) Treiber-Entwicklung gibt. Habe jetzt bisher noch nichts anständiges gefunden. Zumindest kein Forum wo ich das Gefühl habe dass mir dort je irgendjemand auf meine Fragen antworten wird.

Oder vielleicht auch ein paar weiterführende Tutorials. Alles was ich bisher gefunden hab ging nicht (weit) über "Hallo Welt" hinaus.

12

Offtopic / Re:Nerdleben oder doch lieber Partyleben?

« am: 27. October 2010, 16:43 »

Naja.. ich verstehe gar nicht wie man Schüchternheit "zugeben" kann... 

Entweder ist man schüchtern oder nicht. Und wenn man schüchtern ist, dann merken andere das auch.

13

Offtopic / Re:Nerdleben oder doch lieber Partyleben?

« am: 27. October 2010, 12:57 »

Nein, es gibt viele, zumindest sagte es meines Wissens nach eine Studie, Mädchen (oder Frauen) die Schüchterne Jungen lieben, jedoch selbst schüchtern sind um dies zuzugeben.

Kann ich nicht zustimmen. Bin auch eher schüchtern und hab jetzt trotzdem eine Freundin die ich keinesfalls als "schüchtern" bezeichnen würde.

Und ich denke, dass ich da nicht der einzige sein werde 

14

Lowlevel-Coding / Lowlevel außerhalb der OS-Programmierung

« am: 18. October 2010, 15:54 »

Hallo,

Fallen euch andere "Einsatzgebiete" der Lowlevel-Programmierung außerhalb der Betriebssystemprogrammierung ein? Bootloader zählen jetzt auch nicht.

Welche sinnvollen "stand-alone Programme" gibt es oder kann/könnte es geben?

Würde mich mal interessieren, weil mir jetzt nicht wirklich was einfällt  

Edit: Falls das doch eher in den Off-Topic Bereich gehört, dann bitte verschieben!

Lg
Cjreek

15

Lowlevel-Coding / Re:PC ausschalten nicht neustarten!!

« am: 12. August 2010, 15:52 »

Im Wiki ist u.a. ein Link zur Spezifikation.

16

Lowlevel-Coding / Re:PC ausschalten nicht neustarten!!

« am: 12. August 2010, 15:13 »

Kein schlechtes Gefühl dabei, wenn du den Code einfach so übernimmst und scheinbar nicht mal wirklich weißt was init_acpi und acpi_enable tun um die Funktionen richtig aufrufen zu können?

17

Offtopic / Re:xHCI-Spezifikation für USB3-Hostcontroller ist da

« am: 11. August 2010, 12:43 »

Hallo,

Also ich benutze auch eine Linux-"Abart", die hauptsächlich zum partitionieren gedacht ist. (Parted Magic). Vielleicht klappt es mit einem aktuelleren Linux besser?!
Werde heute Abend mal im BIOS nachschauen ob ich da was zum NEC-Controller finde.

Die große Datei ist mir aufgefallen.. Auch dass 90% davon nur Müll ist. Aber ich wollte dir die original Ausgabe geben. Das Realtek-Problem war mir jetzt nicht bekannt..

18

Lowlevel-Coding / Re:Port-Verwaltung

« am: 09. August 2010, 16:50 »

Ich war bisher leider nicht so weit fortgeschritten, dass ich mir um sowas Gedanken machen musste. Aber rein ausm Gefühl her finde ich es generell riskant mehr als 1 Programm einen Port registrieren zu lassen. (Diese Programme sind ja wahrscheinlich dann Treiber). Selbst wenn Programm A den Port X gerade nicht braucht, ist es schon beschissen, wenn B irgendwas rumpfuscht, von dem A dann später nichts weiß.

19

Offtopic / Re:xHCI-Spezifikation für USB3-Hostcontroller ist da

« am: 03. August 2010, 14:48 »

So. Es hat lange gedauert aber jetzt hab ichs mal ausgeführt. Hab das ganze in ne Datei weitergeleitet und sie angehangen. Ich hoffe das hilft dir irgendwie

==> lspci.txt (nicht mehr gültig)

PS: Kann man hier keine Dateien anhängen?  

20

Lowlevel-Coding / Re:Tastaturtreiber

« am: 27. July 2010, 12:37 »

[Topic]
Bist du schon im Proteted mode? Wenn nein nim Grub und lese dann das Wiki zu Thema Keyboard.
[/Topic]

Möglicherweise hast du Recht mit dem was du sagen willst. Aber ich wollte auch erwähnen dass es durchaus möglich ist auch ohne (den heiligen) GRUB den Protected Mode zu betreten......