Hi all, could you file the list of problems which are mentioned in this thread as Bugzilla entries? I believe some RTM did work - and Lucho found a very small binary patch to fix 32RTM - so Lucho, please try to remember what you patched and why, thanks. This might also be related to the used XMS driver (and maybe XMS swap or HMA usage, who knows).
f_nodes should shrink in a somehow slow and safe way. Use SFT where possible without significant size increase / speed decrease ... see my old suggestions about "safe f_node shrink". I do not know enough about SFT structure to be able to tell if it would be a good idea to embed 1 SFT entry into each f_node. First it would be good to have the "2 near f_node" thing fool-proofed, as far as I remember Tyler was able to make the newest kernel panic (out of near f_nodes) in some way. And as usual: Fixes first, optimizations later. Eric PS: Would it be possible to checksum SFTs and throw away / refresh f_node data when SFTs were modified by "3rd party software"? This should be worth many bytes (but << 1kb) of kernel size as long as it improves stability and compatibility. ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
