Unicode String Funktionen
-
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.
-
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.
-
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...
-
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...
-
Jochen Kalmbach schrieb:
Du hast denn Sinn der "StringXxx" Funktionen nicht ganz verstanden...
ich kenne die noch nicht einmal

war' nur so'ne vermutung
-
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
-
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
-
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???
-
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
-
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.
-
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
-
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)...
-
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.
-
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

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