From: address@nospicedham.not.available   
      
   JJ,   
      
   > Since you mention Int 21h (i.e. pure DOS service), you can only use   
   > files as the communication media.   
      
   I mentioned the INT to make absolutily clear that it was a DOS program, and   
   not Windows console, 32-bit, DLL calling one.    Any INT you can reach, or   
   any other method you can think of,  is fair game as far as far as I'm   
   concerned.   
      
   > Or use a more direct approach via Windows interrupt   
   > service (i.e. Int 2Fh)   
      
   I've got Ralf Browns (grandioso) Interrup list here, and have searched it   
   for clues.  Alas, I did not find any.   
      
   > by communicating through Windows virtual devices (see   
   > Windows 3.x DDK).   
      
   I've been using DOS for quite a while, and al my searching in that regard   
   (VxD) came up pretty-much blank.  Can't remember having ever found example   
   code showing what needed to be done, or a description of what the different   
   windows virtual devices all could do and/or how they needed to be talked to.   
      
   I do have some fragments stored ofcourse, but never got a good picture of   
   the whole.   If you have a basic example I would not say no to it. :-)   
      
   > That's for 16-bit Windows program. Not DOS program. Meaning that Win16   
   > API is used.   
      
   The problem is that the old DOS methods do not work, most likely of ntvdm   
   interfering.   So, I have to find a solution that *might* be Windows console   
   specific, and call it only when my program detects Windows to be involved.   
      
   > I don't know what are your requirements, but is UDP socket not   
   > applicable too?   
      
   I've never seen a DOS program in a Windows console talk to the network.  But   
   yeah, that was pretty-much what I was thinking about when I talked about   
   pipes and mailslots.   
      
   But as I said, those client/server solutions do not appeal to me (don't want   
   to have such a server program running al the time).     When that would be   
   my only option I would most likely use the "write batch files to an   
   intermediate file, and execute it" method instead.    At least that is one   
   which seems to work regardless of the platform the command is executed on   
   ...   
      
   Regards,   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)