|
|
Thema: Betriebssystem startet nicht mit angeschlossenem USB-Hub |
|
Zitat: |
Original von Misel
Der Windows 7 Bootscreen wird geladen, die Animation kommt aber über den ersten Frame nicht hinaus. Starte ich es im "abgesicherten Modus", friert der Computer ein, wenn der Balken voll ist. Genauere Informationen habe ich nicht (weiß einer, wie ich an mehr komme?) |
Es gibt bei Windows NT auch Bootoptionen mit Einzelbestätigung / Protokollierung. Da kann man dann immerhin sehen, bei welchem Treiber genau es "kracht".
Abgesehen davon tippe ich ebenfalls auf Hard-/Firmware Problem mit dem Mainboard -- der "Dell-Monitor-Hub" tut bei mir wunderbar mit allen Systemen
|
|
Thema: Duke Nukem Forever mal wieder das Aus |
Zirias
Antworten: |
27 |
Hits: |
41.340 |
|
|
11.09.2010 20:02 |
Forum: Spiele |
Naja vernünftigen mouselook kann eduke32 schon seit Jahren
(ich glaub das ging sogar schon damals im icculus-port, ohne OpenGL). Neu ist halt der "Polymer"-Renderer mit den tollen Lichteffekten, aber der zwingt meinen Rechner leider in die Knie
|
|
Thema: C OOP in ANSI C -- es lässt mich nicht los :) |
|
Soo, das Modell hat sich in den letzten Wochen noch einen gewaltigen Schritt weiterentwickelt, und zwar gibt es jetzt eine spezielle klasse "Event", bei der sich EventHandler registrieren lassen, die bei einem RaiseEvent() alle nacheinander aufgerufen werden -- im Prinzip also eine Event-Verteilung wie man sie aus vielen Frameworks (z.B. auch in .NET) kennt. Die Schnittstelle sieht grob so aus:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
|
/* Signatur eines Event-Handlers: */
typedef void (* EventHandler)(THIS, Object sender, void *eventData);
/* neues Event (normalerweise als member eines Objekts) erzeugen */
Event SomeEvent = CreateEvent();
/* Event löschen (im Destruktor) */
DestroyEvent(SomeEvent);
/* Handler registrieren: */
AddHandler(SomeEvent, this, &handlerMethod);
/* Handler wieder entfernen: */
RemoveHandler(SomeEvent, this, &handlerMethod);
/* Event auslösen: */
RaiseEvent(SomeEvent, (Object) this, eventData);
/* Event zurückziehen:
* (falls schon EventHandler aufgerufen wurden wird die Verarbeitung trotzdem
* abgebrochen, ein EventHandler kann also dafür sorgen, dass er der letzte ist,
* der das Event zu sehen bekommt) */
CancelEvent(SomeEvent);
|
|
Damit das funktioniert muss das Programm irgendwann InitEvents() aufrufen und die Haupt-Ereignisschleife mit DoEventLoop() anspringen. Ein DoneEvents() beendet die Ereignisschleife und gibt alle Resourcen frei.
Im Moment setzt das ganze auf SDL auf, sämtliche Ereignisse werden als SDL_UserEvent in die Event-Queue von SDL eingestellt, andere SDL-Events werden über das global definierte "Event SDLEvent" propagiert -- man definiert also seinen eigenen Handler für SDL-Ereignisse mit "AddHandler(SDLEvent, this, &Event_SDLEvent);".
Ich würde das ganze jetzt doch gerne in eine eigene Library packen, allerdings missfällt mir ein wenig die enge Kopplung an SDL. GFibt es noch andere verbreitete C-Frameworks, die ein Schema der gleichen Art wie SDL für Ereignisse bieten (WaitEvent(*event) / PollEvent(*event)) ?
|
|
Thema: Duke Nukem Forever mal wieder das Aus |
Zirias
Antworten: |
27 |
Hits: |
41.340 |
|
|
09.09.2010 07:49 |
Forum: Spiele |
Hmm, und um die neuesten Entwicklungen am "Original" genießen zu können braucht man mittlerweile wohl brandaktuelle Hardware
http://hrp.duke4.net/
Der neue "Polymer" Renderer (in eduke32 auf linux amd64) ruckelt bei mir nur rum -- läuft das bei jemandem spielbar? Wenn ja, auf was für ner Maschine?
|
|
Thema: [Architektur] Circular Dependency in einem klassischen 2D-Spiel |
|
Zitat: |
Original von phlox81
Also zumindest im C/C++ Bereich halte ich es für ein Antipattern, was leider in vielen der Frameworks begangen wurde (wxWidgets, Qt z.b.). Es führt zu unnötigen Abhängigkeiten, und bläht den Code unnötig auf.
Bei dir mag dies bedingt sinnvoll sein, da du ja in C gewisse Sachen über diese Struktur simulieren/realisieren musst, welche in eine OOP Sprache schon vorhanden sind. |
Ich seh das so: ENTWEDER die Sprache kennt das Konzept "Object" und liefert alle nötigen Fähigkeiten, wie z.B. zur Laufzeit die Klasse zu bestimmen -- ODER ein Basisobjekt tut das. Beides gleichzeitig ist natürlich Unsinn. Aber die Lösung mit einem expliziten Basis-Objekt finde ich eigentlich ganz angenehm, so kann ich in C# zum Beispiel "foo.GetType()" schreiben
Zitat: |
Sowas würde man in C++ mit einer Forward Deklaration lösen.
Ich weiss nicht ob das in C möglich ist. |
Ähm? Klar kann ich in C forward declarations schreiben, MUSS ich sogar, sonst wäre die circular dependency gar nicht implementiertbar
Aber auflösen kann ich sie damit nicht.
Zitat: |
Erstmal würde ich die Beziehung hinterfragen, zwischen Spielfigur und Board.
Eigentlich müsste es eine 3. Klasse Engine geben, welche die Spielzüge durchführt bzw. anstösst. Die Animation wäre dann in Board, oder in einer Klasse dafür. Engine sollte dann die Spielzüge ausführen, und die Spielfigur Klasse hätte nur den Logikcode den die Figur selber betrifft. |
Engine "rauszuziehen" klingt direkt mal sehr sinnvoll. Wird allerdings nicht so einfach sein. Und figurspezifisched Logik ist ja trotz allem von der Umgebung abhängig, die dann wiederum nur der Engine bekannt ist -- könnte man sich höchstens überlegen, GANZ auf die separaten Klassen für die Entities zu verzichten ... hmm ...
Zitat: |
Auch würde ich das Spielfeld intern als 2D Int array abbilden. |
Das tut zur Zeit das Level. Das Board liest das aus und instanziiert die tatsächlichen Objekte. Vielleicht wirklich unnötiger Overhead, muss ich nochmal drüber nachdenken. Praktisch ist es bisher für die fallenden Felsen, wenn die ihr Ereignis für eine abgeschlossene Bewegung bekommen prüfen sie direkt, ob sie weiterfallen bzw abrollen sollten, und fordern dann eine neue Bewegung an
Alle anderen Entities (bis auf "Willy", die eigentliche Spielfigur) tragen aber in der Tat nichts zur Logik bei...
edit:
Danke auch Misel für die Warnung ... habe kurz drüber nachgedacht, und DAS kann zur Zeit zum Glück nicht passieren, da kein Entity jemals "mutators" des Board aufruft. Das Board kann Zustand des Entity ändern, aber nicht umgekehrt. Sollte ich vielleicht dokumentieren, falls ich bei dem aktuellen Modell bleibe, denn andernfalls könnte das tatsächlich zum Problem werden
|
|
Thema: [Architektur] Circular Dependency in einem klassischen 2D-Spiel |
|
Vorgeschichte: Nach einem Hinweis von phlox81 auf ein Anti-Pattern, alles von einer einzigen Basisklasse abzuleiten, hab ich gesucht, ob das tatsächlich eines ist, und, mit welcher Begründung (schließlich machen das viele OOP-Umgebungen ganz implizit so) ... habe auch nichts gefunden. Allerdings fallen einem bei einer solchen Recherche durchaus Dinge auf, von denen man weiß, dass sie nicht toll sind, die man aber trotzdem bis dahin nicht "gewürdigt" hat:
Ich hab eine Circular Dependency. Und zwar gibt es ein Spielfeld (Board), das hat ein zweidimensionales Array (2D-Spiel *g*) von Entities, die sich auf diesem Feld befinden. Jedes Entity weiß aber auch, auf welchem Board (gibt natürlich nur eines) an welcher Stelle es steht. Das Board erzeugt die Entities anhand der Daten eines Levels.
Wenn jetzt ein Entity bewegt werden soll, überprüft es die Gültigkeit der Bewegung, indem es vom Board Nachbar-Entities abfragt. Wenn alles passt, wird ein "Move" erzeugt und an das Board zur Ausführung übergeben. Das Board führt die Bewegung animiert aus und aktualisiert am Ende die Positionsdaten und schickt ein Ereignis, dass die Bewegung abgeschlossen ist.
Also: Board greift auf Entity zu UND Entity greift auf Board zu.
Frage: Gewinne ich an der Stelle wirklich etwas, wenn ich versuche, das aufzulösen? z.B. könnte sich ein Entity selbst seine benötigten Nachbarn merken und vom Board aktualisieren lassen, dann wäre es nicht mehr nötig, dass das Entity auf das Board zugreift. Das erscheint mir aber irgendwie umständlich...
|
|
Thema: Sonstiges Sourceforge? |
|
Mal zur allgemeinen Diskussion: Was genau hat man davon, ein Projekt zu Sourceforge (oder vergleichbaren Seiten) umzuziehen, anstatt alles selbst zu hosten? Also, außer dass "Softpedia" beginnt, die binaries zu klauen ...
Finden sich auf Sourceforge tatsächlich leichter Mitstreiter? Oder ist es am Ende doch völlig unerheblich? Irgendwelche Erfahrungen?
|
|
Thema: C Stoneage: Zweite Portierung eines AmigaBASIC Games |
|
Das ist schon gut möglich
Aber ich will DAS Spiel, das ich von damals kenne.
Aktueller Stand: Die Felsen fallen -- bisher allerdings noch ohne abrollen.
edit:
So, wurde dringend Zeit für ein wenig Dokumentation, auch weil ich sicher bald mal ne Pause machen muss. Ein nettes kleines perl-script (dxprep_h.pl) gaukelt doxygen C++-Syntax vor, und damit kommen dann so nette Sachen raus wie das angehängte Bild
|
|
Thema: C Stoneage: Zweite Portierung eines AmigaBASIC Games |
|
Da jetzt zumindest mal die Infrastruktur in Sachen OOP und Video steht, kann ich ja mal dieses Projekt verkünden:
log
- 2010/05/24: Release 0.0.4 alpha: Erste spielbare Version, enthält die 3 Level des originalen AmigaBASIC Spiels
- 2010/05/23: Release 0.0.3 alpha: Bewegungen von Willy und Tastatursteuerung
- 2010/05/23: Release 0.0.2 alpha: verbesserte Grafik und Felsen rollen korrekt über andere Felsen ab
- 2010/05/21: Erster "feature-merge" -- Grafikverbesserungen. Nicht fertig, aber wenigstens bugfrei. Wenn man meint es gibt genau zwei Stellen, wo der Bug sich verstecken kann, und am Ende ist es eine dritte -> zum Haare raufen
edit: Projekt-Homepage:
http://sekrit.de/stoneage/
edit: Windows-Buildumgebung tut, erstes win32-zip hochgeladen (tut natürlich auch noch nicht wirklich was).
Spielidee:
Steinzeitmensch "Willy" sucht Kohlköpfe und gräbt sich dazu durch Levels -- Felsbrocken sind gefährlich, wenn sie runterfallen können sie entweder Willy erschlagen oder auch den Weg zu den Kohlköpfen endgültig verbauen.
Das Spiel wurde mal im 68000er Magazin als AmigaBASIC Listing veröffentlicht (ich glaube 1988) -- eine Portierung auf MS-DOS mit TurboPASCAL und "BGI" Grafiktreiber habe ich hinter mir -- JETZT sind moderne Platformen dran, mit Hilfe von SDL.
Grobe TODO-Liste:
- Spiel-Logik in den von Entity abgeleiteten Objekten implementieren
- Eingabe: Bisher immer Cursor-Tasten, dank SDL sollte man vom konkreten Eingabegerät doch abstrahieren können? SDL-input anschauen!
- Sound
- Level-Editor (sowas hatte meine DOS-Version auch *g*)
Jemand Lust, mitzucoden?
|
|
Thema: C OOP in ANSI C -- es lässt mich nicht los :) |
|
Zitat: |
Original von phlox81
C ist ein Subraum von C++. |
Stimmt nicht so ganz.
Zitat: |
Man kann auch rein imperativ mit C++ arbeiten, hat aber trotzdem den vorteil von Templates und echten Objekten. Zu mal du in C++ auch mit der STL noch Container und Algorithmen dazu bekommst. |
- Man WILL in C++ nicht rein imperativ arbeiten.
- So etwas wie "unechte Objekte" existiert nicht.
- Mal die STL Implementierungen angeschaut? Das ist alles Komplexität, die man sich sparen kann, wenn man sie nicht braucht.
Zitat: |
Und SDL C++ Wrapper gibts bestimmt auch schon.
|
Wahrscheinlich sogar etliche. Will ich aber nicht
|
|
Thema: C OOP in ANSI C -- es lässt mich nicht los :) |
|
Blaa *fg*
also Hintergrund ist: ich will ENDLICH mal das gute alte AmigaBASIC (!) Game "Stoneage" auf aktuelle Plattformen portieren. Nachdem ich schonmal erfolgreich ne Portierung auf MS-DOS mit TurboPASCAL geschafft hab, sollte es jetzt etwas auf Basis von SDL sein.
Und da kommt halt die Frage auf: C++ oder C? SDL selbst ist rein imperativ, verfasst in C. Ich will natürlich objektorientiert programmieren. Zwei Möglichkeiten: SDL in C++ "wrappen" oder ANSI C objektorientiert erweitern. Letzteres find ich irgendwie "cooler"
|
|
Thema: C OOP in ANSI C -- es lässt mich nicht los :) |
|
edit 4: GANZ WICHTIG -- die erste Version war gar nicht ANSI C...
1. Variadic Macros gibt's erst ab C99, nicht jeder C-Compiler kann das
2. Viel schlimmer: das ARG()-Makro da unten verwendet eine GNU-spezifische Syntax, um ein überflüssiges Komma bei leerer variabler Argument-Liste zu "schlucken".
Bin inzwischen dazu übergegangen, strikt C89-konform vorzugehen, das bedeutet:
1. statt ARG(...) gibt es ein #define THIS void *_this, um wenigstens den boilerplate der Methoden-Deklaration ein BISSCHEN zu verstecken. Sieht dann z.B. so aus:
code: |
1:
|
void FUNC(foo)(THIS, int bar); |
|
2. um der C89/C90 Vorschrift "Deklarationen zuerst" nachzukommen, müssen Methoden alle ihre lokalen Variablen VOR dem aufruf von "METHOD(Classname);" deklarieren.
end edit 4...
Hab mal wieder etwas neues gebaut, dieses mal ist sogar so etwas wie Polymorphie möglich
Das ganze besteht aus einem Kern zum Memory-Management:
mm.h:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
|
#ifndef MM_H
#define MM_H
#include <stdlib.h>
#define XMALLOC(T, n) ((T *)xmalloc((n) * sizeof(T)))
#define XREALLOC(T, p, n) ((T *)xrealloc((p), (n) * sizeof(T)))
#define XFREE(p) do { if (p) {free(p); p=0;}} while(0)
extern void *xmalloc(size_t n);
extern void *xrealloc(void *p, size_t n);
#endif |
|
mm.c:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
|
#include <stdio.h>
#include "mm.h"
void *
xmalloc(size_t n)
{
void *p = malloc(n);
if (!p)
{
fprintf(stderr, "Out of memory!\n");
exit(-1);
}
return p;
}
void *
xrealloc(void *p, size_t n)
{
if (!p) return xmalloc(n);
void *rp = realloc(p, n);
if (!rp)
{
free(p);
fprintf(stderr, "Out of memory!\n");
exit(-1);
}
return rp;
} |
|
sowie einer basis-klasse "object" mit einem Satz von helper-Makros
object.h:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
|
#ifndef OBJECT_H
#define OBJECT_H
#include "mm.h"
#define CTOR(myclass) myclass myclass##_ctor(myclass this, TypeList types)
#define DTOR(myclass) void myclass##_dtor(myclass this)
#define CLASS(name) struct name; \
typedef struct name *name; \
extern CTOR(name); \
extern DTOR(name); \
struct name
#define INHERIT(baseclass) struct baseclass _baseobject
#define CAST(pointer, type) ((type)GetObjectOf(pointer, CLASS_##type))
#define NEW(T) T##_ctor((T)XMALLOC(struct T, 1), 0)
#define DELETE(T, object) do { if (object) { \
T##_dtor((T)object); free(object); object=0; \
}} while (0)
#define BASECTOR(myclass, baseclass) \
types = RegisterType(types, CLASS_##myclass); \
baseclass##_ctor((baseclass)this, types)
#define BASEDTOR(baseclass) baseclass##_dtor((baseclass)this)
#define FUNC(name) (* name )
#define ARG(...) (void *_this, ##__VA_ARGS__)
#define METHOD(myclass) myclass this = CAST(_this, myclass)
struct TypeList;
typedef struct TypeList *TypeList;
CLASS(Object) {
TypeList types;
};
extern Type GetType(void const *object);
extern Object GetObject(void const *object);
extern Object GetObjectOf(void const *object, const Type T);
extern TypeList RegisterType(TypeList types, const Type T);
#endif |
|
object.c:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
|
#include "object.h"
struct TypeList {
unsigned char n;
Type type[16];
TypeList next;
};
CTOR(Object)
{
types = RegisterType(types, CLASS_Object);
this->types = types;
return this;
}
Type
GetType(void const *object)
{
return GetObject(object)->types->type[0];
}
Object
GetObject(void const *object)
{
return (Object)object;
}
Object
GetObjectOf(void const *object, const Type T)
{
int i;
Object p = GetObject(object);
TypeList types = p->types;
while (types)
{
for (i = 0; i < types->n; ++i)
{
if (types->type[i] == T) return p;
}
types = types->next;
}
return 0;
}
TypeList
CreateTypeList(void)
{
TypeList types = XMALLOC(struct TypeList, 1);
types->n = 0;
types->next = 0;
return types;
}
TypeList
RegisterType(TypeList types, const Type T)
{
TypeList current;
if (!types) types = CreateTypeList();
current = types;
while (current->n == 16) {
if (!current->next) current->next = CreateTypeList();
current = current->next;
}
current->type[current->n++] = T;
return types;
}
void
FreeTypeList(TypeList types)
{
if (types->next) FreeTypeList(types->next);
XFREE(types);
}
DTOR(Object)
{
FreeTypeList(this->types);
} |
|
Verwendet wird das ganze dann z.B. so:
classes.h:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
|
#ifndef CLASSES_H
#define CLASSES_H
enum Type {
CLASS_Car,
CLASS_Object
};
typedef enum Type Type;
#endif |
|
car.h:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
|
#ifndef CAR_H
#define CAR_H
#include "object.h"
CLASS(Car) {
INHERIT(Object);
int color;
void FUNC(drive) ARG(char *dest);
};
#endif |
|
car.c:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
|
#include <stdio.h>
#include "car.h"
static void
m_drive ARG(char *dest)
{
METHOD(Car);
printf("driving %d colored car to %s...\n", this->color, dest);
}
CTOR(Car)
{
BASECTOR(Car, Object);
this->color = 0;
this->drive = &m_drive;
return this;
}
DTOR(Car)
{
BASEDTOR(Object);
}
|
|
main.c:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
|
#include "car.h"
int main(int argc, char **argv)
{
Car c = NEW(Car);
Object o = CAST(c, Object);
Car c2 = CAST(o, Car);
c2->drive(c2, "northpole");
DELETE(Car, c2);
} |
|
Kann jemand was damit anfangen?
Natürlich muss jede Klasse in "classes.h" eingetragen werden... man könnte das auch mit Strings lösen, aber so ist es performanter.
edit: Syntax "verschönert" (Funktionalität unverändert)
edit 2: Ganz wichtige Ergänzung: Methoden-Implementierungen UNBEDINGT static deklarieren, sonst gibt's sehr schnell Symbol-Kollisionen (kein mangling in plain C *g*)
edit 3: DELETE() tut nichts bei NULL-pointer -- ist einfach bequemer so.
|
|
Thema: Windows 7 |
Zirias
Antworten: |
20 |
Hits: |
19.265 |
|
|
Hab zur Zeit nur die Server-Variante (Server 2008 R2) im Einsatz, aber auch die arbeitet sehr gut (unter XEN). Mich nervt nur eines: Updates werden selbst MIT reboot vollautomatisch durchgeführt. Gibt es eine Möglichkeit, das Ding so zu konfigurieren, dass es mir eine Mail schickt, wenn ein Update ansteht, das einen Reboot verlangt?
|
|
Thema: kann keine microsoft seiten aufrufen |
|
Da gibt's viele Möglichkeiten:
- Virus/Malware wollte microsoft "umbiegen" und hat versagt
- DNS-Fehler beim Provider, kann ja mal vorkommen
- Apple-Verschwörung
|
|
Thema: Javascript: JSON per HTTP an Server schicken. |
|
Ok, also ich glaube ich kapiere einfach nicht, was du erreichen willst. Die Daten in deinem kurzen Beispiel-HTML-Form in JSON serialisieren und zum Server schicken?
Warum? :o Alle Welt schickt Formulardaten in application/x-www-urlencodet, das verstehen auch alle serverseitigen Framworks. Aber WENN es unbedingt JSON sein soll, musst du wohl erstmal die Daten mit einer Schleife über die form-Elemente "einsammeln".
Normalerweise verwendet man JSON für den umgekehrten Weg, vom Server zum Client.
|
|
Thema: Javascript: JSON per HTTP an Server schicken. |
|
Moment ... was genau du überträgst ist doch egal!
Wenn du dem Browser das übertragen überlässt (also per form.submit()) werden die inhalte der form-elemente als application/x-www-url-encoded im body des requests verschickt. wenn dann in einem feld daten im JSON format stehen, ist das wohl kein problem, die auch wieder zu extrahieren
Wenn du JSON unbedingt direkt im Body haben willst, sieht ein minimaler request so aus:
code: |
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
|
POST [Resource-Pfad] HTTP/1.1
Host: [Hostname]
Content-Type: text/json
Content-Transfer-Encoding: 8bit
Content-Length: [größe des JSON in bytes]
{
"test": {
"foo": "bar"
}
} |
|
Den musst du dann wohl per XmlHttpRequest() Klasse loswerden...
edit: Wie ich sehe arbeitest du da mit irgendeinem Framework -- das ich allerdings nicht kenne. Vielleicht hilft als Beispiel für einen POST-Request (sendet in meinem Fall allerdings application/x-www-form-urlencoded) in javascript mein alter "web 2.0" (*fg*) formmailer:
http://palmen-it.de/script/formmail.js
Der interessante Code beginnt ab dem Kommentar "// POST in asynchronous mode:"
|
|
Thema: Debian Linux FirewallScript beim Booten starten |
|
sysvinit funktioniert über symlinks in /etc/rc0.d bis /etc/rc6.d (für die runlevels) ... einfach bisherigen Inhalt anschauen, dann wird das schon klar, ist distributionsunabhängig.
Debian-spezifisch gibt es noch hooks für Netzwerkinterfaces in /etc/network/interfaces, hier hilft man 5 interfaces (post-up wäre da wohl das richtige)
|
|
|
|