ENGLISH VERSION |
|
Links | | | Forum | | | Kommentare | | | News melden |
Chat | | | Umfragen | | | Newsticker | | | Archiv |
amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
woop
Nutzer
07.02.2018, 23:16 Uhr [ - Direktlink - ] |
Thema: Neuerdings kein Windows Update mehr möglich auf meinem Win10 Rechner
Brett: Andere Systeme Probier mal den Teufel mit Belzebub auszutreiben: http://www.nero.com/eng/support/service/nero-clean-tool.php |
|||||
woop
Nutzer
23.03.2015, 16:16 Uhr [ - Direktlink - ] |
Thema: Assembler/Includes: "unknown mnemonic <funcdef>"
Brett: Programmierung Ich bevorzuge die Methode die LVOs aus der amiga.lib oder der small.lib zu linken: code:XREF _LVOGetMsg doSomething: [...] ; use exec.library movea.l _SysBase,a6 jsr _LVOGetMsg(a6) [...] end Nachteile: * Man muss immer linken * zusätzliche XREF-Zeile für jede verwendete Funktion Vorteile: * Im Sinne der Erfinder * Zusätzliche Linkzeiten fallen schon auf kleineren Systemen kaum ins Gewicht * sehr kompatibel unter den verschiedenen Assemblern * keine Fehler durch verwechselte oder falsche Offsets |
|||||
woop
Nutzer
03.05.2014, 21:09 Uhr [ - Direktlink - ] |
Thema: ADFs von den alten AD&D-Rollenspielen (Pool of Radiance...)
Brett: AROS und Amiga-Emulatoren Vielleicht erhöht es deine Chancen, wenn du noch eine Möglichkeit nennst, wie man dir die ADFs denn zukommen lassen könnte ;-) |
|||||
woop
Nutzer
12.08.2010, 17:24 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 Zitat: Enforcer starten und im Aminet bei A anfangen. Vermutlich hast du die 100 zusammen bevor du zu B kommst :-) |
|||||
woop
Nutzer
10.08.2010, 01:29 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 Zitat: Meinst du das jetzt im Ernst oder soll das ein Troll-Versuch sein? |
|||||
woop
Nutzer
09.08.2010, 23:47 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 Zitat: Ich habs nochmal genau gelesen und komme nicht drauf. Also mal aus der Sicht des Programmierers, dem ich mal unterstelle illegale Speicherzugriffe nicht absichtlich einzubauen: Programm läuft auf einem System mit Speicherschutz und es erfolgt ein illegaler Speicherzugriff -> Programm wird sofort hart beendet und das OS gibt wohlmöglich noch eine Fehlermeldung aus -> Programmierer weiß sofort, oh, da ist wohl noch was faul... Programm läuft auf einem System ohne Speicherschutz und es erfolgt ein illegaler Speicherzugriff -> Programm läuft einfach weiter, wohlmöglich hat es sogar zufällig vorhandenen aber gerade freien Speicher benutzt, dann sind sogar noch nicht einmal Datenfehler feststellbar -> Programmierer denkt, supi, alles läuft prima und die Welt wundert sich, wieso sein Programm Donnerstags immer abstürzt... Wieso soll der Programmierer jetzt auf einem System ohne Speicherschutz gezwungen sein sauberer zu arbeiten, wenn Speicherzugriffsfehler in seinem Programm nicht zwingend zu Laufzeitfehlern führen? |
|||||
woop
Nutzer
09.08.2010, 21:42 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 Zitat: Ist dieser Mythos denn nie kleinzukriegen? illegaler Speicherzugriff eines Programms auf einem System mit Speicherschutz -> Programm wird sofort hart beendet illegaler Speicherzugriff eines Programms auf einem System ohne Speicherschutz -> Programm wird nicht beendet, wenn nur gelesen wird gibts "nur" falsche Daten, Schreibzugriffe auf unbenutzten Speicher bleiben folgenlos Wieso sollten jetzt Programme auf Systemen ohne Speicherschutz "von sich aus sauberer arbeiten" müssen? Tatsächlich ist genau das Gegenteil der Fall! [ Dieser Beitrag wurde von woop am 09.08.2010 um 21:43 Uhr geändert. ] |
|||||
woop
Nutzer
30.06.2010, 01:06 Uhr [ - Direktlink - ] |
Thema: Vortex System 2000
Brett: Amiga, AmigaOS 4 @Amiuso: Guck mal auf diesen Thread: http://www.a1k.org/forum/showthread.php?t=11333 besonders auf diesen Beitrag: http://www.a1k.org/forum/showpost.php?p=178515&postcount=13 Gruß, woop |
|||||
woop
Nutzer
18.09.2008, 01:05 Uhr [ - Direktlink - ] |
Thema: 132 Euro AGL2
Brett: Get a Life Zitat: Oha, bist du in Deutschland? Wenn ja unterliegst du möglicherweise einem Irrtum: Du bist auch nach 10 Jahren bei deiner letzten Krankenkasse versichert, du bist nur 10 Jahre mit deinen Zahlungen im Rückstand und wenn du dich irgendwann mal wieder versichern willst dann solltest du dieses Problem angehen. Die KK holt sich das Geld dann schon noch. Ich dachte auch mal, dass ich während einer Selbstständigkeit nicht versichert sei... [ Dieser Beitrag wurde von woop am 18.09.2008 um 01:13 Uhr geändert. ] |
|||||
woop
Nutzer
29.08.2008, 20:20 Uhr [ - Direktlink - ] |
Thema: 4-Byte char => int?
Brett: Programmierung @thomas: Das ist mir schon klar, dass IFF dahingehend designed wurde, dass sowas nicht vorkommt, aber OT meint ja, es würde eben nicht um IFF sondern um was eigenes gehen, daher mein Hinweis. |
|||||
woop
Nutzer
29.08.2008, 19:49 Uhr [ - Direktlink - ] |
Thema: 4-Byte char => int?
Brett: Programmierung Bitte auch daran denken, dass in einem Datenstrom oder in einem String die Zeichen 'FORM' auch an nicht durch vier teilbaren oder an ungeraden Adressen stehen könnten. Da kann dann ein einfacher 68000er nicht mehr als long darauf zugreifen. |
|||||
woop
Nutzer
11.08.2008, 21:05 Uhr [ - Direktlink - ] |
Thema: V: wer kopiert meine Disketten?
Brett: Kleinanzeigen (keine Auktionen!) *antwort* |
|||||
woop
Nutzer
08.08.2008, 14:25 Uhr [ - Direktlink - ] |
Thema: V: wer kopiert meine Disketten?
Brett: Kleinanzeigen (keine Auktionen!) @juergen: Das lässt sich machen. Wo befinden sich die Disketten? Um wieviele handelt es sich? Bist du bereit, die Disks der Post anzuvertrauen? Sind die Disketten per trackdisk.device lesbar*? (*) Normale AmigaDOS-formatierte Disketten sind das, aber auch einige andere, wie Kickstart-Disketten oder gecrackte Spiele. Wenn sich die Disketten mit einem einfachen Kopierprogramm kopieren lassen ist die Wahrscheinlichkeit hoch, dass man daraus auch ein ADF für den Emulator erstellen kann. [ Dieser Beitrag wurde von woop am 08.08.2008 um 14:43 Uhr geändert. ] |
|||||
woop
Nutzer
06.05.2008, 00:02 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Zu deinem Semaphorenbeispiel solltest du noch einige Dinge beachten, bevor du es als Lehrbeispiel auf angehende Amigaprogrammierer loslässt. 1. Zu jedem GetMsg() gehört auch ein ReplyMsg(). In deinem Beispiel bewirkt das zwar nichts, weil kein Antwortport in die Messages eingetragen ist, aber ReplyMsg ist schlau genau um damit umgehen zu können, also in jedem Fall aufrufen. 2. Genau dein Beispiel benötigt allerdings einen Antwortport, weil der Senderprozess ja wissen will, wann er die mit AllocMem allozierte Message wieder freigeben (oder anderweitig benutzen) kann. Du umgehst das Problem hier einfach, indem der Speicher nie freigegeben wird. Bitte nicht auf die tolle Idee kommen und diesen im Empfängerprozess freigeben 3. Zu CreateMsgPort gehört auch ein DeleteMsgPort 4. Statt der Warte-for-Schleife ist ein Delay(25); hier viel schöner und aussagekräftiger: "Obwohl der Kindprozess schläft kann der Elternprozess wegen der gelockten Semaphore nicht weitermachen." 5. Statt mit WaitPort solltest du deine Schützlinge imho gleich mit Wait konfrontieren, damit kannst du auch prima zeigen, wie ein Task auf mehrere Dinge gleichzeitig warten kann 6. Nach GetMsg machen wir uns erstmal eine Kopie der interessanten Daten und schicken dann sofort das ReplyMsg, bevor wir die Daten verarbeiten (hier: ausgeben) 7. Die Semaphore sollte in MEMF_PUPLIC liegen, auch wenn das auf klassischen Amigas keinen Unterschied macht. 8. Portnamen sollten als Prefix den Programmnamen haben. |
|||||
woop
Nutzer
05.05.2008, 23:18 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung Zitat: Uhm, ohne dir zu nahe treten zu wollen, aber _dazu_ solltest du deine Beispiele noch ein wenig überarbeiten so dass z.B. Fehler sauber abgefangen werden und alle Ressourcen wieder freigegeben werden. Außerdem solltest du dich bei Variblen/Funktionsnamen und Kommentaren auf eine Landessprache einigen |
|||||
woop
Nutzer
05.05.2008, 22:19 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Auch dein Semaphorenbeispiel sieht funktionstüchtig aus, allerdings beachte, dass I/O-Funktionen ein Forbid() vorübergehend aufheben: code:Forbid(); port=FindPort("MainPort"); if (port) { PutStr("Kindprozeß setzt Nachricht abn"); Flush(Output()); PutMsg(port,(struct Message *)rdy); } Hier kann es durchaus passieren, dass dir zwischen FindPort und PutMsg noch ein anderer Task dazwischenfunkt. |
|||||
woop
Nutzer
05.05.2008, 22:02 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Ohne es getestet zu haben sollte das so funktionieren. Ich nehme an, dass du das Polling mit einem simplen code:wegkriegst weißt du.Wait(1 << port->mp_SigBit); Mit AddPort() machst du den Port systemweit bekannt; damit es nicht so leicht Namenskollisionen gibt ist es sinnvoll dem Portnamen ein programmspezifisches Präfix anzuhängen "MeinProgramm_ChildPort", z.B. In diesem Fall brauchst du das allerdings gar nicht und könntest auch einfach den Portzeiger in deinem Programm zugänglich machen. Da du deine eigenen Messagetyp erzeugst den du "ReadyMessage" nennst, gehe ich davon aus, dass du vorhast noch weitere Messagetypen für andere Zwecke zu erzeugen. Beachte hier, dass beim Child erstmal nur ein Pointer ankommt, dem du nicht ansiehst, welcher Typ sich dahinter verbirgt. Falls du das so vorhaben solltest könntest du einen Basistyp definieren, der als einziges Member eine enum hat, von dem auf dem Messagetyp geschlossen werden kann, z.B. so: code:enum eMessageType { Readymessage, DoSomethingMessage }; struct CommonMessage { struct Message msg; eMessageType type; }; struct ReadyMessage { struct CommonMessage base; BOOL Ready; }; struct DoSomethingMessage { struct CommonMessage base; char woop[42]; }; Beim Message-zusammenbauen im Sendertask dann CommonMessage::type entsprechend befüllen und das im Empfängertask entsprechend auswerten bevor du auf den tatsächlichen Typ castest. Wenn es allerdings nur um das Beenden geht, dann könntest du durchaus auch mit einem AllocSignal/Signal/Wait zurecht kommen. |
|||||
woop
Nutzer
04.05.2008, 20:46 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Fein dass das jetzt geht, die Endlosschleife finde ich so schon okay, da du ja zwischendurch den Task sauber per timer.device schlafen legst. Ich würde der Ordung halber aber noch ein beenden-Event einführen, welches vom Hauptprozess getriggert werden kann, so dass sich der Task sauber beendet oder in Wait(0); geht, so dass er ohne das Forbid/Disable entfernt werden kann. Edit: Mir ist gerade eingefallen, dass du das timer.device nur dazu benutzt um die Daten vom Parallelport in bestimmten -- sehr kurzen Zeitabständen -- auszulesen. Das ist für einen sich sparsam benehmenden Task natürlich zuwenig. Ein zweiter Timer, welcher einen kompletten Durchlauf von ReadFrame() und DrawScope() maximal alle 1/25 Sekunden zulässt wäre wohl noch sinnvoll Edit2: Nicht nur der Ordnung halber solltest du das beenden-Event einführen sondern auch um das timer.device in deinem Task wieder korrekt schließen zu können. So hast du ein Speicherleck. Außerdem verwendest du jetzt Fließkommazahlen in deinem Task, was wegen der oben genannten Gründe für Probleme sorgen kann. Da ich in deiner bisherigen Implementierung keine Benutzung von sc->time sehen konnte sondern du ihn nur zur Berechnung eines Integers in CreateScope heranziehst solltest du darüber nachdenken ihn zu entfernen. [ Dieser Beitrag wurde von woop am 04.05.2008 um 22:06 Uhr geändert. ] |
|||||
woop
Nutzer
04.05.2008, 10:08 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung Zitat: Da hast du absolut recht, außerdem glaube ich zu wissen, was Mad_Dogs Problem hier ist. Der Message-Port fürs timer.device wird im Hauptprozess angelegt, aber im Kindtask per SendIO/WaitIO bedient. Das sig-bit des Kindtasks wird wohl noch entsprechend gesetzt obwohl es hier nicht sauber alloziert werden dürfte, aber das GetMsg() des Hauptprozesses kann die Message entfernen bevor WaitIO() das im Task für dich erledigt. Damit würde dann dein WaitIO deadlocken. |
|||||
woop
Nutzer
04.05.2008, 01:27 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Ich weiß nicht genau was READ_PAR() macht, aber ich hätte es eigentlich nach SendIO/WaitIO erwartet (welches du durch ein DoIO() ersetzen kannst) Ansonsten kann ich morgen nochmal drüber schauen, gute Nacht Edit: *gna* Denkfehler von mir, so passt das natürlich mit dem READ_PAR, ich hatte das gestern nacht wohl irgendwie mit Daten-vom-parallel.device-anfordern und der Benutzung des timer.device durcheinander geworfen %-) [ Dieser Beitrag wurde von woop am 04.05.2008 um 09:44 Uhr geändert. ] |
|||||
woop
Nutzer
04.05.2008, 00:48 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Hat zwar nichts mit deinem schlafenden Task zu tun, aber du solltest in deiner inneren Schleife nicht auf !Ende testen, damit beim Beenden auch sicher alle Nachrichten aus dem MSGPort gelesen werden. |
|||||
woop
Nutzer
04.05.2008, 00:31 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Speziell diese float-Problematik lässt sich mit einem C-Compiler wohl nur sehr umständlich und mit ein paar eigenen Assembler-Routinen umgehen. Von daher wäre es vielleicht besser, wenn du ReadFrame/DrawScope in deiner äußeren Schleife des Hauptprogramm aufrufen würdest und stattdessen auf das WaitPort verzichtest. Damit verbrätst du natürlich 100% CPU aber das macht dein Kind-Task so ja auch schon Ansonsten ließe der sich vielleicht noch systemkonform bremen wenn du auf Windows-Messages _und_ Timer-Events warten könntest. |
|||||
woop
Nutzer
04.05.2008, 00:21 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: noch ein paar Fallstricke, die mir da einfallen: 1. Du verwendest floats und damit vermutlich auch die math-libraries. Diese verlangen es allerdings, dass sie für jeden Task geöffnet werden und dort auch jeweils die Task-eigenen Library-Pointer bei Funktionsaufrufen benutzt werden. Keine Ahnung wie übel die das nehmen, wenn man sich nicht daran hält 2. Leider ist es eine Designschwäche des AmigaDOS, dass ein Task quasi die Übermenge eines Prozesses ist und nicht ein Prozess aus einer Menge von Tasks besteht. Das bedeutet u.a. in der Praxis, dass du keine AmigaDOS-Funktionen in einem reinen Task verwenden darfst, auch nicht indirekt, z.B. indem du Fonts benutzt. Leider habe ich auch hier keine Ahnung, wie sich das Nichtbeachten hier äußern kann... |
|||||
woop
Nutzer
03.05.2008, 23:51 Uhr [ - Direktlink - ] |
Thema: V: AMIGA ROM Kernel Reference Manuals (RKMs)
Brett: Kleinanzeigen (keine Auktionen!) Zitat: Betrachte es mal andersrum, alleine auf ebay.de laufen zu jeder Zeit über 1000 Amiga-relevante Auktionen. Wenn jeder hier auf seine ebay-Auktionen aufmerksam machen würde, nunja, lesbar wäre das Forum hier sicherlich nicht mehr. Und wer Amiga-Sachen sucht verfolgt auch ebay-Auktionen, ganz sicher |
|||||
woop
Nutzer
03.05.2008, 23:46 Uhr [ - Direktlink - ] |
Thema: Task schläft ein
Brett: Programmierung @Mad_Dog: Was genau meinst du mit "Task einschlafen"? Er hängt irgendwo in ReadFrame() oder DrawScope() oder beendet er sich einfach? Ich sehe auch keine direkte Syncronisation, da du aber ein Member in struct Scope *sc; mit dem IO-Port des timer.device befüllst gehe ich davon aus, dass der Task das als interne Uhr verwendet und keine sich im Leerlauf befindende Endlosschleife ist, richtig? code:extern void Update(void) { while (1) { ReadFrame(sc); DrawScope(sc); } } Hier wundert mich allerdings das extern. Was bezweckt das hier? Die Funktion ist ja nicht extern und wenn sie es wäre kann man extern bei Funktionen sowieso weglassen. Jedenfalls meine ich, dass dein Problem in ReadFrame/DrawScope zu suchen ist. Da du sc mit einer Funktion erzeugst die als Parameter einen Pointer deiner windows-struktur bekommt liegt die Vermutung nahe, dass du über sc in ReadFrame/DrawScope auf deren Daten zugreifst. Da ich keine Synchronisation in deiner Hauptschleife sehe hättest du dann eine Nebenläufigkeit, die eventuell deine Funktionen einfrieren lassen. |
|||||
woop
Nutzer
01.05.2008, 00:37 Uhr [ - Direktlink - ] |
Thema: Http Post Request
Brett: Programmierung Zitat: Psst, nicht so laut! Immer daran denken, von diesem Codeschnipsel hängt unser aller Leben ab, weil er sehr gefährliche Sachen in Zaun hält. Und schlafende Schäferhunde soll man ja nicht wecken! |
|||||
woop
Nutzer
01.05.2008, 00:00 Uhr [ - Direktlink - ] |
Thema: Http Post Request
Brett: Programmierung Zitat: Schafherden? |
|||||
woop
Nutzer
22.04.2008, 12:03 Uhr [ - Direktlink - ] |
Thema: Nostalgie bei Computerbild
Brett: Amiga, AmigaOS 4 Zitat: @mir_egal: Du liest Computer Bild? 1. geplenktes Ausrufezeichen 2. kleingeschriebener Satzanfang 3. falsches Komma vor und 4. Standart... Glashaus und so |
|||||
woop
Nutzer
12.03.2008, 00:40 Uhr [ - Direktlink - ] |
Thema: Eigene IP ermitteln?
Brett: Programmierung Zitat: Sorry, aber sonderlich erleuchtend war das nicht. Deine Begeisterung für Webservices in Ehren, aber diese Aufgabe kriegt man auch mit per cgi-Einzeiler hin, zur Not kann man sich da sogar die IP dann direkt als 64Bit-BigEndian-Binärwert dumpen lassen, dann spart man sich sogar das parsen Aber das war nicht worauf ich hinaus wollte, am besten mal ein praktisches Beispiel: Wir haben den Rechner "amiga" der hängt in einem LAN und hat die IP 192.168.0.42, sein Standardgateway ist 192.168.0.1. Dieser Rechner -- nennen wir ihn "router" -- hat neben seiner LAN-IP noch drei Internet-IPs: 80.237.146.23, 80.237.146.33 und 80.237.146.43. An 192.168.0.1 ankommende Verbindungen behandelt er so: http/https Anfragen leitet er an ein Zwangsproxy, welches auf das Internet über 80.237.146.23 zugreift. Alle nicht internen IPs nattet er und schickt sie über 80.237.146.33 raus. Eingehende Verbindungen an 80.237.146.43 für Port 22, 23 und 80 leitet er per portforwarding an den Rechner "amiga" weiter. Frage 1: Welche Internet-IP hat hier der Rechner "amiga"? Frage 2: Wie schreibe ich einen Webservice-3-Zeiler, der dieses und andere Setups sicher erkennt, analysiert und die Internet-IP ausspuckt? Wenn du das beantworten kannst, das wäre mal eine Erleuchtung [ Dieser Beitrag wurde von woop am 12.03.2008 um 00:47 Uhr geändert. ] |
|||||
woop
Nutzer
11.03.2008, 02:13 Uhr [ - Direktlink - ] |
Thema: Eigene IP ermitteln?
Brett: Programmierung Zitat: Die Anforderung lautete aber afaik "Ich will die Internet-IP ermitteln und es soll eine universelle Lösung sein"... und das läuft so nicht. Wenn doch, bitte ich um Erleuchtung Für ein spezielles Setup kriegt man natürlich eine Lösung gebastelt, aber eben nichts universelles. Auch diese ganzen Vorschläge nach dem Konzept "Webservice fragen" sind nicht universell und werden so auf einer Menge Rechner aus 64567458658 Gründen nicht funktionieren. Und sobald das jemandem klar ist, wird er hoffentlich ganz von alleine zu den Fragen "wofür genau brauche ich die IP" und "warum genau brauche ich für diesen Zweck unbedingt diese IP" kommen Gruß [ Dieser Beitrag wurde von woop am 11.03.2008 um 02:17 Uhr geändert. ] |
|||||
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |