Hi,

On Wednesday 13 December 2000  9:04 pm, Francois Gouget wrote:
>    If I understand correctly you would put these statements in the
> application's spec file. Right?
>    Ah, I think I understand:
>    - you put these in the application's spec file
>    - you import ntdll & crtdll to get various functions (maybe
> splitpath, beginthread, whatever)
>    - and then you link, in the Unix sense, with the C library and get
> the symbols listed in the ignore statements from there

Spot on. In my case I'm not currently importing crtdll (yet), but I will be 
in the near future. Its important to allow the Winelib user to choose native 
libc IMHO, if the Win behaviour isn't needed...

>    Do we really need this directive to do that? As I understand it if
> you have a function called wcslen in a '.o', its symbol will be resolved
> when you create the '.tmp.o' and so winebuild will not try to import it
> form a dll.

We dont need it for that, hence 'side effect' ;-) Just thought I'd note it. 
Also if your app uses some shared libraries to implement those functions, 
they get resolved to the DLL. So you have to link your libraries statically 
to get the behaviour you descibe above, currently.

>    Why? Is it because you use 'char_t*' instead of 'WCHAR*'?

Yes. In this case VWCL defines it.

>    You mean with VWCL? With Winelib it's already possible. You just have
> three issues to take care of:
>  - the initialization of your strings: 'WCHAR* str=__TEXT("some text");'
> does not work right currently
>  - you must not use wchar_t because it's of the wrong size
>  - you must not use the libC Unicode functions because they expect a
> wchar_t when you would give them a WCHAR. Instead you currently have to
> use the crdtll functions.

Those are some pretty serious limitations. We have to support using libc and 
a win32 crt, so we need to be able to use both. For what Im doing it makes 
more sense to use libc and wchar_t, then convert to WCHAR, since the crt 
functions are called much more than win32 unicode functions (many classes 
aren't gui-based). Once this works Ill be looking at using the ms crt to 
implement the same behaviour.

>    That's interesting. It's specific to C++, right? 
Unfortunately, although a final solution may not have to be. In this case all 
strings in VWCL are a class which makes conversions easier.

>Will it convert any
> wchar_t to a WCHAR or is it specific to a class, like converting a
> CString to a WCHAR?
>    I'm working on a related issue which is trying to get 16bit Unicode
> strings from L##"some text", or more precisely from the __TEXT() macro.

this is class based, though L, __TEXT etc could be defined to a c-func to 
return a converted string (the conversion is trivial, and should be able to 
be done in place).

I probably wont get to trying msvcrt with unicode for a while, so if you have 
any success could you let me know?

Cheers,
Jon

-- 
"May their negative actions ripen upon me. And may all my virtues ripen upon 
them."
"If it could be talked about, everybody would have told their brother."
[EMAIL PROTECTED] , [EMAIL PROTECTED]


Reply via email to