Unicode String Funktionen

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

Jochen Kalmbach

yogle schrieb:

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

Dann wirst Du diese EXE aber unter Win9x nicht starten können, da der "Lader" der EXE die W-Funktionen nicht auflösen kann, da diese eben nicht vorhanden sind. Somit wird schon das Laden Deiner EXE abgebrochen.

yogle schrieb:

Kann es sein, dass unter WNT intern als Stringformat UTF-16 benutzt wird

Ja. Genauer gesagt UCS-2 was aber keine Bedeutung

yogle schrieb:

MessageBoxW nicht alle UTF-Zeichen anzeigen kann?

Woher hast Du denn das?

yogle schrieb:

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

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

Hast Du auch wirklich UTF_8 eingelesen? Sind bei Dir auch alle Schriftarten installiert?

yogle

Jochen Kalmbach schrieb:

Dann wirst Du diese EXE aber unter Win9x nicht starten können, da der "Lader" der EXE die W-Funktionen nicht auflösen kann, da diese eben nicht vorhanden sind. Somit wird schon das Laden Deiner EXE abgebrochen.

Achso, dann natürlich schon. Ich würde ja gerne den fertigen Unicode-Layer benutzen, weiß aber nicht wie ich die Library vor allen anderen einfügen könnte.

Jochen Kalmbach schrieb:

yogle schrieb:

MessageBoxW nicht alle UTF-Zeichen anzeigen kann?

Woher hast Du denn das?

Dacht mir nur, da sie sonst mit UltraEdit, Notepad korrekt angezeigt wird. Was ja eigentlich auch bedeuten müsste das ich die benötigten Sprachen installiert habe und es ist ganz sicher eine UTF-8 Datei.

Aber der Code stimmt soweit?

yogle

Jochen Kalmbach

yogle schrieb:

Aber der Code stimmt soweit?

Nein. Du übergibst einen zu kleinen Puffer für die UNICODE-Zeichen... dann wird versucht so viel wie möglich zu konvertieren und dann aber nicht NUL-terminiert... somit gibt er dann irgendwas aus, was nach dem Puffer steht...

Bzgl. MSLU: Was ist da genau Dein Problem?
http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx
http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx

yogle

Sollt es so aussehen?

szwFileRead = malloc( (dwFileSize + 1) * sizeof(wchar_t) );

Wenn, dann ok, ändert aber nichts.

Jochen Kalmbach schrieb:

Bzgl. MSLU: Was ist da genau Dein Problem?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/compiling_your_application_with_the_microsoft_layer_for_unicode.asp
Genau das hier:

Add the following to the link options for your application (note that these libraries are not separated by commas because that is how you add them to the link list):

* First, add the following: /nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib.

* Then add UnicoWS.lib. <-- Lib _vor_ allen anderen einfügen

* Finally, add the following libraries: Kernel32.lib Advapi32.lib User32.lib Gdi32.lib Shell32.lib Comdlg32.lib Version.lib Mpr.lib Rasapi32.lib Winmm.lib Winspool.lib Vfw32.lib Secur32.lib Oleacc.lib Oledlg.lib Sensapi.lib. In this step, omit any libraries listed after Kernel32.lib whose APIs are not used in your application. However, if your application uses another component, such as MFC, ATL, or CRT, be sure to include any libraries on which the component depends.

Das Problem ist ja, dass ich nicht weiß, wo ich bei Dev-Cpp die Lib vor allen anderen einfügen kann.

yogle

Jochen Kalmbach

yogle schrieb:

Sollt es so aussehen?

Du solltest zuerst mal die erforderliche Größe ermitteln (sie Doku zu MultiByteToWideChar) und dann erst die Konvertierung durchführen. Auch solltest Du nicht vergessen ein NUL-Zeichen am Ende zu setzen (wenn nötig).
Ein Beispiel für den umgekrehrten Weg, siehe (ganz unten):
http://www.c-plusplus.net/forum/viewtopic-var-t-is-146786.html

yogle schrieb:

Das Problem ist ja, dass ich nicht weiß, wo ich bei Dev-Cpp die Lib vor allen anderen einfügen kann.

Dann solltest Du das im Compiler-Forum fragen.... den ganze Thread dorthin zu verschieben macht keinen Sinn, oder?