Unicode String Funktionen

yogle

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

Elektronix

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.

net 0

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.

Jochen Kalmbach

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.

Jochen Kalmbach

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...

Jochen Kalmbach

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...

net 0

Jochen Kalmbach schrieb:

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

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

yogle

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

yogle

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

Jochen Kalmbach

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???

yogle

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

Jochen Kalmbach

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.

yogle

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

Jochen Kalmbach

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)...

yogle

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

Die Ansi-Version läuft auf allen Windows.

Jochen Kalmbach

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

yogle

Damit ich den korrekten Unicodenamen erhalte muss ich ja entweder die Ansiversion aufrufen (W9x) und dann umwandeln, also die W-Funktion emulieren, oder sie direkt aufrufen (WNT). Eine Unterscheidung wann ich welche aufrufe will ich noch einbauen.

Aber ich kann keinen Unterschied mehr zu einem Unicode-Layer erkennen? Dieser macht doch exakt das selbe und ich kann ja auch nicht auf den Unicodenamen verzichten, da dieser unter ANSI Mist ist.

Jochen Kalmbach

yogle schrieb:

Eine Unterscheidung wann ich welche aufrufe will ich noch einbauen.

Die ENtscheidung kann ja aber nur dynamisch (also mit LoadLibrary/GetProcAddress) erfolgen, wenn Du nur eine EXE haben willst...

yogle schrieb:

Aber ich kann keinen Unterschied mehr zu einem Unicode-Layer erkennen? Dieser macht doch exakt das selbe und ich kann ja auch nicht auf den Unicodenamen verzichten, da dieser unter ANSI Mist ist.

Ja. Warum nimmst Du nicht den MSLU?

yogle

So früh schon wieder dran? Respekt!

Wieso denn dynamisch. Wollte es so ungefähr machen:

// Pseudocode
if( WinNT )
{
    W-Funktion
}
else
{
    A-Funktion
    Umwandlung
}

da brauch ich doch nichts mit dynamischen laden der DLL machen.

Diese Unicodesache ist mir doch recht suspekt. Hab jetzt schon zig Artkiel gelesen aber das ganze ist recht umfangreich. Kann es sein, dass unter WNT intern als Stringformat UTF-16 benutzt wird und MessageBoxW nicht alle UTF-Zeichen anzeigen kann?

Habs bisher probeweiße so gemacht:

char      *szcFileRead  = NULL;
wchar_t   *szwFileRead  = NULL;

// Arraygröße anpassen
szcFileRead = malloc( dwFileSize + 1);

// Datei komplett einlesen
if( !ReadFile( hFile, szcFileRead, dwFileSize, &dwBytesRead, NULL ))
{
    MessageBox( NULL, "Fehler ReadFile", "Fehler", MB_OK );
    CloseHandle( hFile );
    return 0;
}

CloseHandle( hFile );

szwFileRead = malloc( dwFileSize + 1 );

// Umwandlung zu UTF
MultiByteToWideChar( CP_UTF8, 0, szcFileRead, -1, szwFileRead, dwFileSize );

MessageBoxW( NULL, szwFileRead, L"Ausgelesen", MB_OK );

Das Original:
αβγабвאבג⅓⅔⅛⅜⅝⅞Ω☼♪♫ﻹﻺﻻﻼ
abc åäö

MessageBoxW:
αβγабвבג□□⅛⅜⅝⅞Ω□□□□□□□□□ﻹﻺﻻﻼ
abc åäö

Irgendwas stimmt noch nicht. Werd mich noch mal dran setzen müssen.

Gruß
yogle