64Bit OS -> serielle Schnittstelle benutzen

[AJ_Oldendorf]

Ok, ich werde mir das mit den Adminrechten mal angucken aber mal ehrlich, geht dann der empfang der seriellen Schnittstelle nur bis Byte 3 wenn man eingeschränkte Rechte evtl. hat?
Kann ich mir nur schwer vorstellen...
Wo sehe ich denn am besten, ob ich wirklich Adminrechte habe?

Viele Grüße
Alex

[Astat]

Zitat:

Zitat von AJ_Oldendorf

Ok, ich werde mir das mit den Adminrechten mal angucken aber mal ehrlich, geht dann der empfang der seriellen Schnittstelle nur bis Byte 3 wenn man eingeschränkte Rechte evtl. hat?
Kann ich mir nur schwer vorstellen...
Wo sehe ich denn am besten, ob ich wirklich Adminrechte habe?

Viele Grüße
Alex

Hallo AJ_Oldendorf, das Problem ist, Du arbeitest mit einem 64 Treiber, dieser wird mit

Delphi-Quellcode:

CreateFileA (NullStr,

verwendet. Nun ist dieser Treiber jedoch 64 Bit, und Du greifst mit einer 32 Bit Applikation drauf zu.

Also 32 Bit Treiber 32 BIt Software, 64 Bit Treiber 64 Bit Software.

Möglichkeit, die Comports Sourcen mit FPC 64 Bit compilieren.

Lazarus bietet eine dementsprechende 64 BIt IDE

lg. Astat

[Muetze1]

Der Treiber für den seriellen Port ist sowas von egal - also selbst das OS ist egal ob es 32 oder 64 Bit ist. Wenn er einen COM Port öffnet mit \\.\COMxx und CreateFile(), dann kann er den öffnen. Dabei ist die WinAPI immer die passende - bei einer 32 Bit Anwendung auf einem 64 Bit OS halt der Win32 Layer. Da gibt es grundlegend keine Unterschiede und keine Besonderheiten.

Ich nutze selbst die serielle Schnittstelle und entwickle sogar unter einem 64 Bit Windows mit 32 Bit Delphi eine 32 Bit Windows Anwendung und die läuft komplett ohne Admin Rechte. Selbst Delphi braucht für seinen Debugger bei seiner eigenen Tochterprozess die UAC zu befragen, das geht so.

Grundlegend würde ich bei der Overlapped Methode vor allem alle Rückgabewerte der WinAPI Funktionen beobachten und schauen ob du dort entsprechende Fehlerhinweise bekommst. Meine serielle Kommunikation ist simpel gehalten: In einem zentralen Thread wird die I/O gehandhabt Sleep und GetCommState() um zu schauen ob Daten anliegen. Da du bei OVERLAPPED ja Events und ähnliches anlegen musst, hast du schonmal deren Anlegung geprüft und verfolgt? Vor allem Rückgabewerte beachten...

[AJ_Oldendorf]

Ich war grad schon erschrocken, dass es wirklich so sein sollte wegen dem 64Bit Treiber und 32Bit Delphi usw. Das konnte ich mir nicht vorstellen und danke Muetze1 dass du mir das bestätigt hast.

Ja, die Events werde alle sauber angelegt und bearbeitet.
Das komische ist ja, dass nur die ersten 2 Bytes in den ReceivedBytes richtig sind (ich weiß was an Daten kommen müsste) und ab dem 3ten Byte steht nur noch "Mist" drinne...
Habe gerade den Test auch unter Vista 64bit gemacht. Da gehts auch nicht.

Also:

Vista 64 bit, Win7 64 bit -> funktioniert nicht (-> Datenmüll)
Win200, Win XP, Win Vista, Win7 (alle 32 bit) -> funktionieren

[Astat]

Zitat:

Zitat von Muetze1

- bei einer 32 Bit Anwendung auf einem 64 Bit OS halt der Win32 Layer.

Jupp, Mein Fehler Sorry.

lg. Astat

[Muetze1]

Zitat:

Zitat von Astat

Jupp, Mein Fehler Sorry.

Kein Problem, aber ich wollte AJ_Oldendorf nicht in seinem Schweiße baden lassen...

Zitat:

Zitat von AJ_Oldendorf

Vista 64 bit, Win7 64 bit -> funktioniert nicht (-> Datenmüll)
Win200, Win XP, Win Vista, Win7 (alle 32 bit) -> funktionieren

Könntest du vllt. ein Kopie des Projektes machen und mal den ganzen OVERLAPPED Kram rauswerfen und das rein threadbasierend machen? Grundlegend ist der OVERLAPPED Zugriff ein wenig komplizierter und es könnten sich dort ungewollt Fehler verstecken die entweder durch den Win32 Layer hervortreten oder doch sogar durch ihn verursacht werden.

(Kopie, weil das nur ein Test ist. Ich habe mich bisher immer um das OVERLAPPED gedrückt und bin bisher immer gut gefahren. Meine Anwendungen haben bisher auch keine Probleme auf den von dir aufgezählten Systemen)

Ansonsten hast du auch schonmal mit dem PortMonitor von SysInternals die Kommunikation betrachtet? Kommen dort alle Daten richtig an bzw. vermeldet er dort irgendwelche fehlgeschlagenen Aufrufe zu deinem Prozess?

[AJ_Oldendorf]

Danke erstmal für deine Anregungen.
Das alles rauszunehmen wird ein haufen Arbeit. Muss ich mal prüfen ob das so einfach geht.
Allerdings kommt mir langsam der Eindruck, dass noch niemand mit Overlapped Strukturen gearbeitet hat auf einer 64bit Plattform.
Da es bei allen 32bit Plattformen funktioniert, denke ich fast mal, dass doch ein Fehler beim Win32 Layer vorliegt.
Wisst ihr, wo ich evtl. auf einer Microsoft Seite (kann auch englisch sein) ein entsprechenden Eintrag machen kann, sodass sich vielleicht jemand diesem Problem annimmt? (knowledge base)

Den PortMonitor von SysInternals gucke ich mir mal an. Habe ich noch keine Erfahrung mit.

Viele Grüße
Alex

[Muetze1]

Die Async Professional nutzt auch die Overlapped Methode. Da dein Programm anscheinend sehr umfangreich ist, könntest du erstmal das Demoprogramm von Async Professional nutzen bzw. dir eins zusammen bauen. Wenn dies auch das Problem hat, dann ist wohl MS Schuld, ansonsten deine Implementierung. Grundlegend ist die Wahrscheinlichkeit eines Fehler im Win32 Layer recht gering, weil ansonsten müssten viele namenhafte Hersteller schon Probleme vermeldet haben. Die ComPort Library ist auch eine Delphi Komponente welche die Overlapped Struktur nutzt. Diese hat auch Examples mit bei und kann zum generellen Test genutzt werden.

[AJ_Oldendorf]

Hab mir mal die ComPort Library angeguckt und eine Exe erzeugt.
Nur wie kann man da in dem Terminalfenster einen String eingeben damit dieser an die serielle Schnittstelle geschickt wird?
Sehe ich dann auch, was zurück kam von der Schnittstelle?
Irgendwie erschließt sich das Programm mir nicht ganz...

Viele Grüße
Alex

[Muetze1]

Also unter Examples\Delphi\ gibt es ein ComExample.dpr Projekt. Dieses hat ein großes Memo welches die empfangenen Zeichen darstellt und rechts ein TEdit mit dem Send Button zum Senden von Daten an die Schnittstelle. Ich habe Version 3.10 geladen, da ich kein D2010 derzeit nutze und somit die Anpassung an dieses nicht benötige.