ZFX + Developia

Schön zu hören!

Drei noch:

It should be noted that the code of the curve was compiled for 32-bit architectures using MSVC 2015.

every code compiled in 32-bit with MSVC on 64-architectures will call llmul every time a 64-bit multiplication is executed

Den letzten Satz finde ich schwamming: Meinen sie, dass 32-Bit-Code __llmul() aufruft, wenn er auf 64-Bit-CPUs ausgeführt wird? Das wäre grob unvollständig, denn auf 32-Bit-CPUs wird es natürlich ganz genau so aufgerufen.

Oder meinen sie, dass 32-Bit-Code __llmul() aufruft, wenn er auf einem 64-Bit-System kompiliert wurde? Das klingt schrecklich, ist aber nicht abwegig: Visual C++ enthält mindestens fünf verschiedene Compiler (x86 on x86; x64 on x64; x64 on x64 Rewrite; Cross Compilers; IntelliSense) und wenn sie nur einen davon getestet haben, ist das ein wichtiger Hinweis. Wem bei der Aufzählung schlecht wird: Microsoft arbeitet seit einigen Jahren daran, das durch einen einzigen Compiler zu ersetzen, aber es ist natürlich eine Mammutaufgabe.

Was mich persönlich mehr nervt als __llmul() ist _chkstk(). Das lässt sich nämlich nur mit Assembler-Code ersetzen (auch unter x64!) und zwingt damit jedem meiner Projekte eine Assembler-Abhängigkeit auf.

Es wäre schon interessant zu erfahren, wie GCC die Situation (long long auf x86-32) handhabt. Ich habe es nie getestet.

fefe hat geschrieben:Update: OK, also bei näherer Betrachtung stellt sich die Lage anders dar. Es geht um curve25519_donna, ein 64-bit-Port von curve25519 von djb. Das 32-bit curve25519 von djb hat das Problem nicht. curve25519_donna ist für 64-bit und hat dort das Problem auch nicht. Man muss also absichtlich und vorsätzlich das falsche curve25519 auf der falschen Plattform kompilieren. Dann fügt Visual Studio eine Routine ein, die die Multiplikation macht. Das macht gcc übrigens genau so unter diesen Umständen. Ich ziehe daher meine Anschuldigung zurück, dass VS hier was verkackt. Verkackt hat alleine der Typ, der das Advisory geschrieben hat. Ich vermute, der wollte nur mal seine 15 Minutes of Fame abholen. Scheiß Publicity-Scheiß immer.

Ich würde nicht einmal so gegen den Typen wettern, denn „die Kurve erfodert 64-Bit-Arithmetik und darf deshalb nicht auf 32-Bit-CPUs kompiliert werden“ ist nicht jedem offensichtlich. Wenn ich die Leute hätte informieren wollen, hätte ich’s ähnlich geschrieben. Ich vermute, dass das Advisory einfach von einer Armee Leute gepusht wurde, die den Text nur halb gelesen haben, und sensationslustig dachten: BWAHAHA, DA MACHT VISUAL C++ MAL WIEDER ALLES KAPUTT!

Krishty hat geschrieben:Lass mich da bitte Ordnung reinbringen:...

Immer wieder krass was Du für Sachen so nebenbei weisst. Danke!

Mal off-topic, sorry.
Wer ist eigentlich dieser Fefe?
Ich kann den irgendwie schwer einordnen....weiß auch sehr wenig von dem.

Hab den gerade auf FB gesehen. Hat einer meiner Anti-NWO-FB-Freunde da was geliket...ich bin verwirrt :?

Ich glaube nicht, dass Fefe persönlich auf Facebook ist, aber falls du mehr wissen willst: https://de.wikipedia.org/wiki/Felix_von_Leitner

Aha...okay.

Und is das der selbe?
https://www.facebook.com/Fefes-Blog-108 ... ED&fref=nf

Okay, sorry. Hab gerade gelesen:

RSS-Feed des erfolgreichsten deutschsprachigen Blogs! Felix von Leitner kommentiert: Tagespolitik, Verschwörungen & Obskures aus aller Welt, Leaks und Softwareprobleme. Diese Seite ist nicht von Fefe.

Weird:
Auf das Telefon war man stolz, weil man statt telegrafieren über einen Draht nun auch direkt miteinander reden konnte.
Auf das Fax war man stolz, weil man nun endlich Dokumente über den Draht schicken konnte und nicht mehr auf das vergängliche Wort angewiesen war.
Auf den Anrufbeantworter war man stolz, weil man mit jemandem reden konnte, der gar nicht da war, statt ihm schreiben zu müssen.
Auf SMS und Messenger war man stolz, weil man jetzt endlich übers Telefon schreiben konnte und nicht mehr direkt miteinander reden oder Sprachnachrichten auf ABs hinterlassen musste.
Auf Spracherkennung und Vorlesefunktion war man stolz, weil man nun solche zu versendenden Texte diktieren konnte statt tippen zu müssen. Und sich vorlesen lassen statt selber zu lesen. Fast schon so gut, als ob man direkt miteinander geredet hätte.
Auf Voice Messaging in Messenger-Apps ist man seit einer Weile stolz, weil man ja eigentlich viel einfacher "auf Band" reden kann statt Buchstaben zu tippen ...

Und als nächstes? Ich könnte mir evtl. vorstellen, die Messenger-App gibt ein akustisches Signal an den Empfänger, wenn versucht wird eine Sprachnachricht zu senden, und stellt automatisch eine direkte Verbindung her statt Voicebox, wenn der Empfänger dies in einem bestimmten Zeitrahmen bestätigt. Sind die aktuell schon so weit oder steckt diese Funktion noch in den Kinderschuhen?
Ich komme mit diesen rasanten Entwicklungen einfach nicht mehr mit. Ich werde alt.

Profiling mit Visual Studio 2015: Profiling mit Visual Studio 2017: IHR DRECKIGEN FICKER, DA IST JA SLEEPY BESSER

Vielleicht funktioniert das Profiling ja jetzt nur noch mit ihrem neuen tollen inkrementellen Debug-Format, das meine Assertions und meine Memory Leak Detection kaputtmacht … scheiß drauf

Man muss hier klicken um die 2015er Ansicht zu erhalten:Wtf?! Das nützlichste Profiler-Feature standardmäßig ausgeschaltet und hinter einem kleinen blauen Text versteckt, der nur über die Hauptansicht erreichbar ist?! RLY?!

Visual C++ 2017 kommt total durcheinander, wenn eine Solution gleichnamige Dateien in verschiedenen Projekten enthält. Es öffnet bei mir dauernd die falsche main.cpp, wenn ein Fehler drin vorkommt und ich auf den doppelklicke. Absolut zum Kotzen.

Außerdem ist mein Build Output voll mit Scheiße wie

  1>cmd.exe /C "A:\Users\Krishty\AppData\Local\Temp\tmp5269a99b78494f44b47c0ffb0a063844.cmd"

Häh?!

Krishty hat geschrieben:Visual C++ 2017

Und hier sitze ich und muss die gesamte Codebase nach wie vor kompatibel zu Compilern von 2008 halten.

Argh; habe mir mein Windows zerschossen.

Musste einen Thumbnail Handler debuggen. Die lädt der Explorer nicht direkt (aus Sicherheitsgründen) sondern erzeugt einen isolierten Systemprozess (dllhost.exe) dafür. Den wollte ich debuggen.

Irgendwann sprang er auch tatsächlich in meinen Haltepunkt. Ich wollte zum nächsten Haltepunkt und drücke F5. Nichts passiert außer voller CPU-Auslastung und frierendem Visual Studio. Offenbar irgendein Deadlock, wo Visual Studio auf den Explorer wartet, und der wartet auf dllhost, und das wiederum ist von Visual Studio angehalten oder so.

Kacke. Task Manager genommen, Visual Studio beendet. Geht nicht.

Explorer beendet. Starte Explorer via Task Manager nochmal.

Geht nicht; Task Manager hängt sich auf.

An dem Punkt ist die Hälfte meiner Fenster zu; ich habe weder Task Manager noch Explorer, nur Alt+Tab. Die separate Instanz Visual Studio 2015 hängt nun ebenfalls.

Ich hätte einfach den Strom kappen sollen, aber neee, ich wollte noch irgendwie ein sauberes Herunterfahren hinkriegen, um keine Daten zu verlieren. CTRL+ALT+DEL.

Nichts.

Nichts geht mehr.

Blue Screen (wichtiger Systemdienst wurde beendet). Festplatten fahren herunter (tun sie sonst nie). Rechner startet neu.

error 0x000001C4: cannot find ../boot/bcd – nichts geht mehr. Windows-Reparatur nötig.

Ende vom Lied: Festplatte voller Fehler. Search Indexer kann nicht starten weil Index zerschossen. Disk Management startet nicht mehr. Event Log sagt, ursprüngliche Ursache war out of paged pool. Fuck fuck fuck

Nachtrag: chkdsk startet nicht mehr; fsutil spuckt nur aus

Unsupported 16-Bit Application – The program or feature "\??\A:\Windows\system32\fsutil.exe" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.

HAHA DIE WINDOWS-DATEIEN SIND SCHROTT, DAS WIRD LUSTIG

chkdsk.exe - Bad Image – A:\Windows\system32\ulib.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.

Aua, Scheiße. Mein Beileid.

So, es geht wieder halbwegs.

Erstmal sollte man die Systemdateien wiederherstellen (sfc /scannow), aber natürlich nicht, so lange das Dateisystem fratze ist. Also über die Recovery Disk die Reparaturkonsole starten, chkdsk /r /f c: ausführen. Komischerweise geht das nur für C: und nicht für andere Partitionen – Biberkacke – aber immerhin ist die Systemplatte dann wieder halbwegs verlässlich.

sfc /scannow muss man dann aus Windows starten, es geht nicht aus der Reparaturkonsole. Wtf?! Wenn ich kaputte Dateien wiederherstellen will, dann jawohl lieber vom Originaldatenträger als aus dem dllcache, der auf der kaputten Festplatte liegt?! Aber egal. Hat funktioniert.

Jetzt kann ich chkdsk aus Windows heraus für die anderen Festplatten aufrufen. In ein, zwei Stunden ist hoffentlich alles in Ordnung.

Nachtrag: Gemäß Event Log ist dem System schon drei Stunden zuvor der Nonpaged Pool ausgegangen. Das ist wirklich merkwürdig.

Viel Glück und Erfolg beim Wiederherstellen!

Danke! Daten scheinen nicht verloren gegangen zu sein. Visual Studio 2017 ist aber geschrottet (startet einfach nicht mehr).

Nachtrag: Der Installer hat keine Reparaturoption. Das Setup bricht nach dem Startbildschirm einfach ab. FUCK

Ich glaube, ich hab’s. Der Visual Studio Installer war beschädigt; habe das ganze Verzeichnis Program Files (x86)/Microsoft Visual Studio gelöscht und nun startet das Setup endlich wieder.

Nachtrag: Nööö, 20 packages failed to install. Für jedes wird ein Link à https://aka.ms/VSSetupErrorReports?q=Pa ... nCode=3017 angegeben, den ich nach Lösungen durchsuchen soll …

Visual Studio 2015 Sprachpaketinstallationsmeldung: "Sie benötigen bis zu 626 MB freien Speicherplatz auf allen Laufwerken". Was zum? Wieso haben die immer noch hardgecodete Pfade zu temporären Verzeichnissen? Und wieso braucht man überhaupt derartig viel Speicher, was wird denn da alles übersetzt? Meine Güte...

Ja; sie installieren gern auf das Laufwerk, das den meisten freien Speicherplatz hat. Habe etliche Male Visual Studio-Installationsdateien auf meiner externen Festplatte gefunden. Sowas am besten abklemmen, bevor man installiert.

  struct Base {
    virtual void foo(int) = 0;
  };

  struct Derived : Base {
    void foo(int const i) override { }; // warning C4373: 'Derived::foo': virtual function overrides 'Base::foo', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers
  };

Verarschen die mich?! Das hat VC++ wirklich vom Überschreiben abgehalten?! Ein Glück, dass ich kein OOP einsetze, sonst wäre der Jammer-Thread die letzten Jahre übergelaufen.

Sooo. Neu gestartet, Visual 2017 zum vierten Mal installiert. Nun schlägt nur noch ein Paket fehl, und starten kann ich trotzdem. Nur beim Schließen stürzt VS nun immer ab.
*seufz*

Microsoft hat es getan. Bei Visual Studio 2017 läuft im Hintergrund immer zwei Mal node.js mit (einmal Server Side, einmal Client Side). WTF

Ich habe einfach mal A:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\ServiceHub\Hosts\ServiceHub.Host.Node.x86 gelöscht. „Visual Studio geht fubar“ habe ich ja schon hinter mir, und so spare ich zumindest 150 MiB RAM(!).

Gestern: Alle Windows-Dienste deaktiviert, die nicht unbedingt nötig sind.

Heute: Visual C++ kann nicht kompilieren. Die EXE ist dauernd gesperrt.

Eben: Process Explorer gesaugt, geprüft: Datei wird nach dem Löschen 2 Minuten vom Systemprozess (PID 4) gesperrt. In der Zeit kann niemand auf sie zugreifen. Google angeschmissen.

Stack Overflow:

It's a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service.

Re-enabling this service has fixed this problem for me.

WHAT THE FUCK?!

(inb4: meh Windows 7: Tritt unter Windows 10 genau so auf)

Application Experience ist der Dienst, der Programme auf Kompatibilitätsprobleme prüft, und dann automatisch patcht. Ich habe eine besonders starke Abneigung gegen ihn, weil in der Regel diese Situation eintritt:

• mein Programm stürzt im Debugger ab, während es sich im Neuzeichnen des Fensters befindet (WM_PAINT), weil irgendein Vertex Buffer nicht existiert oder so
• ich breche das Debugging ab und will den Fehler beheben
• plötzlich taucht ein beschissener Dialog auf und sagt, mein Programm hätte bekannte Kompatibilitätsprobleme und Windows hätte sich dem angenommen
• die Grütze hat keinen Knopf zum Abbrechen und sowieso versteht kein Arsch, was sie meinen
• ich starte das Programm nochmal im Debugger
• es stürzt nicht mehr ab
• mfw
• plötzlich kracht es an einer komplett anderen Stelle
• Windows hat ein automatisches __try __except um meine Message Loop gewrappt, und alle Abstürze werden davon abgefangen und das Programm macht dann einfach trotzdem weiter, und im Debugger merke ich nichts
• obwohl der komplette interne Zustand im Arsch ist
• mfw
• man kann die Scheiße nicht mehr abschalten
• man muss die Registry durchsuchen und findet irgendwann unter dem Pfad des Programms einen Schlüssel, der die Kompatibilitätseinstellungen vornimmt
• den muss ich jedes Mal löschen, wenn die Scheiße passiert
• mfw

Und wenn ich diese Scheiße abwürge, kann Windows keine Dateien mehr löschen?! W T F

Interessant. Ich hatte das ja auch ewig dass beim kompilieren die alte Exe noch gesperrt war. Bei mir war die Lösung dass ich irgendwo nen Registrykey geändert habe der mit der Thumbs.db zusammenhängt. Weil wenn Windows da grade noch am Iconbauen ist, dann ist die Datei auch erst mal gesperrt. Aber das ist schon wieder so elendslang her dass ich vergessen habe welcher das war. Und ich Vollpfosten hatte mir das nicht notiert. Das wird mir noch richtig Freude bereiten falls ich mal das System neu aufsetzen muss -.-

thumbs.db wird seit Vista nur noch im Netzwerk angelegt; bei lokalen Operationen sollte sie keine Rolle spielen.

Ah, danke für die Info :)

Krishty hat geschrieben:disable Application Experience service.

Wir nutzen in der Firma eine Software die gar crasht wenn der Application Experience Service deaktiviert wurde,
natürlich wurde diese "Abhängigkeit" vom Hersteller nicht dokumentiert..
Btw ein nützliches Tool um unnötige Ressourcenverschwender zu finden (nicht nur für VMs):
https://labs.vmware.com/flings/vmware-o ... ation-tool

Danke für den Tipp!

Es ist sicher keine bekannte Abhängigkeit – wahrscheinlich ist irgendwo ein bestimmter Double Free Bug, eine Exception während der Message Loop, o.ä. in der Anwendung. Application Experience behebt sowas gern „automatisch“ – wenn man nicht explizit mit Application Verifier oder ähnlichen Tools testet, fällt der Fehler nie auf. Reproduzieren kann man ihn auch nur ein Mal, bis der Mechanismus greift; danach muss man die Registry-Schlüssel löschen.

Borr macht mich VS 2013 grad narrisch. Will nach dem kompilieren einfach nich zumachen. Und das Minutenlang -.-

WPF!!! Besonder dieses ModernUI...was ja einem erleichtern soll, "modernes" "bewegendes" UI zu implementieren.
Aber kann ich damit ein gaaaanz ordinäres Image darstellen? ==> NEIN, irgendwie nicht....und ich hab keine Ahnung wieso!!!
DRÄCK!!!