home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,620 of 4,675   
   R.Wieser to Rod Pemberton   
   Re: Indirect INT calling   
   28 Oct 18 08:41:50   
   
   From: address@nospicedham.not.available   
      
   Rod,   
      
   > I would suggest hooking two interrupts.  One is for the random   
   > or changing or relocatable interrupt that you call to access the   
   > API.  The other would be on a fixed interrupt with a unique   
   > registers value, say in AX, for the call to detect the presence or   
   > installation of the packet driver API.   
      
   I'm afraid you misunderstood: Finding the API (and by it its INT) isn't the   
   problem, the packetdriver spec already took care of that (unique string at a   
   fixed offset).   
      
   The problem is that my program needs to adjust to the found INT value.   By   
   default the packetdrivers at INT 0x60, but it can be pretty much anywhere.   
      
   In short, how do I change that "0x60" (in my program) into something   
   flexible -or- how do I create a single-point-of-change procedure (instead of   
   having to implement a fixup for multiple INT 0x60 calls).   
      
      
   Currently the absolute simpelest (in my mind) solution is to create a   
   procedure with only "INT 0x60", "ret" sequence in it, and have the   
   initialisation code change that (single!) 0x60 into whatever it found.   The   
   downside to that is that the call itself adds another WORD to the used stack   
   (a total 8 bytes instead of 6).   
      
   > DJGPP's online RBIL has a table of used or in-use AX values   
   > for INT 0x2F here:   
      
   :-) Ralf Browns intlist has been my to-go source for literallly years, and   
   its files (still) have a dominant place on my machine.   
      
   Regards,   
   Rudy Wieser   
      
      
      
   > So, it seems INT 0x2F might be a good place to install an   
   > installation check or interrupt number check in your case.   
      
   I didn't think of such a method   
      
      
      
      
   > I would suggest hooking two interrupts.   
   ..   
   Rick Hodgin also mentioned that (and I thought of it as well).   I decided   
   against it though, as its too easy to have programs clash that way.  Just   
   imagine two programs using that same mechanimsm (but targetting different   
   packet drivers) ...   
      
      
      
      
   "Rod Pemberton"  wrote in message   
   news:pr3j19$1hgt$1@gioia.aioe.org...   
   > On Sat, 27 Oct 2018 14:51:35 +0200   
   > "R.Wieser"  wrote:   
   >   
   >> I'm dealing with a packet driver, which API (ABI?) can be put behind   
   >> any available INT (by specifying the number when loading it).   
   >>   
   >> I would like my program to find the right INT at runtime (which is   
   >> not hard, as the packet driver has a certain string at a certain   
   >> place, just so you can check if its actually there) and than use that.   
   >>   
   >   
   > I would suggest hooking two interrupts.  One is for the random or   
   > changing or relocatable interrupt that you call to access the API.  The   
   > other would be on a fixed interrupt with a unique registers value, say   
   > in AX, for the call to detect the presence or installation of the   
   > packet driver API.  This is the same way you detect DPMI or XMS etc,   
   > e.g., DPMI installs INT 0x2F, AX=1687h and XMS installs INT 0x2F,   
   > 4300h.  However, DPMI's main interrupt is on INT 0x31 whereas XMS   
   > returns an address to a function on INT 0x2F, AX-4310h.  So, it seems   
   > INT 0x2F might be a good place to install an installation check or   
   > interrupt number check in your case.   
   >   
   > DJGPP's online RBIL has a table of used or in-use AX values for INT   
   > 0x2F here:   
   >   
   > http://www.delorie.com/djgpp/doc/rbinter/ix/2F/   
   >   
   >   
   > Rod Pemberton   
   > --   
   > Bitcoin is a pump-and-dump scam driven by a perpetual Ponzi scheme.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca