![]() |
Re: COM ports im Griff bekommen
Eine einbindbare Loesung ist ja garnicht erstrebenswert. Wenn zwei Programme sich um eine Schnittstelle streiten, dann ist das System falsch konfiguriert. Das laesst sich nicht dadurch loesen das ein Programm dem anderen die Schnittstelle entreisst. Danach ist das System naemlich in einem Fehlerzustand. Das unterlegene Programm funktioniert ja nicht mehr.
|
Re: COM ports im Griff bekommen
Ich fände es auch gut, wenn das Programm melden würde , welches Programm die Schnittstelle belegt.
Rausfinden kann man es mit dem ![]() Interessant wäre es natürlich diese Funktion in ein eigenes Programm einzubauen |
Re: COM ports im Griff bekommen
Ja man kann anzeigen welches Programm die Schnittstelle benutzt und empfehlen dieses zu beenden, von mir aus mit blitzendem Screen und Warnsirene die Schnittstellenbelegung per Dienst überwachen.
Sollte ich allerdings irgendwann mal auf eine Software treffen die unser Programm automatisch von einer Schnittstelle trennt, wird das nächste Update diese Funktionalität ebenfalls aufweisen und zusätzlich programme, die auf der "fälschlicher weise" belegten Schnittstelle liefen, beenden. Es kann ja nicht sein das Jemand einfach unsere Betriebdatenerfassung nuked. Zumindest will ich nicht der jenige sein der den Startschuss zum Wettrüsten gibt. Ich bin eigentlich der Meinung das ein Produkt das Programme von Schnittstellen trennt um seinen eigenen Betrieb sicherzustellen Malware ist. Denn was bringts, wenn die achso wichtige Messdatensoftware einwandfrei läuft, aber die Betriebsdatenerfassung deswegen aus unerklärlichen Gründen streikt? Du kannst das Problem das in der Stuhl-Tastatur-Schnittstelle liegt nicht auf diese Weise beheben. Man könnte es arrogant nennen, aber ich bin kein so freundlicher Mensch wie Marquart , für mich ist das Schwachsinn, sehr teurer Schwachsinn. |
Re: COM ports im Griff bekommen
Hallo Robert,
natürlich ist es erstrebenswert eine eingebaute Lösung zu haben. Aber nur für den Teil der die Anwendung ermittelt die die Com belegt. Für das automatische Abschiessen geb ich dir Recht! Gruss Rainer |
Re: COM ports im Griff bekommen
Dann sind wir ja einer Meinung.
Hoffen wir das der Threadsteller sich überzeugen läst. |
Re: COM ports im Griff bekommen
Ich habe mir die SysInternal Tools nochmal angeschaut und da steht etwas von Treiber fuer ProcessExplorer. Ich glaube das es aussichtslos ist so etwas nachprogrammieren zu wollen, ausser vielleicht fuer Olli.
|
Re: COM ports im Griff bekommen
Ich frage dann einfach mal so: Wo ist eigentlich das Problem, wenn z.B. eine BDE auf COM1 läuft und eine Messoftware auf COM2? Für mich klingt euer Problem so nach industriellem Einsatz.
Reicht doch wenn die Software sagt, Port belegt... dann hab ich halt Pech mit COM1 und muss COM2 nehmen, Industrie-PCs haben eh mehrere und eine Schnittstellenkarte kostet auch nicht die Welt. Außerdem laufen dann die als Bsp. genannte BDE und die Messoftware parallel. Korrigiert mich bitte, wenn ich was falsch verstanden hab'. Gruß Marc |
Re: COM ports im Griff bekommen
Das Problem ist, dass Kunden oft nicht wissen welches Programm die Schnittstelle belegt. Bei sind oftmals Handyprogramme oder PDA-Programme die den Port belegen und sich ganz unscheinbar in die TNA legen (wo es dann von XP nach einiger Zeit auch ausgeblendet wird). Wenn dann die eigene Software sagen würde Com1 ist bereits von Software xy belegt, könnte ich mir manche Rückfragen ersparen.
Der Kunde käme dann selber auf die Idee das entsprechende Programm zu schliessen. |
Re: COM ports im Griff bekommen
Das wäre zwar ein tolles Feature, aber die wenigste Software zeigt an, welches Programm den Port belegt.
Ich bin leider noch nicht so fit, aber wäre es nicht möglich, das mit den entsprechenden Handles rauszufinden? Naja, ich muss mir für Handles und WindowsMessages erst mal ein gutes Tutorial oder Buch besorgen... :-D |
Re: COM ports im Griff bekommen
hallo nochmal,
also ich habe gar nicht vor malware oder so ein zeug zu coden. hintergrund: neue laptops haben integrierte datenmodule mit dem man ins internet surfen kann und diese haben eine native software dabei. wenn man jetzt eine eigene (angenommen eine bessere :-) ) software dafür baut aber die native software im hintergrund läuft, dann ist halt das port besetzt...den rest kennt ihr |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz