[Mono-list] Re: unicode wrapper
Serge
serge@wildwestsoftware.com
Sun, 7 Apr 2002 16:22:08 +0300
> MS recommends
> that /NOD:kernel32.lib /NOD:user32.lib etc be placed
This is not really needed. Link just resolves symbol to the first library it
sees, that has it exported. So unicows just has to be the first in the list.
The recommendation is seems for IDE setup.
I don't know if nostdlib will help, after all you still have to add
kerner/user/etc., manually in this case, because not all required symbols
are overriden by unicows.
So it seems not different from placing -lunicows into the linker specs file.
> Are you linking unimono.dll with MS link?
Yes. In fact I guess mono itself can be linked directly to MSLU using MS
link.
> I suspect that it's a makefile ld link command
> line ordering problem
I tried to place it in the specs file either, before any other lib. Nothing
happened, symbols still resolved against kernel lib.
> I read about this, the library code loads the unicode layer for
> Win9x and ME systems, and calls the original unicode function
> for NT/2k/XP systems.
That's correct, that's why it's better to use it directly thus eliminating
any potential slow-downs on NT systems.
Otherwise, I'd say it would be better to provide two builds - Windows build
(with wrapper) and NT native build (no need in unicows).
Also one thing that has to do with Unicode.
P/Invoke resolves symbols depending on the underlying symbols.
If you have two functions in your DLL - FunA and FunW
and
[DllImport("mydll.dll")]
unsafe public static extern void Fun();
Fun will be resolved to FunA on 9x and to FunW on NT.
In some sense this is similar to what unicows does.
This is described in the docs, there is also something about how
stdcall-mangled names are resolved.
Perhaps internalcall is also supposed to have similar mechanism?
> I'll look into this
That would be great.
Actually, I'm not very familiar with ld so as I said maybe I'm missing
something.
Sergey