-
-
Neuer Benutzer
Öfters hier
Bitte um Erklärung zur autorisierten Treiberoutine!
Es ist interessant zu hören, wie schnell man von Conrad (oder eben dem externen Partner) oder aus Beidem nahestehenden Lager reagiert. Das lässt hoffen! Ich muss zu meinem Beitrag nachtragen, dass ich durchaus Respekt vor dem Problem einer Markteinführung in einem konkurrierenden Umfeld habe. Mir ist auch klar, dass die zweite Generation der C-Control I bei weitem noch nicht fertig ist, das merkt man bereits an der im Gegensatz zur alten Software CD-ROM sehr dürftigen Ausstattung der neuen SW CD-ROM, sowie der äusserst sparsamen Bedienungsanleitung. Ich gehe davon aus, dass das bald korrigiert wird. So gesehen ist der erste Wurf der M-Unit 2.0 wahrscheinlich vor allem an die Anwender gerichtet, die Erfahrung mit der ersten Generation haben, ein Laie der heute mit einer M-Unit 2.0 beginnt, wird es nicht gerade leicht haben mit der Dokumentation.
Aber gerade deswegen ist es marketing-technisch gerade äusserst unklug, den SYSCODE-Befehl einfach wegzunehmen und in die Anleitung zu schreiben, dass nur „autorisierte Treiber“ ausgeführt werden können. Das trifft genau den erfahrenen Anwender besonders hart, der bereits viel Mühe investiert hat. Und das heisst doch ganz klar, dass der normale Anwender kann keine eigenen Assembler Routinen mehr entwickeln kann. Oder steh ich nun völlig neben der Kappe? Es ist doch keine Option für die effektive Programmierung, wenn ich meine Assembler Routine zu Conrad zum compilieren schicken muss! Wie soll man da denn debuggen? Und was nützt es mir auch wenn Conrad seine Treiber Listings veröffentlicht? Das ist in den seltensten Fällen, das was ich selbst auch Programmieren will ! Und wo bleibt der Lerneffekt, wenn ich die C-Control in der Ausbildung einsetzen will? Wenn ich anhand der C-Control erklären und üben will, wie ein Maschinen Programm funktioniert? Also diese Kommentare sind äusserst schwach! Tut mir leid.
Das einzige was ich glauben kann, ist das man sich um den Softwareklau Gedanken macht. Vielleicht waren die Erfahrungen mit der völligen Offenlegung des ROM Listings im Internet sehr negativ. Allerdings ist mir bisher kein „non-Conrad Derivat“ bekannt (kennt jemand eines?) . Der Preis der Original Conrad Version ist äusserst schwer mit einem Plagiat zu unterbieten. Da ist ja schon die Platine teurer, es sei den man hat Connections nach Taiwan oder China. Es ist sicher richtig, das man bei der Software IP eine Gratwanderung machen muss, zwischen guter Verbreitung und Kopierschutz, der jede Verbreitung verhindert. Aber die Erfahrung zeigt doch, dass eine abgeschottete SW nur dann konkurrieren kann, wenn sie einen deutlichen Abstand zur Konkurrenz hat. Und so viel Abstand ist nun auch nicht gerade vorhanden, der Wert der C-Control liegt doch vielmehr im konkurrenzlos günstigen Preis und der guten Verfügbarkeit!
Und nun doch mal ganz konkret: Ich habe ja geschrieben, dass ich die andere Startadresse für Treiberroutinen wohl bemerkt habe, sie ist ja auch mit dem noc existierenden SYS Befehl dokumentiert. Das Problem ist doch aber, dass der Anwender keinen SYSCODE Befehl mehr hat, um selbst entwickelte Assembler Routinen einzubinden. Wenn das doch geht, dann bitte ich um eine Erklärung wie. Für alle geschwindigkeits-relevanten Anwendungen sind Assembler Routinen wichtg. Viele Anwender haben auch Bibliotheken mit Assembler Routinen erstellt, die mit der M-Unit 2.0 nun nicht mehr verwendet werden können. Viel Mühe und Zeit ist da kaputt und es kommt enorm Frust auf. Das wäre für die Einführung alles andere als ein guter Start. Dass das Einbinden von eigenen Assemblerroutinen technisch irgenwie geht, ist mir klar, nur sollte der Anwender informiert werden wie. Wenn diese Erklärung nicht kommt, dann heisst das ich kann nur noch „autorisierte Routinen“ einbinden. Die Frage wäre dann, wie kommt man zu einer „autorisierten Routine“ oder zur „Autorisierung“? Wenn hier die Antwort ist, dass man die Autorisierung durch Conrad erwerben muss, dann ist doch klar was gespielt wird, oder? Dass sich die externe Firma gegen den Klau des Operating Systems schützen muss kann ich ja verstehen. Aber dann haben sie einen verdammt schlechten Job gemacht, wenn sie das nur durch Abblocken von anwender-erstellten Routinen schaffen. Und da Conrad auf Kundenzufriedenheit ausgerichtet sein sollte, sollte Conrad solange Nachbesserung fordern, bis das Problem gefixt ist. Dafür bin ich auch gerne bereit zu warten. Nur wäre es verdammt traurig, wenn die neue C-Control I Generation an diesem Problem scheitert. Und dass das der Conrad Elektronic egal ist, kann ich mir einfach nicht vorstellen!
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
-
Foren-Regeln
Lesezeichen