tim@hoptoad.uucp (Tim Maroney) (05/17/89)
In article <1838@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >I don't think the probability will change at all under 7.0. There is one >large address space (up to 14 megabytes) and everything lives there. >There is no protection at all. In that case, I think the probability of one application trashing another actually increases in System 7.0. To be useful, virtual memory requires that process sizes be able to increase. Given one large address space, the only way to do this on the Mac is by discontiguous heaps -- that is, when the application heap runs out of memory, a new chunk is added at a discontiguous location in the global address space. So after a few applications grow, their heaps are thoroughly intertwined. One of the more common program errors consists of assuming that heap block is larger than it actually is and writing past the end. In 7.0, that has a good chance of writing into another application's heap instead of simply corrupting one's own heap. Very messy, and it seems like a giant step backwards. >The comment about low memory was simply repreating what was stated at the >Developer's Conference. If protection was done between application heaps >(which it isn't), it would only be a red herring since the system heap and >low memory is shared. The thought was that it was better to come up with >a total solution in some future system, rather than give users a false >sense of confidence. Why wait? Do you want developers to have to upgrade once for System 7.0 and once for System 8.0? Talk about your pissed-off users! -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Now hear a plain fact: Swedenborg has not written one new truth: Now hear another: he has written all the old falshoods. And now hear the reason. He conversed with Angels who are all religious, & conversed not with Devils who all hate religion..." - Blake, "The Marriage of Heaven and Hell"
lsr@Apple.COM (Larry Rosenstein) (05/17/89)
In article <7320@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > another actually increases in System 7.0. To be useful, virtual memory > requires that process sizes be able to increase. Given one large > address space, the only way to do this on the Mac is by discontiguous > heaps -- that is, when the application heap runs out of memory, a new The System 7.0 virtual memory implementation sits under MultiFinder. Everything is the same as it is now, except that MultiFinder thinks it has more RAM to work with. The heaps are all allocated contiguously from the large address space. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
mfi@beach.cis.ufl.edu (Mark Interrante) (05/17/89)
In article <7320@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >..I think the probability of one application trashing >another actually increases in System 7.0. To be useful, virtual memory >requires that process sizes be able to increase. Given one large >address space, the only way to do this on the Mac is by discontiguous >heaps -- that is, when the application heap runs out of memory, a new >chunk is added at a discontiguous location in the global address >space. So after a few applications grow, their heaps are thoroughly >intertwined. One of the more common program errors consists of >assuming that heap block is larger than it actually is and writing past >the end. In 7.0, that has a good chance of writing into another >application's heap instead of simply corrupting one's own heap. >Very messy, and it seems like a giant step backwards. I know very little about the insides of the mac memory manager (i use lisp :) but it seems that if the manager would start applications far enough apart from each other then the odds of a collision would be very low. If the applications were started say 20mb apart then you could still have a large number of active apllications. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
werner@molokai.sw.mcc.com (Werner Uhrig) (05/17/89)
In article <7320@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > In article <1838@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: > >I don't think the probability will change at all under 7.0. There is one > >large address space (up to 14 megabytes) and everything lives there. > >There is no protection at all. > > In that case, I think the probability of one application trashing > another actually increases in System 7.0. To be useful, virtual memory > requires that process sizes be able to increase. Given one large > address space, the only way to do this on the Mac is by discontiguous > heaps -- that is, when the application heap runs out of memory, a new > chunk is added at a discontiguous location in the global address > space. So after a few applications grow, their heaps are thoroughly > intertwined. One of the more common program errors consists of > assuming that heap block is larger than it actually is and writing past > the end. In 7.0, that has a good chance of writing into another > application's heap instead of simply corrupting one's own heap. > Very messy, and it seems like a giant step backwards. I could imagine a virtual memory system split into 2 sections, identical size, and, and processes getting to use only, at most, half the total available space. if a process size needs increasing, it gets swapped from one section into the other section into a contiguous, larger section. All that would be required would be a change of one bit indicating if the process is using the upper half of the virtual memory space or the lower half of the virtual memory space; all the necessary maintenance shuffling can be done as "overhead" of the operating system; heck, who cares with 4 Gig - and I would even welcome it with 14 or 8 Meg ... sure, *REAL* memory protection is nicer, but .... > >The comment about low memory was simply repreating what was stated at the > >Developer's Conference. If protection was done between application heaps > >(which it isn't), it would only be a red herring since the system heap and > >low memory is shared. The thought was that it was better to come up with > >a total solution in some future system, rather than give users a false > >sense of confidence. oh, I look so forward to the "right" sense of confidence inspiring software. That's the one that will REALLY get you! (SDI, anyone?) > Why wait? Do you want developers to have to upgrade once for System 7.0 > and once for System 8.0? Talk about your pissed-off users! because you can either have a virtual system without memory protection now, or wait much longer for new software *AND* hardware. of course, there will always be those "old" machines without hardware memory protection .... -- --------------------------> please send REPLIES to <------------------------ INTERNET: uhrig@mcc.com (if unavailable: werner@rascal.ics.utexas.edu) UUCP: ...<well-connected-site>!milano!werner ALTERNATIVE: werner@astro.as.utexas.edu OR werner@utastro.UUCP
tim@hoptoad.uucp (Tim Maroney) (05/18/89)
In article <1906@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >The System 7.0 virtual memory implementation sits under MultiFinder. >Everything is the same as it is now, except that MultiFinder thinks it has >more RAM to work with. The heaps are all allocated contiguously from the >large address space. The so-called large address space of 14 megabytes imposed by the unclean ROM, you mean? So processes can't even grow, and you can have a grand total of seven processes each sitting in its own dinky two-megabyte address space? Sheesh. This is sounding sillier and sillier. It seems like this virtual memory only serves one of the many functions usually associated with virtual memory, extending physical RAM. Process memory spaces aren't protected and they can't grow past their initial allocation. Why doesn't Apple just wait until they can do it right? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Do what you wanna, do what you will; Just don't mess up your neighbor's thrill. And when you pay the bill, kindly leave a little tip To help the next poor sucker on his one-way trip." - Frank Zappa, "You Are What You Is"
rubinoff@linc.cis.upenn.edu (Robert Rubinoff) (05/18/89)
In article <7350@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >The so-called large address space of 14 megabytes imposed by the >unclean ROM, you mean? Well, now hold on a second! This is only the limit in 24-bit mode, and it's got nothing to do with the ROM being unclean. 24 bits only gives you a 16 Meg address space, and they need a little room for the OS and related stuff. In 32-bit mode, you get 4 Gigabytes of room, which is plenty (at least for a year or two, until they come out with the 256 Meg RAM chips). Of course, many (most) current applications aren't 32-bit clean, so they will only run in 24-bit mode. But you can hardly blame Apple for that. Even if they had mounted a concerted push from day one to leave the upper bits of addresses alone, people wouldn't have listened. Robert
amanda@intercon.UUCP (Amanda Walker) (05/18/89)
Tim, I'm beginning to wonder what axe you have to grind; you seem to be shooting from the hip more often than usual these days... In article <7350@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > The so-called large address space of 14 megabytes imposed by the > unclean ROM, you mean? So processes can't even grow, and you can have > a grand total of seven processes each sitting in its own dinky > two-megabyte address space? Sheesh. This is sounding sillier and > sillier. OK. I'm looking at the document titled, "Macintosh System Software Release 7.0 Virtual Memory Preliminary Developer Note." It was part of the System 7.0 binder collection that was given out at the Developer Conference. Nothing said about a discontigous virtual address space, two-megabyte limits, or anything else. The only limitation mentioned is that on a system using 24 bit addressing, such as a Mac II, you can have a maximum of 14 megabytes, minus one for each occupied slot. Not bad for a backward-compatible system. Between your posting and a previous one about an "8 megabyte" limit, I wonder if you understand virtual memory and the Mac II architecture. Wake up and pay attention: The current ROMs, while not 32-bit clean, *are* position-independent. They don't have to be mapped in at their (unmapped) physical address. The same is true of the I/O space on NuBus cards. There's *nothing* to prevent Apple from mapping the ROMs and occupied slots as high in the 16-megabyte space allowed by 24-bit addressing as they will go, leaving the rest to act as RAM space. All existing drivers, ROMs, etc. still work fine, since nothing is based on absloute physical addresses. Sure seems like a simple, useful way to do it between now and the time that the ROMs (and all those applications) can handle a 32-bit clean environment... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation -- Usenet: where people who should know better prove that they don't.
paul@taniwha.UUCP (Paul Campbell) (05/19/89)
In article <7350@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >The so-called large address space of 14 megabytes imposed by the >unclean ROM, you mean? So processes can't even grow, and you can have >a grand total of seven processes each sitting in its own dinky >two-megabyte address space? Sheesh. This is sounding sillier and I think that people are forgetting the 7.0 runs in 2 modes 24-bit and 32-bit the above restrictions only apply to 24-bit mode. Why wont everyone run 32-bit? Because initially many applications wont be 32-bit clean. You can bet that as soon as 7.0 comes out everyone will be screaming at their software suppliers that they can't run large VM because of their particular application. By the time 32-bit becomes standard no one will have any excuses .... Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
tim@hoptoad.uucp (Tim Maroney) (05/19/89)
In article <364@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >I think that people are forgetting the 7.0 runs in 2 modes 24-bit >and 32-bit the above restrictions only apply to 24-bit mode. Sure, as long as you don't make any ROM calls, feel free to run in 32-bit mode. Seems the ROMs that are out there won't handle it, and so far Apple has not said that they will be providing a RAM-based OS to get around this. >Why wont everyone run 32-bit? Because initially many applications wont >be 32-bit clean. You can bet that as soon as 7.0 comes out everyone will be >screaming at their software suppliers that they can't run large VM >because of their particular application. By the time 32-bit becomes standard >no one will have any excuses .... Including Apple. Until they either provide a cheap ROM upgrade or switch System 7.0 to RAM-based operation (which ought to be plenty fast enough with a decent hard disk to boot from) no one will be able to run in 32-bit mode. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Mere opinion without supporting argument is no more than the American Bandstand school of literary evaluation." -- Tom Maddox
amanda@intercon.UUCP (Amanda Walker) (05/19/89)
AAAAARGH! In article <7357@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > Sure, as long as you don't make any ROM calls, feel free to run in > 32-bit mode. Seems the ROMs that are out there won't handle it, ... Horse puckey. Parts of the Memory Manager are not 32-bit clean, but most of the ROM is. Think about A/UX. It's a 32-bit environment, and you can call the ROM all you like (the major differences are with the File Manager, since it has to map everything to UNIX file system calls). The parts of the memory manager that need to be changed for 32-bit mode can be handled by a patch resource (like styled TextEdit, the Script Manager, and so on). Repeat after me: 24-bit mode is there so applications don't break, not so the ROMs won't break. Things like Excel, which has a hard enough time with 24 bits :-). Have you ever actually used a 32-bit clean system (either A/UX or the 32-bit clean version of System 6.mumble that developers can get)? Have you ever actually checked the docs (or talked to people at Apple) to make sure you have you facts straight? It sure doesn't sound like it to me. On the other hand, I haven't been this entertained by misinformation in quite some time... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation -- This posting is my opinion, not my employer's, even if the two do happen to coincide.
paul@taniwha.UUCP (Paul Campbell) (05/20/89)
>OK. I'm looking at the document titled, "Macintosh System Software >Release 7.0 Virtual Memory Preliminary Developer Note." It was part >of the System 7.0 binder collection that was given out at the Developer >Conference. two things .... - I realise that the developer's conference was fairly public but was the information given out there (and in these documents) public .... ie am I allowed to talk about it here - will I upset the source so that they wont feed it to me in the future. Did we get it under non-discolsure? Anyone at Apple care to comment?? - Apple went to great trouble to point out that ALL of this information is preliminary and that any or all of it may change before release so remember anything we talk about may not eventually turn up in released code Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
phil@Apple.COM (Phil Ronzone) (05/20/89)
In article <7357@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <364@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >>I think that people are forgetting the 7.0 runs in 2 modes 24-bit >>and 32-bit the above restrictions only apply to 24-bit mode. > >Sure, as long as you don't make any ROM calls, feel free to run in >32-bit mode. Seems the ROMs that are out there won't handle it, and so >far Apple has not said that they will be providing a RAM-based OS to >get around this. Tim, Paul is correct. A/UX uses the exact same ROM as the Mac OS. And boy, does it run in 32-bit mode. Stacks, heaps, the video RAM, the mapped in address of the ROM, they are all over the place (i..e, not just in the first 16MB of address space). I.e., even now the ROMs are dealing with a 32-bit world. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
amanda@intercon.UUCP (Amanda Walker) (05/20/89)
In article <365@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes: > - I realise that the developer's conference was fairly public > but was the information given out there (and in these documents) > public .... ie am I allowed to talk about it here ... Well, some of the notes are marked "Apple Confifential," and some aren't. I made sure the VM section wasn't marked "Confidential" before I mentioned it... > - Apple went to great trouble to point out that ALL of this information > is preliminary and that any or all of it may change before release Indeed. My main point was that reasoning from preconceptions about "how Apple would do it" (as Tim was evidently doing :-)) doesn't jive with what Apple has actually said. While all of the information is preliminary, it does lay out a pretty clear description of the territory, anyway... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation -- This posting is my opinion, not my employer's, even if the two do happen to coincide.
tim@hoptoad.uucp (Tim Maroney) (05/21/89)
In article <31132@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >Tim, Paul is correct. A/UX uses the exact same ROM as the Mac OS. And boy, >does it run in 32-bit mode. Stacks, heaps, the video RAM, the mapped in >address of the ROM, they are all over the place (i..e, not just in the >first 16MB of address space). I.e., even now the ROMs are dealing with >a 32-bit world. Then why does the seventh question and answer under "32-Bit Addressing" in the "Developer Conference Q&A" in the current developer mailing say that a ROM upgrade will likely be required to run in 32-bit mode? Also, do A/UX applications running in 32-bit mode make calls to the various parts of the Toolbox that are needed by MacOS applications, such as the resource manager? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan
paul@taniwha.UUCP (Paul Campbell) (05/22/89)
In article <7383@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Then why does the seventh question and answer under "32-Bit Addressing" >in the "Developer Conference Q&A" in the current developer mailing say >that a ROM upgrade will likely be required to run in 32-bit mode? Also, The only mention I remember of a ROM upgrade was for those people still running on the 64k ROMs .... (oops that includes me :-( Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
tim@hoptoad.uucp (Tim Maroney) (05/22/89)
In article <7383@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Then why does the seventh question and answer under "32-Bit Addressing" >in the "Developer Conference Q&A" in the current developer mailing say >that a ROM upgrade will likely be required to run in 32-bit mode? Also, In article <366@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >The only mention I remember of a ROM upgrade was for those people still running >on the 64k ROMs .... (oops that includes me :-( Eh? The 64K ROM was before the Mac Plus, which introduced the 128K ROM. Machines of this category will always run in 24-bit mode, because they have no MMU capability and no capacity to upgrade memory past 4M (and that only through third-party upgrades; the 64K ROM was also pre-SIMM). If you mean the 128K ROM, I'm still not sure what you mean, since the Mac Plus also will be confined to 24-bit mode for all eternity, as will the Mac SE. This is spelled out in the answer to the eighth question under 32-Bit Addressing in the Developer Conference Q&A. I'm sure the 64K and 128K ROM are both very non-32-bit-clean, but given the RAM and PMMU limits of the computers using them, it doesn't matter. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim If you vote for clowns, you have no right to complain that only clowns make it to the ballot.
amanda@intercon.UUCP (Amanda Walker) (05/22/89)
In article <7383@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > do A/UX applications running in 32-bit mode make calls to the various > parts of the Toolbox that are needed by MacOS applications, such as the > resource manager? Ayup. So do 32-bit clean Macintosh binaries running under A/UX... -- Amanda Walker <amanda@intercon.UUCP> InterCon Systems Corporation -- This posting is my opinion, not my employer's, even if the two do happen to coincide.
paul@taniwha.UUCP (Paul Campbell) (05/22/89)
In article <7392@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Eh? The 64K ROM was before the Mac Plus, which introduced the 128K >ROM. Machines of this category will always run in 24-bit mode, because >they have no MMU capability and no capacity to upgrade memory past 4M >(and that only through third-party upgrades; the 64K ROM was also >pre-SIMM). If you mean the 128K ROM, I'm still not sure what you mean, >since the Mac Plus also will be confined to 24-bit mode for all >eternity, as will the Mac SE. This is spelled out in the answer to the I know this - all I was saying was that the only mention I had heard from Apple about ROMs was that systems with 64K ROMs wouldn't be able to run System 7.0 (not VM just 7.0). I'm sure that there are some 24-bittedness in the current ROMs (or otherwise why would you need a new set at the moment in order to run the 32-bit system with 6.0. Then again maybe they can patch around it ..... since they must have been doing it for a while I'm sure that they have a good handle on it (hopefully one without flags in the top bits :-) Paul -- Paul Campbell Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Achtung! Ve are from ze Interface Police! Ve vant to look und feel!
dwb@sticks.apple.com (David W. Berry) (05/23/89)
In article <367@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >I'm sure that there are some 24-bittedness in the current ROMs (or otherwise >why would you need a new set at the moment in order to run the 32-bit system >with 6.0. Then again maybe they can patch around it ..... since they must >have been doing it for a while I'm sure that they have a good handle on it >(hopefully one without flags in the top bits :-) Actually, the roms in Mac II and later machines are fairly 32-bit clean. A/UX has to make a very few (currently 3 I think :-) exceptions. The primary reason for new roms for 32-bit systems is that the major area of change, the memory manager, has to be present well before the patches, etc. are loaded in. Once you've set up the system heap and pretty much initialized it, it's far too late to go back and change it's format. > > Paul > >-- >Paul Campbell >Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul >Oakland CA AppleLink: D3213 >Achtung! Ve are from ze Interface Police! Ve vant to look und feel! Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry (A/UX Toolbox Engineer) dwb@apple.com 973-5168@408.MaBell AppleLink: berry1
phil@Apple.COM (Phil Ronzone) (05/23/89)
In article <7383@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <31132@apple.Apple.COM> phil@Apple.COM (Phil Ronzone) writes: >>Tim, Paul is correct. A/UX uses the exact same ROM as the Mac OS. And boy, >>does it run in 32-bit mode. Stacks, heaps, the video RAM, the mapped in >>address of the ROM, they are all over the place (i..e, not just in the >>first 16MB of address space). I.e., even now the ROMs are dealing with >>a 32-bit world. > >Then why does the seventh question and answer under "32-Bit Addressing" >in the "Developer Conference Q&A" in the current developer mailing say >that a ROM upgrade will likely be required to run in 32-bit mode? Also, >do A/UX applications running in 32-bit mode make calls to the various >parts of the Toolbox that are needed by MacOS applications, such as the >resource manager? I don't know. A/UX does "patch" and in places replace various pieces of code. (Such as the file manager -- gotta use the UNIX filesystem ...). In general, A/UX can and does make calls to all of the toolbox that makes sense (i..e, not the device manager). Next time I see Rick Daly I'll see if he'll post a more detailed answer. +-----------------------------------------------------------------------------+ |Philip K. Ronzone, Apple Computer, 10440 Bubb Rd, MS 58A, Cupertino, CA 95014| |{amdahl,decwrl,sun,voder,nsc,mtxinu,dual,unisoft,...}!apple!phil | +-----------------------------------------+-----------------------------------+ | All "IMHOs" disclaimed and copyrighted. | Self defense is a human right ... | +-----------------------------------------+-----------------------------------+
tim@hoptoad.uucp (Tim Maroney) (05/23/89)
In article <367@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >I know this - all I was saying was that the only mention I had heard >from Apple about ROMs was that systems with 64K ROMs wouldn't be able >to run System 7.0 (not VM just 7.0). Heard, probably. However, I did give a published reference to what I was talking about -- page 5 of the Developer Conference Q&A document in the current developer mailing, the section on 32-Bit Addressing.... >I'm sure that there are some 24-bittedness in the current ROMs (or otherwise >why would you need a new set at the moment in order to run the 32-bit system >with 6.0. Then again maybe they can patch around it ..... since they must >have been doing it for a while I'm sure that they have a good handle on it >(hopefully one without flags in the top bits :-) That's my hope as well, which is why I referred to a RAM-based OS as one of the ways Apple could avoid a ROM upgrade. My guess, though, is that it would be more than what we usually think of as patching, that is, a routine here and there. Entire managers would likely need replacement. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Its failings notwithstanding, there is much to be said in favor of journalism in that by giving us the opinion of the uneducated, it keeps us in touch with the ignorance of the community." -- Oscar Wilde
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (05/23/89)
With all the postings about whether the ROMs are 32 bit clean, I'd like to
point out that in Tech Note 212 (I think) "The Joy of Being 32 Bit Clean" it
is stated that there is currently no way to write a 32-bit clean CDEF, since
the Control Manager passes the CDEF a handle with the high bit set to indicate
that the CDEF is to return the rgn of its indicator instead of the whole
control. They recommend bypassing the Control Manager entirely if you need
to be absolutely 32-bit clean. That is until they revise the interface.
I don't know if the Control Manager is in ROM or in the System file (probably
some combination) but it could be patched out in any case.
____________________________________________________________________
Have a day. :^|
Murat N. Konar Honeywell Systems & Research Center, Camden, MN
mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)mjohnson@Apple.COM (Mark B. Johnson) (05/24/89)
In article <22437@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes: >With all the postings about whether the ROMs are 32 bit clean, I'd like to >point out that in Tech Note 212 (I think) "The Joy of Being 32 Bit Clean" it >is stated that there is currently no way to write a 32-bit clean CDEF, since >the Control Manager passes the CDEF a handle with the high bit set to indicate >that the CDEF is to return the rgn of its indicator instead of the whole >control. They recommend bypassing the Control Manager entirely if you need >to be absolutely 32-bit clean. That is until they revise the interface. > Look for a revision of this Note which delves into more detail on this topic in the June release of Mac Notes... Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_