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