unicode linkages
News
in the microsoft API specs it says that to use UNICODE you need to link
unicoWS.lib before everything else.
so i'm compiling using:
lcclnk.-o c:\tristan\programming\lcc\projects\smartmsn\lcc\smartmsn.exe
smartmsn.obj smartmsn.res -nodef kernel32.lib -nodef advapi32.lib -nodef
user32.lib -nodef gdi32.lib -nodef comctl32.lib -nodef comdlg32.lib
unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comctl32.lib
comdlg32.lib tcconio.lib wsock32.lib shell32.lib
:) if you could follow that, i assume it's telling the linker not to include
the default libraries, then including unicows.lib, then including everything
else.
the problem is, i get:
"Program has no starting address!" as a result.
i've tried everything i can think of, and i'd appreciate any help i can get.
It was only by luck i discovered the -nodef command, which i assumed was the
"/nod:" that other documents were talking about.
anyway,
thanks in advance for any help :-)
see you later,
Tristan
jacob navia
"News" <burte...@xtra.co.nz> wrote in message
news:5j3a9.1848$Fc4.3...@news.xtra.co.nz...
> hello everyone,
> in the microsoft API specs it says that to use UNICODE you need to link
> unicoWS.lib before everything else.
>
> so i'm compiling using:
> lcclnk.-o c:\tristan\programming\lcc\projects\smartmsn\lcc\smartmsn.exe
> smartmsn.obj smartmsn.res -nodef kernel32.lib -nodef advapi32.lib -nodef
> user32.lib -nodef gdi32.lib -nodef comctl32.lib -nodef comdlg32.lib
> unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comctl32.lib
> comdlg32.lib tcconio.lib wsock32.lib shell32.lib
>
Please keep in your mind that lcclnk is not link.exe and that there is NO
_nodef link option.
> :) if you could follow that, i assume it's telling the linker not to
include
> the default libraries, then including unicows.lib, then including
everything
> else.
>
> the problem is, i get:
> "Program has no starting address!" as a result.
>
"unicows.lib" is probably a library not built for lcc-win32. Note that
lcc-win32 does NOT support any microsoft libraries.
To obtain the best results with microsoft libraries use the compiler
provided by microsoft.
> i've tried everything i can think of, and i'd appreciate any help i can
get.
> It was only by luck i discovered the -nodef command, which i assumed was
the
> "/nod:" that other documents were talking about.
>
To use unicode in your application you should
#define UNICODE
and
#define _UNICODE
before your
#include <windows.h>
News
unicows.lib was a microsoft library.
I can get my program to compile in unicode alright, i.e. MessageBox can
contain foreign languages. The problem is RegisterClass (and rcEx) don't
work.
I looked up this in google's usenet achives; people were having the same
problem (albeit with different compilers). The solution appeared to be in
the linking step. Microsoft itself mentions how unicows.lib is needed.
Perhaps I should start a new thread, but i was wondering whether anyone had
an example of a unicode window being created with lcc. I'll reply with a
barebones example that works without, but not with, UNICODE defined.
I don't want to sound impertinent :-), but what does -nodef do in lcclnk?
any other made up command returns an error.
Thanks a lot, again,
tristan
"jacob navia" <ja...@jacob.remcomp.fr> wrote in message
news:akalkl$n06$1...@wanadoo.fr...
>
> Please keep in your mind that lcclnk is not link.exe and that there is NO
> _nodef link option.
>
>
> "unicows.lib" is probably a library not built for lcc-win32. Note that
> lcc-win32 does NOT support any microsoft libraries.
> To obtain the best results with microsoft libraries use the compiler
> provided by microsoft.
>
News
i'm sure i'm going to get a reply pointing out a stupid mistake i made, but
i can't see why it shouldn't work.
If i compile this with UNICODE defined, it doesn't work. If i delete the
UNICODE lines, the WndClass is created. (no messagebox).
thanks for your help,
tristan
//example starts here, hopefully not too damaged from the Copy/Paste.
#define UNICODE
#define _UNICODE
#include <windows.h>
LRESULT CALLBACK WndProc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam);
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, INT nCmdShow)
{
WNDCLASS wc;
memset(&wc,0,sizeof(WNDCLASS));
wc.style = CS_HREDRAW|CS_VREDRAW |CS_DBLCLKS ;
wc.lpfnWndProc = (WNDPROC)WndProc;
wc.hInstance = hInstance;
wc.lpszClassName = TEXT("myWndClass");
if (!RegisterClass(&wc))
{MessageBox(0,TEXT("RegisterClass didn't work, but this unicode message
box did!"),TEXT("Register Class"),MB_ICONEXCLAMATION); return 0;}
return 0;
}
LRESULT CALLBACK WndProc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam)
{ return DefWindowProc(hwnd, msg, wParam, lParam);}
Mike Caetano
> i'm sure i'm going to get a reply pointing out a stupid mistake i made,
but
> i can't see why it shouldn't work.
It worked for me. Are you running a unicode capable version of windows?
NT/2K/XP? Although many of the dlls in Win9x export "wide" versions of their
functions - most of them do nothing more than return zero. If I recall
correctly from Petzold's book, MessageBoxW works on 9x. RegisterClassW
doesn't. You might want to call GetLastError and pass that to FormatMessage
to retrieve information regarding why RegisterClass is failing on you. If
FormatMessageW fails, call FormatMessageA.
Another place to define UNICODE is in the wedit project|configuration dialog
on the compiler tab. I created a generic project using the wedit skeleton
code generator letting everything default. Then I defined UNICODE through
this tab. The resulting compile errors pertained to conflicts between char
and short. I added an include for tchar.h, I changed the char buffers to
TCHAR buffers and I wrapped all of the string literals with the _T("") macro
(same as TEXT). It runs just fine. (I'm running W2K)
When compiling unicode based apps with lccwin32 there are a couple of things
to note. In some code that you come across on the www, you might see
_tWinMain or wWinMain - lccwin32 only handles WinMain - the lpCmdline
parameter has to be ANSI.
When compiling unicode based apps that call GetProcAddress with any
compiler, the function names have to be ANSI strings as well - so don't wrap
those with _T or TEXT.
When using TCHAR buffers with some API functions that require the size of
the buffer - read the documentation to make certain whether the buffer size
parameter want bytes or characters. A unicode buffer takes twice as many
bytes as an ansi buffer to hold the same string, so the length of the string
does not always equal the number of bytes used by the string.
Hope that helps,
Mike
News
i'm using windowsMe, and get "This function is not supported on this system"
when i FormatMessage the error.
(I'll find a friend with XP, and post the exe for them to try, anyway.) (or
try it at work on NT.)
The question i've got now is, is there anyway to support
asian-arabic-etc-languages in my program? (apart from using an add-on like
NJstar). If messenger can do it, why can't i? :-)
And is unicows.lib the answer to correct the win9x problem? Or maybe forget
about the lib, and just load the unicows dll. Or is that the wrong track
completely.
Is there anything i can do? (or am i stuck with plain old ANSI?) :-)
you've been a great help,
thanks
tristan
Mike Caetano
> The question i've got now is, is there anyway to support
> asian-arabic-etc-languages in my program? (apart from using an add-on like
> NJstar). If messenger can do it, why can't i? :-)
Well, Messenger is written by Microsoft for starters! <g> Perhaps Messenger
9x contains what code it needs for handling unicode text? Perhaps there is a
way to co-opt that part of Messenger? Maybe there's a COM interface
available to take advantage of?
> And is unicows.lib the answer to correct the win9x problem? Or maybe
forget
> about the lib, and just load the unicows dll. Or is that the wrong track
> completely.
That actually might be the right track. If you have the dll you can make a
lib file that is compatible with lccwin32 using pedump and buildlib. In
wedit there is also a utility for importing microsoft lib files.
> Is there anything i can do? (or am i stuck with plain old ANSI?) :-)
I'm not familiar with the unicows.dll - but a quick google search suggests
that it should help you achieve your goal. This url appeared to contain
useful information:
http://www.microsoft.com/msj/0499/multilangUnicode/multilangunicode.htm -
although it doesn't mention unicows.dll at all - it does contain information
regarding internationalizing an application. Perhaps there is a follow up
article that relates more specifically to unicows.dll? You'll have to search
MSDN/MSDN magazine for that. Googling on "unicdows.dll" turned up a
manageable number of returns, although you might need to use altavista's
babelfish translator to make sense of some of them - Japanese, Russian and
French.
There's also IME (Input Method Editor) which deals with input using Asian
glyph sets. You can read more about that here:
http://plaza27.mbn.or.jp/~satomii/design/imm/ - there are other interesting
things at that site worth checking out as well. I haven't used IME and can't
speak to how well it will work with lccwin32. If you pursue it, you might be
breaking new ground.
-Mike
News
thanks mike, i did what you said,
and i think i've cracked it!
at least with the barebones app!
i used: pedump /exp unicows.lib > unicows.exp
then i editted the exp and corrected the first line name of the DLL.
then ran: buildlib unicows.exp unicows.lib
and that produced a lib file that works perfectly. (it killed two birds by
overwriting the microsoft one). I forgot all about -nodef, and put unicows
in the libraries list, and it worked perfectly. (now i just have to go
through changing chars to TCHARS, etc. etc. :-) )
but now RegisterClass works, and i can create a window using it. I have yet
to write any japanese text or anything to the window, but it's definitely
unicode!
so thanks again to everyone who's helped me :-)
and good luck with whatever you're doing,
tristan
"Mike Caetano" <pri...@juno.com> wrote in message
news:akcaep$1h8gcm$1...@ID-115446.news.dfncis.de...
> "News" <burte...@xtra.co.nz> wrote in message
> news:p7ga9.1957$Fc4.3...@news.xtra.co.nz...
>