home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text5743.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.8 KB
  1. Received: from orion.it.luc.edu (orion.it.luc.edu [147.126.1.9]) by nacm.com (8.6.10/8.6.9) with ESMTP id WAA22873 for <executor@nacm.com>; Fri, 20 Oct 1995 22:55:38 -0700
  2. Received: from bhawley.it.luc.edu (lsdiala07.it.luc.edu [147.126.1.107]) by orion.it.luc.edu (8.6.12/8.6.12) with SMTP id AAA27840 for <executor@nacm.com>; Sat, 21 Oct 1995 00:55:35 -0500
  3. Date: Sat, 21 Oct 1995 00:55:35 -0500
  4. Message-Id: <199510210555.AAA27840@orion.it.luc.edu>
  5. X-Sender: bhawley@orion.it.luc.edu
  6. X-Mailer: Windows Eudora Light Version 1.5.2
  7. Mime-Version: 1.0
  8. Content-Type: text/plain; charset="us-ascii"
  9. To: executor@nacm.com
  10. From: Brian Hawley <bhawley@luc.edu>
  11. Subject: Long filenames
  12. Sender: owner-paper@nacm.com
  13. Precedence: bulk
  14.  
  15. Hi all!
  16.  
  17. I've been giving this some thought, so here are a few suggestions as to what 
  18. the long filename slowdown might be caused by. 
  19.  
  20. As far as I know, the long filenames are accessed under DOS with a different
  21. set of interrupts than the original DOS interrupts. This keeps the legacy
  22. code working. You have to check whether the new set of interrupts is working
  23. before you can use them. The fast way to do this would be to check once at
  24. the beginning and then just use the new API. The slow way would be to check
  25. before every call. When you are scanning the hard disk, the overhead of
  26. repeatedly asking whether you can use the LFNs for each file would be huge.
  27. So, which method does the file handling code of djgpp 2.0 use?
  28.  
  29. In any case, a directory with LFNs in it would take longer to read than
  30. another with the same number of files and the old filenames. Since the VFAT
  31. filesystem stores the new-style names in additional FAT entries, the system
  32. has to read more entries when it reads the directory. This can only be fixed
  33. by using a different filesystem, a suggestion that has no place here.
  34.  
  35. Oh, I also have an answer to this question:
  36.  
  37. At 12:54 PM 10/18/95 -0400, jdvanas@iac.net (Josh Vanas) wrote:
  38. >                                    What might I have changed this time 
  39. >and/or are long file names supposed to work outside of the win95 GUI?  If 
  40. >they don't, why not?  It is still the same OS, right?
  41.  
  42. No, it is not the same OS. Command-line mode is the OS formerly known as
  43. DOS. Long filename support is provided by a VxD (virtual device driver) that
  44. is loaded with the GUI. This VxD extends DOS with additional capabiltiies,
  45. as others in previous versions of Windows allowed DOS programs to access the
  46. clipboard and other things. VxDs will only work in protected mode.
  47.  
  48. It should be possible to create a DOS device driver that performs the same
  49. service in command-line mode (or even for previous versions of DOS). Such a
  50. creation is beyond the scope of my knowledge and this mailing list.
  51.  
  52. I hope this helps.
  53.  
  54. Brian Hawley
  55. bhawley@luc.edu
  56.  
  57.  
  58.