ZFX + Developia

Verfasst: **25.09.2018, 14:52**

Das habe ich auch gefunden, aber das sieht mir stark veraltet aus.

Libs mit LTCG dürften überhaupt keinen ausführbaren Code enthalten, sondern nur den Abstract Syntax Tree, weil der Linker ja optimieren muss – und das finde ich dort nicht erwähnt. Und dann war da noch ein Artikel auf einem von Microsofts Blogs (den ich gerade nicht wiederfinde), gemäß dem sie ihre ganzen ASTs und Zwischenformate im Clang-kompatiblen Format re-implementieren wollten …

Verfasst: **26.09.2018, 21:25**

Ich lade mir Browser lieber von Fremden herunter als von Google.

Was den Aufschrei wegen dem gmail==browser-Login angeht: Das hatten wir vor einem oder zwei Jahren schon; ich hatte es selber erlebt. Im nächsten Release war es wieder verschwunden. Also genau wie jetzt.

Verfasst: **03.10.2018, 11:06**

Performance-Drop 1: Update von Windows 1803 auf 1809. 750FPS statt 850FPS.
Das OS kann ich nachvollziehen wegen Meltdown und Spectre, vermutlich. Danke "Sicherheitsexperten".

Performance-Drop 2: Treiber-Update von NVIDIA. 710 statt 750FPS gegenüber dem vorigen Treiber.
Beim Treiber scheint NVIDIA jetzt die GTX 9xx User zur 2xxx zu "vermitteln".

Macht satte 16,5% Leistung weniger. Geht mir dabei nicht um absolute Zahlen sondern ums Prinzip.
Einbrüche sind bei SetResourceBarrier von Render Target nach (Non-)Pixel Shader Resource zu betrachten.

Verfasst: **04.10.2018, 17:49**

TDK hat geschrieben:Performance-Drop 1: Update von Windows 1803 auf 1809. 750FPS statt 850FPS.
Das OS kann ich nachvollziehen wegen Meltdown und Spectre, vermutlich. Danke "Sicherheitsexperten".

Ich nicht. 1803 kam im April, da müssen Meltdown und Spectre längst abgedeckt gewesen sein (die Patches wurden zum März verteilt). Ich glaube nicht, dass es damit zu tun hat.

Verfasst: **05.10.2018, 09:38**

Habe ich schon mal gesagt, wie abgrundtief ich die MFC verachte?
Nein?
Ich verachte dieses Framework so abgrundtief, dass ich ihr den Tod, die Pest und Hepatitis B wünsche!!!
Bei meiner letzten Anwendung habe ich die GUI mit Qt geschrieben (=>wunderbar!!).... und jetzt muss ich hier diesen Rückschritt hinnehmen und mit MFC arbeiten!!
STIRB DU DRECKSDING!!!

Verfasst: **05.10.2018, 09:40**

Ich fühle mit Dir.

Verfasst: **05.10.2018, 10:50**

joggel hat geschrieben:STIRB DU DRECKSDING!!!

I second that.

Verfasst: **08.10.2018, 01:05**

Oh Mann, Visual Studio.

Der Ressource Compiler hört auf zu funktionieren, wenn die Quelldateien in was anderem als UTF-16 vorliegen.
Jemand fixt das. Und stellt versehentlich für alle neuen Quelldateien (C, C++, usw.) UTF-16 als Standard-Codec ein.
Es rutscht durch die QA.
Git kann kein UTF-16:
Git is unable to deal with UTF16 as text.

It will treat UTF16 files as binary.

And git's auto-crlf-correction will corrupt the files if I tell it to treat .cpp as text via .gitattributes.
Clang auch nicht:
1>CLANGCOMPILE : fatal error : UTF-16 (LE) byte order mark detected in 'DynamicLibrary1.cpp', but encoding is not supported
Das bedeutet, dass niemand in der QA auch nur einmal ein neues Projekt angelegt und mit Clang kompiliert oder in git eingecheckt hat. Warum auch, wenn man doch dauernd Betas raushaut und so tolle Feedback-Portale hat!!!11! Das merken die User schon selber!
Jemandem fällt das auf, aber der Support-Chinese schmettert es ab als „by design, mach eine neue Anforderung, wenn du das alte Verhalten zurückhaben willst“. Wie immer.
Yuanlong Li-MSFT [MSFT] hat geschrieben:Thank you for your feedback! We have determined that this issue is not a bug. This is currently by design although this looks more like a feature request to allow choosing the default encoding.
Die Hölle bricht los.
Comedy Gold:
Yuanlong Li-MSFT [MSFT] hat geschrieben:We are so sorry for you are experiencing. All of us want to make VS better. Please provide your suggestion in User voice: https://visualstudio.uservoice.com/foru ... studio-ide . Thanks
- Ashik Salim hat geschrieben:can we get someone who can actually address the issue at least rather than this Yuanlong guy who keeps posting a link to uservoice and does nothing else.
  - Andreas Köhler hat geschrieben:I created a change-request for this shiny "feature" here for everyone to vote:
    https://visualstudio.uservoice.com/foru ... y_id=35066
    - Yuanlong Li-MSFT [MSFT] hat geschrieben:Thanks for making VS better.
In den kommenden Monaten wird mit Version 2017.9 der Patch ausgerollt. (Hat ja nur ein Jahr gedauert.)
Die Lösung wird verkündet:
The new behavior is that all files will be UTF8 without BOM by default with two exceptions:
1. […]
2. Files that contain Unicode characters will use UTF8 with BOM. […]
HR HR HR HR Heisen-BOM! So lange du keine Unicode-Buchstaben verwendest, ist deine Datei immer UTF-8 ohne BOM! Das versprechen wir!!!!
Unicode ist abwärtskompatibel mit ASCII. So lange man keine Unicode-Buchstaben verwendet, ist eine Datei in ASCII, UTF-8, und in den meisten ANSI-Codepages ganz exakt identisch. Aber sie mussten wohl ganz ganz dolle betonen, dass die Lösung irgendwas mit UTF-8 zu tun hat.

P.S.: Dass die UI-QA seit zwei Jahren versagt, ist mir auch aufgefallen. Dass die Support-Chinesen real existieren, bezweifle ich – ist wahrscheinlich Cortana mit zufällig erzeugten Decknamen. Aber immerhin ist die QA des Compiler-Teams hervorragend.

Meine aktuell offenen Bugs; ich freue mich über Upvotes:

Thanks for making VS better.

Verfasst: **08.10.2018, 08:50**

tHaNkS fOr MaKiNg Vs BeTtEr

Verfasst: **09.10.2018, 21:43**

Habe mich bei SourceForge angemeldet um einen Bug in 7-Zip zu melden.

Hatte mein Passwort vergessen (tausend Jahre nicht da gewesen). Ich setze es zurück. Die Mail kommt nicht.

Dann fällt mir ein: Ich habe doch damals meine Mail-Adresse dort geändert! Schaue ich doch ins alte Postfach! Und siehe da: Die Recovery-Mail landete in meinem alten Postfach.

So, das wäre schon ein Jammern wert. Aber fünf Minuten später so eine Mail: „Hello Krishty, Your SourceForge account "krishty" was recently logged-in to.“ Klar, war ja ich.

Die Mail war an mein neues Postfach adressiert.

WTF?! Die speichern die Adressen mehrfach und aktualisieren sie nicht durchgängig?!

Verfasst: **12.10.2018, 19:36**

Wenn man die Adresse einer Funktion oder einer Variable hat, kann man via SymGetLineFromAddrW64() ihren Namen, ihre Quelldatei, und die Zeile ihrer Definition herausfinden. (Sofern das Projekt mit Debug-Informationen kompiliert wurde, natürlich.)

Bei mir ist sie deshalb unverzichtbar für Call Stacks, Assertions, und Debug-Ausgaben.

Dummerweise crasht sie irgendwo in dbghelp.dll!AddressMap::getSectionLength().

Aber nur in einem Projekt. Und nur in rund 80 % der Fälle; in 20 % funktioniert alles wie gewollt.

Ich habe den Quelltext zig-fach auf Speicherfehler untersucht; mit Application Verifier und Debug Checks ausgeführt; alle Compiler-Einstellungen identisch zu anderen Projekten gemacht, in denen sie zuverlässig funktioniert. Ich habe Wettläufe ausgeschlossen und verifiziert, dass DbgHlp nicht doppelt initialisiert wird. Aber all das hat nichts gebracht. Crash, Crash, Crash.

Der einzige andere Mensch, der im Internet etwas davon schreibt, ist Bruce Dawson beim Chrome-Debugging. Er schiebt es auf eine veraltete XP-Version der DLL, aber meine ist definitiv Windows 7-kompatibel. Er schließt mit einem leider völlig unbrauchbaren

The crashing may be caused by VS 2015 generated PDBs hitting some edge cases which would explain why I am seeing this more frequently. The crash is not 100% with VS 2015 PDBs, but it is a non-trivial percentage. We'll have to watch for this if VS 2015 is going to cause XP tests to crash sometimes when failing.

Ich kapituliere und klicke halt bei jeder verletzten Assertion acht Zugriffsverletzungen weg.

Fuck.

Verfasst: **17.10.2018, 17:31**

twittrss.me funktioniert nicht mehr, weil es von Twitter blockiert wird.

Schade. Also gar kein Twitter mehr für mich.

Verfasst: **24.10.2018, 13:03**

Fun fact: Als das saudische Gaskraftwerk gehackt wurde, gab sich die Malware als Windows 10-Update-Zeug aus.

https://www.fireeye.com/blog/threat-res ... tools.html
In dem XML-Dump sieht man schön, dass es als CompatTelRunner.exe lief. Das ist Microsofts Tool, das die Anwendungsnutzung aufzeichnet um zu erfahren, warum man nich auf Windows 10 umsteigt.

Das mit der Moskauer Zeitzone oben kann übrigens nur ein schlechter Scherz sein. Und warum fangen die erst um 10 an zu arbeiten? Ich will auch!

Verfasst: **26.10.2018, 09:43**

Geschichten aus dem Microsoft-Alltag: „Wir wollten Excel mit dem neuen Compiler übersetzen, aber nun ist es 40 % langsamer!“

Excel team observed a number of performance regressions in Recalc scenarios after enabling SSA optimizer in Office build. Eventually SSA optimizer was turned off, but we need to get to the bottom of this problem and fix compiler for the next drop, so Office can use SSA mode.

Das ist, wohlgemerkt, zweieinhalb Jahre nach der Veröffentlichung des Compilers.

Verfasst: **26.10.2018, 10:37**

Verstehe gar nicht warum die ihre eigene Codebases nicht für die Tests des Compilers nutzen. Die treiben da doch bestimmt allen möglichen exotischen Kram in Excel und damit kann man doch optimal den Compiler testen. Das lässt sich doch auch wunderbar automatisieren...

Verfasst: **26.10.2018, 10:49**

Tun sie – wenn du auf die Veröffentlichung oben klickst, siehst du unten, dass sie die Compiler-Änderungen vor der Veröffentlichung am Windows-Kernel, am SQL-Server, und an der JavaScript-Engine von Edge getestet haben.

Dass das Office-Team eine andere Build Chain nutzt, dürfte den unterschiedlichen Anforderungen geschuldet sein. Der Kernel ist auf ARM-Unterstützung und Meltdown/Spectre-Mitigations angewiesen; da ist naturgemäß die neueste Compiler-Version die beste. Office hingegen ist erst dieses Jahr auf ARM umgestiegen; da hat der Schuh nicht gedrückt.

Verfasst: **26.10.2018, 15:14**

Machen sie denn dann auch automatisch Performance-Tests mit den kompilierten Produkten?

Auch interessant aus deinem Link:

Testing with popular open-source projects
Exposing the compiler to more real-world code proved to be an effective way to find more bugs. This includes building and testing Google Chrome, Mozilla Firefox, CoreCLR and Chakra.

Wäre halt gut, wenn die da dann auch noch ein Performance-Tests machen. Ich kann mir kaum vorstellen, dass Excel das einzige Projekt ist, dass das zu spüren bekommt. 40% ist ja auch nicht gerade wenig.

Verfasst: **26.10.2018, 19:59**

Ich denke, dass das Optimizer-Refactoring kaum auf Leistung abzielte, sondern nur auf Korrektheit. Wir haben uns hier jahrelang köstlich darüber amüsiert, dass der Optimizer von Visual C++ bei jeder winzigen Abweichung vom vordefinierten Muster spektakulär gescheitert ist (Operanden vertauschen → komplett anderer Code → LOL). Ich muss offen eingestehen, dass sie das nun (mit dem neuen Optimizer) weitgehend unter Kontrolle haben. Dass die Ergebnisse noch dazu 0,001 % kleiner sind und vergleichbar schnell laufen, ist wohl nur das Sahnehäubchen.

Ja, das mit Excel ist ärgerlich. Aber sie haben es wohl direkt bearbeitet, nachdem es bemerkt wurde (leider schneller als meine Bug-Reports). Und dass nicht früher getestet wurde, nun, dafür hatte das Office-Team halt Gründe. Die Compiler-Entwickler haben eben auch noch anderes zu tun, als jedes Projekt der Welt zu ziehen und dafür Performance-Tests einzurichten. (Respekt, dass sie überhaupt was von außen getestet haben – als ich das letzte Mal Chrome kompilieren wollte, habe ich einfach nach ein paar Stunden hingeschmissen. Hätte ich da auch noch Benchmarks einrichten müssen …)

Übrigens wollte ich kurz nach Chromes Performance-Tests googeln (ich weiß, dass Bruce Dawson jede Menge davon fährt) und habe dann diese Seite gefunden und gesehen, dass alles Rote vier Mal so groß ist wie das Grüne, und jetzt will ich kotzen. Verstehe ich das richtig, dass Gmail nun 14-fache CPU-Leistung zieht? I don’t want to live on this planet any more.

Verfasst: **27.10.2018, 11:16**

Ein neues Wochenende, ein neuer Visual C++-Bug: https://developercommunity.visualstudio ... texpr.html

Verfasst: **30.10.2018, 19:29**

Ich habe den Bug gemeldet und einen Workaround gebaut.

Heute morgen wollte ich auf meinem Laptop arbeiten und habe ziemlich blöd geguckt: Schon wieder Internal Compiler Error.

Ich habe nun einen Repro gebastelt, der den Compiler mit 6–100 % Wahrscheinlichkeit crasht; je nach Maschine und Bitness des Compiler-Prozesses. Das riecht mir sehr sehr stark nach Dangling Pointer oder uninitialisierter Variable.

Und es gibt doch nichts geileres als Sicherheitslücken im Compiler :)

Code: Alles auswählen

// Machine 1 (64-bit):
//   Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x86 -- crashes in six out of 100 runs
//   Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x64 -- crashes in 99 out of 100 runs
// Machine 2 (32-bit):
//   Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26730 for x86 -- crashes in 20 out of 20 runs


template <
	int const [],
	size_t    size
> void crash() { }

template<size_t length> constexpr size_t constexprFunction(int const (&)[length]) {
	return 1;
}
constexpr int constexprArray[] = { 0 };

using FuncPtr = void (*)();
constexpr FuncPtr funcPtrs[] = {
	&crash<&constexprArray[0], constexprFunction(constexprArray)>
};

int main() { }

Bug Report (bitte upvoten!): https://developercommunity.visualstudio ... texpr.html

Verfasst: **31.10.2018, 02:07**

Interessant. https://godbolt.org/z/iZcxe6
Stellt man auf Clang, wird es geschluckt.
GCC hat zwar keinen Crash, verreckt aber an dem Code auch mit einer Fehlermeldung, die keinen Sinn macht.

Gräbt man tiefer, und lässt sich den Typ des Funktionszeigers mal ausgeben: https://godbolt.org/z/CCXCi3
GCC beschwert sich, dass die template<..> crash() Funktion überladen sei und man deshalb kein decltype anwenden darf. Bullshit.
Stellt man auf Clang, gibt das static_assert den Kontext mit aus, in dessen Typensignatur die korrekte Funktionszeigersignatur steht.

Ich denke das ist auch ein Bug im GCC, dass der bei einer template-funktion von einer Überladung ausgeht. Holy shit.

Verfasst: **31.10.2018, 09:05**

Hervorragend, dass du’s ausprobiert hast! Den GCC-Nonsens hätte ich auch nicht erwartet. Meldest du einen Bug dafür?

Verfasst: **31.10.2018, 11:56**

Bin mir unsicher: https://godbolt.org/z/akP6SV
hier verkackt GCC und Clang gleichermaßen. Eventuell sind unsere Erwartungen falsch.
Pointer als Template-Parameter sind wohl etwas merkwürdig. Da sollte man erst mal diskutieren, was hier vor sich geht.

Verfasst: **31.10.2018, 12:19**

Der Code ist falsch – das constexpr foo bewirkt implizit, dass foo neben constexpr auch const ist. Die Zeiger in deinen Templates erwarten aber nicht-const-Daten. Sobald du die Template-Parameter auf TestType const änderst, funktioniert alles. (Deshalb macht auch auto keine Probleme.)

(Privat schreibe ich deshalb auch immer das const hinter constexpr, man kommt sonst einfach zu schnell durcheinander.)

Verfasst: **31.10.2018, 15:10**

Danke für den Hinweis. Minimalbeispiel:

https://godbolt.org/z/DCeZVd
GCC verkackt, Clang schlucks.
Es scheint, als ginge bei der "&Array[0]" vs "Array" etwas kaputt bzw ist da eventuell eine Umwandlung im Gange, die da nicht hingehört? Klingt, als würde der bei der "&Array[0]"-Formulierung quasi die const-ness verlieren (oder was anderes).

Wobei das hier normal funktioniert (auf beiden Compilern)
https://godbolt.org/z/UhRVQ8 (da kann man sich in der Fehlermeldung den Typen angucken)

Verfasst: **31.10.2018, 15:22**

Ich bin mir nicht 100 % sicher, ob & in Constant Expressions erlaubt ist – ich muss es an dieser Stelle aber nutzen, weil der „normale“ Array-to-Pointer Decay Visual C++ kaputtmacht (das war der vorausgegangene Bug Report).

Falls & an der Stelle nicht erlaubt ist, sollte GCC aber auf jeden Fall einen entsprechenden Fehler melden, statt den Typ zu verkacken … (und VCpp natürlich ebenso – aber das wird sich im Verlauf des entsprechenden Bug Reports klären.)

Verfasst: **01.11.2018, 10:25**

WTF?

Gerade bei laufendem YouToube Video Windows neugestartet (also wahrscheinlich eher dieses Soft-Restart von den neuere Windowsen) und nach dem Restart höre ich im Login-Screen im Hintergrund das Video weiterlaufen, bevor ich das Passwort eingegeben habe. Nach Login komme ich zum laufenden Video.

Ich würde es mir selbst nicht glauben, aber ich bin sehr sicher, dass genau das passiert ist.

Das ist doch offensichtlich ein himmelschreiendes Security-Problem.

Verfasst: **01.11.2018, 15:56**

Inwiefern?

(Und, weil ein Kollege sich letztens auch gewundert hat, die Erklärung: )

1. Windows hat seit Vista den sog. Restart Manager. Programme kriegen in Win32 zwar grundsätzlich mit, wenn die Session endet, aber der Restart Manager ist eine API, an der sich Programme anmelden können, damit das System sie nach einem Neustart erneut startet, mit den selben Rechten. Idealerweise stellen sie dabei exakt den Zustand von zuvor wieder her. (Die größte Verbesserung ist, dass der Restart Manager als Teil des Windows Installers bei jeder Software-Installation und jedem Update auflistet, ob noch Programme auf die Zieldateien zugreifen, sie freundlich beendet und nach der Installation im selben Zustand neu startet – du kannst deshalb seit Vista etwa Explorer-Erweiterungen installieren, ohne das System danach neu starten zu müssen, weil der Explorer nur kurz zwischendurch soft abgeschossen und neu gestartet wird.)

2. Windows 10 muss letztens eingeführt haben, dass der User bei einem Neustart nicht mehr ausgeloggt ist. Nach dem Neustart starten die gleichen Sessions wie vorher neu und Windows zeigt den Sperrbildschirm statt des Login-Bildschirms. (Habe ich über Logs meiner Dienste geprüft.) Da Chrome Restart Manager-kompatibel ist, hat dein Video an der selben Stelle fortgesetzt und du hast es im Hintergrund gehört – als wenn du das Video laufen lässt und den Computer sperrst. Ich gehe davon aus, dass die Sperren-statt-Login-Änderung dafür da ist, die Neustartzeit zu drücken – so lädt die Session im Hintergrund, während der User noch sein Passwort eintippt. Und andere User verlieren nicht so viele Daten, wenn einer den Computer neu startet, während sie noch eingeloggt sind.

Eine Sicherheitslücke erkenne ich da nicht. Du warst vor dem Neustart eingeloggt und bist es danach eben wieder (und musst immernoch dein Passwort eingeben, um auf irgendwas zugreifen zu können). Die Prozesse, die da laufen, sind die gleichen wie vor dem Neustart.

(Ich will das nicht verteidigen; ich empfand das als arg unintuitiv. Aber die Vorteile bei der Boot-Zeit sind kaum von der Hand zu weisen.)

Verfasst: **01.11.2018, 17:17**

Danke für die Erklärung. Ich hatte in der Tat implizit auf deine Expertise gehofft.

1) War mir aus Beobachtungen im Wesentlichen wenn auch nicht im Detail klar. Stört mich nicht, ist praktisch.

2) Ist das Problem. Ich erwarte, dass ein Herunterfahren des Rechners den User ausloggt und ich erwarte, dass der User nicht ohne Passwort wieder eingeloggt wird. Und sei es nur aus Gewohnheit. Ich erwarte nicht, dass sich das einfach mal "letzens" ändert. Weißt du zufäliig ob man das irgendwo umschalten kann?

Zu "Inwiefern?":

a) Das Szenario was sich sofort aufdrängt ist, dass Alice in der Erwartung, dass Windows sich wie "früher" verhält mitten in einem Rick Astley Song Reboot drückt und den Raum verlässt. Bob betritt den Raum und wird rickrolled. Wahrscheinlich ist Alice Privacy-Problem größer als Bobs Security-Problem an der Stelle, ich will jetzt nicht an Begriffen festhalten.

b) Ich weiß nicht genau wie transparente HDD Verschlüsselung (Bitlocker ...) funktioniert und wie es mit diesem Feature interagiert (war hier nicht aktiv), aber ich erwarte, dass Windows ohne Passwort nichts von der Festplatte rausgibt. Auch nicht den RAM Inhalt von vor dem Reboot. Eigentlich ist das nicht wirklich ein neuer Punkt im Vergleich zu 2) oben. Ich bin der Meinung (vielleicht irrational?) dass man nicht davon ausgehen darf, dass alle die vor dem Restart authentifiziert waren es nachher immer noch sind.

c) Normalerweise müsste "ausgeloggt" mindestens minimal sicherer sein als "gesperrt" und sei es nur, weil -- darauf zielt auch b) ab -- keine Daten des Users im RAM liegen dürften. Wenn der Browser nicht läuft kann ein Angreifer nicht sehen, dass er läuft, selbst wenn der Angreifer sonst alles überwinden könnte.
Weiterer Punkt aus dieser Kategorie: Nur weil Login und Lock im UI gleich aussehen, bin ich nicht überzeugt, dass sie von denselben Leuten mit der selben Sorgfalt und demselben Fokus auf Security geschrieben wurden. Der XScreensaver-Typ (?) hatte mal was dazu, wie man das verhauen kann, wenn ich mich recht erinnere. Ist vielleicht auch nur gefühlte Sicherheit, keine Ahnung.

Verfasst: **01.11.2018, 20:36**

Natürlich ist das ein himmelschreiendes Sicherheitsproblem, denn es muss ja kein harmloser Popsong sein, der da wiedergegeben wird, es kann sich ja auch um sicherheitskritische Audiodaten handeln. Wozu gibt es denn Useraccounts und PWs, wenn vor der PW-Eingabe Windows Infos über den Account an den nichtangemeldeten Nutzer leakt?

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread