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

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

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

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.

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.

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

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

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

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

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

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

"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

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.

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

yogle

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

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.

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?

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

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?

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

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