COFF MINGW

Which do you want first, the good news or the bad news? Never mind, they’re identical. I managed to cross compile platform/msw/stub.c which ashbb and now I,named as shoes-stub.exe. Wine actually runs it and it displays a dialog that it is a shoes-stub with nothing in the payload. Exactly what static/stubs/blank.exe displays. Exactly what they should show if Winject hasn’t been used on them. The build instructions for blank.exe have been lost in time and I couldn’t get my mind and the existing rakefiles to co-operate on building shoes-setup.exe with MinGW so of course I did a little cowboy coding – just add the compile and link commands I want to a rakefiles task. No need for over engineering with fancy tasks and subtasks and blocks. No one going to run this task unless they’re trying to do what I’m doing, in which case there setup is going to very similar to mine.

I strongly suspected that blank.exe was compile by a MSFT compiler and thats why Ashbb went his special way with MinGW. It turns out stub.c is a C++ program. I consider C++ to be the spawn of good intentions from which evil arrives charring wonky MSFT C enhancements. Your opinion may differ. So I compiled it with C which winhttp.h wasn’t expecting and and and. It’s only got a couple of ‘probably harmless’ error messages and it does run. There nay be future trouble or work required to really get it correct.

I got rid of all the compiler warnings in winject. That’s nice even though they were all harmless.

What won’t work is Winject and a MinGW compiled stub. I suspected that was the reason ashbb went his direction. Confirmed. With my ‘new’ shoes-setup.ext, I get a segfault when winject tries to save it’s work. With gdb if needed. _why left comments in his ‘C’ code and some of them in winject provide a clue what he thought might be a limitation. I suspect I have found it too. _Why also left commented out printf’s so that’s good.

This could turn out to be a dead end – more work that I want to do or the details to troublesome to find. We need to remember this effort is only because I don’t like the current Shoes 3.2 packaging. It would still work again (as Shoes 3.2.15 does), since I haven’t deleted binject.

[update]
blank.exe has four (4) sections and shoes-stubs.exe has 8 sections. There are differences of course but nothing that is unreasonable. There are some Characteristics flags that might matter and they import dlls / symbols differently. Maybe. The icon section seems a bit confused. Winject (and binject) really only plays around with about the .rsrc section. winject.inject just adds an ruby array entry in to the adds field of the winject_exe_t struct (the field is a ruby array – _why did love to mix his C with rb_calls for expandable array and hash purposes). Sorting it out after all the injects from packaging calls is left to winject.exe.save.

I know that shoes-stub.exe is reasonable (from a Wine/Window POV). It’s only when winject gets involved that Windows does’nt like the exe. So, I need to package up just a script (not a downloaded shoes) with each of them and compare the .rsrc sections.

Leave a Reply

Your email address will not be published. Required fields are marked *