Beiträge von Jar Jar Binks

ich würde an deiner stelle erstma viren prog drauf machn, und scannen lassen.
dann die viren rauschmeißen wenn der bestimmte virus immer noch da ist rate ich zu formatieren, denn es gibt viren oder würmer, die sich in deinem systemvestecken, die nichtmal nen viren prog findet, sondern nur eine extra datei die vom eigentlichen Virus angelegt wurde und somit kannst du nur die Datei finden, aber das eigentliche virus nicht.
ich rate dir aber eher dazu, zu formatieren, neu aufsetzen,
als allererstes virenscanner mindestens einer, besser 2 (die sich miteinander vertragen) und dazu noch ne softwarefirewall. damit bist du auf der besseren Seite was Viren und Würmer angeht.

Under Cover
Leider lassen sich mit den bisher vorgestellten Methoden noch nicht alle Fehlerursachen eindeutig erkennen. Vor allem wenn diese Bemühungen bei jedem Crash ein anderes Bild liefern, ist Misstrauen angezeigt: Der Verdacht fällt dann zunächst auf Hardwareprobleme wie vergesslichen Hauptspeicher oder einen unzuverlässigen Festplatten-Controller. Trotzdem kommen immer noch Treiber-Malaisen als Ursache in Frage. Es kann nämlich sein, dass eine Systemdatei Unordnung in die Datenstrukturen des Kernels bringt, was dem aber nicht sofort auffällt. Erst ein späterer harmloser Aufruf eines eigentlich intakten Treibers stolpert dann über diese Falle und gerät zu Unrecht in Verdacht, den Crash verursacht zu haben.

Häufig versteckt sich der für den Crash verantwortliche Treiber im Aufruf-Stack.

Zum Aufspüren dieser Art von Fehlern bringen Windows 2000 und XP von Haus aus eine erweiterte Treiberüberprüfung mit. Einstellen lässt sich dieses Diagnosewerkzeug, indem man per „Start/Ausführen“ das Programm verifier aufruft. Es stellt verschiedene Möglichkeiten zur Auswahl, mit denen Windows geladenen Treibern auf die Finger schaut. Verstößt ein Treiber gegen die verschärften Spielregeln, erzeugt die Treiberüberprüfung einen speziellen BSOD, dessen Speicherabzug sich dann wie oben beschrieben analysieren lässt.
Unter Windows XP ist der verifier als Wizard ausgelegt, bei dem man sich durch verschiedene Schritte klicken muss. Folgende Einstellungen haben sich bewährt: Auf dem ersten Schirm „Benutzerdefinierte Einstellungen verwenden“, im zweiten Schritt „Vordefinierte Einstellungen verwenden“, „Standardeinstellungen“ und „Simulierung geringer Ressourcen“. Im dritten Teil der Einstellung reicht es meist, die nicht signierten Treiber automatisch auswählen zu lassen – die signierten haben diese Tortur ja schon hinter sich. Um Wechselwirkungen auszuschließen, kann man hier auch „Treiber aus einer Liste wählen“ anklicken und im letzten Schritt alle Treiber überprüfen lassen, die nicht von Microsoft stammen.
Der verifier von Windows 2000 zeigt alle Optionen gemeinsam auf dem Register „Einstellungen“ an. Hier sollte man „Ausgewählte Treiber überprüfen“ markieren, in der Liste alle nicht von Microsoft stammenden Treiber auswählen und unten auf „Überprüfen“ klicken. Anschließend kann man durch einen Klick auf „Bevorzugte Einstellungen“ die gängigsten Überprüfungen aktivieren und das Ganze per „Übernehmen“ bestätigen. Sowohl unter Windows XP als auch unter Windows 2000 werden die Einstellungen mit dem nächsten Neustart aktiv.

Nicht übersehen sollte man, dass die Treiberüberprüfung ein zweischneidiges Schwer ist: Zwar identifiziert sie recht zuverlässig Treiber, die sich nicht anständig benehmen. Nimmt man aber zu viele Treiber in de Prüfung auf, kann das das System bis zur Unbrauchbarkeit herunterbremsen.
Außerdem kann die Treiberüberprüfung dafür sorgen, dass einer der Checks schon beim Booten zuschlägt und so einen Systemstart verhindert – den man aber braucht, um sie wieder abzuschalten. Ihre Einstellungen speichert die Treiberüberprüfung im Systemzweig der Registry. Von dem sollte man daher sicherheitshalber mit Hilfe der Wiederherstellungskonsole eine Kopie anlegen, bevor man die Treiberüberprüfung aktiviert.

Verurteilung

Mit der Erkenntnis, welche Treiber am Zustandekommen des BSOD beteiligt gewesen sein könnten, geht es nun daran, Abhilfe zu schaffen. Zunächst lohnt es sich, mit WinDbg nach weiteren Informationen über die Treiberdatei zu fahnden. Dazu übergibt man den Namen des verdächtigen Moduls an den Befehl lm. Ist Ihnen beispielsweise die Datei bsod.sys ins Auge gefallen, lautet der komplette Befehl
Lm v mbsod

Hinter dem „lm“ kommt ein Leerzeichen, dann ein „v“, noch ein Leerzeichen und anschlißend ein „m“, an das der Name des Moduls ohne Dateiendung unmittelbar angehängt wird. Mit etwas Glück enthält die Ausgabe dieses Befehls den kompletten Dateinamen samt Pfad der Treiberdatei und gibt Auskunft über den Hersteller. Wenn nicht, hilft nur noch die Brechstange: Der Befehl
!devnode 0 1

gibt eine Liste aller geladenen Gerätetreiber aus. In der kann man mit dem Menübefehl „Edit/Find“ nach dem verdächtigen Modulnamen – wieder ohne Dateiendung – suchen. In dem Eintrag, in dem er hinter „ServiceName“ erscheint, ist der „InstancePath“ interessant – merken oder notieren.
Alsdann startet man das Programm regedit, navigiert nach
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum und von dort weiter entlang dem in InstancePath angegebenen Pfad . Hier verrät der Eintrag „ DeviceDesc“, um was für ein Gerät oder Treiber es sich handelt, und weitere Informationen, etwa wo auf der Festplatte die Treiberdatei liegt oder wer ihr Hersteller ist, sollten über den Gerätemanager beschaffbar sein.

Abführ’n

Mit diesen Angaben versehen, kann man daran gehen, das Problem zu beseitigen: Erste Anlaufstelle ist der Hersteller, der sich die Frage gefallen lassen muss, ob das Problem bekannt und vielleicht schon ein neuerer Treiber verfügbar ist. Wenn nicht, stellt sich die Frage, was am System verändert wurde, bevor der Fehler zum ersten Mal auftrat. Beim Versuch, diese Änderung rückgängig zu machen, kommen Rettungsversuche über die Systemwiederherstellung, das Einspielen eines gesicherten Festplatten-Images oder eines anderen System-Backup in Betracht. Ist die Treiberdatei schlicht beschädigt, hilft oft eine Neuinstallation des Treibers oder das manuelle Herausfummeln der betroffenen Datei aus einem Installationspaket. Bringt das alles keine Besserung, sollten bei der Ursachenforschung zumindest genug Stichwörter zusammengekommen sein, um eine erfolgversprechende Internet-Recherche zu starten.

Literatur
[1] Microsoft Debugging Tools, http://www.microsoft.com/whdc/ddk/debugging

Ursachen von Bluescreens aufspüren

Seit Windows XP sind sie seltener geworden, aber auch hier gibt es sie doch noch:
Rätselhafte Systemneustarts oder die blauen Bildschirme, mit denen das Betriebssystem sich für arbeitsunfähig erklärt. Auch der Hinweis „Wenden Sie sich an den Administrator“ hilft nicht weiter, wenn dieses Schicksal den Heim-PC ereilt.

Eigentlich ist so ein Bluescreen nichts Schlechtes: Wenn er erscheint hat das Betriebssystem festgestellt, dass es in einen Zustand geraten ist, in dem ein sicheres Weiterarbeiten nicht mehr möglich ist. Jede weitere Aktion könnte mehr Schaden anrichten, als ein vielleicht seit einer halben Stunde nicht gespeichertes Word-Dokument für den Anwender bedeutet. Um die Hardware und den Inhalt der Festplatte vor Schäden zu bewahren, fährt sich das System in so einem Fall kontrolliert herunter. Ob es den Rechner danach automatisch neu startet oder einen Bluescreen anzeigt und die CPU anhält, kann der Anwender einstellen.

Die zuständigen Optionen verbergen sich in den Systemeinstellungen (Rechtsklick auf „Arbeitsplatz“ dann auf „Eigenschaften“) im Register „Erweitert“. Hier führ ein Klick auf „Einstellungen“ im Bereich „Starten und Wiederherstellen“ auf einen Dialog, dessen Einstellmöglichkeiten im Bereich „Systemfehler“ definieren. Was Windows im Falle eines Komplettabsturzes noch alles unternimmt.
Zur Fehlersuche sind hier 2 Optionen wichtig: „Automatisch Neustart durchführen“ sollte ausgeschalten sein (kein Haken im Kästchen), damit ein Bluescreen nicht sofort wieder verschwindet, dem man unter Umständen noch wertvolle Informationen entnehmen kann. Kommt es dann trotzdem zu plötzlichen reboots, ist in der Regel nicht Windows oder sonst eine Softwarekomponente schuld, sondern es liegt ein Hardwareproblem vor. In Frage kommt zum Beispiel ein Netzteil, das die Versorgungsspannung nicht stabil genug liefert und so einen Reset auslöst.
Zum Aufspüren der Ursache für Bluescreens ist es außerdem wichtig, möglichst genaue Informationen über den Systemzustand zum Zeitpunkt des Absturzes zu haben. Das unter „Debuginformationen speichern“ standardmäßig ausgewählte „Kleine Speicherabbild“ reicht dazu in der Regel nicht aus. Besser ist es hier, ein Kernelspeicherabbild anzufordern. Die Größe einer solchen Datei entspricht etwa einem Drittel der Hauptspeichergröße. Ein „Vollständiges Hauptspeicherabbild“ wird dagegen stets so groß wie der Hauptspeicher (plus einem Megabyte für einen Header und ein paar Verwaltungsinformationen). Dieser zusätzlich belegte Platz zahlt sich aber für die reine Fehlersuche in der Regel nicht aus.
Ob man das Häkchen bei „Vorhandene Dateien überschreiben“ setzt, ist nicht nur Geschmackssache: Fehlt es, legt Windows beim nächsten Absturz nicht etwa ein neues Speicherabbild an, sondern schreib schlicht ein kleines und man hat keine Chance, den Fehler zu analysieren. Ist die Option eingeschaltet, geht beim nächsten Crash eine schon vorhandene und vielleicht noch nicht komplett ausgedeutete Datei verloren. In dem Fall empfiehlt es sich, nach einem BSOD und anschließendem Neustart den Memory-Dump so schnell wie möglich durch Umbenennen oder Verschieben in Sicherheit zu bringen.

Ermittlung

Auch wenn ein Bluescreen reproduzierbar immer im selben Programm auftritt: Die Anwendung selbst kann daran nicht schuld sein – jedenfalls nicht unmittelbar. Unter Windows NT Abkömmling laufen ordinäre Programme nämlich im so genannten User-Mode (auch „Ring 3“ genannt). Sie bekommen einen eigenen virtuellen Adressraum zugewiesen und können nicht auf den Adressraum anderer Anwendungen oder direkt auf die Hardware zugreifen. Wenn in einer Anwendung etwas Gravierendes schief geht, kommt es daher allenfalls zum Absturz dieses einen Programms, was sich ain einer Fehlermeldung der Art „WinBugPro.exe hat ein Problem festgestellt und muss beendet werden“ äußert. Windows selbst läuft in so einem Fall unbeeindruckt weiter.

Ein Betriebssystemabsturz in Form eines Bluescreen kann nur enstehen, wenn Code etwas Illegales tut, der im so genannten Kernel-Mode („Ring 0“) läuft. Dazu gehören Gerätetreiber und der Mikrokernel selbst. Im Ring 0 teilen sich alle Treiber einen gemeinsamen Adressraum und können sich durchaus gegenseitig abschießen.

Um herauszufinden, welche Komponente genau den Fehler verursacht hat, muss man sich den Zustand des Systems unmittelbar vor dem Absturz ansehen. Einige Informationen zeigt schon der Bluescreen selbst: Eine Zeile, die mit „*** STOP“ gefolgt von einer achtstelligen Hexadezimalzahl beginnt, ist auf jedem BSOD zu sehen. Sie liefert einen ersten Hinweis auf die Art des Fehlers – wenn man sie denn zu interpretieren weiß. Manchmal findet sich in der Nähe der STOP-Zeile eine symbolische Beschreibung des Fehlers, etwa IRQL_NOT_LESS_OR_EQUAL oder INACCESSIBLE_BOOT_DEVICE, und damit zumindest einen Anhaltspunkt für eine Google-Suche. Mit etwas Glück enthält der Bluescreen auch einen Hinweis auf eine Datei mit der Endung. Sys. Die ist damit natürlich verdächtig, aber leider noch lange nicht als eindeutig schuldig identifiziert.

Mit den Informationen auf dem Bluescreen selbst kommt man also nicht allzu weit. Ein Blick in das Speicherabbild ist angesagt. Glücklicherweise bietet Microsoft dafür ein geeignetes Werkzeug an: den Debugger WinDbg [1 siehe unten], den Sie über den Softlink herunterladen können.
Die Download-Größe ist mit knapp 9 MByte noch erträglich. Um den Debugge allerdings sinnvoll einsetzen zu können, benötigen Sie noch die so genannten Symboldateien – und die schlagen je nach Windows-Version mit ca. 70 bis 170 MByte zu Buche. Ein Komplett-Download ist aber nicht unbedingt nötig, wenn der Rechner, auf dem Sie die Analyse durchführen wollen (das muss nicht notwendigerweise der von den Abstürzen betroffene sein), mit dem Internet verbunden ist. Dann können Sie nämlich WinDbg so einrichten, dass er immer nur die benötigten Symbole lädt und auf dem Rechner zwischenspeichert. Dazu legen Sie nach der Installation des Debuggers zunächst irgendwo auf der Festplatte ein neues Verzeichnis an.
In WinDbg wählen sie den Menübefehl „File/Symbol File Path“ und tragen in das Eingabefeld die Zeile
SRV*C: \Symbols*http://msdl.microsoft.com/download/symbols ein. Statt „C: \Symbols“ müssen Sie dabei den neuen Ordner angeben; hier wird der Debugger die heruntergeladenen Symboldateien zwischenspeichern.
Ein Speicherabbild lädt WinDbg mit dem Menübefehl „File/Open Crash Dump“. Daraufhin öffnet der Debugger zwei Fenster mit den Titelzeilen „Command“ und „Disassembly“. Letzteres kann man der Übersichtlichkeit halber gleich wieder schlissen – die dort dargestellten Informationen zu interpretieren erfordert so viel an System- und Programmierkenntnissen, dass eine Beschäftigung damit den Rahmen dieses Turtorials sprengt.
Das „Command“ – Fenster enthält dagegen meist schon durchaus wertvolle Informationen. Beachtenswert sind zwei Zelen: Eine beginnt mit „Probably caused by:“ (deutsch: „Vermutlich verursacht von:“) gefolgt von einem Dateinamen. Der Tipp, den WinDbg hier abgibt, trifft schon erstaunlich oft ins Schwarze. Zumindest wenn die benannte Datei die Endung .sys trägt, lohnt es sich, zu untersuchen, woher sie stammt.

Die zweite interessante Zeile in WinDbgs Kurzanalyse beginnt mit „BugCheck“ und enthält danach eine Hexadezimalzahl und eine Reihe weiterer kryptischer Angaben in geschweiften Klammern. Hier handelt es sich um eine Wiederholung dessen, was der Bluescreen in der STOP-Zeile angezeigt hat. Um Genaueres über die Bedeutung dieser Angaben zu erfahren, gibt man unten im Command-Fenster hinter „kd>“ den Befehel !analyze –v
Ein . Er liefert meist einen Wust an Informationen, von denen zunächst die ersten Zeilen besondere Beachtung verdienen: Ein symbolischer, aus Großbuchstaben und Unterstrichen bestehender Name wie NTFS_FILE_SYSTEM nebst einer Kurzbeschreibung erklärt die Art des aufgetretenen Fehlers. In den folgenden Zeilen gibt es eine kurze Erklärung der mitgelieferten Parameter. Wer es noch genauer wissen will, kopiert das Fehlersymbol und fügt es in der Eingabezeile hinter dem Befehl .hh wieder ein:
.hh NTFS_FILE_SYSTEM

startet die WinDbg-Hilfe und zeigt einen Artikel an, der weitere Informationen zu dem Fehler enthält. Bei vielen Fehlerarten finden sich hier auch gleich Erklärungen, wie man die möglichen Fehlerursachen einschränken kann oder was zu tun ist, um den Fehler künftig zu vermeiden. Wenn dort steht, dass die häufigste Fehlerursache defekte Hardware ist, dann sollten Sie das durchaus ernst nehmen und die weitere Fehlersuche zunächst darauf konzentrieren.

Detektivarbeit

In der Ausgabe von !analyze –v sind außerdem noch die Zeilen unter der Überschrift „STACK_TEXT:“ interessant: Sie enthalten eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte steht dabei jeweils der name des zuständigen Moduls und dahinter, abgetrennt durch ein Ausrufe- oder ein Plus Zeichen, die Adresse innerhalb des Moduls. Taucht hier in den ersten paar Zeilen ein anderer Modulname als „nt“ auf, ist dieses Modul zumindest verdächtig, an dem Crash beteiligt gewesen zu sein.
Weitere Kandidaten kann man manchmal identifizieren, indem man den Befehl !thread eingibt.
Enthält die Ausgabe die Überschrift „IRP List:“, dann sollte man die Adressen aus der ersten Spalte dieser Liste an den Befehl !irp verfüttern: Ein Kommando wie
!irp ffabccd8
gibt detailliert Auskunft über ein so genanntes I/O Request Packet, das an dieser Adresse im Speicher liegt. Es enthält immer auch die Namen der Treiber, die an dieser Ein-/Ausgabeoperation beteiligt sind, und damit weitere mögliche Schuldige für den Absturz.

Wenn der Rechner immer beim Diskettenzugriff oder beim Anstöpseln eines USB- Gerätes abschmiert, lohnt ein Blick auf die I/O Request Packets.

Subnetting

Was ist Subnetting?

Subnetting ist die Unterteilung eines Netzwerkes in mehre kleine, welche allerdings im selben Netzwerk bleiben.
z.B.: In ihrer Firma gibt es mehrere Gebäude. Allerdings nur ein Netzwerk. Wenn sie jetzt jedem Gebäude ein Subnet zuteilen können diese sich untereinander schneller unterhalten. Die Kommunikation zu den anderen Netzen ist allerdings weiterhin möglich.

Was muss ich beachten?

Man muss beachten aus welcher Netzwerkklasse das zu Teilende Netzwerk stammt.
Man muss sich im Klaren sein, wie viele Subnetze benötigt werden. Ein nachträgliches ändern ist nicht so ohne weiteres möglich.
Wenn die Anzahl der Subnetze welche Sie über die Berechnung erhalten nicht ausreichen oder nicht genau erzielt werden können muss die nächst höhere Aufteilung erfolgen.

Welche Norm muss ich verwenden?

Es gibt zwei verschiedene Normen fürs Subnetting:
1. Cisco Norm (RFC 950)
2. Standart (RFC 187cool
Der wichtige unterschied zwischen den Normen besteht darin das bei der Anwendung der RFC 950 das erste und letzte Subnet abgezogen werden und somit 2 weniger als berechnet zur Verfügung stehen. Dies geschieht bei der RFC 1878 nicht. Hier können alle berechneten Subnetze auch verwendet werden.

Wie werden die Subnetze berechnet?

Berechnung der Subnetze für Klasse C Netzwerke:

Cisco Norm (RFC 950)

Netzwerk: 192. 168. 210. 0
Netzwerk traurig Binär): 11000000.10101000.1010010.00000000
Subnetmask: 255. 255. 255. 0
Subnetmask (Binär): 11111111.11111111.11111111.00000000

Benötigte Subnetze: 4

Formel: 2ⁿ -2 = Subnetze

Um vier Subnetze zu erzeugen müssen 3 Bit der Subnetmask (des Hostanteils ) gestohlen werden.
2³ -2= 6

Somit werden die ersten drei Nullstellen des Hostanteils der Subnetmask auf 1 gestellt. (11111111.11111111.11111111.11100000)
Diese werden von Binär in Dezimal umgerechnet:
1*2⁷+1*2⁶+1*2<sup>5< /sup>= 128+64+32= 224
Somit lautet die neue Subnetmask: 255. 255. 255. 224
Subnetmask (Binär): 11111111.11111111.11111111.11100000

Nun zur Berechnung der Subnetze

128 64 32 = Subnetze
0 0 0 = 192.168.210.0
0 0 1 = 192.168.210.32
0 1 0 = 192.168.210.64
0 1 1 = 192.168.210.96
1 0 0 = 192.168.210.128
1 0 1 = 192.168.210.160
1 1 0 = 192.168.210.192
1 1 1 = 192.168.210.224
Hier werden die auf 1 stehenden Werte addiert um die letzte Stelle der IP-Adresse festzulegen. Die hier stehenden IP-Adressen sind die Netzwerkadressen.

Netzwerkadresse: 192.168.210.64
IP-Adressen: 192.168.210.65 ? 192.168.210.94
Broadcast: 192.168.210.95
Subnetmask: 255.255.255.224

Bitte auch wieder Beachten das, das Erste und Letzte Subnetz weg gestrichen werden. Somit erhalten wir 6 Subnetze.

Andere Norm (RFC 187cool

Netzwerk: 192. 168. 210. 0
Netzwerk traurig Binär): 11000000.10101000.11010010.00000000
Subnetmask: 255. 255. 255. 0
Subnetmask (Binär): 11111111.11111111.11111111.00000000

Benötigte Subnetze: 4

Formel: 2ⁿ = Subnetze

Um vier Subnetze zu erzeugen müssen 2 Bit der Subnetmask (des Hostanteils ) gestohlen werden
2²=4
Somit werden die ersten zwei Nullstellen des Hostanteils der Subnetmask auf 1 gestellt. (11111111.11111111.11111111.11000000)
Diese werden von Binär in Dezimal umgerechnet:
1*2⁷+1*2⁶= 128+64= 192

Somit lautet die neue Subnetmask: 255. 255. 255. 192
Subnetmask (Binärsmile 11111111.11111111.11111111.11000000

Nun zur Berechnung der Subnetze:

128 64 = Subnetze
0 0 = 192.168.210.0
0 1 = 192.168.210.64
1 0 = 192.168.210.128
1 1 = 192.168.210.192
Hier werden die auf 1 stehenden Werte addiert um die letzte Stelle der IP-Adresse festzulegen. Die hier stehenden IP-Adressen sind die Netzwerkadressen

Netzwerkadresse: 192.168.210.64
IP-Adressen: 192.168.210.65 ? 192.168.210.126
Broadcast: 192.168.210.127
Subnetmask: 255.255.255.255.192

Hier können auch alle Berechneten Subnetze auch verwendet werden.

Berechnung der Subnetze für ein Klasse B Netzwerk:

Cisco Norm (RFC 950)

Netzwerk: 128. 12. 0. 0
Netzwerk traurig Binär): 100000000.00001100.00000000.00000000
Subnetzmaske: 255. 255. 0. 0
Subnetmask (Binär): 11111111.11111111.00000000.00000000

Benötigte Subnetze: 4

Formel: 2ⁿ -2 = Subnetze

Um vier Subnetze zu erzeugen müssen 3 Bit der Subnetmask (des Hostanteils) gestohlen werden.
2³ -2=6

Somit werden die ersten drei Nullstellen des Hostanteils der Subnetmask auf 1 gestellt.(11111111.11111111.11100000.00000000)

Diese werden von Binär in Dezimal umgerechnet:
1*2⁷+1*2⁶+1*2<sup>5< /sup>= 128+64+32= 224

Somit lautet die neue Subnetmask: 255. 255. 224. 0
Subnetmask (Binär): 11111111.11111111.11100000.00000000

Nun zur Berechnung der Subnetze:
128 64 32 = Subnetze
0 0 0 = 128.12.0.0
0 0 1 = 128.12.32.0
0 1 0 = 128.12.64.0
0 1 1 = 128.12.96.0
1 0 0 = 128.12.128.0
1 0 1 = 128.12.160.0
1 1 0 = 128.12.192.0
1 1 1 = 128.12.224.0
Hier werden die auf 1 stehenden Werte addiert um die letzte Stelle der IP-Adresse festzulegen. Die Hier stehenden IP-Adressen sind die Netzwerkadressen.

Netzwerkadresse: 128.12.64.0
IP-Adresse: 128.12.64.1 ? 128.12.127.154
Broadcast: 128.12.127.255
Subnetmask: 255.255.224.0

Bitte auch wieder beachten das, das Erste und Letzte Subnetz weg gestrichen werden.
Somit erhalten wir 6 Subnetze.

Andere Norm (RFC 187cool

Netzwerk: 128. 12. 0. 0
Netzwerk traurig Binär): 10000000.00001100.00000000.00000000
Subnetmask: 255. 255. 0. 0
Subnetmask (Binär): 11111111.11111111.00000000.00000000

Benötig werden 4 Subnetze:

Formel: 2ⁿ = Subnetze

Um vier Subnetze zu erzeugen müssen 2 Bit der Subnetmask (des Hostanteils) gestohlen werden.
2²=4

Somit werden die ersten zwei Nullstellen des Hostanteils der Subnetmask auf 1 gestellt.(11111111.11111111.11000000.00000000)

Diese werden von Binär in Dezimal umgerechnet:
1*2⁷+1*2⁶ = 128+64 = 192

Somit lautet die neue Subnetmask: 255. 255. 192. 0
Subnetmask (Binär): 11111111.11111111.11000000.00000000

Nun zur Berechnung der Subnetze:

128 64 = Subnetze
0 0 = 128.12.0.0
0 1 = 128.12.64.0
1 0 = 128.12.128.0
1 1 = 128.12.192.0

Hier werden die auf 1 stehenden Werte addiert um die letzte Stelle der IP-Adresse festzulegen. Die hier stehenden IP-Adressen sind die Netzwerkadressen.

Netzwerkadresse: 128.12.64.0
IP-Adressen: 128.12.64.1 ? 128.12.127.254
Broadcast: 128.12.127.255
Subnetmask: 255.255.192.0

Hier können auch alle Berechneten Subnetze auch verwendet werden.

BaSStar hat recht.
wenn du ein Webtemplate benutzt musst du das Copyright drauflassen,
ausser wenn du dich mit dem Ersteller des Copyright in verbindung setzt und dich mit Ihm einigst, bezüglich des Copyrights, einige Ersteller solcher Webtemplates verlangen für die löschung des Copyrights sogar Geld.

wenn ich mir jetzt so deine Antwort betrachte driver hast du irgendwie recht *Fg*, wobei er fürs erste den iframe mal rausmachn sollte von dem header.

Zitat von sejuma

Ist wie beim Aufräumen: Du musst dem Inhalt nur sagen, in welche "Schublade" er reingehört.
Das was du unter "Layout" versethst ist vermutlich jedoch nur der grafische Teil.

Ich gebe sejuma völlig recht.
Das was du benötigst ist HTML, dies kannst du am leichtesten mit "SelfHTML" lernen
(ist eine kostenlose seite im Internet, google einfach ma)
und mit hilfe von HTML kannst du dann deine Grafiken so zusammenfügen wie du sie haben willst, und an der entsprechenden stelle deinen Text dazuschreiben.

wenn das so stimmt wie dus gesagt hast, warum machst dus net so?? *Fg*
übernimm den Quelltext aus dem iframe und integriere ihn in den rest des framesets.
bzw hab gerade noch den Quelltext angeschaut. hmmz ich würde den Inhalt des Iframes dort hineinsetzen wo dein iframe vom header ist und den Iframe rauslöschen.
aber bevor du das machst, erstell zuvor eine sicherheitskopie, falls etwas falsch läuft du immer noch zurücksetzen kannst.

ich schätze mal wenn du die Breite in diesem CSS skript nicht einträgst, wird die Box automatisch 100% und verändert sich automatisch mit der größe deines Fensters vom Webbrowser.
so würde ich den Queltext verstehen.