Zitat:

---

Original von Der_Wanderer:
Eine GUI Applikation unter Windows kann auch ausgaben mittels printf machen. Man sieht sie nur nicht, weil keine Console aufgeht.
Aber man kann sie in eine File pipen.
Also als No-Go würde ich das nicht bezeichnen.

---

Zitat:

---

Wenn ich das richtig sehe ist der große Unterschied, dass DLLs jedesmal beim öffnen ihren eigenen Kontext erzeugen, während Amiga Shared Libraries nur einmal gestartet werden, und dann von mehreren Prozessen verwendet werden können. Das bringt natürlich einige Probleme mit sich, z.B. man kann bei printf nicht sofort sagen, was der richtige File Handle für den Output wäre.

---

Zitat:

---

Wenn man die vor und Nachteile abwiegt, ist die Amiga Shared Library etwas leichtgewichtiger als die DLL, aber viel schwerer vom Entwickler korrekt zu implementieren. Und eine Library, die 2ms länger braucht zum starten ist besser als keine Library. Dafür würde man sich heute wohl kaum mehr entscheiden.

---

Zitat:

---

Zu Amiblitz:

...

Consolen Output ist möglich, wenn man sich den File Handle der Console bei jedem Aufruf vom aufrufenden Thread besorgt. Global darf man den natürlich nicht speichern.

---

[ - Antworten - Zitieren - Direktlink - ]

@alle und niemanden:

Bevor ich unten auf die getroffenen Aussagen eingehend antworte, schreibe ich vorab etwas Allgemeingültiges.
Ich muss allerdings vorausschicken, dass ich nicht unter Windows 3.x programmiert habe, so dass ich dafür erst einmal entsprechende Literatur im Internet gelesen habe.

1) Unter Windows 3.x wurden üblicherweise nicht die Referenznamen verwendet, sondern die Referenztabellen (import address table (IAT)), was dazu führen konnte, dass bei Änderungen (Updates) der betroffenen DLLs, die IAT des ausführbaren Programmes mit der EAT (export address table) der DLL nicht mehr übereinstimmte, und somit das Starten des betroffenen Programmes einen Blue-Screen verursachen konnte.
2) Mit Windows-NT wurde zwingend die Benutzung der Referenznamen eingeführt um diese Probleme zu umgehen. Man kann aber heute noch die Referenztabellen verwenden (kann man?), diese sollten nach wie vor nominell vorhanden sein; macht nur keiner mehr, wegen der ungeliebten Blue-Screens - denke ich.
3) Eine DLL ist eine stinknormale, ausführbare Datei; demnach müssen Suchvorgänge gestartet werden, um die Referenznamen zu ermitteln. Seht euch mal das Format einer Windows 32/64 Bit Anwendung an, dann versteht ihr mich.
4) Eine DLL wird immer von einem übergeordneten Prozess verwaltet; beim Amiga nur einmal, und zwar beim Laden von einem Medium in den Hauptspeicher und anschließender Initialisierung, bzw. auch noch beim Rausschmiss. Dazwischen hat kein Prozess mehr irgendeine Bedeutung, sondern alles wird von dem Anwenderprogramm erledigt, implementiert aber in der Bibliothek selber, Open(), Close(). Init() wird nur einmal ausgeführt.
5) Eine DLL klont immer ihren nicht-statischen Datenbereich, und zwar für jeden Thread/Prozess, das heißt, beim Öffnen und Schließen ist wesentlich mehr Arbeit seitens einer CPU gefragt als das bloße Hochzählen bzw. Runterzählen einer Variablen (OpenCount) auf Seiten einer Amiga Shared-Bibliothek.
6) Schaut euch mal die gängigsten Probleme mit COM-Objekten an und was Microsoft dagegen getan hat, und dann behauptet nochmal, dass DLLs nur ein einziges Mal im Speicher stehen.


Dass die classic AmigaOS Bibliotheken unter m68k so effizient sind, hat den Grund, wie wir alle wissen, dass sie ausschließlich für m68k gedacht waren. Für andere Prozessoren und andere Programmiersprachen als m68k Assembler ist dieses Format aber alles andere als passend, so weit gebe ich euch Recht. Nur, DLLs und Shared-Objects sind aber auch nicht gerade der Weisheit letzter Schluss, meiner bescheidender Meinung nach.

Effizienz aus Sicht einer CPU bedeutet Aufwand für den Programmierer; Effizienz aus Sicht eines Programmierers bedeutet Aufwand für die CPU.


@Holger:

Zitat:

---

Ähem.
So etwas passiert genau einmal nach dem Laden der Bibliothek, und ähnliches passiert auch beim Amiga, wenn nach dem Laden einer ausführbare Datei Adressen an die tatsächliche Position im Speicher angepasst werden.

---

Zitat:

---

Deshalb funktionieren DLLs selbst unter Windows 3.1 auf einem 386 mit 14MHz...

---

Jo, funktionieren tun auch Classic-Bibliotheken in Verbund mit einer 68000 mit nur 7 MHz recht gut, oder nicht?
Nee, Spaß beiseite, siehe Punkt 1 oben.

Zitat:

---

Wenn man bedenkt, dass der identische Library-Initialisierungscode, inkl. der Verwaltung des Zählers für Anzahl benutzender Programme sich in jeder Bibliothek erneut wiederfinden, statt einmal im Betriebssystem, relativiert sich diese Effizienz erheblich.

---

Da verwechselst Du was. Jede Bibliothek kann einen ganz anderen Initialisierungscode haben; Sprungtabellen können anhand von 32-Bit absoluten Adressen generiert werden (in C macht man das üblicherweise so), für Bibliotheken die ich in Assembler erstellt habe, benutzte ich aber 16-Bit Offsets relativ zur Funktion; zudem kann man im Initialisierungscode reinschreiben was man will, wie will da das Betriebssystem wissen, was es machen soll?
Selbst Open(), Expunge() und Close() sind immer für die betreffende Bibliothek maßgeschneidert.
Das Classic Bibliotheken nicht der Weisheit letzter Schluss sind, weiß ich auch. Nur, ich persönlich finde das Konzept schon ganz passabel. Okay, nicht für PPC und/oder andere Prozessoren, dafür ist es zu maßgeschneidert.
Zudem, wie ich oben schon einmal geschrieben habe, macht das Betriebssystem nichts mehr nachdem die Bibliothek einmal erstellt wurde; eine Bibliothek ist dann nur noch ein Haufen Code der irgendwo im Speicher schlummert und darauf wartet, dass irgendein Anwenderprogramm diesen Haufen Code ausführt. Nix mit Verwaltung seitens des OS.

Zitat:

---

Die Design-Entscheidung, keine symbolischen Namen, sondern eine Tabelle mit 68k-Sprungbefehlen relativ zum Register A6 zu benutzen, die selbst unter der bevorzugten Programmiersprache C ein Fremdkörper ist, muss man akzeptieren. Aber nicht unbedingt glorifizieren.

---

Ich glorifiziere rein gar nichts. Habe ich nicht gemacht und werde es auch nicht machen.
In Zeiten als Assembler noch richtig populär war und CPUs gerade dabei waren in den einstelligen MHz-Bereich vorzudringen, war dieses Konzept aber sehr effizient - und das von beiden Seiten betrachtet, CPU und Assembler-Programmierer.

Zitat:

---

Diese Art des Linkens ist aber auch gar nicht der Grund, warum man Amiga-Libraries nicht so wie Windows oder Unix-Libraries benutzen kann. Der springende Punkt ist hier, dass man nicht die Datensegmente einer Objektdatei automatisch pro Prozess anlegen lassen kann.

---

Stimmt.
Allerdings sollten Amiga Bibliotheken nicht nur thread-safe sein, sondern reentrant, dass heißt dann, dass keine modifizierbaren Daten den Funktionsaufruf überleben. Demnach braucht man auch keinen geklonten Datenbereich.


@Der_Wanderer:

Zitat:

---

Das Argument mit der Effizienz kann ich auch nicht gelten lassen.
Wie Holger gesagt hat, die Klartext Funktionen müssen nur einmal beim Programm start in Jump Offsets aufgelöst werden. Das ist selbst auf einem A500 ein vertretbarer und kaum spürbarer Aufwand.

---

Zitat:

---

Wenn ich das richtig sehe ist der große Unterschied, dass DLLs jedesmal beim öffnen ihren eigenen Kontext erzeugen, während Amiga Shared Libraries nur einmal gestartet werden, und dann von mehreren Prozessen verwendet werden können.

---

Wir driften immer weiter in Richtung pro und kontra DLL, bzw. pro und kontra Classic Amiga Library ab.

Wenn Du mal Zeit hast, dann besuche die Microsoft Entwickler-Seite und lese Dir mal die Low-Level-API Funktionen durch oder programmiere unter Windows mal ohne vorgefertigte WINAPI, dann verstehst Du auch meinen Standpunkt.

Können wir dem Ganzen ein Ende setzen und sagen, dass Holger und Du nichts gegen Sprungadressenermittlung anhand von Bezeichnern habt, wogegen ich statische Offsets fest verankert im Programm favorisiere?


Frieden?

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Mir war nur nicht ganz klar, dass selbst in C es recht schwer ist eine etwas komplexere Library zu erstellen, vor allem wenn es sich um nicht-notwendigerweise-auf-den-Amiga-maßgeschneiderten Code handelt.

---

Zitat:

---

Ich bin in letzer Zeit beruflich mit einigen Plattformen in Berührung gekommen. Da merkt man deutlich, wenn man mal die Ideologie beiseite lässt, dass der Komfort und Qualität von IDE, SDK und der API der Schlüssel sind ob eine Plattform gute Software bekommt oder nicht.

---

Zitat:

---

Die Bereitschaft der Amigafans, mehr Zeit zu investieren für das Gleiche was auf anderen Plattformen viel einfacher ist kann das nicht ausgleichen.

---

Zitat:

---

Z.b. habe ich verzweifelt nach einer Video Codec Library gesucht, nach einer MOD player library oder einer mp3 Encoder Library. Unter Windows ist das alles in 5min erledigt, FFMPEG als DLL, MikMOD als DLL oder LAME als DLL. Gibts alles. So kann man sehr schnell tolle Multimedia Apps zusammenstellen. Angesichts diesem Überflusses bin ich sogar oft sehr enttäuscht, wie "schwach" viele Windows Soft doch ist.

---

Zitat:

---

Auf dem Amiga gibt es von den o.g. Dingen zwar Commando Zeilen Ports, aber keine Libraries. Um da das gleiche zu erreichen muss man quasi alles selbst machen, vom Video Encoder bis zum MOD player. Das ist 1000x so viel Code und Arbeit, und das Ergebnis sehr viel schwächer.
Zumindest ist das so, wenn man keine Statischen Linker Libs hat und oder verwenden kann.

---

Wieder so eine Sache: Alles, was Du aufzählst, IST auch nur als Kommandozeilen-Tool gedacht. ffmpeg z.B. ist eine Tool-Sammlung zur Behandlung unterschiedlicher Bild- und Videoformate, aber keine Link-Library an sich. Für das Bauen dieser Tools existiert jedoch immer auch der Satz an zugehörigen Link-Libraries (libjpeg, libpng, libmpeg und wie sie alle heißen. Ich kriege immer wieder Zustände, wenn ich AmiUpdate auf OS4 starte, weil die Litanei der Link-Libraries, die ich nicht benutze, so irre lang geworden ist und in Wochenabständen länger wird).

Was glaubst Du, wie ffmpeg für Amiga (ja, sogar 68k!) portiert wurde? Alles "selbst gemacht" und unter Verwendung selbst gebauter shared libraries? Oder LAME? Diese Tools sind im engeren Sinne portabel, weil sie nicht auf dynamisch zu ladende Objekte angewiesen sind. Es gibt sie im Original statisch oder dynamisch gelinkt, aber geplant waren sie bisher immer für statisches Linken. Und da es fast immer eierlegende Wollmilchsäue sind, ist dynamische Linken im Grunde auch überflüssig für diese Tools. Was wohl auch der Grund dafür sein dürfte, daß für die meisten der für diese Tools verwendeten Link-Libraries keine Gegenstücke in Form einer Amiga shared Library vorliegen. libmad ist hier eine Ausnahme (mpega.library).

avcodec existiert übrigens sogar als shared library. Du müßest sie im Grunde "nur mal eben" auf 68k bringen (was nicht wirklich schwer ist). Über den Sinn dieser Aktion kannst Du Dir ja dann immer noch Gedanken machen, wenn die Besitzer echter 68k Amigas ihr Befremden darüber in diversen Foren zum Ausdruck bringen

Zitat:

---

Lohnt es sich also, ein paar Bytes und CPU Cylces zu sparen, wenn dadurch das Erstellen mächtiger Software fast unmöglich wird?

---

Was heißt "mächtige" Software? Mächtig groß? Mächtig funktions- und fehlerbehaftet? Mächtig mit selten bis nie genutzten Spezialfunktionen überfrachtet? Mächtig schwerfällig sogar auf schnellsten Maschinen?

Das Problem, das Du da beschreibst, ist kein vom verwendeten Bibliothekssystem verursachtes Dilemma, sondern schlicht Folge der etwas unglücklichen Geschichte des Amiga. Wäre diese Geschichte nur ein wenig positiver verlaufen, würdest Du sicherlich über die unüberschaubare Menge der erhältlichen shared Libraries für einen bestimmten Zweck stöhnen.

Und um auf Dein eigentliches Problem zurückzukommen: Dieses wiederum ist eher eine Designfrage. Gründe für ein Überdenken Deines Designs wurden Dir hier einige aufgezählt.

Wie gesagt, wie Du damit letztendlich umgehst ist allein Deine Entscheidung. Niemand will und kann Dich zwingen, Deine Lib auch für AOS 68k zu entwickeln, wenn es Dir zu aufwändig ist. Aber denk mal darüber nach, was man Dir hier in Sachen C-Standardfunktionen und deren Verwendung in Bibliotheken gesagt hat. Wirklich clever ist dieser Weg nämlich nicht. Simpel und schnell gemacht, ja, aber nicht wirklich clever.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von jolo:
2) Mit Windows-NT wurde zwingend die Benutzung der Referenznamen eingeführt um diese Probleme zu umgehen. Man kann aber heute noch die Referenztabellen verwenden (kann man?), diese sollten nach wie vor nominell vorhanden sein; macht nur keiner mehr, wegen der ungeliebten Blue-Screens - denke ich.

---

Zitat:

---

3) Eine DLL ist eine stinknormale, ausführbare Datei;

---

Zitat:

---

... demnach müssen Suchvorgänge gestartet werden, um die Referenznamen zu ermitteln.

---

Zitat:

---

5) Eine DLL klont immer ihren nicht-statischen Datenbereich, und zwar für jeden Thread/Prozess, das heißt, beim Öffnen und Schließen ist wesentlich mehr Arbeit seitens einer CPU gefragt als das bloße Hochzählen bzw. Runterzählen einer Variablen (OpenCount) auf Seiten einer Amiga Shared-Bibliothek.

---

Zitat:

---

Dass die classic AmigaOS Bibliotheken unter m68k so effizient sind, hat den Grund, wie wir alle wissen, dass sie ausschließlich für m68k gedacht waren. Für andere Prozessoren und andere Programmiersprachen als m68k Assembler ist dieses Format aber alles andere als passend, so weit gebe ich euch Recht.

---

Zitat:

---

Nur, DLLs und Shared-Objects sind aber auch nicht gerade der Weisheit letzter Schluss, meiner bescheidender Meinung nach.

---

Zitat:

---

Da verwechselst Du was. Jede Bibliothek kann einen ganz anderen Initialisierungscode haben; Sprungtabellen können anhand von 32-Bit absoluten Adressen generiert werden (in C macht man das üblicherweise so), für Bibliotheken die ich in Assembler erstellt habe, benutzte ich aber 16-Bit Offsets relativ zur Funktion; zudem kann man im Initialisierungscode reinschreiben was man will, wie will da das Betriebssystem wissen, was es machen soll?

---

Zitat:

---

Zudem, wie ich oben schon einmal geschrieben habe, macht das Betriebssystem nichts mehr nachdem die Bibliothek einmal erstellt wurde; eine Bibliothek ist dann nur noch ein Haufen Code der irgendwo im Speicher schlummert und darauf wartet, dass irgendein Anwenderprogramm diesen Haufen Code ausführt. Nix mit Verwaltung seitens des OS.

---

Zitat:

---

Allerdings sollten Amiga Bibliotheken nicht nur thread-safe sein, sondern reentrant, dass heißt dann, dass keine modifizierbaren Daten den Funktionsaufruf überleben. Demnach braucht man auch keinen geklonten Datenbereich.

---

Zitat:

---

Können wir dem Ganzen ein Ende setzen und sagen, dass Holger und Du nichts gegen Sprungadressenermittlung anhand von Bezeichnern habt, wogegen ich statische Offsets fest verankert im Programm favorisiere?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Mir war nur nicht ganz klar, dass selbst in C es recht schwer ist eine etwas komplexere Library zu erstellen, vor allem wenn es sich um nicht-notwendigerweise-auf-den-Amiga-maßgeschneiderten Code handelt.

---

Zitat:

---

Lohnt es sich also, ein paar Bytes und CPU Cylces zu sparen, wenn dadurch das Erstellen mächtiger Software fast unmöglich wird?

---

Zitat:

---

Original von whose:

Zitat:

---

Ich bin in letzer Zeit beruflich mit einigen Plattformen in Berührung gekommen. Da merkt man deutlich, wenn man mal die Ideologie beiseite lässt, dass der Komfort und Qualität von IDE, SDK und der API der Schlüssel sind ob eine Plattform gute Software bekommt oder nicht.

---

Das würde ich so nicht unterschreiben...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Dieses "mächtige" Programmieren geht aber nur, wenn es, wie schon gesagt, ein gutes IDE, SDK (Docu) und die entsprechenden APIs gibt.
Mit der Amiblitz API habe ich mich versucht da heranzuarbeiten, es ist auch sehr viel möglich, aber alles innerhalb der Grenzen von AmigaOS und was dort verfügbar ist.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

Import Amiga.CImage

CImage img = new CImage("DH0:myImage.jpg")
img.Resize(800,600,CIMAGE_INTERPOLATION_CUBIC);
img.Save("DH0:myImage_in800x600.png","PNG");

---

code:

---

Import Amiga.CSound

CSound snd = new CSound("DH0:mySound.wav")
snd.Play();
snd.Save("DH0:mySound.mp3","MP3")

---

code:

---

Import Amiga.CAudioStream

CAudioStream music = new CAudioStream("DH0:myMusic.mod")
while (music.Available()>0) {
  music.PlayBuffer()
}

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Man bräuchte eigentlich eine moderne API, die auf allen Systemen in gleicher Version verfügbar ist.
Z.B. sowas

code:

---

Import Amiga.CImage

CImage img = new CImage("DH0:myImage.jpg")
img.Resize(800,600,CIMAGE_INTERPOLATION_CUBIC);
img.Save("DH0:myImage_in800x600.png","PNG");

---

Das entspricht so in etwa der API von Amiblitz3 und was in in A/A++ vorhabe, wenn ich das jemals realisiere.

Alles andere ist viel zu kompliziert, mit Datatypes, richtige Tags setzen etc. Und das speichern geht schonmal gar nicht.

---

Zitat:

---

Das Problem ist halt nur, dass jedes System das versucht, aber nicht mit den anderen kooperiert. Deshalb bleibt der Amiga auf 3.x stehen, und ein neues Projekt in C anzufangen ist gleich eine Mammutaufgabe mit viel Trial and Error.

---

Zitat:

---

In Eclipse+Java funktioniert der Code meistens fast auf Anhieb. Unter C auf dem Amiga braucht man zig Compiler Läufe bis dann alles klappt. Und wenns dann auch noch zur Laufzeit funktioniert, fliegt es einem mit hoher Wahrscheinlichkeit um die Ohren wenn jemand das auf einer anderen Plattform ausprobiert.

---

Zitat:

---

Das liegt nicht an C, sondern am schwachen IDE, was einem nicht zur Tip-Zeit auf Fehler hinweist, an einem schwachen SDK was nur eine Plattform berücksichtigt und an einer schwachen API die einem für (aus heutiger sicht) triviale Sachen wie ein Bild laden viel zu viel OS Internas vor den Latz knallt wo man massig Fehler machen kann (auch als erfahrener Progger) und ein vielfaches mehr Code braucht als man heutzutage erwarten würde.

---

Zitat:

---

Und wie gesagt, das kann man nicht durch Enthusiasmus ausgleichen. Und gerade wenn Entwickler Man-Power knapp ist, muss man sich auf eine gutes IDE+SDK+API gespannt konzentrieren, das passiert aber nicht, sondern alle backen ihre eigenen, kleinen Brötchen.

---

Zitat:

---

Aber ich schweife langsam vom Thema ab, das wäre ein anderer Thread...

---

Och, die eigentliche Frage ist doch geklärt. Im Prinzip schon, aber nicht so simpel, wie Du gehofft hast Da können wir ruhig weiter über Grundsätzliches reden, denke ich
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:

Zitat:

---

Ich bin in letzer Zeit beruflich mit einigen Plattformen in Berührung gekommen. Da merkt man deutlich, wenn man mal die Ideologie beiseite lässt, dass der Komfort und Qualität von IDE, SDK und der API der Schlüssel sind ob eine Plattform gute Software bekommt oder nicht.

---

Das würde ich so nicht unterschreiben...

---

Was außer Komfort und Qualität von IDE, SDK und der API soll denn noch eine Rolle spielen?

---

Zitat:

---

Der Enthusiasmus?
Dann müsste der Amiga ja in guter, aktueller Software schwimmen.

---

Erinnere Dich mal daran, wie oft Du hier bestrebt warst, Enthusiasmus abzuwürgen, weil Du der Ansicht warst, daß der jeweilige Enthusiasmus Zeitverschwendung wäre. Und dann erinnere Dich daran, daß Du nicht der Einzige mit diesem Bestreben bist

Viele gute Ideen sind in den vergangenen 10 Jahren den Bach runter gegangen, weil sie schlicht totdiskutiert wurden, statt sie einfach zu nutzen.

Zitat:

---

Die Performance?
Dann hätte der Wechsel von 68k auf ppc einen ordentlichen Anstieg von verfügbarer Software verursachen müssen, den ich nicht wirklich erkennen kann.

---

Hm, also in Sachen "verfügbarer" Software hat PPC durchaus einiges gebracht. Für die Marktverhältnisse sogar erstaunlich großen Anstieg. Und das trotz Grabenkämpfen, übermächtiger Konkurrenz x86, teilweise seltsamem Verhalten der User (Stichwort Ideologie) und Problemen im Bereich der Kernentwickler (gleiches Stichwort).

Die Qualität der zusätzlich verfügbaren Software ist ein anderes Kapitel, aber solange die Ideologie des "Portieren auf Teufel komm raus" vorherrscht, wird sich daran wohl wenig ändern...
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

hm? Im Groben funktionierts via Datatype mit ziemlich genau so viel Code und mit ungefähr der gleichen Menge an Tags.

---

code:

---

Function.l image_LoadViaDT{image.l,filename.s,imgnum.l}
DEFTYPE.BitMapHeader *bmhdp
DEFTYPE.BitMap *bmap
DEFTYPE.pdtBlitPixelArray DTM
succ.l = False
If imgnum<0 Then imgnum=0
tag5.tag5ti_Tag = #PDTA_DestMode, #PMODE_V43, #DTA_SourceType, #DTST_FILE, #DTA_GroupID, #GID_PICTURE, #PDTA_Remap, False,#PDTA_WhichPicture,imgnum,#TAG_DONE,0
*DTPic._Object = NewDTObjectA_ (&filename.s,tag5)
If *DTPic
  tag5.tag5ti_Tag = #PDTA_BitMapHeader,&*bmhdp,#TAG_DONE,0
  GetDTAttrsA_ *DTPic,tag5
  If image_Create{image,*bmhdpbmh_Width,*bmhdpbmh_Height}
    If image_Lock{image}

      ; try to get as ARGB immediately, good datatpyes support this, but not all!
      ;If *bmhdpbmh_Depth>8 ; dont even try if depth <=8
        DTMMethodID            = #PDTM_READPIXELARRAY
        DTMpbpa_PixelData      = raw_ptr          ; /* The pixel data to transfer to/from */
        DTMpbpa_PixelFormat    = #PBPAFMT_ARGB     ; /* Format of the pixel data (see "Pixel Formats" below) */
        DTMpbpa_PixelArrayMod  = bpr              ; /* Number of bytes per row */
        DTMpbpa_Left           = 0                 ; /* Left edge of the rectangle to transfer pixels to/from */
        DTMpbpa_Top            = 0                 ; /* Top edge of the rectangle to transfer pixels to/from */
        DTMpbpa_Width          = *bmhdpbmh_Width  ; /* Width of the rectangle to transfer pixels to/from */
        DTMpbpa_Height         = *bmhdpbmh_Height
        If DoMethodA (*DTPic,&DTM) Then succ = True
      ;End If

      ; ok, try to read out the bitmap if ARGB failed...
      If succ=False
        tag5.tag5ti_Tag = #PDTA_ColorRegisters,&colorMap.l,#TAG_DONE,0
        If GetDTAttrsA_ (*DTPic,tag5)
          tag5.tag5ti_Tag = #PDTA_BitMap,&*bmap,#TAG_DONE,0
          If GetDTAttrsA_ (*DTPic,tag5)
            *layerinfo.Layer_Info = NewLayerInfo_
            If *layerinfo
              *layer.Layer = CreateUpfrontHookLayer_ (*layerinfo,*bmap,0,0,*bmhdpbmh_Width-1,*bmhdpbmh_Height-1,0,#LAYERS_NOBACKFILL,0)
              If *layer
                *rp.RastPort = *layerrp
                If *rp
                  image_Unlock{image}
                  succ = image_CutRP{image,*rp,0,0,*bmhdpbmh_Width,*bmhdpbmh_Height,-1,-1,-1,colorMap}
                  If succ Then image_Lock{image}
                End If
                DeleteLayer_ 0,*layer
              End If
              DisposeLayerInfo_ *layerinfo
            End If
          End If
        End If
      End If

      ; Try READPIXELARRAY LUT8, if we couldn't catch the bitmap (outch!)
      If succ=False
        penArray8.l = AllocVec_(*bmhdpbmh_Height * *bmhdpbmh_Width,#MEMF_ANY)
        lut.l       = AllocVec_(256*4,#MEMF_CLEAR)
        If penArray8><0 AND lut><0
          DTMMethodID            = #PDTM_READPIXELARRAY
          DTMpbpa_PixelData      = penArray8         ; /* The pixel data to transfer to/from */
          DTMpbpa_PixelFormat    = #PBPAFMT_LUT8     ; /* Format of the pixel data (see "Pixel Formats" below) */
          DTMpbpa_PixelArrayMod  = *bmhdpbmh_Width  ; /* Number of bytes per row */
          DTMpbpa_Left           = 0                 ; /* Left edge of the rectangle to transfer pixels to/from */
          DTMpbpa_Top            = 0                 ; /* Top edge of the rectangle to transfer pixels to/from */
          DTMpbpa_Width          = *bmhdpbmh_Width  ; /* Width of the rectangle to transfer pixels to/from */
          DTMpbpa_Height         = *bmhdpbmh_Height
          If DoMethodA (*DTPic,&DTM)
            tag5.tag5ti_Tag = #PDTA_ColorRegisters,&colMap.l,#TAG_DONE,0
            If GetDTAttrsA_ (*DTPic,tag5)
              For pen.l=0 To (1 LSL *bmhdpbmh_Depth)-1
                *CReg.ColorRegister = colMap + 3*pen
                Poke.l lut + (pen LSL 2),((*CRegred&$00FF) LSL 16) | ((*CReggreen & $00FF) LSL   | (*CRegblue & $FF)
              Next
              For y.l = 0 To *bmhdpbmh_Height -1
                For x.l = 0 To *bmhdpbmh_Width -1
                  pen.l = Peek.b(penArray8+y**bmhdpbmh_Width+x) & $FF
                  Poke.l raw_ptr+y*bpr+(x LSL 2),(Peek.l(lut+(pen LSL 2)) );& $FEFEFEFE) LSR 1
                Next
              Next
              succ.l = True
            End If
          End If
          If penArray8 Then FreeVec_ penArray8 : penArray8 = 0
          If lut       Then FreeVec_ lut       : lut       = 0
        End If
      End If
      image_Unlock{image}
    End If
    If succ=False Then image_Free{image}
  End If
  DisposeDTObject_ (*DTPic)
End If
Function Return succ
End Function

---

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Du machst mit dem Code aber auch etwas mehr spezielleres, als "nur ein Bild laden und auf den Schirm bringen". Der Code, den Du als Beispiel dafür brachtest, wie Du Dir "ein Bild laden und auf den Schirm bringen" vorstellst, ist in C ungefähr gleich. Und in Blitz sicher auch. Und bisher kenne ich keine Plattform, wo dieser Code (Bild laden und auf den Schirm bringen) nicht läuft.

Ich verstehe Dein Problem ja, aber es hilft rein gar nichts, sich über die Unzulänglichkeiten zu ärgern und eine Menge Code "drumherum" zu schreiben. Wenn Datatypes nix taugen, weil sie im API festgelegte Funktionen nicht oder falsch unterstützen gibts eigentlich nur zwei Dinge: Knochenhart sagen "Leute, mit dem Datatype läufts nicht, benutzt den oder den". Und sich dran setzen, einen Datatype zu entwickeln, der tut, was er soll.

Manchmal gibts allerdings auch Situationen, wo "selbst machen" unmöglich ist. Ging mir bei Amijeweled mit bestimmten P96-OS3.x-Systemen so. Da bleibt einem nicht viel mehr als zu sagen: "Tut mir leid, Leute, ich kanns auf Euren Systemen nicht zum Laufen bringen und es ist ziemlich unwahrscheinlich, daß der Fehler in P96 oder Eurem GraKa-Treiber noch gefunden und beseitigt wird". Kann man sich dann höchstens Notizen zu machen und schauen, ob eines Tages ein ähnlich gebautes Programm plötzlich funktioniert. Vielleicht findet man dann das Problem und kann es umgehen.

Fakt ist, die Plattformen streben inzwischen deutlicher auseinander. Kompatibilität gibt es untereinander nur noch auf dem kleinsten gemeinsamen Nenner und gerade der krankt an früher eingeführten Problemen. Die kannst Du aber nur dann für alle Plattformen kompatibel umschiffen, wenn Du deutlich mehr Arbeit in den Code steckst. Oder die Plattform OS3.x + RTG zu Gunsten einer der anderen fallen läßt. Mit OS3.x allein kommst Du heutzutage jedenfalls nicht mehr weit. Und es besteht wenig Aussicht darauf, daß OS3.x noch Weiterentwicklung erfährt. Bei den anderen Plattformen sieht das anders aus.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
@Der_Wanderer:
Du machst mit dem Code aber auch etwas mehr spezielleres, als "nur ein Bild laden und auf den Schirm bringen". Der Code, den Du als Beispiel dafür brachtest, wie Du Dir "ein Bild laden und auf den Schirm bringen" vorstellst, ist in C ungefähr gleich.

---

Ähem, der Dreizeiler, von dem Du behauptet hast, "Im Groben funktionierts via Datatype mit ziemlich genau so viel Code", öffnet ein Bild, skaliert es und speichert es.
Wie Du jetzt plötzlich auf "nur ein Bild laden und auf den Schirm bringen" kommst, ist mir schleierhaft.

Allerdings würde ich auch gern mal sehen, wie Du allein das "ein Bild laden und auf den Schirm bringen" mit einem C-Dreizeiler implementieren willst.

Das dürften ziemlich lange Zeilen werden

Allein die Sache, dass man noch ne PROC_LAYOUT-Methode schicken muss, hat mich damals Stunden gekostet, als ich es zum ersten Mal gemacht habe...

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Erinnere Dich mal daran, wie oft Du hier bestrebt warst, Enthusiasmus abzuwürgen, weil Du der Ansicht warst, daß der jeweilige Enthusiasmus Zeitverschwendung wäre.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

DoDTMethod (o,NULL,NULL,DTM_WRITE,NULL,fhand,DTWM_IFF,TAG_END);

---

Jetzt erklär mir bitte mal jemand, was daran so fürchterlich kompliziert ist? Außer vielleicht, daß man die Tags kennen sollte?

Diese Form von API ist nicht komplizierter als die, die Der_Wanderer gezeigt hat. Anders, ja, aber nun wirklich nicht komplizierter. Und wer unbedingt möchte kann, wie ich schon erwähnte, den ganzen Krempel noch weiter vereinfachen, häufige Nutzungsarten in eine Funktion einer Link-Library packen, usw. Es muß halt nur mal einer tun und andere Entwickler sollten das Zeug dann auch nutzen, selbst wenn u.U. irgendein Detail nicht ganz so ist, wie mans sich wünscht, aber dann doch eher selten bis gar nicht benutzt.

Schon mal zlib benutzt? DAS ist kompliziert. Puffer hier, Zwischenergebnisse dort, getaggte Speicherbereiche, die man selbst überprüfen muß usw. Und alles nur, um ein paar Kilobyte zu packen. Darüber beschwert sich aber komischerweise niemand. Das wird benutzt, weils vorhanden ist. Ist ja auch aus dem Unix-Bereich stammend. Nur beim Amiga ist es immer wieder ein Problem, vorhandenes zu benutzen. Nur, weil dieses oder jenes "nicht richtig" oder "zu kompliziert" ist.

Was die Angelegenheit API beim Amiga kompliziert macht ist die (ideologisch) bedingte Vielfalt an z.B. Datatypes, die eigentlich den gleichen Zweck erfüllen sollen, dies aber unterschiedlich gut (oder schlecht) erledigen.

Wie Der_Wanderer schon anmerkte (aber nicht BEmerkte): Es gibt immer wieder Ansprüche, die z.B. kein Datatype erfüllt. Dem einen ist die Qualität der Skalierung nicht ausreichend, der andere stört sich daran, daß es Probleme mit evtl. Remapping auf AGA gibt und so weiter und so fort. Nicht zu vergessen diejenigen, die ein z.B. JPEG Datatype nur dann akzeptieren, wenn es mit Hilfe der libjpg entwickelt wurde.

Was wirklich fehlt ist das Bestreben und der Ehrgeiz, aus dem bereits Vorhandenen gute Software zu produzieren und auch mit anderen Entwicklern aktiv zusammenzuarbeiten. Sich auf das Vorhandene wirklich einzulassen und auch die Gegebenheiten (4 immer wieder leicht unterschiedliche Systeme) einfach mal anzuerkennen, statt ständig eine Angleichung zu fordern, die nicht erreichbar ist, das fehlt. Der Rest ergäbe sich von allein, wenn diese Haltung sich endlich einmal durchsetzen könnte.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Im Groben ... läuft Laden (wahlweise incl. Skalieren) und Anzeigen in 3, max. 4, Schritten ab. NewDTObject(), DoMethod(), GetDTAttrs() und ggf. BltBitMapRastPort().

---

Zitat:

---

Selbst das Speichern sieht so aus:

code:

---

DoDTMethod (o,NULL,NULL,DTM_WRITE,NULL,fhand,DTWM_IFF,TAG_END);

---

---

Zitat:

---

Jetzt erklär mir bitte mal jemand, was daran so fürchterlich kompliziert ist? Außer vielleicht, daß man die Tags kennen sollte?

---

Zitat:

---

Diese Form von API ist nicht komplizierter als die, die Der_Wanderer gezeigt hat.

---

Zitat:

---

Wie Der_Wanderer schon anmerkte (aber nicht BEmerkte): Es gibt immer wieder Ansprüche, die z.B. kein Datatype erfüllt. Dem einen ist die Qualität der Skalierung nicht ausreichend, der andere stört sich daran, daß es Probleme mit evtl. Remapping auf AGA gibt und so weiter und so fort.

---

Genau deshalb ist es ein Fehldesign, diese Aufgaben den Datatypes zu überlassen, statt in der Bibliothek zu verankern.

Und diese Beispiele hier sind noch harmlos. Schließlich ist die Nutzung der Datatypes mit Grafiken quasi die Hauptanwendung.

Schon mal intensiver mit dem Text-Datatype auseinandergesetzt?

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

[ - Antworten - Zitieren - Direktlink - ]

code:

---

;///////////////////////////////////////////////////////////////////////////////
;/                                                                             /
;/ Syntax:  result.l = image_WriteDT{fid.l,image.l}                           /
;/                                                                             /
;/ Description:                                                                /
;/ * private *                                                                 /
;/ Write a picture as 24Bit IFF-ILBM via datatypes.                            /
;/                                                                             /
;/ Inputs:                                                                     /
;/ - image.l     : image object ID                                             /
;/ - fid.l       : file object ID                                              /
;/                                                                             /
;/ Result:                                                                     /
;/ - result.l    : -1 if everything went well, 0 otherwise                     /
;/                                                                             /
;/ Bugs: does not work on AfA4.2 and lower                                     /
;/                                                                             /
;///////////////////////////////////////////////////////////////////////////////
Function.l image_WriteDT{fid.l,image.l}
SHARED imagedat()
DEFTYPE.dtWrite DTMW
DEFTYPE.pdtBlitPixelArray DTMB
succ.l=False
If ARGBbitmap_ptr
  *newbm.BitMap = AllocBitMap_(img_width,img_height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|(#PIXFMT_RGB24 LSL #BMB_PIXFMT_SHIFTUP) ,0)
  If *newbm=0 Then error{"\__THIS_FUNCTION: Unable to allocate 24bit Bitmap!"} : Function Return False

  DEFTYPE.RastPort rp
  InitRastPort_ rp
  rpBitMap = *newbm
  ClipBlit_ rastport_ptr,0,0,rp,0,0,img_width,img_height,$c0


  basename.s = "iff"          ;          #DTA_BaseName    ,&basename,@@
  tag5.tag5ti_Tag  = #DTA_SourceType,#DTST_RAM,#DTA_GroupID,#GID_PICTURE,#PDTA_DestMode,#PMODE_V43,#PDTA_BitMap,*newbm,#TAG_DONE,0
  *DTPic._Object = NewDTObjectA_ (0,tag5)

  If *DTPic
    tag5.tag5ti_Tag = #PDTA_BitMapHeader,&*bmhd.BitMapHeader,#TAG_DONE,0
    GetDTAttrsA_ *DTPic,tag5
    If *bmhd
      *bmhdbmh_Width      = img_width
      *bmhdbmh_Height     = img_height
      *bmhdbmh_Depth      = 24
      *bmhdbmh_XAspect    = 22
      *bmhdbmh_YAspect    = 22
      *bmhdbmh_PageWidth  = 1600
      If (*bmhdbmh_Width<=1280) Then *bmhdbmh_PageWidth=1280
      If (*bmhdbmh_Width<=1024) Then *bmhdbmh_PageWidth=1024
      If (*bmhdbmh_Width<= 800) Then *bmhdbmh_PageWidth= 800
      If (*bmhdbmh_Width<= 640) Then *bmhdbmh_PageWidth= 640
      If (*bmhdbmh_Width<= 320) Then *bmhdbmh_PageWidth= 320
      *bmhdbmh_PageHeight = *bmhdbmh_PageWidth * 3 / 4
    Else
       error{"\__THIS_FUNCTION: Unable to get bitmap header!"}
    End If

    ;fh.l = Open_ (&filename.s,#MODE_NEWFILE)
    fh.l = file_GetFH{fid}
    If fh
      DTMWMethodID            = #DTM_WRITE
      DTMWdtw_GInfo           = 0
      DTMWdtw_FileHandle      = fh
      DTMWdtw_Mode            = #DTWM_IFF
      DTMWdtw_AttrList        = 0
      succ = DoDTMethodA_(*DTPic,0,0,DTMW)
      ;succ = DoMethodA(*DTPic,DTMW)
     ; Close_ fh
      If succ=False
        error{"\__THIS_FUNCTION: Unable to write image via "+basename+" datatype!"}
      EndIf
    EndIf

    DisposeDTObject_ *DTPic
  Else
    error{"\__THIS_FUNCTION: Unable to create datatype object out of the bitmap!"}
    FreeBitMap_ *newbm
  EndIf
Else
  error{"\__THIS_FUNCTION: No bitmap!"}
End If
Function Return succ
End Function

---

[ - Antworten - Zitieren - Direktlink - ]

@Wanderer

Ich sehe Du musstest Dich noch nicht mit Windows APIs rumschlagen. Dagegen ist die AmigaOS API echt niedlich und super zu programmieren.

Einmal was mit MAPI gemacht, und hoffentlich nie wieder... Auch bei Drucker über TerminalSessions wird man zum Hirsch. Von Dienste Programmieren ganz zu schweigen...

Ich hab mal in BASIC Routinen (Laden + Speichern) für BMP, GIF und IFF(ILBM und ACBM) gemacht, und mir sowas für PNG und JPEG schon angesehen.

GIF, BMP, PNG und ILBM sind nicht weiter schwierig zu implementieren (Hierfür braucht man Verständnis für Coder, z.B. LZW und RLE)
Für JPEG musst Du Discrete Consinus-Transformation verwenden, aufgeteilt in kleine Quadrate, ist also komplizierter.

Die Programmiersprachen, die mit einem Befehl (LoadILBM, SaveILBM) sowas machen, müssen sich intern auch um alles kümmern

Die Datatypes wandeln intern alles nach IFF um soweit ich das sehe.
Interessant wäre eine Lib, die die Konvertierung von verschiedenen Formaten unterstürzt...

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

> Also anstatt einmal das gescheit im OS zu haben, gibt es sicherlich hunderte von solchen Implementationen.

Andere OS haben das auch nicht direkt im System.
Für Win gibt es für jede IDE eigene Routinen, auf Linux greift man gernauf die libxxx.o/so zu.

Ein Widerspruch ist das aber nicht, was ich gesagt hab.
Textausgabe in einer Shell ist auch easy zu machen, trotzdem gibt es Aufrufe die das erledigen. Also nicht widersprüchlich sondern "zusätzlicher Wunsch".

> Im Vergleich hat der Amiga aber nur eine Low Level API, also quasi
> nur die Win32. Es wurde nicht wirklich ein neuer Layer draufgesetzt,
> das macht dann immer jede Programmiersprache oder jeder Programmierer
> von Grund auf neu. Und das verbrennt massig wertvolle Entwicklerzeit.

Wozu denn auch? Ich find die API einfach zu programmieren. Wenn ich "Superfunktionen" will, kann ich mir diese bauen.
Das was auf dem AmigaOS wesentlich mehr Entwicklerzeit braucht, ist eine fehlende IDE. Sich einfach eine GUI hinzuklicken und Events zuzufügen, das ist es doch, was das Programmieren auf Win beschleunigt.

Wenn es denn noch keine ultra converter lib gibt, wieso entwickelt dann nicht jemand diese, dann gäbe es sowas. Genauso für API Wrapper und sonstiges. Sooo notwendig wars wohl dann doch nicht

Wenn ich mal bisschen Zeit übrig hab, kann ich mich mal an einer Converter-Lib machen.

[ - Antworten - Zitieren - Direktlink - ]

code:

---

...
img = image_Load{"T:Attachment.jpg"}
image_Resize{img,800,600,IMG_KEEP_ASPECT|IMG_INTERPOLATION_BILINEAR}
image_Save{"T:Attachment_sized.jpg","JPEG",IMG_COMPRESSION_HIGH}
...

---

[ - Antworten - Zitieren - Direktlink - ]

> Die API ist alles andere als einfach zu programmieren.
Wenn man von Blitz auf C++ wechselt, hat man sicher diese Ansicht.
Wer von Assembler auf C++ wechselt, hat eine andere Ansicht.
Wer von Windows auf Amiga wechselt, denkt auch, es ist einfacher.

> Auf dem Amiga vielleicht Superfunktionen, auf anderen OS ist das normal
Super im Sinne von "Übergestellt" nicht im Sinne von "Großartig"

Anders gesagt: Es liegt im Auge des Betrachters. Einige Win-API sachen sind auch einfach, aber andere schwierig.
Es gibt aber sicher win User die sagen, das sei einfach (Außer MAPI, da checken auch die von M$ nicht mehr durch!)

Also, hier haben wir einen Programmierer. Da haben wir ein Problem (fehlende converter-Lib als Beispiel). Und was ist das Resultat? Beschwerde statt handeln. Und genau DAS ist der Stillstand. Immer andere machen lassen.
Wozu seid ihr denn Programmierer? Also ran an den Speck.

Nicht beschweren sondern einfach MACHEN.

[ Dieser Beitrag wurde von Thore am 06.05.2010 um 14:43 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Ich glaube wir reden aneinander vorbei.
Im Grunde teile ich ja deine Meinung mit einfacheren Wrappern/Supermethoden/-funktionen für API Calls, finde aber es nicht schwierig, die API direkt zu nutzen.
Nicht gegensätzlich sondern zusätzlich.

Daß Du diese Funktionen gemacht hast, ist lobenswert, und sie werden sicher auch benutzt. Und genau das ist es doch was ich meinte. Nicht beschweren sondern was machen.
Du hast es doch selbst gezeigt mit deinen Routinen.

Im Grunde wollen wir beide das gleiche.

Um wieder bei dem Beispiel Converter-Lib zu bleiben. Wenn es denn keiner macht, dann wird sie auch nicht benutzt.
Eben weil es sie nicht gibt, macht jeder sein eigenes. Anstatt daß jemand sich dem (überschaubaren) Projekt annimmt.
Wegdiskutieren kann mans nicht

Ich hab auch nicht von "einfach drauf los", "einfache API ist mächtiger/nicht so mächtig" etc gesprochen, das kam alles aus Deinem Munde, äh Deiner Feder

Also um wieder sachlicher zu werden.
Was würdest Du denn von sowas wie einer converter-Lib halten?

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Öhm, wieso?
Das macht keiner so Unter Linux sind das im Grunde nur Libs, die benutzt werden, unter Win wird das teilweise sehr unterschiedlich gemacht (VCL, CLX, WinAPI, ....)
Wieso muss das System es auch so machen? Es benutzt ja schon die Datatypes bzw Reggae. Übrigens auch Libs...

Wieso muss es da ein einheitlicher Standard geben, der über allem steht?
Warum nicht einfach eine Lib, die konvertieren kann?
Vereinfachte API Calls würden sowieso intern das gleiche machen wie vorher, nur daß der Aufruf anders ist.

> Alle diese Programme benutzen die gleiche API zum Laden von Sounds...
Gut, und wo ist das SDK?

[ Dieser Beitrag wurde von Thore am 06.05.2010 um 16:00 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]