Was muss inkludiert sein...?



  • Hallo liebe C-Experten,
    leider kann ich mich selbst nicht als einen solchen bezeichnen - ganz im Gegenteil. Jedesmal wenn ich mich mit sowas rumschlagen muss, ist das für mich der blanke Horror... deshalb bitte ich verzweifelt um Hilfe bei diesem hier:

    DWORD cStr2oStr(char *cStr) { 
    
        HANDLE  oBuffer; 
        char   *oStr; 
        DWORD   dwOStr = MAKELONG(0, 1); 
        size_t  len = 0; 
    
        if (cStr) len = strlen(cStr); 
    
        oBuffer = GlobalAlloc(GMEM_MOVEABLE, (DWORD)len + 1); 
    
        if (oBuffer) { 
            oStr = GlobalLock(oBuffer); 
            if (cStr) memcpy(oStr, cStr, len + 1); 
            GlobalUnlock(oBuffer); 
            dwOStr = MAKELONG(oBuffer, 0); 
        } 
    
        return (dwOStr); 
    }
    

    Diese Funktion stammt aus dem Sourcecode einer in Visual-C++ 2.0 geschriebenen DLL. Sie dient zum Export von Strings (char) an eine recht eigenwillige, VB4-ähnliche Entwicklungsumgebung. Immer wenn aus einer zu exportierenden Funktion ein String zurückgegeben werden soll, wird das Ergebnis vom Typ char zuerst an diese Funktion übergeben und der Rückgabewert (DWORD) wird exportiert.

    Was die Funktion so im Groben veranstaltet verstehe ich eigentlich schon: Es wird ein Speicherbereich alloziiert, dann gesperrt, dann wird der Inhalt aus dem Speicherbereich der char-Variable in diesen neuen Bereich kopiert, dann wird der wieder entsperrt und ein Zeiger zu diesem wird zurückgegeben. Korrigiert mich, wenn ich da voll daneben liege.

    So. Ich muss sowas jetzt nach-programmieren in VC++ 6 und ich bin wie gesagt werder ein C- noch ein API-Held. Wenn's ans Speicherbereiche-Schubsen geht, dann geh' ich normalerweise heim . Also frag' ich mal hier nach:

    1. Welche Header müssen included werden? GlobalAlloc & Co. kommen doch aus der Win-API, oder? Was ist mit strlen() und memcpy(), wo kommen diese Funktionen her? Und MAKELONG() - ist das ein Makro? Wo kommt denn das wieder her?

    2. Die MSDN-Library schreibt zu GlobalLock und Konsorten: "This function is provided only for compatibility with 16-bit versions of Windows". Ah so. 16-bit Windows muss nun wirklich nicht mehr sein, meine eigene DLL muss unter Win'98 und neuer laufen. Was sind die zeitgemäßen Äquivalente dafür?

    3. Weiß jemand vielleicht eine bessere Lösung, wie ich nullterminierte Strings vom Typ char bzw. LPCTSTR bzw. CString aus einer C-DLL an eine superexotische, VB4-artige Programmiersprache exportieren kann, die mit Pointern nix anfangen kann und deren Strings "kopfgesteuert" sind?

    Über schnelle Hilfe freut sich
    Martin



  • 1. Welche Header müssen included werden? GlobalAlloc & Co. kommen doch aus der Win-API, oder? Was ist mit strlen() und memcpy(), wo kommen diese Funktionen her? Und MAKELONG() - ist das ein Makro? Wo kommt denn das wieder her?

    <windows.h> und <string.h>,
    MAKELONG ist ein macro der WIN API, ist aber unter Win32

    dwOStr = MAKELONG(oBuffer, 0);
    

    ==>

    dwOStr = (DWORD) oBuffer
    

    2. Die MSDN-Library schreibt zu GlobalLock und Konsorten: "This function is provided only for compatibility with 16-bit versions of Windows"...

    Besser bleib dabei... Alles was die Funktion macht, ist den String in einem mittels GlobalAlloc allozierten Speicherbereich zu kopieren, was deine "superexotische, VB4-artige Programmiersprache" offenbar erwartet.
    GlobalAlloc bietet einen prozeßspezifischen DLL-übergreifenden Heap.

    3. Weiß jemand vielleicht eine bessere Lösung, wie ich nullterminierte Strings vom Typ char bzw. LPCTSTR bzw. CString aus einer C-DLL an eine superexotische, VB4-artige Programmiersprache exportieren kann, die mit Pointern nix anfangen kann und deren Strings "kopfgesteuert" sind?

    Wie oben, wenn deine "svb4ap" nur mittels GlobalAlloc allozierte Strings frißt, sollte man ihr die Freude machen - so eine trifft man schließlich nicht alle Tage 🙂



  • Danke Sehr,
    hast mir sehr geholfen.
    Martin


Anmelden zum Antworten