ZN makes some magical things to make me read } >> I believe that the solution to this problem also includes the } >> solution to programs continuing to produce screen output even when } >> burried. } } > Probably, yes. } } What I mentioned in an older post. If the save areas are kept in their } original specified format (2BPP, 4BPP, 8BPP, etc) in RAM, and the } application always writes to the save area and in addition to that, writes } to the screen only if it is not burried (with translation for current } screen mode) then this solves the problem of the save area size and the } background screen output in one stroke. Sure, at first on would get the } 'updated' version of a window only once it gets on the top of the job } stack, but that's certainly already a big improvement.
This might be the second step, but I would now push to let Marcel make first the first step he wanted to do. His first step is the more appealing, because it would make a real visual difference. Non-blocking Output for program is not so visual, and I'm still too much used to it... it might be a good second step, nevertheless. } PS: about the 36 character limit. I know that many have argued this is } hardly a burning problem, and for a system where all the software ever } produced fits on an obsolete hard drve, that may largely be true. But we } are talking about serious networking in the near future. Keep in mind that } the trick to solving burning problems is to solve them before they become } burning problems. This one may not be the open flame variety, but the } ambers are being felt under the feet... I really believe that this could be addressed with a new filesystem (Please avoid the kludge of M$: adding fields into previously unused part). Moreover, starting from nothing allow to get ride of compatibility and have things like real directory and symbolic links (if the designer want them...). The traps handling names (device and filename) might need to be checked/updated for the supported length of the string, but there might not be such a big problem, because when using the old network, it has no known problem expanding the path name with N5_. At most, existing application expected only 36 chars for filename might get broken, but the only one I want would be QPAC2 files. (Hint: produce a new version of it which would support long name and I'm happy!) For portability sack, the new filesystem should NOT be supported by floppy or MDV or actual Ramdisk. When copying from hard disk to something else a long filename, the user should specify the new name (automatic removal of the 'directory part' might be difficult to implement, or not...). PS: and Yes, more than 4 partitions are needed (so aligning on some fdisk standard might also be a good thing).
