4. Unicode String Funktionen

Unicode String Funktionen

  • Y

    Hallo,

    kann ich denn die Unicodeversion der neuen String Funktionen wie z.B. StringCbCat
    auch unter einem Win9x System nutzen, oder brauch ich da wie bei den normalen einen
    Unicode-Layer? Ich kann in der MSDN nichts darüber finden.

    Und worin besteht denn der Unterschied zwischen z.B. StringCbCat und StringCchCat?

    Gruß
    yogle

    0
  • J

    Da stellst Du eine interessante Frage...
    Die Funktionen direkt in der "strsafe.lib" implementiert und benötigen keine anderen DLLs... (kannst Du nachschauen indem Du "dumpbin" auf die strsafe.lib ausführst).
    Somit kannst Du die Funktionen unabhängig des OS verwenden.

    0
  • J

    yogle schrieb:

    Und worin besteht denn der Unterschied zwischen z.B. StringCbCat und StringCchCat?

    Das eine nimmt als Länge "bytes" entgegen (Cb), das anderen "characters" (oder besser "code values") (Cch).

    0
  • Y

    Danke erstmal für die schnelle Hilfe.

    Ist ja gut das man wenigstends die überall benutzen kann.

    Nur damit ich das richtig verstehe. Ich kann unter Win9x also mit z.B. CreateFileA keine Datei öffne die einen Unicodenamen hat.
    Dazu bräuchte ich dann CreateFileW und damit ich das unterstützen kann, muss in meinem Projekt ein Unicode-Layer implementiert sein?

    Gruß
    yogle

    0
  • E

    AFAIK gibt es in neueren Entwicklungsumgebungen einen Schalter, mit dem man einstellen kann, ob der Code als Unicode oder als normaler Ansi-C-Code erstellt wird. Die Verlinkung und Convertierung geschieht dann automatisch.

    0
  • N

    yogle schrieb:

    kann ich denn die Unicodeversion der neuen String Funktionen wie z.B. StringCbCat

    ist das sowas wie 'strcat' für wide chars? wenn ja dann gibts doch auch 'wcscat'. das geht mit sicherheit unter win9x.

    0
  • J

    yogle schrieb:

    Nur damit ich das richtig verstehe. Ich kann unter Win9x also mit z.B. CreateFileA keine Datei öffne die einen Unicodenamen hat.

    Genau. Nur Dateiname die in die aktuelle "Codepage" passen.

    yogle schrieb:

    Dazu bräuchte ich dann CreateFileW und damit ich das unterstützen kann, muss in meinem Projekt ein Unicode-Layer implementiert sein?

    Treffer.

    0
  • J

    Elektronix schrieb:

    AFAIK gibt es in neueren Entwicklungsumgebungen einen Schalter, mit dem man einstellen kann, ob der Code als Unicode oder als normaler Ansi-C-Code erstellt wird. Die Verlinkung und Convertierung geschieht dann automatisch.

    Damit wird es aber trotzdem nicht auf Win9x laufen, da dieses OS kein Unicode unterstützt...

    0
  • J

    net schrieb:

    yogle schrieb:

    kann ich denn die Unicodeversion der neuen String Funktionen wie z.B. StringCbCat

    ist das sowas wie 'strcat' für wide chars? wenn ja dann gibts doch auch 'wcscat'. das geht mit sicherheit unter win9x.

    Du hast denn Sinn der "StringXxx" Funktionen nicht ganz verstanden...

    0
  • N

    Jochen Kalmbach schrieb:

    Du hast denn Sinn der "StringXxx" Funktionen nicht ganz verstanden...

    ich kenne die noch nicht einmal 😉
    war' nur so'ne vermutung

    0
  • Y

    Na dann ist ja schlecht 😉 Blöde Win9x-Systeme.

    Da meine Anwendung aber auch unter Win9x laufen soll und ich Wide-Funktionen benötige, muss ich einen Unicode-Layer einbauen.

    Ich hab mich für Unicows entschieden, da die Lizens bei Microsofts Unicode Layer mir viel zu lang ist 😃 In der Doku steht, dass man die Libary vor alle anderen Libarys einfügen soll.
    Ich programmiere mit der Dev-Cpp IDE und weiß nun nicht wie ich da die Libary vor allen anderen einfügen soll!
    Ich hab nirgends (Makefile, Einstellungen) gesehen, wo z.B. die Kernel32.a eingefügt wird und ich die liblibunicows.a davorsetzen könnte.

    Vielleicht hat jemand damit schon einmal Erfahrungen gemacht.

    // edit:
    Diese Sache ist noch ganz interessant. Hab mal die unicows.dll disassembliert um zu schauen was diese denn macht, denn da das OS die Wide-Funktionen nicht unterstützt kann die Libary diese auch nicht herzaubern und so ist es auch. Ich hab mir mal die Funktion GetModuleFileNameW genauer angeschaut. Es scheint so, als ob die Lib mit dem übergebenen Handle die Funktion GetModuleFileNameA aufruft und dann über MultiByteToWideChar den String zu Unicode umwandelt falls es kein NT-System sein sollte!

    Also kann z.B. ein Modul doch einen Unicodenamen haben, der über Ansi-Funktionen abgefragt wird und dann danach zum richtigen Unicodenamen umgewandlt wird. Oder liege ich hier falsch?

    Gruß
    yogle

    0
  • Y

    Man soll ja immer die "Lösung" posten.

    Hab mir jetzt einfach mal den opencow Source Code gezogen 😃
    und mir die benötigten Funktionen rauskopiert. Die Funktionen rufe ich jetz intern z.B. so auf:

    DWORD WINAPI MyGetModuleFileNameW( IN HMODULE hModule, OUT LPWSTR lpFilename, IN DWORD nSize )
{
    CMbcsBuffer mbcsFilename;
    if (!mbcsFilename.SetCapacity(nSize))
        return 0;

    //TODO: does the return value include the NULL char or not??
    if (!::GetModuleFileNameA(hModule, mbcsFilename, mbcsFilename.BufferSize()))
        return 0;

    return (DWORD) ::MultiByteToWideChar(CP_ACP, 0, mbcsFilename, -1, lpFilename, nSize);
}

// der Aufruf
MyGetModuleFileNameW( hModule, szwModulePath, MAX_PATH );

    So benötige ich keine Library und keine DLL, muss mir halt die benötigten Funktionen einbauen. 🙂

    Gruß
    yogle

    0
  • J

    Aber das ist doch keine Lösung... dann kannst Du doch gleich Deine Anwendung mit ANSI übersetzen!
    Was soll den daran eine Lösung sein???

    0
  • Y

    Deswegen ja auch

    "Lösung"

    Aber so schlecht ist es gar nicht mal, denn es bietet ja nur den Nachteil, dass ich die benötigten Funktionen einfügen muss, dafür aber wie schon geschrieben, benötige ich keine DLL und keine Lib. Es funktioniert so und bietet kaum Nachteile, reicht mir erstmal 😃

    Habe aber ein weiteres Problem. Ich habe eine Datei in der UTF-8 Strings stehen und
    möchte die Strings in "normales" Unicode umwandeln. Hab es über WideCharToMutliByte versucht, allerdings kommt immer nur Mist dabei raus 😕

    Vielleicht kann da jemand ein kurzes Beispiel geben?

    Gruß
    yogle

    0
  • J

    yogle schrieb:

    Deswegen ja auch

    "Lösung"

    Aber so schlecht ist es gar nicht mal, denn es bietet ja nur den Nachteil, dass ich die benötigten Funktionen einfügen muss, dafür aber wie schon geschrieben, benötige ich keine DLL und keine Lib. Es funktioniert so und bietet kaum Nachteile, reicht mir erstmal 😃

    Ich verstehe nicht, was daran besser sein soll, als einfach mit ANSI zu übersetzen??? Ausser das es mehr Aufwand ist...

    yogle schrieb:

    Habe aber ein weiteres Problem. Ich habe eine Datei in der UTF-8 Strings stehen und möchte die Strings in "normales" Unicode umwandeln. Hab es über WideCharToMutliByte versucht, allerdings kommt immer nur Mist dabei raus 😕

    Hmm.... UTF8 ist ja auch kein WideChar, oder? Verwende also lieber MultiByteToWideChar mit CP_UTF8.

    0
  • Y

    Ich versteh irgendwie nicht ganz was du

    mit ANSI zu übersetzen

    meinst? Ich hab z.B. in meinem Code die Funktion GetModulFileNameW() da es sich ja auch um ein Modul mit Unicodenamen halten könnte. Wenn ich nun unter Win9x dies aufrufen möchte, benötige ich ja einen Unicode-Layer und da ich nun halt die Funktion MyGetModulFileNameW() anstatt von GetModulFileNameW() aufrufe funktioniert dies eben auch unter Win9x.

    Danke für die Hilfe mit dem MultiByteToWideChar, habs nun hinbekommen.

    Gruß
    yogle

    0
  • J

    Vielleicht verstehe ich ja nicht, was Du machst...
    Du musst ja sowieso zwei EXEen erstellen. Eine für W9x und eine für NT und später...
    Warum verwendest Du nicht immer nur die TCHAR-Varianten, dann kannst Du einmal ohne "UNICODE,_UNICODE" in den preprozessor-Defines übersetzen (für Win9x) und einmal mit "UNICODE,_UNICODE" (für NT und später)...

    0
  • Y

    Mach mir keine Angst! Wieso zwei EXEen? Jetzt versteh ich gar nichts mehr.
    Eigentlich dachte ich, ich könnte mein Programm soweit kompatibel halten, dass es auf Win9x _und_ WinNT oder höher läuft. Genauer geht es eingentlich um eine DLL die Mithilfe der madCodeHook Library in alle Prozesse injiziert wird, um dann manche Funktionen zu patchen. Das ist eh schon schwierig genug, da ich nicht einmal feste Strings im Code haben und nur Kernel32.dll Funktionen aufrufen darf!

    yogle

    0
  • ?

    Die Ansi-Version läuft auf allen Windows.

    0
  • J

    yogle schrieb:

    Eigentlich dachte ich, ich könnte mein Programm soweit kompatibel halten, dass es auf Win9x _und_ WinNT oder höher läuft.

    Warum machst Du Dir dann überhaupt die Mühe und verwendest die W-Funktionen, die es unter W9x nicht gibt? Wenn Du sie eh *immer* Emulierst, kannst Du auch gleich die A-Funktionen aufrufen 😕

    0
Anmelden zum Antworten