Frequently Asked Questions (FAQ) If you can't find the answer here, please look in the NT/95 specific pages and the readme file.
Why is this not an Installable File System Driver (IFS) ? I have written an IFS for NT which you can find here. It is not finished but should be stable enough for personal use. Some other drivers also exist: For windows 95, there is a read only driver already available from http://www.yipton.demon.co.uk/ I am not sure on the development status of this, but the read support is adequate. Where is the debug log? The debug log is written to the debug window. To enable the debug log, go to View -> Options -> Debug and select the debug level (high) and select show debug window. As of version 0.17, the debug log is automatically saved when you exit the program. In earlier version, to save the log to a file, right click and select all, copy and paste into notepad. Why is the program so slow? It depends. On my machine, a PII 233, I think the speed is quite acceptable. The /dev directory takes a while to list, but that is due to the inefficiencies of the graphical component. Exporting files is as fast a copying from NTFS to NTFS, and in my opinion, write support is actually faster than copying files using explorer. The slow down is due to the graphical tree and list components. I think that Delphi attempts to optimise the usage, but it can't handle a large number of items very well. One day I may switch to Delphi 4, where I can attempt to fix this, but until then... As of version 0.18, there is a percentage display used to show the progress of the directory listing. This is the time spent adding the items to the list view. The actual time spend reading the disk is very small. If you find you self waiting while the progress bar works it's way along, complain to Borland and Microsoft, not me. Windows 95 is a different kettle of fish. Because there is no way to read raw sectors from a hard disk (see http://support.microsoft.com/support/kb/articles/q137/1/76.asp ) I have to use a 16 bit DLL. This requires thunking the code, so all the data is passed via the stack. The DLL uses DPMI to call int 0x13, which uses CHS addressing. It is only possible to read up to the end of a track using this interrupt, for a floppy, that is 18 sectors. This means that there is 18 * 512 = 9k of data being pushed on the stack, and copied round in 16 bit land. That is why it is so slow. But, have you ever pulled out a CD and then attempted to access it. 95 starts to blue screen and stop responding, even after you re-insert the CD. This is even slower, so I don't feel to bad. Am I going to improve the speed? If I can find a way of improving the speed, without making the code so complex that I can no longer maintain it I will. I am not however interested in speeding up 95 support. If any body wants to donate a faster solution, feel free, but otherwise it will stay the same. Would more RAM help? Initially I had a plan to cache certain parts of the disk to speed up access. This resulted in complex code which did not provide much improvement. The current scheme stores the disk wide info in memory all the time. The first time a block group is accessed, group specific info is loaded, and stored until the program quits. This provides, IMHO a reasonable speed/memory/complexity trade off. You will notice that the more directories you look at, the more RAM will be taken up. My drives are labelled wrong. Because of Windows abstractions, the physical disks are numbered sequentially. There is no information as to which drive is connected to which physical bus. For this reason, the numbers do not map to letters the same way as under Linux. If you do not like this, please implement a fix. I will not. How do I enable write support. Because of the bugs, write support has been permanently removed. Explore2fs used to work fine, and now it just says Access violation at address xxxxxxxx Did you use Partition Magic? There seems to be some kind of incompatibility between partition magic partition tables and what explore2fs expects to find. This might be my fault, or Partition Magic's fault. I might work out a workaround, but until then, you will just have to put up with exceptions. These exceptions could also be caused by any number of bugs in explore2fs. Unless you are willing to help find and resolve the problem then there is no point reporting them. Last modified
24/05/05 |
