Archiv für November 2012

Wow64-Emulation mit 32/64-bit Architektur

Mittwoch, 28. November 2012

Ich hab damals ein klein wenig in der Registry auf meinem frisch installiertem Windows 7 PC rumgestöbert und dabei fiel mir ein Schlüssel unter HKLM\Software auf. Dieser hatte einen doch sehr merkwürdigen Namen und beinhaltete einen weiteren Microsoft\Windows Schlüssel und komischerweise auch mehrere Schlüssel von vorher installierten Programmen.


Diesen konnte ich noch nicht zuordnen und das Kurioseste war, er hatte im Filesystem einen Bruder, direkt im c:\Windows Verzeichnis:


Dieser hatte auch noch fast den gleichen Inhalt wie system32. Also dann hieß es ran ans Netz und recherchieren. Nach ein paar Stunden begann das Ganze einen Sinn zu ergeben.


Evolution der Prozessor-Architektur und ihre Folgen

Es war doch schon eine ganze Weile her, da sprachen CPUs nur in 8 Bit Wörtern zu ihrem Bus und damit war die Anzahl der übertragbaren Bits doch relativ begrenzt, nämlich auf 28. Einige weitblickende Menschen legten an dieser Stelle Hand an und die Prozessorarchitektur wurde weiter und vor allem breiter entwickelt. Der Bus wurde auf 216 Bits erweitert, die 16 Bit Architektur war geboren.

Die Prozessoren haben immer breitere Wörter bekommen und konnten damit auch deutlich mehr Speicher ansprechen. Es gab dabei trotzdem noch einige Hürden zu nehmen.

Eine Hürde war der maximale Arbeitsspeicher. Dieser ergab sich schlicht und einfach aus dem kleinen Rechenterm 2³². Das waren quasi 232 Bit die über den Prozessorbus übertragen werden konnten. 4294967296 Bit = 4 GB maximaler Arbeitsspeicher

Im x86 PC System wird aber auch noch ein kleines Stück dieses 32Bit Buses abgezwackt für so unwichtige Systeme wie Grafikkarten oder Soundkarten. Im Endeffekt war die maximale Menge RAM in einem 32bit Windows System 3.5 GB RAM. Prozessen wurde dabei maximal 2 GB RAM zugesichert, die größte Beschränkung der 32bit Prozessoren. Durch die fortschreitende Entwicklung der Prozessoren und durch die treibende Kraft hinter der PC-Entwicklung (insb. Games) wurde es bald nötig diese Grenze aufzuheben.

Im Serverumfeld war es schon lange Zeit Gang und Gäbe auf 64bit-Architektur zu wechseln und damit den maximalen Arbeitsspeicher auf 264, die astronomisch hohe Zahl 18446744073709551616 Bit, knappe 16 ExaByte, zu begrenzen.

Das ist natürlich eine unvorstellbare Menge… In RAM Riegeln á 4GB ausgedrückt: 4294967296 x 4 GB RAM Riegel (die Zahl kommt mir bekannt vor). Doch jetzt erst einmal genug zur Entstehung von 64 Bit Systemen.

Was hat das Ganze nun mit dem oben genannten Schlüssel und dem Ordner von vorhin zu tun? Dieser Sprung ist jetzt ein klein wenig komplizierter. Der breitere Bus und damit die veränderte Adressierung lassen es nicht zu, 32 Bit Prozesse unter der 64bit Architektur auszuführen, und jetzt kommt der Knackpunkt:

Der WOW64 Emulator (Windows on Windows 64bit) lässt es zu, in einem 64bit System ein 32bit System laufen zu lassen. Man spricht dann von einem WOW6432.

Kommt Ihnen der Name jetzt bekannt vor? Richtig! Der Name des Emulators ist in den Namen Wow6432Node und SysWOW64 enthalten.

Dieser Schlüssel bzw. Ordner enthält die Registrierungswerte und Dateien um eine komplette 32bit-Umgebung innerhalb des 64bit-Betriebssystems abzubilden. Dabei fällt auf, dass der Syswow64-Ordner fast die gleichen Dateien enthält wie das 64bit-Pendant, der system32-Ordner.

Dies lädt zu einer kleinen Spielerei ein, um den Unterschied zu demonstrieren: Man nehme eine CMD aus dem Verzeichnis c:\Windows\System32 und eine CMD sowie aus c:\windows\syswow64.

Jetzt frage ich einfach mal mit Hilfe des Befehls “reg” den Inhalt des Schlüssels HKLM\Software ab. 64 bit (links) und Syswow64 Prozess (rechts).


Was können wir nun hier sehen bzw. daraus ableiten?

Es ist nicht bzw. nur unter Umständen möglich, aus einem emulierten 32bit-Prozess heraus einen 64bit-Teil des OS anzusprechen. Man spricht hier von der sogenannten Ordner- und Registry-Umleitung. Die Ordner- und Registry-Umleitung kann mit Hilfe des sysnativen Pfades (c:\Windows\sysnative) umgangen werden, wenn 64bit-Teile geändert werden sollen.

Das Ganze ist praktisch einsetzbar, wenn z.B. mit Hilfe des SCCM 2007 Agents (32bit) Teile in einem 64bit Pfad der Registrierung geändert werden soll. Man spricht einfach unter dem 32bit Prozess den Sysnative Pfad an:


Die Lösung und Systematisierung

Der 64bit-Teil der Registry läuft nun unter einem 32bit-Prozess. 64Bit-Teile des OS lassen sich unter 32bit-Prozessen ausschließlich mit Hilfe des sysnativen Pfades ansprechen. Natürlich werden auch in den Systemvariablen die Ordner umgeleitet:

Variable Pfad unter 64bit Pfad unter 32bit
ProgramFiles C:\Program Files C:\Program Files (x86)
ProgramFiles(x86) C:\Program Files (x86) C:\Program Files (x86)
CommonProgramFiles C:\Program Files\Common Files C:\Program Files (x86)\Common Files

Autor: Sebastian Fischer

SharePoint: Unerwünschte Dateiformate (*.onebin) in Inhaltsabfragewebpart filtern

Montag, 19. November 2012

Wenn Sie OneNote-Notizbücher in einer SharePoint-Dokumentenbibliothek abgelegen, dann ist dies definitiv eine “best practice”. Wenn jedoch gleichzeitig eine Inhaltsabfrage über diese Dokumentenbibliothek läuft, dann werden unter anderem Bilder (zum Beispiel Screenshots), die im OneNote abgelegt wurden in Form einer hexadezimal betitelten Datei mit der Endung “onebin” angezeigt. Wir wollen diese Binaries aus dem Inhaltsabfragewebpart verbannen, da diese nicht nachvollziehbar betitelt sind. Mit Bordmitteln ist der Inhaltsabfragewebpart leider nicht in der Lage, einen Filter für unerwünschte Dateiformate zu definieren.

Wie zu sehen ist, tauchen die onebin-Dateien in den Ergebnissen der Inhaltsabfrage auf (siehe blaue Markierungen). Dies wollen wir unterbinden. Alles, was wir dafür benötigen, ist ein Editor (Notepad, SharePoint Designer, Visual Studio) und eine kleine Code-Anpassung – aber zunächst step by step.

Zunächst einmal sollten wir das Dateiformat des unerwünschten Typs eindeutig identifizieren. Dies tun wir mit einem Rechtsklick auf den Hyperlink der unerwünschten Datei. Wir stellen fest: das Format/die Dateiendung lautet “onebin”.


Um den Inhaltsabfragewebpart um das Filterkriterium “Dateiformat” zu erweitern, müssen wir diesen zunächst exportieren und mit einem Editor bearbeiten.


Relevant sind lediglich die beiden markierten Zeilen, die nun angepasst werden müssen.


Ersetzen Sie den Code in den markierten Textstellen (hier in Zeile 53 und 66) durch folgende Code-Zeilen. Je nach Ist-Konfiguration des Webparts sind die besagten Properties selbstredend in unterschiedlichen Zeilennummern zu finden. Eine Textsuche sollte hier Erleichterung bringen.

<property name=”AdditionalFilterFields” type=”string” />

<property name=”CommonViewFields” type=”string” />

Nach der Anpassung sollten die besagten zwei Codezeilen lauten wie abgebildet.


Speichern Sie den Webpart und importieren Sie ihn zurück ins SharePoint. Um dies tun zu können, müssen Sie “Besitzer” der Webseite sein. Falls Sie diese Berechtigung nicht haben, wenden Sie sich an Ihren SharePoint-Administrator.


Anschließend können Sie in den Webpart-Einstellungen den Filter definieren.


Der “Vorher-Nachher-Vergleich” (vorher=links, nachher=rechts) zeigt, dass die unerwünschten onebin-Dateien in dem Webpart “Letzte Dokumente” nicht mehr angezeigt werden. Weitere Artikel zum Thema OneNote hier.


Autor: Karsten Ulferts

Lohnt sich die Migration in die Cloud mit dem Team Foundation Server (TFS)?

Donnerstag, 08. November 2012

In der vergangenen Woche wurde die von Microsoft bereitgestellte Cloud-Variante des Team Foundation Server veröffentlicht. Die Beta-Phase ist damit beendet. Doch lohnt sich der Umstieg auf den “Team Foundation Service” bereits?

Zunächst stellt sich – wie bei allen Clouddiensten – die Frage nach der Sinnhaftigkeit der Verschiebung einer On-Premise Lösung in die Wolke. Speziell beim Team Foundation Server ist diese Frage schnell beantwortet: klar! Da in der Softwareentwicklung zunehmend eine Dezentralisierung der Teams festzustellen ist und dieser Trend durch die Verfügbarkeit von modernen Werkzeugen zur E-Collaboration unterstützt wird, ist bereits jetzt fast jeder TFS von “draußen” erreichbar und die Entwickler arbeiten von unterschiedlichen Standorten aus an dem gleichen Projekt.

Da oftmals auch bestimmte SLAs für den Betrieb von Software, etwa für die Fertigungssteuerung, einzuhalten sind, ist es meist sogar zwingend erforderlich, dass im Notfall von überall Zugriff auf den Quellcode gewährleistet ist. Abgesehen vereinfachter Bereitstellung und Zugriff gelten natürlich auch die bekannten Cloud-Vorteile im Allgemeinen.

Insofern ist der Ansatz durchaus sehr interessant, zumal die SVN- und Git-Konkurrenz auch nicht schläft.

Hinsichtlich Sicherheit und Compliance bestehen ja mitunter noch immer Vorbehalte, sobald das Wort “Cloud” fällt. Im Kontext der Softwareentwicklung sind diese aber aufgrund der fachlichen Nähe zu diesem Thema, wenn überhaupt vorhanden, eher gering ausgeprägt und mehr technischer statt prinzipieller Art. Für Windows Azure, welches die Grundlage für die Bereitstellung der TFS(ervices) bildet, existiert ein recht umfassender “Security Guide” der für die Zerstreuung letzter Bedenken sehr hilfreich ist.

Dennoch gibt es ein paar Einschränkungen, die derzeit (noch) für die Team Foundation Services gelten: Die Individualisierung von Prozesstemplates ist nicht möglich. Es besteht noch keine Integrationsmöglichkeit zu SharePoint, Project Server, etc. Es wird noch keine Active Directory-Federation unterstützt und es gibt geringere Reportingmöglichkeiten gegenüber dem klassischen Team Foundation Server.

Die wichtigste Neuerung, neben der Änderung der URL von “tfspreview.com” nach “tfs.visualstudio.com”, ist die Bekanntgabe der ersten Informationen zum Pricing. Eine sehr wichtige Information, da davon maßgeblich eine Entscheidung pro oder kontra abhängt: Teams bis zu 5 Entwicklern sind kostenlos. Die Anzahl an Projekten ist die beschränkt und aktuell kostenlos verfügbare Features, wie der Build Service, werden in der kostenlosen Version wahrscheinlich nicht verfügbar bleiben.

Dennoch existiert nach wie vor ein gewisser Unsicherheitsfaktor bezüglich der finalen Preisgestaltung, welche noch nicht feststeht und erst 2013 erscheint. Es ist jedoch davon auszugehen, dass schon allein aufgrund der Wettbewerbsfähigkeit eigentlich keine utopischen Preise aufgerufen werden dürften.

Die Infrastruktur ist also bereit und funktioniert. Wir haben intern die Preview schon seit längerer Zeit im Einsatz erprobt und ich kann guten Gewissens festhalten: keine substantiellen Probleme vorhanden. Ganz im Gegenteil, viele interessante Features funktionieren sehr gut. In ersten Versuchen bei einem unserer Entwicklungsteams haben wir zum Beispiel bereits sehr positive Erfahrungen mit dem Einsatz von KANBAN gemacht, welches sehr einfach auf zum Beispiel SCRUM aufgesetzt werden kann und bereits seit August zur Verfügung steht.

Genauere Details zu den angesprochenen Punkten können hier auch noch mal nachgelesen werden.

Der Umstieg klappte dabei unter Verwendung der TFS Integration Tools problemlos, eine entsprechende Anleitung steht im MSDN bereit. Letztlich handelt es sich aber um einen TFS 2012, es ist hilfreich, wenn man mit den zugehörigen Neuerung der 2012er Entwicklungslandschaft bereits einigermaßen vertraut ist.

Die abschließende Empfehlung lautet also auf jeden Fall, den Dienst unbedingt zu testen. Speziell für kleinere Projekte, an denen zum Beispiel mehrere Entwickler nur phasenweise arbeiten, kann man definitiv schon auf die Team Foundation Services setzen, zumal sich diese auch recht einfach übertragen lassen. Komplexe, größere Projekte sollten aber mindestens noch bis zur Veröffentlichung einer feststehenden Preisliste weiterhin lokal verwaltet werden.

Quelle: Security Guide, SCRUM, MSDN, TFS Integration Tools, Migration in die Cloud, Neuerungen

Autor: Tom Halank