2

As the subject says, I am having a problem with my 16-bit application. Application is very low-level, doing some operations in C++/Assembly language. One thing to emphasize: this is a faculty project, so I am somewhat confident that fellow colleagues (at least some of them) were able to run it under Win7.

Compilation is done via BCC compiler. I know, old as hell :)

Under Win7, it report the following error on exit:

enter image description here

Does anyone has some hints on how to on analyze the issue? I was told that memory management settings. I have the following settings available:

enter image description here

Any tips/hints would be greatly helpful!

Jovan Perovic
  • 19,846
  • 5
  • 44
  • 85
  • correct me if I'm wrong, but isn't Windows XP the last OS supporting 16-bit apps? – user_4685247 Aug 25 '15 at 19:52
  • Did you try running it as an administrator? Also see: http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/how-can-i-run-16-bit-programs-in-windows-7-64-bit/22b921f5-0b71-4ba1-8567-2bb86a1b604e?auth=1 – NathanOliver Aug 25 '15 at 19:52
  • I was hoping that was true. @NathanOliver I saw that article, but my Win7 is 32-bit, so it should, at least theoretically, be able to run 16-bit apps, right? – Jovan Perovic Aug 25 '15 at 20:17
  • Have you tested it on a different computer? – Havenard Aug 25 '15 at 20:23
  • I didn't. Because, the teacher provided the virtual machine image (`Win7 x86`), I assumed that one should work. But, good point, I am going to do that now... – Jovan Perovic Aug 25 '15 at 20:25
  • @tofiffe : You can run 16 bit apps on any of the Windows OSes as long as you install the 32 bit versions of Windows. 64 bit version of Windows will not run 16 bit code directly. On 64 bit windows, you can still run a 32 a version of windows in a virtual machine (Virtual PC, VMWare) etc or an emulator (bochs) and then you run your 16 bit apps in the virtual environment. – Michael Petch Aug 25 '15 at 21:43
  • @rcgldr That sounds like a useful piece of info! I have just disassembled the EXE and looking into it... – Jovan Perovic Aug 25 '15 at 21:49
  • 3
    @rcgldr due to the `CS=0000` that's actually the interrupt vector table and not code, hence the entry pointing to segment `F000:02E6` (BIOS). Find out how `CS` got to be zero. – Jester Aug 25 '15 at 22:15
  • @Jester Part of my code actually alters (and restores) IVT. Hmmm, might be something to do with that... – Jovan Perovic Aug 25 '15 at 22:27
  • I assume 0000:0177 is cs:ip after the failure. If it was 0000:174, that's INT 5D, beyond the normal BIOS / DOS interrupts. DesqView may map INT 13 to INT 5D, or DoubleDos may map INT 5 to INT 5D. Or the actual jump was well before 0000:174 and that just happened to be the first byte sequence that failed. – rcgldr Aug 26 '15 at 00:00
  • I am going to sleep over it - it's getting late over hare (GMT+1). Thanks for the ideas/hints guys. :) I will continue working on this problem tomorrow... – Jovan Perovic Aug 26 '15 at 00:14
  • Finally managed to resolve the issue. Guys, thanks a lot for all the hints. It helped a lot during the course of debugging. – Jovan Perovic Aug 31 '15 at 11:07
  • I was a bit trigger happy... :( The problem still occurs :( – Jovan Perovic Aug 31 '15 at 22:31

0 Answers0