evc4 & MFC: seulement UNICODE, pourtant le RTC "semble" aussi dispo en SBCS
2 réponses
machin
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 &
winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ?
* Je constate que le wizard de evc4 génère toujours des projets avec /D
UNICODE
* Tous les makefile des samples des SDK sont aussi /D UNICODE
* le makefile des sources des MFC contient également /D UNICODE. de plus il
n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode
comme avec windows)
* l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI
ex: LoadString devient soit LoadStringW ou LoadStringA.
LoadStringA est effectivement défini (cf. winbase.h)
Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour
compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les
utiliser (aucune n'est implémentée) ?
est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et
dans les .lib
c'est simplement dans l'intention de fournir des tools si l'appli manipule
des strings ANSI issues de données externes mais certainement pour des
strings à passer à l'OS
Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE
Si je comprends bien, dans ce cas la première chose à faire est de faire une
version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE ?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec
maintient de la compatibilité des sources
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alain Zanchetta [MS]
Bonjour,
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas proposées (toute la philosophie de l'API Windows CE est là : ne pas proposer 36 façons de faire la même chose) contrairement à XP. Dans les .H, on a les deux versions car les .H sont les plus semblables possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE). Au passage, je pense qu'il faut essayer d'utiliser systématiquement les types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la place de strcpy, etc...) lorsqu'on développe une application Win32, car cela facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" wrote in message news:41a5c220$0$17796$
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 & winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ? * Je constate que le wizard de evc4 génère toujours des projets avec /D UNICODE * Tous les makefile des samples des SDK sont aussi /D UNICODE * le makefile des sources des MFC contient également /D UNICODE. de plus il n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode comme avec windows) * l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI ex: LoadString devient soit LoadStringW ou LoadStringA. LoadStringA est effectivement défini (cf. winbase.h) Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les utiliser (aucune n'est implémentée) ? est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et dans les .lib c'est simplement dans l'intention de fournir des tools si l'appli manipule des strings ANSI issues de données externes mais certainement pour des strings à passer à l'OS Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE Si je comprends bien, dans ce cas la première chose à faire est de faire une version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE ?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec maintient de la compatibilité des sources
merci
Bonjour,
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme
la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas
proposées (toute la philosophie de l'API Windows CE est là : ne pas proposer
36 façons de faire la même chose) contrairement à XP.
Dans les .H, on a les deux versions car les .H sont les plus semblables
possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de
portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE).
Au passage, je pense qu'il faut essayer d'utiliser systématiquement les
types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la
place de strcpy, etc...) lorsqu'on développe une application Win32, car cela
facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" <machin@truc.com> wrote in message
news:41a5c220$0$17796$626a14ce@news.free.fr...
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 &
winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ?
* Je constate que le wizard de evc4 génère toujours des projets avec /D
UNICODE
* Tous les makefile des samples des SDK sont aussi /D UNICODE
* le makefile des sources des MFC contient également /D UNICODE. de plus
il
n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode
comme avec windows)
* l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI
ex: LoadString devient soit LoadStringW ou LoadStringA.
LoadStringA est effectivement défini (cf. winbase.h)
Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour
compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les
utiliser (aucune n'est implémentée) ?
est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et
dans les .lib
c'est simplement dans l'intention de fournir des tools si l'appli manipule
des strings ANSI issues de données externes mais certainement pour des
strings à passer à l'OS
Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE
Si je comprends bien, dans ce cas la première chose à faire est de faire
une
version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE
?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec
maintient de la compatibilité des sources
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas proposées (toute la philosophie de l'API Windows CE est là : ne pas proposer 36 façons de faire la même chose) contrairement à XP. Dans les .H, on a les deux versions car les .H sont les plus semblables possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE). Au passage, je pense qu'il faut essayer d'utiliser systématiquement les types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la place de strcpy, etc...) lorsqu'on développe une application Win32, car cela facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" wrote in message news:41a5c220$0$17796$
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 & winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ? * Je constate que le wizard de evc4 génère toujours des projets avec /D UNICODE * Tous les makefile des samples des SDK sont aussi /D UNICODE * le makefile des sources des MFC contient également /D UNICODE. de plus il n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode comme avec windows) * l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI ex: LoadString devient soit LoadStringW ou LoadStringA. LoadStringA est effectivement défini (cf. winbase.h) Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les utiliser (aucune n'est implémentée) ? est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et dans les .lib c'est simplement dans l'intention de fournir des tools si l'appli manipule des strings ANSI issues de données externes mais certainement pour des strings à passer à l'OS Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE Si je comprends bien, dans ce cas la première chose à faire est de faire une version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE ?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec maintient de la compatibilité des sources
merci
machin
merci pour les infos bonne journée
"Alain Zanchetta [MS]" wrote in message news:
Bonjour,
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas proposées (toute la philosophie de l'API Windows CE est là : ne pas proposer
36 façons de faire la même chose) contrairement à XP. Dans les .H, on a les deux versions car les .H sont les plus semblables possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE). Au passage, je pense qu'il faut essayer d'utiliser systématiquement les types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la place de strcpy, etc...) lorsqu'on développe une application Win32, car cela
facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" wrote in message news:41a5c220$0$17796$
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 & winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ? * Je constate que le wizard de evc4 génère toujours des projets avec /D UNICODE * Tous les makefile des samples des SDK sont aussi /D UNICODE * le makefile des sources des MFC contient également /D UNICODE. de plus il n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode
comme avec windows) * l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI
ex: LoadString devient soit LoadStringW ou LoadStringA. LoadStringA est effectivement défini (cf. winbase.h) Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les utiliser (aucune n'est implémentée) ? est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et
dans les .lib c'est simplement dans l'intention de fournir des tools si l'appli manipule
des strings ANSI issues de données externes mais certainement pour des strings à passer à l'OS Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE Si je comprends bien, dans ce cas la première chose à faire est de faire une version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE
?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec maintient de la compatibilité des sources
merci
merci pour les infos
bonne journée
"Alain Zanchetta [MS]" <alainza@online.microsoft.com> wrote in message
news:uYs1Dv30EHA.2824@TK2MSFTNGP09.phx.gbl...
Bonjour,
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme
la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas
proposées (toute la philosophie de l'API Windows CE est là : ne pas
proposer
36 façons de faire la même chose) contrairement à XP.
Dans les .H, on a les deux versions car les .H sont les plus semblables
possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de
portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE).
Au passage, je pense qu'il faut essayer d'utiliser systématiquement les
types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la
place de strcpy, etc...) lorsqu'on développe une application Win32, car
cela
facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" <machin@truc.com> wrote in message
news:41a5c220$0$17796$626a14ce@news.free.fr...
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 &
winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ?
* Je constate que le wizard de evc4 génère toujours des projets avec /D
UNICODE
* Tous les makefile des samples des SDK sont aussi /D UNICODE
* le makefile des sources des MFC contient également /D UNICODE. de plus
il
n'existe que 2 versions des lib MFC: debug & release (pas de
ansi/unicode
comme avec windows)
* l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions
ANSI
ex: LoadString devient soit LoadStringW ou LoadStringA.
LoadStringA est effectivement défini (cf. winbase.h)
Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour
compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les
utiliser (aucune n'est implémentée) ?
est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h
et
dans les .lib
c'est simplement dans l'intention de fournir des tools si l'appli
manipule
des strings ANSI issues de données externes mais certainement pour des
strings à passer à l'OS
Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE
Si je comprends bien, dans ce cas la première chose à faire est de faire
une
version UNICODE de l'appli Win32 d'origine et de porter sur Win CE
ENSUITE
?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec
maintient de la compatibilité des sources
Windows CE (comme XP d'ailleurs) fonctionne en interne avec Unicode. Comme la mémoire est limitée, les versions ANSI des APIs Win32 ne sont pas proposées (toute la philosophie de l'API Windows CE est là : ne pas proposer
36 façons de faire la même chose) contrairement à XP. Dans les .H, on a les deux versions car les .H sont les plus semblables possibles (voire identiques) entre WCE et les autres Windows.
Au niveau de la méthodologie, je suis assez d'accord cette la démarche de portage en deux temps (Win32 Ansi => Win32 Unicode => Windows CE). Au passage, je pense qu'il faut essayer d'utiliser systématiquement les types et fonctions "versatiles" (= TCHAR à la place de char, _tcscpy à la place de strcpy, etc...) lorsqu'on développe une application Win32, car cela
facilite le passage en Unicode (qui devrait alors être presque immédiat).
Bonne journée
Alain
"machin" wrote in message news:41a5c220$0$17796$
Débutant un projet win CE, j'essaie de me familiariser/comprendre evc4 & winCE, d'où quelques interrogations basiques
#define UNICODE obligatoire ? * Je constate que le wizard de evc4 génère toujours des projets avec /D UNICODE * Tous les makefile des samples des SDK sont aussi /D UNICODE * le makefile des sources des MFC contient également /D UNICODE. de plus il n'existe que 2 versions des lib MFC: debug & release (pas de ansi/unicode
comme avec windows) * l'API win32 de win CE n'est que UNICODE
Pourtant, en regardant de plus près les .h, on trouve des définitions ANSI
ex: LoadString devient soit LoadStringW ou LoadStringA. LoadStringA est effectivement défini (cf. winbase.h) Par contre, au link, on ne trouve pas cette fonction
=> les définitions ANSI sont présentes ds les .h simplement pour compatibiliter avec win32 std ? et il ne faut surtout pas essayer de les utiliser (aucune n'est implémentée) ? est ce bien cela ?
* le RTC supporte les fonctions str* : elles sont présentes dans les .h et
dans les .lib c'est simplement dans l'intention de fournir des tools si l'appli manipule
des strings ANSI issues de données externes mais certainement pour des strings à passer à l'OS Est ce bien cela ?
* Portage d'une appli Win32 ANSI => Win CE Si je comprends bien, dans ce cas la première chose à faire est de faire une version UNICODE de l'appli Win32 d'origine et de porter sur Win CE ENSUITE
?
Auriez vous des url sur une méthode de portage d'appli sur win CE avec maintient de la compatibilité des sources
