zudem würde ich gerne folgende Frage beantwortet haben:

Warum kann bei der Verwendung von Unicode beim Aufruf von CreateProcess der Parameter CmdLine nicht direkt vor Ort z.B. mit L“calc.exe“ angegeben werden?

danke

SIcher kannst Du bei einem Unicode Projekt direkt die COmmandline mit L"calc.exe" für CreateProcess angeben.

zu 1.:

ich habe unter projekt->eigenschaften den zeichensatz auf "nicht festgelegt" stellen müssen um mein programm zum laufen zu bekommen. als unicode eingestellt war, lief das programm nicht!

hier der code:

STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);

ZeroMemory( &pi, sizeof(pi) );

if( !CreateProcess(

NULL, // Kein Modulname, Kommando-Zeile benutzen

"calc.exe",// Kommando-Zeile

NULL, // Prozess-Handle nicht vererbbar

NULL, // Thread-Handle nicht vererbbar

FALSE, // Handle.Verebung auf FALSE 

NORMAL_PRIORITY_CLASS,  // Normale Priorität

NULL, // Eltern-Evironment-Block verwenden

NULL, // Elternverzeichnis als Startverzeichnis

&si,// Zeiger auf Startup-Struktur

&pi // Zeiger auf Process-Informations-Struktur

))

{
printf( "CreateProcess failed (%d).\n", GetLastError() );
return;
}

Der folgende Code geht immer:

CreateProcess(
NULL, // Kein Modulname, Kommando-Zeile benutzen
_T("calc.exe"),// Kommando-Zeile
...

Grund: Egal auf CreateProcessA oder CreateProcessW verwendet wird. Immer wird die Zeichenkette durch den T-Makro korrekt interpretiert.

Der folgende Code nur in Unicode

CreateProcess(
NULL, // Kein Modulname, Kommando-Zeile benutzen
L"calc.exe",// Kommando-Zeile
...

Aus CreateProcess wird CreateProcessW! Es wird also ein wchar_t (Unicode) String erwartet.

Und hier muss MBCS oder nichts eingestellt sein.

CreateProcess(
NULL, // Kein Modulname, Kommando-Zeile benutzen
"calc.exe",// Kommando-Zeile
...

Aus CreateProcess wird CreateProcessA! Es wird also ein char String erwartet.

Dein Code geht mit Sicherheit *nicht* mit Unicode! Zumindest nicht ab VS2005!

Du hast die Kleinigkeit vergessen, dass der zweite Parameter beschreibbar sein muss. Und ab VS2005 werden string-literale im read-only Bereich abgelegt. Somit erzeugt dies eine Access-Violation.

Für eine Funktionierendes Beispeiel siehe Doku:
http://msdn.microsoft.com/en-us/library/ms682425.aspx
(ganz unten)

Dein Beispiel funktioniert nur für ANSI, da intern beschreibbarer Speicher allokiert wird um den String nach Unicode umzuwandeln

Man schmeißt halt nicht alle Postings durch den Compiler...

Warum kann bei der Verwendung von Unicode beim Aufruf von CreateProcess der Parameter CmdLine nicht direkt vor Ort z.B. mit L“calc.exe“ angegeben werden?

also ist diese Aussage falsch bzw irreführend?

Warum kann bei der Verwendung von Unicode beim Aufruf von CreateProcess der Parameter CmdLine nicht direkt vor Ort z.B. mit L“calc.exe“ angegeben werden?

also ist diese Aussage falsch bzw irreführend?

Was heisst hier falsch. Die Aussage ist richtig:

Der 2. Parameter *muss* ein beschreibarer String sein! String-Literale sind *nicht* beschreibbar, deswegen geht es nicht.

Sorry, falls ich hier den Thread störe

Viele Grüße,
Michael

was ist ein String-Literal?

"abc"

Soweit ich weiß, benutzt Windows für seine Unicode-Darstellung UTF-16, stimmt das?

Genauer gesagt UCS-2, da es damals (NT3.1) noch kein UTF-16 gab
Siehe auch: UCS-2 vs. UTF-16 (not quite Kramer vs. Kramer)
http://blogs.msdn.com/michkap/archive/2005/05/11/416552.aspx

Decimad schrieb:

Was ist denn in Windows mit Multi-Byte-Strings gemeint?

I.d.R. meint man damit alle "proprietären" Zeichensätze die aus 1-n Bytes pro Codepoint bestehen.

Decimad schrieb:

Wäre nicht auch UTF-16 dem Wortverstädnis nach so etwas? Zu diesem Multi-Byte finde ich immer so wenig.

Wenn man es genau nimmt: Ja. Nur mit dem unterschied dass es hier kein *Mulit*-*Byte* ist sonder max ein *Zwei*-*Wort*

Decimad schrieb:

Unter Windows ist folglich ein wchar_t auch ein "short"?

naja... würde ich jetzt nicht so sagen... per default sind diese Typen ab VS2008 nicht mehr kompatibel

Decimad schrieb:

Wie geht man denn mit wstrings am besten um

Die Frage verstehe ich nicht ganz.... wstring *ist* UTF-16...

Decimad schrieb:

, schließlich kann man ja in UTF-16 auch ein Zeichen aus mehreren Einzelzeichen zusammensetzen

WAS verstehst Du unter *Zeichen*? Du kannst auch in UTF-32 ein Zeichen (Glyph) aus hunderten von Codepoints zusammensetzen!!!
Ein sehr schönes Beispiel findet sich hier:
http://blogs.msdn.com/michkap/archive/2006/02/17/533929.aspx

Decimad schrieb:

und hat somit dasselbe Problem wie mit UTF-8, aka durch Buchstaben zu iterieren ist gar nicht mal trivial.

Wie gesagt. Das _Problem_ hast Du mit allen Codepoints; unabhängig des Encodings!

Siehe auch mein Artikel zu Unicode:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-161855.html

Viele Grüße,
Michael

Die Frage verstehe ich nicht ganz.... wstring *ist* UTF-16...

std::wstring ist std::basic_string<wchar_t>, und auf Windows Plattformen ist üblich dass wchar_t 16 Bit breit ist. Das war's aber auch schon. Wenn man möchte kann man auch UTF-7 in einem std::wstring speichern. Oder die Liste der ersten so-und-so-viel Primzahlen. Oder einfach irgendwas

Es hat sich eingebürgert unter Windows UTF-16 Strings in std::wstring abzuspeichern, und wenn man wo einem std::wstring vor den Latz geknallt bekommt, von einem Programmteil oder einer Library die nicht dokumentiert was denn drinnen ist, dann tut man gut daran anzunehmen dass UTF-16 drinnen steht.

naja... würde ich jetzt nicht so sagen... per default sind diese Typen ab VS2008 nicht mehr kompatibel

Ab VS 2005 wenn ich mich richtig erinnere. VS 2003 .NET hatte default noch auf "wchar_t per typedef", VS 2005 hat default bereits auf "wchar_t = builtin type"