Thread: _doint( and _poke( ??????

Hello,

I am re-writing an old program, but that was a DOS program,

now i found the next two function:

_doint( .... ) // mostly integers as argument

and

_poke( .... , .... , .....)

And now i don't know what the function do, is there anyone who knows????

Please help!

GR Johan

Never heard of doint or poke (pokeb?) but just from looking at them here is my guess.


_doint(int intvectornum) -> Generates a software interrupt. Same as geninterrupt() and probably does not preserve the registers which can leave them in an unpredictable state.


_poke(unsigned int,unsigned int,byte value) -> Pokes (places) a byte value into memory at the specified offset and segment.


I have C++ version 1.0 and these functions are not part of that compiler. It is from way back when so I can't imagine what version of compiler you have that would use these functions if my super old dinosaur days C++ compiler does not have them.

Well, ...

That's the problem,

It is for my work, and i have an very old program that should be re-writen, and
the maker (company) who made the program, does not exist anymore, and my own compiler Visual C++ 6 doesn't know the functions too..

But tanx...

Maybe it is what you said, and i am looking if that makes sense.

So tanx for helping.

Well, here is a way to implement the _doint in TASM.

Code:

__doint  proc
ARGS intvectnum:WORD

int [intvectnum]

ret
__doint   endp

I'm not sure if this code will work or not. Currently I'm not near my Intel manuals so I cannot guarantee that the instruction INT can take an operand such as the one I used. If not, you might be able to place a value in AX and then do INT ax, but again this looks suspect. Really easy concept, but the code actually got me thinking there for a bit. I will do some more research when I get home. But thinking about this logically I'm sure that Intel designed the INT instruction to be able to take a memory or register operand expressly for this purpose. Otherwise you would have to write a lot of code to do 255 interrupts (check the value - compare - jump to the correct spot in the function - generate the correct interrupt)


Here is a possible implementation of the poke function.
Offset is a reserved keyword in TASM so I used offst instead.

Code:

__poke  proc
ARGS segment:WORD,offst:WORD,value:BYTE

mov   ax,[segment]
mov   es,ax

mov   dx,[offst]
mov   [es:dx],value

ret
__poke   endp

Again, no testing done here so it might not work as is - I just wrote it off the top of my head. It should give you an idea on how to convert these.


The new equivs for __doint would be:

int86(int intvectum, REGS inregs,REGS outregs);
int86x(int vectnum,REGS inregs,REGS outregs,SREGS sregs);
geninterrupt(int intvectum);----->>(don't use this one)

It should be easy to find an equiv for poke - C has quite a few poke and peek functions and I don't remember them right off hand.

I'm also assuming that you are in real-mode here based on the age of your code and based on the fact that it is generating 8086 software interrupts.

Tanx,

and yes it is true that i just want to know what the function does, because i want to know, if i need them too..

But with the code from Bubba i know know what the functions do...

Tanx to all.

Smal sample code

Code:

union
{
     unsigned dun;
     char dch[2];
}data;

_rax = sens_num - 32; /* user defined  data channel */
_doint(0x60);
data.dun = _rax;
_poke( data.dch[0] , data_off + (n<<1) , data_seg);
_poke( data.dch[1] , data_off + (n<<1) + 1 , data_seg);

I think that doint() reads data from the user-defined data channel. But then it
does a poke() but i still don't realy understand what that does here....

"n" is number of datapoints.

GR Johan

Hmmm. Salem is right. Perhaps __doint() does not generate software interrupts. Looks like I was right on the poke function though.

From that code snippet it is very hard to see what is going on - but I agree with Salem that there is probably a device driver that has been installed on an interrupt or something.

Need more code snippets to see what is going on. And with the link that Salem provided you can see that a lot of companies have used interrupt 0x60 so it is going to be very hard to determine exactly what is being done here, unless you know what ISR has been installed on 0x60 and for what purpose.

So unless you already have a win32 device driver, I can't see where you're going with this.

It could be that a TSR is supposed to be installed before this code runs and it's probably not 32-bit given the age of this code. It's probably installing a TSR on an interrupt in real-mode and this code is simply using that interrupt to use some function(s) provided by the TSR - probably to communicate to some type of hardware or something.

Could be wrong. It's just a thought.