Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Using Dos for Real Time applications -> CLI (Developers)

posted by Arjay, 09.01.2013, 23:40

> > But then I have one more question : is it possible not to restore the
> > original vector of an interrupt, without crashing the computer ?
 Yes.

For an initial starting point you might want to look at the documentation for
IVTUTIL which covers the basics of using Flopper to capture the initial interrupt vector table with this kind of low level tinkering in mind.

If you are just using DOS as an initial loading mechanism then you can save DOS's current interrupt vector table, go as far even as "stopping" DOS, fully or part restore a previously saved initial interrupt table, do various things then restore DOS's interrupt vector table. See flopper as a public example.

About 1-2 years ago I wrote a DOS swap loader (a kind of basic SYSLINUX if you like) which allows me to replace the current DOS with something else... I added a DOS memory viewer (like ramspy) and then created a test version for fun to see just how far I could go zeroing the interrupt vector table and also other things like the BDA (BIOS Data Area). Unsurprisingly after nuking DOS and pretty much everything else including the highlevel code of the main program with the exception of the ramviewer, the environment that I ended up with was similar to the very basic vm86 using Fabrice Bellard's runcom.

I did various tests and obviously my ramviewer allowed me to the results of these tests, e.g. I tinkered with having different interrupts on or off, e.g. I was able to watch the keyboard buffer overflow and overflow after I took out a little bit too much of the BDA area but not interrupt 16h. I'm not saying that I think you should go down this route which was more extreme than most people need to go but just be aware that there is a lot that isn't needed and once an application is up and running there is a lot that you can knock out quite happily. There was a serious side to my testing as I'm interested in old DOS embedded systems so I was curious to gain an insight into what was involved in replacing DOS in situ and how to maximise limited memory. i.e. I was also looking at could I pack extra code into areas normally used for other things in the legacy DOS, BIOS world.

I'm now back near the machine with this test code on but it's currently unplugged and my life is currently very busy but from memory from my testing I believe that at the most extreme I found that on the standard generic fairly modern clone I was testing with that I was able to zero out most of the interrupt table and run only running a basic handler (iret) on Int 00h, 01h, 03h and still keep my program running in various states happily after DOS, most BIOS services were no more. By various states I mean as above I was also experminenting with killing parts of that code as well but also in terms of safe methods for doing that, since it was highlevel code with some low level routines as well. e.g. move out of main highlevel code to low level routine, move stack, kill original stack and highlevel code etc.

If you want to play with IVTUTIL then I'd suggest having a read of the BIOMenance thread which has some examples.

I would strongly advise NOT using the undocumented patching feature which will be removed as/when I get a chance to update IVTUTIL (if/when/ever).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (2 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum