Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.

Re: Jammer-Thread

Beitragvon Krishty » 11.02.2018, 17:43

Chrome hat immer „Extensions” für Google Docs & Co. mitinstalliert.

Ich habe sie jedes Mal deinstalliert.

Nun machen sie das gleiche wieder, nur nennen sie es „Apps“.

Ich will nicht, dass YouTube/Gmail im Hintergrund weiterläuft oder erweiterten Zugriff auf meinen Browser hat. Fuck this shit. Daher eine Bitte an euch:

  1. Gebt in die Adresszeile chrome://apps/ ein

  2. Rechtsklick auf jede App außer dem Web Store (den man nicht deinstallieren kann, verdammte Ficker)

  3. Remove from Chrome…

  4. Wenn ihr gefragt werdet, ob ihr das wirklich wollt, setzt den Haken bei Report Abuse

  5. Ihr werdet zur Beschwerdeseite weitergeleitet

  6. Wählt dort als Beschwerdegrund I never wanted this app and I don’t know how it was installed

  7. Teilt optional via Kommentar mit, was ihr davon haltet

  8. Füllt fünf Captchas aus, damit ihr auch genau wisst, wie wertvoll Google eure Meinung ist und damit sie euch selbst dabei noch ausnutzen können
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Goderion » 11.02.2018, 19:03

Ich konnte gerade in Visual Studio 2015 keine Release-Version mehr von meinen Projekt erstellen. Eine Lib konnte nicht geöffnet werden. Ok. Was? ...
Den ganzen Tag nur am Sourcecode/Dateien gearbeitet, nix am Projekt/Einstellungen etwas verändert. Ich gucke mir die .lib an, die er nicht öffnen kann und WTF... 2,14 GB (2.303.231.034 Bytes) ?!
Wieso ist die so riesig?! Für die Release-Version werden insgesamt mit allen Projekten über 7 GB erzeugt!! Was zum... ?!
Visual Studio 2015 kann die Lib wohl nicht öffnen, da der Linker ein 32Bit-Prozess ist und die vermutlich komplett laden will, was aufgrund der Größe nicht geht.
Ok... NARF... googlen wir mal.... 20 Minuten später nix zufriedenstellendes gefunden... einfachste Lösung das betroffene Projekt aufteilen... eeeh...

Gut, probieren wir Visual Studio 2017, wovon ich mir zum Glück vor ein paar Wochen eine Iso erstellt habe, da Microsoft die warum auch immer nicht mehr selber zur Verfügung stellt.
Ich habe Glück, beim Kompilieren bekomme ich zwar folgende Meldung ...
Code: Ansicht erweitern :: Alles auswählen
3>LINK : Der 32-Bit-Linker (C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\bin\HostX86\x86\link.exe) konnte auf "D:\Engine\Release\ObjectDefinition2.lib" keine E/A für dem Arbeitsspeicher zugeordnete Dateien durchführen. Die Verknüpfung wird mit einem 64-Bit-Linker neu gestartet, um einen besseren Durchsatz zu erzielen.
3>LINK : In %PATH% konnte kein 64-Bit-Linker gefunden werden. Die aktuelle Verknüpfung wird fortgesetzt.
3>Code wird generiert.
... aber die fertig .exe funktioniert einwandfrei.

Jetzt weiß ich auch, warum das Kompilieren so Ewigkeiten dauert. Wenn ich das richtig verstanden habe, versucht er in der .lib alle erdenklichen Situationen zu integrieren mit einem Haufen zusätzlicher Infos, damit sich der Linker nur das raus ziehen kann, was er wirklich braucht. Fast 4 GB .lib-Files und die .exe ist am Ende gerade mal 3 MB groß. Jemand eine Idee, wie ich das optimieren kann.
Das Grundproblem verstehe ich ja, die .lib weiß zu ihrer Erstellung nicht, was wirklich gebraucht wird und packt einfach ALLES rein. Die .lib brauche ich eigentlich nicht, bzw. wird nur in dieser einen Projektgruppe genutzt. Rein praktisch könnte ich alles in ein Projekt packen, aber das wäre zu unübersichtlich und daher habe ich das auf verschiedene Projekte verteilt. Natürlich auch für bessere Kompilierzeiten, eigentlich.
Benutzeravatar
Goderion
 
Beiträge: 82
Registriert: 16.09.2012, 12:02

Re: Jammer-Thread

Beitragvon dot » 11.02.2018, 23:11

Goderion hat geschrieben:IJemand eine Idee, wie ich das optimieren kann.

Was ist denn in dieser .lib alles drin? xD
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1646
Registriert: 06.03.2004, 19:10

Re: Jammer-Thread

Beitragvon Schrompf » 11.02.2018, 23:47

Könnte man abspalten, aber:

es gibt sicher auch für Visual Studio eine Variante von objdump. Damit kannst Du nachschauen, welche Symbole in Deiner Lib exportiert werden. Da ich es für unmöglich halte, mit handgeschriebenem Code auf solche Größen zu kommen, vermute ich, dass Du irgendwie fünftausend Instanzen eines Templates indirekt exportierst oder dass Du irgendein fies großes globales Datenarray exportierst.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3747
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: Jammer-Thread

Beitragvon Goderion » 12.02.2018, 00:47

dot hat geschrieben:
Goderion hat geschrieben:IJemand eine Idee, wie ich das optimieren kann.

Was ist denn in dieser .lib alles drin? xD

In der .lib befinden sich die Definitionen/Strukturen für die Objekte, Komponenten, Level, usw..

Schrompf hat geschrieben:Könnte man abspalten, aber:

es gibt sicher auch für Visual Studio eine Variante von objdump. Damit kannst Du nachschauen, welche Symbole in Deiner Lib exportiert werden. Da ich es für unmöglich halte, mit handgeschriebenem Code auf solche Größen zu kommen, vermute ich, dass Du irgendwie fünftausend Instanzen eines Templates indirekt exportierst oder dass Du irgendein fies großes globales Datenarray exportierst.

Ich habe in den letzten Tagen/Wochen das Objektsystem stark verändert und viele Klassen/Strukturen basieren jetzt auf Templates (erben von Templates). Ich konnte dadurch die Entwicklung/Programmierung neuer Klassen stark beschleunigen und sogar ein wenig die Performance steigern (stark VTables reduziert, kaum noch virtual Delete(), usw.). Je mehr ich auf Templates umgestellt habe, desto langsamer wurde auch das Kompilieren, besonders im Release-Mode.

Auf jeden Fall komplett Banane. Ich habe hier eine Klasse, die von einem Template erbt, die Klasse hat keine 2 Seiten Quellcode (.h + .cpp), aber die .obj-File ist 17 MB groß. Ich suche gerade nach einer Möglichkeit zu gucken, was da alles drin sein soll.
Benutzeravatar
Goderion
 
Beiträge: 82
Registriert: 16.09.2012, 12:02

Re: Jammer-Thread

Beitragvon MasterQ32 » 12.02.2018, 10:06

Mal nen Schuss ins Blaue: Hast du inkrementelles Linken an? Wenn ja: Mach mal aus, mach nen Rebuild und guck, was dabei rauskommt...
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1175
Registriert: 07.10.2012, 14:56

Re: Jammer-Thread

Beitragvon Goderion » 12.02.2018, 14:41

Ich habe das Projekt mit der riesigen .lib in Mehrere aufgeteilt, und jetzt läuft alles wieder auch in Visual Studio 2015.

Visual Studio hat das Tool dumpbin.exe mit dabei, damit kann ich mir die Symbole usw. von .libs angucken. Selbst mit einer "kleineren" .lib von 700 MB explodiert die Konsole, Ewigkeiten wird etwas ausgegeben. 11934 public symbols werden angezeigt. Templates ohne Ende. Sieht aus, als würde jeder Furz in allen Variationen erstellt worden.

Ich kompiliere im Release-Mode immer mit /GL - Optimierung des gesamten Programms. Wenn ich das ausschalte, schrumpfen die .libs von 7 GB auf ca. 500 MB.

Ich werde aber wohl auf Visual Studio 2017 umsteigen, da die Release-Version leicht schneller ist (von 335 FPS auf 350 FPS).
Am Anfang bekam ich gelegentlich komische Fehler, z.B. musste ich zwei mal das Plattformtoolset "Visual Studio 2017 - Windows XP (v141_xp)" installieren und hin und wieder ist es wieder weg und erst nach einem Neustart von Visual Studio 2017 wieder da... he? :? (VS 2017 bereits aktualisiert)

MasterQ32 hat geschrieben:Mal nen Schuss ins Blaue: Hast du inkrementelles Linken an? Wenn ja: Mach mal aus, mach nen Rebuild und guck, was dabei rauskommt...

Statische Bibliotheken (.lib) haben in Visual Studio 2015/2017 keine Linker Einstellungen. Nur das Hauptprojekt in der Projektgruppe, welches die .exe erstellt, hat diese Einstellungen und dort ist inkrementelles Linken bereits deaktiviert.
Benutzeravatar
Goderion
 
Beiträge: 82
Registriert: 16.09.2012, 12:02

Re: Jammer-Thread

Beitragvon Krishty » 13.02.2018, 00:29

d3d9.dll!CD3DDDIDX8::UpdateDirtyStreams()
Entweder stottern die DirectX-Entwickler, oder sie stehen auf dicke Titten.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 13.02.2018, 04:15

Media Player Classic, der mit Abstand beste Player, ist tief im Ansehen gesunken weil er bei Crashes automatisch Dr. Dump kontaktiert: https://trac.mpc-hc.org/ticket/5450

Command Line ist Nonsens. Wenn ich auf eine Datei doppelklicke, kann ich keinen Parameter übergeben. Da müsste ich in die Registry und an die 100 ProgIDs ändern.

CrashReporter-Verzeichnis löschen ist schön und gut, wenn man weiß, dass sowas verbaut ist.

Eine Setup-Option wäre das Minimum.

Oh, und: man kann bei Dr Dump keine Kommentare hinterlassen, ohne sich zu registrieren. Ich weiß, warum der MPC abgestürzt ist (ich hatte die D3D Debug Runtime eingeschaltet, und die hat beim Schließen ein harmloses Speicherleck gemeldet), aber ich kann’s nicht mitteilen. Eigentlich gut so: Wer meine Crash Dumps klaut, hat es auch verdient, Lebenszeit sinnlos damit zu verschwenden. Eigentlich sollte ich den jetzt noch 100 weitere Male abstürzen lassen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Chromanoid » 13.02.2018, 19:23

Nachtrag zu Chrome und Unterstreichungen: Ich glaube ich war da mit meinen Anschuldigungen etwas voreilig :) Verschiedene W3C-Gremien haben sich da schon länger Gedanken drüber gemacht. Es ist einfach Zufall, dass das erst jetzt bei Chrome eingeführt wurde... Naja, ich halte es weiterhin für problematisch und war mit dem alten Aussehen zufriedener.
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3720
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: Jammer-Thread

Beitragvon Krishty » 14.02.2018, 15:45

Bei Visual C++ kollidieren die temporären Dateien, wenn man sowohl foo.cpp als auch foo.c im Projekt hat.

> 2018
> Programme, die auf richtige Dateierweiterungen vertrauen
> idontwanttoliveonthisplanetanymore.mov
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon kaiserludi » 14.02.2018, 17:44

Also ich habe sogar mehrere .cpp Dateien mit komplett identischem Dateinamen in der Solution und das hat noch keiner IDE Probleme bereitet, auch nicht VS, allerdings liegen die Dateien in unterschiedlichen Projekten, die zu unterschiedlichen statischen Bibliotheken kompilieren, welche aber wiederum durchaus am Ende zur gleichen .exe gelinkt werden.
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:
kaiserludi
Establishment
 
Beiträge: 458
Registriert: 18.04.2002, 15:31

Re: Jammer-Thread

Beitragvon B.G.Michi » 14.02.2018, 20:18

QtCreator und qmake vertragen das auch nicht... -.-'
Benutzeravatar
B.G.Michi
Establishment
 
Beiträge: 160
Registriert: 07.03.2006, 21:38
Alter Benutzername: B.G.Michi

Re: Jammer-Thread

Beitragvon Krishty » 17.02.2018, 13:38

1. extern "C" unterdrückt Name Mangling.

Geil! Ich kann endlich auf die exports.def in meinem Projekt verzichten!

(später) Irgendwas stimmt mit der 32-Bit-Version nicht …

2. extern "C" unterdrückt Name Mangling, so lange die Calling Convention nicht __stdcall ist.

WTF, das hat aber doch hier funktioniert?! Sogar mit __stdcall, da bin ich mir sicher!

3. extern "C" unterdrückt Name Mangling, so lange die Calling Convention nicht __stdcall ist, oder sofern die Calling Convention __stdcall ist und Debug-Information abgeschaltet ist.

IST DAS HIER VERSTECKTE KAMERA ODER WAS
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon dot » 17.02.2018, 20:22

Dass extern "C" irgendwas mit Name Mangling zu tun hätte, ist leider ein weit verbreiteter Irrtum. extern "C" ist eine linkage-specification, die besagt, dass die jeweils deklarierte Entität C language linkage haben soll. Effektiv heißt das einfach, dass sie entsprechend dem C ABI der jeweiligen Plattform übersetzt werden soll. Auf Windows gibt's wegen der ganzen verschiedenen Calling Conventions auch in der C ABI Name Mangling...
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1646
Registriert: 06.03.2004, 19:10

Re: Jammer-Thread

Beitragvon Krishty » 17.02.2018, 20:35

dot hat geschrieben:Dass extern "C" irgendwas mit Name Mangling zu tun hätte, ist leider ein weit verbreiteter Irrtum.
Nein ist es nicht. Es mag nicht dafür spezifiziert sein, aber auf Windows und mit Ausnahme der __stdcall-Extraregelung tut es unter anderem genau das.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon dot » 17.02.2018, 21:23

Krishty hat geschrieben:
dot hat geschrieben:Dass extern "C" irgendwas mit Name Mangling zu tun hätte, ist leider ein weit verbreiteter Irrtum.
Nein ist es nicht. Es mag nicht dafür spezifiziert sein, aber auf Windows und mit Ausnahme der __stdcall-Extraregelung tut es unter anderem genau das.

Es gibt keine "__stdcall-Extraregelung". Auf 32-Bit Windows hast du auch mit extern "C" immer Name Mangling (siehe vorhin verlinkter MSDN Artikel). Auf 64-Bit Windows gibt es in der C ABI kein Name Mangling weil es dort nur eine Calling Convention gibt (von __vectorcall mal abgesehen)...

Code: Ansicht erweitern :: Alles auswählen
extern "C"
{
        void f() {}

        void __cdecl a() {}

        void __stdcall b() {}

        void __fastcall c() {}

        void __vectorcall d() {}
}

dumpbin /symbols bla.obj

Code: Ansicht erweitern :: Alles auswählen
029 00000000 SECTA notype () External | _f
02A 00000000 SECT6 notype () External | _a
02B 00000000 SECT8 notype () External | _b@0
02C 00000000 SECT4 notype () External | @c@0
02D 00000000 SECTC notype () External | d@@0
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1646
Registriert: 06.03.2004, 19:10

Re: Jammer-Thread

Beitragvon Krishty » 17.02.2018, 22:05

Verdammt; ich vergaß, dass wir hier über exportierte Funktionen sprechen. Das konntest du nicht wissen, ja. Tut mir leid.

Also, einigen wir uns auf: Es unterdrückt das Name Mangling bei __cdecl. In einer DLL kommen deine Funktionen als f, a, _b@0, @c@0, d@@0 an.

Übrigens fügt dumpbin Dekoration hinzu. Die Unterstriche in _f und _a in deinem Dump existieren nicht wirklich. Das ist kein Witz, sondern Raymond Chen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon dot » 18.02.2018, 22:14

Krishty hat geschrieben:Also, einigen wir uns auf: Es unterdrückt das Name Mangling bei __cdecl. In einer DLL kommen deine Funktionen als f, a, _b@0, @c@0, d@@0 an.

Ich bin dem Ganzen jetzt mal genauer nachgegangen und ich würde sagen: Was wirklich passiert ist, dass der Linker für per /EXPORT angegebene C ABI Symbole den undekorierten Namen als Name für den Export verwendet. Die Symbole selbst haben aber immer einen mangled Name!

Testcode:
Code: Ansicht erweitern :: Alles auswählen
__declspec(dllexport) int x;

__declspec(dllexport) void __cdecl f() {}

extern "C"
{
        __declspec(dllexport) int y;

        __declspec(dllexport) void __cdecl a() {}

        __declspec(dllexport) void __stdcall b() {}

        __declspec(dllexport) void __fastcall c() {}

        __declspec(dllexport) void __vectorcall d() {}
}


Krishty hat geschrieben:Übrigens fügt dumpbin Dekoration hinzu. Die Unterstriche in _f und _a in deinem Dump existieren nicht wirklich. Das ist kein Witz, sondern Raymond Chen.

Nope. Wenn nicht auch noch sämtliche File Editoren und/oder File System Driver oder so kollektiv an der Verschwörung beteiligt sind, dann sind die Underscores definitiv in der Symboltable des vom Compiler ausgespuckten Object File enthalten (egal ob dllexport oder nicht):
Untitled.png

Erst wenn ich dieses Object File zu einer DLL linke, werden für die Exports dann andere Namen verwendet. Aus dem Compiler aber kommen der C Linkage entsprechend mangled Names raus (im Release nur mit /GL- sichtbar da sonst keine COFF Symbole vom Compiler generiert werden). Erst der Linker entscheidet sich offenbar, für bestimmte Symbole den unmangled Name in die Export Table einzutragen.

Der Output von link /dump /exports (und auch dumpbin /exports, was offenbar das gleiche zu sein scheint) sieht mittlerweile übrigens so aus:
Code: Ansicht erweitern :: Alles auswählen
1 0 00011136 ?f@@YAXXZ = @ILT+305(?f@@YAXXZ)
2 1 00018138 ?x@@3HA = ?x@@3HA (int x)
3 2 000110FF @c@0 = @ILT+250(@c@0)
5 3 000110E1 _b@0 = @ILT+220(_b@0)
4 4 0001102D a = @ILT+40(_a)
7 5 00011069 d@@0 = @ILT+100(d@@0)
6 6 0001813C y = _y
Da wird mittlerweile also nicht mehr "geschummelt" sondern einfach das Mapping von Export auf Symbol angezeigt :). Wenn man die .pdb Files löscht, dann zeigt es die originalen Symbolnamen in der Tat nicht mehr an.

__declspec(dllexport) tut effektiv nix anderes als ein entsprechendes /EXPORT Argument in die Linker Commandline zu packen:
Untitled2.png


Zusammengefasst würde ich sagen, dass es bei meiner ursprünglichen Aussage bleibt: extern "C" schaltet nicht das Name Mangling ab sondern übersetzt lediglich nach C ABI statt nach C++ ABI (hab das Ganze auch noch ohne extern "C" direkt mit dem C Compiler getestet, dort ist das Verhalten exakt das gleiche). Was es gibt ist eine Extraregelung für den Export von C ABI __cdecl Funktionen im Linker. Das ist dann aber effektiv aber auch genau so dokumentiert: https://docs.microsoft.com/en-gb/cpp/cp ... -dllimport
MSDN hat geschrieben:No name decoration is applied to exported C functions or C++ extern "C" functions using the __cdecl calling convention.
Zuletzt geändert von dot am 18.02.2018, 22:19, insgesamt 1-mal geändert.
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1646
Registriert: 06.03.2004, 19:10

Re: Jammer-Thread

Beitragvon Krishty » 18.02.2018, 22:18

Alles klar; danke dafür! Hast du noch eine Erklärung, warum bei Exporten das Mangling verschwindet, wenn Debug-Informationen abgeschaltet sind?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon dot » 18.02.2018, 22:21

Sicher dass das nur an den Debug Infos liegt? Wenn du Release mit Whole Program Optimization baust, dann enthalten Object Files keinen Maschinencode und keine COFF Symbole, weil die Code Generation ja in den Linker verschoben wird...
Benutzeravatar
dot
Michael Kenzel
Establishment
 
Beiträge: 1646
Registriert: 06.03.2004, 19:10

Re: Jammer-Thread

Beitragvon Krishty » 18.02.2018, 22:54

Ah, der Wind weht anders. In dem StackOverflow-Thread hatte sich jemand beschwert, dass er mit dumpbin immer nur dekorierte Namen in seiner DLL sieht. Abschalten der Debug-Informationen bewirkt ein Löschen der PDB, und dann zeigt dumpbin die undekorierten Exporte, weil es keine PDB mehr findet.

Es ging da also die ganze Zeit nur um dumpbin, nicht um die tatsächlich exportierten Funktionen …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 19.02.2018, 16:19

Visual C++ 15.5.1 hatte einen Bug, der den Optimizer in einer Endlosschleife festhielt. Es hat ein Bisschen gedauert, einen exakten Repro zu finden, aber hier ist er:

https://developercommunity.visualstudio ... n-con.html

Der Optimizer hing, wenn eine Schleife dem Limit ihres Zählers zu nahe kam. Das wurde ungefähr zur gleichen Zeit eingeführt wie, dass der Optimizer undefinierte Integer-Overflows ausnutzt.

An alle Undefined Behavior-Fans: Das könnte tatsächlich ein Fall gewesen sein, in dem Undefined Behavior bedeutete, dass der Compiler alles hinschmeißt und man nicht mehr weiterprogrammieren kann :D Vielleicht ja jemand die 15.5.1er-Version herunterladen und das tatsächlich erreichen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Tiles » 23.02.2018, 11:46

git did not exit cleanly (exit code 128)

Und ich hatte nichts geändert. Und nichts hilft. Ich kann weder ein neues Repo klonen, noch mein eigenes updaten. Vermutlich habe ich es jetzt eher noch schlimmer gemacht mit meinen Versuchen das zu fixen. Das Lustige ist, auf meinem Laptop geht alles. Nur auf meinem Desktop streikts. Bin grade komplett ratlos :(

EDIT, die Jungs auf Github haben wohl irgendwas abgeschaltet was ich verwende. February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms.

https://githubengineering.com/crypto-removal-notice/

Aber kein Wort was ich da jetzt machen soll. Und wieso merke ich das erst dadurch dass es nimmer geht? Und so richtig spassig ist ja dass es auf meinem Lappy tadellos geht. Mit den alten Dingern. Github. Danke Jungs, habta toll hinbekommen -.-
Free Gamegraphics, Freeware Games http://www.reinerstilesets.de
Die deutsche 3D Community: http://www.3d-ring.de
Benutzeravatar
Tiles
Establishment
 
Beiträge: 1221
Registriert: 11.01.2003, 14:21

Re: Jammer-Thread

Beitragvon Biolunar » 23.02.2018, 13:19

Tiles hat geschrieben:git did not exit cleanly (exit code 128)

Und ich hatte nichts geändert. Und nichts hilft. Ich kann weder ein neues Repo klonen, noch mein eigenes updaten. Vermutlich habe ich es jetzt eher noch schlimmer gemacht mit meinen Versuchen das zu fixen. Das Lustige ist, auf meinem Laptop geht alles. Nur auf meinem Desktop streikts. Bin grade komplett ratlos :(

EDIT, die Jungs auf Github haben wohl irgendwas abgeschaltet was ich verwende. February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms.

https://githubengineering.com/crypto-removal-notice/

Aber kein Wort was ich da jetzt machen soll. Und wieso merke ich das erst dadurch dass es nimmer geht? Und so richtig spassig ist ja dass es auf meinem Lappy tadellos geht. Mit den alten Dingern. Github. Danke Jungs, habta toll hinbekommen -.-

Was für eine Steinzeitsoftware verwendet noch TLS 1.0 oder 1.1 bei dir?
Benutzeravatar
Biolunar
Establishment
 
Beiträge: 128
Registriert: 27.06.2005, 17:42
Alter Benutzername: dLoB

Re: Jammer-Thread

Beitragvon Tiles » 23.02.2018, 13:28

Wenn ich das wüsste wäre ich nicht so am fluchen. Ich habe da Tortoisegit hinten dran hängen. Vermutlich das. Aber ich habe auch auf meinem Lappy Tortoisegit hinten dran. Und da tuts. Und schon das einfache klonen mit Git hat gemeckert. Also ist es wohl ein Git Problem.

Im Moment versuche ich Git und Tortoisegit sauber zu deinstallieren. Und bin zumindest mal den TLS Error losgeworden. Nun ist es von der Git Konsole nur noch der 128er, ohne irgendeinen Hinweis wo es klemmt. Da müssen also noch irgendwo alte Settings rumgammeln. In der Registry oder in den Userprefs, oder was weiss ich wo. Ich habe sogar gitconfigs in meinem C:\User\ Ordner gefunden. Das Vieh verewigt sich wirklich systemweit. Und ich muss immer noch rausfinden wo Tortoisegit immer wieder seine Credentials Einstellungen herzaubert. Und meinem Repo fehlen auch grade die grünen Symbole. Sehr nice alles grade ^^

Uninstaller ohne die Möglichkeit auch die Programm-Settings zu entsorgen sind jedenfalls gruselig -.-
Free Gamegraphics, Freeware Games http://www.reinerstilesets.de
Die deutsche 3D Community: http://www.3d-ring.de
Benutzeravatar
Tiles
Establishment
 
Beiträge: 1221
Registriert: 11.01.2003, 14:21

Re: Jammer-Thread

Beitragvon Krishty » 27.02.2018, 18:00

Warum zur Hölle macht Microsoft mit jedem Visual Studio-Update Dinge kaputt, die früher mal funktionierten? Aktuell ist es das Tippen(!).

Sagen wir, ich habe diesen Text:

  Bezeichner();

Nun möchte ich vor den Anfang Foo:: tippen. Ich tippe also …

  Foo:|Bezeichner();
      ^ Caret ist hier


wenn ich nun den zweiten Doppelpunkt tippe, ändert sich der Text sofort zu:

  FooBezeichner::|();
                 ^ Caret ist plötzlich hier; Doppelpunkte sind weggesprungen; WTF


Das beste: Ich habe die ganze Autokorrektur-Grütze abgeschaltet, der Editor darf also gar nichts an meinem Quelltext ändern. Es nervt mich. Es nervt, dass Visual C++ was anderes hinschreibt als ich mit der Tastatur vorgebe. Es nervt, dass das nur manchmal passiert. Es nervt, dass mit jedem Update neue nervige Bugs kommen. Es nervt, nervt, nervt, nervt.

Nachtrag: Microsoft fährt seit Windows 8 eine extreme Gleichmachereipolitik. Man soll alle ihre Programme nur noch in der Standardeinstellung nutzen – weil das den Testaufwand reduziert. Darum setzt Windows 10 auch nach Updates alle Einstellungen zurück. Das Ergebnis ist seit Jahren sinkende Qualität ihrer Software, wenn man mal doch irgendwo eine Einstellung ändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 07.03.2018, 01:07

Wenn ich eine Funktion __vectorcall deklariere, und dann Datentypen à __m128 by-value übergebe, kann ich im Visual Studio Debugger nicht ihre Werte sehen.

Da ist immer nur m128_f32=0xcccccccccccccccc { ??? ??? ??? ??? }.

Es nervt mich seit Jahren. Ich muss dauernd lokale Kopien meiner Parameter anlegen, damit ich überhaupt debuggen kann.

Dazu gibt es keinen Bug Report. In all den Jahren nicht. Bin ich der einzige, bei dem das passiert?!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon Krishty » 07.03.2018, 01:13

MSDN – WriteFile function hat geschrieben:nNumberOfBytesToWrite [in]
The number of bytes to be written to the file or device.

A value of zero specifies a null write operation. The behavior of a null write operation depends on the underlying file system or communications technology.
Für manche Communications Technologies bedeutet dieser Satz: „Wird eine Exception im Kernel auslösen und das Programm zum Absturz bringen, falls ihr nicht drauf vorbereitet seid“ oder wird niemals gelingen.

Falls ihr einen Wrapper für WriteFile() habt, solltet ihr den nun öffnen und bei Nullgröße vorzeitig zurückkehren lassen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: Jammer-Thread

Beitragvon DerAlbi » 07.03.2018, 01:34

Hmmh. Es ist aber wirklich geräteabhängig... es ist gut möglich, dass man da im Treiber etwas hat, was auf 0 mit Spezialverhalten reagiert (flush, hardware handshake und zeugs), evtl ein leerer HID-USB-Transport also Kommando an ein HID oder so.
Zumindest gibt es einen Grund, warum die bei MS da eine 0 zulassen wollten. Es generell zu blocken würde ich auch der Ebene oben drüber überlassen.
DerAlbi
Establishment
 
Beiträge: 226
Registriert: 20.05.2011, 05:37

VorherigeNächste

Zurück zu Allgemeines Talk-Brett

Wer ist online?

Mitglieder in diesem Forum: Majestic-12 [Bot] und 3 Gäste