home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / mswindo / setup / 2064 < prev    next >
Encoding:
Text File  |  1992-11-21  |  2.9 KB  |  62 lines
  1. Newsgroups: comp.os.ms-windows.setup
  2. Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!spool.mu.edu!umn.edu!csus.edu!netcom.com!fuzzy
  3. From: fuzzy@netcom.com (Fuzzy Fox)
  4. Subject: Re: Can't pipe to NUL in a dos session - Help please!
  5. Message-ID: <1992Nov22.042652.5566@netcom.com>
  6. Organization: Foxes 'R' Us - Seven locations to serve you
  7. References: <168A28014.ANAVARRO@vm.poly.edu> <1992Nov18.175648.17461@rei.com> <1992Nov21.182227.12451@ucsu.Colorado.EDU>
  8. Date: Sun, 22 Nov 1992 04:26:52 GMT
  9. Lines: 51
  10.  
  11. colfelt@ucsu.Colorado.EDU (Andrew BW Colfelt) writes:
  12.  
  13. >I always thought that piping > NUL was just a
  14. >fancy @ECHO OFF statement, but this comment leads
  15. >me to believe that it is not as innocuous as I
  16. >believed.
  17.  
  18. Since I have not programmed TSR's, I must first explain that this is
  19. information I have heard on the net, but I have no direct experience.
  20.  
  21. When you run a command and redirect its output via >NUL, the shell
  22. (command.com) opens the NUL device as a file and passes this file handle
  23. to the program.  The program writes its output to this file and thus the
  24. output goes nowhere, essentially the 'ECHO OFF' behavior.  However, the
  25. file is still opened by DOS and the application still performs write
  26. operations on this device.
  27.  
  28. Most programs terminate when they are done, and so the file that they
  29. are writing output to is then closed for them.  However, in the case of
  30. a TSR, the program does not exactly terminate, because it stays resident
  31. in the machine.  So, if the program is written poorly and the programmer
  32. forgets to close the output file, then that means the output file for
  33. that program remains open forever, or at least until you reboot the
  34. machine.
  35.  
  36. I'm not sure how the sharing code works, but SHARE is a program which
  37. prevents simultaneous conflicting access to files and devices.  For
  38. instance, it will prevent to programs from trying to write to the PRN or
  39. COM1 device (which is a very good thing!).  I am not sure, but I believe
  40. that DOS does not differentiate when it comes to the NUL device, and it
  41. prevents conflicting accesses to that device as well.
  42.  
  43. So if a TSR is installed with its output redirected to >NUL and it does
  44. not close the file as part of its installation, then SHARE will prevent
  45. other programs from trying to write to >NUL because another program is
  46. using it.
  47.  
  48. Now, the short version:  Go into AUTOEXEC.BAT and remove all the
  49. redirections to >NUL, then reboot and see if your problem goes away.  If
  50. it does, then what I said above is causing it.  Find out which program
  51. is causing the trouble, and don't redirect that program's output to
  52. >NUL.
  53.  
  54. If your problem does not go away, then that means I'm wrong.  Please let
  55. me know if I am.
  56.  
  57. -- 
  58. #ifdef TRUE         | Fuzzy Fox                  fuzzy@netcom.com
  59. #define  TRUE   0   | a.k.a. David DeSimone      an207@cleveland.freenet.edu
  60. #define  FALSE  1   | "You have been recruited by the Star League to defend
  61. #endif              |    the Frontier against Xur and the Kodan Armada."
  62.