Wieso sollte ein Programmierer einen Unterschied merken, ob er nun eine Funktion direkt nutzt oder über eine Lib?
Abgesehen davon, daß im AmigaOS die API Funktionen ebenfalls über Libs bereitgestellt werden, sogar exec ist als lib vorhanden....

Ok, VCL, CLX etc bedienen sich intern den WinAPI Routinen, falls nötig, aber sudeln auch gern selbst auf der Canvas rum, abhängig von der Komponente.

Es ging doch um die Bequemlichkeit beim Programmieren?
Direkte Änderungen an APIs machen ein Betriebssystem kaputt, bei Windows merkt mans langsam. Lauter Änderungen, die API ändert sich sogar von Service Pack zu Service Pack. Lauter Strukturen mit Endung "Ex" oder einfach durchnummeriert. (Drucker-Strukturen gehen sogar bis Nr 9 hoch), jedes Struct hat Attribute für n verschiedene Win Versionen, die Du abprüfen musst.
Also meiner Meinung nach ist sowas der falsche Weg (obwohls sicher auch so kompatibler gehen könnte), alles über API Funktionen zu versuchen. Eine Lib hingegen lässt sich auch auf einer neuen Amiga Version nutzen. Neue Libs müssten entsprechend abwärtskompatibel bleiben.

Für den Programmierer an sich spielt es aber keine Rolle, wo sein Aufruf versteckt ist (wenn er nach dem Blackbox Verfahren handelt).

Sicher hat beides Vor- und Nachteile. Aber hauptsache es funktioniert und man kann damit arbeiten, oder?
Bis die API geändert wird..... oder dann doch lieber ne Lib?

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

;///////////////////////////////////////////////////////////////////////////////
;/                                                                             /
;/ Syntax:  succ.l = image_CutRP{image.l,*rp.RastPort,@x.l,@y.l,@xs.l,@ys.l:: /
;/ ,@trgb.l,@tolerance.l,@dithermode.l,@colorMap.l}                            /
;/                                                                             /
;/ Description:                                                                /
;/ Creates an image object out of (a part of) the given Rastport.              /
;/ NOTE:  ideal for screen-grabbing.                                           /
;/                                                                             /
;/ Inputs:                                                                     /
;/ - image.l        : image object ID                                              /
;/ - *rp.RastPort   : Rastport where to fetch the data from                    /
;/ - trgb.l         : rgbvalue for the desired transparent color, e.g. $ff0000 f:: /
;/ or red, set it to -1 for no transparency                                    /
;/ - x.l,y.l        : optional: position from where to fetch                       /
;/ - xs.l,ys.l      : optional: width and height of the area to fetch              /
;/ - tolerance.l    : ???                                                      /
;/ - dithermode.l   : ???                                                     /
;/ - colorMap.l     : ???                                                       /
;/                                                                             /
;/ Result:                                                                     /
;/ - succ.l     : True if everything went well, False if it failed             /
;/                                                                             /
;///////////////////////////////////////////////////////////////////////////////
Function.l image_CutRP{image.l,*rp.RastPort,@x.l,@y.l,@xs.l,@ys.l,@trgb.l,@tolerance.l,@dithermode.l,@colorMap.l}
SHARED imagedat(),imageengine:USEPATH imagedat(image)
succ.l = False
If *rp
  If x<0 Then x=0
  If y<0 Then y=0
  If *rpLayer
    If xs<=0 Then xs=*rpLayerWidth  -x
    If ys<=0 Then ys=*rpLayerHeight -y
  Else
    If *rpBitMap
      If xs<=0 Then xs=GetBitMapAttr_(*rpBitMap,#BMA_WIDTH)  -x
      If ys<=0 Then ys=GetBitMapAttr_(*rpBitMap,#BMA_HEIGHT) -y
    End If
  End If

  If image_Create{image,xs,ys}
    d.l=GetBitMapAttr_(*rpBitMap,#BMA_DEPTH)
    If d>8 OR d<=0
      ReadPixelArray_ raw_ptr,0,0,bpr,*rp,x,y,xs,ys,#RECTFMT_ARGB
    Else
      *scr.Screen = Peek.l(Addr Screen (Used Screen))
      If *scr
        scr_depth.l = d ;*scrBitMapDepth
        CopyMem_ *rp,temprp.RastPort,SizeOf.RastPort
        temprpLayer = 0
        xsw.l = (((xs+15) LSR 4) LSL 4)
        temprpBitMap = AllocBitMap_ (xsw,1,8,0,0)
        temprpBitMapBytesPerRow = xsw LSR 3
        penArray8.l = tempbuffer_Get{xsw*ys*1}
        ReadPixelArray8_ *rp,x,y,x+xs-1,y+ys-1,penArray8,temprp
        FreeBitMap_ temprpBitMap

        lut.l = AllocVec_(256*4,#MEMF_CLEAR)

        If colorMap=-1
          For n.l=0 To 1 LSL scr_depth-1
            GetRGB32_ *scrViewPortColorMap,n,1,col.cmapitem
            R.l = colR LSR 24
            G.l = colG LSR 24
            B.l = colB LSR 24
            ARGB.l = (R LSL 16) | (G LSL   | (B)
            Poke.l lut+n*4,ARGB
          Next
        Else
          For pen.l=0 To (1 LSL scr_depth)-1
            *CReg.ColorRegister = colorMap + 3*pen
            Poke.l lut + (pen LSL 2),((*CRegred&$00FF) LSL 16) | ((*CReggreen & $00FF) LSL   | (*CRegblue & $FF)
          Next
        End If
        For y.l = 0 To ys-1
          For x.l = 0 To xs-1
            pen.l = Peek.b(penArray8+y*xsw+x) & $FF
            Poke.l raw_ptr+y*bpr+(x LSL 2),Peek.l(lut+(pen LSL 2))
          Next
        Next
        FreeVec_ lut
      End If
    End If
    If trgb><-1
      image_InitMask{image,trgb,tolerance.l}
    Else
      mask_trgb = -1
    End If
    succ.l = True
  End If
Else
  error{"\__THIS_FUNCTION: Uninitialized rastport!"}
End If
If succ=False Then image_Free{image}
Function Return succ
USELASTPATH
End Function

---

[ - Antworten - Zitieren - Direktlink - ]

Da dieser Thread zu lang geworden ist um auf alle Beiträge einzugehen, ich zudem gestern Skat-Abend hatte, hier nur kurz meine Gedanken.

Fakt ist, und da stimme ich whose uneingeschränkt zu, dass das Amiga Segment in unterschiedliche Lager aufgeteilt ist und die jeweiligen APIs immer weiter auseinanderdriften.
Fakt ist aber auch, dass dies ein natürlicher Prozess ist, der weder aufgehalten werden kann noch soll. Unsere eigene Existenz ist durch solche Abläufe bestimmt worden, ansonsten säßen wir nach wie vor als kleine Gruppe um ein Lagerfeuer herum (falls wir soweit wären, ein Feuer zu entfachen) und würden beten, dass uns bei Nacht nicht irgendein Tier auffrisst.
Fakt ist aber auch, und da stimme ich Der_Wanderer zu, dass es abstrakte APIs gibt, die es sehr erleichtern ein Programm auf einem völlig fremden Betriebssystem ohne irgendwelche Änderungen zu kompilieren und auszuführen, ohne dass irgendwelche Fehler auftreten.
Solange aber auf der MorphOS und AmigaOS4 Seite nicht die Version seitens der Kernentwickler bereitgestellt wird, die annähernd dem entspricht was sich diese Entwickler für das jeweilige Betriebssystem wünschen, solange wird kein (Hobby-) Programmierer sich die Mühe machen, eine API zu schreiben bzw. portieren, die losgelöst vom zugrunde liegenden Betriebssystem ist. Den kleinsten gemeinsamen Nenner den wir heutzutage haben, ist die POSIX-API. Damit kann man UNIX, BSD, Linux, QNX, MS-Windows (mit Einschränkungen) und viele andere Betriebssysteme auch, inklusive des AmigaOS (sowie Klone) (mit Einschränkungen) und das MorphOS-Betriebssystem (mit Einschränkungen) programmieren.
Der Nachteil an POSIX ist, dass es C zwingend voraussetz sowie auf spezielle Merkmale eines Betriebssystems nicht eingeht und zum Thema Benutzerschnittstelle nur die Konsole anbietet.

Zum Thema Datatypes kann ich nur anmerken, dass das Konzept veraltet ist, da es nicht die heutigen Belange abdeckt, und zwar das Laden und Speichern von Dateien, die im Netzwerk liegen, inklusive wahlweiser Abbruchmöglichkeit des jeweiligen Vorganges. Ach ja, das leidige Thema Netzwerk und Internet seitens des Amiga/MorphOS Betriebssystem... Hier besteht auch noch Nachholbedarf obwohl sich die Situation schon sehr gebessert hat.

Bezüglich IDE: Viele Programmierer benutzen keine IDE, sondern einen Texteditor nach Wahl und 'makefiles'. Es gibt aber sicherlich genauso viele Programmierer (wenn nicht sogar mehr), die eine IDE benutzen.
Mir persönlich bringt eine IDE auf dem Amiga (OS3) aber solange nichts, wie mir schneller als ich schauen kann das Betriebssystem unterm Hintern wegschmiert, und das nur bei kleinen Fehlern. Das Laden einer IDE unter AmigaOS3 dauert mir viel zu lange, da lobe ich mir schlanke Texteditoren, die es zu Hauf auf dem Amiga gibt.
Komischerweise nutze ich heute unter Windows auch keine IDE obschon MS Studio 2008 komplett vorhanden ist, sondern schreibe lieber 'makefiles' für 'nmake'. Geht sehr wahrscheinlich darauf zurück, dass mir Frank Wille 'makefiles' gemailt hatte, die selbst 'nmake' abdeckten, obwohl er nach eigenen Aussagen mit Windows nichts am Hut hat.
Von Profis kann einer wie ich viel lernen bzw. viel klauen...

Ich habe zudem eine andere Ansicht als Der_Wanderer bezüglich "warum ein Betriebssystem ein Erfolg wird oder nicht".
Der Schlüssel zum Erfolg, meiner Meinung nach, ist das Marketing. IBM OS2 war zu jener Zeit in jeder Hinsicht besser als Windows, es wurde trotzdem kein Erfolg.
Ich behaupte mal, dass QNX Neutrino wesentlich besser als Linux ist - und es trotzdem kein Erfolg wurde.
Das kann man so weiterspinnen.
Ich glaube, wer gut täuscht, hat schon die halbe Miete gewonnen.
Nichtsdestotrotz ist jedes Betriebssystem für sich genommen ein Glanzstück an Programmierkunst. Man macht sich keine Gedanken, was die betreffenden Programmierer geleistet haben bzw. leisten, um aus einer Ansammlung von elektronischen Komponenten ein funktionierendes 'es' zu schaffen.
Demnach halte ich es wie whose: Ich bin mit dem zufrieden, was ich vorfinde, auch wenn es bedeutet, sehr viel Zeit in Funktionen zu stecken, die noch nicht im Betriebssystem verankert worden sind bzw. noch von keiner dritten Partei geschrieben wurden (Stichwort: Library).
Und ja, auch Der_Wanderer hat Recht: Je weniger Zeit man sich mit Low-Level-Funktionen rumplagen muss, desto schneller sieht man Ergebnisse. Nur, sind wir davon bei der Amiga/MorphOS-Programmierung weit entfernt. Aber, das macht auch einen Teil des Reizfaktors beim Programmieren aus - die Zusammenhänge zu verstehen und nicht nur etwas nutzen. Alle, die ausschließlich letzteres wollen, sollten einen Blick auf Hollywood werfen.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von jolo:
Bezüglich IDE: Viele Programmierer benutzen keine IDE, sondern einen Texteditor nach Wahl und 'makefiles'.

---

Zitat:

---

Mir persönlich bringt eine IDE auf dem Amiga (OS3) aber solange nichts, wie mir schneller als ich schauen kann das Betriebssystem unterm Hintern wegschmiert, und das nur bei kleinen Fehlern.

---

Zitat:

---

Das Laden einer IDE unter AmigaOS3 dauert mir viel zu lange, da lobe ich mir schlanke Texteditoren, die es zu Hauf auf dem Amiga gibt.

---

Zitat:

---

Ich habe zudem eine andere Ansicht als Der_Wanderer bezüglich "warum ein Betriebssystem ein Erfolg wird oder nicht".
Der Schlüssel zum Erfolg, meiner Meinung nach, ist das Marketing. [...]
Ich behaupte mal, dass QNX Neutrino wesentlich besser als Linux ist - und es trotzdem kein Erfolg wurde.

---

Zitat:

---

Und ja, auch Der_Wanderer hat Recht: Je weniger Zeit man sich mit Low-Level-Funktionen rumplagen muss, desto schneller sieht man Ergebnisse. Nur, sind wir davon bei der Amiga/MorphOS-Programmierung weit entfernt.

---

Zitat:

---

Aber, das macht auch einen Teil des Reizfaktors beim Programmieren aus - die Zusammenhänge zu verstehen und nicht nur etwas nutzen. Alle, die ausschließlich letzteres wollen, sollten einen Blick auf Hollywood werfen.

---

Zitat:

---

Original von Thore:
Hollywood ist ein Multimedia Layer und keine "echte" Programmiersprache an sich.

---

Zitat:

---

Trotz einfacher Syntax verwendet man es nicht so groß wie C/C++, obwohl es auch Win-Versionen gibt. Dann kanns wohl nicht an der API/Befehlssatz liegen.

---

Zitat:

---

Macht man sich als 1-Mann-Programmierer die Arbeit, die auf anderen Systemen zwischen 5 und 100 Leute gemacht haben?
Ich denke DAS ist vielmehr der Knackpunkt. Ein Ressourcen-Zeit-Problem.

---

Zitat:

---

AmigaBASIC hat auch einen einfacheren Befehlssatz wie C/C++, wird aber weniger verwendet (Liegt aber vermutlich eher in den Micro$oft Bugs *g*)

---

Zitat:

---

Original von Der_Wanderer:
... wobei Hollywood ein geschlossenes System ist, soweit ich weis. Das geht für "richtige" Entwicklung natürlich nicht, weil man zu anderen Libs, Sprachen, CPUs etc. im Ernstfall offen sein muss.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:

Eine gute Basis dafür wäre wohl AROS, das wären die einzigen die sowas "offiziell" machen könnten, und vielleicht würde es dann auf den anderen Platformen akzeptiert.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Ich glaube die "Zufriedenheit" mit der API so wie sie ist kommt daher, dass kaum jemand noch versucht was ernsthaftes damit zu entwickeln.
Den Amiga Proggern geht es wohl eher darum, sich mit dem OS als Selbstzweck zu beschäftigen als mit einer echten, nützlichen Applikation, die entstehen soll.

---

Würdest Du nur mich ansprechen, würde ich Dir zustimmen. Da ich Programmieren nur als Hobby betreibe, kann daran auch keiner etwa aussetzen.
Ich verlange kein Geld für meine Programme, dementsprechend brauche ich auch keine Rücksicht auf Anwender zu nehmen. Ich entwickle hauptsächlich Werkzeuge, die für mich interessant sind.

Ich kann Dir aber auch versichern, dass es professionelle Programmierer gibt, die nach wie vor versuchen ihre zig Mega-Bytes umfassende kommerzielle Anwendung AmigaOS/MorphOS tauglich zu halten, und ich meine diesmal nicht Hollywood.
Zudem sind sie trotz der deiner Meinung nach "Unzulänglichkeiten der Amiga/MorphOS Betriebssystemen" imstande, ihre Programme AmigaOS/MorphOS kompatibel zu halten, teilweise aber mit Abstrichen. Ob es sich für sie rechnet, wird die Zukunft zeigen.

Zitat:

---

Es werden eher Mini-Projekte gemacht, die zum Experimentieren oder Lernen dienen, aber nicht als richtige Applikation released werden sollen, wo man auf Stabilität, GUI Richtlinien, Integration ins OS, Kompatibilität mit der Aussenwelt etc. wert legt.

---

Zitat:

---

Das Problem ist wohl eher dieses: Man sieht auf Linux ein Programm, versucht es zu portieren. Es ist posix, benutzt vll noch fork/vfork und schon fängt das erste Problem an: Kein posix, kein fork.

---

Solange es die POSIX-API benutzt kann man es portieren, auch wenn einige POSIX-Funktionen in der entsprechenden Amiga-Implementierung nicht vorhanden sind. Es bedeutet aber einen Mehraufwand, weil man die fehlenden Funktionen nachbilden muss.
Bei fork() sieht es ähnlich aus aber man kann es leider nicht wirklich benutzen, weil es keine Benutzerrechte unter AmigaOS gibt.
Demnach, da hast Du Recht, ist es fast aussichtlos ein Programm zu portieren, dass fork() benutzt.
Für MorphOS/AmigaOS4 bin ich mir nicht sicher, ob es nicht doch möglich ist solch eine Funktion nachzubilden, weil beide versuchen, mehr POSIX-Style (Linux) Programmierung zu erlauben, bzw. die Low-Level-Funktionen die als Basis dafür dienen, anzubieten.
Da müsste man sich an die jeweiligen Entwickler wenden. Ich bin da überfragt.


@Der_Wanderer:

Zitat:

---

Aber ich bin nun immerhin in der Lage, wenn du mir jetzt sagst: "Programmiere ein Tool, wo ich ein Bild reinladen kann, die Schärfe und Farbraum anpassen, resizen und als JPEG, PNG, BMP oder IFF abspeichern."
Dann kann ich das in 2-3h erledigen, und zwar so dass es unter OS3, OS4 und MOS funtkioniert.
Mit der AmigaOS API direkt brauche ich dafür 20-30h, oder vermutlich noch wesentlich mehr wenn man die Saver und DSP Algorithmen noch entwickeln muss, und dannach auch noch Beta Testen auf den verschiedenen Plattformen.

---

Zitat:

---

Das mag für C-Programmierer so sein, insbesondere, wenn die IDEs, die sie sich vorher angeschaut haben, tatsächlich nur umständlich zu bedienende makefile-Generatoren waren.
Wenn man erst mal mit anderen Programmiersprachen gearbeitet hat, kommt einem so etwas wie eine Rückkehr zur Steinzeit vor.

---

Die wirklich erste gute IDE, abgesehen von Devpac 3, die ich verwendet habe, war die, die dem MaxonC++-Compiler spendiert wurde. Ausgeklügelt angelegt, bunt ( ), übersichtlich, intuitiv zu bedienen.
Die VC++ IDE unter Windows ist bestimmt nicht schlecht - und trotzdem komme ich mir nicht vor als wäre ich wieder im Steinzeitalter gelandet nur weil ich handverfasste 'makefiles' benutze.
Zudem glaube ich nicht, aber ich kann mich täuschen, dass ein Projekt mittels einer IDE erstellt, so ohne weiteres auf andere Systeme übertragbar ist. Demnach, falls meine Aussage richtig ist, muss man sich ohnehin mit 'makefiles' beschäftigen, wenn man denn etwas von einer anderen Plattform portieren möchte bzw. auf eine andere portieren möchte, jedenfalls für C/C++.

Da die Programmiersprachen, die ich momentan benutze als ausreichend für meine Belange erscheinen, sehe ich auch nicht die Notwendigkeit, eine IDE zu erlernen.
C und C++ sind relativ weit *unten*, Java und Co relativ weit *oben*, demnach denke ich, dass man bei höheren Programmiersprachen mehr Wert auf eine IDE legt, abgesehen vom persönlichen Geschmack.
Es gibt nämlich auch Assembler-Programmierer, die eine IDE verwenden.

Zitat:

---

Mir persönlich bringt eine IDE auf dem Amiga (OS3) aber solange nichts, wie mir schneller als ich schauen kann das Betriebssystem unterm Hintern wegschmiert, und das nur bei kleinen Fehlern.

Zitat:

---

Ja, woran liegt das wohl...
Da spielt die Kombination aus Programmiersprache und API des Betriebssystems mit Sicherheit eine nicht zu unterschätzende Rolle.

---

---

Nee, für Fehler zeichne ich mich alleine verantwortlich.
Es gibt Tage, da programmiere ich ohne einen einzigen Fehler im Quellcode zu haben, abgesehen von kleinen Unzulänglichkeiten. Es gibt aber auch Tage, da mache ich dermaßen viele Fehler an einem einzigen Tag, dass ich manchmal an mir selber zweifle.

Zitat:

---

Und Du meinst "Linux" hat mehr Marketing betrieben als QNX?

---

Zitat:

---

Auch auf einer höheren Ebene bedeutet Programmieren, Zusammenhänge zu verstehen. Man hat allerdings die Gelegenheit, auch größere Zusammenhänge zu verstehen...

---

Zitat:

---

Natürlich ist es ein Ressourcen/Zeit Problem. Deshalb kann sich Linux auch leisten, grottige APIs anzubieten und irgendwer baut dann schon bessere High-Level APIs drumherum, gerne auch zwei, drei verschiedene Parteien gleichzeitig, so entstehen Gnome und KDE, WebOS und ChromeOS und trotzdem bleiben noch Ressourcen übrig, um darauf aufsetzend auch noch nutzbare Anwendungen zu stricken.

Der Amiga hat solche Ressourcen nicht, und genau deswegen ist es umso wichtiger, die Ressourcen nutzbringend einzusetzen und nicht dafür zu verpulvern, zum hundertsten Mal den gleichen Workaround um eine unzureichende Funktion zu bauen.

---

Zitat:

---

Eigentlich müssten sich alle verbleibenden Entwickler erstmal auf eine freie, offene high-level API für AmigaOS stürzen.

---

Wenn Du mehr als eine Personen in ein Boot steckst und keine klare Hierarchie besteht, wird nur Chaos dabei herauskommen.
Hat aber einer das letzte Wort, muss sichergestellt werden, dass diejenigen, die etwas ausarbeiten sollen, es auch tun, ohne wenn und aber. Üblicherweise spricht man dann von einem Angestelltenverhältnis.
Du weißt worauf ich hinaus will?

Habe ein wenig Geduld, irgendwann erfahren wir, ob MorphOS oder AmigaOS4 oder auch AROS das Zeug dazu haben, weiter zu bestehen. Für Dich, der etwas Kommerzielles vertreiben möchte, ist es bestimmt nicht der beste Rat, aber am Beispiel von Hollywood kann man erkennen, dass es jetzt auch schon möglich ist kommerzielle Wege zu beschreiten, allerdings dies mit Aufwand verbunden ist.
Ob Du dazu bereit bist, liegt einzig und alleine bei Dir.
Anbei, eine einheitliche API für die verschiedenen Systeme wird es meiner Meinung nach nie geben.


Grüße

[ - Antworten - Zitieren - Direktlink - ]

@Holger
Ja ob was kommerziell ist oder nicht ist auch ein Faktor, den man nicht unterschlagen sollte. Allerdings ist Hollywood seinen Preis wert.

Ich sagte nicht daß AmigaBASIC einen kleineren Befehlsumfang hat sondern "einfacher". Wobei Du mit Deiner Kritik recht hattest, ich meinte nicht den Befehlssatz an sich sondern die Befehle und das Programmieren an sich (z.B. um ein Window zu öffnen braucht man hier nur eine Zeile Code, auf OS1.x und C geht es nur mit mehreren, ab OS2.x Dank TagLists in wenigen Zeilen aber immer noch mehr Schreibarbeit)
Daß C nur eine kleine Menge eigener Befehle mitbringt ist jedem C-Programmierer bekannt
Sorry, mein Fehler.

Wenn Hollywood seine Plugin-Schnittstelle bekommt, könnte man flexibler werden.

Auf anderen Systemen zahlen die Leute 6000 Euro für ein Programm, um Installations-Pakete zu erzeugen... Soviel zur Relation

Die Linux-Programme sind übrigens nicht "fürs Portieren" gemacht
Die Portabilität von Linux-Programmen ist eigentlich nur innerhalb der Linux-Welt zu verstehen. Alles was nach außen portiert wird, ist entweder zufällig gleich richtig oder muss kompatibel gemacht werden (z.B. mit Hilfe von GeekGadget, ixemul, cygwin,....)

Das MorphOS OWB und AmigaOS OWB benutzen nur den gleichen Kern. Alles andere außenrum ist eigenständig. Timberwolf benutzt als GUI übrigens Intuition und kein GTK-Ersatz. Also auch viel Handarbeit (sonst wärs ja easy, einfach compilieren...)

Eine zumindest teilweise einheitliche API wurde mit SDL schon versucht, das klappt auch soweit ganz gut

Also Leute, programmiert Es fehlt noch ein Office und ein gutes Chatprogramm

[ Dieser Beitrag wurde von Thore am 08.05.2010 um 20:04 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von jolo:
Die wirklich erste gute IDE, abgesehen von Devpac 3, ...

---

Zitat:

---

... die ich verwendet habe, war die, die dem MaxonC++-Compiler spendiert wurde. Ausgeklügelt angelegt, bunt ( ), übersichtlich, intuitiv zu bedienen.

---

Zitat:

---

Zudem glaube ich nicht, aber ich kann mich täuschen, dass ein Projekt mittels einer IDE erstellt, so ohne weiteres auf andere Systeme übertragbar ist. Demnach, falls meine Aussage richtig ist, muss man sich ohnehin mit 'makefiles' beschäftigen, wenn man denn etwas von einer anderen Plattform portieren möchte bzw. auf eine andere portieren möchte, jedenfalls für C/C++.

---

Zitat:

---

Es gibt nämlich auch Assembler-Programmierer, die eine IDE verwenden.

---

Mindestens Dich und mich.

Zitat:

---

Nee, für Fehler zeichne ich mich alleine verantwortlich.

---

Zitat:

---

Zitat:

---

Und Du meinst "Linux" hat mehr Marketing betrieben als QNX?

---

Ich gehe davon aus. Das Pinguin-Emblem findet man überall, anders als der goldene Stern.

---

Zitat:

---

Was sind für Dich größere Zusammenhänge?

---

Zitat:

---

Obschon Du definitiv Recht hast, spielt es doch nur eine entscheidende Rolle für kommerzielle Projekte, die mal eben so auf die Schnelle portiert werden sollen.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Reth:

Du liebe Güte, hört das eigentlich nie auf? Ihr redet um den heißen Brei herum. Weder Java noch Windows hatten "von Geburt" an die "API", von denen ihr hier berichtet. Beide sind immer noch genau so "low level" wie AmigaOS. Der Knackpunkt sind die (mehr oder weniger) fehlenden Toolkits, Linker-Libraries, DLLs oder AmigaOS shared libraries für eure Zwecke, nicht das AmigaOS API an sich.

Blättert einfach mal durchs Aminet, wie viele Toolkits sich dort befinden, die keine S** (tschuldigung!) außer dem Entwickler selbst je benutzt hat. Es finden sich sogar mehrere Bibliotheken für OOP-Fans da. Wer hat die bisher genutzt? Und wenn die nicht genutzt wurden, aus welchen Gründen? Welche Ausrede findet ihr, um die auch nicht zu nutzen?

Ich kann diese "aber das API ist soooo schlecht"-Jammerei echt bald nicht mehr lesen. Nutzt endlich mal das, was zur Verfügung steht und verbessert es ggf., statt ständig nach neuen Toolkits zu brüllen, die dann doch wieder kein Mensch nutzt.

Oder macht die von Euch so dringend benötigten Toolkits selbst. Da zeigt sich dann auch ganz nebenbei, ob es wirklich sinnvoll ist, die von Euch bevorzugten API-Erweiterungen/-Vereinfachungen per Toolkit für AmigaOS zu benutzen. In den meisten Fällen dürfte auf Euch die eine oder andere nicht so positive Überraschung warten, was z.B. Performance angeht...

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Wie ich schon öfters sagte. Nicht lange fackeln, handeln.
Eine Linklib könnte das Problem lösen Also ran an den Speck.

Ihr wisst ja was zu tun ist, wenn ich eure Beiträge so les. Hihi.

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Du liebe Güte, hört das eigentlich nie auf? Ihr redet um den heißen Brei herum.

---

Zitat:

---

Weder Java noch Windows hatten "von Geburt" an die "API", von denen ihr hier berichtet. Beide sind immer noch genau so "low level" wie AmigaOS.

---

Zitat:

---

Blättert einfach mal durchs Aminet, wie viele Toolkits sich dort befinden, die keine S** (tschuldigung!) außer dem Entwickler selbst je benutzt hat.

---

Zitat:

---

Ich kann diese "aber das API ist soooo schlecht"-Jammerei echt bald nicht mehr lesen. Nutzt endlich mal das, was zur Verfügung steht und verbessert es ggf., ...

---

Zitat:

---

Oder macht die von Euch so dringend benötigten Toolkits selbst.

---

Zitat:

---

Da zeigt sich dann auch ganz nebenbei, ob es wirklich sinnvoll ist, die von Euch bevorzugten API-Erweiterungen/-Vereinfachungen per Toolkit für AmigaOS zu benutzen. In den meisten Fällen dürfte auf Euch die eine oder andere nicht so positive Überraschung warten, was z.B. Performance angeht...

---

Zitat:

---

Original von Thore:
Wie ich schon öfters sagte. Nicht lange fackeln, handeln.
Eine Linklib könnte das Problem lösen

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]