🚀 go-pugleaf

In article <2409@vrdxhq.UUCP> tom@vrdxhq.UUCP (Tom Welsh) writes:
>
>As many of you may know, DOS is NOT reentrant.  In other words,
>if DOS is busy doing something like writing to disk or printer,
>then no interrupt routine should attempt to invoke a DOS service,
>e.g. INT 21H.   I found this out by having a program crash.  My
>
>Here's what I'm curious about ...
>
>SuperKey, which responds to keyboard interrupts, seems to obey this
>rule.  If, while doing nothing, I press ALT-/ to invoke Superkey,
>it comes up instantly.  If I do something like copy a gigantic
>file (requiring several seconds), and I press ALT-/ as soon as the
>copy starts, Superkey WAITS until the copy is done before it comes
>up.   HOW DOES IT KNOW at the time of the interrupt that DOS was
>currently doing something and should not be interrupted?  A while ago,   
>someone on the net mentioned a DOS/BIOS service or a flag that could
>be checked to see if DOS was busy.  I can't find such a thing in
>the Superkey code.
>
>And, on another note, I found an INT 28H in the Superkey code.  What
>does this do?  All my documentation says its reserved for DOS.   
>

	In a previous place of employment, I was involved in solving the
	DOS reentrancy puzzle.  The product that I worked on was a real-time
	communications device, a terminal emulator, that could be placed in
	the back-ground via "Hot-Key".  What was special about this product
	was the ability to have background file-transfer while a separate
	user application was occuring in the foreground.  We went through a
	number of contortions with DOS to provide this backgound file transfer
	ability, the above mentioned INT 28 being one of the keys to our
	sucess.
	
	Our product ran off of the hardware timer while in background mode.
	To make matters even more complicated, the product was comprised of 
	three separate resident modules, each of which communicated with
	each other via software interrupts.  The lowest module was driven
	by interrupts occuring from a communication line, while the higher
	modules were driven by the timers tick.   Incoming data was buffered
	in the lower module,  waiting for polls from above before passing it
	up to the higher layers.

	The highest of the three layers was the brains of the whole system. It
	polled the other two modules for data as well as interfacing to both
	DOS and BIOS.  Being the brains, it had to know when DOS was in a
	critical section, caused by a foreground application issuing an INT 21
	call.  Sounds simple... just trap INT 21, put a semaphore around it
	and hold off any DOS accesses until the INT 21 call finished.  This
	was our first approach, and it worked resonably well.  Unfortunately,
	we discovered that the DOS command prompt, as well as many applications
	issued keyboard reads by waiting for input (INT 21 functions 1 and 0A).
	We also had problems around the EXEC and EXIT calls (function 4B and
	4C).  End result... try another solution.

	The next attempt involved the famous undocumented DOS "dirty bit".  
	While DOS is not reentrant to the outside world, it reenters itself
	left and right.  In fact many function calls call DOS dozens of times
	before completing.  For an educational experience try tracing a DOS
	function call, function 4B  for instance. Anyway,  if DOS reenters it-
	self, it must have a means of checking when it is safe to do so.  This
	means is provided  in MS-DOS via INT 21 function 34.  Note that I said
	MS-DOS as opposed to IBM PC-DOS.  It returns the DOS critical section
	semaphore in AL, if AL is 1 DOS is busy, try again later.  To make a
	long story short, this worked 98% of the time, but we still had problems	when DOS itself was waiting for keyboard input, and when the user "hot-
	keyed" at just the wrong instant.  So... scratch one more good idea...

	After a series of marathon sessions tracing through PRINT.COM and
	MODE.COM we started to notice that  DOS grabbed the INT 28 interrupt
	vector in these programs.  More disassembling convinced us that we
	had tripped over DOS's internal scheduling mechanism.  We found that
	many of the DOS functions called INT 28 from within themselves. A
	lot of experimentation convinced us that trapping INT 28 was a means
	of knowing when it was safe to reenter DOS. So.. we built a system
	that used the INT 21 function 34 semaphore to tell us if we could
	interrupt DOS, if we could, great, off went our disk or printer request
	with no risk of rentrancy.  If on the other hand, the semaphore 
	indicated that DOS was in a critical section we backed off, since 
	we were currently in the hardware timer interrupt, not a good place
	to be while DOS is critical. 

	Before we exitted the timer however we set another semaphore of our
	own indicating that we had a pending DOS request which had been post-
	poned.  We then trapped INT 28, and issued the postponed request when
	the next INT 28 occurred, one that DOS itself had generated, indicating 	to other applications that they could schedule a DOS interrupt at this
	time.

	I would be extremely interested in hearing from anyone else on the
	net with similar solutions to this problem.  I also would like to pose
	two questions of my own.

	First; is there anyone who had access to DOS source code that can
	postively confirm that INT 28 is a scheduling function? 

	Second; a corollary part of our product was the ability to deallocate
	the three resident programs from memory.  We did so via a SETBLOCK
	(function 4A) when starting the program and a FREE (function 48)
	when the user wished to deallocate the program.  It worked most of
	the time.  Any hints what we were doing wrong, any other approaches
	to this problem would also be interesting.


	Larry Backman
	Micom Interlan, Inc.
	155 Swanson Rd.
	Boxborough, Ma.  01719
	617-263-1199

	mit-eddie \
	ulowell    -> !interlan!backman
        ima       /