jaenicke hat folgendes geschrieben:

elundril hat folgendes geschrieben: da er nicht mit Windoof-funktionen arbeitet. Wie soll das gehen? Ohne die Windows API wird der Total Commander wohl kaum arbeiten...

Ich glaube mit einem eigenen Treiber ist das schon möglich.

mfg

Wenn ich aber anfange und mir für den Windows Explorer Ersatz einen Treiber installeren soll, das ist doch hirnrissig. Dann kann ich gleich den Usermode in den Kernelmode hängen, weil dann jede Anwendung seinen Triber bekommt.

Etwas übertrieben, aber ihr wisst, was ich mein, Gruß
alias5000

Ich versteh aber nicht, was an der Rechnung Übertragungsgeschwindigkeit * Noch zu übertragende Daten so fehleranfällig ist...

F34r0fTh3D4rk hat folgendes geschrieben:

jaenicke hat folgendes geschrieben: elundril hat folgendes geschrieben: da er nicht mit Windoof-funktionen arbeitet. Wie soll das gehen? Ohne die Windows API wird der Total Commander wohl kaum arbeiten... Ich glaube mit einem eigenen Treiber ist das schon möglich.

Sicher ist es das, nur wäre eine Treiberinstallation bei mir geblockt worden, zudem wären dann nicht die Parallelen mit der schlechten Geschwindigkeit bei Vista vorhanden...

Wolle92 hat folgendes geschrieben:

Ich versteh aber nicht, was an der Rechnung Übertragungsgeschwindigkeit * Noch zu übertragende Daten so fehleranfällig ist...

ganz einfach: die ermittlung der Geschwindigkeit.
Man kann zwar "feste" Parameter auslesen/ermitteln oder Standardwerte nehmen. aber diese Werte entsprechen nicht immer dem möglichen.

Stell dir einfach mal zum Beispiel eine CD vor, die an einer Stelle verkratzt ist. (Jetzt nur mal als Extrembeispiel)
Jetzt dauert das Auslesen an dieser einen Stelle sehr lange. Vorher wurden 100 MiB in 20 Sekunden kopiert, jetzt dauert 1 MiB plötzlich 10 Sekunden. Welche Geschwindigkeit nimmst du jetzt? Die der aktuellen Sekunde? Was wenn alle 5 Sekunden eine Störstelle auftritt? Was wenn danach alles wieder glatt läuft?

Das Problem ist einfach, dass es starke Schwankungen der aktuellen Geschwindigkeit geben kann. Das interessiert dich aber eigentlich nicht als Benutzer, du willst trotzdem einen "guten" Wert haben. Du willst ja nicht, dass der Wert je nach gerade aktueller Geschwindigkeit hin- und herspringt.

Und an der Stelle kommen dann Approximationen und mehr oder weniger gute Algorithmen ins Spiel, die die Restzeit so realistisch wie möglich anzeigen. Aber eben nicht immer...

OK...

Ich hab heut auch was lustiges entdeckt.

Moderiert von Tino: BMP ins PNG Format umgewandelt.

Ja, bei dieser Installation kenne ich das, das ist genau solch eine Ausnahmebehandlung, wo das Programm selbst merkt, dass der Wert nicht so ganz stimmt. (In diesem Fall in der umgekehrten Richtung.) Und um den Benutzer nicht zu verwirren wird dann (ähnlich wie im Verkehrsverbund Berlin Brandenburg bei der Zugankunftsanzeige DAISY) nicht plötzlich wieder ein höherer Zeitwert angezeigt.

Aber wenn dann sowas eingebaut wird, ist es auch wieder lustig, deshalb: was soll man hinschreiben, wenn das Programm merkt, dass die Zeitangabe nicht stimmt oder gestimmt hat?

Viel lustiger ist ja, dass der liebe Ladebalken vorher einmal durchlief. Keine Ahnung, was da abläuft, aber einen Schmunzler wars allemal wert. Ich verurteile es ja nicht

Was mir auch auf den Geist geht, sind Ladebalken, die beliebig oft durchlaufen, z.B. beim Bootscreen von XP. Daran kann man doch höchstens ablesen, dass etwas passiert, aber nicht im geringsten, wie lange es noch dauert.
Spielt jemand zufällig Battlefield 2? Wenn ich da ein Spiel starte, bleibt der Balken immer erst 3/4 der Zeit am Anfang stehen und rast dann durch...

Solche Ladebalken finde ich noch schlimmer, als die andauernd durchlaufenden, denn da bin ich nicht immer sicher, ob es nicht doch einen Freeze gab.

elundril hat folgendes geschrieben:

da er nicht mit Windoof-funktionen arbeitet.

Ist ja interessant. Welche Funktionen benutzt er denn dann, wenn nicht die Windows-API Funktionen?

ich glaub mich dunkel daran zu erinnern das es auch sowas wie assambler gegeben hat. und das total-commander schon ziemlich lange existiert (ich glaube das erste is under Win 3.1 rausgekommen) könnte es ziemlich gut möglich sein das diese leute sowas verwenden.

lg elundril

Was verwenden? ASM? Auch wenn sie ASM verwenden, die einzige Schnittstelle zu Windows ist und bleibt die Windows-API. Und ob ich nun eine API-Funktion in ASM oder in einer Hochsprache aufrufe bleibt sich gleich.

Luckie hat folgendes geschrieben:

Was verwenden? ASM? Auch wenn sie ASM verwenden, die einzige Schnittstelle zu Windows ist und bleibt die Windows-API. Und ob ich nun eine API-Funktion in ASM oder in einer Hochsprache aufrufe bleibt sich gleich.

Frag mich nur grad, wie es dann Windows macht. Irgendwie muss ja CreateFile auch programmiert worden sein. Und wieso könnte man es dann nicht auch genauso machen? (Btw: gehen IO-Zugriffe nicht über INT 13h? Kann man den nicht irgendwie in Assembler aufrufen?)

Ich merk schon, wir schweifen langsam vom Thema des Threads ab..

Der direkte Hardwarezugriff ist unter Windows nur durch einen Treiber möglich (und eben durch das System). Einen solchen Treiber installiert der Total Commander aber nicht.

Und genau diese Diskussion hatten wir ein paar Beiträge früher schon...

jaenicke hat folgendes geschrieben:

F34r0fTh3D4rk hat folgendes geschrieben: jaenicke hat folgendes geschrieben: elundril hat folgendes geschrieben: da er nicht mit Windoof-funktionen arbeitet. Wie soll das gehen? Ohne die Windows API wird der Total Commander wohl kaum arbeiten... Ich glaube mit einem eigenen Treiber ist das schon möglich. Sicher ist es das, nur wäre eine Treiberinstallation bei mir geblockt worden, zudem wären dann nicht die Parallelen mit der schlechten Geschwindigkeit bei Vista vorhanden...

jaenicke hat folgendes geschrieben:

Der direkte Hardwarezugriff ist unter Windows nur durch einen Treiber möglich (und eben durch das System).

Und woher soll ich das wissen? Muss einem doch gesagt werden.. tststs..

Dann muss aber Windows (genauer theoretisch die Win-API) für sich selber auch nen Treiber haben.

Ich finds schon hammer, was Microsoft da zusammenbastelt. Ich habe in ein paar Stunden eine Restzeitbereichnung von MP3-Konvertierungen gemacht - und die verrechnet sich nur um Sekunden. Windows dagegen um Jahrtausende...

Es ist ja nicht so, dass das immer so ist, das sind relativ seltene Ausnahmefälle In jeder Software, in der mir das schon vorgekommen ist.
Dass es einfach ist für die meisten Fälle eine gute Restzeit zu berechnen ist klar. Es geht aber gerade um die Ausnahmefälle. Und inwiefern die bei dir berücksichtigt sind, weiß ich ja nicht. Stell dir vor, dass der Rechner für plötzlich stark ausgelastet ist, dann hast du die Entscheidung: nimmst du den Durchschnittswert insgesamt, dann hast du einen zu kleinen Wert, nimmst du nur den der letzten Sekunden, dann hast du evtl. einen zu großen.

Und genau das ist das Problem bei parallelen Festplattenzugriffen: Manchmal verzögern sich Zugriffe stark, weil gleichzeitig auf viele Dateien an unterschiedlichen Stellen der Festplatte zugegriffen wird, wodurch der Lesekopf stark bewegt wird. Das sind dann unvorhergesehene Verzögerungen, die in die Berechnung einfließen, ob realistisch oder nicht, hängt vom Algorithmus ab. Und das wichtige ist eben, dass es meistens realistisch ist.

Natürlich ist es nicht unbedingt schön, dass bei der Berechnung nicht derartig unrealistische Werte abgefangen werden, aber das Thema ist eben auch nicht ganz so einfach.