Opened 7 years ago
Closed 6 years ago
#17744 closed defect (fixed)
Guru Mediation in DOS while running Flat Assembler (FASM) (fixed in svn)
Reported by: | darryl_seamans | Owned by: | |
---|---|---|---|
Component: | VMM | Version: | VirtualBox 5.2.4 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description
While running FASM in a MS-DOS 6.22 virtual environment, machine execution is halted. This happens whether or not I run CWSDPMI before running FASM, do a clean boot in DOS (F5 to bypass CONFIG.SYS and AUTOEXEC.BAT) or not, or anything else. Version 5.2.4 of VirtualBox hosting MS-DOS 6.22. I'm about to try v5.2.10.
Attachments (1)
Change History (8)
by , 7 years ago
Attachment: | DOS-2018-05-08-18-51-25.log added |
---|
comment:1 by , 7 years ago
I have verified this bug exists in 5.2.10 also. Application (FASM) works fine on a real machine and in DOSBox. It has worked in the past as well, although it was awhile ago that I tried it (2013 perhaps).
comment:2 by , 7 years ago
I copied the .vdi file containing the MS-DOS 6.22 image to two different Windows 7 machines running 5.2.10 as well as 5.2.4 and tried the same software (FASM) there. The problem did not occur in either case. I am convinced there's something up with the original machine's installation or configuration. what it's worth, the fasm.exe program runs in a 32-bit flat mode (it may be the "unreal mode" ?) which throws a curve ball to DOS, of course, so it's not entirely surprising this would happen.
comment:3 by , 7 years ago
Component: | other → VMM |
---|
The "something" is the machine's CPU. Highly likely fasm will work on both older and newer CPUs (or likely on any AMD CPU). The problem is triggered by VT-x without unrestricted execution. You should be able to work around it by disabling hardware virtualization for the VM.
And yes, fasm is... interesting.
comment:4 by , 7 years ago
Summary: | Guru Mediation in DOS while running Flat Assembler (FASM) → Guru Mediation in DOS while running Flat Assembler (FASM) (fixed in svn) |
---|
This has now been fixed in source code, at least to the point where fasm runs and compiles one or two of the examples it comes with. The fix will be part of some future maintenance release.
comment:5 by , 7 years ago
Note that the problem was reproducible with fasm 1.69.34 that you used. The current fasm 1.73.04 is different and requires DPMI always. I'm not entirely sure if it will use unreal mode or not but it does not crash the VM.
I should also add that the problem can only be reproduced when there is no EMM386 or similar memory manager loaded in the VM. If the CPU runs in V86 mode, unreal mode cannot be used.
comment:6 by , 6 years ago
Replying to myself: fasm only uses unreal mode if the code segment fits within 64K. That is no longer the case with current fasm versions, but it was the case with 1.69.34.
The fix should be in the next maintenance release.
comment:7 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Log file from halted session