Author Topic: I think there may be a bug in the claim of using ORG 0x100 for COM files  (Read 1849 times)

Offline ben321

  • Full Member
  • **
  • Posts: 107
The reason I say this, is because when I execute a COM file, rather than being loaded into the memory location 0000h:0100h (flat memory location 00100h) it instead loads into memory location 0F63h:0100h (flat memory location 0F730h). And I'm not making this up. I tested it in the debugger version of DosBox, which allows me to easily debug 16bit applications. I expected the first byte of code of my COM file program to loaded into memory at 0000h:0100h but instead it was at 0F63h:0100h.
« Last Edit: June 14, 2016, 10:03:09 PM by ben321 »

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2429
  • Country: us
Hi Ben321,
Your expectation of what DOS does appears to be incorrect. It does not load at segment 0 (would trash your IVT if it did) but at a segment of its choice (lowest free segment available, usually). Sorry for the delay - I imagine you've figured that out by now.


Offline debs3759

  • Global Moderator
  • Jr. Member
  • *****
  • Posts: 79
  • Country: gb
    • GPUZoo
To expand on what Frank said (and to introduce myself here)

DOS decides where to load your file in memory. In your case it was loaded into segment 0F30h. At offset 0 is a program header that takes up 256 bytes, which is why you start your code at org 100h, which is the offset of your code in the segment DOS loaded it into.
My graphics card database: