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: 6193
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: 75
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: 1612
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: 3640
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: 75
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: 1029
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: 75
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: 6193
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: 6193
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: 3665
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: 6193
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: 451
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: 6193
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: 1612
Registriert: 06.03.2004, 19:10

VorherigeNächste

Zurück zu Allgemeines Talk-Brett

Wer ist online?

Mitglieder in diesem Forum: Ahrefs [Bot], Bing [Bot] und 1 Gast