Ein eMule-Tutorial ...mal anders

[MaxUpload]

Hallo liebe eMule-Code-Interessierte

und Leute die sich einfach nur mal über die Zusammenhänge und Abläufe in einem Windowsprogramm -> hier am Beispiel von eMule informieren wollen.

An dieser Aussage seht ihr schon,daß es in diesem Tutorial nicht um C&P (*1) gehen wird!!!

Dieses Tutorial soll vielmehr eine Grundlage zum Verständnis werden,welches euch befähigen sollte eMule bzw. C++ (*2) zu verstehen.

Ob Ihr das einfach nur mal wissen wolltet, ein anderes Programm schreiben wollt, eure Aussagen auf Boards mit Code untermauern wollt oder aktiv eMule mitgestalten möchtet das liegt in eurer Verantwortung.

So nun genug zum Vorwort. Dann lasst uns mal loslegen !
__________________________________________
*1 ) C&P = Copy & Paste ist das stupide rauskopieren von Code aus einem anderen Programm und einfügen in das eigene Programm.

Damit wir uns nicht falsch verstehen jeder hat mal eine gute Idee aufgegriffen und sie in seinen Mod übernommen. Es ist ja auch völlig unsinnig gut funktionierende Sachen neu zu schreiben. Verwerflich ist nur wenn man einen Würfel in einen Zylinder stecken will ohne ihn vorher rund zu schleifen


*2)im folgenden beziehe ich mich auf Visual C++ .net 2002 und/oder 2003
____________________________________________

Quellen:
1) "Visual C++ . NET" - Kompendium von Kate Gregory
_____________________________________________
Bemerkung : Da dieses Tutorial auch als solches aufgebaut sein soll untergliedere ich in Kapitel....die einzelnen Kapitel werde ich separat editieren. Für evtl. durch diese Vorgehensweise entstehende Doppelposts möchte ich mich im Vorraus entschuldigen.
Ich hoffe es wird mir verziehen und ich hoffe es wird zwischen den Kapiteln zu regen Diskussionen und Anmerkungen aus allen Richtungen kommen.

[MaxUpload]

Kapitel 1 - Windowsprogramme in C++ und ihre Besonderheiten

Leitfaden :

Was unterscheidet die Windowsprogrammierung vom guten alten DOS ?

Wo ist verdammt nochmal der Anfang ?

__________________________________________________ _____________

Was unterscheidet die Windowsprogrammierung vom guten alten DOS ?

Wer von euch hat denn schonmal Programme unter DOS geschrieben z.B. in QBasic ?

Ich hatte das damals noch in der Schule (ja ich weiss ich bin alt ).
Mit diesem Grundwissen hab ich mich dann in die eMule Welt gestürzt .
Nach einer Stunde bin ich völlig entnerft zu dem Schluss gekommen ohne C++-Buch geht wohl garnichts. Dabei war nicht der Code das Problem, sondern einfach die ungewohnte Strukturierung von objektorientierten Sprachen.

Bis dahin galt für mich ein Programmablauf ist linear....er beginnt in Zeile 1 und endet mit der letzten Zeile. Das war typisch für DOS und wie ist das nun im Windows?

Im Windows gibt es das Meldungsrouting.
Vereinfacht gesagt eine Tastatureingabe, ein Mausklick...jeder Vorgang in Windows löst eine Meldung aus diese wird an die Ebene (z.B. ein Fenster) weitergeleitet für die sie bestimmt ist.

Dabei unterscheidet man Low-Level-Meldungen von Meldungen höherer Ebenen.
Für den Programmierer sind Low-Level-Meldungen normalerweise belanglos.
Mich interessiert es ja nicht ob der User irgendwo in Windows rumklickt oder gerade eine Eingabe in einem anderen Programm macht.
Mich interessiert eigentlich ja nur ob er z.B. gerade mit der Maus auf den Verbindungsbutton von eMule gedrückt hat.

Hier mal ein kleiner Auszug aus der WINUSER.H zu Veranschaulichung:

#define WM_SETFOCUS                     0x0007
#define WM_KILLFOCUS                    0x0008
#define WM_ENABLE                       0x000A
#define WM_SETREDRAW                    0x000B
#define WM_SETTEXT                      0x000C
#define WM_GETTEXT                      0x000D
#define WM_GETTEXTLENGTH                0x000E
#define WM_PAINT                        0x000F
#define WM_CLOSE                        0x0010
#ifndef _WIN32_WCE
#define WM_QUERYENDSESSION              0x0011
#define WM_QUERYOPEN                    0x0013
#define WM_ENDSESSION                   0x0016
#endif
#define WM_QUIT                         0x0012
#define WM_ERASEBKGND                   0x0014
#define WM_SYSCOLORCHANGE               0x0015
#define WM_SHOWWINDOW                   0x0018
#define WM_WININICHANGE                 0x001A

Meldungen werden immer mit Namen angesprochen auch wenn das Betriebssystem dafür Integer verwendet, deshalb werden per #define-Anweisung die Namen mit den Zahlen verbunden.

Wenn ihr eMule nach WM_ durchsucht werdet ihr feststellen das im Muli neue Meldungen definiert werden. WM steht dabei für Window Message (Fenstermeldung).

Das Herzstück eines jeden Windowsprogramms ist die Message Loop...eine Endlosschleife die so lange durchlaufen wird bis sie die Meldung WM_Quit und somit false erhält.

In dieser Schleife werden die empfangenen Messages bearbeitet TranslateMessage( ) behandelt Tastatureingaben und DispatchMessage( ) ist eine riesige switch-Anweisung mit jeweils einer case-Anweisung pro Message die der Programmierer abfangen möchte.

Beispiele lass ich mal wegfallen,wenn sich jemand intensiv dafür interssiert kann man die immernoch nachreichen .

Da diese Schleife bei umfangreichen Programmen wie eMule sehr sehr lang werden kann.
Löst die MFC das Problem indem sie die Informationen über die Meldungsverarbeitung möglichst eng an die Funktionen koppelt,die die Meldungen behandeln.

Dies geschieht über Meldungstabellen die mit

BEGIN_MESSAGE_MAP(...)

anfangen und mit

END_MESSAGE_MAP()

enden.

So jetzt habt ihr alles Wichtige mal gehört nun endlich zu eMule.

Da ich als "Linear-Programmierer" irgendwie immer einen Anfang und ein Ende brauche um mich in ein Programm reinzudenken stellte sich mir als erstes die Frage :

Wo ist verdammt nochmal der Anfang ?

Wie ihr sicherlich schon gemerkt habt kann man tagelang darüber diskutieren wo denn nun wirklich der Anfang eines Windowsprogrammes liegt so es denn einen gibt.

Also kurz, knapp, bündig.....für mich beginnt ein Windowsprogramm beim Initialisieren des Hauptfensters.

Also in unserem Falle genau hier:

emule.cpp

BOOL CemuleApp::InitInstance()
{
	CWinApp::InitInstance();

	AfxEnableControlContainer();


	CemuleDlg dlg;
	emuledlg = &dlg;
	m_pMainWnd = &dlg;

	dlg.DoModal();

	return FALSE;
}

Somit läßt sich auch schon sagen eMule ist keine SDI oder MDI-Anwendung sondern eine Dialogbasierte Anwendung.

Für das Hauptfenster interessant sind erstmal folgende Dateien :


CWinApp-Klasse für die gesammte Anwendung CemuleApp
Emule.cpp
Emule.h

Dialogklasse für die gesammte Anwendung CemuleDlg
EmuleDlg.cpp
EmuleDlg.h

und natürlich

emule.rc und resource.h

Wie komm ich jetzt eigentlich zu der Behauptung das eMule eine Dialogbasierte Anwendung ist und warum soll gerade EmuleDlg das Hauptfenster sein ?

Gut die Wahl der der Namensgebung spricht ja für meine Aussage,aber das muß ja nichts heißen.

In der emule.h steht folgendes :

class CemuleApp : public CWinApp

Das bedeutet das die Klasse CemuleApp von CWinApp abgeleitet wird und somit die zentrale Anwendungsklasse ist.

Wenn wir uns jetzt wieder CemuleApp::InitInstance() in emule.cpp anschauen sehen wir das dort die Dialogklasse CemuleDlg zum Hauptdialog ernannt wird .

        CemuleDlg dlg;
	emuledlg = &dlg;
	m_pMainWnd = &dlg;

Und warum nun Dialog ?

Das ist schnell erklärt :

Typisch für einen Dialog ist die Funktion dlg.DoModal( ) welche den Dialog erzeugt und das return false am Ende von BOOL CemuleApp::InitInstance() .
SDI- und MDI-Anwendungen liefern hier ein true zurück was soviel bedeutet wie die Initialisierung wurde erfolgreich abgeschlossen führe den Rest der Anwendung aus.

Bei dialogbasierten Anwendungen gibt es keinen Rest der Anwendung, daher liefert InitInstance ( ) ein false zurück.





Pause

[martin22]

Wer sich für die Grundlagen des Emule-Protokolls interessiert, wird hier fündig:

Hydranode Project