Hi, not sure about that yet, but I think Bart pointed out the way to go here: As I described, most f_node fields have corresponding SFT fields. And we recently had this new abstraction level which copied between NEAR and FAR f_nodes. Barts suggestion is to replace those copy functions by functions which CONVERT between NEAR f_nodes (which can stay exactly as they are, and are hopefully only valid while you stay in the kernel, i.e. not while the application is running) and FAR SFT entries. This conversion would be relatively simple as f_nodes and SFT have many similarities.
Things required for this to work: FAR f_nodes must not be touched by anything except the near <-> far copy functions, NEAR f_nodes must not stay valid while InDOS is false (otherwise applications could change the SFT in the meantime, and the f_nodes would need to be refreshed), and the conversion function must be able to decide when the raw directory entry (you know, a chunk of 32 bytes length) has to be copied to / from disk. In particular, it should be able to avoid unnecessary disk writes. Usual kludge would be a checksum, but it would be more elegant to "just know" when the dir entry has to be written back to disk. If all those preconditions are met, we can drop FAT f_nodes completely and do a big jump forward compatibility-wise. We will even be able to cope with programs which change the number of FILES=... (SFT size) dynamically. I think that causes big chaos while FAR f_nodes exist, as you would have a different number of FAR f_nodes and SFT entries. NEAR f_nodes can stay as they are for now, so the transition would be relatively easy to implement. But do not forget Tom's warning: If f_node fields have slightly different semantics compared to SFT fields, a program which uses undocumented DOS heavily enough to make it break will show up. However, I think the general perspective is quite promising. Background: Now, many SFT fields are not processed by FreeDOS at all. In the future, those fields would be used in quite normal way, possibly with small oddities coming from f_node traditions. I think it is still better to have the fields in use than to have them dangling around with 00 bytes inside and hope the best, in particular for fields like cluster numbers, even if "in use" only means 99% MS DOS style, not 100%. http://cvs.sourceforge.net/viewcvs.py/freedos/kernel/hdr/sft.h?rev=1.13&view=log http://cvs.sourceforge.net/viewcvs.py/freedos/kernel/hdr/fnode.h?rev=1.20&view=log f_flags is almost (not exactly?) the same as sft_flags f_dpb is the same as sft_dcb, but for devices the SFT word is used as sft_dev, how is this handled for f_nodes? f_mode is almost (not exactly?) the same as sft_mode f_count is almost (not exactly?) the same as sft_count f_dir exists only in f_nodes <<< f_diroff might be the same as sft_diridx f_dirstart might be the same as sft_dirdlust (sic!) f_offset is the same as sft_posit as far as I can tell f_cluster_offset seems to be the same as sft_relclust f_cluster should be the same as sft_cuclust sft_stclust is the same as a field in f_dir sft_time is the same as a field in f_dir sft_date is the same as a field in f_dir sft_size is the same as a field in f_dir sft_name is the same as a field in f_dir sft_attrib is the same as a field in f_dir, I hope OTHER f_dir fields have no corresponding SFT fields, so it looks like we have to access the directory on disk to create a near f_node or to write back near f_node changes? In particular, VFAT extra timestamps are affected - what else??? sft_bashare / sft_shroff / sft_status are alledgedly processed by SHARE, and are also processed by KERNEL (not sft_bshare) sft_psp is for "commit/close by task number", which is normally the PSP segment but for Win386 it is the VM number (this is why Win386 wants to be able to disable checking/setting of that value by the kernel... at least that is my educated GUESS about that field). sft_mach has the same purpose (machine number, 0 if local computer)... sft_status is already handled by kernel. sft_ifsptr is - I believe - only accessed by IFS drivers, and hopefully initialized to 0 by kernel. So we would need some fiddling around with f_dir, but all other fields can be simply copied between near f_nodes and SFT entries in order to obsolete far f_nodes. Well, maybe not ALL other fields. Would be nice if the experts could comment the above list and tell if all my "is the same" are true and "how almost" my "is almost the same" or "might be" or "seems to be" or "should be" the same fields are "almost the same". The CURRENT kernel version does not bother to touch any of the following SFT fields, even though almost all of them have corresponding and actively used f_node fields: sft_dcb, sft_stclust, sft_relclust, sft_cuclust, sft_dirdlust, sft_diridx, sft_bshare and sft_ifsptr (as far as I can tell, only the last 2 have no corresponding f_node fields). Eric ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
