Versionen der Apis?

Hallo Leute,

die meisten Apis liegen in mehreren Versionen vor.
A) Großes A am Ende meint Ansi Version
Großes W am Ende meint Unicode Version
C) Weder A noch W meint das es sich der Compiler aussucht welche Version benutzt wird

Für welche Api sollte ich mich für ein Projekt entscheiden?
1. Nach welchen Kriterien entscheidet sich der Kompiler wenn ich Version C) verwende?
2. Wenn ich die Ansi Version verwende, läuft dann mein Tool in Asien nicht mehr?
3. Wenn ich die Unicode Version nehme, bin ich dann immer auf der sicheren Seite? (Performance ist nicht so wichtig.)

Vielen Dank

tobZel

WinApi Neuling schrieb:

Für welche Api sollte ich mich für ein Projekt entscheiden?
1. Nach welchen Kriterien entscheidet sich der Kompiler wenn ich Version C) verwende?

Kommt dann drauf an ob UNICODE definiert ist also

#define UNICODE

jetzt nimmt er W funktionen sonst A.

WinApi Neuling schrieb:

2. Wenn ich die Ansi Version verwende, läuft dann mein Tool in Asien nicht mehr?

Doch, der standort des PCs ist egal.
Stell dir vor du nimmst einen Laptop nach Asien mit und jetzt ist er kaputt...

Naja
das Prog läuft schon blos der anwender sieht eben nur müll.

WinApi Neuling schrieb:

3. Wenn ich die Unicode Version nehme, bin ich dann immer auf der sicheren Seite? (Performance ist nicht so wichtig.)

Von der Programmierer Seite schon blos kann ein Chinese wenig mit Deutsch anfangen
und wenn der Zeichensatz keine Üs oder Äs... unterstützt kann er die auch mit Unicode nicht sehen.

mfg tobZel

Ich dachte Unicode würde garantieren das der Text überall richtig interpretiert wird? Du meinst es steht nicht fest ob der Chinese einen Font installiert hat der deutsche Umlaute darstellen kann?

CodeFinder

WinApi Neuling schrieb:

3. Wenn ich die Unicode Version nehme, bin ich dann immer auf der sicheren Seite? (Performance ist nicht so wichtig.

Mehr oder weniger schon. Wenn Du dann Zeichen verwendest, die das entsprechende Zielsystem nicht darstellen kann, liegt das nicht mehr an Dir, sondern eben am Zielsystem. Du kannst zur Not eine Information anzeigen, alá: "Falls Sie Darstellungsprobleme mit den Schriften haben, installieren Sie bitte die Schrift XYZ."

Jochen Kalmbach

Es ist eigentlich egal, was Du nimmst!
Das wichtigeste ist nur: Verwende *immer* und konsequent "tchar.h"!!!!
Dann kannst Du immer noch von UNICODE auf ANSI oder zurück wechseln, ohne auch nur eine Zeile Code anzufassen!

CodeFinder

Aber da brauch er ja nicht unbedingt tchar.h inkludieren. TCHAR ist in den std-Windows-Headern definiert und lstrcpy, lstrlen gibts da auch .

Jochen Kalmbach

Doch, er muss tchar includieren, sonst geht das alles nicht wenn man die CRT verwendet...
Nur ohne CRT braucht man die tchar.h nicht einzubinden...

CodeFinder

Jochen Kalmbach schrieb:

Doch, er muss tchar includieren, sonst geht das alles nicht wenn man die CRT verwendet...
Nur ohne CRT braucht man die tchar.h nicht einzubinden...

Hm joar stimmt, hab grad mal nachgeguckt, aber ob ich nun lstrlen oder _tcslen (dieser Name ist ja echt so sinnfrei ... ) verwende ist doch egal oder ?

Jochen Kalmbach

Es gibt halt nicht zu allen CRT-Funktionen auch Windows-Pedants...
Auch müsstest Du dann einen eigenen Entry-Point definieren, da Du zumindest für "_tmain" das tchar.h brauchst...

Erstmal vielen Dank für die Antworten

Wenn ich variabel sein möchte, müsste ich also die Datentypen und String Operationen aus der tchar.h nehmen.
Die tchar.h gibt es nicht im include Verzeichnis meines SDK oder bei den Dateien vom VS6. Ich finde sie nur im Vezeichnis: C:\Program Files\Microsoft SDK\src\crt
Muß ich das jetzt auch immer mit einbinden?

Was hat es mit wmain auf sich? In tchar.h steht:
#define _tmain wmain
Wo ist dieses wmain definiert? Reicht es nicht wenn ich meiner main() Routine einfach einen "wchar *param[]" geben lasse?

Der int scheint bei Unicode ein wint_t zun sein. Wenn ich das in der tchar.h auflöse komme ich zu einem unsigned short (also nur 2 Bytes):
http://msdn2.microsoft.com/de-de/library/c426s321(VS.80).aspx
Liegt das daran das Unicode schon soviel Platz wegnimmt und man deshalb das mit dem kürzeren int wieder gut machen wollte? *g*

Ich werde durchgehend die Unicode Variante nahmen, weil man in C++ scheinbar nicht so einfach zwischen Unicode und Ansi hin und her schalten kann. CStoll hatte vorgeschlagen selber ne Menge TypeDefs zu machen das ist aber zuviel Aufwand. Ich wüsste auch nicht wozu man eine reine Ascii Variante erstellen sollte.

Hat sich also erledigt. Vielen Dank

CodeFinder

WinApi Neuling schrieb:

Wenn ich variabel sein möchte, müsste ich also die Datentypen und String Operationen aus der tchar.h nehmen.
Die tchar.h gibt es nicht im include Verzeichnis meines SDK oder bei den Dateien vom VS6. Ich finde sie nur im Vezeichnis: C:\Program Files\Microsoft SDK\src\crt
Muß ich das jetzt auch immer mit einbinden?

Eigentlich solltest Du die SDK-Include-Verzeichniss zu den Standard-Include-Verzeichnissen Deines Compilers/IDE hibzufügen.

WinApi Neuling schrieb:

Was hat es mit wmain auf sich? In tchar.h steht:
#define _tmain wmain

Das ist eben die UNICODE-Version von main. _tmain ist die Zeichensatz unabhängige Version.

WinApi Neuling schrieb:

Wo ist dieses wmain definiert? Reicht es nicht wenn ich meiner main() Routine einfach einen "wchar *param[]" geben lasse?

Nein, das reicht nicht. main ist die ASCII/ANSI-Variante (char), wmain die UNICODE-Variante (wchar_t).

WinApi Neuling schrieb:

Der int scheint bei Unicode ein wint_t zun sein. Wenn ich das in der tchar.h auflöse komme ich zu einem unsigned short (also nur 2 Bytes):
http://msdn2.microsoft.com/de-de/library/c426s321(VS.80).aspx
Liegt das daran das Unicode schon soviel Platz wegnimmt und man deshalb das mit dem kürzeren int wieder gut machen wollte? *g*

lol ?! ... also char ist immer mindestens 1 Byte groß, wchar_t ist mindestens 2 Bytes groß. int hat damit eigentlich gar nix zu tun.