home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1278 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.3 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!jvnc.net!yale.edu!nigel.msen.com!emory!sol.ctr.columbia.edu!hamblin.math.byu.edu!arizona.edu!mvb.saic.com!macro32
  2. From: GAVRON@VESTA.SUNQUEST.COM
  3. Newsgroups: vmsnet.internals
  4. Subject: RE: moving DDT for CDdriver etc.
  5. Message-ID: <920903111707.6b3@VESTA.SUNQUEST.COM>
  6. Date: 3 Sep 92 18:17:06 GMT
  7. Organization: Macro32<==>Vmsnet.Internals Gateway
  8. Lines: 59
  9. X-Gateway-Source-Info: Mailing List
  10.  
  11. Date sent:  3-SEP-1992 11:13:44
  12.  
  13. Glen Everhart suggested a standardizing method for stealing DDBs,
  14. FDT entries, and which could also be modified to steal any other
  15. referential vector:
  16.  
  17. >   The notion is to produce a UCB extension that looks like this:
  18. >
  19. >        .long   ident-pattern
  20. >        .long   previous-DDB-address
  21. >ucb$a_victimddb:
  22. >        .blkl   nnnn    ;however long this needs to be, look it up
  23. >
  24. >   With such a standard in force, if I find the DDB from ucb$l_ddb
  25. >of the victim device, I can check ident-pattern against my
  26. >own program's pattern, and if it matches I just go ahead and use
  27. >offsets from there to find my driver's UCB and thus its data
  28. >(e.g. the CDdriver UCB). If it does not match, I chain using
  29. >the previous-DDB-address and keep looking for my pattern, and
  30. >when I find it (in usually one or two tries at most), I have
  31. >found my UCB and can go on from there.
  32. >   The pattern choice is arbitrary, and I have no great objections
  33. >to making it two longs, but I think one is enough by prejudice.
  34.  
  35. Agreed.
  36.  
  37. >   It is necessary of course that this chain never be removed
  38. >or broken once established, though the contents of the DDB copy
  39. >in the area labelled "ucb$a_victimddb" above could of course
  40. >be altered if one wanted to turn off a program.
  41.  
  42. Yes! :)
  43. ...
  44. >   I would suggest a similar strategy be used for stealing
  45. >FDT table bits also. These can be made to coexist rather nicely
  46. >if one has a structure somewhat along these lines for FDT routines
  47. >to be added to a driver's FDT chain.
  48. [code suggestion removed]
  49.  
  50. Yup!
  51.  
  52. >   What say the rest of the forum?
  53.  
  54. I didn't see anything else along this line from anyone - these sound
  55. like good suggestions.  Why not write up a white paper... I'll be happy
  56. to help out if you need any, and I'm sure there are others.
  57.  
  58. >Glenn Everhart
  59. >Everhart@Raxco.com
  60. >215 358 5875
  61. >
  62.  
  63.  
  64.         Ehud
  65.  
  66. --
  67. Ehud Gavron        (EG76)
  68. gavron@ACES.COM
  69. The world consults with you when you're cool.
  70.