Background Processing and 7.0

By Larry Nedry, Mousehole BBS

From: Atom

Re: MPW, MacApp, and ETO

Why are Apple’s MPW and MacApp releases getting less and less frequent? Very few beta versions are available to regular APDA customers any more, and even some post-final products are only available on ETO, to wit MacApp 2.0.1 -- and this after much of MacApp 2.0 final was actually beta stuff. Outrageous, if you ask me.

Things appear to be getting worse, not better. The C 3.2 beta distributed with MPW C++ 3.1 is buggy, but Apple kept usable betas of MPW 3.2 (including CFront 3.1-compatible C compilers) in the hands of the ETO elite for months. Now I’m told MPW C++ 3.1 is incompatible with MPW 3.2, and C++ 3.2 is still a couple of months away at best. MacApp 3.0 is supposed to have full support for all the new System 7.0 features, but it’s barely on the horizon unless you have ETO. More and more it seems that Apple really targets the MPW product line for its ETO subscribers, and the rest of us just get a few scraps here and there.

I’m not holding anything against the people who have ETO, mind you. Honestly, my beef is with Apple alone. Adding value to the ETO package to make it more attractive is one thing, trying to force people to subscribe by making it the *only* source of current and mutually compatible tools is quite another.

P.S. - To be fair, APDA has been promising a free upgrade to MacApp 2.0.2 (instead of 2.0.1) for purchasers of v2.0, claiming there were “some problems” with 2.0.1. Well, there ARE problems with 2.0, and 2.0.2 is just talk so far. If 2.0.1 is good enough for the ETO folks, why hold it back?

From: Atom

Re: MPW 3.2 prices

APDA just released pricing info on MPW 3.2 today. Update prices haven’t changed much since 3.1 -- the C (or Pascal) Bundle Update actually went down to $50, and the C and Pascal Bundle Update is $100 on floppies, $50 on CD. I’m told everything in the package is System 7.0-compatible, including a beta of SADE 1.3. For C++ users there’s still a catch: C++ 3.1 is not compatible with MPW 3.2 (no explanation given), and C++ 3.2 isn’t due out until “at least August” (you know what that means).

From: Mrteague

Re: prices

Hmmm. I don’t know about the C++ 3.1 being incompatible with MPW 3.2 - as far as I know, this is the version of C++ I use all the time with MPW 3.2 and MacApp 2.01 to produce a large program, without any undue problems.

From: Atom

Re: MPW 3.2 prices

I thought it sounded strange too, since I’ve tried CFront 3.1 myself with the C compiler from a colleague’s ETO #3 which I think is 3.2b6, and it worked fine. But I heard this from at least 2 different APDA reps, so I gave it enough credence to mention it. BTW, do you have MPW 3.2 final?? I thought this hadn’t shipped yet.

From: Atom

Re: MPW 3.1 and System 7.0

Does anyone know why MPW 3.1 is incompatible with System 7.0? The Finder in the new system software refuses even to launch it. The “Compatibility Checker” says you “must upgrade” to MPW 3.2, which isn’t even available yet. Same with SADE 1.1. MS Word 4.0 has been out for ages and I understand it’s 7.0-compatible. Why couldn’t Apple avoid this problem?

From: Mrteague

Re: MPW 3.1 and System 7.0

I don’t know for a fact, but there are several possibilities I can think of - 1) the MPW Shell and all it’s tools are NOT 32 bit clean; 2) the MPW Shell probably patches some traps for its memory management, and maybe some changes were needed; 3) MPW 3.1 did not execute tools in the background too reliably, and with System 7.0 coming up, this was going to be important; 4) there are probably enhancements in it for System 7.0 etc.; 5) as always, it is a maintenance release that fixes (and adds some new ones <grin>) bugs.

Of course, MPW 3.2 is now released, and you should be able to get it from APDA. But betas of MPW 3.2 have been available to developers for probably a year now, on the ETO CD-ROM.

Also, I forgot to mention the other important reason for MPW 3.2 - it adds all the Interface files and Libraries for all the System 7.0 stuff.

From: Atom

Re: MPW 3.1 and System 7.0

Yes, MPW 3.2 is out. Unfortunately, it seems like APDA is the last outlet to get it. I’ve been calling them every week for the last month or so, and every time it’s “try back next week”. I’m sorely tempted to buy ETO, but that’ll have to wait for a big drop in CD drive prices (sigh)

Thanks for replying, Mrteague. In the end, I guess it doesn’t matter WHY MPW 3.1 is incompatible, just THAT it is. Must be something serious, though, since Finder 7.0 won’t even launch it.

From: Atom

Re: Background performance under 7.0

I wonder if anyone would be interested in the results of a benchmark I ran today to test out how well background tasks perform under System 7.0? The benchmark is an FPU-intensive program that’s designed to call WaitNextEvent often enough to run comfortably in the background without impeding its own performance significantly -- if the foreground application cooperates, of course. It passes a sleep parameter of 0 so it should get as much time as other processes will allow. Here are some results running under System 6.0.4 on a Mac II; “P.I.” stands for performance index and is just a linear measure of execution speed (so if the P.I. doubles, it means the program executes twice as fast).

Foreground application             P.I.
----------------------             --
benchmark                          9.4
Finder                             9.1
Idle                               9.4

“Idle” is a screen saver application that yields the CPU for 2 sec at a time and, as these results suggest, uses a minimum of processor time. Now here are the same results under System 7.0; the Mac II, incidentally, has 8 MB of RAM and no PMMU, so virtual memory is not a factor.

Foreground application             P.I.
----------------------             --
benchmark                          9.2
Finder                             7.1
Idle                               8.5

The slight difference when the benchmark is in the foreground may just indicate higher overhead in the new system, or it may not be significant. But the results for Idle in foreground suggest the Process Manager is definitely less generous to background apps than was MultiFinder, and the Finder is downright unfriendly. (Incidentally, a DA in foreground roughly halves execution speed under either system -- which is why I wrote “Idle” as an application.) This is definitely not good news to people who use their Macs for numerical calculations that they run in the background while doing other things. Even if you’re just staring at the screen there’s a definite hit to having another program in the foreground, unlike under System 6.x. The “best” case (assuming Idle can be taken as that, which I’ve found is pretty reasonable under System 6) is still about a 10 percent drop in performance overall -- not a disaster, but still significant. Of course, this is only one benchmark, and results may vary. Really I should prepare a set of benchmarks and run them with a variety of different apps in foreground, but this will have to wait until I get 7.0-compatible updates. I’ll be doing this over the next few weeks, and if the results are significantly different, I’ll drop another note here.

From: Atom

Re: More on background performance

Since I posted my first message on this subject last night, I realized that I actually have more 7.0-compatible applications than I had thought -- at least they run, though Apple either says they’re not compatible, or doesn’t know. Here is a table of PI values (Performance Index) for the benchmark I mentioned last night, under Systems 6 and 7, as a function of the foreground application. I also ran one DA (Apple’s Calculator) for comparison. Under System 6.0.4, I used MultiFinder 6.1b9 and Finder 6.1.4. Under System 7.0 I used Finder 7.0. Both Systems were “clean” -- no INITS (other than those in the System file), no Backgrounder, and no virtual memory under System 7.

Foreground application         System 6.0.4    System 7.0
----------------------         ------------    ----------
Benchmark                          9.4            9.2
MPW 3.1                            9.4             *
Mouser 1.2d7                       9.3            8.2
Finder                             9.1            7.1
Igor 1.11                          8.1            7.8
Calculator DA                      4.9            4.2
ResEdit 1.2                        4.7            4.3
HyperCard 1.2.5                    4.5            4.3

*The Finder won’t launch MPW 3.1 under System 7.0.

It looks like the performance drop in going to System 7 varies with foreground application more than I thought at first. BTW, by setting breakpoints in MacsBug I confirmed that ResEdit and HyperCard call GetNextEvent, not WaitNextEvent --which probably explains the poor results when they’re up front. I hope this is of interest to someone.

From: Atom

Re: Backgrounding problem

I think I know why background processes slow down under System 7.0. It’s because the new system doesn’t respect the sleep parameter the foreground application passes to WaitNextEvent, unless it’s less than about 6 or 7 ticks. You pass a larger value, and even if there’s no event pending, WNE will return with a null event, regardless, after about 7 ticks. The end result is the foreground process hogs the CPU whether it wants to or not, and anyone in the background suffers. The same isn’t true for a process in the background: its sleep parameter IS respected. I can’t find any documentation of this “feature” in Inside Mac V6.

From: Bishop

Re: WaitNextEvent

You say that control is returned to the foreground app in <= 7 ticks. I can’t seem to duplicate that, all my tests indicate that the yieldTime parameter of the WaitNextEvent() function in Sys. 7.0 behaves like its 6.x MultiFinder predecessor. Also Inside Mac VI gives no indication that the behavior of yieldTime has changed. In my test I varied the yieldTime in 5 tick increments starting at 0 ticks up to 60 ticks. The application behaved as expected in the background and the foreground. (However, IM VI does recommend that yieldTime should not be set less than 15 ticks if you’re using TextEdit.)

From: Atom

Re: WaitNextEvent

Thanks for trying to duplicate my problem. Your findings puzzle me greatly, since I traced through WaitNextEvent in MacsBug and found exactly where things were getting fouled up, at least on my system. The problem isn’t in WNE proper, but somewhere in the call to GetNextEvent which WNE makes. WNE calculates the time to wake up and stores it until after GNE returns; GNE overwrites this storage with a value of its own, which is 5 ticks (it’s hard-coded!) from the time that point in GNE is reached. I wrote an INIT to patch WNE that is identical to the original WNE, except that after GNE returns it uses the original wake-up time, instead of the value stored by GNE. Using this INIT causes the sleep parameter to behave as under MultiFinder 6.x. Obviously, though, there’s some difference between our systems. I’m using a Mac II, and installed System Software for Mac II and Software for Imagewriter. At the time I performed the tests reported earlier, no file containing an INIT resource was in either the Extensions or Control Panels folders.

From: Bishop

Re: WaitNextEvent

I am going to look further into this...I am also using a Mac II using the same system software. My tests were not carried out on the low-level...I used various timing routines to measure the effects of varying the yieldTime, and found that the change in execution negligible. I’ll investigate further.

From: Atom

Re: WaitNextEvent

Thanks again for your interest. If this problem was occurring on your system, I’m sure you would have noticed something when you tried to sleep for a full second. Next week I’ll have access to another Mac II with different HD and other peripherals, I’ll try installing my System 7 copy and see what happens. I might be able to wheedle access to a IIfx too. Too early to say really, but my copy might be corrupted somehow and I’d hate for anyone to waste time on this if that’s the case.

From: Musicman

Re: Floating palettes

Is there any easy way to implement floating palettes in System 6.0.x? I have the article from the April 1988 MacTutor, but isn’t there an easier way than by trying to outfox the OS?

From: Btoback

Re: Floating palettes

I don’t know of an easier way, but I’ve used the floating windows stuff from the April 1988 MacTutor, and it works very well. It’s also very easy to use, if it’s the code I’m thinking of. I just dropped it in, changed the few calls in my existing code that mattered, and it came right up.

From: Musicman

Re: Floating palettes

Thanks, I got it to work too. My WDEF though had a varcode of 1, a no no for MultiFinder, since the OS thought it had a dialog box on the screen. Took me a while to figure that one out. I think even a better solution is Greg Dow’s Think Class library supplied with Think PASCAL. It’s beautifully done.

From: Ebishop

Re: menu-in-window

I’m trying to discover the “secret” to placing a real menu bar within a window (a HyperCard 2.0 xWindow, actually). I see it done all the time in DAs like Vantage or DeskWrite-Draw-Paint-Comm, & in SuperBoomerang. I’ve been able to work a kludge with a row of popUp menus, but it seems like there ought to be a more elegant solutions.

Any insights from a more experienced hacker??

From: Thehulk

Re: menu-in-window

Menus in Windows just so happens to be the topic of a MacTutor article found in MacTutor Vol. 4 No. 11 or in The Definitive MacTutor Vol. 4. The code is on disk 38 (Nov. 88). Hope this helps.

From: Hweiss

Re: Assembly + C

I have been programming with THINK C for awhile now and have been learning to debug object code with a low level debugger. Why, you ask? I have come across a few bugs that did not appear when running the application under THINK C but did appear when in a real time environment. I thought that it might be more useful for me to learn to write assembly instead of only learning to read it (as would be the case if I just wanted to learn to debug object code). Do any of you multilingual programmers who know/use both Assembly & C feel that this might be the best approach?

Also, THINK C has an inline assembler that allows me to incorporate some assembly into my source files. Would it be best for me to start learning to write assembly by converting small routines in my existing THINK C source to assembly language instead of purchasing a standalone assembler? If not, then what assembler do you use or would you recommend?

From: Mrteague

Re: Assembly + C

I don’t use THINK C, but hopefully I can give you advice on multilingual programming. The best way to learn assembly is to read as much code as you can from other programmers, and with the Instruction Set documentation in one hand, understand what the code you are reading, is doing - sometimes it will you give you new found respect for assembly language programmers (or then again, not) <grin>. Looking at the sample code from Apple, including such things as WDEF, CDEF, MDEF source (the definition routines, not the viruses by the same name!) which is usually well commented will help. Definitely look at the code generated by your C compiler - which you are already doing with your MacsBug debugging - you will soon get to recognize the code sequences generated by compilers, and with practice, you will be able to determine what development system a programmer used, by simply looking at the code generated, which can help you if you are tracing some unknown code from someone else. Using the inline assembler to recode some of your routines in assembly would be an excellent start. As for suggestions for what assembler to use - I have been programming for a long time, and was brought up on machines/operating systems etc. much less sophisticated than today’s Mac’s etc. - I was quite proficient in using the Apple II Monitor program (not the built-in mini-assembler) to enter reasonable sized programs in hex from memory, and I have done a certain amount that way with MacsBug. On PC’s I would generally use ShareWare Assemblers as they were easier to use than the standard for the day - MASM from MicroSoft (I guess these days people are spoiled by the Turbo Assembler products). There are some Free/ShareWare Assemblers for the Mac, but they are generally not of very good quality. You are better off with what you have got, or if you want a professional assembler, I would recommend MPW Assembler.

From: Jhannah

Re: McAssembly

Hi. If you don’t want to use MPW for 68000 Assembly, you have a few options:

1) McAssembly, but you already said you used that, and it’s out of date by now.

2) MDS Assembler. That’s right.. the predecessor to CDS and MPW. if you can find it, and don’t mind having to use System version 1.0 to run the Linker, go for it. :-)

3) The last thing is THINK C. Probably the best. THINK C has a built in assembler. You’ll just have to learn a little bit of overhead to figure out how to use the assembly in it, with as little C code as possible.

PS The neat thing about THINK is that aside from MPW, its the only one of those assemblers that generates 68020/030 code!!!

From: Kevin7

Re: Think C for 7.0

Has anyone heard of an update for Think C for System 7? I am really looking forward to getting system & and likewise be able to develop programs under it. I currently use Think C 4.02 (?) and was wondering when these guys would have the include and header files for System 7. I’m still trying to find my registration cards so I can call and ask them directly. I HATE having to keep track of damn numbers for other people!!!!!

From: Mrteague

Re: Think C for 7.0

Yes, developers have been receiving updates of THINK C & Pascal for System 7.0 for some time now. But Symantec has now released the latest versions to the public - version 4.05 for THINK C. It should be already on the BBS, or you can probably get it direct from the Symantec BBS at (408) 973-9598.

From: Kling

Re: Think C for 7.0

Yes... I upgraded THINK C about a week ago with the upgrade file I got from Symantec’s BBS... It works fine...But Virtual Mem must be off when using it and you can not use it in 3 bit mode ( this is because THINK C, although it can produce 32 bit clean code, is itself NOT 32 bit clean) The newer version is called 4.0.5...I have not gotten into using System 7.0 traps since the upgrade does not come with System 7.0 header files..but I should be able to make my own (or if anyone else has them they could Upload them...) with the help of THE MONSTER (vol. 6 of IM)

From: Atom

Re: Clipping problem with MacApp 2.0

Some while ago I wrote a MacApp program that allows a user to extract data from a scanned image. The main view displays a picture and sometimes some other elements -- a marquee, for example. Since the picture is usually large, it’s drawn offscreen. (I adapted the code from TView.DoOffscreen without setting the qExperimentalAndUnsupported flag.) The view’s Draw method checks that the offscreen image is still valid and blits it in the usual way, using CopyBits. If the marquee is drawn, it’s then drawn directly onscreen. Here’s the problem: if the user changes the screen depth the Draw method has to redraw the offscreen image. I recently discovered that in this case the marquee will still be drawn, right over other views in the same window, if it’s been scrolled out of view but not outside the window’s content region. I call Focus before drawing so it’s not that. It’s as if MacApp’s view clipping isn’t working right for some reason. Does anyone have a clue as to what I might be doing wrong?

From: David

Re: MacApp Views--I am confused

I am trying to get an application up and running under MacApp, but I am having some difficulties understanding the complexities of the views and the relationships among them. I have a large offscreen bitmap that I want to display in a scrollable window. Obviously, I want to use a TScroller view to control the scrolling. However, what is the relationship between the TScroller and the offscreen bitmap? I can’t see how the TScroller can be the superview of the offscreen bitmap, because the size of a subview is constrained by the size of the superview, so the bitmap can be no larger than its superview. This then defeats the whole purpose of using a TScroller in the first place. Tentatively, I think that I am supposed to have the TScroller communicate with the offscreen bitmap and tell it what its current coordinates are so that the bitmap can then display the proper rectangle, but I still am confused as to how to subclass TView so that I can draw the bitmap. If there are any MacApp gurus out there who would be willing to help a novice MacApper, let me know. If you don’t want to take the time and effort to write a file on the MouseHole, send me e-mail, and I’ll be happy to call you.

From: Atom

Re: MacApp Views--I am confused.

I’m not a MacApp guru by any stretch, but I’ve faced a similar problem myself. I’ll try to cover the basics and let the real pros fill in the details, if necessary.

For the moment, forget about the offscreen bitmap. You want to create a TView subclass (I’ll call it TYourView) that displays a large image. So you define the view’s enclosing rectangle to enclose the whole image and make the view’s superview a TScroller. If TYourView has a Draw method that correctly draws the image, you get scrolling for free. MacApp takes care of setting up local view coordinates for you (this is part of what TView.Focus does). This means that when your Draw method is called, (0,0) in the window’s coordinate system will be at your view’s upper-left corner (wherever it happens to have scrolled to) and everything will be drawn (or blitted) to the right place.

The offscreen bitmap comes in when you implement the Draw method. Instead of drawing the usual way, your view’s Draw method will create or update the offscreen bitmap if necessary, then use CopyBits to blit the bitmap to the screen. You might declare your subclass as:

TYourView = object(TView)
   ...
   fBitMap: BitMap;
   ...
   procedure TYourView.Draw(area: Rect);
   ...
end;

and then implement its Draw method as something like this:

TYourView.Draw(area: Rect)
BEGIN   {first check if user has changed screen depth or otherwise made 
bitmap invalid}
  if NeedToUpdateOffscreen then
  BEGIN
     UpdateOffscreen;  {recreate offscreen bitmap and save it in TYourView.fBitMap}
  END;
{$H-}
  CopyBits(fBitMap, thePort^.portBits, area, area, srcCopy, NIL);
{$H+}
END;

assuming you keep the entire image in the offscreen bitmap and the bitmap’s bounds rectangle is identical to the view’s framing rectangle (its “QD extent”).

Cautionary note: when drawing the offscreen bitmap you need to set the current GrafPort’s visRgn so it includes the entire view rectangle, or only part of the image will be drawn. Ditto for the clipRgn. Be careful to save and restore both regions, or bad things may happen (I learned that one the hard way).

I hope this helps. If you need sample code on how to set up and maintain the bitmap, you might check out the (experimental) TView.DoOffscreen method.

From: Walshag

Re: protecting volumes at startup

Does anyone know what the “proper” way to protect a disk from being accessed is? Some password programs keep a protected volume from being opened even when the system is booted from a floppy (that is, the hard disk(s) are protected even when the protection program is not running). Is there a correct way to do this? I heard that some write to Parameter RAM to achieve this....any idea?

From: Mrteague

Re: protecting volumes at startup

Can you be more specific about what you are trying to do/ask? There are no bits in PRAM that I know about that pertain to disk protection - if there, protection would be very easy to defeat (remove the battery, or use a program to modify PRAM, or zap-PRAM on bootup). DiskLock from Fifth Generation Systems is an example of an excellent disk protection package. The method by which protects hard disks, even against booting from floppies, is the use of a modified SCSI driver on the drive in question - the driver will not allow access to the drive until the right password has been entered. It would require some very low level hacking to defeat this protection (suffice it to say, I will not give you any more clues on how this might be done).

From: Walshag

Re: protecting volumes at startup

Thanks for your reply...I’m writing a program (CDEV) that is similar to most disk protection programs. It won’t allow you to delete files unless you have access to the volume the files reside on. You can still run the applications & look at the contents of the volume, you just can’t delete files unless authorized. The problem is that when someone boots from a floppy, my program is not active, and the volumes are not protected. I wanted some way of making the volume invisible (or locking it) when my program is quit (of course, if someone reboots in without using shutdown, it never has a chance to lock/make invisible. But this isn’t going to be a terribly tight security program, just something simple for the computer lab).

If you have any further suggestions I would like to hear them...thanks for your time.

From: Aikidoka

Re: Blocking switch under MultiFinder

Help!!

I have to find a way to stop a multi-media application from switching to the Finder or another application when the small icon in the upper right is clicked on. Any ideas?? Thanks!! :}

From: Mrteague

Re: Blocking switch under MultiFinder

If you are running under MultiFinder, there is a reasonably easy way to stop “context switches” when clicking on the small icon in the upper right corner of the menu bar - MultiFinder will NOT switch tasks if the frontmost window is a “modal” window. This is not to say that there has to be a modal dialog window up front, but rather MultiFinder checks the window class of the window, and if it finds a 2, then it won’t switch. You might be able to modify window resources in the application to change their “window definition ID” using ResEdit to 2. It will look funny on the screen, but it will stop context switching. I’m not quite sure why you are trying to stop context switching, but alternatives might be to ask people not to run it under MultiFinder; there might be INITs that remove the MultiFinder small icon from the menu bar; or another suggestion of mine - remove Finder from a startup disk, and make the multimedia application the Startup application (and Finder application, by modifying the boot blocks with FEdit or similar) - that way there would be NO Finder to switch to (or Quit to either <grin>). I haven’t tested that last suggestion. I believe there are some ways of “killing” Finder once you are running in another application, but it may start up again, if you try to “switch” to Finder.

From: Musicman

Re: MacsBug docs

Where can I get decent documentation for MacsBug 6.2 (for a non-assembler)?

From: Mrteague

Re: MacsBug docs

The official Apple MacsBug 6.2 manual is available from APDA. It is actually an excellent manual (I learned a few things I didn’t know before about MacsBug, having never read a manual for MacsBug). It is designed for beginning Macintosh programmers, however you still need some experience with assembly language, and a copy of the instruction set, if you hope to do any good with MacsBug.

From: Kling

Re: MacsBug docs

There are two books pending on MacsBug 6.2 both from Addison-Wesley...The first is called MacsBug Reference and is similar (in size and content style) to the new Addison-Wesley Book on ResEdit called (strangely enough ResEdit Reference) The second is called MacsBug Complete (or a Complete Guide to MacsBug or something like that ) and is part of the inside/out series....I’ll try to get more information (like release dates, authors names and ISBN #’s) I think the first is due out this month....

From: Brainiac

Re: DeRez documentation errors

NEW (and seasoned) users of MPW and MPW documentation please take note of an MPW command reference documentation error.

See: MPW: Macintosh Programmer’s Workshop Development Environment, Volume 2, Command Reference, p. 109, DeRez-Resource decompiler.

Description, first paragraph, first sentence, second clause: “ ... according to the resource type declarations in the resource description file(s).” SHOULD READ “ ... in the resource TYPE DECLARATION file(s).”

The description should then go on to explain that these declarations act as “templates” for resource “decompilations” of ANY FILE’S resource fork or stand alone resourceFile(s). “resourceFile” is italicized in the command reference and is defined in the glossary, volume one, p. 621. See the glossary.

I believe this mix up (“definition” instead of “declaration”) is responsible for an error in the PROGRAMMERS GUIDE TO MPW, Addison-Wesley Macintosh Inside Out, Volume One, Chapter 8, Building an Application, pps. 427-428.

Item 2, p. 427 states: “If you write your resource fork using ResEdit ... “, this should read: “If you CREATE your resource fork using ResEdit ... “. Bear with me here.

Now see item 4, p. 428 that states: “If you have written your program’s resource fork using the MPW editor, you must compile it using the MPW command DeRez.” This should read: “ ... using the MPW command Rez.”

MPW for “DeRez” of us.

From: Mrteague

Re: Total number of files on a disk??

If you look in I.M. Vol. IV, File Manager chapter, it explains the layout of the various HFS data structures that you can access. PBHGetVInfo will return the number of files on the volume in field ioVFilCnt; the number of files in the root directory in ioVNmFls; the number of directories (not including the root) in ioVDirCnt - these fields are part of the HParamBlockRec structure. Similar information exists for MFS volumes. I believe that AppleShare volumes *may* behave differently. Just to give you some advance warning - you can’t necessarily depend on the number of files on disk changing to indicate someone/thing is updating your disk (e.g. a file added, and a file deleted before you look at the count again). Most applications that require the ability to track changes, look at timestamps of things last modified - unfortunately there is a limitation in that renaming files will NOT update the modification date of its parent folder. I suggest you download the Disinfectant 2.4 source code that is available on this BBS. It already does the kind of things you want to do, including special code for handling changes to the volume being scanned. Hope this helps.

From: Johnbaro

Re: Arithmetic drawing modes

Maybe someone can clarify how the arithmetic drawing modes work - the drawing and CopyBits I’ve been trying don’t seem to work the way I expected. I’ve been trying to superimpose two images, one made up of red shades and the other of green shades. What I would like is for the two to add together where they overlap, to create a shade of yellow. I have a palette that has all the red and green shades I’m using, as well as a shade of yellow that exactly matches the sum of each red and green shade. The background for the image is black. If I draw or CopyBits either the red or green image using the srcCopy mode, everything looks OK. However, if I draw the red image, then draw or CopyBits the green image on top of it using the addPin mode, the green image is not drawn correctly. Clearly visible bands appear in what should be gradual light/dark transitions. This also happens if I draw either image alone using addPin on a black background.

I understood addPin to work by adding the source and destination pixels together, the R,G, and B components separately. If this is true, then drawing with addPin on a black background should be the same as drawing with srcCopy. But it’s not - the colors with addPin are only poor approximations of what they should be.

I have a 256 color palette, with usage set to pmTolerant+pmExplicit (necessary for offscreen GWorlds). addPin is pinned to the maximum shade of yellow that would be obtained if the brightest red and green values were added together. Tolerance is set to zero. Any clarification of how these drawing modes work, or alternative ways of accomplishing what

I’m trying to do would be greatly appreciated. Thanks.

From: Derek

Re: THINK Pascal Resource

I am writing a Hermes BBS External Resource, and have a question.

I set up the THINK Compiler to compile my code in a Resource called XHRM with an id of 10001. This works fine, in fact my program works! :)

But I also need to create a second resource in the same file. This second resource, so far, I can only copy into my program with ResEdit.

What I would like to do is create a second resource in the same file, when I compile the first one. I do not want to use an already compiled resource, I want to compile a second, smaller one at the same time. Is this possible with THINK Pascal?

Also I have to admit, I do not even know how to compile the second resource. The information I have is as follows:

Resource Name: HRMS

Id Number: 100

Structure of this resource is as follows:

eInfoRec = record
    allTime : boolean;
    minSLforMenu : boolean;
    Restriction : char;
    end;

If anyone can tell me how to compile this second resource at the same compile time (If possible) I would really appreciate it. Even if I can’t do it at the same time, as of Yet, I do not even now how to compile it.

From: Mark

Re: System 7.0 bugs...

Hi, I was wondering how many people have run into bugs in the system itself? Or in little things that are really weird. Here is my list: The trash won’t empty a file (happened on 8 occasions). Problem? It thinks the file is locked yet gives no message when you try to delete. Solution is to lock then unlock the files.

Occasionally the Finder gets aliases confused. Some real programs it thought were aliases right after my install. Solution is to get info and say find original. It will then correct the problem.

Thinking an alias is a file. Not much to do about this one except throw the file away and start again.

And now for the interesting interactions between programs! After changing something in SuitCase II (v 1.2.9) if you then choose the Control Panel the finder thinks that the control panel is no longer an alias and changes it to a file. Gotta delete it and start again.

And my favorite is SilverLining 5.27. The compatibility checker lists it as not working, but doesn’t say why. This is why: The drivers don’t work in 32 bit memory mode! With really weird results. If you hold down the shift key (disable all inits) it works. If you run in 24 bit memory mode it works fine too. The really interesting thing is that you can get it to run in 32 bit memory mode if you pull the extensions folder out of the system folder. Just leaving it empty doesn’t do it. The only problem is that the system will then make the extension folder again so you have to do this every time you boot. I had to reformat with a different hard drive formatter program.

If anyone else would like to add to this list I would really like to hear it. I did my tests on a Mac IIci running no inits at first, and now I am running a handful and it hasn’t affected these problems.

From: Sysop

Re: System 7.0 bugs...

You can update Suitcase II to version 1.2.10 with the update which can be found in the file library.

From: Kling

Re: System 7.0 bugs...

I have had some problems with the trash also.. The system insisted that one of the files in the trash can was busy so it could not be flushed.. When I went to open the trash can it was empty (but the can was still fat) I restarted the system (heck.. restarting is a quick fix when you don’t know what is wrong) and the can was empty... kinda weird ...

From: Mark

Re: System 7.0 bugs...

It doesn’t look like 7.0 is completely bug free. My bet is that they will delay 7.1 for as long as possible to try and save face.

From: Kling

Re: System 7.0 bugs...

Well..it may not be bug free but it is VERY good considering all the programmers needed to take into account (like keeping it backwardly compatible with as much software as possible) I have been using it for about three weeks now and have yet to see it crash. That is saying a lot considering my experiences with System 6.0 (6.0.5,6.0.6 and 6.0.7 were fairly stable) I would give Apple and A for the system but a C+ for public relations (we waited a long time for this OS, perhaps they should have put off mentioning it to the public until the project was further along) Oh well, just some of my thoughts...

From: Mark

Re: System 7.0 bugs...

Yeah, I have yet to see the system bomb, yet I don’t recall the 6.0.5 system bombing either. It is usually the applications. I think what you are seeing is that the program either runs (and that means that the programmer took the time to do it right) or it doesn’t run at all in which case you chalk it up to “compatibility problems.” You see my point?