Uwe Bonnes writes:
Paul> fixme:ole:DispCallFunc Do not know how to handle pvargResult ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For the first error, either try with a combo of the native OLE dlls (ole2,ole32,oleaut32, rpcrt4 and maybe more) or hope that some of the OLE gurus( Hey Marcus :-) picks up the problem.
Ok, that error disappeared. Will have to add back builtin to each dll individually to determine which one is at fault... I don't think that was the cause of my problem anyway (see below).
Paul> kernel32.dll.BeginUpdateResourceA fixme:process:CreateProcessA ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For the unimplemented function, perhaps try to add a stub implementation. Look in the archives how others did it ( find out the arguments, add the entry in the spec file, add a stub implementation in a .c file and send the patch).
Ok, I did this. Now I'm not a C programmer but it was pretty easy to figure out what to do. I changed the @stub in the spec file to @stdcall, and added the argument types. I noticed that UpdateResourceA and UpdateResourceW are implemented as stubs in /win32/kernel32.c, so I put in the BeginUpdateResourceA, W and EndUpdateResourceA, W there as well.
With these changes, the Build EXE process doesn't crash for me anymore. I end up with an EXE that runs fine, but doesn't contain icon and version resources. At least I can do my test builds on Linux and then when I'm ready to deploy I can build on Windows.
So, I'll follow the instructions on submitting the patch later today.
Thanks Uwe!