amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Library & Devices proggen [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

15.04.2003, 08:46 Uhr

Cyborg
Posts: 47
Nutzer
Hoi folks..


Ich hab da mal ein paar Fragen zum Thema Libraries & Devices programmieren,
die mir die RKMs so nicht wirklich beantworten konnten und über die ich auch
nichts Brauchbares im Internet finden konnte..

1. Muß ich etwas Spezielles beachten, wenn ich eine Library/Device mit Vbcc
kompilieren muß? Bis jetzt halte ich mich beim coden einfach an die Vorgaben
der RKMs und des Beispiels, das bei StormC dabei war..

2. Ich möchte eine Lib programmieren, die als Modul von einem anderen
Programm geladen wird. Im Prinzip ist es ein HW-Treiber.
Wenn dann eine entsprechende HW gefunden und eine Instanz von meiner Lib
erzeugt wird, möchte ich die HW dem User gerne als ein Device zur Verfügung
stellen.
In den RKMs steht zwar, wie man eine Library zur Laufzeit "von Hand" in das
System einfügen und wieder entfernen kann (LoadSeg(), MakeLib(), AddLib(), etc.),
aber wie man das mit einem Device macht, konnte ich nicht finden.

Es ist ja ohne Zweifel möglich ein Device dynamisch zu erzeugen (beweisen ja
viele Programme), aber ich konnte nichts darüber finden, wie man es genau
anstellen muß ;(

Außerdem kommt noch erschwerend hinzu, daß ich dieses Device von meiner Library
aus erzeugen will/muß. Da hört dann mein Verständnis völlig auf.. kann ich
den Code für das Device einfach in eine Funktion der Library packen? Oder
einfach die Device-Funktionen ans Ende (hinter die Library-Funktionen) packen
und dann eben den Einsprungpunkt für LoadSeg() (oder was auch immer) eben
entsprechend setzen?


Wär schön, wenn mich da jemand erleuchten könnte ;)



--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

16.04.2003, 18:09 Uhr

_PAB_
Posts: 3016
Nutzer
Also, ich denke Du solltest ein "xxx.device" machen, dazu gibt es Beispiele in den RKRMs.
Im device selbst kannst Du dann die Funktionen aus der Library aufrufen.
Um das device zu aktivieren/deaktivieren verwendest Du den gleichen Mechanismus wie "Mount" und "Assing device: DISMOUNT"

[ - Antworten - Zitieren - Direktlink - ]

16.04.2003, 19:51 Uhr

thomash
Posts: 172
Nutzer
Hi Cyborg.

zu 1.: Du darfst nicht mit dem Standard-Startup-Code linken, also nur mit der Option -nostdlib. Ferner mußt Du beim linken aufpassen, daß die Objektdateien in der richtigen Reihenfolge sind. Bei den üblichen Beispielen heißt die Objektdatei, die zuerst gelinkt werden muß, meistens "libstart.o" oder ähnlich.

zu 2.: Eigentlich macht es keinen Sinn, ein Device aus einer Library heraus zu erzeugen, da ein Device praktisch eine aufgebohrte Library ist. Ein Programmierer muß nur das Device öffnen und den LibNode einer Basisvariablen zuweisen, wie bei den Libraries, schon sind die "Library"-Funktionen zugänglich. Siehe das Beispiel timer.device in den RKMs.

Aus reiner Neugier: Was ist das denn für eine Hardware, die so ein Vorgehen verlangt ?

Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

17.04.2003, 11:01 Uhr

Cyborg
Posts: 47
Nutzer

Danke für 1. ;)

Zitat:
Original von thomash:
zu 2.: Eigentlich macht es keinen Sinn, ein Device aus einer Library heraus zu erzeugen, da ein Device praktisch eine aufgebohrte Library ist. Ein Programmierer muß nur das Device öffnen und den LibNode einer Basisvariablen zuweisen, wie bei den Libraries, schon sind die "Library"-Funktionen zugänglich. Siehe das Beispiel timer.device in den RKMs.


Es macht schon Sinn.
Der Hardware-Treiber muß als Library vorliegen, damit er von dem eigentlichen Stack
geladen werden kann. Das erfordert nunmal das Design des Stacks.

Wurde der Treiber geladen, sollen das Gerät alle möglichen Applikationen nutzen
können, ohne dafür etwas vom Stack oder der HW-Besonderheiten zu wissen. Also
muß ich ein Device erzeugen.
Da alles schön kompakt bleiben und das System nicht mit unnötigen Devices vollgemüllt
werden soll (mein Device soll ja nur erzeugt werden, wenn auch eine entsprechende
HW gefunden wurde), möchte ich es einfach aus der Treiber-Lib heraus erzeugen.

Zitat:
Aus reiner Neugier: Was ist das denn für eine Hardware, die so ein Vorgehen verlangt ?

Is (noch) geheim ;-)


--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

17.04.2003, 13:59 Uhr

Solar
Posts: 3674
Nutzer
Zitat:
Original von Cyborg:
-- We would die for :commo:


:boing: has died for :commo: ... :lickout:

[ - Antworten - Zitieren - Direktlink - ]

17.04.2003, 17:30 Uhr

thomash
Posts: 172
Nutzer
Zitat:
Original von Cyborg:

Wurde der Treiber geladen, sollen das Gerät alle möglichen Applikationen nutzen
können, ohne dafür etwas vom Stack oder der HW-Besonderheiten zu wissen. Also
muß ich ein Device erzeugen.
Da alles schön kompakt bleiben und das System nicht mit unnötigen Devices vollgemüllt
werden soll (mein Device soll ja nur erzeugt werden, wenn auch eine entsprechende
HW gefunden wurde), möchte ich es einfach aus der Treiber-Lib heraus erzeugen.

Zitat:
Aus reiner Neugier: Was ist das denn für eine Hardware, die so ein Vorgehen verlangt ?

Is (noch) geheim ;-)


Also quasi wie eine Decoder-Library, die entweder per Software (Library) funktioniert, oder Hardware-beschleunigt, wenn die Karte dazu vorhanden ist.

Stack ? Also irgendwas mit USB oder Netzwerk ? Oder beides ?
:D

Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

17.04.2003, 20:15 Uhr

Cyborg
Posts: 47
Nutzer
Zitat:
Original von thomash:

Also quasi wie eine Decoder-Library, die entweder per Software (Library) funktioniert, oder Hardware-beschleunigt, wenn die Karte dazu vorhanden ist.


hmm.. eigentlich nicht... die Library wird nur aktiv, wenn wirklich eine
unterstützte Hardware vorhanden ist. Wenn das aber so ist, soll dem Benutzer
(egal, ob Coder oder Programm) die Hardware über ein Device zur Verfügung
gestellt werden. Und *nur* dann!
Ist keine Hardware vorhanden, wird die Library auch nicht geladen und somit
soll dann auch kein unnötiges Device im System rumgeistern.

Zitat:
Stack ? Also irgendwas mit USB oder Netzwerk ? Oder beides ?

Hehe... das möchtest Du jetzt gerne wissen, gell :D
Vielleicht isses ja auch was völlig anderes :P



--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

18.04.2003, 02:21 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von Cyborg:
Da alles schön kompakt bleiben und das System nicht mit unnötigen Devices vollgemüllt
werden soll (mein Device soll ja nur erzeugt werden, wenn auch eine entsprechende
HW gefunden wurde), möchte ich es einfach aus der Treiber-Lib heraus erzeugen.

Tja, ganz offensichtlich bist Du gerade dabei genau das Gegenteil zu entwickeln, einen aufgeblähten Library-Code, in dem nicht benötigte devices eingelagert sind, egal ob sie benötigt werden oder nicht.
Vielleicht solltest Du mehr Anstrengungen unternehmen, das device-system des Amigas zu verstehen, in dem das dynamische Nachladen bereits seit über zehn Jahren problemlos funktioniert, anstatt dieses umständliche Handling entwickeln zu wollen, das keinerlei erkennbaren Vorteil bietet.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

18.04.2003, 11:47 Uhr

Cyborg
Posts: 47
Nutzer
Zitat:
Original von Holger:
Tja, ganz offensichtlich bist Du gerade dabei genau das Gegenteil zu entwickeln, einen aufgeblähten Library-Code, in dem nicht benötigte devices eingelagert sind, egal ob sie benötigt werden oder nicht.
Vielleicht solltest Du mehr Anstrengungen unternehmen, das device-system des Amigas zu verstehen, in dem das dynamische Nachladen bereits seit über zehn Jahren problemlos funktioniert, anstatt dieses umständliche Handling entwickeln zu wollen, das keinerlei erkennbaren Vorteil bietet.


Oh, Vergebung!
Vielleicht sind Eure Hoheit so gändig und erleuchten unseren kleinen Geist ein
wenig, damit wir Eurer Weisheit ein wenig näher kommen, obgleich wir sie niemals
werden erreichen können?!


Im Ernst, anstatt hier nur groß heiße Luft zu versprühen und zu versuchen, mir
meine Arbeit madig zu machen, wären konstruktive Vorschläge weitaus sinnvoller!
Du solltest vielleicht auch erstmal genauer nachfragen, bevor Du meckerst..

z.B. habe ich die Kapitel über Devices im RKRM Devices und RKRM Libraries genau
gelesen... leider steht da aber nur, wie man ein Device *benutzt*, nicht, wie
man eines selbst *programmiert* und schon gar nichts von dynamisch erzeugten
Devices.
Jedenfalls hab ich nichts darüber gefunden, außer einem Assembler-Beispielcode
für ein Custom-Device, mit dem ich aber mangels Assembler-Kenntnisse nichts
anfangen kann..

Nebenbei hast Du anscheinend nicht verstanden, worum es hier eigentlich geht,
also nochmal, nur für Dich: Es wird ein Treiber für eine bestimmte Hardware
benötigt, der von einem übergeordneten Stack geladen oder auch wieder entfernt
wird. Daher *muß* es eine Library sein. Punkt.
Das nächste ist, daß dem User auf einfache Weise Zugriff auf diese Hardware
gestattet werden soll. Das geht nuneinmal am besten über eine deviceähnliche
Schnittstelle.
Natürlich könnte ich darauf verzichten, aber dann wäre jedem älteren Programm,
das nicht mehr gepflegt wird, der Zugriff auf die Hardware versagt. Inzwischen
ist der Anteil der nicht weiter gepfegten Software am Amiga so groß, daß dies
völlig inakzeptabel ist.
Da also die Library nur geöffnet wird, wenn auch die Hardware vorhanden ist,
macht es natürlich Sinn, wenn auch das Device nur dann verfügbar ist. Also
dynamisch erzeugt wird (siehe z.B. duart.device oder auch das usbparallel.device
von Chris Hodges).
Leider sieht es so aus, daß ich keine Möglichkeit habe, den Code für das Device
in einem Verzeichnis bereitzustellen, sodaß ich ihn immer finden kann und
vor allem die Dateistruktur *nicht* durcheinander bringe. Also muß der Devicecode
in der Library eingebettet sein.
Natürlich kommt jetzt von Dir wahrscheinlich wieder, daß ich ein komplettes
Device schreiben und es im DEVS: ablegen soll. Schön und gut, wenn aber keine
Hardware vorhanden ist (was wohl öfter vorkommt, da sie relativ selten ist),
würde dieses Device bei vielen einfach nur rumgammeln und evtl. für Verwirrung
sorgen.

Abgesehen davon, macht es öfter Sinn ein Device dynamisch dem System hinzuzufügen.
Und dieser Mechanismus würde mich *generell* interessieren.. im Moment eben aus
einer Library heraus, ansonsten eben aus einem normalen Programm heraus.


So, jetzt sollte es auch der Letzte verstanden haben, um was es geht. Es ist
wirklich traurig, daß man hier genauso angepflaumt wird, wie in den Kommentaren
zu irgendeiner News-Meldung, wenn mal etwas nicht nach dem Geschmack gewisser
Personen hier ist... tolle Community.. :angry:

--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

18.04.2003, 16:29 Uhr

thomash
Posts: 172
Nutzer
Hi ihr zwei...
:)

Das Assemblerbeispiel ist eigentlich recht gut dokumentiert, die Umsetzung in C sollte nicht so schwer sein. Aber Assembler sollte man vielleicht doch dazu können, zumindest ansatzweise... 8)

Im Aminet gibt es ein uraltes Beispiel in C:
ftp://de.aminet.net/pub/aminet/dev/src/DosDev.lha
Sieht aber nicht unbedingt schön aus...

Ansonsten habe ich vorhin mal kurz die Autodocs überflogen, es gibt ein AddDevice()/RemDevice() in exec, wie bei einer Library. Die Vorgehensweise zum dynamischen Einklinken in das System müsste auch die gleiche, wie bei einer Library sein.

Und auch Devices kann man entfernen, wie eine Library. Bei den Beispielen zum serial.device war eine kleine Funktion dabei, wie das geht. Eigentlich genauso, wie bei der Library: Expunge() aufrufen.

Ein Device in eine Library zu stecken, macht eigentlich nur noch Sinn, wenn man eine alte Library ersetzen will, weil ein Device praktischer wäre, um die Hardware anzusteuern.

Ich kann mir allerdings nicht vorstellen, daß irgendjemand mal eine Hardware nicht direkt per Device angesteuert hätte, sondern den "Umweg" über eine Library gegangen ist. :dance3:


Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

19.04.2003, 15:06 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von Cyborg:
Im Ernst, anstatt hier nur groß heiße Luft zu versprühen und zu versuchen, mir meine Arbeit madig zu machen, wären konstruktive Vorschläge weitaus sinnvoller!

Der Vorschlag war absolut konstruktiv: lerne erst einmal, wie ein device funktioniert, dann programmiere eines.
Zitat:
z.B. habe ich die Kapitel über Devices im RKRM Devices und RKRM Libraries genau gelesen... leider steht da aber nur, wie man ein Device *benutzt*, nicht, wie man eines selbst *programmiert* und schon gar nichts von dynamisch erzeugten Devices.
Nochmal zum mitschreiben:
Jedes device wird dynamisch erzeugt, jedes!
Ob der dafür verwendete Code aus einem device aus einem ROM, einer .device-Datei geladen, oder von Dir in einer library verpackt wird, spielt dabei überhaupt keine Rolle. Dein Verstecken in einer Library ist reine Kosmetik und Speicherverschwendung.
Zitat:
Jedenfalls hab ich nichts darüber gefunden, außer einem Assembler-Beispielcode für ein Custom-Device, mit dem ich aber mangels Assembler-Kenntnisse nichts anfangen kann..
Also gibst Du es ja direkt zu: Du kannst noch nichtmal ein normales device programmieren und willst gleichzeitig am Lademechanismus für devices rumpfuschen. Lerne erst mal Laufen, bevor mit dem Tanzen anfängst.
Zitat:
Nebenbei hast Du anscheinend nicht verstanden, worum es hier eigentlich geht, also nochmal, nur für Dich: Es wird ein Treiber für eine bestimmte Hardware benötigt, der von einem übergeordneten Stack geladen oder auch wieder entfernt wird.
Das war schon längst klar.
Zitat:
Daher *muß* es eine Library sein. Punkt.
Falsch. Jedes devices wird von einer übergeordneten Instanz geladen und wieder entfernt. Das funktioniert über den gleichen Mechanismus wie bei libraries.
Zitat:
Da also die Library nur geöffnet wird, wenn auch die Hardware vorhanden ist, macht es natürlich Sinn, wenn auch das Device nur dann verfügbar ist. Also dynamisch erzeugt wird (siehe z.B. duart.device oder auch das usbparallel.device von Chris Hodges).
Totaler Unfug.
Auch ein device muß nur dann verfügbar sein, wenn es geöffnet wird. Und das Öffnen funktioniert natürlich auch nur dann, wenn die entsprechende Hardware vorhanden ist.
Zitat:
Leider sieht es so aus, daß ich keine Möglichkeit habe, den Code für das Device in einem Verzeichnis bereitzustellen, sodaß ich ihn immer finden kann und vor allem die Dateistruktur *nicht* durcheinander bringe.
Himmel, was machst Du nur mit Deinen Dateien, daß Du sie laufend so durcheinander bringst, daß Du sie nicht mehr wiederfindest!
Zitat:
Schön und gut, wenn aber keine Hardware vorhanden ist (was wohl öfter vorkommt, da sie relativ selten ist), würde dieses Device bei vielen einfach nur rumgammeln und evtl. für Verwirrung sorgen.
Was spielt das für eine Rolle, ob Dein unbenutztes device allein oder in einer library eingebettet rumgammelt?
Es führt viel mehr zur Verärgerung, wenn Du meinst, unbenutzte devices verstecken zu müssen, weil Du den User offenbar für dumm hälst. Die meisten Amiga-User wissen es sehr zu schätzen, daß ein einfaches "dir devs:" ausreicht, um einen Überblick über alle installierten devices zu bekommen. Programmier doch für Windows, da freut man sich, wenn alles schön irgendwo versteckt wird.
Zitat:
So, jetzt sollte es auch der Letzte verstanden haben, um was es geht. Es ist wirklich traurig, daß man hier genauso angepflaumt wird, wie in den Kommentaren zu irgendeiner News-Meldung, wenn mal etwas nicht nach dem Geschmack gewisser Personen hier ist... tolle Community..
Deine Reaktion ist absolut unangemessen. Du wolltest Empfehlungen, Du hast welche bekommen. Nur weil sie Deine Vorgehensweise nicht in den Himmel loben, muß man nicht so reagieren.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

19.04.2003, 15:21 Uhr

Kronos
Posts: 1168
Nutzer
Nenene .......

Auch wenn Holger im Prinzip recht hat (IMHO) ist das noch lange
kein Grund so "freundlich" zu werden.

Also ein Device gehöhrt nach devs: (eventuell noch ein Unterverzeicniss)
oder eben in ein ROM. Es mag zwar Ausnahmen geben, aber solange ich
nicht weiss worum es hier eigentlich geht ....

Also was du willst scheint ja sowas wie usbpar.device zu sein, und
da denke ich du solltest das einfach über den Installer lösen
"Wollen sie den Treiber für den TCP/IP-Fön, oder nicht ?",
und damit hats sich. Wenn jemand doch das Device öffnet ohne das
der Fön angeschlossen ist, gibt es eben die entsprechene Fehler-
meldung (DOS-Code 2666 "no fön available" :P ).


MfG
Kronos
--

Only the good die young all the evil seem to live forever

[ - Antworten - Zitieren - Direktlink - ]

19.04.2003, 22:33 Uhr

Cyborg
Posts: 47
Nutzer
@ Holger

Wir reden wohl teilweise aneinander vorbei.. ich meinte mit "dynamisch erzeugen",
daß es eben keine #?.device Datei gibt, sondern das Device aus einem anderen
Stück Code heraus zur Verfügung gestellt wird.
Mir ist sehr wohl klar, daß Device <-> Library keinen großen Unterschied
darstellt.

Von wegen mein Nichtskönnen "zugeben".. Du hattest mir unterstellt (wenn auch
nicht wörtlich), daß ich überhaupt nichts mit Devices anfangen kann. Und das
ist so eben nicht richtig. Ich kann ein Device XY benutzen, kein Problem.
Daß ich im Moment noch kein eigenes Device programmieren kann, gebe ich offen
zu.. warum auch nicht? Genau das will ich ja eben lernen.
Genau in diesem Zusammenhang hat mich eben interessiert, wie man ein Device
in anderem Code einbettet. Das war schon alles.
Es wäre schön, wenn Du - anstatt Schadenfreude dafür zu empfinden, daß es
heutzutage tatsächlich Leute gibt, die mit Assembler nichts anfangen können -
mir z.B. eine Quelle nennst, wo ich Informationen zur Device-Programmierung
unter C finden kann.

Beim nächsten Punkt muß ich doch zitieren:
Zitat:
Falsch. Jedes devices wird von einer übergeordneten Instanz geladen und wieder entfernt. Das funktioniert über den gleichen Mechanismus wie bei libraries.
Dies hast Du eindeutig *falsch* verstanden. Der Stack *erfordert*, daß der
eigentliche Hardware-Treiber eine Library ist. Daran beißt die Maus keinen
Faden ab.
Natürlich stimme ich Dir bei der Aussage grundsätzlich zu, aber in diesem
Fall ist sie einfach fehlangebracht.

Was den "Totalen Unfug" angeht, hast Du eigentlich nichts anderes gesagt,
als ich es getan habe.. Nur daß ich eben das Device auch nur dann zur
Verfügung stellen wollte, wenn die Hardware da ist und nicht erst bei einem
Zugriff darauf checken..

Zu der Dateistruktur.. das bezog sich auf die Vorgabe, daß es *kein* #?.device
im Devs: gibt, sondern das Device eben in einem anderen Stück Code untergebracht
ist. Und dieses Stück Code hätte keinen *vernünftigen* Platz, der die angedachte
Verteilung der Dateien des Stacks *nicht* durcheinanderbringen würde.. da
habe ich herzlich wenig damit zu tun.

Es ist richtig, daß ich den User für "dumm" halte.. allerdings *konstruktiv* !
Ich versuche Software zu schreiben, die möglichst DAU- und narrensicher ist..
dadurch können ein Haufen Probleme von vornherein vermieden werden.
Das ist IMO keine Beleidigung des Users, sondern vielmehr eine Vereinfachung
für den User.. es beschränkt sich ja nicht nur auf das Verstecken von Devices,
wenn sie nicht benötigt werden, sondern erstreckt sich über ein viel größeres
Gebiet.
Um Dein Beispiel aufzugreifen: wenn ein User "dir devs:" macht, will er - wie
Du selbst geschrieben hast - wissen, welche Devices *installiert* sind.. sprich:
welche Devices hat er zur Verfügung. Ein Device hat er aber nur zur Verfügung,
wenn er auch die entsprechende Hardware dafür hat. Wenn also diverse Devices
existieren, die der User gar nicht nutzen *kann*, weil die Hardware eben *nicht*
zur Verfügung steht, warum sollten sie dann aufgelistet werden? (Nicht vergessen,
wenn die HW nicht da ist, wird auch der HW-Treiber nicht geladen und damit auch
das Device nicht zur Verfügung gestellt - sollte es in dem Treiber eingebettet
sein).
Aber natürlich sehe ich auch Deinen Standpunkt.

Abschließend: Richtig, ich wollte Antworten auf meine Fragen. Von deinen
Empfehlungen fühlte ich mich allerdings leicht angegriffen.. vielleicht habe
ich dabei etwas überreagiert, kann sein.. in dem Fall, entschuldige. Trotzdem
wären mir handfeste Quellenverweise (Device-Coding in C, etc.) lieber, als
so lapidare Sprüche, wie "Vielleicht solltest Du mehr Anstrengungen...".

Ich würde sagen, wir begraben hier und jetzt unser "Kriegsbeil" .. schließlich
will ich nicht streiten, sondern etwas lernen.. ;)


--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

19.04.2003, 22:43 Uhr

Cyborg
Posts: 47
Nutzer
Zitat:
Original von thomash:
Das Assemblerbeispiel ist eigentlich recht gut dokumentiert, die Umsetzung in C sollte nicht so schwer sein. Aber Assembler sollte man vielleicht doch dazu können, zumindest ansatzweise... 8)

Da ich in Assembler eine Null bin (welch Wortspiel ;) ), tu ich mir da verdammt
hart.. aber das Beispiel war auch das erste, was ich mir zu dem Thema angesehen
hab..

Es muß da doch auch was in C geben, oder??
Zitat:
Ansonsten habe ich vorhin mal kurz die Autodocs überflogen, es gibt ein AddDevice()/RemDevice() in exec, wie bei einer Library. Die Vorgehensweise zum dynamischen Einklinken in das System müsste auch die gleiche, wie bei einer Library sein.

Und auch Devices kann man entfernen, wie eine Library. Bei den Beispielen zum serial.device war eine kleine Funktion dabei, wie das geht. Eigentlich genauso, wie bei der Library: Expunge() aufrufen.

;-) Ja .. das hab ich kurz nach dem Abschicken meiner letzten Nachricht ebenfalls
entdeckt ... muß mir endlich angewöhnen, etwas genauer zu lesen.. ;)
Zitat:
Ein Device in eine Library zu stecken, macht eigentlich nur noch Sinn, wenn man eine alte Library ersetzen will, weil ein Device praktischer wäre, um die Hardware anzusteuern.
Da ich im Device - egal, ob stand-alone im Devs: oder nicht - sowieso auf Funktionen
in meiner Treiber-Lib zugreifen müßte, dachte ich eben, daß ich die Device-Schnittstelle
gleich in die Library packen und damit zwei Fliegen mit einer Klappe schlagen kann
(1. Zugriff auf die Funktionen und 2. Device nur "sichtbar", wenn auch HW verfügbar
ist).
Anscheinend war das wohl keine so gute Idee .. ;(
Zitat:
Ich kann mir allerdings nicht vorstellen, daß irgendjemand mal eine Hardware nicht direkt per Device angesteuert hätte, sondern den "Umweg" über eine Library gegangen ist.
Nimm als Beispiel USB.. da hast Du keine andere Möglichkeit, als den eigentlich
Treiber in eine Library zu packen und die Befehle wiederum über eine Library (dem Stack)
an die Hardware zu schicken.

Der User (Coder), der jetzt diese von Dir unterstützte Hardware benutzen möchte,
muß ebenfalls über die Stack-Library und evtl. deine Treiber-Library gehen, um
die HW nutzen zu können...

Genau dafür würde ich eben geren ein Device bereitstellen, damit 1. die Handhabung
für Dritte einfacher fällt und 2. auch ältere Programme ohne Rework sofort die
Hardware benutzen können (sofern sie über Devices arbeiten).

--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

19.04.2003, 22:49 Uhr

Cyborg
Posts: 47
Nutzer
Zitat:
Original von Kronos:

Also ein Device gehöhrt nach devs: (eventuell noch ein Unterverzeicniss)
oder eben in ein ROM. Es mag zwar Ausnahmen geben, aber solange ich
nicht weiss worum es hier eigentlich geht ....

Grundsätzlich stimme ich Euch da ja auch zu.. in diesem Fall denke
ich aber, daß es genau so eine Ausnahme ist..
Zitat:
Also was du willst scheint ja sowas wie usbpar.device zu sein, und
da denke ich du solltest das einfach über den Installer lösen
"Wollen sie den Treiber für den TCP/IP-Fön, oder nicht ?",
und damit hats sich. Wenn jemand doch das Device öffnet ohne das
der Fön angeschlossen ist, gibt es eben die entsprechene Fehler-
meldung (DOS-Code 2666 "no fön available" :P ).

Eben.. Du sagst es, sowas wie usbparallel.device... und das ist
eben *nur* dann im System vorhanden/sichtbar, wenn ein USB-Drucker
angeschlossen ist. Ist keiner da, gibt es das Device auch nicht.
Es wird eben dynamisch zur Verfügung gestellt und liegt nicht
im Devs: rum...

--
Bye,
Cyborg
-- We would die for :commo:

[ - Antworten - Zitieren - Direktlink - ]

25.04.2003, 00:02 Uhr

Holger
Posts: 8093
Nutzer
Zitat:
Original von Cyborg:
Wir reden wohl teilweise aneinander vorbei.. ich meinte mit "dynamisch erzeugen", daß es eben keine #?.device Datei gibt, sondern das Device aus einem anderen Stück Code heraus zur Verfügung gestellt wird.

Das ist der springende Punkt: wo auch immer das Stück Code sich befindet, es ist vorhanden. Und in .device-Dateien ist er i.A. besser aufgehoben.
Zitat:
Es wäre schön, wenn Du - anstatt Schadenfreude dafür zu empfinden, daß es heutzutage tatsächlich Leute gibt, die mit Assembler nichts anfangen können - mir z.B. eine Quelle nennst, wo ich Informationen zur Device-Programmierung unter C finden kann.
Schadenfreude? Absurd.
Ich suche nach einem Beispiel-Source. Aber ich habe nicht so viel Zeit...
Zitat:
Es ist richtig, daß ich den User für "dumm" halte.. allerdings konstruktiv* !
konstruktive Bevormundung? Ich befürchte, das ist ein typischer Fehler von Programmierern, die es nur zu gut meinen.
Zitat:
Um Dein Beispiel aufzugreifen: wenn ein User "dir devs:" macht, will er - wie Du selbst geschrieben hast - wissen, welche Devices *installiert* sind.. sprich:
welche Devices hat er zur Verfügung.

Falsch.
Er sieht, welche devices installiert sind, das schließt grundsätzlich auch nicht zur Verfügung stehende devices mit ein.
Wenn er z.B. eine Notfalldiskette erstellen will, kann er auf der Diskette selektiv installieren. Mit versteckten Code geht das nicht.
Zitat:
Trotzdem wären mir handfeste Quellenverweise (Device-Coding in C, etc.) lieber, als so lapidare Sprüche, wie "Vielleicht solltest Du mehr Anstrengungen...".
Ja, da suche ich doch gerne. Aus der Anfrage "Wie bette ich device-code in libraries ein, o.ä." ging eben nicht hervor, daß Du auch an generellen Informationen/ Beispielcode zur Deviceprogrammierung interessiert bist. Gib nur nur ein paar Tage Zeit..

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

25.04.2003, 11:36 Uhr

Ochnygosch
Posts: 17
Nutzer
Hi Cyborg,
ich möchte dir ja nur ungern in den Rücken fallen ( ;-) ), aber ich denke auch, dass ein Device in Devs: nun mal gut aufgehoben ist.

Es wäre doch möglich ein Device zu schreiben, welches nur als "Wrapper" funktioniert. Ein Programm öffnet das Device und das Device benutzt deine Library, um die Anfragen zu beantworten (Schreiben, Lesen ...). Und wenn die Hardware nicht vorhanden ist, läßt sich das Device einfach nicht öffnen.

Hast du schon mal in der Amiga-C Maillingliste nachgefragt? Die können dir da bestimmt helfen.
Amiga-C Maillingliste


Adios,
Jens


This could be a lot more uh, uh, uh, complex, I mean it just might, it might not be such a simple, uh, you know?
--- The Dude

[ Dieser Beitrag wurde von Ochnygosch am 25.04.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Library & Devices proggen [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.