Newsgroup: it.comp.programmare.win32
Titolo: Gestione Ansi/Unicode

Questa e' una domanda un po' particolare. Io fino ad adesso ho sempre
sviluppato su Win32 "fregandomene" abbastanza dell'Unicode, cioe' usando
semplicemente CHAR, LPSTR, ecc... e basta.
Ora, se volessi sviluppare una applicazione (.exe) sia per Ansi che Unicode,
so benissimo che basta usare TCHAR, LPTSTR, ecc... e ricompilare con o senza
#define UNICODE per ottenere una applicazione Unicode o Ansi.
Ma per le librerie (.lib) e le DLL ??? Come ci si deve comportare in questo
caso ? Mi riferisco a come gestire le funzioni esportate nel formato
FunzioneA/FunzioneW.
Grazie, e se non sono stato molto chiaro, ditelo !

 FunzioneA/FunzioneW.
Dunque. Le librerie di SO (le API) sono tutte in doppio formato A e W. Poi a
seconda che sia o non sia definito Unicode c'è qualcosa del tipo
#ifndef UNICODE
#define CreateWindow CreateWindowA
#else
#define CreateWindow CreateWindowW
#endif
(quindi il CreateWindow senza niente è o la versione Ansi o la versione
Unicode. Le due versioni Ansi e Unicode sono comunque disponibili)
Per le librerie tue, hai due possibilità:
- costruisci due librerie: una Ansi e una Unicode (i sorgenti sono gli
stessi, ma quando compili definisci o non definisci la costante UNICODE).
Nei files .h della libreria usi TCHAR, LPTSTR ecc.
- fai come hanno fatto per il Window, due funzioni per ogni funzione che
tratta "stringhe". Una che termina in A e una che termina in W. Gli header
conterranno i prototipi di entrambi (una che usa LPSTR e una che usa
LPWSTR). Poi fai un bel blocco #ifdef e ci schiaffi dentro tanti #define,
creando degli alias per tutte le funzioni.
Inoltre COM (e quindi ActiveX) usano sempre WSTR.
Se usi librerie di terze parti normalmente sono solo Ansi, quindi ti
conviene creare delle funzioni "filtro" che trasformano da LPTSTR a LPSTR
(quindi a seconda dei casi o non fa niente o converte da Unicode a Ansi e
ritorno).
--- bye

 creando degli alias per tutte le funzioni.
Per le librerie (.lib) indubbiamente penso sia meglio crearne due, una Ansi
e l'altra Unicode.
Il mio dubbio sono le DLL. Nelle DLL di sistema ci sono sia funzioni "A" che
"W" (quelle che usano stringhe ovviamente). Ma il fatto e' che su sistemi NT
(NT/2K/XP) i "veri" entri point sono quelli "W" e quelli "A" sono niente
altro che dei wrapper che convertono da Ansi a Unicode mentre il discorso e'
diverso per i Win 9x/ME, perche' ci sono solo gli entri point "A" e quelli
"W", pur essendoci, mi sembra che siano "vuoti" o comunque non gestiti.
E poi se nella mia libreria DLL ci sono funzioni esportare che non usano
stringhe ? Dovrei spostare quelle funzioni in un sorgente a parte e
compilarlo 1 volta sola.

 compilarlo 1 volta sola.
Continui ad avere due possibilità: o fai due dll (una che finisce per A e
una che finisce per W) o crei una dll con doppie versioni di tutto. Il fatto
che le versioni W non siano usabili sotto W9X (perchè manca il sottostrato)
non è un problema tuo. Il fatto che sotto NT le versioni A rimappino le
versioni W non è un problema tuo (tu NON VUOI avere una dll per W9X e una
per NT, fidati!)
Per quanto riguarda la domanda 2 (funzioni senza stringhe), dipende da come
le costruisci. Cmq per sicurezza ti conviene compilarle due volte e vivere
felice. (le dll di solito le compili raramente... metterci un paio di minuti
in più ma avere dei sorgenti "monolitici" è molto meglio).
--- bye

 "vuoti" o comunque non gestiti. 
Primo: Windows 9x ha un minimo supporto Unicode in alcune librerie (OLE 
e shell), per compatibilità con la famiglia NT. Secondo: le librerie di 
sistema non lo supportano, ma si può abusare del supporto esistente per 
una minima emulazione. Cerca "Microsoft Layer for Unicode" per qualcosa 
già pronto da usare
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.2.1. C, C++ and ASM developers
                               and beta testers are welcome!