Hi, I tried to understand what SAVEDS and SAVEBX mean for MS DOS... it is used in the main int 21 handler, functions 0..32, 34..4f, 52..61, 63 and 64..??. First, ES DS BP DI SI DX CX BX AX are pushed. Then DOSDS is loaded, caller DS and caller BX are saved in SAVEDS and SAVEBX. A far pointer at dosds:584 is copied to dosds:5f0, byte dosds:572 is zeroed, if dosds:1030 tests 1 zero, dosds:33e (the "user id word") is zeroed. Finally the indos flag is incremented. Current stack far pointer is saved to dosds:584 (see above). DS = dosds:33c = dosds:330. Stack far pointer is saved again, now to DS:2e, and new stack far pointer is set to dosds:7a0. (value, not a variable at dosds:7a0). DS is set to dosds, too. caller AX is saved in BX, and AX is zeroed and used to zero 5f6, 357, 34a, 34a bytes, and 611 word with 800, set 358 byte to 1, ... BX is set to twice caller AH. Functions 0, 59 and 1..c are special cases, the latter using SP=aa0 unless dosds:320 is a nonzero byte... some other things happen... Functions 0 and above c do: 33a=ax 323=1 320=0 322=-1 (bytes), do int 2a.82 with AX pushed/popped around it, 358=0, SP=920, if 337 (byte) nonzero "call 90b9" with AX pushed around it. In the end, all reach the main dispatcher: fetch BX from SAVEBX, while at the same time storing the near pointer to the handler for the requested function in SAVEBX. Restore DS from SAVEBS. Finally CALL the handler. dosds:86 and not 4, cli, then start to clean up: load DS with DOSDS again, and if dosds:85 (byte) is zero, decrement indos, restore stack pointer as stored in dosds:584, store returned AL on stack, copy back dosds:5f0 pointer to dosds:584, pop all registers, iret.
So SAVEDS just stores the caller DS for some not really obvious reason (a handler at 3adc, it seems: DS is copied back to SAVEDS, Then pop ax, ax, dosds:584, pushf, clip push ax, dosds:584, SAVEDS, pop DS, if CL above 24 then (AL=0 IRET), AH=CL, jump into the main int 21 handler again (skipping the "if AH above 6c..." check, but otherwise at the very beginning). ... nothing else seems to use SAVEDS!?) And SAVEBX stores the caller BX, but that is exchanged with the handler offset when dispatching. There is no clear reason why this is important for instancing, but on the other hand it should be no problem to just store the caller DS and BX in two dummy variables. I forgot what the purpose of that "do int 21.0..24 but use CL as func number" handler is... does it ring a bell for somebody? "User ID" checking is, by the way, found at: 70:6835 "if es[di] byte is not -1, inc bx. If es[di+31] word is not dosds:33c, inc bx. If es[di+2f] is not dosds:33e (userid), inc bx. Otherwise es[di]=0 byte." ... something with data structures of 3b bytes size ... at 70:9f68, "if dosds:1030 byte test 1 is zero", dosds:33e = [dx+12] and dosds:33c = [dx+14], this happening right after "cmp al,7 / jb do_this / cmp al,9 / jbe skip_this", which sounds familier! At skip_this, what follows is pushing a far pointer (stored several 10s of bytes before this handler in what looks like a call table), push ax, call something, mov byte dosds:323,1, mov al=1, jump to ah=0 / call 3 things, [si+16] or 1, stc, [si]=ax, ret. ... Similar stuff happening at 70:a10b / 70:a3b2. So this thing is not used a lot, but probably the context is, as suspected, "commit file by machine/user/task". Enough of that for now :-). Eric ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
