The main question:
An executable compiled within the VM will not run on the controller (Pentium architecture) for which it is intended. The same code compiled on a native x86 Windows XP laptop runs fine. An MD5 comparison shows that the two executables created from the same code are in some way different.
Is x86 emulation on an x64 processor just doing something different with the instruction sets that will never yield the exact same results? Anyone have any ideas what I can try to make this work? Any suggestions are appreciated - these are deeper waters than I'm familiar with.
The backstory:
I have inherited some programs written in PL/M-86. Originally this was intended for use with the Intel 8086 architecture, but currently is known to compile and run fine with at least up to a Core Duo processor. I assume that this means that anything x86 would still be usable. Currently I have one laptop with a Core Duo running Windows XP on which this code is written and compiled. Given that this machine is going on about 15 years old, there are concerns of always having a native environment in which to support this software.
I have two different VMs that I have tried; one is Windows XP SP3, the other is MS-DOS 6.22. Within each I can write/edit the code using AEdit from the command line. I can successfully run the utilities which compile the code to an executable. There is no error returned by any of the utilities along the way.
Problems with Code Compiled Inside VMs
-
ghr
- Volunteer
- Posts: 383
- Joined: 25. May 2007, 22:46
- Primary OS: MS Windows 7
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: DOS, Win3x, Win95, WinXP, Ubuntu, OS/2
Re: Problems with Code Compiled Inside VMs
Apparently you need a VM for compilation only, using a DOS era compiler: 16 bit compiler to generate 16 bit executable ?
I had similar issues with old DOS-era ompilers and from there some suggestions, all based on DOS 6.22 VM.
[1] inside VirtualBox: typically I use DOSIDLE and you could try to reduce the execution cap.
[2] outside VirtualBox: sometimes I get nice results using PCEM, e.g. DX 486/33MHz and rather standard BIOS. If that helps you you could "upgrade" (in PCEM) to eg.a more modern CPU etc. Best case you learn something that you can use to return to VirtualBox...
I had similar issues with old DOS-era ompilers and from there some suggestions, all based on DOS 6.22 VM.
[1] inside VirtualBox: typically I use DOSIDLE and you could try to reduce the execution cap.
[2] outside VirtualBox: sometimes I get nice results using PCEM, e.g. DX 486/33MHz and rather standard BIOS. If that helps you you could "upgrade" (in PCEM) to eg.a more modern CPU etc. Best case you learn something that you can use to return to VirtualBox...
Re: Problems with Code Compiled Inside VMs
Thanks for the suggestions, ghr. I have downloaded both and will try them when I can find some time to sit down and get them configured.
In other related news, yesterday I tried again in both VirtualBox environments with the "Hardware Virtualization: Enable VT-x/AMD-v" option disabled and I had some possible success. The compiler makes two executables, one with a symbol table and one without - we only use the one without for reasons that I don't fully understand. Anyhow, the one without the symbol table compiled and matched an MD5 hash to the original version of the same executable which means that there is a chance that it should run properly. The other (discarded) executable still came back different from its original, but that would be somewhat irrelevant if the other one works and I have what I need. I'm going to set up a test chassis locally and try loading it and then try making it go live next time I'm back on-site.
In other related news, yesterday I tried again in both VirtualBox environments with the "Hardware Virtualization: Enable VT-x/AMD-v" option disabled and I had some possible success. The compiler makes two executables, one with a symbol table and one without - we only use the one without for reasons that I don't fully understand. Anyhow, the one without the symbol table compiled and matched an MD5 hash to the original version of the same executable which means that there is a chance that it should run properly. The other (discarded) executable still came back different from its original, but that would be somewhat irrelevant if the other one works and I have what I need. I'm going to set up a test chassis locally and try loading it and then try making it go live next time I'm back on-site.