ZFX + Developia

Ja, mein letzter Kontakt lag tatsächlich noch im letzten Jahrhundert :) Gut zu wissen.

Krishty hat geschrieben:Ja, mein letzter Kontakt lag tatsächlich noch im letzten Jahrhundert :) Gut zu wissen.

beneidenswert... :D

Boah. Ich nutze ja seit Jahren keine CRT mehr, einfach um mal selber zu lernen, wie alles funktioniert.

Und ich nutze keine Exceptions mehr, weil ich an der Komplexität gescheitert bin. Wenn man sich mal anguckt, wie die in Visual C++ realisiert sind … oh Scheiße, da fängt direkt wieder mein Auge an zu zucken. Die 40k Zeilen hole ich mir nie mehr in eine EXE.

Jedenfalls habe ich nun die neueste Missgeburt gefunden, die im Alltag toll vor uns versteckt wird: stdio.

Wer einmal mit der puren WinAPI eine Funktion schreiben musste, die eine Zeile aus der Konsole liest, will nie wieder Konsolen nutzen. Die lustigsten Fallstricke:

• ReadConsole() unterstützt keine redirected handles (steckt ja im Namen dass es nur für die Konsole ist, aber trotzdem … wtf)
• ReadConsole() und ReadFile() schlagen beide im Bereich von 20-KB-Input fehl (26608/31004/31346 B auf Windows XP/Server 2003/7) weil irgendein interner Puffer feste Größe hat, aber mit anderen Komponenten geteilt wird
• ReadFile() gibt auch gern mal ein paar Bytes weniger zurück als man angefordert hat, aber das ist dann kein Fehler sondern man sollte es einfach nochmal versuchen

Nachtrag: Diese Zeitleiste ist ja lustig. Alle zwanzig Jahre brauchen wir hundert Zeichen mehr für die selbe Aufgabe! (Fortran: 110 Zeichen; Algol: 206; [C ähnlich;] Java: 330; C#: 595)

Ich werde Vater.

Patch schnell noch den Internet-Bug in Splatter!

:| mein Beileid

Hallo !

Versuche ( :( ) zur Zeit Visual Studio 2015 Community Edition zu installieren.
Hab von 'nem Kollegen ein ISO - Image (5,8GB) bekommen, da ich selber nur ein begrenztes flat-rate-Volumen (1GB/Monat) besitze.

Bekomme immer die Fehlermeldung:
Egal, ob ich ein Laufwerk mit MagicDisc oder Deamon-Tools emuliere.


Da mir Visual Studio wirklich wichtig ist, schreibe ich dies in diesen Thread :( :( :( ...

Kann mir jemand weiterhelfen ?!

Gruss
RedGuy

Ich werde Vater.

Ich kann mich nicht entscheiden, ob ich "Herzlichen Glückwunsch" oder "Selbst schuld!" sagen soll :D
Anyway geht uns damit wohl ein wertes ZFX-Mitglied "verloren", deine Freizeit wird wahrscheinlich stark eingeschränkt werden :?

@RedGuy:
Naja, das ist schwierig zu beurteilen, wenn du uns nicht sagst, was du für ein System hast... wieviel RAM haste denn? Haste Windows 8.1 oder 10?

Egal, ob ich ein Laufwerk mit MagicDisc oder Deamon-Tools emuliere.

Schonmal mit Windows versucht, ohne 3rd party tool?
Bei mir hat ein Doppelklick auf die ISO gereicht, um ein virtuelles Laufwerk zu erzeugen; aber mit meinen 32GB RAM krieg ich halt auch keine Memory-Probleme :P
Aber es kann gut sein, dass die Fehlermeldung nix mit dem Memory zu tun hat, sondern die .exe eine Macke hat oder eine andere Mindestanforderung nicht passt.

Hi !

@Schrompf: also mich hatte vorhin glaub ich verwirrt warum das im Jammer-Thread drin ist :D -sonst hätte ich gleich etwas geschrieben ;) .
Also trotz Jammer-Thread -wie auch immer :D : Herzlichen Glückwunsch !!

@NytroX: also ich hab im Gegensatz zu Dir nur 2GB Speicher (Dell 2,2GHz mit Windows 7). Daran wird's wohl auch liegen. Ich hab sowieso bald vor auf 8 GB aufzurüsten ;) .
Muss ich mich halt noch gedulden- JAMMER :( - wenn dann der Speicher reicht... :( !!!
Vielen Dank für die Antwort auf jeden Fall !

Gruss
RedGuy

evtl. mal an der Größe der Auslagerungsdatei schrauben

Hi !

@B.G.Michi:
also das war 'ne gute Idee, hab 8GB probiert. Allerderings: negativ- das hat nix gebracht :( :( .
Danke trotzdem !!!

Gruss
Red

Schrompf hat geschrieben:Ich werde Vater.

Jammer-Thread?

Okay, Screenshot gespeichert, das zeige ich in 14 Jahren deinem Sohn. Dann wird er dich verlassen und du hast wieder voll Zeit fürs Spiele-Programmieren.

RedGuy hat geschrieben:@Schrompf: also mich hatte vorhin glaub ich verwirrt warum das im Jammer-Thread drin ist :D -sonst hätte ich gleich etwas geschrieben ;) .
Also trotz Jammer-Thread -wie auch immer :D : Herzlichen Glückwunsch !!

antisteo hat geschrieben:Jammer-Thread?
Okay, Screenshot gespeichert, das zeige ich in 14 Jahren deinem Sohn. Dann wird er dich verlassen und du hast wieder voll Zeit fürs Spiele-Programmieren.

Danke, schätze ich :-) Ich habe es aber bewusst in beiden Threads geschrieben: Jammer und Anti-Jammer.

[edit] Aber wenn Du das hier lesen solltest, liebes Kind: Gezockt wird erst, wenn Du Deine Hausaufgaben gemacht hast!

Schrompf hat geschrieben:Ich habe es aber bewusst in beiden Threads geschrieben: Jammer und Anti-Jammer.

Ich mochte deinen Humor / 'Fähigkeit, Dinge interessant auszudrücken' schon immer :) (Besonders im ersten Splatter waren ein paar gute Texte dabei.)

Sieh bloß zu, dass euer Rollenspiel noch fertig wird, da würde sich das großartig drin machen.

RedGuy hat geschrieben:Hallo !

Versuche ( :( ) zur Zeit Visual Studio 2015 Community Edition zu installieren.
Hab von 'nem Kollegen ein ISO - Image (5,8GB) bekommen, da ich selber nur ein begrenztes flat-rate-Volumen (1GB/Monat) besitze.

Bekomme immer die Fehlermeldung:

Code: Alles auswählen

Program too big to fit in memory

Egal, ob ich ein Laufwerk mit MagicDisc oder Deamon-Tools emuliere.

Der Fehler bedeutet nicht, dass du zu wenig RAM hast (dank virtuellem Speicher gibt es sowas seit 20 Jahren nicht mehr). Das ist die Standardfehlermeldung von DOS, wenn eine ausführbare Datei defekt ist. Ich gehe mal davon aus, dass die ISO beschädigt ist; besorg sie dir nochmal neu.

Hi !!

@Krishty:
Hey- vielen Dank ! Verdammt- muss ich dem Typen von dem ich das herhab nochmals sagen... Das kann dauern :( ...
Aber Danke für die Antwort! Ich freue mich auf 'ne bessere Internetverbindung, die ich voraussichtlich ab März bekomme ;) , dann hätte ich kein Problem mit dem Herunterladen :( .

Ich werd' ich das schon noch gebacken bekommen mit dem guten Visual Studio.
Denn - und jetzt kommts: ich will von Linux und JAVA wieder zurück zum guten Windows, .NET und C# ;) .
Verschiedene Dinge haben mich unter Linux zum Wahnsinn getrieben... Ich behalte es aber als gutes Alternativsystem auf ner anderen Festplatte ;) .

Gruss
Red

MSDN hat geschrieben:For a future—or the last shared_future—that's attached to a task started with std::async, the destructor blocks if the task has not completed; that is, it blocks if this thread did not yet call .get() or .wait() and the task is still running. If a future obtained from std::async is moved outside the local scope, other code that uses it must be aware that its destructor may block for the shared state to become ready.

Na prima. Angeblich war das schon immer so, aber bisher haben meine std::async()-Aufrufe trotzdem sauber funktioniert. Ich ruf ja auch ne void() auf, die explizit als Fire-And-Forget designed ist. Seit neuestem nun blockt aber das zurückgegebene std::future im Destructor, SELBST BEI NEM VOID-ERGEBNIS. Auf nichts ist mehr Verlass auf dieser verfickten Welt.

Scheint, als müsste ich mein hochparalleles Geschnösel endlich mal zum Laufen bekommen, damit mein bisschen Mehrkernbetrieb in Splatter wieder funktioniert.

Gehört ebenfalls in die Ecke "Nebenläufigkeit":

Ich hatte eben einen Blue Screen, zum ersten Mal seit Jahren auf diesem Rechner. Dabei ist eine Datei, die gerade von meinem Programm bearbeitet wurde, verschwunden.

Ich bin schon extra die sichere Variante gefahren: Die langwierigen Berechnungen auf einer temporären Kopie ausführen; dann das Original durch die Kopie ersetzen. Beim letzten Schritt muss die Kiste abgerauscht sein.

Dafür gibt es schon lange eine Lösung (ich war nur bisher zu faul, sie zu implementieren): MoveFileTransacted(). Großartig wie das ganze transactional NTFS. Man beginnt eine neue Transaktion, ersetzt dabei die alte Datei durch die Neue, und sobald man die Transaktion abschließt wird der Fortschritt atomar für das restliche System sichtbar. Ist mittendrin der Strom weg (oder bricht der Benutzer den Prozess ab oder wasweißich), bleibt die Transaktion uncommitted und alles bleibt, wie es vorher war.

Die Vorteile sind also nicht nur für Installer, Windows Update, und Backup-Lösungen gigantisch (man kann beliebig viele Operationen in Transaktionen bündeln bevor man sie atomar sichtbar macht, sogar Registry-Veränderungen! Komplette Programminstallationen sind damit als atomarer Schritt möglich), sondern tatsächlich auch für Alltagsprogramme (wenn Krishty nicht gerade zu faul ist, das einzubauen, und dann über verlorene Dateien meckert).

Naja, und jetzt … hat Microsoft das wieder abgeschafft. Weil das Interesse zu gering ist. WTF?! Ich *soll* jetzt also ReplaceFile() nutzen, obwohl ich gerade gesehen habe, wie wunderbar das bei einer Unterbrechung meine Dateien röstet?

Das ist, als würde Intel atomare Operationen aus den CPUs verbannen weil die so selten auftauchen, und dann sagen, dass man ja auch in volatile-Variablen schreiben kann. WTF WTF WTF

Krishty hat geschrieben: Die langwierigen Berechnungen auf einer temporären Kopie ausführen; dann das Original durch die Kopie ersetzen. Beim letzten Schritt muss die Kiste abgerauscht sein. [...] obwohl ich gerade gesehen habe, wie wunderbar das bei einer Unterbrechung meine Dateien röstet?

Überseh ich was? Vorher Sicherungskopie der zu ersetzenden Datei machen löst das Problem?!

Dann hast du nach einem Stromausfall zwei Dateien statt einer. Du kannst genau so gut das Original umbenennen und die Kopie an seinen Platz schieben, aber dann hast du nach einem Stromausfall eine bis zwei Dateien, wovon eine oder null den Originalnamen tragen. Nicht-atomar ist da einfach scheiße.

Krishty hat geschrieben:Dann hast du nach einem Stromausfall zwei Dateien statt einer.

Das habe ich schon verstanden. Wesentlich besser als null statt einer.

Ooooder wir machen es halt atomar. Dann haben wir immer eine :)

Außerdem holst du dir damit eine Shitload Komplexität ins Boot. Wie heißt die Kopie? Was, wenn der Name schon existiert? Was, wenn dein Quota erschöpft ist? Usw.

Theoretisch ist das klar. Praktisch kann ich nicht abwägen ob der Aufwand für Microsoft, das anzubieten, den Nutzen übersteigt. Die werden auch wissen, dass der Anteil der Geräte die einen Akku haben an der Gesamtheit der Zielplattformen ständig steigt.

Es ist ja sowieso seit acht Jahren eingebaut, die Akkus haben das also längst überwunden. Und da Windows Update drauf fußt (nicht, dass das als Glanzbeispiel für stabilen und effizienten Betrieb anzusehen wäre) müssen sie sowieso jede Menge umschreiben, bevor sie es deprecaten können.

Wenn ich höre, dass sie solche Probleme von tausend externen Entwicklern lösen lassen wollen, statt ihre Lösung in einer API anzubieten (wie sie es ja schon seit Jahren tun!), dann rollen sich mir die Fußnägel. Klingt mir nach dem Microsoft-typischen "Wir schmeißen's weg damit wir in zwei Jahren das gleiche in Grün als Innovation anpreisen können und sich alle Windows 12 kaufen".

Krishty hat geschrieben:Es ist ja sowieso seit acht Jahren eingebaut, die Akkus haben das also längst überwunden. Und da Windows Update drauf fußt (nicht, dass das als Glanzbeispiel für stabilen und effizienten Betrieb anzusehen wäre) müssen sie sowieso jede Menge umschreiben, bevor sie es deprecaten können.

Wenn ich höre, dass sie solche Probleme von tausend externen Entwicklern lösen lassen wollen, statt ihre Lösung in einer API anzubieten (wie sie es ja schon seit Jahren tun!), dann rollen sich mir die Fußnägel. Klingt mir nach dem Microsoft-typischen "Wir schmeißen's weg damit wir in zwei Jahren das gleiche in Grün als Innovation anpreisen können und sich alle Windows 12 kaufen".

Nur mal so aus Neugier, wie soll das eigentlich implementiert sein? Ich weiß was eine Transaktion ist und ich weiß (ungefähr) wie Datenbanken das machen, aber Datenbanken haben dabei ja auch Zugriff auf ein funktionierendes Dateisystem, bzw. müssen sich im Fehlerfall ja gerade nicht darum kümmern, dass das Dateisystem an sich konsistent ist.

Ich habe da zwei Steine des Anstoßes:

1) Egal wie man es macht, das Dateisystem muss Meta-Daten schreiben, die nicht selbst als Dateien im Dateisystem auftauchen.

Warum letzteres? Wenn das normale Dateien wären, wär es ja nicht transparent, man hätte nicht "_immer_ eine" Datei, die Kopie wär nur im Zweifel in einem Windows Systemverzeichnis. Letztlich könnte man _das_ natürlich auch zu Fuß implementieren, nicht mit meiner knee-jerk Sicherungskopie, klar, aber eben so wie bei einer Datenbank. Der Unterschied wäre nur, dass das OS halt ein API dafür anbieten würde. Die von dir kritisierte Komplexität und Sichtbarkeit für den User hätte es trotzdem.

Fü diese Metadaten muss aber, auch wenn sie nicht als Dateien auftauchen natürlich trotzdem ein Teil der Platte magnetisiert werden. Ich kann und will nicht ausdiskutieren, ob das eine gute Idee wäre. Klar ist, es wäre nicht umsonst.

2) Apropos Platte magnetisieren. Irgendwo trifft das Gummi die Straße und im Filesystem muss, sinngemäß, ein Zeiger so umgebogen werden, dass die Datei x in dem Verzeichnis y jetzt auf diesem und nicht mehr auf jenem Teil der Platte liegt. Und diese Änderung muss selbst auf der Platte ankommen. Und jetzt meine Frage: ist das _in Hardware_ eine atomare Operation?

[Wenn ich das richtig verstehe ist Atomarität im Prozessor übrigens was ganz anderes, deren Sinn ist es ja nicht, dass du nach einem Stromausfall in einem konsistenten Zustand bist (?) ich bin von deiner Analogie nicht überzeugt.]

Wenn nämlich jemand den Stecker ziehen kann, während der Zeiger in Hardware "halb" umgebogen ist, dann kann dich keine Software der Welt darüber retten, sondern nur Statistik und der Umstand, dass dieser Moment sehr sehr kurz sein wird.

---

Ich kam mir erst doof vor mit den Fragen, aber wenn ich bei Wikipedia lese dass transaktionale Dateisysteme für Linux derzeit "research projects" ist und sich die Seite zu TxF weitgehend ausschweigt, dann scheint es so trivial dann doch nicht zu sein. Und was die zweite Frage angeht, da geht es darum wie Festplatten implementiert sind, da schäme ich mich nicht, es nicht zu wissen, ist schlicht nicht meine Baustelle.

Vorher schonmal Entschuldigung für viel Halbwissen … aber NTFS und TxF sind halt spärlich dokumentiert.

Erlaub mir, das in umgekehrter Reihenfolge zu beantworten:

Alexander Kornrumpf hat geschrieben:Irgendwo trifft das Gummi die Straße und im Filesystem muss, sinngemäß, ein Zeiger so umgebogen werden, dass die Datei x in dem Verzeichnis y jetzt auf diesem und nicht mehr auf jenem Teil der Platte liegt. Und diese Änderung muss selbst auf der Platte ankommen. Und jetzt meine Frage: ist das _in Hardware_ eine atomare Operation?

Wenn nämlich jemand den Stecker ziehen kann, während der Zeiger in Hardware "halb" umgebogen ist, dann kann dich keine Software der Welt darüber retten, sondern nur Statistik und der Umstand, dass dieser Moment sehr sehr kurz sein wird.

Die Hardware garantiert dafür, dass sich bei einem Stromausfall die Platten noch lange genug drehen, um den transparenten Cache der Festplatte zu schreiben. Die Bits auf der Platte sind also konsistent.

NTFS ist von sich aus bei jeder Operation Sektor-konsistent und arbeitet nur über eine Log-Datei, mit deren Hilfe beim Ziehen eines Steckers der letzte gültige Zustand wiederhergestellt wird. Das bedeutet NICHT, dass deine Dateien dann in Ordnung sind -- sondern nur, dass die Sektoren zu jedem Zeitpunkt gültig zugewiesen bleiben. (Wikipedia ist da IIRC recht ausführlich.) Darum siehst du mit NTFS z.B. keinen "Platte auf Fehler überprüfen"-Bildschirm nach einem Blue Screen, wie er mit FAT damals Standard war.

Transaktionen sind mächtiger als das Schreiben einzelner Sektoren. Wie das intern funktioniert weiß ich nicht; aber ich glaube, dass der Kernel hier die neuen und alten Daten neben einander auf dem Dateisystem auslegt, beim Realisieren der Transaktion alle Dateizugriffe Dritter stoppt, und dann die Zeiger in Dateisystem, Registry, und Datenbanken "zurechtbiegt". Ich weiß jedoch ziemlich genau, dass das über eine Log-Datei geschieht, in der die Transaktion festgehalten wird. Wird mittendrin der Strom abgeschaltet, kann der Kernel beim nächsten Boot aus der Log-Datei herauslesen, bis wo er gekommen ist, und die Änderungen dann entweder vollenden oder rückgängig machen (eher letzteres).

Warum ich das so genau weiß, bringt mich zu Frage 1:

Alexander Kornrumpf hat geschrieben:1) Egal wie man es macht, das Dateisystem muss Meta-Daten schreiben, die nicht selbst als Dateien im Dateisystem auftauchen.
[…]
Fü diese Metadaten muss aber, auch wenn sie nicht als Dateien auftauchen natürlich trotzdem ein Teil der Platte magnetisiert werden. Ich kann und will nicht ausdiskutieren, ob das eine gute Idee wäre. Klar ist, es wäre nicht umsonst.

Es ist nicht nur nicht umsonst, sondern es ist sogar ein bleibendes Memory Leak, wie ich schonmal hier erklärt habe:

So belegt diese Log-Datei auf meinem Systemlaufwerk mittlerweile 363 MiB. WTF, Microsoft?! REALLY?! Ihr habt ein Memory Leak ins Dateisystem eingebaut gekriegt?!

(Ich muss aber richtig stellen: Das Löschen der Metadaten ist implementiert, sie haben es nur aus irgendelchen Gründen per Default deaktiviert.) Wie groß der Overhead ist, weiß ich nicht. Die 363 MiB stammen aus mehreren Jahren Computer-Nutzung; in der Zeit hat Windows Update ungefähr 2 GiB an Updates auf meinem PC installiert (plus viele manuelle Installationen bei Visual Studio und so); jedes ein Dutzend Dateien umfassend. Aus ein paar MSDN-Artikeln meine ich mich zu erinnern, dass da auch Kompression im Spiel ist (wahrscheinlich die NTFS-Standardkompression). Ja ich hasse den Overhead auf der Platte, aber so lange man diese Daten wieder löscht, sobald eine Transaktion vollendet ist, müsste er sich im Rahmen halten.

[Wenn ich das richtig verstehe ist Atomarität im Prozessor übrigens was ganz anderes, deren Sinn ist es ja nicht, dass du nach einem Stromausfall in einem konsistenten Zustand bist (?) ich bin von deiner Analogie nicht überzeugt.]

Ja; bei Fluchen suche ich nicht erst minutenlang gute Vergleiche, wie ein Schriftsteller, der … ach Kacke ;)

Krishty hat geschrieben:Die Hardware garantiert dafür, dass sich bei einem Stromausfall die Platten noch lange genug drehen, um den transparenten Cache der Festplatte zu schreiben. Die Bits auf der Platte sind also konsistent.

Geil, wusste ich nicht, macht aber natürlich total Sinn. Ingeniuere sind schon was tolles.

Ich weiß jedoch ziemlich genau, dass das über eine Log-Datei geschieht, in der die Transaktion festgehalten wird. Wird mittendrin der Strom abgeschaltet, kann der Kernel beim nächsten Boot aus der Log-Datei herauslesen, bis wo er gekommen ist, und die Änderungen dann entweder vollenden oder rückgängig machen (eher letzteres).

Japp, das ist auch das was Datenbanken tun.

Warum ich das so genau weiß, bringt mich zu Frage 1:

Alexander Kornrumpf hat geschrieben:1) Egal wie man es macht, das Dateisystem muss Meta-Daten schreiben, die nicht selbst als Dateien im Dateisystem auftauchen.
[…]
Fü diese Metadaten muss aber, auch wenn sie nicht als Dateien auftauchen natürlich trotzdem ein Teil der Platte magnetisiert werden. Ich kann und will nicht ausdiskutieren, ob das eine gute Idee wäre. Klar ist, es wäre nicht umsonst.

Es ist nicht nur nicht umsonst, sondern es ist sogar ein bleibendes Memory Leak, wie ich schonmal hier erklärt habe:

So belegt diese Log-Datei auf meinem Systemlaufwerk mittlerweile 363 MiB. WTF, Microsoft?! REALLY?! Ihr habt ein Memory Leak ins Dateisystem eingebaut gekriegt?!

(Ich muss aber richtig stellen: Das Löschen der Metadaten ist implementiert, sie haben es nur aus irgendelchen Gründen per Default deaktiviert.) Wie groß der Overhead ist, weiß ich nicht. Die 363 MiB stammen aus mehreren Jahren Computer-Nutzung; in der Zeit hat Windows Update ungefähr 2 GiB an Updates auf meinem PC installiert (plus viele manuelle Installationen bei Visual Studio und so); jedes ein Dutzend Dateien umfassend. Aus ein paar MSDN-Artikeln meine ich mich zu erinnern, dass da auch Kompression im Spiel ist (wahrscheinlich die NTFS-Standardkompression). Ja ich hasse den Overhead auf der Platte, aber so lange man diese Daten wieder löscht, sobald eine Transaktion vollendet ist, müsste er sich im Rahmen halten.

Japp, macht Sinn. Ich verstehe dein Argument, dass Microsoft das besser einmal implementieren sollte, als tausende Programmierer tausende Male. Ich verstehe aber nicht was Microsoft dazu veranlassen sollte, wenn diese tausenden Programmierer erstens nicht seine Kunden sind (Microsofts Kunden sind die Leute, die Office kaufen (früher) und irgendein Konglomerat aus Minecraft, XBOX, Metro Store, Cloud 365 Zeug (heute)) und zweitens von jemand anderem bezahlt werden. Es ist halt ein for Profit Unternehmen. Ich finds eigentlich schon ganz cool, dass sie ihr Zeug außer Office an Academia herschenken, dass ich es nutzen kann, auch ohne dass sie für mich Transaktionen implementieren, aber YMMV.

Ja, das mit der Kundenverschiebung ist ein Argument. Joel Spolsky hat vor 15 Jahren einen Artikel darüber geschrieben, dass Microsoft bis zum Ende der 90er die Programmierer durch die WinAPI bündeln konnte, für Windows zu programmieren, das dann aber aufgegeben hat. Und heute ist halt alles nur Apps.

Verdammt, Krishty, wir werden alt.

Seit wann beschönigst du was?

Wir sind alt!