Hallo,

ich verwende jetzt eine WinAPI, die laut MSDN erst ab Windows CE 2.1 und jünger läuft. Welche OS-Versionen wären das? XP ja, ME, 98 und 95 nicht. Mir würde es auch schon reichen, wenn ich die Versionsnummern wüsste für:

Ähm, die ist schon klar, dass WinCE Windows für PDAs ist?

Jupp, aber zu der WinAPI die ich nutzte, steht als mindestanforderung nun einmal WinCE (und ein Kommentar, warum es unter ME/98/95 nicht funktioniert, während es unter XP funktioniert ).

Wenn Du mit Delphi programmierst wirt es auch nie unter Windows CE funktionieren. Kannst Dir diese Prfüfung also sparen.

Dann hohle ich eben meine Beweise raus : MSDN siehe hier und der Beweis das die API funktioniert siehe hier (die Alpha).

Mein Emulator bietet keine WinCE version an, kann es also nicht testen. Hast Du es denn selber schon auf einem Gerät mit WinCE getestet?

Ne, ich hab nur XP und 95. Mit 98 habe ich heute in der Schule getestet. Die Ergebnisse stimmen mit dem Kompatabilitätsmodus überein.

Bloß weil die API-Funktion unter CE existiert, heißt das nicht, dass dein Programm unter CE läuft. Ist schließlich ein anderer Prozessor. Außerdem haben CE-Programme glaube ich (korrigiert mich wenn ich mich irre) einen anderen Header.
Wenn das steht: WinCE und WinXP, dann läuft es unter CE und höher, also alle PocketPC-Versionen, und unter XP. CE ist eine völlig andere Produktlinie.
Da im MSDN steht WinCE, sollte es auch nur unter CE laufen. Seltsam, wenns unter XP läuft...

Mhm, ich geb mich geschlagen . Bei dem MSDN-Suchergebnis habe ich danach ausschau gehalten, wo das W dran ist. Ich hab zwar beim "normalen" vorbeigeguckt, aber naja, bin da nicht weiter drauf eingegangen. Ich hätte vlt. die Bemerkung nicht gleich vergessen sollen *g*.

Zitat:

Unicode Implemented as FindFirstFileW (Unicode) and FindFirstFileA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode.

welche mindestabfrage erfordert das? Denn ich weiß nicht in wie weit NT etc. Unterstützt wird (und Vista ).

Die W-WinAPI-Funktionen gibt es i.d.R. ab Windows NT (NT, 2000, XP, 2003, Vista, ...). Den Microsoft Layer for Unicode kannst Du vergessen da der die Aufrufe unter Win9x/ME nur auf die A-Versionen der API-Funktionen umbiegt (Da nimmst Du besser die TNTWare-Controlls.

Bernhard Geyer hat folgendes geschrieben:

Den Microsoft Layer for Unicode kannst Du vergessen da der die Aufrufe unter Win9x/ME nur auf die A-Versionen der API-Funktionen umbiegt (Da nimmst Du besser die TNTWare-Controlls.

Die (externen Controls) nimmt er doch ohnehin besser, wenn er mit Delphi programmiert, weil die VCL auch unter NT ff. kein Unicode kapiert

und die TNTs können auch nur da Unicode, wo es Windows auch gut kann, offizell können sie es unter Win9.x gar nicht

tommie-lie hat folgendes geschrieben:

Die (externen Controls) nimmt er doch ohnehin besser, wenn er mit Delphi programmiert, weil die VCL auch unter NT ff. kein Unicode kapiert

Nicht die VCL ist das Problem sondern die von Borland gelieferten WinAPI-Wrapper Komponenten wie TButton, TEdit, .... Wenn es ein Grundsätzliches Problem wäre könnten TNTWare oder die Elpack-Komponenten ja auch kein Unicode. Und das ElPack kann Unicode sogar unter Win9x/ME wo selbst .NET scheidert.

Ich hab mir einfach mal die Abfrage der TNT-Controls angeguckt, welche Abfrage die nehmen. Es war mal wieder zu leicht *g*:

Bernhard Geyer hat folgendes geschrieben:

Nicht die VCL ist das Problem sondern die von Borland gelieferten WinAPI-Wrapper Komponenten wie TButton, TEdit, ....

... die Teil der Visual Component Library sind. Richtig, es ist nicht die VCL selbst, es ist der Inhalt der VCL. Die drei Buchstaben sind komplett unschuldig.

Bernhard Geyer hat folgendes geschrieben:

Wenn es ein Grundsätzliches Problem wäre könnten TNTWare oder die Elpack-Komponenten ja auch kein Unicode. Und das ElPack kann Unicode sogar unter Win9x/ME wo selbst .NET scheidert.

Diese Komponenten (insbesondere wohl letztere) benutzen "lediglich" eigene Zeichenroutinen. Von Datentypen wie TCaption können sie dennoch keinen Gebrauch machen, da dieser nunmal ein Ansi-String ist. Klar kann man da UTF8-Zeichen unterbringen, aber dann bräuchte ich ja zusätzlich auch noch allerhand Konvertierungs-Infrastuktur.
Ich weiß nicht wie "tief" TNTControls und ElPack ansetzen, aber ich denke, daß es "sehr tief" ist, denn dort, wo es in der VCL anfängt, grafisch zu werden, hört die Unicode-Unterstützung auf. Ich kann also nicht einfach von TCustomButton ableiten, weil TCustomButton bereits ein Interface definiert, das ausschließlich Ansi spricht.
So kann ich schon nicht von TControl ableiten, weil bereits TControl die Properties Caption und Text mit dem Typ TCaption bereitstellt. Während diese beiden noch Protected sind und ich sie in einer Ableitung durch UCaption und UText ersetzen könnte, ist das Property Hint vom Typ String bereits in TControl published. Diese Sichtbarkeit kriege ich nicht mehr weg und hätte entweder nur einen Ansi-Hint, zwei Hint-Felder (Hint und UHint) parallel, oder msste auf UTF-8 ausweichen, mit der Notwendigkeit zu performanten Konvertierungsmöglichkeiten, weil die meisten Unicode-Systemfunktionen (sprich: alle W-Funktionen) nach wie vor gerne 2Byte-Zeichen hätten und keine 1Byte-Zeichen.
Und mal ehrlich, jede Eingabe und jede Ausgabe vor jeder Operation von UTF-8 nach UTF-16 (oder UCS-2? ich weiß grad' nicht wie die W-Funktionen die Bytes interpretieren) und zurück zu konvertieren ist nicht das, was ich von einem Framework erwarte, das mir Unicode-Fähigkeit bieten soll. Abgesehen davon daß die RTL immer noch nicht sonderlich WideString-freundlich ist, was beispielsweise ein (zum Beispiel bei Funktionsparametern sinnvolles) Reference Counting angeht.

Das Elpack setzt früh an um auch ein Theming zu realisieren das unabhängig vom XP-Theming laufen könnte.

Auch ist es kein Problem publisched Properties neu als Widestring zu veröffentlichen. Als ist der Umweg über UTF8 oder WideProperty nicht nötig. Selbst Unicode-Hints bekommen die Hint (zusätzlich auch noch mit der Möglichkeit der HTML-Formatierung).

Referenzcounting vermisse ich nicht. Selbst bei Ansi-Strings ist es performancetechnisch von Vorteil die nicht veränderlichen Parameter als Const zu definieren. Bei Widestring ist es doppelt von Vorteil.

Bernhard Geyer hat folgendes geschrieben:

Referenzcounting vermisse ich nicht. Selbst bei Ansi-Strings ist es performancetechnisch von Vorteil die nicht veränderlichen Parameter als Const zu definieren. Bei Widestring ist es doppelt von Vorteil.

Mir ist nicht bekannt, daß es etwas wie const returntype func(sometype param); auch in DelphiLanguage gibt. (mir ist bewusst daß es auch in C(++) keine sinnvolle Möglichkeit für Pascal-ähnliche Compiler Magic gibt, daß also ein "const WideString" als Ergebnistyp kein echter Ersatz wäre)
Außerdem denke ich, daß es noch andere Verwendung für Referenzzählung gibt, zum beispiel bei temporären Puffern bei denen ungewiss ist, ob sie sich im Laufe der Funktion ändern werden oder nicht (manchmal kommt man mit einem const parameter auch nicht weiter, ohne den String zu kopieren).
Danny Thorpe ist/war nicht grundlos der Meinung, daß reference counting ein notwendiges Merkmal von neuen WideStrings sein soll, als es darum ging, sie in einem 64bit-Compiler zusammen mit einer Unicode-VCL "richtig" zu implementieren und nicht aus COM-Kompatibilität als BSTR. Ob sich die Sicht der Dinge zusammen mit dem Inhaber von Delphi geändert haben, weiß ich nicht.

Bernhard Geyer hat folgendes geschrieben:

Auch ist es kein Problem publisched Properties neu als Widestring zu veröffentlichen. Als ist der Umweg über UTF8 oder WideProperty nicht nötig. Selbst Unicode-Hints bekommen die Hint (zusätzlich auch noch mit der Möglichkeit der HTML-Formatierung).

Mir war nicht bekannt, daß man geerbte Identifiers mit anderer Signatur aber gleichem Namen erneut deklarieren kann.