tim@hoptoad.uucp (Tim Maroney) (05/03/90)
>Comments to some of the points raised in <11248@hoptoad.uucp> by >tim@hoptoad.uucp (Tim Maroney): >"In a better OS design, [application data structures such as the window >list] would not be visible to applications as data structures, >just as descriptors in a system-maintained table, and this would make >it easy to prevent application corruption." In article <363.263c55dd@waikato.ac.nz> ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >This has already been done--look at Windows, and OS/2 with Presentation >Mismanager. You have to reference all the important data structures >via 16-bit values called "handles". I don't have any experience to >back this up, but I suspect this requirement that the OS do all the >memory allocation for graphical data structures for you is one reason >why Windows is such a dog in performance terms. QuickDraw gives the >application much more direct control over things like where GrafPorts >and bitmaps come from. I don't see why it should make a difference. The amount of time needed to allocate, say, a WindowRecord is far beneath the human threshold of perception, unless the heap is nearly full and fragmented. And this is a one-time, lead-off overhead that does not continue to affect the operation of the window after allocation. As for bitmaps, what are you recommending -- that they be kept in application globals? You'll hit the size limits pretty fast! And again, heap allocation is not all that slow, and only once. There is a bit of overhead for table lookup to get the data structure address, but it's pretty small even if you do it a thousand times. I think the reasons for OS/2 and Windows dogginess have to be found elsewhere. In any case, information hiding has so many benefits that they easily justify a minor performance hit. Which would you rather have -- a fractionally slower system with memory protection, or an almost imperceptibly faster system where one application can crash all the others and developers are slowed down by frequent system crashes during development? >"Or you could look in your 68000 manual and note that MOVE SR,<ea> is not >a privileged instruction. Only MOVE <ea>,SR is privileged; you can read >the status register in any mode." >Or you could look in your 68000/010/012 manual and note that MOVE SR, <ea> >*is* a privileged instruction on the 68010 and higher-numbered processors. >It all has to do with supporting virtual machines; you can't even let >user-mode code find out that it *is* in user mode, if it is in fact >a "guest" OS which has to run in supervisor mode. Yes, but the consensus is that on other processors, the privilege violation exception should be mapped into an access to the virtual SR, so that it continues to look unprivileged and compatibility is maintained with 68000 software. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com If you vote for clowns, you have no right to complain that only clowns make it to the ballot.