Zitat:

---

Original von Der_Wanderer:
> Wie ich schon öfters sagte. Nicht lange fackeln, handeln.
Eben nicht. Das ist ja genau das, was ich versucht habe zu veranschaulichen. Liest (und kognitiv verarbeitet) jemand (ausser Holger) mein Geschriebenes überhaupt?

---

Zitat:

---

Jeder für sich alleine kann nicht viel erreichen. Jede Lib oder Linkerlib wäre nur ein kleiner Baustein dessen was benötigt wird.

---

Zitat:

---

Wenn die Bausteine nicht wie Lego aufeinander passen, wird ein Programm zur Flickschusterei mit viel fehleranfälligem Glue-Code und es gibt keine wiederkehrenden Mechanismen, die einem die Einarbeitung so sehr erleichtern.

---

Zitat:

---

Ausserdem ist es sehr gefährlich, wenn man 3rd Party Software (zumindest auf Binary Basis) einbindet, das ist wie ungeschützer Sex.

---

Zitat:

---

Die meisten Libs machen auf irgendeiner Plattform Zicken, alleine wegen dem wenigen Testen bei so vielen verschiedenen Libs.

---

Zitat:

---

Also der Weg zum Glück liegt selten auf dem gierigen Pfad.

---

Amen.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Also, was spricht dann dagegen, Deine AmiBlitz-Includes in C-Code zu gießen? Das "schlechte shared library API"?

---

Zitat:

---

Ich denke, das Stichwort "Plattform" ist das eigentliche Problem, weniger das AmigaOS API... (@Holger: Das ist der heiße Brei, um den immer gern herumgeredet wird. "Plattform".)

---

[ - Antworten - Zitieren - Direktlink - ]

Auf Windoof sind die Superfunktionen (High Level API Aufrufe) auch nur Aufgeflanscht auf darunterliegende Libcalls und Funktionen (welche sich leider zwischen den verschienen Versionen unterscheiden oder abstürzen, danke M$ du bist echt der Held...)
Eine Lib oder Unit/Include/.. mit entsprechenden Aufbauten würde diesbezüglich haargenau das gleiche darstellen.
Daher verstehe ich nicht was "der Wanderer" genau meint.

Ich vermute aber mal daß er das meint (Voraussetzungen):
1. Die Schnittstellen müssen offiziell sein (z.B. von Hyperion lizensiert oder sonstwie "nativ" und kein Third Party)
2. MorphOS und AROS müssen "pflichtbewusst" mitziehen.
3. Die Calls werden in den Standard Libs (dos, icon, graphics, intuition, ...) mit aufgenommen.
4. Die Funktionen werden im RKM aufgenommen.

Ist das so in etwa richtig?

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
Ich vermute aber mal daß er das meint (Voraussetzungen):
1. Die Schnittstellen müssen offiziell sein (z.B. von Hyperion lizensiert oder sonstwie "nativ" und kein Third Party)
...
Ist das so in etwa richtig?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Du kannst anhand meiner dargelegten Funktionsnamen erkennen, was dahinterstecken soll? Ui große Gabe, Verneigung

Mal als Hilfestellung eine mögliche Schnittstelle (Beispiele):
TextW(RastPort, x, y, WideString); // Ausgabe eines Unicode Texts an Pos x,y
ScaleImage(RastPort/Bitmap, x, y, w1, h1, x2, y2, w2, h2); // Scalieren eines Bildausschnitts Formatsicher mit Pos x,y und Maße w1,w2 nach Pos x2,y2 mit Maße w2,h2

Wie soll es denn noch einfacher gehen? Je weniger Infos man der Routine mitgibt, umso unflexibler wird das ganze.

Oder was genau meinst du? Konkretes Beispiel. Ich denke Du bist grad der einzige der weiß was er will.

[ - Antworten - Zitieren - Direktlink - ]

@Der_Wanderer:

Um beim Android-Beispiel zu bleiben:

Spätestens in Sachen 68k würdest Du damit vor eine Wand rennen. 3rd level API auf die sich alle einigen können schön und grün, aber die Hardware und die unter der High-Level-API liegenden Schichten müssen da auch mitspielen.

Ok, man kann jetzt wie üblich argumentieren, daß 68k-Liebhaber ja wegen der Geschwindigkeit auf WinUAE & Co. umsteigen könnten. Aber wer von denen macht das? Und ich verstehe die auch sehr gut, daß die ihre Hardware nutzen möchten, neue Programme dafür bekommen möchten usw. Und dann ist da ja noch die Systemsoftware...

Deswegen sage ich, daß sich da jemand hinsetzen und eine entsprechend zugeschnittene API zaubern muß, sonst wird das so oder so nichts. Klar, bei ner One-Man-Show besteht die Gefahr, daß das einfach untergeht. Die Gefahr besteht aber auch bei einer One-Dozen-Men-Show, und zwar aus den gleichen Gründen. Es hilft einfach nichts, ein API aufzubauen, wenns hinterher nicht einmal die Entwickler selbst voll nutzen. Dagegen hilft auch Open Source als Allheilmittel nicht. Wie viele Open Source Projekte gibt es, bei denen gar nichts mehr passiert? Und das, obwohl sie anfangs vielversprechend waren und schicke Funktionen mitbrachten?

Von dem Gedanken, daß es für alle Amiga-Abkömmlinge die gleiche API ohne Zwang geben kann, wird man sich auch verabschieden müssen. Es wird immer im Detail haken, weil sich die einzelnen Plattformen schon recht weit auseinanderentwickelt haben. Dazu kommt, daß jedes Trüppchen seine eigenen Vorstellungen hat, wie man was umsetzen sollte. Mir ist z.B. zu Ohren gekommen, daß mindestens 2 der neueren Vertreter AHI ablösen wollen. Dann die Druck-Problematik, da ist ja bei den einen CUPS im Gespräch (hoffentlich nicht!), bei den anderen ein aufgebohrtes printer.device...

Ja, und dann ist da noch dieser bald zwanghaft-manische Wunsch, das Ganze auch noch auf Winblows, Linux & Co. auszuweiten... wieso eigentlich? Wozu soll das gut sein? Hilft dem Amiga nicht wirklich. Höchstens dabei, eben diesen Plattformen immer ähnlicher und damit immer überflüssiger zu werden.

Ich schätze, der einzige Weg, da etwas zu erreichen ist, eine API zu entwerfen, zu implementieren und Referenzanwendungen dafür zu bauen. Dazu sollte das Ganze, wie Du schon sagtest, "aus einem Guß" sein und wirklich gute, neue Features bringen. Wenn sich dann noch genug Entwickler finden, die das wirklich und ausführlich benutzen, baut das Druck auf die OS-Teams auf. Das könnte manche Leute eventuell dazu bewegen, diese API als Quasi-Standard anzuerkennen und zu übernehmen. Garantie gibts allerdings keine.

Ich wette aber, daß es, egal wie gut es tatsächlich ist, von den "üblichen Verdächtigen" direkt oder auf lange Sicht wieder totgequatscht wird. Aus den unterschiedlichsten Gründen, manche davon vielleicht sogar berechtigt, je nach dem, wie diese API gestaltet wird.

Leicht wird das Ganze sicher nicht.
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
Du kannst anhand meiner dargelegten Funktionsnamen erkennen, was dahinterstecken soll? Ui große Gabe, Verneigung

Mal als Hilfestellung eine mögliche Schnittstelle (Beispiele):
TextW(RastPort, x, y, WideString); // Ausgabe eines Unicode Texts an Pos x,y
ScaleImage(RastPort/Bitmap, x, y, w1, h1, x2, y2, w2, h2); // Scalieren eines Bildausschnitts Formatsicher mit Pos x,y und Maße w1,w2 nach Pos x2,y2 mit Maße w2,h2

Wie soll es denn noch einfacher gehen? Je weniger Infos man der Routine mitgibt, umso unflexibler wird das ganze.

Oder was genau meinst du? Konkretes Beispiel. Ich denke Du bist grad der einzige der weiß was er will.

---

Nein, ich weiß auch in groben Zügen, was er will

TextW() zum Beispiel wäre auf einen String beschränkt. Eine 3rd level API nach seinen Wünschen würde z.B. auch ganze String-Arrays zulassen und den Krempel auf Fensterbreite automatisch formatieren. Im Groben das, was die ganzen "Bildschirmausgabe-Engines" ala Quartz oder auch Klamotten wie PostScript machen, eben mit einer einzigen aufzurufenden Funktion den ganzen Segen verwursten.

Beim Skalieren ging es vor allem darum, wie das Ganze z.Z. im Zusammenspiel mit den Datatypes gehandhabt wird. Das ganze Geraffel könnte man ja relativ problemlos in eine einzige Funktion packen, deshalb sagte ich anfangs ja auch, daß ich da kein Problem sehe. Einmal ne entsprechende Funktion schreiben, ab in ne Linker-Lib und fertig.

Sein Wunsch zielt halt darauf ab, entsprechende Funktionen auf allen Amiga-Plattformen (und evtl. darüber hinaus) offen zur Verfügung zu haben. Theoretisch kein Thema, nur machen muß es jemand. Und dann muß es natürlich auch von Dritten genutzt werden. Gerade bei letzterem sehe ich einige Probleme. Die gäbe es aber auch bei den "Offiziellen". Ich erinnere in diesem Zusammenhang immer wieder gern an ReActor. Schöner Ansatz, aber von allen Seiten (sogar von den Entwicklern selbst!) direkt totgequatscht worden. Daher dürfen wir die GUIs wieder schön brav von Hand bauen...
--
---

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

[ - Antworten - Zitieren - Direktlink - ]

code:

---

Import "CImage"                         ; use CImage Class

 CImage img = New()                      ; declare an image object

 img.Load("DH0:Pics/image.png")          ; load from disk
 img.Resize(800,600)                     ; resize to 800x600 pixels
 img.Save("DH0:Pics/image.jpg",'JPEG')   ; save as JPEG

 img.Delete()

 End                                     ; end of program

---

code:

---

Import "CSound"                         ; use the CSound Class

 CSound snd = New()                      ; declare a sound object

 snd.Load("DH0:SFX/Bing.wav")            ; load a sound from disk
 snd.Play()                              ; play the sound
 snd.Resample(44100)                     ; resample the sound to 44100kHz
 snd.Save("DH0:SFX/Bing.aiff",'AIFF');   ; save the sound as AIFF
 
 snd.Delete()

 End                                     ; end of program

---

code:

---

Import "CThread"

CThread thrd = New()
thrd.SetEntryPoint(&myFunction)
thrd.Run()
...
thrd.Break()
thrd.Delete()

End

---

[ - Antworten - Zitieren - Direktlink - ]

Du musst immer die Koordinaten angeben bei Blitting, das ist doch gerade der Sinn
Aber nehmen wir mal ein fiktives GUI Toolkit, da sollen die Elemente (standardmäßig, wenn man kein eigenes Layout verwendet) auch automatisch angepasst werden.
Der Programmierer von so einer Komponente muss sich natürlich darum kümmern. Der Programmierer, der diese Komponente dann verwendet, nicht mehr.
So etwas gibt es allerdings bereits. Es nennt sich MUI

Man kann schon so Routinen machen, auch ein TextW, welches auotmatisches Wrapping hat und dergleichen. Die Frage ist dann, ob dies nur bei bestimmten Komponenten passieren soll.
Auf Windows passen sich die Komponenten mit sogenannten "Anker" (Anchors) an, das ist aber dann nicht automatisch wie bei MUI sondern statisch mit "festgeklebten" Seiten die sich mit dem Fenster vergrößern/verkleinern. Auch Textlabels sind statische Elemente.
(Mit statisch und dynamisch mein ich die Platzierung auf einem Fenster oder Form)
Die API um diese Elemente anzusprechen sind nicht aus Windows sondern aus der GUI Umgebung.

Ok anders gefragt: Wäre eine IDE, die die Event-Zuordnung und dergleichen automatisch bereitstellt nicht sinnvoller als über eine neue API nachzudenken? Wenn schon die Vorschläge nicht angenommen werden...

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

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 - ]

code:

---

CImage img = New("Dh0:test.jpg"); <= von Datei

CImage img = New("Dh0:test.gif",4); <= von Datei, Bild # 4

CImage img = New(*screen,x,y,width,height); <= grabben vom Screen

CImage img = New(width,height,rgb); <= blankes Bild

CImage img = New(Bitmap, Viewport); <= von Bitmap holen

CImage img2 = New(img); <= duplizieren

...

---

[ - Antworten - Zitieren - Direktlink - ]

Dieser Code hat Dich Wochen gekostet?
Dann weiß ich warum Du eine andere API willst

Allerdings sollte ein neues Interface Programmiersprachen-unabhängig sein, also Linklib oder Shared Lib und entsprechende Header-Files für diverse Sprachen.
Selbst wenn sie offiziell wären, würden alte Amiga Programmierer noch die bisherigen Funktionen benutzen, Neueinsteiger würden es sich überlegen...

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Muss dazu sagen, daß ich deinen zweiten Beitrag noch nicht lesen konnte als ich meine Antwort geschrieben hab, weil wir gleichzeitig geschrieben haben
Nein ich finde es nicht "cool" aber ich bin mit der API aufgewachsen, und kenne daher die Strukturen und wie die Funktionen allgemein aufgebaut sind. Ich habe das so seit vielen Jahren im Blut. Deshalb würde ich eine neue API anfangs eher selten benutzen. Das soll es aber nicht schlechtreden, es war nur als Anmerkung gedacht.

Vll kams auch falsch rüber, ich meinte das nicht proletenhaft sonder verständnisvoll. Ich kanns auch anders formulieren:
Wenn der Code Dir zu kompliziert ist, dann versteh ich warum Du eine einfachere Programmierweise suchst.

Der Code muss dann aber auch Leakfree sein, Speicherlöcher müssen vermieden werden, was bei solchen high level APIs nicht immer einfach ist. Threadsafe sollte er auch sein....

Da hatte ich letztens das Problem auf Windoof. Trotz "korrekter" Programmierung ständig Verbindungsprobleme zur Datenbank. Bis ich dahintergekommen bin, daß das DB System nicht Threadsafe ist. Die Folge: In jedem Thread neue DB Verbindung öffnen, dann sollte es klappen. Hat mich 2 Wochen gekostet bis ich das rausgefunden hab....

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
...
... Hat mich 2 Wochen gekostet bis ich das rausgefunden hab....

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Ich denk Du hast mich nicht richtig verstanden
Die Entwickler der High Level API müssen Bugs vermeiden, damit der Programmierer, der diese API anwendet, auf der sicheren Seite ist. Er soll ja nicht tiefgreifend in die Routinen rein sollen (Blackbox Prinzip).
Wenn der Programmierer mehr auf "Low Level" setzt, ist er natürlich selbst dafür verantwortlich was er macht, und muss sich um mehr Details kümmern. Allerdings weiß er dann auch tiefgreifender was er macht.

Die "These" ist daher nur halb verstanden
Bugs in High Level APIs, welche ein Drittentwickler verwendet, sind schmerzlicher als Bugs die er selbst im Griff hat, wenn er "Low Level APIs" verwendet, da/wenn er diese selbst beheben kann.
Wenn aber der Bug in beiden Möglichkeiten drin bleibt, ist das natürlich gleich schlimm

--

Anm zur Begrifflichkeit: Der Begriff "Low Level API" in diesem Beitrag ist in "" weil es nicht wirklich Low Level ist sondern eine tiefere Schicht als die hier angepriesene High Level API darstellen soll, auch wenn die hier zitierte Low Level API auch eine High Level API des AmigaOS ist Der Begriff wird hier nur zur besseren Unterscheidung verwendet.

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

So jetzt sind wir wieder beieinander Genau so ist es.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:

? Was möchtest du uns damit sagen? Dass BlitzBasic2 einen Bug hat?
BB2 hat massig Bugs, sonst hätten wir ja in Amiblitz2/3 nicht so viel zu tun gehabt ;-)
> und damit getötet:
Da hast du aber schnell aufgegeben ;-)

---

Weiss ich schon, wollte nur die 2 Wochen toppen
Ich hab auch nicht aufgegeben. Ich schau mir alle sources alle paar jahre mal an. Und da find ich dann Sachen, die ich heutzutage nicht mehr so machen würde-und ändere das dann.

Zitat:

---

> kann jetzt alles neu machen (weil: 10 Jahre alt).
Software ist keinem Alterungsprozess unterworfen (höchstens der Datenträger...). Die Ansprüche ändern sich nur. Dann müsstest du aber auch bei erfolgreicher Fertigstellung vor 10 Jahren alles neu machen...

---

Zitat:

---

Thores These ist, dass Bugs in High-Level APIs zu größeren Problemen führen als Bugs in Low-Level APIs. Interessant. Klingt auch auf den ersten Blick intuitiv richtig. Aber ist das wirklich so? Bin ich im Low-Level Falle nicht genauso aufgeschmissen, nur weis ich etwas genauer was nicht funktioniert? Und rechtfertigt das den Mehraufwand im Falle wenn kein Bug auftritt?

---

Zitat:

---

Andersherum betrachtet, wenn ich z.B. ein Bild via DT laden will, dann kann ich unglaublich viele Bugs selbst produzieren (im Vergleich zu einem "LoadImage", wo ich höchstens den Dateinamen falsch schreiben kann). Wäre es nicht besser, wenn jemand, der sich besser auskennt als ich, das in eine Robuste "LoadImage" Funktion gegossen hat? Und wenn diese Funktion von Vielen benutzt wird, sollte sie dann doch stabiler sein als meine Home-Brew "MyLoadImage" die nur ich benutze?

---

[ - Antworten - Zitieren - Direktlink - ]