News Teil-Lösung für Mouse-Lag in Windows 8.1

SkipOutLaw schrieb:
In diesem Fall: nur wenn der OS-Hersteller Microsoft heißt :)
Microsoft geht schon oft genug auf idiotische Programmierer ein um die Abwärtskompatibilität nicht zu gefährden.
Was meinst du wem wir die Kacke zu verdanken haben, dass sich die 64 Bit DLLs im System32 Ordner befinden?
Nur den Leuten, die "c:\windows\system32" in ihre Programme hardcoded einprogrammiert haben.

Das geht sogar hin bis zur Kernelversion. Der Grund warum Windows 7 nicht die Kernel-Version 7 bekommen hat, sondern nur Kernel Version 6.1 ist, weil viele Programmierer immer nur überprüft haben, ob die MajorVersion = 6 ist und haben dann die neuen Aero Features aktiviert.
Bei Tests ist MS aufgefallen, dass mit Kernelversion 7 dieses Features in Windows 7 dann aber auf einmal alle wieder deaktiviert wurden. Also hat man als Notlösung nur die Minor-Number des Kernels erhöht, obwohl in Wahrheit sogar der neue MinWin Kernel eingeführt wurde.

Windows steckt voller Ungereimtheiten, weil man auf idiotische Programmierer rücksicht nehmen muss, doch manchmal geht es halt nicht anders, wenn dadruch 5% der Programme nicht funktionieren.
Wenn es aber nur eine Hand von Spiele sind, dann ist das kein Beinbruch und die Spieleentwickler müssen sich anpassen. Nicht Microsoft.

Natürlich sieht es von außen so aus, als sei alles Microsofts Schuld, aber wenn man alles mal ganz nüchtern betrachtet, dann ist es schon erstaunlich, was nach den tausenden von Änderungen die bei einer neuen Betriebssystemversion vorgenommen werden anschließend trotzdem noch alles einwandfrei funktioniert. Da wurde schon ausführlich getestet was das Zeug hält.
 
@noxon: das liegt aber nur zum Teil an den "idiotischen" Programmierern, denn es muss ja vormals auch "Idioten" gegeben haben, die das exakt so vorgesehen hatten. Und das waren nun mal die von Microsoft. Hätten sie mal lieber diesen Schritt/Schnitt vor Win7 oder noch besser vor XP gemacht, denn Win8 hat es auch ohne diese "absichtlichen" Inkompatibilitäten schon weiß gar nicht leicht ...
 
@noxon

Kein Panik, ich wollte damit nur zum Ausdruck bringen, dass gewisse Leute hier im Forum immer gegen MS schießen, ganz egal was sie auch machen.
 
romeon schrieb:
das liegt aber nur zum Teil an den "idiotischen" Programmierern, denn es muss ja vormals auch "Idioten" gegeben haben, die das exakt so vorgesehen hatten. Und das waren nun mal die von Microsoft. Hätten sie mal lieber diesen Schritt/Schnitt vor Win7 oder noch besser vor XP gemacht, denn Win8 hat es auch ohne diese "absichtlichen" Inkompatibilitäten schon weiß gar nicht leicht ...
Was für absichtliche Inkompatibilitäten? Wer hat das so vorgesehen? Wieso muss es "vormals" so etwas gegeben haben? Ist ja nicht so, dass nicht jeder "Entwickler" einfach mal so irgendwas hinzaubern kann. Schön wie du aber versuchst es MS anzulasten, weil sie eine Möglichkeit im Fall der Fälle anbieten. Deswegen ist es nicht der richtige Weg.

Wer ist aber eigentlich dran Schuld, dass "Entwickler" "C:\Windows\system32" im Pfad angeben? MS natürlich, weil die den Pfad einfach nicht im Nachhinein ersetzen und somit schöne Seiteneffekte und nicht vorhergesehen Bugs mit ins Programm durch den Compiler schleusen. Natürlich...

Es gibt nun mal nicht umsonst Umgebungsvariablen, die auch genutzt werden sollen. Wenn sich Hanswurst eben denkt "brauch ich nicht", ist das nicht die Schuld vom OS-Hersteller. %userprofile%, %systemroot%, %appdata%, %temp%, %programfiles% etc. gibt es nicht, weil MS absolute Pfade liebt. Und selbst wenn es MS so machen sollte, gibt es immer noch keinen Grund, warum ein anderer Entwickler es nicht richtig machen sollte. Dilettanten-Entwickler gibts leider viel zu oft und wenn man sich so manchen Spaghetti-Code ansieht, wo selbst in C++ noch (sinnlose) gotos [1] verwendet werden, muss man sich nicht wundern. Wenn jeder auch nur die API richtig verwenden würde, gäbe es gar nicht solche Inkompatibilitäten.

Wunderbar auch an versauter Verschlüsselung einiger Entwickler zu sehen, da sie zwangsweise meinen, die Verschlüsselung selbst implementieren zu müssen, anstatt bspw. auf OpenSSL zu setzen und so vorhandenes und bewährtes zu nutzen.

Ein sehr schönes Beispiel ist auch LoadLibrary().
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx schrieb:
If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.
Manche "Entwickler" meinen hier aber eine eigene DLL mitzuliefern und einzubinden müssen. Das resultiert dann in der bekannten DLL-Hell, was spätestens seit Vista mit dem WinSxS-Verzeichnis der Vergangenheit angehören sollte. "Entwickler" laden DLLs dann eben per "./abc.dll". Schon krachts und abc.dll wird immer aus dem Arbeitsverzeichnis geöffnet werden. Würde man stattdessen "abc.dll" angeben, würde Windows sich darum mit bestimmtem System kümmern, die richtige DLL mit richtiger Version herauszusuchen.

Wo war die Schuld nochmal? Nicht beim OS-Hersteller... Entwickler halten sich einfach nicht an Vorgaben, sei es aus Faulheit (nicht lesen wollen), Sturheit (ach das passt schon so wie es ist) oder Überheblichkeit (ich kann das genauso gut bzw. besser). Das passende Beispiel haben wir in dieser News!

Der nächste Graus, ist das Zusammenstellen von Pfaden. Da wird in PHP bspw. eben require 'abc/'.$def.'/ghi/jkl'.$mno.'.php' gemacht. Es wäre ja zu einfach eine Funktion zu schreiben, die mir einen sauberen Pfad zurückgibt, welche ich einfach mittels BuildPath( 'abc', $def, 'ghi/jkl', $mno.'.php' ); aufrufen könnte und zudem bspw. noch OS unabhängig laufen könnte (Windows \, Linux/Mac / als Path Delimiter).

Anderes Thema...

edit:

[1] Nicht dass sie sinnlos sind, aber im dortigen Code eben sinnloserweise verwendet werden.
 
[Arnold] schrieb:
Der Patch hilft gegen bei Problemen mit einer zu niedrigen USB-Polling-Rate bei Gaming Mäusen nichts, jedenfalls in meinem Fall nicht (CM Storm Recon, Windows 8.1 + Patch, Max. Polling Rate (gemessen mit Mouse Rate Checker) 200 Hz, Soll wäre 1000 Hz).

Hast du auch mal den mousemovementrecorder als "custom datei", wie in dem workaround auf der microsoft seite beschrieben, hinzugefügt? bei mir funktioniert das danach tadellos :)
 
Yuuri schrieb:
Weil MS keine Einsicht in deren Quellcode erhält und mit Sicherheit auch nicht erhalten will. Bisher hat doch alles funktioniert, wer denkt also daran, dass Entwickler falsche Methoden nutzen? Ergo ein Bug, der bisher nie aufgetreten ist.
Wozu braucht MS Einsicht in den Quellcode? Wenn sie davon ausgehen, dass diese API niemand mehr nutzt hätten sie sie längst rausstreichen können. Würden sie davon ausgehen, dass sie noch genutzt wird haben sie versagt.

Yuuri schrieb:
Wirklich? Ich hab mir den Spielexplorer ein Mal angesehen und ihn sonst nie angefasst.
Mit dem "My Games"-Ordner meine ich nicht den Spieleexplorer sondern den zentralen Ordner für Spielstände. Das hat MS damals mit XP gehörig verpennt.

Clint schrieb:
Soll MS die Spiele der 1000 Entwickler testen? Irgendwie drehen wir uns im Kreis :freaky:
Ist gar nicht nötig, ein paar Stichproben hätten genügt um festzustellen, dass es Probleme gibt. Aber dass MS der PC als Spieleplattform ziemlich egal ist ist ja nichts neues. Die Prioritäten liegen da woanders, auch wenn gerne das Gegenteil behauptet wird.

Kassenwart schrieb:
Natürlich sollten sie das. Wenn Microsoft ein neues Betriebssystem herausbringt dann müssen wir z.B. dafür sorgen das unsere Software damit läuft. Haben sich Schnittstellen geändert dann müssen wir uns anpassen.
Ich nehme mal stark an, dass eure Software Nachfolger erhält die den Vorgänger komplett ersetzen und nur relativ aktuelle Versionen noch supportet werden.
Bei Spielen ist es nun mal so, dass diese keine Nachfolger erhalten. Daher hinkt dein Vergleich.
 
Ich nehme mal stark an, dass eure Software Nachfolger erhält die den Vorgänger komplett ersetzen und nur relativ aktuelle Versionen noch supportet werden.

Falsch unsere Software bekommt Updates. Supported wird JEDE Version die noch beim Kunden im Einsatz ist.

Bei Spielen ist es nun mal so, dass diese keine Nachfolger erhalten. Daher hinkt dein Vergleich.

Wieder Falsch. Spiele bekommen genauso Updates. Teilweise über Jahren hinweg. Ich habe Spiele die teilweise über 20 Gigabyte an
Updates erhalten haben. Von daher hinkt hier gar nichts.
 
Der Landvogt schrieb:
Wozu braucht MS Einsicht in den Quellcode? Wenn sie davon ausgehen, dass diese API niemand mehr nutzt hätten sie sie längst rausstreichen können. Würden sie davon ausgehen, dass sie noch genutzt wird haben sie versagt.
Dir sagt Kompatiblität was? Was meinst du warum heutige 32 Bit Systeme selbst noch alte DOS-Games ausführen können? Nicht weil man APIs streicht, sondern Kompatiblität erhält.

Und MS würde Einsicht in den Quellcode benötigen um genau zu sehen, welche Nachrichten die Anwendungen wo abfangen. Wieso wohl wurde jedem Gamer geraten, die Mausbeschleunigung zu deaktivieren? Weil anscheinend damals schon einige Entwickler zu blöd waren, die richtigen Methoden und APIs anzusprechen, womit dies eben nicht auftritt. Man braucht im Prinzip Fixes für Sachen, die so eigentlich gar nicht passieren sollten, wenn die Entwickler auch nur zwei Sekunden mitdenken, lesen und es umsetzen würden.

Außerdem wird WM_MOUSEMOVE systemweit auf dem Desktop genutzt. WM_INPUT ist u.a. prädestiniert für Spiele und Anwendungen, die ungefilterte Positionen benötigen, ohne jeglichen Einfluss von Beschleunigung o.ä. Sachen, die damit noch angestellt werden.
Der Landvogt schrieb:
Ist gar nicht nötig, ein paar Stichproben hätten genügt um festzustellen, dass es Probleme gibt. Aber dass MS der PC als Spieleplattform ziemlich egal ist ist ja nichts neues. Die Prioritäten liegen da woanders, auch wenn gerne das Gegenteil behauptet wird.
Wenn Drittentwickler Funktionen falsch verwenden, muss natürlich das System drumherum gestrickt werden. Eben nicht, das System gibt Vorgaben, an welche sich Drittanbieter halten müssen, um eine korrekte Funktionsweise zu gewährleisten.
 
An dem Problem sind klar die Spieleentwickler schuld, die die falche API nutzen.

Es gibt einen Grund warum es mehrere verschiedene Möglichkeiten gibt Nutzereingaben zu verarbeiten.
Es gibt im MSDN nen Artikel dazu: Taking Advantage of High-Definition Mouse Movement

Kleiner Auszug daraus:
The primary disadvantage to data from WM_MOUSEMOVE is that it is limited to the screen resolution. This means that if you move the mouse slightly — but not enough to cause the pointer to move to the next pixel — then no WM_MOUSEMOVE message is generated. So, using this method to read mouse movement negates the benefits of high-definition input.

The advantage to WM_MOUSEMOVE, however, is that Windows applies pointer acceleration (also known as ballistics) to the raw mouse data, which makes the mouse pointer behave as customers expect. This makes WM_MOUSEMOVE the preferred option for pointer control (over WM_INPUT or DirectInput), since it results in more natural behavior for users. While WM_MOUSEMOVE is ideal for moving mouse pointers, it is not so good for moving a first-person camera, since the high-definition precision will be lost.
Ich habe mal die relevanten Stellen hervorgehoben.
Es wird deutlich, das WM_MOUSEMOVE in Spielen nur dann genutzt werden sollte, wenn man einen Mauszeiger anzeigt (also in Menüs, oder evtl. bei Point & Click Adventures o.Ä.)

Es gab ne Developer Preview von Win 8.1.
Wenn die Entwickelrstudios es nicht selbst gebacken bekommen ihre Spiele ordentlich zu testen, dann ist das ihr Problem.
MS kann nicht die Qualitätskontrolle für andere Firmen übernehmen.
 
CrazyT schrieb:
Hast du auch mal den mousemovementrecorder als "custom datei", wie in dem workaround auf der microsoft seite beschrieben, hinzugefügt? bei mir funktioniert das danach tadellos :)

Nein, das hatte ich nicht, danke für den Hinweis. Bedeutet das, dass auch diese Software nicht korrekt die API nutzt und deshalb dieses Problem nur ein Problem der Software, nicht aber des Betriebssystems ist?
 
Der Landvogt schrieb:
Ist gar nicht nötig, ein paar Stichproben hätten genügt um festzustellen, dass es Probleme gibt.
Wie stellst du dir denn vor, wie Microsoft seine Software testet?
Die stellen hunderte von Leute ein, die jeden Tag nur damit beschäftigt sind alle möglichen Programme zu benutzen um zu überprüfen, ob damit irgendwelche Fehler auftreten?

Software muss progammatisch, automatisch und regelmäßig getestet werden. Da wird nicht nur einmal kurz vor dem Release getestet ob alles funktioniert.

Und da du die 50 Millionen Zeilen Quellcode von Windows eben nur mit Testprogrammen testen kannst und nicht durch regelmäßiges durchspielen von Call of Duty werden solche Effekte halt übersehen.
Die Testprogramme melden das Ganze natürlich auch nicht als Fehler, weil es eben kein Fehler des Betriebssystems ist, sondern einer von Call of Duty, oder funktioniert deine Maus im Moment auch nicht?

Also. Das mit deinen Stichproben kannst du vergessen. Es macht genug Arbeit die Testprogramme zu schreiben. Die allein sich vom Umfang her möglicherweise schon größer als Windows selbst.
 
Zuletzt bearbeitet:
Kassenwart schrieb:
Falsch unsere Software bekommt Updates. Supported wird JEDE Version die noch beim Kunden im Einsatz ist.

Wieder Falsch. Spiele bekommen genauso Updates. Teilweise über Jahren hinweg. Ich habe Spiele die teilweise über 20 Gigabyte an
Updates erhalten haben. Von daher hinkt hier gar nichts.
Dann seit ihr eine große Ausnahme. Ich kenne keinen bekannten Hersteller der so verfährt.

Abgesehen von Blizzard-Spielen fällt mir neben CoH spontan kein einziges ein, welches min. 5 Jahre supportet wurde. Selbst bei BF2 wurde der Support nach 4 Jahren eingestellt.
Da hätte ich gerne mal ein paar Beispiele abseits von MMOs bei denen das schließlich nicht anders geht.
IdR wird der Support nach einem Jahr eingestellt. Ist auch verständlich wenn das Spiel rund lief.

Yuuri schrieb:
Wenn Drittentwickler Funktionen falsch verwenden, muss natürlich das System drumherum gestrickt werden. Eben nicht, das System gibt Vorgaben, an welche sich Drittanbieter halten müssen, um eine korrekte Funktionsweise zu gewährleisten.
Wenn Drittentwicker nach 10 Jahren Funktionen immer noch falsch verwenden muss auch bei MS einiges schief gelaufen sein. Es handelt sich offensichtlich ja nicht um Einzelfälle.

noxon schrieb:
Wie stellst du dir denn vor, wie Microsoft seine Software testet?
Die stellen hunderte von Leute ein, die jeden Tag nur damit beschäftigt sind alle möglichen Programme zu benutzen um zu überprüfen, ob damit irgendwelche Fehler auftreten?
Dazu braucht es nicht hunderte von Leuten. In diesem Fall hat man ja bewusst was gestrichen, man hätte also nicht jede einzelne Funktion und jeden Level eines Spiels testen müssen sondern hätte gezielt testen können. Das hat man offensichtlich verpennt.
 
Der Landvogt schrieb:
... Es handelt sich offensichtlich ja nicht um Einzelfälle. ...
Naja, so sehr viele Fälle sinds jetzt aber auch nicht. Und wenn ich mir den Streit zwischen Adobe und Apple um 2010 herum so anschaue, als es darum ging, dass Adobe damals in der CS auf Windows 64b einführte, auf dem Mac aber bei 32b bleiben musste und damit die Mac-Platform für Leute, die mit Adobe-Programmen arbeiten, unattraktiver machte, nur weil Adobe, eines der größten Desktop-Software-Unternehmen der Welt, seine Software auch zehn Jahre, nachdem Apple ganz offiziell zur Carbon-API gesagt hatte, dass sie lediglich in einer Übergangsphase zur Verfügung stehen würde, um alte OS9-Programme leichter portieren zu können, seine dicke fette Software-Suite mit Carbon baute und sich darüber beschwerte, dass Apple Carbon nicht auf 64b portierte... Man sieht, wo das hinläuft. Programmentwickler nehmen sich gerne mal auch Arroganz heraus, ihre falschen Entscheidungen gegen OS-Hersteller durchzuprügeln. Adobe hat gegen Apple in diesem persönlich gewordenen Streit verloren, weil Steve Jobs dann irgendwann einfach Flash vom iPhone AppStore ausgeschlossen hat. (und Apple mit FinalCut pro eine Alternative parat hatte) Dafür hat Adobe Apple erfolgreich aufgezwungen, Case-Insensitivity im Dateisystem zu erhalten. Aber Anwendungsstudios probieren sowas halt immer wieder und nicht nur, aber besonders, Windows leidet darunter.
 
von dem Update gibt es eine Version 2:

Die neue Version der win32k.sys lautet nun 6.3.9600.16456.
 
Wie schaut es denn aus bei dem Thema? Habe meinen Spielerechner noch nicht auf Win 8.1 gezogen. Gibt es die Probleme noch bzw. ist seitens MS eine Lösung zu erwarten?
 
Es wird keine Lösung seitens MS geben, denn die Entwickler sind zu doof die richtigen APIs zu nutzen. Wenn du eine Lösung willst, installier den Patch, der einen Fallback auf die alte Lösung darstellt und gut ist.
 
der Patch ist Teil vom letzten Update Rollup. Wenn du das installiert hast sind schon mal einige Spiele abgedeckt.
 
Zurück
Oben