🚀 go-pugleaf

In article <1990Dec19.174402.5882@holos0.uucp> lbr@holos0.uucp (Len Reed) writes:
>In article <18633@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes:
>>[some stuff deleted]
>>>        assume  cs:code,ds:code,es:code
>>....
>>>        mov     word ptr [old_int+2],es         ; Save old vector
>>>        mov     word ptr [old_int],bx
>>
>>Here, there is a rather unsafe assumption that ds points to the code segment
>>after DOS has been called. You should better set ds explicitly to code (e.g.
>>by push cs, pop ds) or use an segment prefix for cs.
>>in this place that ds points to code, it is just unsafe.
>
>Nonsense.  What's unsafe about this?  This is obviously a ".com" TSR: COMs
>start with CS=DS=ES=SS.  The assume notes this (although SS is not
>listed), and the DOS calls used preserve the DS register, so the DS
>register does in fact point to the code.
>
>Why use overrides or pushes and pops when the DS: points where you want
>it to?  (And if it doesn't point where you want it to then the assumes
>should tell the assembler this.  This is where the bug lies.)

It looks like my posting is starting a flame war, which the topic is definitely
not worth. Still I want to add a comment.

    Unless you had deleted it up there, you would see that I said that DS points
    to the right segment there. I certainly know this, and I would not add the
    code to set it explicitly to the code segment. However, from the listing
    given, I assumed that the original poster was not experienced in assembly
    language, so I wanted to show him a piece of code that works under all
    circumstances. Although there is no DOS call that changes DS, there are
    some BIOS calls that do. If you do not have good documentation about it
    (and lots of people do just a little bit of assembly programming without
    any documentation but instead copying from other's sources), it is best to
    make the least assumptions that you can and establish everything else that
    you need explicitly. Note that in this case it would not even have costed
    at lot, as this code is just running once.

    I am not (!) trying to make people add inefficiences to their programs. It
    is just that when you are not completely sure that some improved solution
    works, you should do it the safe way.


Marc-Michael Brandis
Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology)
CH-8092 Zurich, Switzerland
email: brandis@inf.ethz.ch