Jammer-Thread

[Jonathan]

CMake :(

Code: Alles auswählen

if(CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT APPLE)

[Jonathan]

Code: Alles auswählen

else (WIN32)
	if ( USING_GNU_C AND NOT APPLE)
		set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DM_PI=3.14159265358979323846" )

Jetzt werden also schon CMake-Skripte benutzt um den Wert von \($\pi$\) festzulegen? Das kann doch einfach niemand mehr für eine gute Idee halten, oder?

[dot]

Nun, das Problem fangt in dem Moment an, wo CMake benutzt wird... :P

[Jonathan]

Ich mach hier einfach mal weiter...

Code: Alles auswählen

# This enforces a particular version of CMake that we require to process the script files
# properly.
cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR)

# As of CMake 2.6 policies were introduced in order to provide a mechanism for
# adding backwards compatibility one feature at a time.  We will just specify
# that all policies will use version 2.6 symantics.
cmake_policy(VERSION 2.6)

Ich bin mir nicht 100%ig sicher, aber ich glaube, die haben gerade erst explizit mindestens Version 2.8 verlangt, nur um direkt danach in den Kompatibilitätsmodus zu 2.6 zu schalten. Egal was für einen obskuren Grund es dafür auch geben mag, sollte man doch trotzdem irgendwie einsehen, dass das keine Gute Lösung sein kann...

[dot]

Egal was für einen obskuren Grund es dafür auch geben mag, sollte man doch trotzdem irgendwie einsehen, dass das keine Gute Lösung sein kann...

Du musst bedenken: Die verwenden schon CMake, damit isses eigentlich eh schon egal... :P

[Chromanoid]

RoboVM Winding Down https://robovm.com/robovm-winding-down/

Ich hab's nie benutzt, fand aber die Technologie spannend. Schon echt ne klassische Tech-Geschichte, Xamarin kauft RoboVM, Microsoft kauft Xamarin, RoboVM wird abgesägt.

[Krishty]

Nachtrag zu der lokale-Variablen-teilen-sich-Speicher-Geschichte von letztens:

Ist es also vielleicht ein anderweitig nützliches Detail der Implementierung, was die o. g. Invarianz zerstört? Sprich: ein Trade-Off?

Vielleicht haben sie das so gemacht weil ihnen sonst einfach zu viel Code kaputtgeht. Hier ist Quelltext aus dem Microsoft-Beispiel, wie man einen Shell Handler für Thumbnail-Erzeugung registriert:

Code: Alles auswählen

if (*pszFileType == L'.')
{
    wchar_t szDefaultVal[260];
    hr = GetHKCRRegistryKeyAndValue(pszFileType, NULL, szDefaultVal, 
       sizeof(szDefaultVal));

    // If the key exists and its default value is not empty, use the 
    // ProgID as the file type.
    if (SUCCEEDED(hr) && szDefaultVal[0] != L'\0')
    {
       pszFileType = szDefaultVal;
    }
}

// Create the registry key 
// HKCR\<File Type>\shellex\{e357fccd-a995-4576-b01f-234630154e96}
hr = StringCchPrintf(keyPath, ARRAYSIZE(keyPath), 
    L"%s\\shellex\\{e357fccd-a995-4576-b01f-234630154e96}", pszFileType);

Beobachtet mal genau, was mit dem Inhalt von szDefaultVal passiert sein könnte, sobald er in der letzten Zeile durch pszFileType in den String geschrieben wird.

Da graust es einen echt, denn sicher ein Viertel aller Thumbnail Handlers auf diesem Planeten wurde nach diesem Beispiel gebaut. Der Code ist ganz klar kaputt, aber Visual C++ warnt nicht. Vielleicht hatten sie die Optimierung an irgendeiner Stelle eingebaut; dann in ihren Tests zwanzigtausend Abstürze wegen Müll in Variablen gekriegt (schließlich wird ganz Windows mit Visual C++ kompiliert, und da kommt Code wie oben sicher öfter vor), und das vertagt, bis sich die Code-Qualität verbessert hat.

[Alexander Kornrumpf]

Erscheckend plausibel. Vielleicht wäre es besser, wenn man Pointer in den Stack grundsätzlich nur zum Zweck der Parameterübergabe kopieren dürfte?!

[Spiele Programmierer]

Der Vorschlag überzeugt mich nicht, weil er viele sehr wichtige und legitime Anwendungsfälle verhindert.
Mein Gegenvorschlag lautet "Rust". ;)

[Jonathan]

Ich habe eine Millionen Jahre lang gesucht und zweimal CMake neu installiert, weil mein Projektname ein Leerzeichen enthielt, was eine völlig merkwürdige Fehlermeldung produzierte... ("CMake Error: Could not find cmake module file: CMakeDetermineDemoCompiler.cmake")

[Krishty]

Mein Thumbnail Handler ist 90 KiB groß. 79 KiB davon entfallen auf die Visual-C++-CRT, die überzeugt ist, folgende Dinge gehörten in mein Programm obwohl ich keinen Gebrauch davon mache:

• log10() (fast 2 KiB)
• parse_command_line(), expand_argument_wildcards(), common_expand_argv_wildcards(), usw – obwohl ich eine DLL kompiliere(!)
• memcpy – ich sehe ein, dass man das manchmal zur Initialisierung braucht; aber nicht, dass es mit 1 KiB größer ist als viele meiner Image Loader
• _raise_exc_ex(), _seh_filter_exe() und weitere Ausnahmebehandlungsroutinen – obwohl Exceptions in den Projekteinstellungen abgeschaltet sind und ich kein SEH nutze
• setmbcp_internal(), write_text_utf8_nolock(), und weiterer Locale-Dreck – obwohl ich keine stdio oder C++-I/O nutze
• __report_gsfailure() – obwohl Security Checks deaktiviert und Security Cookies durch Compiler-Switch ausgeknipst sind
• Rund fünfzig Funktionen betreffend Locks und Mutexe – obwohl ich nichts in Richtung Multithreading verwende außer _InterlockedIncrement() & Co.
• Etliche KiB unkenntlichen Mülls aus einer gewissen winapi_thunks.obj

Ich muss also dringend wieder anfangen, meine eigene CRT zu schreiben. Wirklich – fuck that shit.

[Spiele Programmierer]

Ist es nicht Aufgabe es Linkers, unbenützte Funktionen zu entfernen?
Werden die genannten Routinen auf subtile Art doch irgendwo benützt oder ist der Linker wirklich so ein Schrott?

[Krishty]

Ich vermute folgendes:

1. Visual C++ baut für alle globalen Variablen Initializer.
2. Diese Initializer werden bei Programmstart durch die CRT aufgerufen.
3. Die CRT wird nur gelinkt, nicht reinkompiliert. Die reingelinkte CRT hatte wahrscheinlich Exceptions eingeschaltet und nutzt irgendwo was mit Locales (Fehlermeldungen?).
4. Visual C++ hievt den Scheiß also auch bei mir rein
5. Sicher liegen die main() für DLL und EXE in der selben CPP, also werden beide gelinkt, also rutscht das Kommandozeilenzeug mit rein.

Warum dann nicht einfach einen eigenen Einsprungspunkt anlegen?

Weil dann alles aufhört, zu funktionieren. Ich bin so weit gekommen, dass die dynamisch gebundene Version läuft – aber die statisch gebundene stürzt in irgendeinem globalen Initializer ab weil da ein Lock genommen wird, der auf globale, thread-lokale CRT-Datenstrukturen zugreifen will oder so. Keine Ahnung; hab' seit 'nem Jahr nicht mehr reingeguckt weil ich dachte, es könnte ja so schlimm nicht sein … ich Narr

[Krishty]

Seit Update 2 unterstützt Visual C++’ STL kein /RTCc mehr. Das ist die Compiler-Option, die bei

  int x = …;
  short y = short(x);

zur Laufzeit prüft, ob bei der Konvertierung Daten verloren gehen. Äußerst nützlich, um Integer Overflow Attacks zu finden und Fixed-Point-Arithmetik zu debuggen … und jetzt quasi nicht mehr brauchbar (außer, man fügt obskure #defines hinzu, um drumherum zu bauen).

Ich nutze die STL nur noch in Assimp und anderen Drittprojekten, aber trotzdem … was für eine Scheiße.

Nachtrag: Und hid.lib haben sie auch noch entfernt oder verschoben. Jedenfalls für 32-Bit-Programme. Jetzt kann ich keine Joysticks mehr ansteuern … aber x64 linkt noch immer problemlos … WTF

Nachtrag 2: Sie haben mein x86-Projekt auf das Windows 10-SDK hochgepatcht, und das enthält keine hid.lib. Die x64-Version kompiliert noch mit dem Windows 7-/8-/8.1-SDK, und die enthalten jeweils hid.lib. WTF WTF was soll das; erst eine Bibliothek aus dem SDK löschen und dann bei Visual C++-Patches die Bibliothekspfade auf andere SDKs ändern, aber nur bei der Hälfte der Konfigurationen?! Da kann ich ja bald auf CMake umsteigen …

Nachtrag 3: Es ist der Windows-XP-Kompatitibilitätsmodus, der kaputtgegangen ist. Stelle ich auf Vista oder höher um, findet er die Bibliothek. Warum

Nachtrag 4: Oh lol. Diversen Usern geht mit Update 2 CTP der XP-Modus kaputt (siehe Kommentare hier). Sie eröffnen ein Ticket hier. Dann wird ein Workaround hochgeladen, aber irgendwie ist das Ticketsystem kaputt und niemand kann ihn sehen. Irgendwann stellen sie ihn dann als ZIP-Download zur Verfügung. Die ZIP besteht aus einer Sammlung von Property Sheets für MSBuild. Soll ich meine Props jetzt durch die Dateien in der ZIP ersetzen? Und jedem meiner User sagen, sie müssen das selbe machen, um das Programm kompilierbar zu kriegen? Hmmm …

[Jonathan]

Ich habe aus Testzwecken einen Ordner in #.git umbenannt. Jetzt wollte ich ihn wieder .git nennen, aber der Explorer sagt dazu nur "You must type a filename". Die Lösung ist, den Ordner .git. zu nennen, dann 'denkt' Windows, es sei ein Dateiname mit leerer Endung, anstatt ein leerer Dateiname mit Endung. Oh un der Punkt am Ende wird 'praktischerweise' automatisch entfernt. Ist jetzt nicht wirklich irgendwie schlimm, aber doch durchaus kurios.

[Chromanoid]

Ah den Trick kannte ich noch gar nicht. Ich verwende immer die Kommandozeile für mit . geschützte Ordner.

[marcgfx]

Mein Computer zeigt nur noch schwarz an. Vermutlich ist das Motherboard oder die Graphikkarte kaputt. Hab friedlich was gegessen und ein dämliches Youtube Video gekuckt. Dröhnende Lautsprecher, ein schwarzer und ein weisser Monitor haben mir den Mittag versaut. Wie ich das hasse :(

[marcgfx]

pc startet wenn ich die grafik-karte ausstecke, problem wird wohl da sein. kurz bevor das problem auftrat sah ich noch ne asus-installationsmeldung. vermutung treiber. also alle deinstalliert. leider startet der pc weiterhin nicht mehr, wenn die grafikkarte saft hat. wie soll ich da neue treiber installieren?

asus support hat mir geraten einen anderen slot zu probieren (motherboard auch von asus, modell habe ich mitgeteilt). Da flog doch prompt die sicherung raus, war wohl nicht so eine gute idee. motherboard hats überlebt. muss mir wohl ne neue grafikkarte organisieren.

[DerAlbi]

Also meinem Elektronik-Grundverständnis nach darf keines Falls die 16A Hauptsicherung kommen, nur weil man eine Grafikkarte umsteckt. Die Schaltnetzteile in einem PC sind intrinsisch kurzschlussicher, das bedeutet: du kannst die 5V, 3.3V und die 12V kurzschließen oder sogar die 12V auf die 5V-Schiene geben und alles, was passiert ist, dass eine elektronische Sicherung (Fehlererkennung) anspringt und das Netzteil ausmacht (oder das stimmt nicht; und meine Erfahrungen dahingehend sind die gute Seite der Ausnahmen).
Das gilt auch ohne Kurzschluss für Überstrom usw... einen sekundärseitigen Kurzschluss sollte man auf der Primärseite gar nicht sehen :-/
Bedeutet: wenn du kein mega ****** Netzteil hast, ist der Fehler nicht nur in der GraKa zu suchen. (Meiner Meinung nach)
Das Probelm ist: die Primätseite eines Schaltnetzteils ist überhaupt nicht darauf ausgelegt solch einen 16A-Fehlerstrom überhaupt zu erzeugen, noch zu überleben.
Falls du eine neue GraKa reinbaust... ööhmmm miss mal die 12V vorher nach oder wechsel gleich das Netzteil mit, falls du eins rumliegen hast...


Wenn ich schonmal poste:
Die Wärmeleitpaste auf meiner CPU war eingetrocknet. Sehr interessantes Phänomen. Das Tolle: dabei hat die extrem gut den Prozessor mit dem Kühlkörper verklebt.. und zwar so, dass weder Hebeln noch Schraubenzieher noch sonst irgendeine mechanische Kraft, die man an einer 500€ CPU aufbringen mag, geholfen hat. Mechanisch also top verbunden, thermisch leider nicht so mega :|
Nunja. Aber irgendwie muss man es lösen... Also... eine beherzte Drehbewegung am Kühlkörper (wurde im internet vorgeschlagen(TM)) und es war geschehen - Die Klebeverbindung war hinüber.. aber nicht nur das :-D. Neben komplett verbogenen Heatpipes ist mit der CPU-Sockel komplett zerbrochen... juhuuu aber die CPU hats überlebt :-)
Nach einer anstrengenden mechanischen Reinigung des Klebstoffs, äääh der alten Wärmeleitpaste, neue Paste drauf und gleich ne WaKü. Die CPU sitzt nun leicht fragwürdig im Sockel.. quasi handplatziert mit etwas gutem Willen. Das hat nach dem ~8. Versuch tatsächlich geklappt.
Irgendwie geht noch alles, außer so ein paar komische Sachen, wie die ganze Sensorik.. die ist hinüber. Mein Mainboard hat durchschnittlich -11°C... meine CPU spannnung hat grade 1.5V :-D die 5V-Schiene wird als 6.12V angezeigt und die 12V sind auf 13.5.. aber herjeeh scheiß drauf. Die CPU läuft.
Ist bischen wie bei modernen Auto... die selbst gehen kaum kaput, aber die Sensorik, die Defekte erkennen soll, bedarf Wartung...
Die neue WaKü ist aber Top. 6x 4.4GHz bei nur 80°C

[Krishty]

Ich bastle gerade für meine Retro-Projekte einen ILBM-Viewer. Das war das am weitesten verbreitete Bildformat der Amiga-Ära. Leider kann z.B. IrfanView keine exotischen Variationen davon laden, und libilbm und was es sonst noch gibt ist alles unvollständig. Weil ich ja eh schon einen Viewer für ein paar PlayStation-1-Dateien habe, packe ich also noch ILBM dazu.

Boah ist das ein Verschachtelungshorror. Ich zähle 105 Verzweigungen im ladenden Code. Am tollsten sind die Pixelformate:

• 0 Bits Farbtiefe mit Palette bedeutet, dass gar kein Bild in der Datei vorhanden ist, sondern dass es nur eine Palette transportiert.
• 24 und 32 Bits Farbtiefe sind RGB(A) und damit die einfachsten Fälle.
• 1–8 Bits Farbtiefe bedeuten, dass eine Palette benutzt wird.
• außer 8 Bits Farbtiefe ohne Anwesenheit einer Palette – denn das ist eine Graustufendatei.
• 5 oder 6 Bits Farbtiefe mit einer 16er-Farbpalette bedeuten Hold and Modify-Grafikmodus (eine Art zeilenweise Deltakompression).
• ebenso 7 oder 8 Bits Farbtiefe mit einer 64er-Palette.
• 6 Bits Farbtiefe mit 32er-Palette bedeuten Extra-Halfbrite, wo die verbleibenden 32 Farben verdunkelte Versionen der ersten 32 sind.
• PBM bedeutet, dass dieser ganze Kram nicht nur als einzelne Bit-Planes vorliegen kann, sondern auch als „normale” Bitmap. Hier fällt HAM zum Glück raus.
• Davon unabhängig kann jede Zeile RLE-komprimiert sein.
• Beliebige Pixel können maskiert sein – als Color Key, als Maske (abhängig von Datenlayout als zusätzliche Bit-Plane oder nicht), oder durch Flood Filling. Aber man darf sie erst nach dem Dekodieren verwerfen, weil das sonst mit der Zeilenkompression interferiert.

Und am schönsten war dann, wie ich einen Tag vor unlesbaren Dateien gesessen habe, bevor ich merkte, dass die Beispieldateien im Internet Archive kaputt (wie in: von beschädigtem Datenträger kopiert) sind … yay.

[Schrompf]

Dafür habe ich noch uralten Loader-Code rumliegen :-) Aber der deckt nur die 1-8-Bitplane-Version ab, also weit weniger, als Du da hast. Der Großteil dieser absurden Modi ergibt sich aus den absonderlichen Fähigkeiten des damaligen Grafikchips.

[Krishty]

Der Großteil dieser absurden Modi ergibt sich aus den absonderlichen Fähigkeiten des damaligen Grafikchips.

Weil ich ja aus den hunderten Seiten Dokumentation auch was gelernt habe:

Frühe Computer wurden direkt an den Fernseher angeschlossen und arbeiteten deshalb direkt auf dem NTSC-Signal. Als die Computer noch mit zwei/vier/acht Farben arbeiteten, konnte man ein Byte Speicher (und einige Transistoren) sparen, indem man die Farbe am Anfang der Zeile setzt und danach nur noch das Helligkeitssignal überträgt (ist bei TV ja beides getrennt). Natürlich hatte man dann nur eine Farbe pro Zeile, aber … doppelte Geschwindigkeit!

Als Commodore auf RGB umstellte, entfiel diese Funktionalität. Dummerweise hatte man dann ein großes Loch mitten im Grafikchip. Der Chefingenieur meinte, das wären drei Monate Arbeit, das wieder raus zu kriegen. Also einigte man sich darauf, die Funktionalität drin zu lassen, aber sie für RGB anzupassen. Und das war dann der erste Hold and Modify-Modus, und 35 Jahre später jammert Krishty, was für ein scheiß Gewusel das im Code ist.

[dot]

Branch Prediction to the rescue... :P

[Krishty]

Die Geschwindigkeit ist mir da sogar fast egal, weil das Konvertieren von ILBM zu Bildschirmpixeln keine Echtzeitaufgabe ist (ähnlich wie nie jemand direkt aus JPG-Daten rendern würde). Nur ist es ein Wartungsalptraum, eine 300 Zeilen lange Pixelkonvertierungsroutine mit sechs Verschachtelungen in der inneren Schleife zu haben. Eine Zeile umstellen, fünf exotische Kompressionsarten gehen kaputt. Bäh.

[Alexander Kornrumpf]

Weil ich ja aus den hunderten Seiten Dokumentation auch was gelernt habe:

Frühe Computer wurden direkt an den Fernseher angeschlossen und arbeiteten deshalb direkt auf dem NTSC-Signal. Als die Computer noch mit zwei/vier/acht Farben arbeiteten, konnte man ein Byte Speicher (und einige Transistoren) sparen, indem man die Farbe am Anfang der Zeile setzt und danach nur noch das Helligkeitssignal überträgt (ist bei TV ja beides getrennt). Natürlich hatte man dann nur eine Farbe pro Zeile, aber … doppelte Geschwindigkeit!

Als Commodore auf RGB umstellte, entfiel diese Funktionalität. Dummerweise hatte man dann ein großes Loch mitten im Grafikchip. Der Chefingenieur meinte, das wären drei Monate Arbeit, das wieder raus zu kriegen. Also einigte man sich darauf, die Funktionalität drin zu lassen, aber sie für RGB anzupassen. Und das war dann der erste Hold and Modify-Modus, und 35 Jahre später jammert Krishty, was für ein scheiß Gewusel das im Code ist.

Da ich mal, allerdings nur für 10 Minuten, versucht habe zu verstehen wie EGA funktioniert kann ich so richtig respektieren, wie du dich da durchwühlst.

[Krishty]

Ich muss nichts rückentwickeln oder so; Dokumentationen gibt es zu Hauf (das AmigaOS-Wiki ist super). Aber in Implementierungsdetails sind diese Dokumentationen teils widersprüchlich (Randfarbe „Schwarz“ oder „Erster Paletteneintrag“?) und muss man sich die Wahrheit aus hunderten verstreuten Mini-Quellen zusammensuchen.

Was wirklich schwer ist, ist das Finden geeigneter Testdateien. Für Half-Brite musste ich z.B. ein 1993er Webcomic aus einer LZH extrahieren, die in einem längst stillgelegten CD-Repository eines alten BBS lag. Und diese Quellen sterben immer weiter, Tag für Tag.

[Krishty]

Da ich mal, allerdings nur für 10 Minuten, versucht habe zu verstehen wie EGA funktioniert

Boah, gut dass du EGA erwähnst. Es scheint ILBMs zu geben, die gar keine eigene Palette mitbringen, und stattdessen auf der EGA-Standardpalette arbeiten. Ich weiß, dass solche Dateien z.B. in den komprimierten Archiven von Commander Keen herumliegen; bin aber bisher an keine Kopie gekommen (Spiel suchen -> Image runterladen -> DOS-Emulator installieren -> schon wieder 5 Uhr morgens, fuck my life). Also eine weitere Verzweigung für die Jammer-Liste oben.

Wer noch so alten Kram auf der Platte liegen hat: Immer her damit! Ihr kriegt dafür natürlich auch den Viewer und die Thumbnail-Shell Extension samt Quelltext.

[Krishty]

Mein Thumbnail Handler ist 90 KiB groß. 79 KiB davon entfallen auf die Visual-C++-CRT, die überzeugt ist, folgende Dinge gehörten in mein Programm obwohl ich keinen Gebrauch davon mache:

• log10() (fast 2 KiB)
• parse_command_line(), expand_argument_wildcards(), common_expand_argv_wildcards(), usw – obwohl ich eine DLL kompiliere(!)
• memcpy – ich sehe ein, dass man das manchmal zur Initialisierung braucht; aber nicht, dass es mit 1 KiB größer ist als viele meiner Image Loader
• _raise_exc_ex(), _seh_filter_exe() und weitere Ausnahmebehandlungsroutinen – obwohl Exceptions in den Projekteinstellungen abgeschaltet sind und ich kein SEH nutze
• setmbcp_internal(), write_text_utf8_nolock(), und weiterer Locale-Dreck – obwohl ich keine stdio oder C++-I/O nutze
• __report_gsfailure() – obwohl Security Checks deaktiviert und Security Cookies durch Compiler-Switch ausgeknipst sind
• Rund fünfzig Funktionen betreffend Locks und Mutexe – obwohl ich nichts in Richtung Multithreading verwende außer _InterlockedIncrement() & Co.
• Etliche KiB unkenntlichen Mülls aus einer gewissen winapi_thunks.obj

Ich muss also dringend wieder anfangen, meine eigene CRT zu schreiben. Wirklich – fuck that shit.

So. Habe mich eine Stunde hingesetzt und eine Mini-CRT geschrieben. Alle Symbole definiert. Ich musste kranken Scheiß machen, über den ich hier später noch ausführlicher jammern werde. Und was ist die Frucht meiner Mühen?

  1>Formats ILBM.obj : error LNK2016: absolute symbol '@comp.id' used as target of REL32 relocation in section 8D

FFFFFFFFUUUUUUUUUU

Nachtrag: Alle CRT-Ersatzfunktionen in eigene .cpp schieben; globale Optimierung deaktivieren; passt. Jetzt bin ich direkt viel weiter:

Code: Alles auswählen

1>dllmain.cpp : fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 249)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information
1>    link!RaiseException()+0x58
1>    link!CxxThrowException()+0x65
1>    link!std::_Xout_of_range()+0x1f
1>    link!InvokeCompilerPass()+0x25984
1>    link!InvokeCompilerPass()+0x18c0d
1>    link!InvokeCompilerPass()+0x18b8b
1>    link!InvokeCompilerPass()+0x18fa3
1>    link!InvokeCompilerPass()+0x18f14
1>    link!InvokeCompilerPass()+0x1be23
1>    link!InvokeCompilerPass()+0x1b8d3
1>    link!DllGetC2Telemetry()+0xc7cc6

Die „location listed above“ ist die erste Zeile des Projekts (was mir wohl sagen soll, dass ich von Anfang an verschissen habe).

[Krishty]

Geschafft. Der Thumbnail Shell Extension Handler nutzt keine CRT mehr, und die Größe ist von 104 KiB auf 15 geschrumpft (64-Bit-Version!). Davon entfallen

• 4+2 KiB auf ILBM- und TIM-Decoder
• 3 KiB auf COM-Server
• ein paar KiB auf Overhead wie globale GUID-Variablen, DLL-Einsprungspunkt, Funktionsimporte, Konstanten, etc.

… und es wäre erwiesen, dass 85 % der DLL tatsächlich überflüssiger Schrott aus Visual C++’ CRT waren.

Das Ersetzen der CRT ging übrigens – selbstverständlich – nicht ohne Assembler-Quelltext. Danke, Visual C++!

[glassbear]

Ich wuerde sogar Geld bezahlen wenn du das in einen Artikel zum Nachmachen verpackst ;)