Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,604 of 4,675    |
|    Rick C. Hodgin to sdn4...@nospicedham.gmail.com    |
|    Re: EXE program stack setup questions    |
|    17 Oct 18 11:18:59    |
      From: rick.c.hodgin@gmail.com              On Wednesday, October 17, 2018 at 1:57:25 PM UTC-4, sdn4...@nosp       cedham.gmail.com wrote:       > My understanding of how a COM program really works (in real life)       > is that DOS reserves ALL 640K memory and all segments are supposed       > to point to the code segment (64K or less). When you reallocate it       > is up to you to define the SS. If you are mixing your COM program with       > other code not in ASM then as Emilly Latella would say (never mind),       > might as well use an EXE. I routinely use all available ram with tiny COM       > programs and have never had a problem, but for COM programs NASM       > doesn't assume anything, you must tell it.              My recollection is that TINY model .EXE, and all .COM files,       received the full memory initially allocated to them once they       start. You had to explicitly do a resize, and then re-allocate       memory as needed to obtain known blocks of memory that weren't       akin to guesswork as to where you're writing to, what you're       over-writing, etc.              Except for very niche apps, I can't see a reason to explicitly       use a .COM model any longer. Memory's cheap, and you can do       in most C-like languages 95% of what you can do in assembly,       and do so more generically, portably, and more clearly. For       those 5% cases where you truly do need x86 assembly, it's nice       to have those abilities ... but I would advise anyone seeking       to do lots of assembly work today to reconsider the goals of       the app. Years roll by, and other platforms become popular.       The Nn% savings in performance you have by going to assembly       are lost by not having the ability to translate to the other       architectures.              But when it's needed, it's definitely to be used. I have had       to use even 64-bit AMD64 assembly for writing a custom dispatch       algorithm to call DLLs loaded at runtime that are unknown at       compile-time, but are given through a type of parsing at run-       time. The AMD64 dispatch model calling convention uses an un-       usual format for how its parameters are passed, and to setup       the stack in that way required some custom assembly.              --       Rick C. Hodgin              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca