Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!SUMEX-AIM.ARPA!INFO-MAC-REQUEST From: INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator Dwayne Virnau...) Newsgroups: mod.mac Subject: INFO-MAC Digest V4 #82 Message-ID: <8607032209.AA06423@ucbvax.Berkeley.EDU> Date: Thu, 3-Jul-86 17:11:00 EDT Article-I.D.: ucbvax.8607032209.AA06423 Posted: Thu Jul 3 17:11:00 1986 Date-Received: Fri, 4-Jul-86 04:17:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: INFO-MAC@SUMEX-AIM.ARPA Organization: The ARPA Internet Lines: 612 Approved: info-mac@sumex-aim.arpa INFO-MAC Digest Friday, 4 Jul 1986 Volume 4 : Issue 82 Today's Topics: bugs in C desk accessories Re: TML Pascal and New System... Re: uw question GetIText and the string length byte LightspeedC bug dialog textEdit rightJust, ROM listings please Edit and ResEdit MACs as test instruments HabaDisk and the new systems... System folder bug? announcing availability of new version of FastEddie editor (Vn 2.5) Mac Magazines C compilers and benchmarking floating point Talk about easy! ACTA outliner DA ---------------------------------------------------------------------- Date: Mon, 30 Jun 86 14:09:26 pdt From: oster%ucblapis@BERKELEY.EDU (David Phillip Oster) Subject: bugs in C desk accessories Newsgroups: mod.mac Subject: Bugs in C on the Mac: Summary: Expires: Sender: Reply-To: oster@ucblapis.UUCP (David Phillip Oster) Followup-To: Distribution: net Organization: University of California, Berkeley Keywords: 1.) Do you write in C on the Mac? 2.) Do you write Desk Accessories? 3.) Do you use global variables? 4.) Do you occasionally pass pointer to C routines to the operating system? If you answered YES to all of the above, then you should know: Ordinarily globals variables are referenced off of register A5. The operating system guarantees to set up A5 correctly before calling your procedure. When you write a desk accessory, many language systems, particularly C compilers, generate code to reference global variables off of A4. The operating system MAY mess up A4 before calling you. The solution: LightSpeedC has two undocumented routines: SetupA4(); and RestoreA4(); that are supposed to do the right thing. they don't work all the time. I will post my solution to the net soon. --- David Phillip Oster -- "The goal of Computer Science is to Arpa: oster@lapis.berkeley.edu -- build something that will last at Uucp: ucbvax!ucblapis!oster -- least until we've finished building it." ------------------------------ Date: Thursday 26 June 1986 13.19 CST From: Samir Kaleem Subject: Re: TML Pascal and New System... I too had problems using TML Pascal using any other Finder/System other than 4.1/3.0. When they announced the new v1.11, I happily ordered it, but to my dismay, found that that it still uses Finder 4.1. When I tried it with newer Finder/System, it just didn't work properly. I think that a call to them is required, or I'll post a gripe on their BB. As soon as I get a response, I'll post a message here to let you know what happened. Seems to be a lot of little bugs are creeping in with the Mac+... BCNU...Samir BITNET: (XSAK@IECMICC.BITNET) ARPA : (XSAK%ICEMICC.BITNET@WISCVM.WISC.EDU) ------------------------------ Date: Wed, 2 Jul 86 10:09:18 PDT From: John Bruner Subject: Re: uw question UW consists of a Macintosh program and a UNIX server. A simple protocol is defined through which these two programs communicate a few commands. These commands perform functions such as window creation and destruction; they also specify with which window subsequent data is to be associated. The Macintosh program manages (up to) seven windows. It demultiplexes input from the host and sends the characters to a "draw" routine which updates a per-window text buffer (24 rows of 80 columns) and manipulates the screen by calling the appropriate QuickDraw functions. It tags keyboard input with the window number of the active window and sends it to the host. The host program uses pseudo-terminals to provide the terminal sessions. It demultiplexes the (keyboard) input from the Mac and writes it to the master side of the appropriate ptys. It reads from the ptys, tags the data with the window number, and sends it to the Mac. (This actually is quite simple; I wrote the first UW server in a day, and I've invested less than three days total in the UNIX code.) The auxilary program "uwtool" just opens a pseudo-terminal, starts a specified command on the slave side, and passes the file descriptor (via a UNIX-domain datagram socket) to the server. It has been a long time since I distributed UW v2.10. I am working on a newer version, but as the size of UW has increased my progess has slowed. I am now looking at mid to late August for the release of version 3.x (UW is available by anonymous FTP from S1-C.ARPA. It is contained in the four files "uwdist3.[1234]".) -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor [jdb@s1-c.ARPA] (415) 422-0758 UUCP: ...!ucbvax!decwrl!mordor!jdb ...!seismo!mordor!jdb ------------------------------ Date: Tue, 1 Jul 86 01:08:41 mdt From: dlc%b@LANL.ARPA (Dale Carstensen) Subject: GetIText and the string length byte In an earlier posting, I accused GetIText of returning the string length byte twice, but I was wrong. The DITL resource I was using is set up by the Manx rgen utility, and one of the two tabs in the item text line was actually included in the text line by rgen. It was a coincidence that the string was 9 characters long and the tab character is a hexidecimal 9, too. Now I wonder why rgen doesn't strip all the leading white space from the string. Also, I accused DialogSelect of not processing keyDown events. But the instructions to process keyDown events, including a special case for tab, are part of DialogSelect. Somehow, my program seems to skip those instructions, but there must be some way to get it to work. In the meantime, I can handle them just fine in my main event loop. (DialogSelect returns false.) Another bogus occurrence is that after GetNewDialog(...,...,-1L), the window previously in front gets an activate event telling it to deactivate, but never another update event until the dialog goes away or to the back. DialogSelect also returns false on both activate and update, although the instructions to process them are part of DialogSelect, and the update does get done. So, when I get an update for the dialog, I update the other window! Simple, huh? ------------------------------ Date: Thu, 26 Jun 86 08:43:12 MDT From: t-jacobs%utah-cbd@utah-cs.arpa (Tony Jacobs) Subject: LightspeedC bug Here is a bug my brother discovered. This bug still shows up after installing the recient list of patches (6-11-86?). #include #include /* Author: Steven R. Jacobs Computer Science Department University of Utah Salt Lake City, Utah 84112 (801) 581-8580 LightSpeed Libraries needed: stdio, unix, MacTraps This program should print only the word "Works" when running correctly. **MOVE THE FOLLOWING LINE OUTSIDE OF THE COMMENT TO DEMONSTRATE THE BUG** */ /* #define SHOWBUG */ #ifdef SHOWBUG #define MIDSTRING(ch) ((isspace(ch) || 0) ? 0 : (ch)) #else #define MIDSTRING(ch) (isspace(ch) ? 0 : (ch)) #endif main() { char word[128], *readtoken(); printf("%s\n", readtoken("Works incorrectly!", word)); } /*****************************************************************************/ /* returns first word from a string */ char *readtoken(t, str) char *t, *str; { register int ch; register char *s; ch = *t++; for (s = str; *t && (*s++ = MIDSTRING(ch)); ) /* NOT == */ ch = *t++; *(++s) = '\0'; return (str); } ------------------------------ Date: Tue, 1 Jul 86 23:49:47 mdt From: dlc%b@LANL.ARPA (Dale Carstensen) Subject: dialog textEdit rightJust, ROM listings please As I mentioned in a previous posting, trying to keep dialog textEdit items right-justified seems to be impossible. After 6 hours with MacNosy, I now know why (at least with the 64K ROM, but if it is fixed in the 128K or some INIT resource, even more of Inside Macintosh is suddenly and incompatibly obselete.) Page I-408 of the Addison-Wesley hardbound book, at the very bottom of the page, states, Note: Actually, a single edit record is shared by all editText items; any changes you make to it will apply to all such items. See chapter 12 for details about what kinds of changes you can make. Chapter 12 is, of course, the textedit chapter, and has no index entries for the word "textEdit," so it must not have any traps that are not allowed for dialog textEdit items, right? Well, the note is very wrong. Don't bother to try to change anything with a direct TE trap. When DrawDialog (which is called in case of an update event by DialogSelect, or by ModalDialog) updates the currently active textEdit item, it calls TEUpdate using the "single edit record." However, when DrawDialog updates the remaining editText (or statText) items, it calls TextBox. TextBox doesn't require a TERec handle, so it just does a TENew to make its own TERec, then calls TEUpdate -- without any of the precious changes you made to the "single edit record." I hope I just saved you 6 hours and $85 for MacNosy. I wish Apple would publish listings of the ROMs and INITs and PACKs. If some non-Apple computer company were selling 10,000 M68xxx computers per month, it seems to me fairly trivial to tell whether they used the Apple listing to develop their system. On the other hand, if Apple loses 10,000 sales of Macintoshes per month because programs are slow to appear because programmers are off on wild goose chases finding out why they can't believe IM, it's nobody's fault but Apple's. Or if the Macintosh programs have bugs because developers can't figure out what's really going on in Macintosh traps, packages, etc., it's Apple's fault. I don't mean that to discourage anyone from buying MacNosy or doing business with Steve Jasik (Jasik Designs). I recommend MacNosy. I just happen to feel Apple made a mistake in not publishing listings of Macintosh ROM, etc. software, and obviously Steve thought Apple should have published the listings, too, so he made a business of that niche. So, I hope Steve does well, but I don't think it's too late for Apple to correct its mistake. Not only should ROM, INIT, and PACK listings be published, but also listings of CODE resources in the System file, and DRVR resources in the Imagewriter file, etc. I don't see any need for listings of the Finder, but some things like the "Get Info" text in the DeskTop file should be formally defined and support for access by other applications should exist. Apple could make a profit on the books, too. The reason developers need to be able to buy listings is that Inside Macintosh is written in "natural" English, with all the ambiguities and contradictions that come "naturally." We need a reference work that can definitively explain why we can't get our program to work when we follow the directions in IM, that's all. ------------------------------ Date: Sun 29 Jun 86 00:13-EDT From: "Michael C. Adler" Subject: Edit and ResEdit Does anyone know if Apple has released a version of Edit more recent than 2.0D1? I need to use something compatible with HFS and have heard that the 2.0D1 version is relatively unstable. ------------------------------ Date: Mon, 30 Jun 86 19:55:06 EDT From: katsanos@harvisr.HARVARD.EDU (Nick Katsanos) Subject: MACs as test instruments Would like to know if anyone has information on using the Macintosh as an electronic test instrument. -- Nicholas Katsanos (Harvard Univ.) ------------------------------ Date: Wed, 2 Jul 86 15:23:20 CDT From: Scott Comer Subject: HabaDisk and the new systems... I have a 400K HabaDisk external drive, and when running System 3.1.1, Finder 5.2, and HD 20 (to get HFS, no hard disk) I cannot read disks on the HabaDisk. It puts up a dialog telling me that the disk is unreadable and want me to eject or initialize. I click eject, and nothing happens (that is, the disk does not eject). The finder then says that the disk is unreadable, and... These disks I can read without trouble using System 2.0 and Finder 4.1. Clues? scott ------------------------------ Date: Thu, 3 Jul 86 13:34:16 EDT From: Meredith Lesly Subject: System folder bug? I use WayStation as my finder, which I keep in my system folder. This means that when an application returns, it goes back into WayStation. All this is fine until I move WayStation onto the desktop. The finder still knows it's in the system folder, since if I do "put away" it winds up there, but when I exit an application I go back to the Finder. Is this a finder bug? It's probably not important, but I'm using system 3.2 and finder 5.3 on a enhanced Mac with a hyperdrive. ------------------------------ Date: Fri, 27 Jun 86 12:56:02 cdt From: werner@ngp.UTEXAS.EDU (Werner Uhrig) Subject: announcing availability of new version of FastEddie editor Subject: (Vn 2.5) [ below follow some notes describing the changes since version 2.3. remember, the program I am permitted to upload is only a "castrated" version, in that it is limited to small files only - 6K max, I believe. Enough to check out most/all of the options. I also feel obligated to point out the following: When you purchase the program, you receive a personalized copy of the full editor, as well as of the limited version. You are encouraged to pass on the limited version by a "33% commission" of any follow-up sales resulting from your "help". Given that the posted copy has my "serial- number" in it, I would find it improper to post-and-profit, so I have a) insisted that I get no "commission" of any orders b) anyone making an order in result of my posting can take off 33% of the price themselves instead; please refer to me saying so. Regular price is $48 (plus $5 for overseas postage), which I consider more than fair. Which would make "your price" $32, which is outright cheap for what you get. I would consider it only fair, that, should you take the discount, that you tell Daniel (the author) you also want no 33% "commission" of any orders that might result of you distributing your Ltd-copy, but that is, of course, up to you to do. I also try to encourage Daniel to consider making the whole program into ShareWare, but I am not sure if that is a recommendation which would benefit or harm him. You may want to tell him your opinion on the matter. Given that he distributes updates at cost (in my opinion, he does it below his cost, actually; I think his time is worth more than he charges for updates), if FastEddie would become ShareWare , updates could be distributed over this net at great convenience to everyone. Please also note, that the program is so powerful through its extension capabilities, that unless you make some effort to explore this feature, you will hardly be able to fully understand and appreciate the gem that this program really is. It takes some understanding of the C-language to take advantage of this, however, but you can't expect power without some added complexity. In order to allow exploring this complexity I uploaded all the files that I, legally, could - please don't ask me to do more or expect me to have either the time or the knowledge to answer questions. Other than this article, look for 3 files which I will post shortly - binhexed4 and PackIted2. Cheers, --Werner ] *** CHANGES between VERSIONS - 2.3 - and - 2.4 - of FastEddie : *** *** NEW FEATURES: ***