Hi! Indeed JAM only works on non-FAT32 kernels because of different data structures... JAM apparently needs the start cluster of the compressed disk file so it can use lowlevel (int 25/26...?) calls to access that file without causing reentrancy while the kernel accesses files on the compressed disk :-).
> Ignoring the fact that it apparently broke SHARE.EXE, too Our version of share? Does it work less well on FAT32 aware kernels? >> It's hard to be compatible to everyone... >> In any case JAM can be made >> compatible to MSDOS 7.10 on FAT16 by DEBUG >> (in addition to the changes discussed before): >> debug jmount.com >> edf3 >> 35 >> w Interesting. >> That'll make jmount incompatible with MSDOS<4, DRDOS 5&6, but >> compatible with newer versions, because the word at 35h is the last >> accessed cluster, and after reading one sector (as Eric showed) that >> will still be the starting cluster. Not sure whether JAM will have accessed the file at that moment, probably yes :-). Of course patching JMOUNT into different extra versions (one which accepts FreeDOS, one which accepts FreeDOS and uses FAT32 kernel specific offsets) is not elegant, but that is a typical problem with closed source software :-p A proper "if DOS version X then do Y" patch would be quite painful to push in the JMOUNT binary I guess. > Does JAM read anything from the archive file (I presume it wants > the first cluster of that file) before looking into the SFT? It does the following: Drive reset, network flush buffers, check if drive is remote, check for DJ mechanism state, for dblspace, for JAM drive properties, truename, more JAM drive properties. Then it checks the DPB of the drive with the JAM compressed disk file on it, OPENs that. Then dosdebug/dosemu logged that a first disk sector read happens, not sure why. Next JMOUNT seeks to: current +0, end +0, start +0. Now JMOUNT reads the first sector of the compressed disk file. Then it checks the JFT and SFT to, indeed, get the start cluster of the compressed disk file :-). > Also, what if it read > exactly one sector (or more) but the cluster size was only one sector, > either? Then it would read the second cluster instead of the first one > from the SFT. I am not sure whether DOS would already read the next cluster when you read the first (size of cluster) bytes of a file, I would guess it will not... >> It won't help FreeDOS of course because it still uses fnodes >> for these things instead of SFTs. In your context: Wrong. FreeDOS keeps the SFT in sync as far as outside viewers are concerned. Only WHILE the kernel works with fnodes, some information might not yet be updated. But as soon as FreeDOS returns the first sector of data to JMOUNT you can assume that the SFT of FreeDOS (yes it does use it) already has the cluster number that JMOUNT needs :-). The only problem is that JMOUNT has no idea how to work with FAT32 SFT which makes it fail on FAT32 enabled kernels - even on FAT16 and FAT12 drives in this case ;-). > Doesn't it update the SFT relative and absolute current cluster values, > too? As far as I've understood it, fnodes should be invalidated when > leaving DOS, so if these cluster references were saved in the fnode only, > it wouldn't help a lot. FreeDOS already does exactly that - as soon as any int 21 call is done, the SFT is updated with information from the fnodes where necessary. Only if an outside software would WRITE to the SFT you could cause problems because this might get the SFT out of sync with the fnodes: FreeDOS might have information stored in the fnodes which the outside software which manipulated the SFT will fail to update if it does not know about fnodes. Maybe extremely lowlevel software such as task swappers could cause problems here, but JMOUNT should be safe :-). Eric ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
