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