> Indeed JAM only works on non-FAT32 kernels because of different > data structures...
Any other different structures besides the SFT? > 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? Nope, here I talked about the MS-DOS SHARE.EXE only problems of MS-DOS 7.10+ only. >>> 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. > > patching JMOUNT [...] is not elegant, but that > is a typical problem with closed source software :-p Anyone tried to contact the JAM developers before patching the binaries? >> 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 :-). Does it parse the "JFT" and SFT chain directly or does it use DOS services such as 2F.1220 and 2F.1216 ? > 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 *could* read the value of the next cluster from the FAT (value inside the FAT entry of just-read cluster) but that could also result in an EOF marker so I guess you're right. > 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. But is the fnode re-used for the next DOS call, or is it populated from all values found in the SFT again? Because, if the former is true, then the cluster reference would be lost as soon as another call used the fnode for another file. And if the fnode was repopulated from the SFT on each DOS call, then if whatever program changed the cluster references in the SFT would also change the fnode indirectly (if it accessed the SFT when the InDOS and CritErr word was zero). > Maybe > extremely lowlevel software such as task swappers or such unimaginable things as online defragmenting software ;-) > could cause > problems here, but JMOUNT should be safe :-). Ack. Regards, Christian ------------------------------------------------------------------------------ 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
