Win32 Programmierung und UNICODE
-
hi.
ich komme aus dem java bereich und bin daher gewohnt, daß alle strings unicode sind und alle chars ansi. bei win32 verwirrt mich daher die fülle an verschiedenen datentypen und angepaßten funktionen. ich würde gerne wie vorher generell alle strings unicode und alle chars ansi halten. sollte ich daher
- WCHAR (anstatt TCHAR),
- _T (anstatt TEXT),
- wprintf (anstatt _tprintf)
bevorzugen? auf den ersten blick scheinen die fragen leicht zu beantworten. doch selbst win32 projekte, die mit assistentvorlagen erstellt werden, inkludieren tchar.h und auch im buch "windows programmierung" wird extra immer TEXT/TCHAR verwendet.
warum sollte man überhaupt programme kompatibel halten zu sowohl ansi als auch unicode? nur damit es noch auf windows 95 läuft?
hoffe, jemand kann da ein bißchen licht ins dunkel bringen.
wan-hi
-
Wie du richtig erkannt hast, laufen Unicode-Programme nur auf NT. Wenn dich W9x nicht interessiert, kannst du natürlich alles in Unicode machen, allerdings kommt es auch oft vor, dass man mit anderen Bibliotheken sprechen muss, und diese gibt es fast nie in Unicode. Zumindest dafür müsstest du also dann hin- und herkonvertieren.
-
was ist eigentlich der genaue unterschied zwischen der definierung von UNICODE und _UNICODE? beide mappen generische "T" datentypen auf unicode varianten und setzen bei stringmakros ein "L" voran. ich beziehe mich vor allem auf das buch "windows programmierung" von charles petzold, wo der unterschied nicht klar wird.
... Der Einfachheit halber habe ich in die Debug-Konfiguration jeweils das Symbol UNICODE (bei der Verwendung von C-Bibliotheksfunktionen zusätzlich: _UNICODE) eingesetzt: ...
bedeutet das, daß ich _UNICODE definieren muß, damit bei der verwendung von standard funktionen der c bib unicode versionen genommen werden und sonst nichts? UNICODE ist dann also zusätzlich notwendig für win32-spezifische generische funktionen / datentypen?
*verwirrt*
-
Du brauchst nicht verwirrt zu sein. Es ist eigentlich ganz simpel, und du hast es bereits auf den Punkt gebracht. Wenn du das Symbol UNICODE definierst, dann lässt der Präprozessor alle UNICODE-Versionen der WinAPI-Funktionen stehen und exkludiert die ANSI-Versionen. Damit das gleiche mit den Funktionen in der C-Lib geschieht, musst du das _UNICODE Symbol definieren. Beide Symbole haben also ihren Zweck; warum es jedoch nicht einfach ein einziges Symbol gibt, das die Wirkung von beiden hat, ist mir unbekannt, und im Prinzip irrelevant, oder?
-
Übrigens:
Hier sind Links, die mir dabei geholfen haben die UNICODE-Welt näher kennenzulernen; vorallem aus der Perspektive eines Windows Programmierers (was allerdings klar sein sollte).
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q181/6/04.asp&NoWebContent=1
http://www.microsoft.com/msj/0499/multilangunicode/multilangunicode.aspx
http://www.joelonsoftware.com/articles/Unicode.html
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mslu/winprog/using_the_microsoft_layer_for_unicode.asp
http://www.microsoft.com/middleeast/msdn/VC-Arabic.aspx
ftp://ftp.microsoft.com/developr/msdn/newup/glossary
http://www.microsoft.com/globaldev/dis_v1/disv1.asp
ftp://ftp.microsoft.com/developr/msdn/newup/glossary
http://www.microsoft.com/msj/1198/multilang/multilang.aspx
http://mattandjess.net/c++/index.html
http://www.microsoft.com/technet/prodtechnol/winntas/tips/intcodck.mspx
http://www.microsoft.com/globaldev/handson/dev/muiapp.mspx
http://www.yare-vb.com/Vor ein paar Wochen habe ich mich entschieden mit dem wxWidgets-Framework zu programmieren, weil die WinAPI mir schon etwas zu mühselig wurde. Das tolle an wxWidgets ist, dass es in erster Linie eine plattformunabhängige GUI Library ist und außerdem auch plattformspezifischen Code erlaubt. Somit denke ich, dass es doch von großem Nutzen war, dass ich das Programmieren mit der WinAPI angefangen habe. Die Erfahrungen, die ich gemacht habe erlauben mir nämlich zu jeder Zeit problemlos speziellen Code schreiben zu können, wenn mich wxWidgets einschränken sollte (was man nur notgedrungen tun sollte, weil der Code dann auch portiert werden muss -> bedeutet Extra-Aufwand). Was ich sagen will, ist, dass der Aufwand, den ich getrieben habe um die WinAPI zu erlernen (Gott sei Dank) nicht umsonst war; es hat mir viel Detailwissen im Bereich der GUI-Programmierung eingebracht.