Klotzkopp

Dann brauchst du kein API Hooking, jedenfalls nicht das, was man unter Windows darunter versteht. Das bedeutet nämlich, dass man sich in die API-Aufrufe anderer Programme reinhängt, um deren Verhalten zu untersuchen oder zu verändern. Wenn es nur um dein eigenes Programm geht, brauchst du das nicht. Da reicht es, das API zu benutzen.

In deinem eigenen Programm, oder in einem anderen?

Kommt drauf an. Ich frag' auch gern nochmal: Was hast du denn vor?

Windows Mobile kann man nicht "einfach so" kaufen, weil (zumindest der OS-Teil) auf die Hardware speziell zugeschnitten wird. Was hast du denn vor?

Das sieht nicht nach einer gültigen res-Datei aus. Das würde nämlich bedeuten, dass der erste Ressourcenblock in der Datei etwa 50 MByte hat, mit einem Header davor, der über 3,5 GByte groß ist. Das ist zwar nicht unmöglich, aber zumindest doch sehr unwahrscheinlich, zumal dann, wenn die Datei selbst kleiner ist - wovon ich ausgehe. Die Datei ist IMHO beschädigt oder gepackt oder verschlüsselt. Die Endung .res trägt sie jedenfalls zu Unrecht. Sind in der ganzen Datei keine Texte zu erkennen, auch nicht gegen Ende? Ressourcendateien können Stringtabellen oder Versionsinformationen enthalten, zumindest diese sollten auch in einem Hexdump lesbar sein.

Welche Werte stehen denn in den ersten 8 Bytes?

Hast du noch irgendwo (im Code oder in den Projekteinstellungen für den Präprozessor) UNICODE oder _UNICODE definiert?

Davon habe ich nichts gesagt. Das kannst du nicht "einstellen". Du kannst nur das Mapping von TCHAR und den dazugehörigen Makros beeinflussen. Stell den Zeichensatz auf Multi-Byte.

Das hättest du auch früher sagen können. Ich verschiebe dich mal ins richtige Forum und gebe dir den hier mit auf den Weg: Edit and Continue in ASP.NET - The Code Project - ASP.NET

Offenbar kann McArgumentException::Throw nichts mit Wide-Character-Strings anfangen. Da ich die Methode nicht kenne, kann ich dazu nicht mehr sagen.

Solange du kein Unicode benutzt, klappt das so, weil dann das _T-Makro einfach nichts tut.

Solange du keine Erlaubnis vorweisen kannst, dass du dieses Dokument verbreiten darfst, muss ich das leider wieder entfernen. Kann man das irgendwo runterladen?

Könnte ich, werde ich aber nicht. Du solltest hier im Forum genügend Beispiele finden können, um dir selbst zu erarbeiten, wie man DLLs erstellt und LoadLibrary/GetProcAddress benutzt. Ein wenig mehr Eigeninitiative darf's ruhig sein Bei konkreten Problemen kannst du ja nochmal nachfragen.

Falls du an den Konfigurationen nichts geändert hast: Benutzt du die Debug- oder die Releasekonfiguration? Falls du etwas geändert hast: Benutzt du für den Compiler einen anderen /O-Schalter als /Od? Oder irgendeinen /OPT-Schalter für den Linker?

Die hinteren Teile des Strings müssen auch das _T-Makro benutzen: #define IC_ARGUMENT_ASSERT(COND) (void) ( (COND) || (McArgumentException::Throw(_T("IC_ARGUMENT_ASSERT("_T(#COND)_T(")")), __FILE__, __LINE__), 0) ) [/code]

Indem du in deiner Entwicklungsumgebung ein DLL-Projekt erstellst du diese Funktion exportierst. Das geht nicht, ohne den Code in main zu ändern. Du musst Run-time dynamic linking benutzen (also LoadLibrary/GetProcAddress), denn sonst kommt es zu einer Fehlermeldung beim Starten des Programms, wenn die DLL fehlt.

Das ist so nicht ganz richtig. Auch bei E&C wird neu kompiliert und gelinkt. Und, trifft das zu? Hast du dich nachträglich an einen Prozess angehängt, oder debuggst du optimierten Code?

Du versuchst anscheinend, ein normales und ein Wide-Character-Stringliteral aneinanderzuhängen. Das geht nicht. Für genauere Hilfe wäre es von Vorteil, wenn du den Code zeigst

Die MFC-DLLs enthalten bereits eine DllMain-Funktion. Wenn du in einer DLL die MFC verwendest, darfst du keine eigene DllMain-Funktion haben.

Das geht schon, nur nicht so. In C++ z.B. mit einer std::map.

Wie soll sich der ausgegebene Wert denn ändern, wenn du immer nur die Variable random ausgibst, und sonst nichts damit tust? Du musst rand schon in der Schleife aufrufen.

Wie ermittelst du die Werte denn?

Das hat nichts mit Vista zu tun. <iostream.h> ist schlicht falsch, zumindest nach dem heute gültigen Standard. Ganz alte Versionen von Visual C++ konnten das noch. <iostream> heißt der Header, in dem cout usw. deklariert sind. Ohne ".h". Naja, wenn du sie nicht kompilieren kannst, kannst du sie natürlich auch nicht ausführen, oder ist das ein anderes Problem?

Im "Hilfsprogramm" steht, wie man ein Basic-Programm übersetzt oder ausführt. Das "Hilfsprogramm" muss ja nicht derselbe Compiler sein, der da gebaut werden soll. Es muss überhaupt kein Compiler sein, ein Interpreter tut's ja auch. Und das Hilfsprogramm muss auch nicht in Basic geschrieben worden sein. Wie ich bereits (mehrfach?) sagte, am Anfang dieser Kette steht ein von Hand in Maschinensprache geschriebenes Programm, das in einer höheren Sprache geschriebenes Programm ausführen kann. Und wenn man irgendwann mal ein Programm hat, das Basicprogramme ausführen kann, kann man auch einen Basic-Compiler in Basic schreiben, wenn man denn möchte. Du kannst aber keinen Basic-Compiler in Basic schreiben, ohne ein anderes Programm, das Basic ausführen kann. Ich verstehe immer noch nicht, wo du da ein Problem siehst.

Könntest du bitte mal klarstellen, ob es hier um ein allgemeines Verständnisproblem geht, oder um einen konkreten Basic-Compiler auf einer spezifischen Plattform? Irgendwie verstehe ich weder deine Fragen noch dein Problem. Ich habe das Gefühl, du fragst immer wieder dasselbe.