ma168a@sdcc3.UUCP (02/05/87)
I was not paying attention at the time the newsgroup contained a discussion
of utilities to direct printer output to a file. I recently found that I needed
such a utility -- and obtained two public domain utilities (VPRINT and LPTX --
the latter was obtained from the info-ibmpc library). Both crash on my AT-
compatible running DOS 3.2. I noted that LPTX.ASM was written to work with DOS
2.0. When I run it under 2.0 it does work. I also have no problems with two
separate utilities I wrote inspired by VPRINT: the first saves printer output
to memory; the second saves memory to disk. [While my immediate needs have
been satisfied by these two programs, I'd like to hear from the person who
offered to supply a printer-->disk redirection program provided it works on
DOS 3.2]
The crash occurs at the point, within the printer interrupt, when a disk
service interrupt is called. LPTX tries to ameliorate the problem by saving
a substantial chunk of DOS during the disk call -- apparently the proper chunk
for DOS 2.0 is not the proper chunk for DOS 3.2.
The standard references caution against using interrupts from within a
proposed new interrupt. This imposes a severe limitation which some people
have apparently managed to circumvent in special cases. Are there any general
techniques?
The reason given for the caution is that "DOS is not reentrant". My under-
standing of this is that certain registers and memory locations are used to
service a call and, therefore, if two calls are made to the same code some
vital data needed for the first call will be displaced by the second. This
prevents a true multi-user environment (in which two tasks are executing the
same code at the same time) and it prevents a task from calling a segment of
code before a previous call using the same code or data has been completed.
Vital data contained in absolute memory rather than being stacked or located
in a user frame would produce this problem. I fail to see how a call to a
printer interrupt and a call to a disk write function could overlap, but
apparently they do.
My questions are:
(1) Is my understanding of the problem (as expressed in the previous paragraph) correct? {if not, please explain the situation}
(2) Is there a valid statement of the form:
"to execute interrupt x from within interrupt y you must save
and restore z"
I would be interested in finding that there is a z which works for all x
and y!
John J Wavrik
Math Dept
UCSD
...ucbvax!sdcsvax!sdcc3!ma168a (uucp)
sdcc3%ma168a@SDCSVAX.UCSD.EDU (arpa)ee65xta@sdcc14.UUCP (05/08/87)
I am attempting to write an interrupts handling routine in Microsoft C, and have been having some difficulty. Presently, I am installing a short assembly language routine that saves registers, and then calls my C routine. Once it is installed, my program then tries to call the interrupt trhough the Microsoft C int86() function. I know that the routine is installed correctly, because when I perform the interrupt from a program, it makes it to my routine, and works fine. Unfortunately, it never makes it back to the main program once its done, but instead, locks everything up. I am using one of the unused interrupts, so I shouldn't be conflicting with any system things. Is there anybody out there who has tried something similar, or who knows of something I might be doing wrong? Any help would be greatly appreciated. Steve
rosen@mtgzz.UUCP (05/11/87)
In article <266@sdcc14.UUCP>, ee65xta@sdcc14.UUCP (Steve Burnap) writes: > [...] > in Microsoft C, and have been having some difficulty. Presently, I am > installing a short assembly language routine that saves registers, > and then calls my C routine. Once it is installed, my program then > tries to call the interrupt trhough the Microsoft C int86() function. > [...] > works fine. Unfortunately, it never makes it back to the main program Are you sure that all your CALLs and RETs match up. That is are they all far and near. Specifically, after you return to the assembly routine do you restore all registers and do an IRET instead of a regular RET. (IRET pops 3 words, the saved return address, and the flags). -- Tom Rosenfeld @ AT&T Information Systems Labs, Middletown, NJ (201) 957-5867 UUCP: {harpo,ihnp4,burl,akgua}!mtgzz!rosen Disclaimer: I don't claim anything.
jim@aeshq.UUCP (jim) (10/11/89)
I am looking for the most current interrupt list available. I know it is
out there, and I know it is big, so if you have it and are willing to send
it my way, could you drop me a line?
Also, I see that the interrupt list is updated by sending out a diff. In
order to apply this diff to to your list I believe you need a program called
patch. Could someone send me this too?
Still further, I am just learning interrupts and would be eternally grateful
for any examples people could supply me. In particular I would like to know
how to detect any key or combination of keys pressed on the keyboard; but
any example would do nicely. (I use Turbo-C, but am willing to learn assembler
for the IBM - any suggestions on reading material? assemblers? (I believe
Turbo-C comes with an assembler, but I have never used it)).
Thanks,
(and Eternally grateful - Now that's inspiration!!)
Jim Roberts
--
Jim Roberts {utgpu,mnetor}!geac!aeshq!jim |
Environment Canada |"Now that's entertainment!"
Atmospheric Environment Service | - G. Khan