Suchergebnisse
Suchergebnisse 1-20 von insgesamt 83.
Entschuldige, so sollte das nicht klingen! Ich bin wohl nur ein Bisschen frustriert weil ich die letzten Jahre mit Nachdenken über Determinismus verplempert habe während du die CLR entwickelt hast
Der Finalizer muss garnicht aufgerufen werden. Er läuft vielleicht nie. Und die Umstände dafür liegen außerhalb des Einflussbereiches des Prozesses. Da noch „deterministisch“ reinprügeln zu wollen, nur damit man Recht hat, ist schon enorm verbohrt, aber deterministisch BlueCobold
Gute Frage – ist schon ein Jahr her; ich werde heute abend in meine Kommentare schauen. Erstmal ist ein lokales Drehmoment einfacher zu berechnen: Ist der Masseschwerpunkt gleichzeitig der Nullpunkt, vereinfachen sich viele Formeln stark. Wenn man ein Raumschiff steuert, liegen auch alle Kräfte der Düsen in lokalen Koordinaten vor. So weit, so gut. Der Punkt ist nun: Das Raumschiff dreht sich die ganze Zeit, denn man fliegt nicht nur geradeaus. Dreht sich das Drehmoment, das vorher bereits aufs ...
Hmmm. Also ich habe allein für die Frage, ob ich Drehmomente in körperlokalen Achsen anwende oder in globalen, eine Woche analysieren müssen (und es beschleicht mich, dass das nicht genug war). Mir wäre auch neu, dass man Lösungen dafür in der Schule oder auf der Uni lernt. Aber viel Glück!
Windows setzt beim Betreten des Fensters immer als erstes den Zeiger, der in der Fensterklasse (WNDCLASSEX-Struktur beim Erzeugen des Fensters) eingetragen war. Trag dort mal LoadCursor(MAKEINTRESOURCE(IDC_ARROW)) ein. Danach setzt Windows den Cursor der WM_SETCURSOR-Nachricht. Ich glaube nicht, dass die häufig überschrieben wird, aber könnte ja auch sein: Falls die NULL zurückgibt, ist der Zeiger ebenfalls unsichtbar. Und, wie FSA schrieb: Der Zeiger darf nicht durch ShowCursor() ausgeblendet w...
Normalerweise verarbeitet der Besitzer des Controls WM_CTRLCOLORSTATIC: Das übergibt ein HDC im Parameter, und da macht man z.B. SetBkColor(hdcStatic, RGB(0,0,0));. (Siehe MSDN-Beispiel.) Beachtet, dass seit Aero nur 100 % deckende Hintergrundfarben funktionieren; transparente gehen nur mit dem Classic Theme.
Im Datensegment findet sich Laufzeittypinformation für std::bad_exception (".?AVbad_exception@std@@"), also ist zumindest ein Teil davon in C++ geschrieben. Das Linken geschah gemäß Header offenbar mit Visual C++; zum Raussuchen der genauen Version bin ich aber gerade zu faul weder mit 2010 noch 2012. 2005, 2008, und 2013 habe ich nicht zum Testen hier; ich gehe aber von Visual C++ 2008 für .NET 4.0 aus.
Zitat von »LukasBanana« Zitat von »dot« Weder ein Release noch ein Debug Build enthalten Source Code, zumindest wenn wir von MSVC reden, nichtmal die Symbolinformation wird dort direkt in der Binary gespeichert, sondern in der .pdb. Genau das wollte ich wissen, ok danke :-) Was aber sehr wohl in der EXE/DLL gespeichert wird, ist der Pfad zur PDB in deinem Dateisystem. Wenn du z.B. ein Virus schreiben willst, solltest du aufpassen, das Projekt nicht in C:\Users\LukasBanana\Desktop\Virus zu kompi...
Ja; und malloc und HeapAlloc kriegen ihren Speicher auch nur von VirtualAlloc. Was immer also drin steht, es kann unmöglich von einem anderen Prozess kommen. Übrigens bezieht sich das Nullen auch auf andere Aspekte: Die Page File wird genullt sobald eine Kachel freigegeben oder in den Speicher zurückgeholt wird (damit sensible Daten nicht im Klartext auf der Platte stehen).
Woher weißt du, dass nichts freigegeben wurde? Allein die C-Runtime legt bei der Initialisierung ein ganzes Dutzend Objekte an und gibt sie wieder frei. Die DLLMains abhängiger Module bereiten ihre Daten vor. Nicht zuletzt braucht der Image Loader, der dein EXE-Modul in den Adressraum lädt, auch ein Bisschen Platz für Temporäres. Z.B. muss auch die Kommandozeile geparst werden, damit deine main() argc und argv erhält. Das schließt auch die Konvertierung von UTF-16 zu ANSI ein. Und jede WinAPI-Fu...
Ist immer so; das ist Teil der Prozessisolation. Der Müll, den du siehst, kommt aus deinem EIGENEN Prozess. Falls du es schaffen würdest, Müll eines anderen Prozesses zu sehen, hättest du ein wirklich übles Sicherheitsleck entdeckt. Tatsächlich gibt es unter Windows genau einen Systemprozess allerniedrigster Priorität: Den Dienst, der nichts anderes tut, als freigegeben Speicher zu nullen damit das nicht erledigt werden muss wenn Anwendungen anfangen, Speicher zu allokieren.
Noch ein Fallstrick: „gleichverteilt“ ist nicht unbedingt „gleichverteilt“. Bei vielen Pseudozufallsgeneratoren haben die einzelnen Bits gleiche Wahrscheinlichkeit. Dadurch sind aber nicht die Zahlenwerte der Bits gleichverteilt, weil bei gleichverteilten Zahlen die höheren Stellen statistisch häufiger 0 sind als die niedrigen (siehe Benfordsches Gesetz).
Zitat von »Nimelrian« Das meint er nicht. Er meint, dass du mit free()/delete einen Memorybereich zwar wieder für andere Anwendungen freigibst, deine Daten aber noch drinstehen. Bei sensitiven Daten sollte man den Speicher deswegen vorher mit Ramsch-/Nullbytes füllen. Nicht ganz richtig – das SecureZeroMemory() ist für den Fall, dass ein Exploit im Prozess selber auftritt und die allokierten Seiten durchsucht. Andere Prozesse können freigegebene Daten sowieso nicht mehr auslesen weil Windows gr...
Er kann den Rest nicht wieder freigeben weil VirtualFree nur auf den kompletten Block (also die ganzen 2 MiB) auf einmal funktioniert. Er könnte den Überfluss höchstens decommitten, aber das würde ja nichts bewirken.
Unter 32-Bit-Windows wären es schlimmstenfalls 32.768 Tests. Du kannst ja direkt am Anfang reservieren, wenn der Adressraum noch leer ist. Und wenn es richtig brutal sein muss, dann allokier einfach 2 MiB via VirtualAlloc, merk dir die Adresse; gib es wieder frei; und teste die auf 1 MiB ausgerichtete gemerkte Adresse zuerst (die Wahrscheinlichkeit, dass sie dir zwischendurch ein anderer Thread wegschnappt, ist winzig). Mess einfach mal aus wie langsam das wirklich ist. In absoluter Not google n...
Zitat von »Krishty« Du kannst VirtualAlloc eine Adresse übergeben, an der du reservieren möchtest. Ganz naiv würdest du also in 1-MiB-Schritten über den Adressraum gehen, bei jedem Schritt via VirtualQuery prüfen, ob der Block dort allokiert ist, und falls nicht, VirtualAlloc mit dieser Adresse aufrufen. Das kannst du dann optimieren indem du Liste über die Blöcke führst. Was sprach gegen diese Lösung? Und einen Fallback-Algorithmus für aligned_malloc mit Riesenalignment gibt es nicht weil nur ...
Zitat Ich frage mich, warum _aligned_malloc das nicht von Haus aus tut. ôO Weil 99,9 % der Anwendungsfälle nur Ausrichtung auf 8 oder 16 B brauchen, und es bei denen nicht ins Gewicht fällt. Es würde mich wundern, wenn sie Ausrichtung > 4096 beim Entwurf überhaupt bedacht haben – braucht schließlich nie jemand. Und zu guter Letzt gehe ich davon aus, dass sie für Debug-Versionen die Größe des Speicherblocks in die ersten Bytes schreiben; dann wuchert der Block ebenfalls ganz gewaltig.
Zitat von »Spiele Programmierer« Ich habe auch gelesen, dass das die Allokationen beim MSVC ab einer gewissen Größe direkt an entsprechende "VirtualAlloc" weitergeleitet werden. Ja; die Grenze lag wohl zwischen 512 KiB und 4 MiB. Es ist aber keine direkte Weiterleitung im Wortsinne sondern zusätzlicher Overhead damit die Seiten auch wieder freigegeben werden wenn man den übergeordneten Heap freigibt. Auf jeden Fall ist es aber für die meisten Anwendungsfälle eine deutlich besser durchdachte und...
Mir bei labiler Netzwerkverbindung schon tausend Mal. Sie diagnostiziert beachtlich gut ob der Treiber rumzickt oder mich der Provider aufgegeben hat oder ob der Adapter einen Schuss hat und behebt es dann schneller als ich die Schritte selber durchführen könnte (sogar wenn ich wüsste, wie die gehen). Das Problem mit der Problembehandlung sieht mir eher danach aus dass ein Dienst zu viel deaktiviert oder eine Datei zu viel gelöscht wurde.
Win32 hat eine Allocation Granularity von 64 KiB; grundsätzlich sind also alle deine frischen Allokationen daran ausgerichtet. Normalerweise reicht das auch aus Du kannst VirtualAlloc eine Adresse übergeben, an der du reservieren möchtest. Ganz naiv würdest du also in 1-MiB-Schritten über den Adressraum gehen, bei jedem Schritt via VirtualQuery prüfen, ob der Block dort allokiert ist, und falls nicht, VirtualAlloc mit dieser Adresse aufrufen. Das kannst du dann optimieren indem du Liste über die...
28.04.2024, 06:53
Zum Seitenanfang
