On Wednesday, June 5, 2019, 10:44:25 AM GMT+3, Alexandre Julliard julliard@winehq.org wrote:
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_secon...
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 ?