<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Aug 2015 at 00:44 Stefan Dösinger <<a href="mailto:stefandoesinger@gmail.com">stefandoesinger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi,<br>
<br>
You dropped the wine-devel CC. Was that intentional? There are people<br>
who have more clues about winelib than I do.<br></blockquote><div>No, it was accidental, sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>> I found that OutputDebugStringA doesn't write anything here,<br>
>> even if successful. I replaced it with printf calls to get<br>
>> actual output.<br>
><br>
> OK, but why exactly is this necessary? This is just an artificial<br>
> example to demonstrate the general problem.<br>
I looked into the source code of OutputDebugStringA, but I couldn't find<br>
an obvious answer. It certainly does a lot more than just write a string<br>
to STDOUT. I didn't really understand what it was doing.<br></blockquote><div> </div><div>Yes, it sends the message to the attached debugger if any, not to stdout. On Windows or Wine you can run SysInternals DbgView.exe to see it. It's just an example though, and many other APIs also crash when called from initialisers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> Though it's not quite working here either:<br>
><br>
> Any ideas why, or how it could be fixed?<br>
Sorry, no idea :-( .<br>
<br>
> Yes. My hope was that Winelib could be used to help port a legacy<br>
> Windows CE 4.x application to Linux (ARM, though I am testing on<br>
> x86 right now). Initially I could try compiling on Windows and<br>
> running it on Linux, but the real goal would be to port the<br>
> application in stages, so changing a few modules at a time to use<br>
> Linux APIs while leaving some parts using the Win32 (and MFC) APIs.<br>
> Eventually there would be no need for Winelib but I'd expect that<br>
> porting all of the code at once would resulting in a lot more<br>
> debugging effort because changes would not be localised.<br>
Hmm yeah, that sounds like a task where you need winelib. Unfortunately<br>
winelib isn't something that gets used a lot, and even less so with C++.<br>
<br>
Also keep in mind that Wine doesn't target Windows CE applications, so<br>
you'll have to invest a lot of time into bridging Windows CE <-> Win32<br>
differences.<br></blockquote><div> </div><div>Yes I understand, but fortunately most of the application also runs on normal Win32.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You'll also have to compile MFC with Winelib to target ARM. It should<br>
be possible to compile MFC (or at least parts of it) with winelib, but<br>
I don't expect this to be easy either.<br></blockquote><div> </div><div>That's true, and that was actually the first thing I tried to do. I tried both static and dynamic libraries but it crashes before it gets to WinMain(), hence my question. GDB can trap the crash but the stack trace gives no function names or other useful information.</div><div><br></div><div><div>(gdb) bt<br></div><div>#0  0x00000000 in ?? ()</div><div>#1  0x7ec4b7c0 in ?? ()</div><div>#2  0x7ec4b77e in ?? ()</div><div>#3  0x7ec4b79e in ?? ()</div><div>#4  0xb7febd77 in ?? ()</div><div>Backtrace stopped: previous frame inner to this frame (corrupt stack?)</div></div><div><br></div><div>Winedbg cannot even get that far. But I will try 1.7...</div><div> </div><div>Luke</div><div><br></div></div></div>