From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-068 Date: Thu, 17 Nov 1994 15:39:10 +0100 (MET) C.S.M.P. Digest Thu, 17 Nov 94 Volume 3 : Issue 68 Today's Topics: How do you get the bit depths the main device supports? MIDI programming Memory management in the Real World, part 2 Q: Sound Input Device QC FAQ ResEdit 2.1.3, is it good this time? Shareware, VISA Merchant Accounts, and YOU! Smalltalk implementations for Mac - update needed What is MIDI Manager etc (reply) The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From mxmora@unix.sri.com (Matt Mora) Subject: How do you get the bit depths the main device supports? Date: 31 Oct 1994 11:56:33 -0800 Organization: SRI International, Menlo Park, CA At Init time I would Like to get the number of bit depths the main device can support and make a small Gworld for each of theses bit depths. Is there a call that can tell me what the main device can support? Thanks, Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Tue, 01 Nov 1994 21:44:39 +1200 Organization: AucklandUniversity:ComputerScience:HMU In article <393i5h$fc@unix.sri.com>, mxmora@unix.sri.com (Matt Mora) wrote: > At Init time I would Like to get the number of bit depths the main device > can support and make a small Gworld for each of theses bit depths. Is there a > call that can tell me what the main device can support? Yep, it's a status call to the video (screen) driver. Look in . You use the cscGetMode status call. I'll have to get back to you with some code (Pascal:), tho' "Designing Cards & Drivers" has it all well documented. Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- +++++++++++++++++++++++++++ >From eric.hegstrom@3do.com (Eric Hegstrom) Date: 1 Nov 1994 23:14:24 GMT Organization: 3DO Company In article chris-b@cs.auckland.ac.nz (Chris Burns) writes: > > At Init time I would Like to get the number of bit depths the main device > > can support and make a small Gworld for each of theses bit depths. Is there a > > call that can tell me what the main device can support? > > Yep, it's a status call to the video (screen) driver. > > Look in . You use the cscGetMode status call. I'll have to get Or you can do it by stepping through HasDepth with all the possible bit depths. (Dot overuse the HasDepth function because it has a small memory leak -- $2A bytes per call if I remember correctly). for (bd=1; bd <= someBigNumber; bd *= 2 ) HasDepth( ..., bd, ...); -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -=-=- This in no way represents the opinion of my employer -- or anyone at all for that matter. Eric Hegstrom eric.hegstrom@3do.com -or- theeric@aol.com A very bright programmer -- I'm wearing flourescent underware. +++++++++++++++++++++++++++ >From arose@ATHENA.MIT.EDU (Alex Rosen) Date: 2 Nov 1994 21:35:25 GMT Organization: Massachusetts Institute of Technology Use the HasDepth call, available with System Software 6.0.5 or thereabouts. Check out Tech Note DV10. (You can find it on ftp.apple.com). --Alex --------------------------- >From bemaa@celsiustech.se (Bengt M}nsson) Subject: MIDI programming Date: Tue, 1 Nov 1994 21:31:26 GMT Organization: CelsiusTech AB Hi out there! Being both a hobby musician and a hobby programmer I would like to get hold of some information: a) The specification for MIDI files b) How to write applications for the Apple MIDI Manager (or do I have to go through the troubles getting it from Apple?) c) How to write my own MIDI driver (if at all possible in Pascal) Are these issues covered in any document available via ftp? Bengt M}nsson +++++++++++++++++++++++++++ >From jbeeghly@u.washington.edu (Jeff Beeghly) Date: 1 Nov 1994 23:45:04 GMT Organization: University of Washington >a) The specification for MIDI files I can't help you out too much on this one, but I KNOW I have seen ftp sites on the net which carry a description & breakdown of standard MIDI file formats... I just don't know where... >b) How to write applications for the Apple MIDI Manager (or do I have to go > through the troubles getting it from Apple?) It's probably a best bet to purchase the MIDI developer guide from Apple. At $35, it's not TOO bad. There is one example floating around that might help you out... it's called QwertyTunes and is from someone at Apple Developer Tech Support. ftp to ftp.apple.com... it should be somewhere there. Other than that, I haven't seen any other examples. >c) How to write my own MIDI driver (if at all possible in Pascal) >Are these issues covered in any document available via ftp? Ummm..... I wouldn't do that.... Are you meaning you want to write something that will replase the Apple MIDI Manager? DON'T!!! Use the Apple MIDI Manager. If it's not what you're looking for, check out FREE MIDI (by Opcode, I think). Unless you are planning on writing a MIDI driver for your own use, and never plan on releasing any apps that use your driver, it will be a waste of your time. Jeff --------------------------- >From jbeeghly@u.washington.edu (Jeff Beeghly) Subject: Memory management in the Real World, part 2 Date: 18 Oct 1994 16:46:56 GMT Organization: University of Washington I was speaking with one of my co-workers today about having to deal with handles, MoreMasters, etc... on the Mac. I come from an ANSI-C background and am more comfortable with pointers. I feel somewhat comfortable with handles, but there are lots of "Brick Walls" which I am encountering - like linked lists, and the fact that you need to pre-determine the maximum number of handles the app WILL EVER need at the beginning of the program. He told me that Windows used to be like the Mac (he's a Windows programmer) in terms of memory management: everything needed to be done with handles (because the memory was being moved around) up until Windows 3.1. In 3.1, Windows could be run in what's known as Protected Memory Mode. In Protected Memory Mode, programmers didn't have to worry about handles - they could just use pointers. Yes, memory is still being moved around to compact space, but in PMM, the HARDWARE is handling the memory management. Programmers can just use pointers. The pointer points to a location, and that location is being handled be the hardware (if I understand my friend correctly). If the memory needs to be moved around, the hardware keeps track of everything and the programmer doesn't need to worry about it. My friend (the Windows programmer) said that I should see if the Macs have anything like this. Maybe not the 68000 macs but maybe the 68030 & 68040. He said that the mac chips are really advanced and he would be surprised if they didn't have it (for a Windows programmer, he was very supportive of the Mac). Now, I don't want to start any Windows vs Mac debates, I was just wondering if there is a Mac equivalent of Protected Memory Mode? +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (MARK H. LINTON) Date: 18 Oct 94 17:18:10 EST Organization: HRB Systems, Inc. In article <381538$fsc@dartvax.dartmouth.edu>, Eric Kidd writes: > In article <380u60$lmv@nntp1.u.washington.edu> Jeff Beeghly, > jbeeghly@u.washington.edu writes: >>I was speaking with one of my co-workers today about having to deal with >>handles, MoreMasters, etc... on the Mac. I come from an ANSI-C >>background and am more comfortable with pointers. I feel somewhat >>comfortable with handles, but there are lots of "Brick Walls" which I >>am encountering - like linked lists, and the fact that you need to >>pre-determine the maximum number of handles the app WILL EVER need at >>the beginning of the program. > > [interesting idea re: Windows snipped] > > You don't need to worry about filling your master pointer blocks. New ones > will be automatically allocated by the Memory Manager if you declare more > handles than you had expected when you were making your MoreMasters calls. > > There is a catch, however: these blocks are non-relocatable and will > fragment your heap if they are not allocated at one end or the other. To > avoid this, Mac programs try to guess a "normal maximum # of handles" at > initialization time. This is what you are dealing with, not an absolute > limit. > Eric (and Jeff, hello again ;^), Maybe the mystery surrounding the Handle in the Macintosh world is really the puzzler. Easy way around it? Use NewPtr instead of NewHandle. If all you are trying to do is make a linked list, there is no need to muddy the water with a Handle based solution. Now if you are using a ToolBox call (that was designed to run on a machine that had 128k of RAM) then you may have to use a handle, but you are not required to use them in your own data types. As far as nifty ways to control memory, you really have to get Inside Macintosh: Memory. What are you missing if you don't? o Multiple heaps/heap zones o Temporary Memory - allows you to (temporarily) access more memory than your program is allocated o More complete functions for assessing memory conditions: - FreeMem/FreeMemSys - MaxBlock/MaxBlockSys - PurgeSpace - StackSpace o More complese functions for freeing memory - CompactMem/CompactMemSys - compacts (system) heap - PurgeMem/PurgeMemSys - purges (system) heap - MaxMem/MaxMemSys - compacts and purges (system) heap o Virtual Memory Jeff said he didn't want to start a Mac/Windows flame war, so I won't say what I think of extended memory. -- Hope this helps. Mark H. Linton ____________________________________________________________________ mark \'märk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG marha boundary, L margo] 1 a : a conspicuous object serving as a guide for travelers 2 : A standard or criterion of quality 3 : An object or point that serves as a guide --idiom. mark time. 1 : To make little or no progress +++++++++++++++++++++++++++ >From kevin@dgs.dgsys.com (Kevin Vail) Date: Tue, 18 Oct 1994 18:10:19 -0400 Organization: Vailhalla In article <380u60$lmv@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >I was speaking with one of my co-workers today about having to deal with >handles, MoreMasters, etc... on the Mac. I come from an ANSI-C >background and am more comfortable with pointers. I feel somewhat >comfortable with handles, but there are lots of "Brick Walls" which I >am encountering - like linked lists, and the fact that you need to >pre-determine the maximum number of handles the app WILL EVER need at >the beginning of the program. He told me that Windows used to >be like the Mac (he's a Windows programmer) in terms of memory management: >everything needed to be done with handles (because the memory was being moved >around) up until Windows 3.1. In 3.1, Windows could be run in what's >known as Protected Memory Mode. > >In Protected Memory Mode, programmers didn't have to worry about handles >- they could just use pointers. Yes, memory is still being moved around >to compact space, but in PMM, the HARDWARE is handling the memory management. That's because the underlying hardware (80386 or higher) uses two items to locate any piece of data: a SELECTOR (or "segment") and an OFFSET into the segment. The selector is two bytes, the offset can be two or four. This has always been how memory is accessed on the 80*86 chips, but in non-protected mode the selector part is called the "segment" and indicates a physical memory segment address (a segment can begin at any divisible-by-16 memory address). You take the segment and shift it four bits to the left and add in the offset. This gives you a 20-bit (up to 1 megabyte) address. In protected mode, however, the selector bears no relation to the physical memory address except that the hardware uses it as an index into a table of physical addresses. It takes the beginning of the segment address and adds the offset to that to give the actual memory address. In protected mode, there is a 4 gigabyte (32-bit) address space. Since the actual physical address is only stored in the table that the selector indexes into, the operating system (i.e., Windows) can move the physical location around; the program still uses the same selector to access it. This is not possible on the Mac because the Motorola 680*0 chips use a linear address space with none of this segment/selector garbage. Windows has always used a selector-plus-offset memory model (they refer to the segment part as a "handle"); it used to be that you had to make a Windows call to find the *real* memory address, but now it's the same, because of the way selectors work in protected mode. It has a few advantages in special-purpose cases like Windows memory allocation, but in general it's *much* easier to define and use a linear address space. [snip] >Now, I don't want to start any Windows vs Mac debates, I was just >wondering if there is a Mac equivalent of Protected Memory Mode? The short answer is No, not in the sense you're talking about. (The MMU in the 68030 and 68040 is capable of setting up protected memory regions, but this isn't used in the MacOS.) However, here's a thought, and maybe this is what Apple is doing in Copland-- wouldn't it be possible to set up the memory so that each program had its own address space, with the system heap somehow shared? I don't know what you could do with low-memory globals (perhaps set them up so each program had its own copy, or make them read-only so that writes cause a trap so that changes to the low-memory stuff could be tracked by the OS) and I know there's other stuff, but this would provide memory protection between tasks and give every program a heap the size of the address space; no more trying to guess partition sizes. You'd still have to dereference handles, though... -- Kevin Michael Vail | "This is so cool I have to go to the bathroom!" kevin@dgs.dgsys.com | -- Calvin +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 19 Oct 1994 08:31:31 +0100 Organization: Royal Institute of Something or other In article <380u60$lmv@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >comfortable with handles, but there are lots of "Brick Walls" which I >am encountering - like linked lists, and the fact that you need to Linked lists with handles is just as easy as with pointers. Just remember to store the HANDLE, not the de-referenced pointer. >pre-determine the maximum number of handles the app WILL EVER need at >the beginning of the program. He told me that Windows used to Uh? You should make a good guess, if you're really interested in efficiency. You can just leave it be, in which case the system will allocate onrelocatable master pointer blocks in your heap when needed - depending on how you code, these allocations may or may not cause memory fragmentation. Mostly they don't. >In Protected Memory Mode, programmers didn't have to worry about handles >- they could just use pointers. Yes, memory is still being moved around >to compact space, but in PMM, the HARDWARE is handling the memory management. You can use pointers to your hearts content in the Mac as well. Yes; there may be fragmentation, but that's the case for Windows as well (it just masks the fact) Indeed, fragmenting VM tables is in many cases just as bad as fragmenting "real" memory. Windows handles are NOT the same as Mac handles; Windows memory isn't like Mac memory at all because of their painful segmented architecture. Just go ahead and use malloc()! For as much memory as you want! And don't worry about pointer arithmetics; unlike Windows 3.1, it'll always work. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "I like to do very very late binding. ŒJust in time¹ binding." ‹ Dave Feldt +++++++++++++++++++++++++++ >From bw16@cornell.edu (Bretton Wade) Date: Wed, 19 Oct 1994 08:35:10 -0400 Organization: Cornell Program of Computer Graphics In article , h+@nada.kth.se (Jon W{tte) wrote: > Windows handles are NOT the same as Mac handles; Windows memory > isn't like Mac memory at all because of their painful segmented > architecture. Just go ahead and use malloc()! For as much > memory as you want! And don't worry about pointer arithmetics; > unlike Windows 3.1, it'll always work. It's been a while since I was coding in MS Windows. Do they still have that silly global limit on the number of handles? It was ridiculously low, like 64 or something... ______________________________________________________________ Bretton Wade (bw16@cornell.edu) http://www.graphics.cornell.edu/~bwade/ ______________________________________________________________ +++++++++++++++++++++++++++ >From nick@sw.stratus.com (Nicolas Tamburri) Date: 19 Oct 1994 14:44:59 GMT Organization: Stratus Computer, Inc. In article , kevin@dgs.dgsys.com (Kevin Vail) writes: > > However, here's a thought, and maybe this is what Apple is doing in > Copland-- wouldn't it be possible to set up the memory so that each > program had its own address space, with the system heap somehow shared? I > don't know what you could do with low-memory globals (perhaps set them up > so each program had its own copy, or make them read-only so that writes > cause a trap so that changes to the low-memory stuff could be tracked by > the OS) and I know there's other stuff, but this would provide memory > protection between tasks and give every program a heap the size of the > address space; no more trying to guess partition sizes. I hope this is what they are doing, since this was old technology 20 years ago. I assume that the reason it has not been done yet is because of low memory globals and compatibility with older programs. The way other vendors have solved this problem (and related memory sharing problems,) is 4 fold: 1. You publish a decree that says "Henceforth storing directly into low-memory globals is considered to be a bad programming practice, and we are providing you with this/these OS calls for modifying those globals." 2. If you need to set up shared memory between processes, you must use these OS calls, i.e. don't assume that the same numeric address actually refers to the same physical memory location. 3. Each process on the system gets its own address space, as you state. The low-memory addresses are set up so that reads and writes to them actually trap to the OS, which takes apart the instruction and stuffs the global data into the process space, (or vice-versa.) For most globals, this is sufficient, for some, a global can only be used by one process at a time, and if pre-emptive multi-processing is used, the calling process may actually block until valid data becomes available. This extra processing is much less efficient than accessing globals directly, and thus becomes the incentive to not use them. But, it does provide compatability for older programs that may never be updated, even though they may run slower. 4. Spend a bunch of time shaking out the incompatabilities, since what I've described is greatly simplified. (On the other hand, it's not like I can run every program I've ever bought on my Q650, so maybe they won't worry too much about this last part.) Anxiously awaiting Copeland and Gershwin... /nt +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 19 Oct 1994 18:03:45 GMT Organization: Apple Computer MARK H. LINTON, mhl@icf.hrb.com writes: > Maybe the mystery surrounding the Handle in the Macintosh world > is really the puzzler. Easy way around it? Use NewPtr instead of > NewHandle. Not if you're worried about performance; NewPtr is really slow. A better idea is to use the malloc/free routines in your development system's ANSI library. Generally (at least in THINK and CW) these allocate large blocks via NewPtr and then sub-allocate them, which is a lot more efficient than using the Mac memory manager straight. The drawback is that these blocks are not disposed back to the Mac heap, so you have to make sure that malloc doesn't eat up too much of your memory (you need enough free to keep the Toolbox happy.) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From Lloyd Sargent Date: 21 Oct 1994 15:04:39 GMT Organization: Canna Software Development Re: Memory management in the Real World, part 2 Don't get me started on that "feature" of Windoze. Yes, it is true, Virginia, they do move pointers around without handles. But it is at a cost -- you have to follow some rules about how your data is formated (i.e. you can't have words on 64K boundaries and a host of others that I soon as well forget). It is better? Depends on your point of view. When coding, handles don't slow me down. They are just another data structure. True, it slows the system down moving the handles (and their data) around, but it is just as ugly on the Windoze side. I have to admit, that one feature of Windoze saved my butt (we had to build a 2 mb structure in order to get the speed required for a customer - if we had used Windoze handles it would have meant re- writing large chunks of s/w in a couple of days. It really boils down to methodology. And that is about a touchy subject as religion and politics! Cheerio, Lloyd - -------------------------------------------------------------------- Lloyd Sargent | "{The mice} are merely the protrusions into Canna Software Development | our dimension of vast hyper-intelligent pan- Del Valle, Texas | dimensional beings, thw whole business with Infobahn: canna@bga.com | cheese and squeaking is just a front" AppleLink: CANNA.SW.DEV | Hitchhikers Guide To The Galaxy Voice: 512.243.0283 | "nam et ipsa scientia potestas est" 512.243.3355 | {for knowledge too is itself power} "Been there, done that." | Francis Bacon +++++++++++++++++++++++++++ >From Glenn L. Austin Date: Fri, 21 Oct 1994 18:39:15 GMT Organization: Eugene FreeNet In article <1994Oct19.180345.10342@gallant.apple.com> Jens Alfke, jens_alfke@powertalk.apple.com writes: >Not if you're worried about performance; NewPtr is really slow. A better idea >is to use the malloc/free routines in your development system's ANSI library. >Generally (at least in THINK and CW) these allocate large blocks via NewPtr >and then sub-allocate them, which is a lot more efficient than using the Mac >memory manager straight. The drawback is that these blocks are not disposed >back to the Mac heap, so you have to make sure that malloc doesn't eat up too >much of your memory (you need enough free to keep the Toolbox happy.) DON'T USE malloc/free!!! Although they do sub-allocate, they still call NewPtr, and if you think you'll get better performance calling something that calls NewPtr, you need to check your logic circuits. Use NewPtr and DisposPtr, or better yet, design your own malloc/realloc/free using locked, dereferenced handles. This way you can control your memory usage and still have the resizable objects that true pointers don't provide (there is a SetPtrSize, but that's a crash waiting to happen, since it doesn't work exactly like realloc but attempts to resize the memory block in place, while SetHandleSize is allowed to move the unlocked block of memory to satisfy the request). The only time to use true malloc/free is under Windows, since that brain-dead operating system only allows for 8192 total global handles, and the only way to handle large amounts of data is to use the dev. environment's large model (or huge model) and let it allocate and suballocate memory for you. // // Glenn L. Austin // Computer Wizard and Racing Car Driver // Internet: glenn_a@efn.org // +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sun, 23 Oct 1994 16:51:17 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) chopps@water.emich.edu (Christian E. Hopps) writes: >An MMU is not setup to handle application based resizing mostly. >I'me not sure if you've had experiance with MMU's before or not. However >MMU's do not map just any logical address to just any physical one (in >most cases.) The 680x0 MMU's and the PPC MMU's map pages (4k or 8k mostly). Interestingly, Intel 386 machines and up have MMUs that are designed to manage lots of segments, with sizes ranging from a few bytes to many megabytes. The bounds of the segment are expressed in bytes, not pages, until the segment gets really big, and then it has to be rounded up to the next chunk (512 bytes?). Because DOS/Windows doesn't fully use these capabilities, they aren't well known. But the CPU architecture is almost ideal for a system with lots of little protected objects. The PenPoint prototype used it quite successfully, before AT&T bought it and made them switch to another CPU. John Nagle +++++++++++++++++++++++++++ >From devon_hubbard@taligent.com (Devon Hubbard) Date: Tue, 18 Oct 1994 21:21:15 GMT Organization: Taligent, Inc. In article <380u60$lmv@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >Now, I don't want to start any Windows vs Mac debates, I was just >wondering if there is a Mac equivalent of Protected Memory Mode? Not currently, no. :-] dEVoN - ----------------------------------------------------------------------- Devon Hubbard Silicon Pilot devon_hubbard@taligent.com Taligent, Inc +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Wed, 19 Oct 1994 01:20:02 GMT Organization: Taligent, Inc. In article <1994Oct18.171810.22120@hrbicf>, mhl@icf.hrb.com (MARK H. LINTON) wrote: > is really the puzzler. Easy way around it? Use NewPtr instead of > NewHandle. If all you are trying to do is make a linked list, NewPtr is very slow because it tries to place the pointer as low in the heap as possible. You may be better doing NewHandle and immediatly locking the handle. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com +++++++++++++++++++++++++++ >From Rick_Holzgrafe@taligent.com (Rick Holzgrafe) Date: Wed, 19 Oct 1994 03:21:41 GMT Organization: Semicolon Software In article <380u60$lmv@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > the fact that you need to > pre-determine the maximum number of handles the app WILL EVER need at > the beginning of the program. Well, you don't *need* to. The Mac will allocate more master pointer blocks for you as and when needed. But you do *want* to, because master pointer blocks are themselves locked. The system will spend time trying to move unlocked handles around in order to place the master pointer block near one end of your heap, to avoid fragmentation; and if it can't manage it, then you get fragmentation anyway. -- Rick Holzgrafe, a member of the Taligentsia Rick_Holzgrafe@taligent.com rmh@taligent.com +++++++++++++++++++++++++++ >From edevinney@aol.com (EDevinney) Date: 24 Oct 1994 16:11:04 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , nagle@netcom.com (John Nagle) writes: >>> Interestingly, Intel 386 machines and up have MMUs that are designed to manage lots of segments, with sizes ranging from a few bytes to many megabytes. The bounds of the segment are expressed in bytes, not pages, until the segment gets really big, and then it has to be rounded up to the next chunk (512 bytes?). Because DOS/Windows doesn't fully use these capabilities, they aren't well known. But the CPU architecture is almost ideal for a system with lots of little protected objects. The PenPoint prototype used it quite successfully, before AT&T bought it and made them switch to another CPU. <<< The PenPoint memory manager used 4k pages throughout. One could create new heaps for variable-sized data, and that was nice, but those also used 4k pages - you wouldn't use a heap like a handle if you gave any thought about overhead. It would be nice to use the MMU to get a protected, never-fragmenting soup of variable-sized objects, but PenPoint didn't have it. Regardless, PenPoint did show me that while VM is nice, it is by no means the panacea that handle-opponents often make it out to be. Real RAM does eventually run out, and it runs out quick on small (ie commonplace) machines. Performance takes a big hit when thrashing, and users find that unacceptable, and it can kill battery life on mobile machines. Like handles, VM should be used with care and a full understanding of the costs involved. regards - ed devinney (GO & EO alumnus) +++++++++++++++++++++++++++ >From Peter_Gontier@novell.com (Pete Gontier) Date: Mon, 24 Oct 1994 19:30:56 -0800 Organization: Novell, Inc., Walnut Creek Macintosh Site In article , bw16@cornell.edu (Bretton Wade) wrote: >> It's been a while since I was coding in MS Windows. Do they still have > that silly global limit on the number of handles? It was ridiculously low, > like 64 or something... 8192. Yes, ridiculously low, if you use those blocks for general managment and don't break them up internally to your program. I believe their 32-bit environments lift the restriction, though. -- Views expressed here do not necessarily reflect the views of Novell. +++++++++++++++++++++++++++ >From Peter_Gontier@novell.com (Pete Gontier) Date: Mon, 24 Oct 1994 19:34:53 -0800 Organization: Novell, Inc., Walnut Creek Macintosh Site In article , Glenn L. Austin wrote: > DON'T USE malloc/free!!! Although they do sub-allocate, they still call > NewPtr, and if you think you'll get better performance calling something > that calls NewPtr, you need to check your logic circuits. Do some benchmarking, Glenn. They really are faster. They call NewPtr only for blocks above a certain size and when a block which has been sub-allocated fills up. -- Views expressed here do not necessarily reflect the views of Novell. +++++++++++++++++++++++++++ >From tnelson@fluorite.telesciences.com (Tracy M Nelson) Date: 25 Oct 1994 17:04:19 GMT Organization: Securicor Telesciences Inc John Nagle (nagle@netcom.com) wrote: : Interestingly, Intel 386 machines and up have MMUs that are designed to : manage lots of segments, with sizes ranging from a few bytes to many Not surprising, since they copied many of the design elements of the iAPX432 processor, which relied on the concept of "capabilities" (a sort of an address + access permission structure, which maps nicely into a two-register data access scheme) to manage their objects. I don't know anything about the specifics of the '386 MMU, but it's possible that, given a proper object-oriented OS and development environment, the x86 architecture could be handy after all... -- Tracy Nelson (tnelson@telesciences.com) // WARNING: May contain code which is too intense for young programmers... +++++++++++++++++++++++++++ >From ajbarry@ozemail.com.au (Andrew Barry) Date: Thu, 27 Oct 1994 08:33:20 GMT Organization: OzEmail Pty Ltd Sydney Australia Tracy M Nelson (tnelson@fluorite.telesciences.com) wrote: : John Nagle (nagle@netcom.com) wrote: : : Interestingly, Intel 386 machines and up have MMUs that are designed to : : manage lots of segments, with sizes ranging from a few bytes to many : Not surprising, since they copied many of the design elements of the : iAPX432 processor, which relied on the concept of "capabilities" : (a sort of an address + access permission structure, which maps : nicely into a two-register data access scheme) to manage their : objects. I don't know anything about the : specifics of the '386 MMU, but it's possible that, given a proper : object-oriented OS and development environment, the x86 : architecture could be handy after all... Hmmm...the main problem with the 386 MMU (at least as far as selectors go), is that there are only 8192 selectors available in each of the local and global descriptor tables. Unfortunately, this would mean a maximum of 8192 objects per process (or in the case of Windows, 8192 handles in use across the entire system). Just as some further information, 386 handles have a granularity of 16 bytes, unless you want to address memory beyond 16Mb, at which point the granularity goes up to 4k. Also note that Microsoft is ditching the use of selectors as handles in Chicago and NT, where they're using a flat address space. Just a bit of input...personally I don't think the 386 architecture can be useful. Andrew +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: 28 Oct 1994 07:35:59 GMT Organization: Computer Science Dept, U of Witwatersrand In article , stevew@teleride.on.ca (Stephen M. Webb) wrote: > Virtual memory became possible only with the 68020, which was not in Wasn't it the 68010 that added VM support? Some managed to find complex hardware workarounds, like second processor to handle page faults. > production at the time the Mac was released. Handles were required to > support a pseudo-virtual memory scheme under which regions of memory > could be relocated during a system call if necessary, and without > notice, at run time. Such a scheme does not require restartable instructions. I don't think this is sufficient reason to introduce handles. Other systems had things like overlays (clumsy but easier to program). I think the real reason for overlays was system calls and user program were allocating sometimes short-lived data (e.g. for menus) in the same small heap. With so little RAM to play with a conventional memory manager would have had problems coping. Things like puregeable resources help, but could work without handles if there is enough free RAM to run a conventional memory manager (with free list, coalescing adjacent blocks etc.). The Lisa - which initially was sold with much more RAM than a Mac - had a more sophisticated memory management scheme. Does anyone know details? -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa (at University of Cape Town 4 July-7 Nov) phone 27(11)716-3309 fax 27(11)339-7965 +++++++++++++++++++++++++++ >From pcastine@prz.tu-berlin.de (Peter Castine) Date: Fri, 28 Oct 1994 12:13:55 GMT Organization: Process Control Center In article , (Stephen M. Webb) wrote: > > Virtual memory became possible only with the 68020, which was not in > > production at the time the Mac was released. In response, in article , philip@cs.wits.ac.za (Philip Machanick) wrote: > The Lisa - which initially was sold with much more RAM than a Mac - had a > more sophisticated memory management scheme. Does anyone know details? Lisa had a PMMU and (I'm 99% sure of this) memory protection. I'm not sure about virtual memory (the first Lisas were diskette-based, but later models had external hard disks). Philip also said: > I don't think this is sufficient reason to introduce handles. Other > systems had things like overlays (clumsy but easier to program). I think > the real reason for overlays was system calls and user program were > allocating sometimes short-lived data (e.g. for menus) in the same small > heap. With so little RAM to play with a conventional memory manager would > have had problems coping. Things like puregeable resources help, but could > work without handles if there is enough free RAM to run a conventional > memory manager (with free list, coalescing adjacent blocks etc.). Menus should never be purgeable. But windows (particularly Dialogs and Alerts) come and go and chew up memory. Ditto for fonts. Overlays *are* clumsy, require a lot of attention on the part of the applications programmer (IMO, more work than the occaisional _HLock/_HUnlock call), and are usually used for swapping sections of program code (and, hence, don't help with memory requirements of windows, etc.). -- Peter Castine | Useful approximations: pcastine@prz.tu-berlin.de | Pi seconds is a nanocentury. Process Control Center | Electricity travels a foot per nanosecond. Technical University Berlin | One ostrich egg will feed 24 people for brunch. +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) Date: Fri, 28 Oct 1994 12:54:47 GMT Organization: DCRT, NIH, Bethesda, MD In article , philip@cs.wits.ac.za (Philip Machanick) writes: >In article , stevew@teleride.on.ca (Stephen M. >Webb) wrote: >> Virtual memory became possible only with the 68020, which was not in >> production at the time the Mac was released. Handles were required to >> support a pseudo-virtual memory scheme under which regions of memory >> could be relocated during a system call if necessary, and without >> notice, at run time. Such a scheme does not require restartable >> instructions. > >I don't think this is sufficient reason to introduce handles. Other >systems had things like overlays (clumsy but easier to program). I think >the real reason for overlays was system calls and user program were >allocating sometimes short-lived data (e.g. for menus) in the same small >heap. With so little RAM to play with a conventional memory manager would >have had problems coping. Things like puregeable resources help, but could >work without handles if there is enough free RAM to run a conventional >memory manager (with free list, coalescing adjacent blocks etc.). Overlays are only for code, most times. The CODE segment structure of the Mac's runtime environment is far superior, IMHO. What people are talking about here is using the PMMU to move stuff around in physical memory without changing its logical addressing, transparently to the application. Basically, the reason the Mac doesn't do this is that the MC68000 doesn't have any hardware memory-management; handles were a way to give the OS *some* way of making room for new allocations in a fragmented heap. >The Lisa - which initially was sold with much more RAM than a Mac - had a >more sophisticated memory management scheme. Does anyone know details? The Lisa was an amazingly advanced machine for its day. It *did* have hardware memory management, and preemptive multitasking. It achieved this through custom hardware to supplement the 68000 (which, as I said, didn't offer any of this functionality itself). This is part of what made the Lisa so expensive, unfortunately; it was too much technology for the niche it needed to occupy. - ------------------------------------------------------------------ Christopher T{te | "I never thought of surgery as 'editing fixer@faxcsl.dcrt.nih.gov | a person' before...." eWorld: cTate | -- Mark Linton (mhl@icf.hrb.com) +++++++++++++++++++++++++++ >From "Donald T. Major" Date: Fri, 28 Oct 1994 15:11:05 GMT Organization: SAS Institute Inc. Handles, and the Lisa memory management, etc., all came from the work achieved with Smalltalk-80. Handles are a direct descendant of the object table of Smalltalk, just implemented in a more flexible manner. Sure, in Smalltalk object references were offsets in the object table, and the only "real" pointers the system used were the result of resolving such a reference, but the basic idea was there (it may even be older than that--I honestly don't know). The really neat part about the Smalltalk model, though, was that it allowed for a very flexible virtual memory scheme, where disk I/O was even more of a major system expense than it is today. LOOM and another similar scheme, the name of which escapes me at the moment, were virtual memory systems implemented for Smalltalk, to allow moving only the minimum amount of data to and from disk as necessary. Implemented entirely in software, they could make use of ridiculously small chunks of memory (since most objects were ridiculously small) to load an object from disk, while keeping as many current system objects loaded as possible, and cutting back on the total amount of RAM lost to pad bytes. Since RAM in the original Smalltalk-80 implementation couldn't exceed 2 meg, this was a very desirable goal. This flexibility is why handles were used in the Mac from day one (and I believe in the Lisa, though I can't swear to it)--the original Mac only had 128k of ram, of which only about 80k was available to applications; even the Finder was an application which was just run when no other applications were loaded. The virtual memory scheme was also adapted, though only for loading stuff in, not writing data back out (CODE resources, MDEFs, etc., are all based on this scheme). It's true that the original reasons for handles are gone, but that doesn't mean that their usefulness is; I personally rarely find using handles that much of a hassle, while heap fragmentation can be very irritating, and often means I need more RAM for my heap. *Maybe* when we finally get virtual addressing I'll feel differently (note, this is NOT virtual memory), but for now, I like the Handle. +++++++++++++++++++++++++++ >From Jonathan Gary Date: Thu, 3 Nov 1994 17:55:02 GMT Organization: Eastman Kodak > Message-ID: In article Stephen M. Webb, stevew@teleride.on.ca writes: > Virtual memory became possible only with the 68020, which was not in > production at the time the Mac was released. This is mostly correct, as the 68010 also supports interruptable instructions which allow mid-instruction page faults. With all the addressing modes of the 68K, a single instruction can cause a large number (I think as many as 17) page faults. +++++++++++++++++++++++++++ >From pgontier@novell.com (Pete Gontier) Date: Mon, 07 Nov 1994 10:12:50 -0700 Organization: Novell, Inc., Walnut Creek Macintosh Client Site In article , Jonathan Gary wrote: > In article Stephen M. Webb, > stevew@teleride.on.ca writes: > > > Virtual memory became possible only with the 68020, which was not in > > production at the time the Mac was released. > > This is mostly correct, as the 68010 also supports interruptable > instructions which allow mid-instruction page faults. Not really. There were several UNIX systems which handled virtual memory page faults on a regular old 68000 by handing control to their *second* 68000 ... -- Views expressed here do not necessarily reflect those of my employer. +++++++++++++++++++++++++++ >From lsr@taligent.com (Larry Rosenstein) Date: Thu, 3 Nov 1994 22:11:13 GMT Organization: Taligent, Inc. In article , philip@cs.wits.ac.za (Philip Machanick) wrote: > The Lisa - which initially was sold with much more RAM than a Mac - had a > more sophisticated memory management scheme. Does anyone know details? The Lisa supported segmented virtual memory and protected address spaces, but it still used handles. (BTW, I believe it had a custom MMU.) The main reason was that data segments could not be automatically paged in and out, because the 68000 CPU didn't support restarting instructions on a fault. (68000 machines that did support full demand paging like the early Apollos used 2 CPUs, one of which was dedicated to loading pages from the disk.) The Lisa did support demand paging of code segments and automatic stack expansion. This was possible because there were a limited set of instructions used to access code segments, and the OS group figured out how to restart those instructions. Similarly for the stack segment, the compiler generated a TST instruction at function entry to touch the maximum stack address needed in the function. The OS knew how to restart that instruction as well. Handles are useful in an environment with a fixed sized data space where heap blocks of varying size are allocated and deallocated relatively frequently. -- Larry Rosenstein Taligent, Inc. lsr@taligent.com --------------------------- >From gg110@cus.cam.ac.uk (G. Gavazzi) Subject: Q: Sound Input Device Date: 1 Nov 1994 01:36:02 GMT Organization: University of Cambridge, England Hi everybody, I need some help, sorry for the naive question: I am using: Handle rate; SPBGetDeviceInfo(myInRefNum,siSampleRateAvailable,*rate); to determine the available sampling rate of the sound device input. Now the Inside Mac VI tells that this function returns an Integer and a Handle (list of sample rates of type Fixed). I think then that *rate points to a 4 bytes int, the next 4 bytes Fixed being allocated for the first sample rate and so on. Besides the fact that I do not know what kind of type is Fixed (fixed point? not standard C certainly) I cannot get a sensible result out of this :( Also my SPBRecordToFile(out_file,&myinParam,FALSE) does not fill my out_file, I think because the sampling rate is 0. And I cannot set the sampling rate with SPBSetDeviceInfo() 'cause I get bad sampling rate error (-225). (btw: I am using the wonderful CW4 :) Can somebody point me to some example source code (I should be able to ftp a develop issue if necessary)? Thank you. Giuliano Gavazzi +++++++++++++++++++++++++++ >From chris-b@cs.auckland.ac.nz (Chris Burns) Date: Tue, 01 Nov 1994 21:33:16 +1200 Organization: AucklandUniversity:ComputerScience:HMU In article <394622$jri@lyra.csx.cam.ac.uk>, gg110@cus.cam.ac.uk (G. Gavazzi) wrote: > to determine the available sampling rate of the sound device input. Now > the Inside Mac VI tells that this function returns an Integer and a Handle > (list of sample rates of type Fixed). I think then that *rate points to a > 4 bytes int, the next 4 bytes Fixed being allocated for the first sample > rate and so on. Besides the fact that I do not know what kind of type is > Fixed (fixed point? not standard C certainly) I cannot get a sensible > result out of this :( ///////////////////////////////////////////////////////////////////////// // Include appropriate header files #include #include ///////////////////////////////////////////////////////////////////////// // Set up types to access a handle to an array of Fixed typedef Fixed RateList[]; typedef RateList **RateListHandle; ///////////////////////////////////////////////////////////////////////// // Define a structure according to IM6 22-67 'srav' struct{ short count; RateListHandle rates; }SampleRates; ///////////////////////////////////////////////////////////////////////// // Get sound input device to fill in the "SampleRates" struct Err = SPBGetDeviceInfo(RefNum,siSampleRateAvailable,(Ptr)&SampleRates); FailOSErr(Err,"\p_SPBGetDeviceInfo[siSampleRateAvailable] FAILED"); ///////////////////////////////////////////////////////////////////////// // For example, pick the highest sampling rate from the ones returned. long MaxLong; long MaxPos; Fixed CurFixed; long CurLong; short i; if (SampleRates.count == 0) SampleRate = (**SampleRates.rates)[2]; else { MaxLong = 0; MaxPos = 0; for (i = 0;i < SampleRates.count;i++) { CurFixed = (**SampleRates.rates)[i]; if (BitTst((Ptr)&CurFixed,0)) { BitClr((Ptr)&CurFixed,0); CurLong = 32768 + Fix2Long(CurFixed); } else CurLong = Fix2Long(CurFixed); if (CurLong >= MaxLong) { MaxLong = CurLong; MaxPos = i; } } SampleRate = (**SampleRates.rates)[MaxPos]; } ///////////////////////////////////////////////////////////////////////// // Set sampling rate Err = SPBSetDeviceInfo(RefNum,siSampleRate,(Ptr)&SampleRate); FailOSErr(Err,"\p_SPBGetDeviceInfo[siSampleRate] FAILED"); Chris B - --------------------------------------------------------------------- NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns Internet: chris-b@cs.auckland.ac.nz Phone: +64 9 373-7599 x6194 Fax: +64 9 373-7453 Async, therefore I am. - --------------------------------------------------------------------- --------------------------- >From Pete Gontier Subject: QC FAQ Date: 1 Nov 1994 08:01:21 GMT Organization: Pete's Proxy Posting, Ink. This is a monthly posting. Changes this month: none. This posting is available via 'ftp': ftp://ftp.dnai.com/users/gurgle/QC_FAQ.txt Poster has no affiliation with Onyx Technology. Please email responses to addresses listed at the bottom of this text. - --------------------- cut here ----------------------- QC(tm) FAQ 0794.2 ================= Q: So what is QC? A: QC is a control panel/extension that adds the ability to stress test applications for runtime, memory related errors. QC can be used during development, during testing by inhouse and beta testers, and after the product ships (although a little late if errors are detected) by end users to evaluate the stability of a software package. Q: Is there a demo available? A: Yes. It is available from most online services as well as Internet sites like sumex. Q: What do I have to do to use the demo? A: Put QC in your Control Panels folder and reboot your Mac. If the demo has expired contact us at one of the online addresses listed above. Q: Can I use QC to test existing applications without rebuilding them? A: Yes. QC was designed to test applications without requiring any modifications to the code. The release version of QC includes an optional application programming interface (QCAPI) that programmers can use to control QC testing directly from their code. Q: How does QC report errors it finds? A: QC reports detected errors through the use of a low level debugger. QC uses the _DebugStr trap to cause a user break into your favorite debugger. QC is fully compatible with MacsBug, TMON, TMON PRO, The Debugger, SourceBug, SADE, THINK C, CodeWarrior, MPW, etc. If you turn off debug breaks in the list of options, QC will emit a short distinctive beep when errors are detected. Q: Does QC work on a Power Macintosh? A: Yes. However, two incompatible tests are disabled if you are using the Modern Memory Manager. Those tests are 'Block Bounds Checking' and 'Invalidate Free Memory'. The next release of QC will be a native PowerPC application and will be available as a free upgrade to existing users. Q: How does QC compare with tools such as Even Better Bus Error and the debugging version of the Modern Memory Manager? A: EBBE is a free utility but one downfall it has is that it's either installed or it isn't. You either get bus errors potentially caused in all running apps or you get nothing. With QC, you can control when testing is active and what apps might potentially crash with a bus error. Everything is unaffected. Although early development versions were available, we are not aware of any debugging version of the Modern Memory Manager being made available by Apple at this time. Early versions of MMM were much slower than QC in comprobable tests and the MMM does not offer as many tests as QC does. There is also no easy to use UI to activate/deactivate MMM testing on an application heap. Q: What are the advantages to using QC? A: QC offers tests that are not available anywhere else and it performs many tests much faster than other testing tools. All QC's tests are integrated into a single INIT/cdev combination. A Macintosh interface makes QC usable right out of the box. QC's API can be used to fine tune testing to specific areas of code (new code or suspect code, for example). QC reports more information when an error is found. Q: What do I get when I purchase QC? A: The following is contained on the release disk. A fully licensed copy of QC for single machine use and complete documentation. The QC Application Programming Interface (QCAPI) libraries and interfaces for those who want to control QC testing directly from their code. Full source code to an application called BadAPPL that illustrates what QC detects as well as how to use the QCAPI. The disk also contains some assorted free utilities. Q: How can I obtain QC? A: Pricing is $99.95 for a single copy, $400 for a five pack, and $700 for a ten pack. Please add $5 shipping and handling to each order. Credit card orders are accepted. You can contact Onyx via the email addresses listed above or by calling 813.795.7801 or faxing 813.795.5901. You can also send regular mail to: Onyx Technology 7811 27 Ave W Bradenton, FL 34209 Our email addresses are: America Online: OnyxTech Internet: onyxtech@aol.com AppleLink: D2238 CompuServe: 70550,1377 QC is a trademark of Onyx Technology Copyright (c) 1994 Onyx Technology --------------------------- >From cazelaig@ERE.UMontreal.CA (Cazelais Gilles) Subject: ResEdit 2.1.3, is it good this time? Date: Wed, 26 Oct 1994 07:26:07 GMT Organization: Universite de Montreal Hello folks, I just want to know if the recent version of ResEdit (2.1.3) is a good version without known bugs, like the nasty one in version 2.1.2. Is anybody having some troubles with 2.1.3? Any problems with it? In brief, can I trust it?? I really want to be sure before using it... Thanks a lot, Martin. +++++++++++++++++++++++++++ >From aatrix@aol.com (Aatrix) Date: 26 Oct 1994 08:20:01 -0400 Organization: America Online, Inc. (1-800-827-6364) In article , cazelaig@ERE.UMontreal.CA (Cazelais Gilles) writes: > I just want to know if the recent version of ResEdit > (2.1.3) is a good version without known bugs, like the nasty one in > version 2.1.2. Is anybody having some troubles with 2.1.3? Any problems > with it? Uh, which nasty bug? The one that tanked a file if you copied a resource over another that was smaller has been fixed. Don't know about some of the others (CNTLs in DLOGs don't display on a Quadra, for one thing). a.d. jensen, Aatrix Software, Inc. aatrix@aol.com "Forty below keeps out the riff-raff." - North Dakota State Motto +++++++++++++++++++++++++++ >From alain@cs.uchicago.edu (Alain Aslag Roy) Date: Wed, 26 Oct 1994 12:57:12 GMT Organization: Department of Computer Science, University of Chicago In article cazelaig@ERE.UMontreal.CA (Cazelais Gilles) writes: > >Hello folks, > I just want to know if the recent version of ResEdit >(2.1.3) is a good version without known bugs, like the nasty one in >version 2.1.2. Is anybody having some troubles with 2.1.3? Any >problems with it? I've had no problems with Resedit 2.1.3, and I use it a fair amount. I did have problems with 2.1.2, so I guess they really did fix those heinous crashes. -alain +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Wed, 26 Oct 1994 11:44:23 -0400 Organization: The Pitt, Chemistry In article , cazelaig@ERE.UMontreal.CA (Cazelais Gilles) wrote: > I just want to know if the recent version of ResEdit > (2.1.3) is a good version without known bugs, like the nasty one in > version 2.1.2. Is anybody having some troubles with 2.1.3? Any > problems with it? > > In brief, can I trust it?? I really want to be sure before using it... What the X-files slogan "Trust no one, backup frequently?" :-) I've been using 2.1.3 for a while now, and had none of the corruption problems that I did with 2.1.2. I seem to remember a post when 2.1.3 was released claiming all reported bugs were dealt with, and that *seems* to be the case. Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From ross@bnr.ca (Ross Brown) Date: Wed, 26 Oct 1994 12:40:49 -0400 Organization: Bell-Northern Research In article , cazelaig@ERE.UMontreal.CA (Cazelais Gilles) wrote: > Hello folks, > I just want to know if the recent version of ResEdit > (2.1.3) is a good version without known bugs, like the nasty one in > version 2.1.2. Is anybody having some troubles with 2.1.3? Any > problems with it? The nasty 2.1.2 bugs are indeed gone. No more file corruption. But... Try this on a Power Mac. It doesn't seem to happen on 68K Macs - odd, since ResEdit runs in full emulation on PPC. I find that this happens even with all extensions (and Modern Memory Manager) off. Copy some resources into the Clipboard. In ResEdit, open a file whose resource fork has no resources of the types represented in the Clipboard, then paste them in. Close the file, and click "No" when asked if you want to save the file. Open the file, and you'll find that the resources *were* added to the file, against your instructions. I sincerely hope that this bug is not traceable to the emulator. -- Ross Brown Macintosh/UNIX Systems Integration Bell-Northern Research Ltd. ross@bnr.ca +++++++++++++++++++++++++++ >From kurisuto@babel.ling.upenn.edu (Sean Crist) Date: 26 Oct 1994 20:14:31 GMT Organization: University of Pennsylvania, Linguistics Department In article , Cazelais Gilles wrote: > >Hello folks, > I just want to know if the recent version of ResEdit >(2.1.3) is a good version without known bugs, like the nasty one in >version 2.1.2. Is anybody having some troubles with 2.1.3? Any >problems with it? > >In brief, can I trust it?? I really want to be sure before using it... There's at least one bug I've come across. Unfortunately I didn't make notes of the specific circumstances, but I remember that I was able to replicate it. It was something in the DITL editor; I think it had to do with resizing CNTL items or something like that. \/ __ __ _\_ --Kurisuto (kurisuto@unagi.cis.upenn.edu) --- | | \ / _| ,| ,| ----- For a free copy of the Bill of Rights, finger _| ,| ,| [_] this account. | | | [_] +++++++++++++++++++++++++++ >From cazelaig@ERE.UMontreal.CA (Cazelais Gilles) Date: Wed, 26 Oct 1994 22:51:30 GMT Organization: Universite de Montreal In article <1994Oct26.125712.3989@midway.uchicago.edu> alain@cs.uchicago.edu (Alain Aslag Roy) writes: >In article cazelaig@ERE.UMontreal.CA (Cazelais Gilles) writes: >> >>Hello folks, >> I just want to know if the recent version of ResEdit >>(2.1.3) is a good version without known bugs, like the nasty one in >>version 2.1.2. Is anybody having some troubles with 2.1.3? Any >>problems with it? > >I've had no problems with Resedit 2.1.3, and I use it a fair amount. I >did have problems with 2.1.2, so I guess they really did fix those >heinous crashes. > >-alain So, do you think it really worth to upgrade it from 2.1.1? +++++++++++++++++++++++++++ >From s.fraser@ic.ac.uk (Simon Fraser) Date: Sat, 29 Oct 94 15:56:35 GMT Organization: Centre for Population Biology In article <38mdb7$f2m@netnews.upenn.edu> Sean Crist, kurisuto@babel.ling.upenn.edu writes: >There's at least one bug I've come across. Unfortunately I didn't make >notes of the specific circumstances, but I remember that I was able to >replicate it. It was something in the DITL editor; I think it had to do >with resizing CNTL items or something like that. Yes, I've had problems here. Create a new CNTL resource, open a DLOG, make a new CNTL item, then double-click to edit it. Just as you finish typing the ID of your new CNTL, ResEdit crashes. I've found that saving the file _before_ opening the DLOG helps. I've also found that sometimes editing resources with templates fails to set the 'window dirty' flag (or whatever tells ResEdit that you've made changes), so ResEdit fails to save changes to the resource. I'm sure there are one or two other things that I've forgotten.... Simon __________________________________________________________________________ Simon Fraser NERC Centre for Population Biology s.fraser@ic.ac.uk Imperial College at Silwood Park Ascot, Berkshire, SL5 7PY. UK +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Mon, 31 Oct 1994 12:14:37 +0800 Organization: NCRPDA, Curtin University ResEdit 2.1.3 is quite useable, but it still has bugs. One that gets me a lot is thast it locks up when you open the DITL editor if there is strange things in the clipboard. This is on a 6100, System 7.5 - it reliably locks up every time if I copy stuff out of SimpleText and then open a dialog window for editing in ResEdit. So I just copy something in ResEdit before editing dialogs. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From Jason.Grossman@ucs.cam.ac.uk (Jason Grossman) Date: Mon, 31 Oct 1994 15:03:50 +0000 Organization: University of Cambridge Peter N Lewis wrote: > ResEdit 2.1.3 is quite useable, but it still has bugs. One that gets me a > lot is thast it locks up when you open the DITL editor if there is strange > things in the clipboard. This is on a 6100, System 7.5 - it reliably > locks up every time if I copy stuff out of SimpleText and then open a > dialog window for editing in ResEdit. So I just copy something in ResEdit > before editing dialogs. > Peter. Ah! It does this to me, too (7100, 7.1), but I'd never realised what the conditions were, so I didn't know the work-around of copying something before opening a DITL. I've been using the alternative work-around of opening the DITL, getting the crash, pressing the emergency reboot button, waiting for the machine to restart, and then opening the DITL again. Jason +++++++++++++++++++++++++++ >From alyx@apple.com (alyx) Date: Thu, 3 Nov 1994 03:46:24 GMT Organization: Apple Computer, Inc. In article , nick+@pitt.edu ( nick.c ) wrote: > [...] I seem to remember > a post when 2.1.3 was released claiming all reported bugs were > dealt with, and that *seems* to be the case. ah, memories. anyone else remember the beloved 4D Tools dialog box: "No problems found. Everything *seems* OK." quite a nasty sense of humor there... alex. --------------------------- >From red.riders Subject: Shareware, VISA Merchant Accounts, and YOU! Date: Thu, 03 Nov 1994 00:27:00 -0500 Organization: DSC/Voicenet - BBS/Unix Shells/SLIP/NEWS - (215)443-7390 Hey homeys, here's some info I had laying around. No more bitching about lost shareware dollars, OK? Increase Your Business by Taking Mastercard and Visa Credit card industry experts report that offering customers the ability to pay with Visa or Mastercard will increase a company's business between 10% and 50%. Whether the increase is closer to 10% or 50% depends on the type of business and its particular clientele. Yet there can few tasks more difficult for a home-based business than obtaining a merchant account. This is because of discrimination against home-based as well as other types of businesses by most banks. Nevertheless, home-based businesses do manage to be able to offer their customers the ability to use their charge cards. There are four basic avenues for securing a merchant account. I. Financial Institutions A. Banks Even though banks as a general rule are not granting home businesses merchant accounts for taking Visa & Mastercard, do try your own bank, particularly since they know you as a customer. If your bank denies you a merchant account, try small independent banks, particularly ones that have their merchant accounts processed by an out-of-state bank instead of doing it themselves or using a larger local bank. Banks in smaller communities are more apt to work with home-based businesses. B. Saving & Loans, Thrifts and Credit Unions Most people think of banks as THE only financial institutions granting merchant accounts to businesses. However, savings & Loans, thrifts and even credit unions are increasingly offering merchant accounts. You may find these institutions more willing to work with you. Remember that banks, in the words of Larry Schwartz and Pearl Sax founders of the National Association of Credit Car Merchants (217 N. Seacrest Boulevard, Box 400, Boynton Beach, Florida 33425; (407) 737-7500), "need reassurance that handling your business will both safe and profitable." It almost goes without saying that your presentation of your business, your financial ability and yourself must make your banker feel absolute confidence in you. II. Business Organizations A. Trade Associations Trade associations sometimes provide access to Visa and Mastercard accounts as a member service. Examples of organizations that may be helpful are the Retail Merchants Association and Direct Marketing Association and others specifically related to your particular industry. To find trade associations in your field, use Gale's Encyclopedia of Associations, available at the reference desk in most libraries. B. Local Business Organizations. Chambers of Commerce and local merchant associations sometimes help their members secure merchant accounts through a bank affiliated with the Chamber or the association. These can be the least costly merchant accounts with discounts as low as 2% to 3% on relatively small volumes. III. Independent Selling Organizations Perhaps the most likely way to get a merchant account is to work through a bank agent or independent sales organization (ISO), which is a company that acts as an intermediary between small businesses and banks. You will undoubtedly pay more using an ISO because these companies derive their income from fees and surcharges added to what you would normally pay if were able to deal directly with a bank. You may be quoted these fees and charges when going through an ISO: o Application fees ranging between $95 to $325. These may or may not be refundable. Usually they are not, but find out under what circumstances all or part of the fee may be refundable. o Point of sale terminal lease or purchase. ISO's typically charge from $425 to $1700 for a terminal if purchased through a bank would cost about $300. Leasing typically runs between $18 and $80 a month. Some ISO's are offering software that can be used in place of a sales terminal, priced as low as $150. o Service fees from 3.5% to 7% compared to 2% to 5% from a bank, though one ISO is quoting fees of 1.99%. This ISO has other charges that tend to make up fo the lower service fee. o Per transaction charge of $.20 to $.25 o Monthly statement fee of $5.00 to $10.00 o Minimum monthly fee Advice about dealing with ISO's. Fees vary considerably among ISO's, so it pays to be a comparison shopper. Read the contract carefully for hidden charges and requirements. You may also be required to use a check verification service provided by the ISO for an additional fee. One final warning. The salespeople for ISO's may be so eager to sign you up that they may inaccurately fill out your applications about items that would not be approved if filled in accurately. The problem is that if a falsehood is detected later by the bank, your merchant account may be terminated and your name placed on a terminated merchant list that bars you from getting another merchant account in the future. Subject that are sometimes filled in include whether the salesperson has personally inspected your premises and the percentage mail order and telephone constitute of your sales. Be sure to check your filled in application for accuracy. Following are independent selling organizations listed in alphabetical order that have told us or have been reported by members of the forum to accept home businesses for merchant accounts (Asterisked entries are posted in this file for the first time): Bancard, Inc. 1233 Sherman Drive Longmont, CO 80501 303/530-0264 800/666-7575 Requires two years in business at the same address. Data Capture Systems 231 Quincy Street Rapid City, SD 57701 605/341-6461 Comes to your home for an on-site interview and charges $25 to send an application plus a $300 application fee. Electronic Bankcard Systems 2554 Lincoln Blvd., Suite 1088 Marina Del Rey, CA 90291 213/827-5772 No mail order, telemarketing or spa sales Gold Coast Bankcard Center Ft. Lauderdale , FL 305-492-0303 Affiliated with American Bankcard Center 800-777-VISA Harbridge Merchant Services 681 Andersen Drive, 4th Floor Building Six Pittsburgh, PA 15220 (412)937-1272 Under prior ownership, this company was called Peachtree. As Peachtree, it was the subject of many complaints, but since the change in ownership, the reports are more positive. Teleflora Creditline 12233 West Olympic Boulevard Los Angeles CA 90064 800-325-4849 or 310/526-5233. Deals primarily with bulletin boards. US Merchant Services 775 Park Avenue Huntington, NY 11743. 516 427-9700 Fax 516 427 9746 Thomas A. McGuire IV. Options Other Than Visa and Mastercard What about American Express and Discover? More people are likely to have a Visa or Mastercard. In early 1992 these were the market shares for each of the principal cards: Visa - 46%; Mastercard - 26%; Am Express - 20%; Discover - 7%. But American Express is easier to get than Visa and Mastercard. To contact American Express, call 800/528-5200. Discover is reportedly as difficult to get as Visa and Mastercard; however, the number to call is 800/347-6673. +++++++++++++++++++++++++++ >From wgiverson@ucdavis.edu (Will Iverson) Date: Thu, 03 Nov 1994 00:27:44 -0800 Organization: University of California, Davis In article , red.riders wrote: > Hey homeys, here's some info I had laying around. No more bitching > about lost shareware dollars, OK? > > > Increase Your Business by Taking Mastercard and Visa > Thanks tremendously for the info! Very interesting & informative! -Will +++++++++++++++++++++++++++ >From dbayly@homebase.tiac.net (David Bayly) Date: Thu, 03 Nov 1994 10:14:50 -0500 Organization: Chez moi In article , wgiverson@ucdavis.edu (Will Iverson) wrote: > In article , > red.riders wrote: > > > Hey homeys, here's some info I had laying around. No more bitching > > about lost shareware dollars, OK? > > Increase Your Business by Taking Mastercard and Visa > > > > > Thanks tremendously for the info! Very interesting & informative! > > -Will Theres also, netcash, which I am in the process of learning about. The way to do that is to send mail to help@agents.com. They have merchant accounts, Peter Lewis for one uses them. -- - David Bayly dbayly@homebase.tiac.net "If you keep your mind sufficiently open, people will throw a lot of rubbish into it." -William A. Orton +++++++++++++++++++++++++++ >From kurisuto@babel.ling.upenn.edu (Sean Crist) Date: 3 Nov 1994 21:41:46 GMT Organization: University of Pennsylvania, Linguistics Department One thing to be careful of if you're arranging this: the bank may charge you a minimum monthly fee for this service (something like $5 or $10 a month). I once arranged VISA/MasterCard service of this sort for a small charitable organization; I can't remember all the details, but I remember that it ended up being enough of a money leech that we decided that it wasn't worth it to continue the arrangement. \/ __ __ _\_ --Kurisuto (kurisuto@unagi.cis.upenn.edu) --- | | \ / _| ,| ,| ----- For a free copy of the Bill of Rights, finger _| ,| ,| [_] this account. | | | [_] --------------------------- >From nagle@netcom.com (John Nagle) Subject: Smalltalk implementations for Mac - update needed Date: Fri, 28 Oct 1994 06:26:27 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) I've been away from Smalltalk on the Mac for a while, and I need to get up to date. I'd appreciate answers to the following questions. 1. I know about ParcPlace and Digitalk. Any other vendors? (Somebody else was in Real Soon Now status, as I recall.) 2. Did Digitalk ever do much with the Mac implementation, like provide a compiler or a reasonable way to generate a standalone app? 3. I need something that can respond to Table Suite AppleEvents. (That is, I will be writing a program that responds, but I need a Smalltalk with AE support.) Suggestions? Thanks. John Nagle +++++++++++++++++++++++++++ >From podenski@halcyon.com (Patrick Podenski) Date: Sat, 29 Oct 1994 18:39:46 -0700 Organization: Northwest Nexus In article , nagle@netcom.com (John Nagle) wrote: > I've been away from Smalltalk on the Mac for a while, and I need > to get up to date. I'd appreciate answers to the following questions. > > 1. I know about ParcPlace and Digitalk. Any other vendors? > (Somebody else was in Real Soon Now status, as I recall.) > > 2. Did Digitalk ever do much with the Mac implementation, like > provide a compiler or a reasonable way to generate a standalone app? A new version was put out a while ago (V 2 ?), but I haven't seen it. > > 3. I need something that can respond to Table Suite AppleEvents. > (That is, I will be writing a program that responds, but I need > a Smalltalk with AE support.) Suggestions? There is a new Smalltalk from Quasar Knowledge Systems for the Mac that is supposed to be nice. It apparently caters to Mac specific things like you mentioned in 3. -- - ---------------------------------------------- Pat Podenski | my opinions are my own, podenski@halcyon.com | as are yours yours! - ---------------------------------------------- +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Sat, 29 Oct 1994 20:49:05 -0700 Organization: Internet for the Olympic Peninsula In article , nagle@netcom.com (John Nagle) wrote: > I've been away from Smalltalk on the Mac for a while, and I need > to get up to date. I'd appreciate answers to the following questions. > > 1. I know about ParcPlace and Digitalk. Any other vendors? > (Somebody else was in Real Soon Now status, as I recall.) QKS (Quasar Knowledge Systems) SmalltalkAgents. I bought that on nearly the last day of their User group special (ended Sep 30). I like it a lot. It provides pretty good coverage of special Mac things, while at the same time being highly cross-platform in nature (doesn't matter to me (I don't have a cross platform, only a contented Mac), does matter to some others). I'm still in the learning stage, but I like "STA" a lot. > 2. Did Digitalk ever do much with the Mac implementation, like > provide a compiler or a reasonable way to generate a standalone app? They finally did...they still don't seem terribly interested in the Mac, however. My Smalltalk V/Mac is back on the shelf. > 3. I need something that can respond to Table Suite AppleEvents. > (That is, I will be writing a program that responds, but I need > a Smalltalk with AE support.) Suggestions? I *think* you could arrange this either either Smalltalk V/Mac or SmalltalkAgents. I think it would be less work with SmalltalkAgents. --John -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] Sorry...clever signatures require cleverness, not found here. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From vollrath@vax.oxford.ac.uk (Alun ap Rhisiart) Date: 30 Oct 94 17:02:30 GMT Organization: Oxford University VAX 6620 In article , nagle@netcom.com (John Nagle) writes: > I've been away from Smalltalk on the Mac for a while, and I need > to get up to date. I'd appreciate answers to the following questions. > > 1. I know about ParcPlace and Digitalk. Any other vendors? > (Somebody else was in Real Soon Now status, as I recall.) Those two plus QKS SmalltalkAgents. I don't think Smalltalk/X is on the Mac yet (and neither is IBM's VisualAge, as you might have guessed). > > 2. Did Digitalk ever do much with the Mac implementation, like > provide a compiler or a reasonable way to generate a standalone app? > Not really. You had v1.2 didn't you, John? When the released v2 I was looking forward to something better than that old cloner, but no, it was exactly the same. They did do a lot to v2.0 (like system 7 support - including AE - and an even-driven interface, block-based exceptions, stuff like that). Unfortunately, the changes meant that the old tools, like Widgets (a al windowbuilder), Profile/V, and so on, no longer worked. We are _still waiting_ for an update for widgets to give us a GUI builder! Compatibility with other platforms is said to be 'improved', but evidently not much or windowbuilder would have been ported a year ago. It is also no faster, by the way, and Digitalk are not more responsive (except, I gather, through Compu$erve - although they are on this group more often now, which is something). > 3. I need something that can respond to Table Suite AppleEvents. > (That is, I will be writing a program that responds, but I need > a Smalltalk with AE support.) Suggestions? > STA is the way to go for this kind of stuff (and a lot else). The main criticisms of it at the moment would be: on Mac only (but other platforms on the way); no equivalent of Envy for version control and config management (but home grown solution due in v2); changes management is pretty poor (less reliable and convenient than even St/Vs change log), but again is being worked on. Main strengths are: speed; very easy access to C (especially), pascal, fortran, etc functions; saving objects to file or sending over network is very nicely done, and *tons* faster than the V solution); multithreaded; very easy and quick way to make standalones. My St/V is on the shelf too. The problem is that after using STA for a while you forget how far beyond the others it has gone, and it becomes easy to under-sell it. > Thanks. > > John Nagle -- Alun ap Rhisiart Animal Behaviour Research Group Oxford University vollrath@vax.ox.ac.uk (also not a paid endorsement. Not that I object to being paid, you understand!) +++++++++++++++++++++++++++ >From gburian@epaus.island.net (Geoff Burian) Date: 30 Oct 1994 15:01:47 -0800 Organization: Island Internet Inc - (604) 753-2383 In article , John Nagle wrote: > I've been away from Smalltalk on the Mac for a while, and I need >to get up to date. I'd appreciate answers to the following questions. > > 1. I know about ParcPlace and Digitalk. Any other vendors? > (Somebody else was in Real Soon Now status, as I recall.) Check out SmalltalkAgents from Quasar Knowledge Systems. The info they sent me was very impressive. There's a good article in the April '94 edition of MacTech. SmalltalkAgents is a superset of standard Smalltalk, but it seems to have good access to Toolbox calls and external (i.e., C, Pascal) code routines. QKS - 1-800-296-1339, info@qks.com Geof Burian gburian@island.net +++++++++++++++++++++++++++ >From kiisaka@is.morgan.com (Ken Iisaka) Date: Wed, 2 Nov 1994 23:00:26 GMT Organization: Or Lack Thereof In article <3918ks$a5l@epaus.island.net>, gburian@epaus.island.net (Geoff Burian) writes: |> In article , John Nagle wrote: |> > I've been away from Smalltalk on the Mac for a while, and I need |> >to get up to date. I'd appreciate answers to the following questions. |> > |> > 1. I know about ParcPlace and Digitalk. Any other vendors? |> > (Somebody else was in Real Soon Now status, as I recall.) |> |> Check out SmalltalkAgents from Quasar Knowledge Systems. The info |> they sent me was very impressive. There's a good article in the |> April '94 edition of MacTech. SmalltalkAgents is a superset of standard ^^^^^^^^ |> Smalltalk, but it seems to have good access to Toolbox calls and What standard Smalltalk? The ANSI ST? PPS? Digitalk? There is no standard that I know of that has been implemented. -- | ### ### | ### ### ### | ### ### | ### ### ### | | ### ### | ### ### ### | ### ### | ### ### ### | | ### ### | ### ### ### | ### ### | ### ### ### | | ### ### | ### ### ### | ### ### | ### ### ### | | | | | | | | | | | | | | | | | Ken Iisaka | (kiisaka@morgan.com) | Morgan Stanley & Co. Inc | | 1 Pierrepont Plz, Brooklyn, NY 11201 | All disclaimers apply. | |____|____|____|____|____|____|____|____|____|____|____|____|____|____|___ "Smalltalk Goes Object Oriented" - INFORMATIONWEEK, August 8, 1994, pg. 58 --------------------------- >From gpointer@guest.adelaide.edu.au (Geoff Pointer) Subject: What is MIDI Manager etc (reply) Date: 1 Nov 1994 00:26:05 GMT Organization: PatchUp There's nothing wrong with writing your own MIDI driver unless you don't have to (for kicks??). The whole point of an *idea* like MIDI Manager is to provide programmers with a consistent interface to work with that fits in with the multiprogramming environment. The problem seems to be that for obscure business reasons Apple has remained light on the provision and support of MIDI facilities. Having a MIDI Manager is just like having a File Manager or a Dialog Manager, ie, built in support. Unfortunately few *big* software companies are behind its use because its been a long time coming of age and hasn't yet. I personally would rather not have to write my own MIDI Driver so I intend to pursue development with the MIDI manager. The problem with music programs in a multiprogramming environment is the use of the serial port, if you have several MIDI programs running at once for different purposes they argue about who's going to get the port and you often end up having to reboot. To avoid this you use them independently which is anathema to modern operating systems. The beauty of the MIDI Manager is the way it arbitrates the use of the serial port. Now, someone here mentioned that there are programs that let you do both - use the port directly or use it via the MIDI Manager. Cubase is supposedly one of these - HAH!!, as soon as you play back a piece in Cubase, via MM, any program that uses MM solely gets nowhere. You have to open PatchBay and turn off the port and turn it back on again every time. I am still having difficulty with discovering which way to go from this point of view as I believe the idea of being able to have several MIDI tools open at once working in harmony is one of the most important aspects of MIDI programming today. Phew, there, I said it. - --------- Cheers - Geoff %^> ---------- What???..... No signature!!??.... OK, I give in: "I'm not afraid of dying. ... I just don't want to be there when it happens." Woody Allen. - --------------------------------------- +++++++++++++++++++++++++++ >From magma@cray-ymp.acm.stuorg.vt.edu (Christian Fowler) Date: 2 Nov 1994 17:57:19 GMT Organization: ACM Student Machine You can get the OMS (open Midi System) Development kit from Opcode for about $15.00. Several big name apps use it like Vision/StudiVision/Galaxy (of course) as well as Deck, SampleCell II Editor, and maybe the newest Cubase, but I'm not sure on that one. Anyway, OMS is very nice. -- +-+ +-+|+-+ Christian Fowler | shape +-+|+-+ magma@acm.vt.edu | FACTOR moMeNt +-+ --------------------------- End of C.S.M.P. Digest **********************