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

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

-1- 2 [ - Beitrag schreiben - ]

09.12.2007, 16:18 Uhr

MaikG
Posts: 5172
Nutzer
Ich hab einen befehl wie

STR$(a&/1000)

STR$ macht nichts anderes als eine Variable zum String zu
wandeln. a&/1000 Teilt die LONG a druch 1000.

Ja, das ist nun eigentlich nicht was irgenwie mit Librarys
oder so zu tun hat, aber es geht nicht.

Hingegen:


b&=a&/1000
STR$(b&)


geht.

Ist das der Emulation zuviel oder wie?

Dagegen gehen unsaubere Sachen, wie zugriff auf bereits
freigegebenen Speicher eigenartigerweise schon.

[ - Antworten - Zitieren - Direktlink - ]

09.12.2007, 17:34 Uhr

Der_Wanderer
Posts: 1229
Nutzer
Welche Sprache, welches System ?

Sieht so aus, als ob der Compiler eben anderen Code erzeugt, der in einem Falle geht und im anderen nicht.
> Ist das der Emulation zuviel oder wie?
Die Emualtion führt ja keinen Basic code aus, sondern das resultierende Compilat. Müsste man mal disassemblieren was das passiert. Wäre es eine Sprache wie Amiblitz, die noch entwicklet wird, könnte man den Compiler fixen.
--
Thilo Köhler, Author von:
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]

09.12.2007, 17:54 Uhr

MaikG
Posts: 5172
Nutzer
>Welche Sprache, welches System ?

MaxonBasic und Classic (A4000) natürlich.

>Sieht so aus, als ob der Compiler eben anderen Code erzeugt,
>der in einem Falle geht und im anderen nicht.

Möglich, aber solche befehle greifen nicht auf Customchips zu,
nicht auf Librarys etc.

Also kann ich mir nicht vorstellen was da nicht Systemkonform sein
soll.


>Die Emualtion führt ja keinen Basic code aus, sondern das
>resultierende Compilat. Müsste man mal disassemblieren was das
>passiert.

Ja, das ist schon klar. Da auch die Library gelinkt wird
ist das schon 20 kb groß und da genau den Code zu finden...

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 11:29 Uhr

ZeroG
Posts: 1487
Nutzer
@MaikG:
Also zu allererst muß ich mal sagen das das Threadthema komplett irreführend ist.
OS4Emu ist ein MOS Programm, da fällt es nicht gerade leicht drauf zu kommen das es hier um die 68k-Emulation von OS4 geht.

So, hast du das ganze mit oder ohne JIT probiert?

Was sagt der Grimreaper dazu, wie sieht das Crashlog aus?

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 15:32 Uhr

MaikG
Posts: 5172
Nutzer
>Also zu allererst muß ich mal sagen das das Threadthema komplett
>irreführend ist.
>OS4Emu ist ein MOS Programm, da fällt es nicht gerade leicht drauf
>zu kommen das es hier um die 68k-Emulation von OS4 geht.

Sorry, was wirklich passendes, kurzes ist mir nicht eingefallen.

>So, hast du das ganze mit oder ohne JIT probiert?

Beides natürlich.


>Was sagt der Grimreaper dazu, wie sieht das Crashlog aus?

Also da muss ich sagen, ich komme mit Enforcer klar, mit Cyberquard
klar, aber den Grimreper kann ich nichts entnehmen was ich in irgendeiner
weise interpretieren kann.

Ich konnt einmal auch fortsetzen, dann wurde statt sagen wir
500 eine Floatingpoint zahl ausgegeben.

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 16:05 Uhr

ZeroG
Posts: 1487
Nutzer
@MaikG:
Zitat:
Beides natürlich.
Ok, wenns mit und ohne JIT abstürzt ist es schonmal kein Bug im JIT. :D

Zitat:
Also da muss ich sagen, ich komme mit Enforcer klar, mit Cyberquard
klar, aber den Grimreper kann ich nichts entnehmen was ich in irgendeiner
weise interpretieren kann.

Dann setzt doch hier mal das komplette Crashlog rein, im GR gibts ja einen Knopf um das Ding zu speichern. Wenns geht bitte ein Log von einem Absturz ohne JIT.
(Der JIT verschiebt ein paar Addressen, also ist zum debuggen von 68k-Zeug am besten ein Log zu gebrauchen das ohne JIT entstanden ist.)

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 16:23 Uhr

MaikG
Posts: 5172
Nutzer
a&=50000
print str$(a&/1000)






Crash log for task "Test"
Generated by GrimReaper 52.4
Crash occured in module kernel at address 0x08215590
Type of crash: program exception

Register dump:
GPR (General Purpose Registers):
0: 08227B30 3EA7FF60 100E1110 8000000B 00000000 0000000C 0000000A 00800000
8: 08645EE0 08696B56 0868E650 08696B57 48002222 11100E11 3EECF0A0 0034000F
16: 9FFA3B00 FFFFFFFF 3EE0CA80 3EB52850 0882F68C 00000000 08791D0A 00000000
24: 00000001 3EB529B8 7FFFFFFF 80000014 3EF19740 3F321582 3FFF9140 00000000


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 4.19374e-309 5.67894e-299 2.84864e-260
4: 3.26001e-265 5.97523e-299 5.37793e-299 3.90152e-308
8: 3.39035e-43 4.6905e-09 1.78065e-235 1.18938e-134
12: 12.0591 3.03342e-284 1.42904e-284 9.73474e-309
16: 3.19914e-308 9.163e-130 1.1684e+78 7.23155e-308
20: 50 10000 2.50324e-308 5.9528e-236
24: 2.29731e+155 1.06758e-167 6.13473e-130 6.28161e-77
28: 2.23321e-187 7.20566e-241 5.77053e+53 1.78002e-133

FPSCR (Floating Point Status and Control Register): 0x201F0000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F070
Condition (cr) : 0x48002282
Instruction Pointer (ip) : 0x08215590
Xtended Exception (xer) : 0x20000200
Count (ctr) : 0x0822D10C
Link (lr) : 0x0820796C
DSI Status (dsisr) : 0x00017D07
Data Address (dar) : 0x00017360



680x0 emulated registers:
DATA: 00004049 00000000 40C38800 00000000 0000001A 00000000 00000000 40490000
ADDR: 3EA7FFBC 3EB3505F 3EF01E44 3F328008 3EA7FFE4 3EF01004 3EF01FB8 3EA7FFB8
FPU0: 50 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x08215590 belongs to module "kernel" (HUNK/Kickstart)

Stack trace:
native kernel module kernel+0x00015590
native kernel module kernel+0x00027b30
native kernel module kernel+0x000468b8
native kernel module kernel+0x00053b84


PPC disassembly:
08215588: 4bfffff0 b 0x8215578
0821558c: 60000000 nop
*08215590: 7fe00008 trap
08215594: 4e800020 blr
08215598: 3c600821 lis r3,2081

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 19:06 Uhr

TetiSoft
Posts: 197
Nutzer
Zitat:
Original von MaikG:
Also da muss ich sagen, ich komme mit Enforcer klar, mit Cyberquard
klar, aber den Grimreper kann ich nichts entnehmen was ich in irgendeiner
weise interpretieren kann.

Der GrimReaper hat seine Stärken beim Suchen von Bugs in
PPC-Programmen, zusammen mit addr2line bekommt man oft
leicht raus in welcher Quellcode-Zeile genau der Fehler steckt.
Bei 68k-Programmen ist es schwieriger weil ja nicht der 68k-Code
abstürzt sondern der PPC-Code den Petunia daraus gemacht hat,
oder der interpretierende 68k-Emulator wenn man Petunia deaktiviert hat.

Es gibr eine Umgebungsvariable "Reaper.68kStacktrace" oder so
ähnlich (such in GrimReaper selbst oder im kernel), die ist numerisch
und gibt die Anzahl der Stacktrace-Zeilen für 68k an, damit und
OHNE Petunia kann man machmal aus einem GrimReaper-Log heraus
erkennen wo im 68k-Programm der Fehler liegt.

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 19:36 Uhr

TetiSoft
Posts: 197
Nutzer
Zitat:
Original von MaikG:
>Die Emualtion führt ja keinen Basic code aus, sondern das
>resultierende Compilat. Müsste man mal disassemblieren was das
>passiert.

Ja, das ist schon klar. Da auch die Library gelinkt wird
ist das schon 20 kb groß und da genau den Code zu finden...


Das war eine Steilvorlage denke ich :)
In einem anderen Thread wollte ich darauf hinweisen daß
fehlender Assembler-Quellcode bei größeren (30k) Binaries
in Arbeit ausarten könnte, Deine Antwort war
Zitat:
>Ich hab schon ab und an 68k Binaries gepatcht weil kein
>Quellcode da war und habe auch Bugs in ASM-Quellcode gefixt und
>kann das "fast genauso gut wie der ASM-Source" definitiv nicht
>unterschreiben.

Warum? Es fehlen vielleicht die klar lesbaren Library einsprünge
oder selbst definierten Konstanten. Aber nach einer weile gewöhnt
man sich dran. Wobei librarys wurden ja damals eh nicht so häufig
verwendet.


Wenn Du vor und nach der Stelle irgendwas einfügst das sich im
Disassembler leicht finden läßt, eine Ausgabe eines suchbaren
Textes z.B., sollte es leichter werden.

[ - Antworten - Zitieren - Direktlink - ]

10.12.2007, 23:32 Uhr

MaikG
Posts: 5172
Nutzer
>In einem anderen Thread wollte ich darauf hinweisen daß
>fehlender Assembler-Quellcode bei größeren (30k) Binaries
>in Arbeit ausarten könnte, Deine Antwort war

Ich bin bloß faul. Nein, in Assembler hab ich nur
relativ wenig gemacht und das meiste war auch schon
sehr lange her.



>Wenn Du vor und nach der Stelle irgendwas einfügst das sich im
>Disassembler leicht finden läßt, eine Ausgabe eines suchbaren
>Textes z.B., sollte es leichter werden.


Der Compiler kann Text ja ablegen wo er will, von daher bringt
das auch nichts.
Früher hab ich z.B. in einem Programm die OpenScreen Taglist
zuerst per Library Einsprung gesucht(HexEditor) aber da waren oft nicht die
zu modifizierenden Daten...

[ - Antworten - Zitieren - Direktlink - ]

11.12.2007, 01:12 Uhr

TetiSoft
Posts: 197
Nutzer
Zitat:
Original von MaikG:
>Wenn Du vor und nach der Stelle irgendwas einfügst das sich im
>Disassembler leicht finden läßt, eine Ausgabe eines suchbaren
>Textes z.B., sollte es leichter werden.


Der Compiler kann Text ja ablegen wo er will, von daher bringt
das auch nichts.

Wenn der Disassembler was taugt hat jeder Text einen Label
und dieser Label wird im Code genau einmal referenziert.
Hängt natürlich auch davon ab was das Basic da genau für einen
Code produziert.

Oder sei doch schlau und disassembliere zwei Versionen die
sich nur in der verwendeten Konstanten im Quellcode unterscheiden
und mach ein diff, dann findest Du schonmal wo Dein eigener Code
eigentlich liegt weil Startup und linker-Libs ja gleich bleiben.

[ - Antworten - Zitieren - Direktlink - ]

11.12.2007, 11:12 Uhr

thomas
Posts: 7716
Nutzer
Zitat:
sei doch schlau

?( :lach:


--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

11.12.2007, 12:14 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von MaikG:

Ich hab einen befehl wie

STR$(a&/1000)

STR$ macht nichts anderes als eine Variable zum String zu
wandeln. a&/1000 Teilt die LONG a druch 1000.

... es geht nicht.

Hingegen:

b&=a&/1000
STR$(b&)

...

Ich konnt einmal auch fortsetzen, dann wurde statt sagen wir
500 eine Floatingpoint zahl ausgegeben.


Das wundert mich eigentlich nicht.
In Basic ist x/y immer eine Floating-Point Operation, selbst dann, wenn beide Operatoren (und sogar die Zielvariable) einen Integer-Typ besitzen.

Einfach zu Erkennen,
a&=42
b&=a&/22

liefert eine 2 in b&, also das FP-Ergebnis wurde nach Integer gerundet.

Du führst also zwei völlig verschiedene Operationen durch. Im ersten Fall lässt Du eine Floating-Point Zahl in einen String umwandeln, im zweiten Fall rundest Du zuerst in ein Integer und lässt dann einen Integer in einen String umwandeln.

Damit ist klar, dass der Fehler in der Umwandlung einer FP-Zahl in einen String liegt.

Das kannst Du ja auch Testen...

? STR$(RND(0))

mfg

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

[ - Antworten - Zitieren - Direktlink - ]

11.12.2007, 14:58 Uhr

MaikG
Posts: 5172
Nutzer
>Das kannst Du ja auch Testen...

Klingt eigenartig.

RND ist eine Floating Point, wie auch
TIMER

aber mit Defint a-z lege ich doch alles als Integer fest.

[ - Antworten - Zitieren - Direktlink - ]

11.12.2007, 15:56 Uhr

MaikG
Posts: 5172
Nutzer
Scheint aber zu stimmen, denn das 2. Beispiel braucht
doppelt so lang wie das erste.

Da die Variablen an Verschiedenen Positionen an komischen
stellen im Programm liegen konnte ich auf die schnelle
nicht den entsprechenden Code finden.

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 09:59 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von MaikG:
Scheint aber zu stimmen, denn das 2. Beispiel braucht
doppelt so lang wie das erste.


Deine Art der Fehlerdiagnose finde ich immer wieder faszinierend.

I-)

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 10:04 Uhr

MrMarco
Posts: 445
Nutzer
Sieh es mal so...

Würde er bei uns beiden in der Firma arbeiten, dann hätten wir unseren Spaß ;)

Stell dir mal vor er schreibt einen Unittest auf diese Art und die Fachabteilung stellt fest, dass hier bei den Beträgen ein paar Mio Differenz dann sind *G*

DAS wird ein Spaß! Den Anpfiff hören wir auf der anderen Gebäudeseite noch :D

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 10:05 Uhr

Solar
Posts: 3680
Nutzer
:lach: 8)

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 10:12 Uhr

MaikG
Posts: 5172
Nutzer
>Deine Art der Fehlerdiagnose finde ich immer wieder faszinierend.

Hast du irgendwas sinnvolles zum Thema beizutragen?

Holger ist sehr kompetent, weil mir dieses verhalten von
Basic nicht bekannt ist machte ich einen Test.

Trotz benutzung einer 2. Variable wird das Programm doppelt
so schnell. Was nur heissen kann das im fall eine doppelt
so komplizierte Operation läuft. Eine LONG hat die halbe länge
einer Floating-Point, dazu kommt das FPU berechnungen
immer langsamer sind.
Dann natürlich die FP ausgabe in OS4.

Ja, aber wem erzähle ich das. Du kannst ja gar nicht Programmieren
so weit ich weiss.

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 10:22 Uhr

Robin
Posts: 1056
Nutzer
@MaikG:

> Du kannst ja gar nicht Programmieren so weit ich weiss.

Öhm ... http://www.rootdirectory.de/resume.html

--
(Bild) http://my.morphosi.net/
morphos

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 10:39 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von MaikG:

Hast du irgendwas sinnvolles zum Thema beizutragen?


Hätte ich wohl, wenn ich irgendwelche Hoffnung hätte, daß Du aufnahmebereit wärst.

Ich könnte Dir sicher einiges zum Thema Softwaretest, Fehlerdiagnose und Problembeschreibung beibringen. Es würde Dir mit Sicherheit auch helfen in der Kommunikation mit anderen Entwicklern.

Falls ich mich getäuscht haben sollte und Du Interesse hast, melde Dich einfach mal über PN und ich höre auf zu feixen. ;)

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 17:19 Uhr

ylf
Posts: 4112
Nutzer
@MrMarco & Solar: ist euch langweilig auf der Arbeit oder warum treibt ihr euch hier wieder herum? :D

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 17:37 Uhr

Solar
Posts: 3680
Nutzer
Jup. I-)

Edit: Nee, die Slashdotter waren gemein zu uns.

Edit2: ...oder, draußen war's uns zu kalt und wir holen uns hier ein bißchen Nestwärme. :lach:

[ Dieser Beitrag wurde von Solar am 12.12.2007 um 17:38 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 18:17 Uhr

MaikG
Posts: 5172
Nutzer
>Ich könnte Dir sicher einiges zum Thema Softwaretest,
>Fehlerdiagnose und Problembeschreibung beibringen.

An meinen vielen Bugreports hatte bissher keiner was auszusetzen.

Logisch das dies per Forum nicht grade gut geht, ich will hier
z.B. auch nicht alles mit Crashlogs zumölen.

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 18:43 Uhr

ZeroG
Posts: 1487
Nutzer
@MaikG:
Zitat:
Logisch das dies per Forum nicht grade gut geht, ich will hier
z.B. auch nicht alles mit Crashlogs zumölen.

Genau das ist aber im moment (leider) die einzigste möglichkeit als nicht Betatester Bugreports zu OS4 Systemteilen loszuwerden.

Oder man weiß durch Zufall wer für das fragliche Systemteil zuständig ist und macht es direkt.

Falls direkt:
NUR Bugreports/Crashlogs von OS4 Systemteilen, nicht von jedem 68k-Spiel/-Anwendung/-Sonstwas was bei dir unter OS4 bei dir absemmelt.

EDIT:
Zitat:
Original von TetiSoft auf OS4Welt.de
Wenn man nicht selbst rausfindet an welchen Autor man am besten
ein Crashlog schickt, ist öffentliches Nachfragen wohl das beste.

Tipp: Den StackTrace-Teil des Logs in der Frage mitschicken,
aber nur den, und nur wenn es ein DSI-Crash ist (bei ISI hilft der
Teil meist nicht). Ggf. sieht man im Stacktrace ob das Programm
selbst abstürzte oder eine vom Programm aufgerufene Bibliothek etc,
dann macht es Sinn auch in der Bibliothek nach dem Fehler zu suchen.

Also die ersten 4 Zeilen + Stacktrace bei DSIs reichen zum nachfragen.

[ Dieser Beitrag wurde von ZeroG am 13.12.2007 um 11:37 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.12.2007, 23:24 Uhr

MaikG
Posts: 5172
Nutzer
>Falls direkt:
>NUR Bugreports/Crashlogs von OS4 Systemteilen, nicht von jedem
>68k-Spiel/-Anwendung/-Sonstwas was bei dir unter OS4 bei dir
>absemmelt.


Bei letzteren würde das wohl das Postfach sprengen.

Trotzdem wo sollte ich ein Crashlog hinsenden?
Die Hyperion Seite sieht irgendwie so minmalistisch aus,
legentlich zum Speichermanagement gibts eine Erklärung.

Z.b. hab ich eins von Prefs/GUI.
Meistens schmiert Grimp aber ab bevor man das Log speichern kann.

[ - Antworten - Zitieren - Direktlink - ]

13.12.2007, 01:41 Uhr

ZeroG
Posts: 1487
Nutzer
@MaikG:

Keine Ahnung wer für Prefs/GUI zuständig ist.

Zitat:
Trotzdem wo sollte ich ein Crashlog hinsenden?
An die Entwickler direkt. Dazu muß man allerdings die entsprechenden EMail-Addressen kennen, und wissen das der Entwickler da wirklich seine Finger dran hatte. Ab und zu findet man dazu Hinweise wenn man die Forenbeiträge ließt.

Du kannst eigendlich nur ein neues Thema mit dem Titel "OS4 Crashlog zu <Systemteil>" aufmachen, oder einen Betatester/Entwickler fragen ob er es weiterleitet.
Ist nicht optimal ist aber so, den EMail-Support sollte wohl Amiga <wasgeradeaktuellist> machen, in der letzten A1 Version findet man noch eine (vermutlich tote, wir kennen die ja inzwischen) EMail-Addresse von denen. Ist aber bekanntlich alles anders gekommen.

Zitat:
Meistens schmiert Grimp aber ab bevor man das Log speichern kann.

Zum Glück gibts jetzt zwei Arten den Amiga zu Reseten
- Soft (Kickstart wird nicht nochmal geladen)
- Hard (wie direkt nach dem Anschalten)

Wenn der Grim also auch abschmiert und ein SoftReset (CTRL-AMIGA-AMIGA) den Amiga wieder erfolgreich nach OS4 bringt, kann man in einer Shell mit

dumpdebugbuffer ram:crash.log

das Crashlog noch retten. Praktisch was?

[ - Antworten - Zitieren - Direktlink - ]

13.12.2007, 10:21 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von MaikG:
>Ich könnte Dir sicher einiges zum Thema Softwaretest,
>Fehlerdiagnose und Problembeschreibung beibringen.

An meinen vielen Bugreports hatte bissher keiner was auszusetzen.


Es war mir zu blöd, deswegen in der Historie irgendwelcher Threads herumzugraben, aber dankenswerterweise brauchte ich das ja gar nicht...

[ - Antworten - Zitieren - Direktlink - ]

13.12.2007, 10:29 Uhr

MaikG
Posts: 5172
Nutzer
>dumpdebugbuffer ram:crash.log

>das Crashlog noch retten. Praktisch was?


Mh, fürs Debuggen ja, für den Speicherkonsum eher nicht.



>Es war mir zu blöd, deswegen in der Historie irgendwelcher Threads
>herumzugraben, aber dankenswerterweise brauchte ich das ja gar nicht...

Ich rede von richtigen Bugreports per Email.

[ - Antworten - Zitieren - Direktlink - ]

13.12.2007, 11:33 Uhr

ZeroG
Posts: 1487
Nutzer
@MaikG
Zitat:
Mh, fürs Debuggen ja, für den Speicherkonsum eher nicht.
Woher wusste ich nur das das wieder kommt...

Lese mal die Dokumentation vom Kernel, da steht wie du das auf die serielle Schnittstelle einstellst. Aber dann mußt du einen 2. Computer per Nullmodemkabel dran und auf empfang haben, wenn nicht geht der Report ins nichts. Kann auch sein das man da irgendwo die Buffergröße einstellen kann.

Ich denke das es so wie es ist am besten ist.

Niemand kann zu 100% vorhersagen wann und unter welchen Umständen sowas passiert, muß ja nicht unbedingt ein Systemteil sein, die Authoren von Spielen/Anwendungen, wollen ja auch ihre Reports.

Gerade die Crashes die nur sehr selten Vorkommen sind aus Entwicklersicht am interressantesten.

Zitat:
Ich rede von richtigen Bugreports per Email.

Und was bitte ist daran so schwer eine vernümpftige und wirklich informative Beschreibung des Fehlers in ein Forum zu schreiben, wenn du sowieso schon A gesagt hast? Warum muß da aus deiner Sicht unbedingt ein B per Mail kommen?

Ich hab in meinem Post vom 12.12. übrigens noch ein Zitat von TetiSoft auf OS4Welt angehängt, hatte ich da vergessen. Vielleicht schreibst du ja eher in ein Forum wenn du nicht das ganze Log schicken mußt.

[ - Antworten - Zitieren - Direktlink - ]


-1- 2 [ - Beitrag schreiben - ]


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


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