On December 27, 2003 01:11 pm, Subhobroto Sinha wrote:
But as I am using pure C++, I have to use GLibc's library functions which
expects wchar_t to be 4 bytes long and NOT 2 bytes.
Herein lies your problem. Mixing the two is not pretty, and I think
it should be avoided to maintain sanity. Just
No, actually I really don't want to use WineLib (then I can use COM to resolve the
shortcut anyway!)
I just want a method where I can use GLibc's Unicode functions on Win32 serialized
data which treats wchar_t as 2 bytes long..
On Sun, 28 Dec 2003 Dimitrie O. Paun wrote :
On December 27, 2003
The program runs on Windows just fine because Windows Unicode function expects wchar_t
to be 2 bytes (unlike GNU's) which is what it gets..
So the program runs on wine correctly too...
But I want the app to be a native ELF using GLibc's own Internal functions...
I have assumed that the user
What about libs/unicode? I have no idea about that stuff, but isn't a
situation like this what those libs are for?
--
gmt
It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act,
Subhobroto Sinha wrote:
The program runs on Windows just find because Windows Unicode function expects wchar_t to be 2 bytes (ulike GNU's)
So the program runs on wine correctly too...
But I want the app to be a native ELF using GLibc's own Internal functions...
I have assumed that the user may
You did try -fshort-wchar on GCC command-line yes?
It gives you 2 bytes wchar_t but there are these other problems people
where saying. English will probably work. But Hebrew? I'm not sure!
Subhobroto Sinha wrote:
The program runs on Windows just fine because Windows Unicode function expects
Subhobroto Sinha wrote:
If you test the .lnk (DAEMON_TOOLS.LNK), you will see that the program crashes in the function:
unsigned int WineWorksShortcutResolver::UnicodeToANSI(const WCHAR* wszInUnicode,unsigned int uiLen,char* szOutANSI)
at the GLibc function:
wcstombs(..)
I'm way out of touch
Dan Kegel wrote:
I'm way out of touch with Wine these days, but here's
[ meant to say my two bits... obviously my mind is wandering... ]
1. If you want to get something useful done, switch to C. Mixing
g++ and Winelib seems to be a bit tricky, and you might end up
spending all your time on that
2. If you insist on using C++:
if the problem resists analysis, perhaps you could use Valgrind
to help track down the problem. It's pretty easy to build the
wine edition of valgrind, and you don't need any special changes
to wine. You can download valgrind's sources at
