I cannot, neither of them.

For 1., I don't get so far, because it crashes when I start the DOS prompt: Exit to error: DynrecCore: illegal option in dyn_mov_seg_ev

For 2., I don't see a difference, except that it does not crash anymore when I start the DOS prompt, but instead seems to exit Windows immediately (and sometimes eat any further keyboard input, depending on whether I'm in real DOS or DOSBox DOS).

The DOS prompt does work when I run it under a 32 bit build of DOSBox.

Uh, so you're talking about Windows 3.11, not Windows for Workgroups. Is that right? I used WfW.

I'll have to reinstall anyway, as I just removed my image accidentally with an incautious usage of git clean -dfx 😉. 🙁

No, also not with Win 3.11.

1. imgmount works (at least, does not crash)
2. Windows starts and seems to run normally.

Last update: I missed the part about this being about 0.74-2. I used the trunk version previously, but it makes absolutely no difference.

What I don’t get: In the other thread you mentioned that just starting the DOS Prompt caused the dynrec error, same as for me. How come that you are reporting a different experience now?

The dynrec problem seems to be caused by the S3 video driver wanting to switch into text mode. It does not happen with:
- Standard VGA
- S3 driver with windowed DOS Prompt

Driver: S3 Trio64V 1.70.04 1024x768 64K C SF

I can imgmount an iso file without a problem.

Ringding wrote:

I cannot, neither of them.

For 1., I don't get so far, because it crashes when I start the DOS prompt: Exit to error: DynrecCore: illegal option in dyn_mov_seg_ev

Is that fixed with commenting out the pop_ev instruction block ? As that was the bug I am trying to fix.

Number 2 is a different problem I ran into while trying to fix problem 1.

For 2., I don't see a difference, except that it does not crash anymore when I start the DOS prompt, but instead seems to exit Windows immediately (and sometimes eat any further keyboard input, depending on whether I'm in real DOS or DOSBox DOS).

So windows does boot if you set the instructions to 1 (and not apply the push_imm commenting) ?, exit windows happens at my place during startup, so I don't know how
it will behave when starting the command prompt, as I can't reach that.

The videodriver can influence things, but I am trying to get the 64 bit build working identical to the 32 bit one. (they use a different core in dynamic mode)

Qbix wrote:

Is that fixed with commenting out the pop_ev instruction block ? As that was the bug I am trying to fix.

Yes. Then it works. Also imgmount.

So windows does boot if you set the instructions to 1 (and not apply the push_imm commenting) ?, exit windows happens at my place during startup, so I don't know how
it will behave when starting the command prompt, as I can't reach that.

Yes. Setting the translation block size to 1 does not make any difference. Not with and not without the pop_ev commented out.

Ringding wrote:

Yes. Setting the translation block size to 1 does not make any difference. Not with and not without the pop_ev commented out.

Rereading my own report from earlier, I have to correct this. It does make a difference with the pop_ev left alone. Then it exits Windows when I try to run the DOS Prompt.

thanks for trying it.

The 1 instruction thing is hard to reproduce it seems, but some progress was made on that.

The problematic instruction is pop dword [eax+0x87], where [eax+0x87] points into a non-present page. The normal core handles this quite differently from the dynrec core by using mem_writed_inline which spawns a nested run loop via PAGING_PageFault to run the exception handler and then continues where it left of, which is a somewhat gross hack that seems to work somehow 😉. In contrast, the dynrec core uses mem_writed_checked_drc which jumps into DynRunException which sets up the CPU state like the real thing would and then continues its run loop. From here it becomes difficult to follow. In theory the guest handler should bring in the page and then retry the operation. Or should it? And while writing this it occurs to me that the problem is likely this: Execution is resumed at the faulting instruction, which bumps the stack pointer for the second time and makes a complete mess.

Yes Precisely!
Let me pm you something.

The 1 instruction problem, which has been plaguing me a lot, seems to be a problem with overwriting code, which is identical to the original code, except 16 bit instead of 32 bit. The cache detection doesn't detect this as new code and thus runs the wrong operand size.

Qbix: I've been away from home/IRC most of the time lately but I'll try and get on tomorrow...