Jammer-Thread

[Schrompf]

Nebenbei: ab VS2008 braucht man kein separates Platform-SDK mehr. Wenn Du schon aktualisierst, dann mach's doch konsequent.

[Krishty]

Vertex-Deklarationen kann man mit sizeof und offsetof ja schon sehr sicher gestalten … fehlt nur noch ein Template für das Format.

wtf

Achja, ich hatte das Format ja von 16-Bit-Floats auf 16-Bit-UNorms geändert …

… oder auch auf SNorms. FFFFUUUUU

[Helmut]

allerdings war ich diesmal zu faul, wieder ein paar hundert 'strcpy', 'strcat', usw in 'strcpy_s', 'strcat_s' usw zu ändern. hab mir dafür also ein paar ganz unschöne #defines geschrieben (die das was strcpy_s dem strcpy vorraus hat, wieder ganz und gar zu nichte machen), compiliert um die linkerfehler zu bekommen ...

Ähm, niemand zwingt dich die _s Versionen zu benutzen. Die Meldungen darüber sind alles nur Warnungen, die man auch deaktivieren kann, wenn man sich mal eine ganz durchliest ;) (ein #define mit kryptischem Namen)

Ciao
Helmut

[Aramis]

Genauer, du *solltest* die -s- Versionen nicht benutzen. Denn damit wird dein Code erstmal unportabel, ganz mal zu schweigen dass die Dinger einfach nur haesslich aussehen.

Praktischer Nutzen: mag existieren, ich hab bislang davon aber noch nicht profitiert. Sprich: keine der neuen 'Sicherheitsfunktionen' hat mir je das Leben gerettet. Lieber in neuem Code konsequent auf idiomatischere Loesungen (std::string) setzen, oder, wenn der alte Code staendig Probleme macht, diesen auch auf diese umstellen.

[Krishty]

Genauer, du *solltest* die -s- Versionen nicht benutzen. Denn damit wird dein Code erstmal unportabel, ganz mal zu schweigen dass die Dinger einfach nur haesslich aussehen.

Lustig, denn als ich meinen Code portiert habe haben mir genau diese Funktionen den Hintern gerettet, da sie exakt das Loch abdecken, das VC 6’ CRT meinem Code gelassen hatte :)
Bei einer in VC 6 geschriebenen DirectX-7-Engine wird mit Portabilität nichts zu reißen sein, aber ::std::string ist natürlich trotzdem vorzuziehen wo immer es möglich ist. Allein, weil die _s-Funktionen in einer mächtigen Explosion hochgehen, wenn der Puffer zu klein wird, statt einfach einen Fehler zurückzugeben.

Ich würde aber viel lieber die #defines sehen, die eine Nutzung der _s-Versionen unmöglich machen :)

[Aramis]

Meinst du _CRT_SECURE_NO_DEPRECATE?

[Krishty]

Nein – ich merke gerade, dass ich das hier ein wenig überspitzt im Gedächtnis hatte:

hab mir dafür also ein paar ganz unschöne #defines geschrieben (die das was strcpy_s dem strcpy vorraus hat, wieder ganz und gar zu nichte machen), compiliert um die linkerfehler zu bekommen ... und schwups, war ich vollbildmodus meiner anwendung.

[Löwe]

Ähm, niemand zwingt dich die _s Versionen zu benutzen. Die Meldungen darüber sind alles nur Warnungen, die man auch deaktivieren kann, wenn man sich mal eine ganz durchliest ;) (ein #define mit kryptischem Namen)

danke ... bin fehlermeldungen mit lösungsvorschlägen nicht gewöhnt. dazu kommen halt 4 jahre abstinenz :D

@Krishty
... unmöglichmachen nicht.
meine difines sahen in etwa so aus:

Code: Alles auswählen

#define MAXSTRLEN 8192
#define strcpy(str1, str2) strcpy_s(str1, MAXSTRLEN, str2)

... lässt mich auch nur ruhig schlafen, weil ich schon vorher keine probleme im zusammenhang mit char* im code hatte. wobei, nein, eigentlich lässt es mich nicht ruhig schlafen ;)

::std::string ist natürlich toll. aber auch dafür müsste ich ne menge umschreiben, was ich eigentlich nicht vor habe. ich wollte meine "engine" nicht umschreiben, sonden nutzen :)

[Krishty]

wobei, nein, eigentlich lässt es mich nicht ruhig schlafen ;)

Noch nicht einmal mich ;)

Btt: Gerade durch Jahre alte Sicherheitskopien gestöbert … CS-Maps und so. Irgendwo im Bereich 2004 habe ich zufällig eine BMP in einen Hex-Editor geladen und dabei entdeckt, dass das Mistding von Bildbearbeitungsprogramm, das ich damals benutzt habe, die Namen meiner Fotosammlungen hinten an die Dateien angehängt hat. Wenn ich die Fotosammlungen wirklich benutzt hätte, hätte das wohl eine datenschutztechnische Katastrophe sein können :(

[Lynxeye]

Weil ich gerade am Nouveau Nvidia Treiber verzweifle. Irgendwo im Kernelcode ist ein Bug in der Verwaltung der BufferObjects, wodurch diese wenn sie sich im GART befinden gelöscht werden, bevor die GPU mit zeichnen fertig ist. Allerdings tritt das Problem nur auf NV4x Grakas auf. Jemand hat dafür im Userspace einen Workaround eingebaut, der allerdings zwei Drittel der Performance frisst. Verdammt blöde Sache und ich finde den grundlegenden Fehler nicht.

Kernelspace debuging ist nicht lustig. :(

[klickverbot]

@Lynxeye: Du kannst dir meines Mitleids sicher sein – ich habe einmal kurz probiert, ein paar Bugs im 3D-Support von noveau anzugehen, dann das Interesse aber aus sicher vollkommen unerfindlichen Gründen recht schnell verloren… ;)

[kimmi]

Welchen Debugger benutzt du, WinDbg oder etwas anderes?

Gruß Kimmi

[Lynxeye]

Da es sich um eine Linuxmachine handelt: KGDB. Nouveau ist der freie 2D/3D Treiber, der durch RE des NVidia Blobs entstanden ist. Liefert auch schon erstaunlich gute Ergebnisse, allerdings gibt es halt immer wieder solche kleinen Punkte, wo Fehler auftreten, die man aber mangels Dokumentation sehr schwer verstehen kann.

[Krishty]

Beim Kopieren von ein paar Dateien über’s Netzwerk:

Ich kann leider nicht sagen, welcher Prozess das verzapft hat, aber ich hätte die Kiste wirklich fast aus dem Fenster geschmissen. Selbst beim Zippen ganzer Datenträger mit höchsten Einstellungen läuft mir der Arbeitsspeicher nicht dermaßen voll. Um überhaupt zum Task-Manager zu switchen hat der fast eine Minute geswappt …

[Krishty]

Präzision ist wirklich ein Thema für sich. Nachdem doubles sich in der Zeit- und Datumsrechnung als furchtbar ineffizient erwiesen haben, steige ich nun gerade auf Festkomma-Arithmetik um (was ich eh schon ewig vorhatte) … aber was man vorn gewinnt, verliert man hinten. Nun sitze ich schon seit einer halben Ewigkeit daran, an den richtigen Stellen das Richtige zu runden … ein echtes Trauerspiel. Da fehlen mir dann ein paar Hundertstelsekunden, obwohl unsere Prozessoren heute in jedem Takt genug Binärstellen verarbeiten, um jeden Zeitpunkt der Menschheitsgeschichte auf eine Millionstelsekunde genau adressieren zu können …

[eXile]

Heute gab es bei mir mal wieder ein DLL-Hell-Problem der Extraklasse. Eine Executable (x64) benutzt eine DLL, welche unter Debug-Einstellungen kompiliert wurde. Wie sich später heraustellte, hatte diese DLL aufgrund von Konfigurationsschwierigkeiten eine Abhängigkeit zur MSVCR90.dll. Richtig, die MSVCR90.dll ist eine DLL für Release-Versionen. Aber damit fing das Ganze erst an.

Da die Executable natürlich auch in der Debug-Verison vorlag, hatte diese keine eingebetteten Manifeste, wie denn die MSVCR90.dll geladen werden soll. Normalerweise liegt diese nämlich in unterschiedlichen Versionen für x86 und x64 im WinSxS-Verzeichnis vor. Also geht das Spiel los: Der PE-Lader lädt die Executable. Da kein Manifesteintrag zur MSVCR90.dll drin ist, durchsucht er bekannte Pfade nach dieser Datei. In meiner Pfad-Umgebungsvariable ist auch der Pfad zur MikTeX-Executable eingetragen, und in demselben Verzeichnis gibt es auch eine MSVCR90.dll. Diese passt natürlich nur zu MikTeX, und liegt für x86 vor. Also schmeißt mir der PE-Lader eine so tolle Fehlermeldung an den Kopf, wie „Die Anwendung konnte nicht korrekt gestartet werden (0xc0000005)“. Yay.

Nach nem halben Tag hatte ich diese Hintergrundinfos dann mir zusammengesucht. Nachdem ich das mit MikTeX überhaupt mal herausgefunden habe (Dependency Walker for the win), hab ich es natürlich sofort wieder aus der Pfad-Variable entfernt. Immerhin kommt nun die Fehlermeldung, dass die MSVCR90.dll nicht gefunden wurde, was ja am fehlenden Manifest dafür liegt.

Vielleicht sollte ich nun noch erklären, warum die DLL überhaupt die MSVCR90.dll will. Weil OpenEXR so ein bescheuertes CreateDLL-Tool hat, welches die zu exportieren Symbole und deren Abhängigkeiten zusammenstellt. Und dabei offensichtlich hart failt. Morgen also das Tool erst einmal fixen, das wird ein Spaß …

[Lord Delvin]

Präzision ist wirklich ein Thema für sich. Nachdem doubles sich in der Zeit- und Datumsrechnung als furchtbar ineffizient erwiesen haben, steige ich nun gerade auf Festkomma-Arithmetik um (was ich eh schon ewig vorhatte) … aber was man vorn gewinnt, verliert man hinten. Nun sitze ich schon seit einer halben Ewigkeit daran, an den richtigen Stellen das Richtige zu runden … ein echtes Trauerspiel. Da fehlen mir dann ein paar Hundertstelsekunden, obwohl unsere Prozessoren heute in jedem Takt genug Binärstellen verarbeiten, um jeden Zeitpunkt der Menschheitsgeschichte auf eine Millionstelsekunde genau adressieren zu können …

Klingt ja fast so, als würde dein nächstes Projekt ein Kalendermanager werden:D

Warum optimierst du Prozesse, die nur marginal oft auftreten? Ich hatte eigentlich immer viel Spaß mit double timern, zumal die auf meinem Rechner nicht erkennbar langsamer sind als irgendwelche anderen Basistypen.
Gruß

[Schrompf]

Wir haben uns vor langer Zeit mal einen uint64 als Zeitpunkt bzw. Zeitdifferenz in ne Klasse gekapselt. Auch auf nem Intel, wo der PerformanceCounter eine Auflösung in Höhe der Prozessortaktfrequenz hat, kommt man damit noch einige Hundert Jahre hin. Gibt dem Ding dann noch Umrechnungsfunktionen in/von float/double in Sekunden und Du bist ernsthaft versorgt für den Rest Deiner Tage.

Wobei... bei Deiner sonst so üblichen Arbeitsweise reichen Dir wahrscheinlich 200 Jahre Zeitspanne nicht. :-)

[Krishty]

Heute gab es bei mir mal wieder ein DLL-Hell-Problem der Extraklasse. Eine Executable (x64) benutzt eine DLL, welche unter Debug-Einstellungen kompiliert wurde. Wie sich später heraustellte, hatte diese DLL aufgrund von Konfigurationsschwierigkeiten eine Abhängigkeit zur MSVCR90.dll.

Sowas ist wirklich die verabscheuenswerteste Kategorie von Fehlern. Was viele nicht wissen ist, dass Visual C++ in Batch-Builds ständig Debug-, Release-, x86- und x64-Versionen durcheinanderschmeißt – der Bug ist bekannt, aber nicht lösbar. Auch sorgt die Virenscanner-Warnung „mt.exe exited with code 31“ dafür, dass das Kompilat in allen folgenden, nicht-kompletten Rebuilds nur mit einem Bruchteil der Ressourcen produziert wird, die ihm zugewiesen sind (u.a. ohne Manifest), solange man das Kompilat nicht von Hand löscht. Die Moral von der Geschicht’: Niemals Batch-Builds durchführen (dank Multi-CPU-Compilation ist manuelles Auswählen und Builden eh schneller) und den Virenscanner für alle Output-Verzeichnisse deaktivieren, sonst ist man irgendwann schwer gefrustet.

Klingt ja fast so, als würde dein nächstes Projekt ein Kalendermanager werden:D
Warum optimierst du Prozesse, die nur marginal oft auftreten? Ich hatte eigentlich immer viel Spaß mit double timern, zumal die auf meinem Rechner nicht erkennbar langsamer sind als irgendwelche anderen Basistypen.

Wir haben uns vor langer Zeit mal einen uint64 als Zeitpunkt bzw. Zeitdifferenz in ne Klasse gekapselt. Auch auf nem Intel, wo der PerformanceCounter eine Auflösung in Höhe der Prozessortaktfrequenz hat, kommt man damit noch einige Hundert Jahre hin. Gibt dem Ding dann noch Umrechnungsfunktionen in/von float/double in Sekunden und Du bist ernsthaft versorgt für den Rest Deiner Tage.
Wobei... bei Deiner sonst so üblichen Arbeitsweise reichen Dir wahrscheinlich 200 Jahre Zeitspanne nicht. :-)

Da bei mir eine Menge Astronomie vorkommt, ist das leider kein marginaler, sondern sogar ein Hauptprozess … ein Performance-Counter hat bloß ein paar Millionen Ticks pro Sekunde, damit kommt man weitaus länger hin als ein paar hundert Jahre. Leider ist er damit nicht unbedingt präzise genug.
Alle grundlegenden Funktionen – Berechnung der Sternzeit, des Sonnen- und Mondstands – rechnen mit dem Julianischen Datum, also der Zeit, die seit 12:00 am 1. Januar 4713 vor Christus vergangen ist. Allein bis in die Gegenwart sind das also rund 80 Billionen Sekunden, die vor dem Komma gespeichert werden müssen. Wenn man das Spiel auch noch in der Zukunft spielen lassen möchte kommen ein oder zwei Bits dazu.
Hinter dem Komma wird es noch haariger, weil ich auch Positionsangaben mit Festkomma speichern möchte. Habe ich ein Objekt, das sich mit einem cm pro Sekunde bewegt (0,01 m÷s, das könnte eine rollende Cola-Dose sein) und meine Anwendung läuft in fünf Jahren auf entsprechenden Rechnern mit 200 fps (z.B. weil irgendjemand benchen möchte), sind das 0,01 m × 0,005 s – da liegt die Ungenauigkeit einer Festkommazahl, die im Bereich von Millionstelsekunden/-metern arbeitet, schon bei 2 %. Jetzt bedenkt man, dass man auch in der Zeitdimension Überabtastung braucht und verlangsamt die In-Game-Zeit für Bullet-Time-Effekte auf ein Zehntel und schon ist die ganze Physik dahin.

Klingt pedantisch, aber bei sowas habe ich traumatisiert … man betrachte einmal S.T.A.L.K.E.R. – Shadow of Chernobyl – da arbeitet die KI mit einer Zeitangabe in Milisekunden. Die hat aber so eine Nase als int deklariert … nach fast einem Monat Spielzeit versagt also spielweit irreversibel die KI. Wenn man, wie ich, ein Spiel über Jahre immer wieder mit demselben Spielstand ein bisschen weiter spielt, ist das ein GaU.

[Schrompf]

ein Performance-Counter hat bloß ein paar Millionen Ticks pro Sekunde

Nein, hat er nicht. Wie ich schon schrieb: auf Intel-Prozessoren ist der Performance-Counter mit der CPU-Taktfrequenz aufgelöst. Nur auf AMD-Prozessoren ist er immer bei dreikommairgendwas Millionen Ticks pro Sekunde. Daher stammt auch mein Rechenbeispiel mit 200 Jahren Reichweite - das war bei 3GHz Timerauflösung eines aktuellen Intel-Prozessors.

Ich kann Integerrechnung auf jeden Fall empfehlen. Ich verstehe aber Dein Reichweitenproblem mit uint64 - ich würde da ein Paar von uint64 in eine Klasse packen und die Operatoren entsprechend überladen.

[Krishty]

ein Performance-Counter hat bloß ein paar Millionen Ticks pro Sekunde

Nein, hat er nicht. Wie ich schon schrieb: auf Intel-Prozessoren ist der Performance-Counter mit der CPU-Taktfrequenz aufgelöst. Nur auf AMD-Prozessoren ist er immer bei dreikommairgendwas Millionen Ticks pro Sekunde.

Ich habe hier auf meinem Core 2 Quad 2,5 Millionen Ticks pro Sekunde. Fantastisch – direkt der Nächste Grund zu jammern -.-

Ich kann Integerrechnung auf jeden Fall empfehlen. Ich verstehe aber Dein Reichweitenproblem mit uint64 - ich würde da ein Paar von uint64 in eine Klasse packen und die Operatoren entsprechend überladen.

Momentan komme ich mit 64 Bits gerade eben aus – aber wirklich bis aufs letzte Bit (bei 26 Bits für Sekundenbruchteile). Problematisch werden dann Multiplikationen und Divisionen, für die ich theoretisch Datentypen mit 128 bzw 96 Bits bräuchte … aber erstmal muss ich den fundamentalen Kram klären. So arbeitet z.B. der Prozessor aus irgendeinem Grund schon mit 128 Bits, wenn ich nur zwei 32-Bit-Zahlen multipliziere …

[Schrompf]

Ich habe hier auf meinem Core 2 Quad 2,5 Millionen Ticks pro Sekunde. Fantastisch – direkt der Nächste Grund zu jammern -.-

Öhm... bist Du sicher, dass es "Millionen" sind, nicht "Milliarden". Ich habe ne Weile nicht mehr geschaut, aber soweit ich mich erinnere hatte ich auf meinem Core2Quad 2,8 Milliarden Ticks pro Sekunde.

Momentan komme ich mit 64 Bits gerade eben aus – aber wirklich bis aufs letzte Bit. Problematisch werden dann Multiplikationen und Divisionen, für die ich theoretisch Datentypen mit 128 bzw 96 Bits bräuchte … aber erstmal muss ich den fundamentalen Kram klären. So arbeitet z.B. der Prozessor aus irgendeinem Grund schon mit 128 Bits, wenn ich nur zwei 32-Bit-Zahlen multipliziere …

Hm. Ich hätte ja erstmal die grundlegende Funktionalität implementiert, bevor ich mich über die Performance einer 32bit-Multiplikation Gedanken mache. Wenn Du einen großen Timer brauchst, dann bau einen. Die Performance desselben ist dann erst der zweite Schritt, und in den meisten Fällen sogar ein optionaler, weil man auch in engagierten Simulationen wohl bestenfalls ein paar tausend Mal pro Frame Zeiten skalieren wirst.

Aber wir beide verfolgen da halt zwei sehr unterschiedliche Ansätze... und ich bin doch immer wieder verblüfft, was Du am Ende aus Deinen Nachforschungen erfährst. Von daher: ich bin neugierig, was Du dieses Mal alles rausbekommst.

[Krishty]

Ich habe hier auf meinem Core 2 Quad 2,5 Millionen Ticks pro Sekunde. Fantastisch – direkt der Nächste Grund zu jammern -.-

Öhm... bist Du sicher, dass es "Millionen" sind, nicht "Milliarden". Ich habe ne Weile nicht mehr geschaut, aber soweit ich mich erinnere hatte ich auf meinem Core2Quad 2,8 Milliarden Ticks pro Sekunde.

Jetzt war ich verunsichert, weil es wirklich hätte sein können, dass ich die Ticks pro Sekunde mit der Julianischen Tageszahl durcheinander geschmissen habe. Ich habe aber nochmal nachgeguckt – ich kratze nun knapp an den drei Millionen. Vista vs XP vielleicht …

Hm. Ich hätte ja erstmal die grundlegende Funktionalität implementiert, bevor ich mich über die Performance einer 32bit-Multiplikation Gedanken mache. Wenn Du einen großen Timer brauchst, dann bau einen. Die Performance desselben ist dann erst der zweite Schritt, und in den meisten Fällen sogar ein optionaler, weil man auch in engagierten Simulationen wohl bestenfalls ein paar tausend Mal pro Frame Zeiten skalieren wirst.

Auch wieder wahr … aber du weißt ja: ganz oder garnicht.

ich bin neugierig, was Du dieses Mal alles rausbekommst.

Und ich erst … übrigens, gerade vergessen:

Ich kann Integerrechnung auf jeden Fall empfehlen.

Unbedingt – je tiefer ich dort eintauche, desto weniger verstehe ich, warum sich Gleitkommazahlen durchesetzt haben, zumal a) wir fast nirgends exponentielle Wertebereiche brauchen außer in HDR-Anwendungen und in der 3D-Grafik nach der Projektion, b) sich sowieso niemand um NaNs, Unendlichkeiten und die üblichen Anomalien kümmert, c) das Optimierungspotential bei Festkommazahlen mindestens 10× höher liegt und d) sie einfach einfacher sind.

[kimmi]

Du redest von 3D-Grafik, richtig? Bei Numerik-Anwendungen machen floating-Ops durchaus Sinn. Allerdnings entsinne ich mich an spezielle Server, die für numerische Floating-Point-Ops spezielle Hardware zu Verfügung hatten. KA, was das war. Ich habe aber auch schon mal in einer Anwendung mitgearbeitet, die mittels F77 versucht hat, so viel Ops wie möglich in Integer zu machen.
Aber auch da haben wir erst die Operationen fertiggestellt, bevor wir uns auf die Bit-Operation-Performance gekümmert haben ;).

Gruß Kimmi

[Krishty]

Natürlich – ich vergesse dauernd, dass es da noch was Anderes gibt :/

Als ob die Optimierung premature wäre – die Multiplikation und Division sind je nur eine Zeile Code und werden direkt durch einen Batzen Tests gejagt … da kann man auch ruhig mit der Optimierung im Auge programmieren.

[Schrompf]

Ich kann Integerrechnung auf jeden Fall empfehlen.

Unbedingt – je tiefer ich dort eintauche, desto weniger verstehe ich, warum sich Gleitkommazahlen durchesetzt haben, zumal a) wir fast nirgends exponentielle Wertebereiche brauchen außer in HDR-Anwendungen und in der 3D-Grafik nach der Projektion, b) sich sowieso niemand um NaNs, Unendlichkeiten und die üblichen Anomalien kümmert, c) das Optimierungspotential bei Festkommazahlen mindestens 10× höher liegt und d) sie einfach einfacher sind.

Och, das ist glaube ich sehr einfach zu erklären: Fließkommazahlen sind bequem. Man kann damit in beliebigen Zahlenbereichen rechnen und kommt praktisch immer zu hinreichend genauen Ergebnissen. Die Artefakte, wenn man an die Grenzen des Wertebereichs stößt, sind halt andere. Bei Integern springen die Zahlen in ganz andere Bereiche, bei floats werden sie einfach nur zunehmend ungenau und verändern sich bei kleinen Operationen irgendwann nicht mehr... als Programmierer, der auf Schadensbegrenzung aus wäre, würde ich letzteres auf jeden Fall vorziehen.

Aber wir kommen vom Thema "Jammern" ab: warum zur Hölle muss ich mir Bugtracker-Einträge wie "Bearbeitung einer TV-Aufnahme auf USB-Medium ist manchmal unmöglich" manuell raussuchen, während ich "Hilfetext von XYZ müsste anders formatiert werden" mit höchster Priorität und telefonisch vermittelter Dringlichkeit aufgedrückt bekomme? Was soll der Unsinn? Make it work, then make it beatiful, for fuck's sake.

[Lynxeye]

Das habe ich mir bei den ersten Revisionen der Firmware vom Technisat HDTV 40 auch gedacht. ^^

Bei dem Teil wurde sogar die Hauptplatine gewechselt, weil keiner mehr weiter wusste... nach ein paar Updates der Firmware stellte sich das Problem als Softwarebug heraus.

[Schrompf]

Du hast einen HDTV40? Cool... Danke für's Bezahlen meines Arbeitsplatzes!

[Herror]

Amazon.de verbietet mir Grundlos über das Lastschriftverfahren oder Rechnung zu bezahlen...

Ich darf keine Kreditkarte bekommen, weil ich kein festes Einkommen habe. Also ist Amazon für mich ab jetzt wohl gestorben...

Guten Tag,

vielen Dank für Ihr Schreiben an Amazon.de.

Bitte entschuldigen Sie nochmals, dass Sie Ihre Bestellung nicht zu Ende führen konnten.

Wir behalten uns vor die Zahlungsweise Kreditkarte als einzige zu akzeptieren. Sollten Sie sich für diese Zahlungsart entscheiden, bitte ich Sie, eine neue Bestellung wie gewohnt über unsere Website aufzugeben.

Die wichtigsten Informationen zu Zahlung per Kreditkarte finden Sie hier:

http://www.amazon.de/gp/help/customer/d ... eId=504930

Sicherlich haben Sie Verständnis dafür, dass wir uns zu internen Entscheidungen aus Gründen der Wahrung unserer Geschäftsgeheimnisse nicht weiter äußern.

Für sonstige Fragen steht Ihnen unser Kundenservice gerne zur Verfügung.

Freundliche Grüße

[Alexander Kornrumpf]

Das hab ich ja noch nie gehört. Konntest du denn früher mal etwas dort bestellen und hat das immer funktioniert? Oder ist mal eine Lastschrift zurückgegangen.

Unabhängig davon wäre ich mir mit der Kreditkarte nicht so sicher. Die Kreditkarten die hier vor allem üblich sind, sind im Grunde bessere EC Karten da du dich verpflichtest die Differenz gegenüber dem Kreditkartenunternehmen monatlich auszugleichen. "Echte" Kreditkarten wo du wirklich einen Kredit eingeräumt bekommst gibt es hierzulande meines Wissens kaum, sie sind eher im anglikanischen Raum verbreitet. Insbesondere meine ich mich zu erinnern, dass einige Direktbanken "Kreditkarten" als Standardleistung bei ihren Girokonten herausgeben. Also wenn du wirklich eine solche Karte haben wolltest, könntest du vermutlich eine bekommen.