THINK vs MPW and db_Vista

By Larry Nedry, Mousehole BBS

From: Roembke

Re: MPW vs THINK

I figured this would be the perfect place to find out what the pros and cons of each of these environments is. I have quickly scanned the messages, but none really jumped off of the screen at me, so I am asking which is best?

If you need some background, I am a new Macintosh Programmer, I am interested in learning OOP, I am only interested in real languages like C and Pascal. I have an SE/30 at home and a Mac IIx at work. Currently I am leaning towards MPW- but interested in getting advice before putting down my hard earned cash on one or the other. I am interested in (eventually) producing all types of Macintosh code (XCMDs, DAs, Applications, INITs, etc.) Any thoughts?

From: Mward

Re: MPW vs THINK

The basic difference is ease-of-use vs power. MPW gives you the power of a command line interface, and a lot of useful tools, while Think gives you a very pleasant, well integrated environment. If you are new to Mac programming, I would doubt you’d need the power offered by MPW for a long time.

I’m curious - what languages do you consider “unreal”?

From: Roembke

Re: MPW vs THINK

Actually, I was using “real” as tongue-in-cheek! At the present time I consider myself to be pretty well occupied with C and Pascal to consider any other languages. If I had to pick an “unreal” language it would have to be: IBM PC rom basic... yuk!

From: Walrus

Re: Develop,the Apple Tech. Journal

I’m not sure if you can get it thru APDA (but it is worth a try) but for sure you can call the Apple Certified Developers number and get the first issue for free, which includes a CD-ROM. And even if you miss the first couple of issues, never fear, for the CD that comes with the magazine will include all the articles and source code from all PREVIOUS issues! Or you could write to:

develop

P. O. Box 3725

San Diego, CA 92025

The first issue is OK, and I’m sure it will get better, but I keep thinking that if they want to have a first rate magazine, they would do well to emulate MacTutor, adding some Inside Apple stuff that MacTutor would not necessarily have. They could also have some of their people that do the Tech Notes work on it. If I were to ever take a job in technical writing, that’s the group I’d want to work in, good information AND good writing.

But I digress. Anyway, that’s the info for Apple’s foray into magazine publishing....

From: Walrus

Re: Jasik’s Annual MacTutor Article

I’m not necessarily asking any questions or preaching but I do have a few observations on Steve Jasik’s “Marketing Mac Tools” article in the 3/90 edition of MacTutor.

He notes the tough job that any developer of Mac programming tools will have in developing a product and points out that Symantec’s Mac programming tools barely turn a profit. Actually I’m surprised and not surprised. If Symantec is doing that bad than how do the other language vendors do it? The major reason for this is

A) the number of installed Macs and

B) the fact that working on the Mac is “hard”.

As for option B, OOP probably won’t help much because there is a learning curve in object-oriented concepts for procedure-oriented programmers, and although it is interesting and mind-expanding, it is like going back to school. But the real problem with the Mac tool developer is the relatively low installed base of Macintoshes. Apple’s new 1-year warranty and price reduction in the SE line should help, but the time is getting late. A friend of mine bought an MS-DOZE machine because of warranty and price. Apple still has to learn that they MUST suck in the beginning user, get them addicted to the narcotic known as the Macintosh User Interface and they will have a convert for life, buying Mac software and that X percent of computer users who are programmers will buy languages, debuggers, etc. The solution? DROP THE PRICE OF THE MAC PLUS TO A POINT THAT IT CAN COMPETE WITH THE CLONES!

On a related point in Steve’s article, he said APDA loses money, and I’m sure APDA would like everyone to think so, but I think we’re dealing with one of those accounting tricks. They offer no discounts on other party products, and the in-house stuff ain’t no bargain either. Apple may be figuring the cost of the development of alot of the products put out by APDA into the profits from APDA. The problem with that view is that Apple would probably be developing much of it anyway for their own consumption, in which case it would be figured as part of the cost of doing business. For instance, is the development and maintenance of MPW charged against APDA? In that case, I’m not surprised that it operates at a loss, that’s a big product and it’s complicated.

Of course, one way to help fix this is to create more members of APDA by converting the MS-DOS users.

From: Atom

Re: Jasik’s article (cont)

Unfortunately, lots of users reared on MS-DOZE won’t even consider a Macintosh, not because of the old prejudice against GUIs but because of the Mac’s well- deserved reputation for frequent crashes. Until the Mac OS is a lot more robust than it is now you won’t see DOS users coming over in droves, even if Apple decides to undersell the Clones. (I know, that’s a pipe dream!)

From: Lbp

Re: Detecting MultiFinder Article

In reference to the TechNote article, Vol. 6 no. 3, “Detecting MultiFinder”. This method is not correct as per Apple tech note #205. It states that in systems later than 6.0 _WaitNextEvent is available including notification if the cursor location is outside a specified region. Therefore the specified test will not work. What we have tried and seems to work is testing the Multifinder memory trap against the unimplemented trap. In our tests this trap #8F is only available when Multifinder is running.

From: Jmoreno

Re: Detecting MultiFinder Article

I use the toolbox call PBGetCatInfo on MultiFinder in the current system folder. It will tell you if the file is currently open. Just what you need. i.e. set the current WD to the system folder call PBGetCatInfo with @MultiFinderStr as the the value for NameStr.

From: Rick

Re: security

I do alot of work on my home computer and I also let friends use my home computer alot. I do not want to put on passwords on my computer, but is there a good simple program that keeps track of all applications that are run and what files that open, and how long they are open? Something like shareware would be nice because I do not know if this is what I really am looking for.

Any information would be appreciated.

From: Critmidor

Re: FSWrite & Pascal

I’m having a problem using FSWrite from THINK Pascal. The syntax is fine, but the pointer you specify must be a “Signed-Byte” type. I need to be able to write a dynamic variable of type “Byte.” Anybody have any help?

From: Mward

Re: FSWrite & Pascal

This may sound a bit rudimentary, but have you tried typecasting on the call to FSWrite?

From: Siegel

Re: FSWrite & Pascal

The pointer can be the address of anything: @myByte will work even if “myByte” isn’t a signedbyte. However, if you’re writing out a single byte, take the address of a SignedByte; the “Byte” data type in fact takes up two byte.

From: Critmidor

Re: FSWrite & Pascal

Yes, thanks, I got that far, but (unless I’m missing something REALLY basic) FSWrite changes the “Byte” to a “signed byte”: from -127 to +128. It HAS to be from 0 to 255. I’ve tried typecasting the data’s pointer, but not in the actual call yet. I’ll try that ext. Thanks a lot!

From: Jmoreno

Re: FSWrite & Pascal

I’m not quite sure what your problem is (the solution already offered seem fine to me). Why don’t you post your question again, including sample code and the results desired when you read the data back in? By the way are you reading the data back yourself or is it for another app, if it’s just your program, include the line that you use to read the data back.

From: Mward

Re: database

I’ve been using db_Vista for about four months, and while it’s not wonderful (I’ve yet to find a DBMS of any kind that’s wonderful), it’s certainly more than adequate. It’s a network, rather than a relational style database, which is a big plus in my book. If you are not familiar with network databases, it might take some getting used to. The essential difference is that records in a network database contains pointers (called sets) to other related records. So the need to do lots of lookups is minimized. db_Vista is pretty fast - I have not done nor seen any side-by-side comparisons with other products, but I have no complaint on that issue. I have not encountered any problems in defining or implementing any entity-relationship structures, and I tend to like to make these pretty complicated. On the whole, it’s about as nice a DBMS as I’ve seen.

Now the bad news. db_Vista does not support variable length text fields - you have to cram your data into a series of fixed length records and relate them through sets. Not really a big problem, but a bit of a pain. More terrible is that they only support a one-to-many set structure. Each set has one owner and many members, and any record can only belong to (be a member of) one instance of any type of set. That’s kind of hard to understand unless you already know what it means, but what it boils down to is that, in order to implement a many-to-many relationship between two records, you have to define a third file.

Might as well be using a relational database. Also, you end up with LOTS of files in your database.

While the database is well done and mature, the support programs were obviously written by people who did not understand the Mac. They are terrible. They die horrible deaths if they are run under Multifinder - or even if you try using a DA text editor with them. The user interface is awful, they switch from application to application in order to get things done. Basically, they are hack ports of PC programs. For the money they charge I’d think they could put a little more effort into it.

I don’t regret having purchased db_Vista - it’s doing the job I need it for - but I sure wish someone would come out with a real nice DBMS.

From: Macww

Re: database

I also am interested in the db_vista product, but I do not know anything of it personally. However, I thought you might like to know that Apple manufacturing in Freemont, CA used the product to build their own database for the Freemont plant. I suppose that isn’t too bad an endorsement! The only other thought I had was perhaps to contact Raima and ask for the names of a couple of customers who would be willing to talk about the product.

From: Macww

Re: database

<<It’s a network, rather than a relational style database, which is a big plus in my book.>>

Here, here! I am a database neophyte but I must say when I learned what a relational database is, I was incredulous. It certainly isn’t what I would call “relational”, and it seems like an error waiting to happen (unless, of course, you have an enormous overhead of error checking built in).

From: Macww

Re: database

Thanks very much for the pros and cons of db_Vista. As far as I am concerned, the only reviews worth trusting are those you can read on the BBS’s around the country.

From: Rmark

Re: Fourier XCMD to THINK Pascal

I have converted the TML Pascal XCMD to THINK Pascal, but with one problem: the call “penpat(ltGray)” produces a link error for “ltGray”. How can this be fixed?

From: Siegel

Re: Fourier XCMD to THINK Pascal

You can’t use Quickdraw globals (of which ltGray is one) in code resources. the best work around is to use GetIndPattern to get the light-gray pattern from the system pattern list, and use that.

From: Phineas

Re: Building Crashes

I need some help with a problem i’m having using Think C 4.0. My program seems to work perfectly well when run under Think C, but crashes when I try to run it after I have built the application. Any suggestions???

From: Sysop

Re: Building Crashes

I had the same problem with Think Pascal. It turned out the project was corrupt. Try creating a new project.

From: Thehulk

Re: Building Crashes

Are the resources being included when you build the application? Use ResEdit and see if they are. This is a common error that people forget about naming their resource file correctly so that Think C will add them into the build.

From: Gregory

Re: Serial communications

I’m trying to write a simple term program in C for my Mac...I have THINK 4.0 however I’m running into several problems. I am new both to C and to Mac programming...Are there any simple communication examples around to look and play with in think C? Also any book that is highly recommended for new people that covers Mac communications...?

From: Frankh

Re: Serial communications

I know of two C examples; Ters (Terminal Simulator?) and Miniterm. As for books, there aren’t any. There have been two or three articles in MacTutor: “Serial Port Demo” (Pascal) by Tom Scheiderich in the June 1988 issue (pg 54) and my article, Cerial I/O programming (assembly) in the July 1989 issue (pg 78).

You may want to take a look at Apple’s Communications Manager, which will be part of System 7.0; you can get a beta version for $80 through APDA. The Communications Manager is really quite good, and complete. The only drawback is that it’ll only run with system 7 or with a Mac that has had the CM drivers installed.

From: Chips

Re: Imagewriter & THINK c

Does anyone know of an easy way to printf text on an Imagewriter directly from THINK ‘c’ similar to the fprintf(stdprn... of the DOS world.

From: Mward

Re: Imagewriter & THINK C

You should be able to printf to the serial port, named ‘bout’. Open it just like a file and fprintf to it. Now, I haven’t tried this since version 2 of THINK C, but it should still work.

From: Rick

Re: C++

I am new to C++ and MPW. Is there any good documentation to introduce me to MPW style programming? I only switched from THINK C to MPW C++ to work on a true C++ compiler.

I want to compile this simple program to get started:

#include <Stream.h>

int main(void)
{
cout << “Hello, World\n”;
return 0;
}

How does the worksheet work? I would like to create a Macintosh Application to run this simple program or also how do I run it so I can view it in the worksheet?

From: Thehulk

Re: C++

You could simply make your hello world code an MPW tool and then run the tool in MPW.

From: Atom

Re: C++

Joel West’s Programming With MPW is an excellent intro to MPW, although it was written for 2.0.2 and so doesn’t cover Projector. Lippmann’s C++ Primer is great, much more readable than Stroustrup’s original book, plus it covers C++ 2.0. One tip: if all you use from <stream.h> is cout, include <iostream.h> instead, you’ll save on compile time.

From: Mauser

Re: Low-Level Globals

Not having explored this system too much, I’m wondering if there is a table of all of the Macintosh low-level globals and their functions. The list in the IM X-Ref and Thom Hogan’s Mac Sourcebook have huge holes in them. Right now I’m playing with the Cursor Wrap Init from the October ’89 MacTutor and I’m wondering where the author got the address of the Mouse Coordinates. Also, it doesn’t seem to work quite as smoothly as one might think from the code. When the cursor hits the edge of the screen it flies all over the place, as if the Mac IIcx mouse handling routines try to animate the spaces inbetween the mouse jump, give it some velocity and run it off the screen again. (I know that’s not what happens, but it’s a vivid description, and there is a flicker of the mouse in the middle of the screen when it jumps). The reason I’m bothering with Inits at the moment is that at work I’m developing an INIT/cdev to control a video switcher. The Switcher is an external device controlled by the serial port and has nothing to do with the Mac’s video. Anyway, the Init will install itself as a VBL task to give a constant indication of the state of the switch in the menu bar (Ala Superclock). The cdev will do the actual switch controlling, and will update a variable stored at the head of the VBL task to indicate what should be displayed.

This leads to a second question. I forget how to get at the screenPort. How would I draw to the menu bar (like Superclock). I did something to the screenport a long time ago so I know it can be done (I recall it was a SetOrigin. That did some real fun things!). The third and final question in this already-too-long post is: I recall reading a reference to a standard bit of code that’s being passed around for how to display one’s INIT’s icon at startup

From: Arlen

Re: Low-Level Globals

The code you’re thinking of is ShowInit by Paul Mercer (from an idea of Steve(?) Capps). It’s an assembly language routine which I believe can be found in the download library here. There’ also a Lightspeed C 3.0 version included in the Morse CDEV/INIT with no credit given to anyone.

Please use one of them. I have four INITs in my system (Two of them from Symantec!!) whose author’s apparently considered themselves too good to play nice with the rest of the world. I’ve grown to enjoy the INIT parade across my screen at startup, and it’s an unending source of irritation whenever those four nincompoops mess it up. If I didn’t consider them necessary, I’d have trashed them long ago. Excuse me, the count is three. I already trashed one. I’d forgotten about trashing it, but the memory of the irritation apparently lives on.

From: Mauser

Re: Writing to the menu bar.

Has anyone tried getting the Window manager port and writing to that? Will accessing it through the Global ($9DE), particularly at VBL time cause problems?

I’m really hoping someone can answer this. MacDTS?

From: Walrus

Re: MPW Error messages

Am I blind or do the MPW languages (Pascal and Assembly) not have any error messages in the documentation??? I’ve been fortunate so far in figuring out compiler messages, but I’m sure there is one coming with my name on it. I’ve looked for something called error messages, status codes, result codes, all the variations but I can’t find any. I do believe this is the first compiler I’ve bought that doesn’t have a list with the esplanations (as Ricky Ricardo would say). I guess this means every MPW programmer compiles his own list? Or do we just call Tech Support at Apple? (ha ha)

From: Atom

Re: MPW Error messages

I don’t know about Pascal but I sure haven’t found any error messages in either the Assembler or C manuals. And as far as C is concerned, the error messages themselves get on my nerves. I don’t just mean they’re not helpful, they’re downright NASTY sometimes. Like, “A typedef name was a complete surprise to me at this point in your program.” This usually means you’ve forgotten the closing brace at the end of a function. Or the ever popular “Error 247 Huh ?” (No kidding.) The guys that wrote this stuff were probably trying to be funny, as in “Too many errors on one line (make fewer)”, but when you see it every day the humor starts to wear thin. I can’t blame them for not putting this junk in the manual.

From: Siegel

Re: Modifying ‘STR ‘s in LSP on Mac

To modify a STR resource, get a handle to it with GetString. Then use SetString to change it, then call ChangedResource and WriteResource to write it back out, if desired. It sounds as though you’re stomping off the end of the string.

From: Roberts

Re: CDEV Source Code

Can anyone suggest where I can get some sample source code for a basic CDEV? I’m looking for something I can use as an example for a CDEV I want to write in Pascal, and I really don’t have any idea where to start. Thanks in advance.

From: Jhowarth

Re: Smalltalk/V Mac

It is my impression that SmallTalk is better suited to an environment where everything you run is written in SmallTalk. Other than as a SmallTalk learning tool, I don’t think any SmallTalk is actually useful on the Macintosh. For one, they are interpreted or at least tokenized rather than being compiled.

Also, by its very nature SmallTalk is designed that you tote around a large assembly of classes that you create which doesn’t keep the library size down. I believe SmallTalk/V has some sort of runtime feature that allows you to make pseudo-standalone applications. I don’t know if it is bright enough to do a strip link on the libraries you attach to your program. It seems to me that SmallTalk is really more of an OS than just a programming language.

From: Invader

Re: Display Flashing

Almost all drawing of any complexity looks bad when it is done directly on the screen. The usual way to combat this is to do all drawing offscreen and use copybits to actually show the data. This requires allocating memory for the bits on the heap and making a bitmap to point to it. If you are going to keep the bits around for a long time, it is better to allocate them with NewHandle and just lock it down and stash the pointer into the bitmap when you are actually drawing. All this is a lot of work, but well worth it. Look at the Art Class application. Try using the marquee tool to drag something around. There is virtually no flicker. This is because all the drawing is being done this way. It is a lot of trouble, but you have seen the results the other way.