Re: Redirecting a DOS interrupt call out to Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 18 July 2013 23:49:41 Stas Sergeev wrote:
> 18.07.2013 20:35, Andrew Bird (Sphere Systems) пишет:
> > Hi all,
> > 
> > 	I've been playing with the Dosemu source code with the hope of replacing
> > 
> > an old TSR with a native Linux daemon. Currently a DOS app I have no
> > source
> > for makes an interrupt call to a TSR with data, the TSR works with it and
> > the result is returned.
> > 
> > I had in mind to replace it with something like this:
> > 1/ Old DOS app makes call to interrupt
> > 2/ New Dosemu interrupt handler that collects the data given to it by the
> > DOS app and pushes it into a message queue on the host.
> > 3/ A Linux daemon that reads the incoming message, does the processing and
> > returns the result via a second message queue.
> > 4/ The new Dosemu interrupt handler then reads the result from the second
> > message queue, places it in memory and returns.
> > 5/ The DOS app sees the result and is unaware of any difference.
> > 
> > My first step was to hook in a new skeleton Dosemu interrupt handler, but
> > it doesn't seem to be being called and the DOS app thinks the TSR is not
> > installed. I'm using Dosemu 1.2.2 for historical reasons, but I expect
> > the problem is similar on 1.4.0 etc.
> > 
> > I figured all I'd need to do would be to add a new function to
> > src/base/async/int.c and reference it.
> > 
> > /* this is the handler for INT 76 calls from DOS to the test interface */
> > int test_int (void) {
> > 
> > 	ds_printf("INT76: we have been called\n");
> > 	return 1;
> > 
> > }
> > 
> > /* add reference to it in setup_interrupts() */
> > interrupt_function[0x76] = test_int;
> > 
> > Can anybody tell me what I'm missing? How does the interrupt vector table
> > get built?
> 
> Firstly, the interrupt handling is much different in 1.2
> and 1.4. Secondly, you need to make sure the interrupt
> vector points to BIOSSEG:INT_OFF(i) (see bios_setup() in setup.c)
> and that no one have hooked it from DOS (or, at least, chains
> it back to the original address).
> Alternatively you can make dosemu to try and intercept the int0xNN
> instruction. In this case you won't need to worry if someone have
> hooked that vector under DOS. For that you will need to modify
> the can_revector() function.
> Note that this all applies to 1.4. I have no idea how 1.2 worked,
> this was too long ago.
> Additionally, curent git allows you to sleep inside the interrupt
> handler of dosemu, while the DOS is still running. This will likely
> allow you to do the thing within one interrupt call, instead of 2.

Hi Stas,
	Thanks for the help. For the time being I've switched to latest git 
master whilst I experiment. It seems the reason the handler wasn't being 
called initially was that the DOS program was checking to see the memory 
location matched what it expected in the Interrupt table. If it wasn't correct 
then it just bailed out. Swapping the SETIVEC to match that address cured the 
problem for the DOS programs, but of course I need my interrupt routine to 
live there. So it seems I can't use the normal Dosemu mechanisms for adding 
interrupts. I don't want to code my mods in assembler, as you can imagine. 
I noticed that the int33 mouse was doing something similar, so I added a 
little code to the bios.S assembler file, to just add a 'hlt' at the correct 
address. I've then modified the hlt handler to call my function just like 
int33_post(). Inside there I have a di_printf() and a fake_iret(), and it's 
being called fine now, I just have to add the function meat.

	Are there any downsides to this approach?

Best regards,

Andrew 
--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Console]     [Linux Audio]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Camping]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Linux Media]     [Fedora Users]

  Powered by Linux