dbghelp detached from wine into standalone windows dll...

[Tarmo Pikaro]

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, 
and this form:
utf8ztowchar(searchPath, sp, len);

is also shorter than:
MultiByteToWideChar(CP_ACP, 0, searchPath, -1, sp, len);
by 6 - 3 = 3 parameters.

What I'm afraid is usage of active code page (CP_ACP), which might be run-time configured via some locale command.
I have tried to search some documentation on active PE structures, but could not find any - suspect it's relatively ancient structures without decent documentation. Made once upon a time as ascii, and never were designed from unicode perspective.
Btw - windows C++ provides such classes as CA2W(), CW2A() - it can give even shorter form - wondering if dbghelp can be upgraded to C++ ? (pros / cons?)


> I would like to head into direction of having only one compilation instead of multiple -
> https://www.reddit.com/r/cpp/comments/bjgt0j/make_portable_dll_without_second_compilation/
>
> basically replace .so & .dll file format with one centralized file format, which can be run on multiple platforms. (e.g. linux and windows)
>
> Please don't tell me it will be a long way to get there, I know that - but there already exists prototypes
> who managed to make this happen. I think wine's dbghelp is good place to start from, but
> we might indeed require native compilers support, need to locate good guys for this job.

> The file format is not the interesting part, it's easy to do a PE loader
> on Linux, or an ELF loader on Windows. You could probably also write a
> PE<->ELF converter without too much trouble.

> The thing is once you have loaded the binary, it's going to call APIs,
> and these are completely different between platforms. So you need either
> an abstraction layer to wrap all the APIs, or something like Wine to
> make the APIs compatible. That's where the real work is.

Yes, but I would like to start from basics - enable functionality initially, and worry about which dllexports 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 ?


-- 
Alexandre Julliard
julliard at winehq.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190605/a63f7304/attachment-0001.html>