Aber eine richtige Glanzleistung, die bei der Übersetzung entstanden ist, findet sich in diesem Artikel. Dort wird beschrieben, wie man eine Batch-Datei anlegt… die dann den Rechner wieder heile macht oder so in der Art. Der Inhalt ist folgender:

net Stop wuauserv
CD-%systemroot%\SoftwareDistribution
Ren Download.old herunterladen
Net start Wuauserv

Das sieht ein wenig merkwürdig aus. Alles englisch, plötzlich ein “herunterladen”, Groß- und Kleinschreibung und was ist “CD-%systemroot%\SoftwareDistribution” für ein Befehl? Die Zeilen aus dem englischen Original bieten Klarheit:

net stop wuauserv
cd %systemroot%\SoftwareDistribution
ren Download Download.old
net start wuauserv

Diese Clowns haben den Code mit übersetzt. Aus “Download” wurde “herunterladen” und weil es an der falschen Stelle steht passiert dort gar nichts. Wobei das eigentlich auch Wurst ist, denn mit “CD-irgendwas” kommt man auch nirgends an.

Ist das jetzt ein Einzelfall oder ist sämtlicher Code in diesen Artikeln potentiell nicht zu gebrauchen? Hat jemand nur vergessen, den Abschnitt mit “nicht übersetzen” zu markieren – oder ist das System dort womöglich dazu gar nicht in der Lage?!

Setup your system to detect your device.

• If you’re developing on Windows, you need to install a USB driver for adb. If you’re using an Android Developer Phone (ADP), Nexus One, or Nexus S, see the Google Windows USB Driver. Otherwise, you can find a link to the appropriate OEM driver in the OEM USB Drivers document.
• If you’re developing on Mac OS X, it just works. Skip this step.
• If you’re developing on Ubuntu Linux, you need to add a rules file that contains a USB configuration for each type of device you want to use for development. Each device manufacturer uses a different vendor ID. The example rules files below show how to add an entry for a single vendor ID (the HTC vendor ID). In order to support more devices, you will need additional lines of the same format that provide a different value for the SYSFS{idVendor} property. For other IDs, see the table of USB Vendor IDs, below.
  1. Log in as root and create this file: /etc/udev/rules.d/51-android.rules.For Gusty/Hardy, edit the file to read:
     SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"For Dapper, edit the file to read:
     SUBSYSTEM=="usb_device", SYSFS{idVendor}=="0bb4", MODE="0666"

It just works <3

Damals trat es still und heimlich durch mein damals verwendetes Antiviren-Programm verursacht auf und verschwand nach dem Tausch dessen sofort. Inzwischen bin ich einer anderen Ausprägung dieses Fehlers begegnet.

Evince und Inkscape (beide GTK, Zufall?) verursachen diesen Fehler bei mir sporadisch. Er äußert sich in einem Popup im Infobereich, der etwa so lautet:

*.exe – Datei beschädigt

Die Datei C:/[Pfad zur exe]/*.exe ist beschädigt und kann nicht gelesen werden. Bitte führen die CHKDSK aus.

Wobei letzteres keine Bitte ist, sondern ein Befehl, denn zugleich wird CHKDSK /r beim Systemstart angeordnet.

Und wie zu erwarten meldet sich Freund Backup mit den Worten

"wurde von der Windows-Sicherung übersprungen [...], da sich das Element auf dem beschädigten Laufwerk "C:\" befindet.

Und auch der alte Bekannte fsutil stiftet mir bei, fsutil dirty query C: bestätigt ein “beschädigtes” Dateisystem.

Mittlerweile wurde ich in den Kommentaren auf KB982927 von Microsoft aufmerksam gemacht. Dieser liefert dann auch eine Art Erklärung, da z.B. eine häufige, aufeinander folgende Verwendung von MoveFileEx() ein Ausnahme hervorrufen kann. Schon gruselig, denn es handelt sich damit definitiv um einen Bug im Dateisystem. Deshalb und da er recht selten zu sein scheint, wird der Hotfix nicht über Windows Update verteilt, sondern kann nur von Microsofts Seite manuell heruntergeladen werden. Ich habe ihn nicht installiert, da die genannte Dateiversion nicht zu meinem System passt.

Der Hotfix soll erstmals im SP1 enthalten sein, das erst im März 2011 erscheinen soll. Bis dahin bleibt mir wohl nichts anderes übrig, als ab und zu doch zu Rebooten, wenn dieser Fehler mal wieder seine hässliche Fratze zeigt.

Update: Service Pack 1 behebt das Problem scheinbar endlich.

THIS

Eigentlich sollte dieses eine Bild ausreichen, denn es illustriert das Problem, das Flash von schon immer hatte und bis in alle Ewigkeit haben wird einfach perfekt: Es ist ein Plugin und setzt als solches auf der Seite auf, es integriert sich nicht.

In diesem Fall ist die Beschreibung des Vollbildknopfes auf Youtube ist abgeschnitten, denn Flash kann nicht außerhalb seines festgelegten Canvas zeichnen. Es ist zwar möglich, Flash über einen Parameter genannt wmode anders zeichnen zu lassen und so auch HTML-Inhalte über das Video zu legen, was aber vor allem bei Video erheblich zu Lasten der Performance geht, siehe hier:

Flash Player 10.1 hardware rendering is automatically enabled on supported devices, and it’s not necessary to add the wmode=gpu embed parameter to enable it. However, when working with Flash Player 10.1, the wmode=opaque or wmode=transparent embed parameters will disable hardware rendering, causing the software to render the graphics.

Dabei ist das hier ein einfaches Beispiel, das nicht besonders weh tut. Viel schlimmer ist es, wenn Flash

• sich nicht mit der Tastatur bedienen lässt
• das Kopieren von Text unmöglich macht
• nicht zoombar ist, weil der Programmierer meinte, die Seite ist ohnehin Vollbild und der Text groß genug und überhaupt, wir benutzen alle 72dpi Computermonitore zum Betrachten seines Kunstwerkes
• alle Events klaut – auch solche, die es nicht benutzt – vor allem wheelup/down ARGH!
• nicht direkt verlinkbar ist
• schlecht mit Screenreadern zusammen arbeitet
• uvm.

Nein wirklich, wenn ich noch länger nachdenken würde fielen mir noch mehr Beispiele ein. Nur macht mich dieser Murks zusehends wütend und anschaulicher als “Full scr” werden sie wahrscheinlich nicht mehr.

PS: Hier das Video von oben. Natürlich in Flash m(

Die Variable browser.display.focus_ring_width bestimmt die Breite des Rahmens. Schnell in about:config auf 0 gesetzt verschwindet er sofort. <3 about:config

Das System sollte das Spielen nur ermöglichen, wenn eine Verbindung zu speziellen Ubisoft-Servern besteht. Bricht die Verbindung während dem Spielen ab wird das Spiel beendet und es muss am letzten Speicherpunkt neu begonnen werden, sobald die Server wieder erreichbar sind.

Ubisoft dementiert derweil kräftig, dass ihr perfekter Schutz bereits am Tag der Veröffentlichung geknackt wurde. Gecrackte Versionen von Silent Hunter 5 und Assassin’s Creed II seien unvollständig und nicht spielbar.

Die Meldungen sind noch widersprüchlich, aber es dürfte klar sein, was passiert ist. Ubisoft hat sich weit, sehr weit aus dem Fenster gelehnt und damit sämtliche Cracker dieser Welt auf ihren Code gehetzt. Selbst wenn erste Cracks nicht richtig funktionieren wäre das nicht das erste Mal. Ihre Nachfolger, die spätestens nach dem Wochenende online sein dürften werden funktionieren.

Bleibt die Frage, was Ubisoft nach diesem Debakel tun wird. Sie haben mit dieser Art Kopierschutz das Maximum an Verarschung des ehrlichen Käufers erreicht. Folgt als nächstes ein Versuch ohne Kopierschutz oder werden sie, vermutlich vergeblich versuchen, das aktuelle System durch eine sichere Implementierung zu verbessern? Ich bin hier ganz Pessimist und tippe auf letzteres.

Ich finde es erstaunlich wie hier scheinbar anthropologische Grundlagenforschung an kommerziellen Produkten betrieben wird. Einfach ausgedrückt versenkt ein Publisher hier zig Millionen in nicht nur ein, sondern gleich mehrere AAA-Titel, um an ihnen die Funktionstüchtigkeit eines Kopierschutzsystems und seine Akzeptanz unter den Spielern zu testen.

ACHTUNG: Ab hier folgt LOGIK

Für jeden normal denkenden Menschen sollte dieser Ablauf eigentlich vorhersehbar gewesen sein. Wie alle Menschen lieben Cracker Herausforderungen und Prestige. Beides bietet Ubisofts neues System. Als (simplifizierte) logische Formel ausgedrückt, etwa das:

normal denken -> System funktioniert nicht

Per Kontraposition ergibt sich daraus:

System funktioniert -> nicht normal denken

Daraus schließe ich, dass bei Ubisoft jemand in den oberen Etagen nicht ganz bei Trost ist. Das war angesichts der hervorragenden Öffentlichkeitsarbeit aber genauso vorhersehbar.

Update

Es ist passiert. Ubisofts DRM-Server sind down. Wir haben es ihnen gesagt. Und wie wir es ihnen gesagt haben. Unzählige Male. Sie wollten nicht hören. Während in Villaschutz noch zum Server verbunden wird, wird in Villacrack schon gezockt.

Aus dem Ubisoft-Forum:

“RAZOR/SkiDROW crack coming out tomorrow. No need to be online!”
“Don’t say nonsense…
It’s a FIX, not a crack.”

Köstlich.

Mac-User stimmen zu, Windows-User nicht. Woran liegt das?

Die Geschwindigkeit lässt definitiv zu wünschen übrig. Paradebeispiel ist Youtube, das mein Macbook mit Leichtigkeit auf Hochtouren bringt. Alles über 360p lastet einen Kern des 2,0 GHz Core 2 Duo voll aus und dropt dabei noch Frames. Ob Firefox oder Safari macht keinen Unterschied. Quicktime benötigt zum Abspielen nur einen Bruchteil der CPU-Zeit. Genaue Werte sind schwierig zu messen, aber die braucht es  auch nicht. Adobe hat offiziell zugegeben, dass Flash unter OSX langsamer läuft als unter Windows und gelobt Besserung, u.a. durch die Nutzung vorhandener APIs (Quicktime, Core Animation, etc.). Allerdings geht genau das laut Adobe nicht (Quelle):

Why is hardware decoding of H.264 only supported on the Windows platform?

In Flash Player 10.1, H.264 hardware acceleration is not supported under Linux and Mac OS. Linux currently lacks a developed standard API that supports H.264 hardware video decoding, and Mac OS X does not expose access to the required APIs. We will continue to evaluate when to support this feature on Mac and Linux platforms in future releases.

Ja was denn nun Adobe? API-Zugriff oder nicht? Es scheint zumindest unterschiedliche Meinungen zu geben.

Wie steht es nun mit der Stabilität des Flash Players. Windows-User können sich dort tatsächlich kaum beklagen und verstehen deshalb selten, wenn ein Macianer sich beschwert. Tatsächlich gibt es im Flash-Player für OSX seit Version 10 einen schwerwiegenden Bug, der für zahlreiche Abstürze verantwortlich ist. Dieser wurde September 2008 gemeldet, reproduziert und zu Behebung in der nächsten Version vorgesehen. Im Oktober erschien Version 10, zu zeitig, um ihn zu beheben und den Fix zu testen. Die bis heute noch nicht erschienene Version 10.1 wurde also zur nächsten. Nun mögen einige anmerken, dass nur schlecht programmierter Content Flash zum Absturz bringen würde. Dem ist nur entgegen zu halten, dass man mit ActionScript, der Programmiersprache von Flash, keine Abstürze produzieren kann. Wie der Name vermuten lässt handelt es sich bei ActionScript um eine zur Laufzeit interpretierte Scriptsprache. Die aktuelle Version ActionScript3 ist ein ECMAScript Dialekt, wie auch Javascript. Der Code wird also nicht vor der Ausführung compiliert, sondern interpretiert, was dem Interpreter genügend Spielräume lässt, um unvorhergesehene Fehler abzufangen. Wenn der Interpreter abstürzt, dann ist auch der Interpreter schuld. Genau das sagt auch Adobe (Quelle):

[It] is a tenet of the Flash Player team that ActionScript developers should never be able to crash Flash Player. If a crash occurs, it is by definition a bug, and one that Adobe takes very seriously.

Zur Verdeutlichung: Adobe weiß seit mittlerweile 16 Monaten von einem kritischen Bug im Flash Player für OSX, hat es aber bis heute nicht geschafft, ihn zu beheben. Verständlich, dass viele Mac-User “not amused” sind. Umso verständlicher erscheint langsam auch Jobs Position in der Sache.

Bleibt noch die Sicherheit. Natürlich finden sich im Flash Player Sicherheitslücken. Es scheinen nicht übermäßig viele zu sein, aber die Anzahl der Updates ist bei proprietärer Software immer mit Vorsicht zu genießen. Allzu oft werden mehrere Lücken in einem Update geschlossen, ohne genau zu erwähnen, was eigentlich das Problem war. Große Probleme gab es in jüngster Vergangenheit wie es scheint genug, sodass sich z.B. Mozilla dazu gezwungen sah, zunächst einen Updatecheck speziell für Flash einzurichten, was später auch auf andere installierte Plugins ausgeweitet wurde. Interessant ist in diesem Zusammenhang auch, was Flash so alles über die Browsernutzung speichert. So ist es Seiten in der Standardeinstellung z.B. erlaubt, Cookies und eine kleine Mengen an Daten auf dem Rechner zu speichern. Löscht man jetzt im Browser Cookies und Verlauf zeigt sich Flash unberührt. Um diese Daten los zu werden muss eine spezielle Seite aufgerufen werden, die ein spezielles Flash-Video enthält, über das diverse Sicherheitseinstellungen verwaltet werden können. Diese sehr merkwürdige Art, Einstellungen vorzunehmen findet man allerdings nur durch gezieltes Suchen, am besten per Suchmaschine. Adobe nimmt unsere Privatsphäre sichtlich ernst.

Was ist also bei Adobe los? Am schwerwiegendsten ist wohl, dass bisher nicht einmal versucht wurde mit ein Jobs einen Dialog zu beginnen (Quelle):

Knowledge@Wharton: But now there is a lot of contention around getting Flash on the iPhone.

Warnock: Oh, yes.

Knowledge@Wharton: Have you talked to Steve Jobs about that?

Warnock: No, I haven’t.

Knowledge@Wharton: Have you thought about calling him?

Warnock: I’ve thought about calling him and saying, “Steve, you know, at this point you want might to engage the partnership again.” Because I think otherwise he is going to get some competitive pressures from outside that he is not going to like.

Statt also einen gesunden Dialog mit dem Verantwortlichen bei Apple zu führen folgt bei Adobe ein PR-Stunt auf den nächsten, oft einfache Blog-Posts verschiedener Mitarbeiter, die ihre unterschiedlichen Meinungen kundtun. Öffentlichkeitsarbeit ist etwas anderes.

Fazit: Es stimmt also, auf dem Mac ist Flash langsam, stürzt ab und hat schwerwiegende Sicherheitslücken. Und Adobe unternimmt dagegen wenig. Jobs hat also recht. Aber ist das der Grund dafür, Flash auf den iDevices nicht zu zu lassen? Dazu demnächst mehr.

Die Dokumentation spricht von Java 1.2-Kompatibilität. Angeblich funktioniert es nur mit einer original Sun-VM. Ob das mittlerweile noch irgendwas mit der Realität zu tun hat, weiß kein Mensch. Jedenfalls läuft es weder auf meinem Mac, noch auf der Windose mit Sun-VM, noch auf dem Terminal im Projektraum.

Es scheitert wie es scheint daran, dass ein Properties-File nach “home” geschrieben werden muss, was aber nicht passiert. Ein Auszug aus diesem File von einer Linux-Maschine, auf der es funktioniert, spricht Bände:

Browser\ name=C\:/Programme/Netscape/Communicator/Program/Netscape.exe

Ich habe schon überlegt, ob ich nicht etwas ähnliches schnell in Python zusammenklöppeln sollte.

Update: Nachdem ich das Tool fast komplett zerlegt hatte, offenbarte sich mir die Ursache des Fails. Eine mitgelieferte, native Library konnte nicht geladen werden. Und zwar nicht, wie die Fehlermeldung vermuten lassen möchte, weil die Datei nicht gefunden wird, sondern weil sie nicht im richtigen Format vorlag. Ein falsches Format konnte in diesem Fall eigentlich nur PowerPC statt Intel bedeuten. Kurz gegooglet, compiled und läuft.

Ein gutes Beispiel, wieso man Fehler nicht mit Exception abfangen sollte.

So erscheint es auch nicht unlogisch, dass ich keinerlei Probleme mehr habe, seit ich Antivir durch Microsoft Security Essentials ersetzt habe. Für Microsofts frisch erschienenes, kostenloses Tool sprach die nach ersten Tests gute Erkennungsrate und, dass keine kostenpflichtige Version angeboten wird. MSE hält sich entsprechend auch im Hintergrund, denn es muss nicht für die kostenpflichtige Security-Suite werben und es gibt auch keine periodischen Meldungen, dass der Rechner toll geschützt wird. Oder ganz schlimm, dass Angriffe auf längst gepatchte Sicherheitslücken abgefangen wurden (Blaster lässt grüßen).

Und ich hoffe ihr könnt euch vorstellen, wie angenehm es ist, wenn Backups plötzlich einfach so im Hintergrund passieren, ohne, dass man etwas merkt. Um einen zeitgenössischen Colafabrikant zu zitieren:

[Windows 7,] so, wie es sein sollte.

Update: Fast ein Jahr später nochmal Neuigkeiten. Ich habe einen weiteren Artikel geschrieben, der ein Paar Hintergründe und einen möglichen Patch von Microsoft aufzeigt.

Update 2: Service Pack 1 behebt das Problem scheinbar endlich.

Die Geschichte von Windows-Backups ist eine Geschichte voller Missverständnisse. Kennen sie das auch, wenn sich ihr Dateisystem mal nicht ganz frisch anfühlt? Ich schon, denn seit ein paar Wochen passiert das ständig

Die Konsequenz ist, dass das geplante Backup durchläuft, am Ende feststellt, dass D beschädigt ist, die Sicherung für unvollständig erklärt und zum Schluss noch ganz böse guckt. Die Daten verbleiben allerdings allem Anschein nach am Sicherungsort. Ob sie dann wiederhergestellt werden können, ist aber mehr als fraglich. Da das letzte Backup unvollständig war, ist das Nächste natürlich nicht nur ein Inkrement, sondern eine vollständige Sicherung. Hach, ohne Unsicherheit wären Computer doch nur halb so spannend.*

Die übliche Vorgehensweise ist natürlich erst mal CHKDSK durchlaufen zu lassen, etwa so

chkdsk D: /f /x

Keine Fehler.

OK, vielleicht liegts an der Festplatte, also mal

chkdsk D: /r

aber ein paar Stunden später erneut: keine Fehler.

Vielleicht weiß das Festplattentool vom Hersteller mehr… aber auch da keine Fehler, selbst im Intensivmodus. Es ist also wenigstens kein Hardwaredefekt.

Langsam wird mir die Chose zu bunt, also Frage ich Tante Gurgel. Die fördert erstmal folgenden Befehl zu Tage:

fsutil dirty query D:

Und ja, dieses Tool widerspricht CHKDSK und bestätigt, dass D beschädigt ist. Was denn nun? FSUTIL sagt beschädigt, CHKDSK sagt, dass es keine Fehler findet. Führt man es allerdings nach CHKDSK aus sind sich beide einig und alles ist scheinbar OK. Bis der Fehler wenig später wieder auftritt. Irgendwas stimmt hier nicht. Wenn Dateisystemfehler tatsächlich so zahlreich auftreten würden wäre etwas ganz schön im argen. Dabei funktioniert das System sonst tadellos. Also weiter gurgeln… und finden. Tatsache, es gibt einen Bug in Windows 7, durch den scheinbar das “dirty”-Bit im Dateisystem fälschlicherweise gesetzt wird.

Einen Fix oder Workaround habe ich noch nicht gefunden. Es gibt aber einen Hinweis Richtung Avira, das ich verwende.

* Wie ich bereits festgestellt habe ist Apple totlangweilig.

Update: Ich habe mittlerweile Antivir durch Microsoft Security Essentials ersetzt und seitdem keinerlei Probleme mehr. Ich habe zum Thema einen Folgeartikel geschrieben.

Update 2: Fast ein Jahr später nochmal Neuigkeiten. Ich habe einen weiteren Artikel geschrieben, der ein Paar Hintergründe und einen möglichen Patch von Microsoft aufzeigt.

Update 3: Service Pack 1 behebt das Problem scheinbar endlich.