Tarmo Pikaro <tapika@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 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 ?

--
Alexandre Julliard
julliard@winehq.org