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

amiga-news.de Forum > Programmierung > AmiDevCpp [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 4 [ - Beitrag schreiben - ]

11.10.2005, 14:32 Uhr

TerAtoM
Posts: 1230
Nutzer
@Kaesebroetchen:

Hallo,

es hat sich jetzt eigentlich alles aufgelösst. Ich habe das ganze nämlich auf einem ENGLISCHEN WinXP installiert. Dort hat das Standartverzeichniss den Namen "Program Files" (im Deutschen wäre es ja "Programme"). Das hat wohl zu den ganzen schwierigkeiten geführt. Ich habe nun wieder ein neu installiertes WinXP (Englisch) genommen und den Standartpfad auf "Programme" geändert. Dann wieder AmiDevCPP (übrigens immer die neue v0.4) installiert und nun kann man alles einwandfrei Compilieren (zumindest die Basissachen die sich Automatisch anlegen). :)

Vielleicht sollte das in einem kleinen ReadMe.txt File erwähnt werden das keine Leerzeichen im Installationspfad sein dürfen, bzw. das man bei einer Englischen Windowsversion auf das "Program File" nicht installieren kann/sollte wenn man auch die C++ sparte abdecken möchte.

Ist zwar ein "Dummer" Fehler aber ich habe ihn begangen und das obwohl ich von dem "Lerrzeichen im Pfad" Problem wusste.

CU TerA
--
Bild: http://img.photobucket.com/albums/v283/TerAtoM/TeratomLogo.jpg

A4K 604e/233MHz 060/50MHz 146MB CV64_3D+SD & CVPPC
Band: http://www.TERATOM.de - Amiga: http://www.AmigaProject.de.vu
Privat: http://www.TerAmigA.de.vu - Profession: http://www.Xavo.de

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 14:37 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von bernd_roesch:
Aber schau dir mal AROS source an.auch für X86 64 bit findet sich schon einiges drin.
Es ist viel mehr aufwand alles platformunabhängig zu machen.da passierrt es halt das der builder nen include link setzt

Was hat das mit der Frage noch der korrekten Anwendung der #include Anweisung zu tun?
Das klingt doch alles nur nach herumpfuschen an den Symptomen-zuerst include falsch benutzen und dann mit links alles unnötig komplizierter machen als nötig. Der Präprozessor besitzt mit #ifdef usw. Konstrukte, die genau dafür gedacht sind, ein Herumdoktorn an der Verzeichnisstruktur des Projekts ist vollkommen unnötig.
Zitat:
schon allein das configure script hat mehr als 300 kb.Das ist schon ne grosse Leistung,auch wenn es keiner sieht.
Resourcenverschwendung-wenn doch wenigsten auf EINER Plattform das Ganze stabil laufen würde...
Außerdem werden configure-Skripte sowieso automatisch generiert-nur wenn niemand auf den verschiedenen Plattformen überhaupt mal einen Testlauf durchführt, ist es komplett sinnlos.
Theoretische Plattformunabhängigkeit ist keine.
Zitat:
schon ein OS lib aufruf muss je nach dem target system anders gehen,die aufrufkonventionen müssen
auf die target CPU angepasst werden ohne irgend ne zeile code in der lib zu ändern includes oder anwenderprog

HÄ?
Der compiler für ein bestimmtes target kennt bereits die Aufruf-Konventionen--im C-Source muß absolut nichts angepaßt werden.
Aros ist eh nur auf C-Source-Ebene kompatibel-ein Herumpfuschen an plattformspezifischen Eigenheiten sollte ja genau aus diesem Grund überflüssig sein.

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

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 16:23 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@TerAtoM:
Das ist gut. Ich werde dann erst mal einen Hinweis auf die Homepage legen.
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 18:44 Uhr

bernd_roesch
Posts: 364
[Benutzer gesperrt]
>Das klingt doch alles nur nach herumpfuschen an den Symptomen-zuerst include falsch benutzen

wenn du linux hast mach mal mit deren ihrem buildsystem (configure und make aufrufen) ein testprog.
Ich denke du kannst auch ein file im selben dir wie das aufrufende mit <> einbinden.von daher wenn nix meckert
macht man es automatisch mal aus versehen falsch

es ist nicht nur aros.zu meiner aztec C zeit wenn ich als mal sourcen runterludt und kompilieren wollte,
fand er auch nie die .h files und nix ging.Ich habe das auch nie gewusst,dass mann dann einfach " " setzt.

aber dank moderner technik in VC braucht man heute auch nimmer seitenlange man pages zu wälzen.einfach help über
include gedrückt und schon weis man was sache ist.C ist nunmal zu verworren als das man da was schnell
fehlerfrei hinkriegt

das ganze include zeugs hat mich immer abgenervt irgend nen fremden C source zu probieren

egal was,aber einfach einladen kompilieren und geht,sowas hab ich bei C nie erlebt.selbst den winuae kann ich
nun durch geänderte config files von den neueren VC nicht einfach so reinladen.

gegenüber früher aztec C kam ich mit amidev doch recht schnell zu nem ziel auf 68k kompilieren zu können
und Hilfe bei problemen bekam ich von Georg und anderen auch immer schnell.

in amidev fehlt mir nur noch der kprintf,wenn ich in main.c reinschreibe
krpintf()
{
}

kann ich das exe erstellen.nur kprintf ausgaben wollte ich schon auch machen können

>HÄ?
>Der compiler für ein bestimmtes target kennt bereits die Aufruf-Konventionen--im C-Source muß absolut nichts angepaßt werden.

wenn man die parameter per register übergeben will ohne die includes oder stubs zu ändern muss man
ja festlegen wo in welches register der architektur der par reinkommt.dazu muss man die gcc asm befehle nutzen wo
den par der architektur zuordnen.
Auch für nen aros arm port sind sourcen da.schau dir doch mal amiga libs oder MUI Klassen an wo es für 68k MOS OS4
native gibt.voll mit #ifdef.unter aros ist das nicht nötig und es geht unter 68k PPC X86 arm 64 bit oder sonstwas.
Der Grundstock für platformunabhängig ist da.

Man könnte sich zwar den ganzen heckmeck sparen,und nur über stack aufrufen,denn heutige CPU's sind eh schnell genug
aber bei MOS wurde auch gesagt es nutzt die Registerübergabe die es verhindert auf X86 portierbar zu sein.

Aros unterstüzt sowohl stackpars als auch registerpars.das es registerpars hat,macht es das als OS3.1 ersatz
reinzubauen einfacher.

z.b für 68k gemäss OS3.1 konventionen sehen die defines so aus.

#define __AROS_LHA(type,name,reg) register type name __asm(reg)
#define __AROS_LPA(type,name,reg) register type __asm(reg)
#define __AROS_LCA(type,name,reg) name
#define __AROS_LDA(type,name,reg) register type __asm(reg)
#define __AROS_UFHA(type,name,reg) register type name __asm(reg)
#define __AROS_UFPA(type,name,reg) register type __asm(reg)
#define __AROS_UFCA(type,name,reg) name
#define __AROS_UFDA(type,name,reg) register type __asm(reg)

für X86 so


#define __AROS_LHA(type,name,reg) type name
#define __AROS_LPA(type,name,reg) type
#define __AROS_LCA(type,name,reg) name
#define __AROS_LDA(type,name,reg) type
#define __AROS_UFHA(type,name,reg) type name
#define __AROS_UFPA(type,name,reg) type
#define __AROS_UFCA(type,name,reg) name
#define __AROS_UFDA(type,name,reg) type
#define __AROS_LHAQUAD(type,name,reg1,reg2) type name
#define __AROS_LPAQUAD(type,name,reg1,reg2) type
#define __AROS_LCAQUAD(type,name,reg1,reg2) name

>Resourcenverschwendung-wenn doch wenigsten auf EINER Plattform das Ganze stabil laufen würde...

Tja bei Linux wurde die Platformunabhängigkeit genauso eingeführt.nur fanden sich halt mehr wo coden.
vieleicht gab es da auch keine weiteren Anbieter wo Unix auf X86 bringen wollten,so halfen eben alle bei Linux mit

Ich möchte AROS mal für 68k als OS3.1 ersatz nutzbar machen.zumindest hat man den Vorteil
wenn man auf die alten OS funcs zurückgreifen kann immer was lauffähiges zu haben.
erst wird die layerlib ersetzt weil die bei P96 arg lahm ist für opaque fenster move.

dadurch das AROS opensource ist kann man es wenigstens verbessern.man ist nicht von nem Hersteller abhängig

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 19:51 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von bernd_roesch:
Ich möchte AROS mal für 68k als OS3.1 ersatz nutzbar machen.zumindest hat man den Vorteil
wenn man auf die alten OS funcs zurückgreifen kann immer was lauffähiges zu haben.
erst wird die layerlib ersetzt weil die bei P96 arg lahm ist für opaque fenster move.


Klingt Interessant !
Wäre das binärkompatibel zum AmigaOS ?
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 20:50 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von bernd_roesch:
aber dank moderner technik in VC braucht man heute auch nimmer seitenlange man pages zu wälzen.einfach help über include gedrückt und schon weis man was sache ist.C ist nunmal zu verworren als das man da was schnell fehlerfrei hinkriegt

Niemand hat gesagt, daß C einfach ist. Ich programmiere auch bevorzugt in anderen Programmiersprachen, trotzdem kenne ich die richtige Anwendung von #include und vor allem würde ich mich erst mal mit der Materie ausreichend beschäftigen, bevor ich mir ein Projekt in der Größenordnung eines ganzen Betriebssystems auflade. Aber Aros-Entwickler ticken ja demnach etwas anders...
Zitat:
in amidev fehlt mir nur noch der kprintf,wenn ich in main.c reinschreibe [...] exe erstellen.nur kprintf ausgaben wollte ich schon auch machen können
Tja, kprintf dient der Ausgabe aus dem Kernel und ist deshalb bei der normalen Anwendungserstellung natürlich nicht vorhanden. Dazu muß man die Software an eine spezielle Bibliothek für Kernel-Entwicklung linken.
Konnte Dir das keiner der Aros-Entwickler sagen? Eine entsprechende Bibliothek müßte ja im Aros-Source enthalten sein, wenn dieses ein komplettes Betriebssystem werden will (und kprintf selber verwendet).
Zitat:
wenn man die parameter per register übergeben will ohne die includes oder stubs zu ändern muss man ja festlegen wo in welches register der architektur der par reinkommt.dazu muss man die gcc asm befehle nutzen wo den par der architektur zuordnen.

Vollkommener Quatsch.
Nochmal: Aros beinhaltet keine Kompatiblität zu 68k-Anwendungen, benutzt deshalb das ABI der Zielplattform. Und genau dieses wird vom Compiler automatisch verwendet, wenn man eine Zielplattform auswählt. Wenn das ABI der Zielplattform Registerübergabe verwendet, wie z.B. bei den üblichen ppc-ABI, dann benutzt auch der Compiler Registerübergabe für die Funktionsaufrufe, sobald man für diese Plattform übersetzt.
Dazu muß man keine Stunts mit dem Präprozessor machen. Einzige Ausnahme ist eben 68k, wenn man Binärkompatibel mit dem Amiga sein will. Für die x86, IA64, ppc, alpha oder arm Versionen ist das aber unwichtig.
Zitat:
Tja bei Linux wurde die Platformunabhängigkeit genauso eingeführt.nur fanden sich halt mehr wo coden.
Linux hat keine neuen ABIs eingeführt.
Zitat:
vieleicht gab es da auch keine weiteren Anbieter wo Unix auf X86 bringen wollten,so halfen eben alle bei Linux mit
Du meinst, außer zum Beispiel BSD?
Zitat:
Ich möchte AROS mal für 68k als OS3.1 ersatz nutzbar machen.zumindest hat man den Vorteil wenn man auf die alten OS funcs zurückgreifen kann immer was lauffähiges zu haben.
erst wird die layerlib ersetzt weil die bei P96 arg lahm ist für opaque fenster move.


Das ist ja prinzipiell eine gute Idee, aber ohne daß einer der Kernentwickler gleiche Ambitionen entwickelt, wird das nie etwas werden.
Die halbherzigen Aussagen bezüglich 68k-Kompatiblität helfen Dir da nicht weiter. Du bist so ja schon mehr mit dem Überarbeiten der Dinge beschäftigt, die theoretisch eigentlich schon funktionieren sollten.
Vom Fertigstellen eines solchen Projekts wollen wir gar nicht erst reden...

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

[ - Antworten - Zitieren - Direktlink - ]

11.10.2005, 20:55 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Kaesebroetchen:
Klingt Interessant !
Wäre das binärkompatibel zum AmigaOS ?


In der Theorie ja.
Aber genausogut könnte man für dieses eine Feature eine re-Implementierung von Picasso96 machen (darauf läufts ja sowieso hinaus) und sich die Mühe mit dem 68k-Port von Aros sparen.

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

[ - Antworten - Zitieren - Direktlink - ]

12.10.2005, 09:37 Uhr

gni
Posts: 1106
Nutzer
Zitat:
Holger:
Zitat:
roesch:
vieleicht gab es da auch keine weiteren Anbieter wo Unix auf X86 bringen wollten,so halfen eben alle bei Linux mit

Du meinst, außer zum Beispiel BSD?
Was, es gibt tatächlich Alternativen zu Linux!?

SCNR.

[ - Antworten - Zitieren - Direktlink - ]

12.10.2005, 10:41 Uhr

bernd_roesch
Posts: 364
[Benutzer gesperrt]
>Vollkommener Quatsch.
>Nochmal: Aros beinhaltet keine Kompatiblität zu 68k-Anwendungen, benutzt deshalb das ABI der Zielplattform.

Hast dir aros noch nie angesehen und dann weist du das schon..

Mir hat Georg gerade die aros diskfont library geschickt wo er vor 3 Jahren zu testzwecken für uae erstellte
Das zeigt es geht ohne #ifdef orgien

ansonsten hat es ca 5 Std (4 E-Mails wenn man das warten auf Mail pausen abzieht) gebraucht um aros ohne Linux als
Host zu compilieren.normalerweise ist aros buildsystem dazu ausgelegt über das configure script unter
Linux alles zu ermitteln und manche files (z.b lidefs.h) automatisch zu erstellen.deshalb braucht man Linux um es zu kompilieren

Aber es ist auch so gut durchdacht,denn wenn man
machine.h (wo ich von Georg's diskfont lib habe)von Hand anpasst,das libdefs_68k_uae.h
(_68k_uae.h ist ein file wo nicht in aros vorkommt,und einmal pro amigaoslib im dir sein muss)
von Hand erstellt,kann man die lib ohne source Änderung auf jedem beliebigen system compilieren.
Da MOS auch AROS nutzt gingen die wohl den selben Weg
nur wie es geht haben die nicht verraten oder das machine.h für aros lib funcs hostet on MOS releast.
Im prinzip ist das was ich machen will ähnlich MOS.MOS hatte allerdings schon (super)layerslib und gfx libs von CGX her.
BeiBei MOS ists die gadtoolslib und (teile oder ganz weis ich nicht) intuition.library

Da das einbinden der libdefs auch über ein define geht,kann man jedes beliebige file einbinden
ohne den source zu ändern.die endung _68k_uae.h

#include LC_LIBDEFS_FILE

im machine.h definiere ich dann

#define LC_LIBDEFS_FILE "libdefs_68k_uae.h"

somit nimmt aros kernel libsource dieses file.

so sieht das für die layers lib 68k aus

#ifndef _LAYERS_LIBDEFS_H
#define _LAYERS_LIBDEFS_H

#define GM_UNIQUENAME(n) Layers_ ## n
#define LIBBASE LayersBase
#define LIBBASETYPE struct LayersBase
#define LIBBASETYPEPTR struct LayersBase *
#define MOD_NAME_STRING "layers.library"
#define VERSION_NUMBER 41
#define MAJOR_VERSION 41
#define REVISION_NUMBER 0
#define MINOR_VERSION 0
#define VERSION_STRING "$VER: layers.library 41.0 (10.10.2005) \r\n"
#define COPYRIGHT_STRING ""
#define LIBEND GM_UNIQUENAME(End)
#define LIBFUNCTABLE GM_UNIQUENAME(FuncTable)
#define RESIDENTPRI 60
#define RESIDENTFLAGS RTF_AUTOINIT|RTF_COLDSTART
#include "layers_intern.h"
#define GM_SYSBASE_FIELD(lh) (((LIBBASETYPEPTR)lh)->lb_SysBase)
#define GM_SEGLIST_FIELD(lh) (((LIBBASETYPEPTR)lh)->lb_SegList)

#endif * _LAYERS_LIBDEFS_H *

Das hat mich positiv überrascht,ich dachte auch es ist änderung im Source nötig,
so wie z.b ne lib von OS4 zu MOS portieren,dass dann dutzende
#ifdefs notwendig sind für jeden Befehl.amigaos hat ca 500 befehle,da hätte ich dann auch keine lust zu

Man kann die original aros sourcen nehmen und muss nix anpassen,von daher wenn
die AROS Kernelentwickler keine ambition haben uae aros zu unterstützen,ists nicht schlimm.

wie man im aros source sieht,ist aber die AROS layerslib noch nicht komplett,ausserdem kann es auch sein,dass
strukturen anders sind(einträge vertauscht).deshalb wollt ich kprintf um debugausgaben zu haben.
aber da die aros (oder besser amiga headerfiles wo platformunabhängig gemmacht wurden)
eh nicht änderungen ausgesetzt sind,kann ich auch eigene headerfiles machen und kann trotzdem wenn die kernelentwickler was an layerslib upddaten direkt das file nutzen

per setfunction ändert man dann die lib adresse auf den neuen code.Da weis ich auch noch nicht wie man die adresse einer funktion
in C erhält.denn die adresse muss ich setfunction übergeben

Falls in den nächsten Jahren OS4 oder MOS nicht mehr weiterentwicklet wird,und AROS sich weiterentwickelt
besteht dann die selbe möglichkeit wie bei OS3.1 ersetzen nur eben PPC

vieleicht kommt dadurch mal ne sourcecode Einheit zustande und weniger ifdefs

>Tja, kprintf dient der Ausgabe aus dem Kernel und ist deshalb bei der normalen Anwendungserstellung natürlich nicht vorhanden. Dazu muß man die Software an eine

woher hast du denn die Weisheit.du solltest dich mal wieder mit amigaos beschäftigen.es ist der Befehl
den jeder C entwickler unter amiga OS braucht wo etwas weiterentwickeln will wo keinen modernen sourcelevel debugger hat (also ziemlich alle)
der befehl gibt den text auf dem seriel device aus.Kann man mit sushi in ne shell umleiten.

>Aber genausogut könnte man für dieses eine Feature eine re-Implementierung von Picasso96 machen (darauf läufts ja sowieso hinaus) und sich die Mühe mit dem 68k-Port von Aros sparen.

nur der source für layer ist ja schonmal soweit da.Von 0 anfangen ist quatsch

damit man amigaOS erweitern kann,nimmt man dann eben den source.z.b graphics lib source um alpha blending
ins API zu integrieren oder intuition lib um schöneres fenster aussehen ohne patches zu erhalten.

feelin ist ja auch opensource,vieleicht hat jemand Lust den feelin GUI look reinzubauen und man kann es mit dem feelin
prefs prog einstellen

somit lässt sich jedes amiga OS auch PPC(wenn es ne AROS hostet on PPC lib gibt) per aroscode erweitern


[ - Antworten - Zitieren - Direktlink - ]

12.10.2005, 11:32 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von bernd_roesch:
Zitat:
>Nochmal: Aros beinhaltet keine Kompatiblität zu 68k-Anwendungen, benutzt deshalb das ABI der Zielplattform.
Hast dir aros noch nie angesehen und dann weist du das schon..

Bernd, dazu muß man sich AROS nicht "ansehen", das ist, was vom AROS-Team seit jeher propagiert wird. Das weiß sogar ich, und ich war insgesamt vielleicht 5 Minuten auf der AROS-Webseite...

Nachtrag - auf http://www.aros.org/introduction/ steht zu lesen:

"Should be binary compatible on Amiga and source compatible on any other hardware."

Sprich, die ABI ist die der Zielplattform. D'oh.

Zitat:
Zitat:
Tja, kprintf dient der Ausgabe aus dem Kernel und ist deshalb bei der normalen Anwendungserstellung natürlich nicht vorhanden. Dazu muß man die Software an eine
woher hast du denn die Weisheit.du solltest dich mal wieder mit amigaos beschäftigen.

Wofür, glaubst Du, steht das "k" in kprintf()? (Und bedenke, das AmigaOS 3.x nicht zwischen Kernel und Anwendung trennt...)


[ Dieser Beitrag wurde von Solar am 12.10.2005 um 11:36 Uhr editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

14.10.2005, 15:08 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Unter diesem Link:

http://amidevcpp.kilu.de/Examples/Bitoperation.zip


habe ich ein kleines Reaction Projekt abgelegt.

Wäre super, wenn sich das mal jemand anschauen könnte. Aus irgendeinem Grund wird nämlich die WHMI_GADGETUP Message nicht verarbeitet.
Ich komme da irgenwie nicht weiter...



--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

14.10.2005, 15:58 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Kaesebroetchen:
Wäre super, wenn sich das mal jemand anschauen könnte. Aus irgendeinem Grund wird nämlich die WHMI_GADGETUP Message nicht verarbeitet.
Ich komme da irgenwie nicht weiter...

Ich hab's mir noch nicht angesehen, will aber schonmal darauf hinweisen, daß GADGET_UP-Messages normalerweise nur gesendet werden, wenn RELVERIFY (oder so ähnlich) true ist. Sonst gibt's nur GADGET_DOWN.
Vielleicht liegt's ja daran.

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

[ - Antworten - Zitieren - Direktlink - ]

15.10.2005, 09:48 Uhr

Mazze
Posts: 263
Nutzer
Zitat:
Original von Kaesebroetchen:
Wäre super, wenn sich das mal jemand anschauen könnte.


Email ist raus.
--
Meine Homepage

[ - Antworten - Zitieren - Direktlink - ]

16.10.2005, 21:38 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@Mazze:
Danke für die mail !
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

17.10.2005, 17:07 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@whose

Wirf mal einen Blick auf deine emails (gmx Adresse)
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

20.10.2005, 22:03 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Hab dir wegen der OS4 Version ne mail geschrieben.
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

20.10.2005, 23:24 Uhr

whose
Posts: 2156
Nutzer
@Kaesebroetchen:

Ok, ich kümmer mich morgen nachmittag mal drum und teste ein wenig :)

Grüße


--
---

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

[ - Antworten - Zitieren - Direktlink - ]

24.11.2005, 19:59 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Hat jemand hier im Forum schon mal AmiDevCpp unter Windows9x (95,98,me) installiert und falls ja, gibt es damit irgendwelche Probleme ?
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

06.01.2006, 16:10 Uhr

Clydos
Posts: 68
Nutzer
Hi!

Ich habe AmiDevCpp 0.4 unter WinXP installiert - allerdings hatte ich vorher schon die aktuelle DevCpp darauf installiert! Selbstverständlich habe ich AmiDevCpp in ein anderes Verzeichnis installiert, aber trotzdem bekomme ich jetzt die Ami-Einstellungen, wenn ich den "normalen" DevCpp starte. :-((( Dies ist _sehr_ ungeünstig im Moment für mich. Woran liegt das und wie kann ich das beheben (am besten so, dass ich beide Installationen drauf habe)?

Heißen Dank!

Finde das Projekt und die Idee klasse! Werde mir aber vermutlich trotzdem Cubic holen. :-)

MdG
--
:commo: CD32 + SX-1

Heute schon geluxt?

[ - Antworten - Zitieren - Direktlink - ]

06.01.2006, 17:21 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@Clydos:
Hallo Clydos,

das Problem ist, das Dev-Cpp die Einstellungsdaten in der Datei Dev-Cpp.ini speichert welche sich im Ordner Dokumente und Einstellungen\Dev-Cpp befindet.
AmiDevCpp überschreibt diese Einstellungen. Du musst also diese Ini Datei so anpassen, das Sie so aussieht:

code:
[CompilerSets_0]
gcc.exe=gcc.exe
g++.exe=g++.exe
gdb.exe=gdb.exe
make.exe=make.exe
windres.exe=windres.exe
dllwrap.exe=dllwrap.exe
gprof.exe=gprof.exe
Options=
cmdline=
LinkLine=
CompAdd=0
LinkAdd=0
Bins=C:\CrossCompiler\AmiDevCpp\Bin
C=C:\CrossCompiler\AmiDevCpp\include
Cpp=C:\CrossCompiler\AmiDevCpp\lib\gcc\mingw32\3.4.2\include;C:\CrossCompiler\AmiDevCpp\include\c++\3.4.2\backward;C:\CrossCompiler\AmiDevCpp\include\c++\3.4.2\mingw32;C:\CrossCompiler\AmiDevCpp\include\c++\3.4.2;C:\CrossCompiler\AmiDevCpp\include
Lib=C:\CrossCompiler\AmiDevCpp\lib
[Options]
Version="4.9.9.2"
Language="English.lng"
Theme="New Look"
First=0
Splash=""
MRUMax=10
DblFiles=0
NoSplashScreen=0
MinOnRun=0
OpenStyle=0
BackUps=0
AutoOpen=2
MsgTabs=1
ShowBars=0
ShowMenu=1
DefCpp=0
ShowOutput=0
OutputOnNeed=1
OutputHeight=120
ProjectView=1
ClassView=0
ProjectWidth=161
Statusbar=1
FullScreen=0
FindCols="75, 75, 120, 150"
CompCols="75, 75, 120"
ToolbarMain=1
ToolbarMainX=11
ToolbarMainY=2
ToolbarEdit=1
ToolbarEditX=201
ToolbarEditY=2
ToolbarCompile=1
ToolbarCompileX=11
ToolbarCompileY=30
ToolbarProject=1
ToolbarProjectX=375
ToolbarProjectY=2
ToolbarOptions=1
ToolbarOptionsX=143
ToolbarOptionsY=30
ToolbarSpecials=1
ToolbarSpecialsX=202
ToolbarSpecialsY=30
ToolbarSearch=1
ToolbarSearchX=261
ToolbarSearchY=2
ToolbarClasses=1
ToolbarClassesX=11
ToolbarClassesY=58
AssociateCpp=1
AssociateC=1
AssociateHpp=1
AssociateH=1
AssociateDev=1
AssociateRc=1
AssociateTemplate=1
ShowTipsOnStart=1
LastTip=17
XPTheme=1
FileDate=844534490
ShowProgress=1
AutoCloseProgress=0
PrintColors=1
PrintHighlight=1
PrintWordWrap=0
PrintLineNumbers=0
PrintLineNumbersMargins=0
WatchHint=1
WatchError=1
[Position]
WinPlace=2, 3, -1, -1, -1, -1, 144, 131, 1008, 733
[Compiler]
UseParams=1
InterDir=
OutputDir=
RunParams=
Log=0
Delay=0
gcc.exe=i686-aros-gcc.exe
g++.exe=i686-aros-g++.exe
gdb.exe=gdb.exe
make.exe=make.exe
windres.exe=windres.exe
dllwrap.exe=dllwrap.exe
gprof.exe=gprof.exe
CompilerSet=2
Options=0000000000000000000000
[Makefile]
FastDep=1
[Editor.Font]
Charset=1
Color=-2147483640
Name="Courier New"
Pitch=0
Size=10
[Editor.Gutterfont]
Charset=1
Color=-2147483640
Name="Terminal"
Pitch=0
Size=9
[CompilerSets_1]
gcc.exe=m68k-amigaos-gcc.exe
g++.exe=m68k-amigaos-g++.exe
gdb.exe=gdb.exe
make.exe=make.exe
windres.exe=
dllwrap.exe=dllwrap.exe
gprof.exe=gprof.exe
Options=0000000000000000000000
cmdline=-noixemul
LinkLine=
CompAdd=1
LinkAdd=0
Bins=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\bin;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\bin;C:\CrossCompiler\AmiDevCpp\utils\bin;C:\CrossCompiler\AmiDevCpp\bin;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\lib\gcc-lib\m68k-amigaos\2.95.3
C=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\sys-include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\include\g++-3
Cpp=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\sys-include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\include\g++-3
Lib=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\lib;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\m68k-amigaos\lib\libnix

[CompilerSets_2]
gcc.exe=i686-aros-gcc.exe
g++.exe=i686-aros-g++.exe
gdb.exe=gdb.exe
make.exe=make.exe
windres.exe=windres.exe
dllwrap.exe=dllwrap.exe
gprof.exe=gprof.exe
Options=0000000000000000000000
cmdline=
LinkLine=
CompAdd=0
LinkAdd=0
Bins=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\bin;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\bin;C:\CrossCompiler\AmiDevCpp\utils\bin;C:\CrossCompiler\AmiDevCpp\bin
C=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\sys-include
Cpp=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\sys-include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\include\g++-3
Lib=C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\lib
[CompilerSets]
0=Default compiler
1=m68k-AmigaOS
2=i686-aros

[Directories]
Exec="C:\CrossCompiler\AmiDevCpp\"
Config="C:\Dokumente und Einstellungen\Administrator\Anwendungsdaten\Dev-Cpp\"
Bins="C:\CrossCompiler\AmiDevCpp\usr\local\amiga\bin;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\bin;C:\CrossCompiler\AmiDevCpp\utils\bin;C:\CrossCompiler\AmiDevCpp\bin"
Default="C:\CrossCompiler\AmiDevCpp"
C="C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\sys-include"
Cpp="C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\sys-include;C:\CrossCompiler\AmiDevCpp\usr\local\amiga\include\g++-3"
Help="Help\"
Icons="Icons\"
Lang="Lang\"
Lib="C:\CrossCompiler\AmiDevCpp\usr\local\amiga\i686-aros\lib"
Templates="Templates\"
Themes="Themes\"
[Editor]
AutoIndent=1
InsertMode=1
TabToSpaces=1
SmartTabs=1
SmartUnindent=1
TrailBlank=0
GroupUndo=1
EHomeKey=0
PastEOF=0
PastEOL=0
DblClkLine=0
FindText=1
Scrollbars=1
HalfPageScroll=0
ScrollHint=1
SpecialChars=0
AppendNewline=1
AutoCloseBrace=0
TabSize=4
MarginVis=1
MarginSize=80
MarginColor=-2147483626
InsertCaret=0
OverwriteCaret=0
InsDropFiles=0
GutterVis=1
GutterAuto=0
LineNumbers=0
LeadZero=0
FirstLineZero=0
Gutterfnt=1
GutterSize=32
UseSyntax=1
SyntaxExt="c;cpp;h;hpp;cc;cxx;cp;hp;rh;"
DefaulttoPrj=0
ParserHints=1
Match=0
HighCurrLine=1
HighColor=16777164
[Editor.Syntax]
Assembler=clBlue, clNone, 0, 0, 0
Character=clBlack, clNone, 0, 0, 0
Comment=clHighlight, clNone, 0, 1, 0
Float=clPurple, clNone, 0, 0, 0
Hexadecimal=clPurple, clNone, 0, 0, 0
Identifier=clBlack, clNone, 0, 0, 0
Illegal Char=clBlack, clNone, 0, 0, 0
Number=clPurple, clNone, 0, 0, 0
Octal=clPurple, clNone, 0, 0, 0
Preprocessor=clGreen, clNone, 0, 0, 0
Reserved Word=clBlack, clNone, 1, 0, 0
Space=clBlack, clWhite, 0, 0, 0
String=clRed, clNone, 0, 0, 0
Symbol=clBlack, clNone, 0, 0, 0
Break points=16777215, 255
Error Line=16777215, 128
Active Breakpoints=16777215, 16711680
Gutter=0, -2147483633
Selected text=16777215, 8388608
[CodeCompletion]
Width=320
Height=240
Delay=500
BackColor=-2147483643
Enabled=1
UseCacheFiles=1
[ClassBrowsing]
Enabled=1
ViewStyle=0
ParseLocalHeaders=1
ParseGlobalHeaders=0
ShowFilter=0
UseColors=1
ShowInheritedMembers=0
[CVSHandler]
Executable="cvs.exe"
Compression=4
UseSSH=1
[ExternalPrograms]
Dummy=0
[History]
0=C:\Amiga_Platten\AmigaDev2\cpp\Bitoperation\Bitoperation.dev
1=C:\CrossCompiler\AmiDevCpp\Projekt1.dev


Das Compilerset_0 (das oberste) ist der MinGW32 für die Windows Programmierung. Du musst natürlich die Pfade anpassen.
In meiner Installation habe ich alle Compiler im Pfad C:\CrossCompiler\AmiDevCpp. Bei dir dürfte der MinGW32 wohl in C:\Dev-Cpp zu finden sein.
Um Amigaprogramme zu kompilieren, musst du dann natürlich m68k_amigaOS als Compilerset auswählen.

Wenn ich Zeit habe (und Hyperion mir endlich auf meine Mail antwortet) werde ich ein wunschlos glücklich Paket schnüren. Dann wird man mit einer AmiDevCpp Installation Programme für Windows, Classic Amiga, OS4, Morphos und AROS erzeugen können.


--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

06.01.2006, 17:31 Uhr

Clydos
Posts: 68
Nutzer
@Kaesebroetchen: Wow, danke für diesen Hammer. :-) Hat hier ganz schön das Layout zerhauen. :-) Vielleicht kann man das noch anders gestalten?

Aber zum Thema: Das hilft mir natürlich sehr, danke! Demzufolge erstelle ich mir einfach 2 ini-Dateien, eine für PC und eine für Ami. Klasse, danke, muss ich am WE mal ausprobieren.

Wegen Mail an Hyperion: Das "Prob" kenne ich auch. :-/ Aber ich habe hier ja super Hilfe gefunden (@whose)! :bounce: :itchy:
--
:commo: CD32 + SX-1

Heute schon geluxt?

[ - Antworten - Zitieren - Direktlink - ]

06.01.2006, 17:44 Uhr

Kaesebroetchen
Posts: 643
Nutzer
@Clydos:
Eine ini reicht völlig.
Bisher ist sowohl das Default Compiler Set als auch Amiga m68k für Amigaprogramme. Wenn du es so änderst wie oben beschrieben, dann ist das Default Compiler Set für windows und das m68k_amigaos für Amigaprogramme.
--
http://amidevcpp.kilu.de/

[ - Antworten - Zitieren - Direktlink - ]

06.01.2006, 17:47 Uhr

Clydos
Posts: 68
Nutzer
@Kaesebroetchen: Ah, I see! Danke! _So_ detailiert hatte ich mir die ini nicht angeschaut. :-) Super!
Steht das in irgendeiner Dokumentation zum Paket/auf der Seite? Wäre sinnvoll und hilfreich!

--
:commo: CD32 + SX-1

Heute schon geluxt?

[ - Antworten - Zitieren - Direktlink - ]

07.01.2006, 00:44 Uhr

Clydos
Posts: 68
Nutzer
@Kaesebroetchen: Vergiß mein letztes Posting ... :-) Hab die ini gefunden, zumal der Pfad ja auch in Deiner ini da stand. Sorry für die Hektik ... :-(

Du hast also DevCpp nur einmal installiert, aber eben die alle Crosscompiler und wechselst das Set nur über die ini - cool, ich hoffe, ich kann das so ohne weiteres auch anpassen/kopieren. Welche Dateien/Verzeichnisse müsste ich denn in meine Bestehende DevCpp-Installation kopieren? Oder geht das doch nicht so ohne weiteres?

Gruß und gute Nacht

--
:commo: CD32 + SX-1

Heute schon geluxt?

[ - Antworten - Zitieren - Direktlink - ]

07.01.2006, 01:58 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von Clydos:

Du hast also DevCpp nur einmal installiert, aber eben die alle Crosscompiler und wechselst das Set nur über die ini


Ich wechsle den Compiler über das Menü Projekt->Projekt Optionen

Zitat:
- cool, ich hoffe, ich kann das so ohne weiteres auch anpassen/kopieren. Welche Dateien/Verzeichnisse müsste ich denn in meine Bestehende DevCpp-Installation kopieren? Oder geht das doch nicht so ohne weiteres?

Im Prinzip kannst du den Inhalt des Dev-Cpp Verzeichnisses einfach in das AmiDevCpp Verzeichnis kopieren.
Wenn du AmiDevCpp in C:\CrossCompiler\AmiDevCpp installiert hast, dann kannst du einfach meine Ini Datei übernehmen:


http://amidev.kilu.net/AmiDevCpp_v05/devcpp.ini

Die ist allerdings für Version 0.5

http://amidev.kilu.net/AmiDevCpp_v05/InetInstallerAmiDevCpp.exe

müsste allerdings auch mit ein paar Fehlermeldungen mit Version 0.4 tun.
--
http://amidev.kilu.net/

[ - Antworten - Zitieren - Direktlink - ]

07.01.2006, 02:25 Uhr

_PAB_
Posts: 3016
Nutzer
@Clydos:
Dein Beitrag wurde wegen eines Problems im Forum nicht eingefügt.
Da Kaesebroetchen den aber sowieso wieder vergessen soll, habe ich ihn jetzt nicht wiederhergestellt...

[ - Antworten - Zitieren - Direktlink - ]

09.01.2006, 10:49 Uhr

Clydos
Posts: 68
Nutzer
@Kaesebroetchen:
Ich habe schon diesen Eintrag in den Kommantar vom MonsterPack geschrieben. Schreibe ihn aber sicherheitshalber auch nochmal hier rein. :-)
--
Hey, klasse! Würde mir das gern ziehen, aber ich habe nur Highspeed-Netz in der Uni. Da nützt mir leider die Internet-Install-Datei nix. :-(( Und alle Pakete einzeln runterzuladen ist auch nicht gerade ideal. :-( Wäre es auch möglich, dass Du das Monsterpack direkt zum Download zur Verfügung stellst? Da könnte ich das hier runterladen und auf den Stick kopieren. Wäre klasse, wenn das ginge. Danke im Voraus!

MdG
--
:commo: CD32 + SX-1

Heute schon geluxt?

[ - Antworten - Zitieren - Direktlink - ]

09.01.2006, 11:05 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Dann antworte ich sicherheitshalber auch noch hier.

Heinz-Raphael Reinke (09-Jan-2006, 11:02)

@clydos

Das geht nicht sorry.
Ich benutze einen kostenlosen Webspace und der lässt nunmal keine Dateien
> 1MB zu.

Aber vielleicht stellt ja jemand etwas Webspace zur Verfügung,läd das Komplettpaket hoch und postet hier einen Link ?

Notfalls kann ich dir das ganze auch auf CD brennen und gegen einen kleinen Unkostenbeitrag mit der Post schicken.
--
http://amidev.kilu.net/

[ - Antworten - Zitieren - Direktlink - ]

09.01.2006, 11:59 Uhr

Holger
Posts: 8116
Nutzer
@Kaesebroetchen:
Was genau muß man denn machen, um eine große Datei zu erhalten, die man wieder online stellen könnte?
Ich mein insb. wegen Installation .exe oder so...

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

[ - Antworten - Zitieren - Direktlink - ]

09.01.2006, 12:22 Uhr

Kaesebroetchen
Posts: 643
Nutzer
Zitat:
Original von Holger:
@Kaesebroetchen:
Was genau muß man denn machen, um eine große Datei zu erhalten, die man wieder online stellen könnte?
Ich mein insb. wegen Installation .exe oder so...

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


Im Grunde einfach alles herunterladen und das selbstentpackende Archiv ausführen (AmiDevCpp.exe).

Wenn du das Internet Setup ausführst, wird das automatisch gemacht.

Das Installationspaket heisst dann AmiDevCpp_Setup_V09_Monster_Pack.exe
und ist ca 90MB groß.

P.S. Ich dachte immer du wärst Modem Nutzer ?
--
http://amidev.kilu.net/

[ - Antworten - Zitieren - Direktlink - ]


1 -2- 3 4 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > AmiDevCpp [ - Suche - Neue Beiträge - Registrieren - Login - ]


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