ADVERTISEMENT

Related Info: Script Manager

Tips & Tidbits

By Neil Ticktin, Editor-in-Chief

Tip of the month

Here is a simple routine that returns a Boolean indicating whether the monitor is currently set at black & white or color.

/* 1 */

Boolean IsColorOn( void )
{
 GDHandle hGDevice;
 long   theMode;
 
 hGDevice = GetMainDevice();
 theMode = (**hGDevice).gdMode;
 theMode &= 0x0000000F;
 
 if( theMode != 0 ) return( true );
 else return( false );
}

I figured out how to write this piece of code after struggling with the concept for many months. It’s not a very complex routine, but I searched through every source I had available and never found anything that explained how to do it. I hope this will help others having the same problem.

- Marc White, Corinth, Mississippi

Script Manager Pitfall

If you plan to work with non-Roman script (such as Kanji, Arabic, Hebrew, etc ), there is a subtle - but important - point that Inside Macintosh will not tell you.

Script Manager functions can return wrong answers if the appropriate font is not set in the current GrafPort.

For example, there is a Script Manager function called CharByte which tells you if a given character is part of a two-byte script (or not). After reading the description of CharByte in Inside Macintosh, you will conclude it will know the right answer simply by looking at a piece of text. Wrong!

Unless the current font is a Kanji font, CharByte has no way of knowing that a given character is part of a double-byte Kanji character or whether it is a single-byte Roman character.

The reason is all 256 byte values are “valid” for all Roman fonts. If the current font is, say, Geneva, CharByte will think that 1/2 of a Kanji byte is really a single Roman character.

This is neither clear in Inside Macintosh Vol 5 nor the World Script section in Vol 6, but it is a fairly major point!

- Gar, DataPak Software

Apple’s Lame Disk Cache

After seeing significant I/O performance problems with large disk caches (set via the Memory control panel) I decided to run some benchmarks. I wrote a little application that would write a 400K file to a hard disk in 8K sector aligned chunks with various disk cache sizes and return to me the number of ticks that it took. Here are the results:

400K write

32K 50 ticks

64K 50 ticks

96K 51 ticks

128K 50 ticks

192K 50 ticks

256K 50 ticks

384K 691 ticks

512K 681 ticks

1024K 681 ticks

7680K 678 ticks

It appears that the Apple’s disk cache scheme hits a wall at 384K (in this test, anyway). I linked DTS with these results and got an interesting reply. It turns out that their disk cache scheme is optimized for very small reads and writes - like an application reading one byte at a time from a file without doing it's own buffering. I guess this was a problem back when most people used floppies and small hard drives. But modern apps usually do their own file buffering anyway (read a big piece into a buffer and then take it out of the buffer one byte at a time), so the Apple disk cache scheme becomes more of a hinderance than a help.

Not all reads and writes are cached by the Apple scheme. The formula it uses to decide if any given read or write should be cached is:

/* 2 */

numCacheBlocks = user-defined cache size DIV 512;
maxCachedReadWrite = (numCacheBlocks - 1) * 16;

So, with a cache size of 256K you get:

numCacheBlocks = 512
maxCachedReadWrite = 8176

That means that any read/write larger than 8176 bytes or larger will not be cached. So in my test app, nothing was being cached until the cache was 384K or larger, at which time my 8K writes were being cached (and I got a 13x performance slow-down).

There is hope, though. Page 2-95 of the new Inside Macintosh File Manager documents the "no cache" bit of ioPosMode. You can set bit 5 of ioPosMode to prevent your reads and writes from being cached. I strongly recommend you do this except in those few cases where you know you're going to need the data again right away or where you're not doing your own intelligent sector-aligned buffering. When I set this bit in my test app, my times for writing 400K with very large caches were the same as those for writing 400K with very small caches.

That's great for your code but what about other code that you can't control and that doesn't take advantage of bit 5 of ioPosMode? The only real defense is to reduce your disk cache to the minimum (32K) at which time only very small reads and writes will be cached (1008 bytes or less). But in my own tests with compiling large projects under MPW and Think C I have found that a disk cache size of 128K gives the fastest build times. You should do your own timings based on what type of I/O operations you do most.

- Mike Scanlin

Useless Trivia or a tip?

This is perhaps more fit for “Useless Trivia” than is is for “Tips and Tidbits,” but no matter, here it is:

Nearly every piece of C code that I ever see (even in MacTech Magazine) uses parentheses around all return statements. People always seem to write:

int theirfunc()
{
  .
  .
  return (1);
}

Even the examples in K&R itself use parentheses around the return statments. But look at the actual syntax reference in K&R: “if,” “while,” “for,” and “switch” all require parens, but “return” does not. For years, using many compilers, on many machines, I've been writing:

int myfunc()
{
  .
  .
  return 1;
}

It may look odd, but try it - it does work!

- Ken Gladstone