On (01 Jul 97) Kurt Wismer wrote to Jerry Coffin...
 JC> mov dx, 0ffffh
 JC> arge:
 JC> inc dx
 JC> xor ax, ax
 KW> and the problem was that xor ax, ax... i put it before arge: and as a
 KW> result it wasn't 0 after the first pass through the loop... dos wound
 KW> up being told to check drive number 2 instead of 0 (and there is no
 KW> drive 2)...
Which obviously calls for the "do what I meant, not what I told you"
version of DOS. 
 KW> well, i've done more testing on it (and my version after i fixed the
 KW> original problem) and i found a new glitch, or at least it's a
 KW> behaviour i don't understand... the 4626 byte image file is invalid,
 KW> it should (though i didn't realize this before) be 16962 bytes... if
 KW> the floppy drive is not read in any way before the program is executed
 KW> the 4626 byte image is produced but running a hex editor like norton
 KW> diskedit or even just performing dir a: before running the disk backup
 KW> program will result in the 16962 byte file being produced (with both
 KW> our versions of the program)...
Hmmm...strange.  Just doing a `dir' shouldn't affect the contents of the
disk at all.  The only thing I can think of is somehow the buffering
and/or caching is causing the anomoly.  I'm only guess, but from the
sounds of things, you could probably ask DOS to search for the first
file on the disk and ignore the result to prevent the anomoly from
happening.  If this works, I'd _definitely_ add a comment about why the
extra code is there and what it accomplishes.
 JC> This should assemble to 89 bytes.
 KW> it did when i commented out the ".stack"....
Ah, in that case you must be using TASM.
 KW> a restoration routine would probably be good too...
Well, yes, that would likely come in handy now that you mention it.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------