https://bugs.winehq.org/show_bug.cgi?id=55942
--- Comment #7 from Bernhard Übelacker bernhardu@mailbox.org --- (In reply to Eric Pouech from comment #5)
this doesn't look fully correct At least, it shows that the app expects the DOS ioproc to be used; but I'm not sure that this the place to set it. For example, MMIO_Open() sets pIOProc before calling MMIO_SetBuffer() so doesn't look right to always overwrite it in MMIO_SetBuffer. Can you tell if the MMIO_SetBuffer call is made from MMIO_Open or mmioSetBuffer? And if from MMIO_Open() what is the content of refmmio (esp. fccIOProc and pIOProc fields).
I added logging just above my modification: 0020:0024:trace:mmio:MMIO_SetBuffer wm->info.pIOProc was 00000000, setting to pIOProcListAnchor[0].pIOProc 004E69C7 (with mmioDosIOProc 77A5EB80, mmioMemIOProc 77A5EDD0)
I think the application expects to get the ioproc returned it did set with MMIO_InstallIOProc before calling MMIO_Open. And MMIO_Open gets called with refmminfo==NULL.
If I understand it right, MMIO_InstallIOProc places the new proc at index 0 in pIOProcListAnchor?
And when running with winedbg, a breakpoint on MMIO_SetBuffer is just hit once (before the "nebula assertion"): Wine-gdb> bt #0 MMIO_SetBuffer () at mmio.c:595 #1 MMIO_Open () at mmio.c:698 #2 mmioOpenA@12 () at mmio.c:765 #3 0x004e6cc9 in Moorhuhn-Im-Anflug.exe