dbghelp detached from wine into standalone windows dll...

[Alexandre Julliard]

Tarmo Pikaro <tapika at yahoo.com> writes:

> On Wednesday, June 5, 2019, 10:44:25 AM GMT+3, Alexandre Julliard <julliard at winehq.org> wrote:
>
> Tarmo Pikaro <tapika at yahoo.com> writes:
>
>>> Other stuff like missing WideCharToMultiByte can be
>>> addressed by providing the missing functions in your own separate object
>>> file, without changing the source.
>>
>> I've scanned quite many unicode libraries and concluded of bringing up cutf library alive - that is basically a replacement for
>> WideCharToMultiByte & windows api - uses less call arguments, but can achieve stuff.
>> 
>> My point is that you can write a simple WideCharToMultiByte wrapper on
>> top of your cutf library, and then you don't need to patch dbghelp at
>> all, only to link it against your wrapper.
>
> I think wrapping can go in either direction, but you must admit that writing:
>
> len = utf8zestimate(searchPath);
>
> is shorter than:
>
> len = MultiByteToWideChar(CP_ACP, 0, searchPath, -1, NULL, 0);
>
> by 6-1 = 5 parameters, 

It's also completely non-standard. In Wine, we use Windows APIs wherever
possible.

> Yes, but I would like to start from basics - enable functionality initially, and worry about which dll
> exports and what later on. I think we could have even our own (application) specific "standard" API.
>
> Btw - I have tried to load from wine / LoadLibrary linux shared object, but could not. Tried something like this:
>
>     void stackCallbacker()
>     {
>         printf("%s", g3::internal::stackdump().c_str());
>     }
>
>     typedef void(*func)(void);
>     typedef void(*fcallFunc)(func);
>
>     int main(int argc, char **argv)
>     {
>         //HMODULE h = LoadLibraryA("dll.dll");
>         const char* dllName = "dll";
>         //const char* dllName = "/mnt/c/Prototyping/dbghelp2_dev2/bin/Release_x86/dll.so";
>         HMODULE h = LoadLibraryA(dllName);
>         if (h == 0)
>         {
>             printf("Failed to load '%s'\n", dllName);
>             return 0;
>         }
>
>         fcallFunc fc;
>         *((FARPROC*)&fc) = GetProcAddress(h, "DoTestCall");
>
>         printf("Calling dll -> DoTestCall ...\n");
>         fc(stackCallbacker);
>         printf("call ok.");
>
> But wine refuses to load dll.so by relative or absolute path. Does wine supports this ?

It works if the .so file was built as a Wine library, with an embedded
PE header. It's not possible to load a plain .so lib, since there's no
way to return a valid HMODULE for it.

-- 
Alexandre Julliard
julliard at winehq.org