dbghelp detached from wine into standalone windows dll...

[Tarmo Pikaro]

 Tarmo Pikaro <tapika at yahoo.com> writes:

> Here is 64-bit enabling commit:
>
> https://github.com/tapika/dbghelp2/commit/3a3e9daacae14c4f73585aeff4ef53a207a9f55d
>
> Basically my intention was to prototype that it's possible to determine call stack using wine dbghelp parts. 
>
> - Does it makes any sense to try to make my dbghelp prototype be more or less official / or create such version which would be suitable for wine and for standalone compilation ?

> For what you want, you should be able to use Wine's dbghelp unmodified.

Hmm... Basically use wine, and run windows executable, but load elf file instead ? Hmm... That sounds like a plan, will try this later on.I have already tried to cross compile wine in linux subsystem for windows.
> Things that are legitimate bug fixes (like getting rid of 'long') can be
> merged upstream. 
Ok, but I still bit suspicion on potential regressions, I don't fully know dbghelp area where it should work and where it should not.
> 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 forWideCharToMultiByte & windows api - uses less call arguments, but can achieve stuff.
I've posted one message to reddit about cutf library in here:https://www.reddit.com/r/cpp/comments/bwdjjq/utf8_wide_character_conversion_with_c_c/
and already prototyped patching dbghelp library, see:https://github.com/tapika/dbghelp2/commit/b516e1ca2f47055c994a3ede9fc8c28dfa29dfb6

One thing which I'm not so sure about - is whether or not you actually use code pages (and which) in dbghelp.dll.
> - I would be interested in further development of dbghelp - as standalone dll / so independently from wine.
>
> At the moment dbghelp serves like read / parse of existing file
> formats (PE & ELF), has anyone considered of expanding support towards
> generation of same file formats ?
> There was an effort a long time ago to generate PDB files from the Unix
> data, but it never got good enough for real use. Doing this at the
> compiler level is probably more realistic.

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 prototypeswho managed to make this happen. I think wine's dbghelp is good place to start from, butwe might indeed require native compilers support, need to locate good guys for this job.
C# .net already compiles only one compilation .net assembly, why same cannot be done with C++ ?
Suspect that need to set up "discussion" bridges to Microsoft compiler, gcc and clang teams.
I had already some experience with Android platform development and know about linker limitations on that platform. Suspect might need to take some development effort to make dll loader, file format, call stack to be fully platform agnostic.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190604/b0d461eb/attachment.html>