![](https://seccdn.libravatar.org/avatar/e8efd891fc055d9843fcbb18465143dc.jpg?s=120&d=mm&r=g)
Hallo, ich habe folgenden Code in einem Windowsprogramm gefunden, bin mir aber bei der Bedeutung nicht zu 100 % sicher. Ausprobieren bringt in dem Fall auch nichts. Das Programm steuert Hardware über den Parallelport. Hier das Codefragment: last1 = inportb(0x40); last2 = inportb(0x40); while (last1 == inportb(0x40) && last2 == inportb(0x40)) ; Auf was genau wartet dieses Codefragment? Die Funktion inportb() dürfte es in ähnlicher Form (inb() ?) auch unter Linux geben, deshalb die Frage hier. Vielen Dank! Gruß, Bernhard -- "Regular ist rekursiv. Ein User ist ein Regular, wenn er von den Regulars als Regular angesehen wird." -- Sebastian Posner in de.alt.folklore.usenet
![](https://seccdn.libravatar.org/avatar/8576ac1b72af7a8d7391dbaa48c37e65.jpg?s=120&d=mm&r=g)
On Sun, 2004-03-28 at 23:51, Bernhard Walle wrote:
Hallo,
ich habe folgenden Code in einem Windowsprogramm gefunden, bin mir aber bei der Bedeutung nicht zu 100 % sicher. Ausprobieren bringt in dem Fall auch nichts. Das Programm steuert Hardware über den Parallelport.
Hier das Codefragment:
last1 = inportb(0x40); last2 = inportb(0x40);
while (last1 == inportb(0x40) && last2 == inportb(0x40)) ;
Auf was genau wartet dieses Codefragment?
Glaskugel, Glaskugel ....
Die Funktion inportb() dürfte es in ähnlicher Form (inb() ?) auch unter Linux geben, deshalb die Frage hier. Ich tippe mal darauf, dass inportb(arg) ein Byte von IO-Port Nummer "arg" einliest. Im Linux-Kernel gibt es auf unterster Ebene vergleichbare Funktionen, die ähnlich heissen (vgl. /usr/src/linux*/include/asm-*/io.h).
while (last1 == inportb(0x40) && last2 == inportb(0x40)) ; Sollte meine obige Annahme stimmen, wird hier auf IO-Port 0x40 gepollt, und darauf gewartet, dass sich eine 2 byte-ige Zeichenkette wiederholt.
cat /proc/ioports liefert bei mir ... 0040-005f : timer .. Das könnte darauf hindeuten könnte, dass der Windows-Code versucht, auf unterster Ebene, am OS vorbei, auf einen Timer-Port zugreift. ;) .. Keine Ahnung, was sich an Port 0x40 genau befindet ;) Ralf
![](https://seccdn.libravatar.org/avatar/6744e3dba6073c19b0c976021177a94a.jpg?s=120&d=mm&r=g)
Hallo Dein Programm liest zweimal am parallelport und bekommt zwei (vielleicht) unterschiedliche Werte. Jetzt liest es so lange, bis es exakt die gleichen zwei Byte wieder in der Reihenfolge bekommt. Normalerweise benutzt man sowas für Hardware, die periodisch einen Sync-impuls sendet, damit man sich auf den Datenstrom synchronisieren kann, aber dann hat man feste Werte, die in irgendeiner Form NICHT im Datenstrom vorkommen und normalerweise sind dass dann mehr als zwei... In deinem Fall möchte ich raten, dass warscheinlich 2 mal eine NULL erwartet wird und dann wieder Daten, aber ein Blick in die Hardware, oder aber ein Oskar an der Leitung wäre hilfreich (Oskar=Oszilloskop) Oder du nimmst den Windowstreiber und jagst den schnell mal durch den SoftICE. (SoftICE = Debugger von NuMega, ähhh sorry ist jetzt Compuware) Gruss - Arndt Am Sonntag, 28. März 2004 23:51 schrieb Bernhard Walle:
Hallo,
ich habe folgenden Code in einem Windowsprogramm gefunden, bin mir aber bei der Bedeutung nicht zu 100 % sicher. Ausprobieren bringt in dem Fall auch nichts. Das Programm steuert Hardware über den Parallelport.
Hier das Codefragment:
last1 = inportb(0x40); last2 = inportb(0x40);
while (last1 == inportb(0x40) && last2 == inportb(0x40)) ;
Auf was genau wartet dieses Codefragment? Die Funktion inportb() dürfte es in ähnlicher Form (inb() ?) auch unter Linux geben, deshalb die Frage hier.
Vielen Dank!
Gruß, Bernhard
-- "Regular ist rekursiv. Ein User ist ein Regular, wenn er von den Regulars als Regular angesehen wird." -- Sebastian Posner in de.alt.folklore.usenet
![](https://seccdn.libravatar.org/avatar/e8efd891fc055d9843fcbb18465143dc.jpg?s=120&d=mm&r=g)
Hallo,
* Arndt Stedler
Dein Programm liest zweimal am parallelport und bekommt zwei (vielleicht) unterschiedliche Werte. Jetzt liest es so lange, bis es exakt die gleichen zwei Byte wieder in der Reihenfolge bekommt.
Also 0x40 ist nicht die Adresse des Parallelports sondern die irgen- deines Timers. Deshalb ja die Frage.
Oder du nimmst den Windowstreiber und jagst den schnell mal durch den SoftICE. (SoftICE = Debugger von NuMega, ähhh sorry ist jetzt Compuware)
Das ist kein eigentlicher Treiber. Die Software benötigt diesen Treiber nur, um unter Windows NT direkten Zugriff auf die Hardware zu haben. Unter Windows 9x braucht man diesen Treiber nicht, daher steckt darin auch keine Funktionalität, die ich analysieren müsste. Mir geht's wirklich nur um diesen Code:
Hier das Codefragment:
last1 = inportb(0x40); last2 = inportb(0x40);
while (last1 == inportb(0x40) && last2 == inportb(0x40)) ;
Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Lernen ohne zu denken, ist eitel, denken, ohne zu lernen, gefährlich. -- Konfuzius
![](https://seccdn.libravatar.org/avatar/6744e3dba6073c19b0c976021177a94a.jpg?s=120&d=mm&r=g)
Sorry, war wohl sehr müde ;-) Antwort findest du unter: http://www.geocities.com/zebra9.geo/pctimer.htm Gruss - Arndt Am Mittwoch, 31. März 2004 15:53 schrieb Bernhard Walle:
Hallo,
* Arndt Stedler
[2004-03-30 22:35]: Dein Programm liest zweimal am parallelport und bekommt zwei (vielleicht) unterschiedliche Werte. Jetzt liest es so lange, bis es exakt die gleichen zwei Byte wieder in der Reihenfolge bekommt.
Also 0x40 ist nicht die Adresse des Parallelports sondern die irgen- deines Timers. Deshalb ja die Frage.
Oder du nimmst den Windowstreiber und jagst den schnell mal durch den SoftICE. (SoftICE = Debugger von NuMega, ähhh sorry ist jetzt Compuware)
Das ist kein eigentlicher Treiber. Die Software benötigt diesen Treiber nur, um unter Windows NT direkten Zugriff auf die Hardware zu haben. Unter Windows 9x braucht man diesen Treiber nicht, daher steckt darin auch keine Funktionalität, die ich analysieren müsste.
Mir geht's wirklich nur um diesen Code:
Hier das Codefragment:
last1 = inportb(0x40); last2 = inportb(0x40);
while (last1 == inportb(0x40) && last2 == inportb(0x40)) ;
Gruß, Bernhard
-- _________ http://www.bwalle.de _________________________________________________ Lernen ohne zu denken, ist eitel, denken, ohne zu lernen, gefährlich. -- Konfuzius
![](https://seccdn.libravatar.org/avatar/6744e3dba6073c19b0c976021177a94a.jpg?s=120&d=mm&r=g)
Einen hab ich noch... ...der helfen koennte: http://www.techedge.com.au/tech/8253tec.htm
participants (3)
-
Arndt Stedler
-
Bernhard Walle
-
Ralf Corsepius