Global Handlers

Date:    Wed, 15 Nov 1995 11:20:12 EST
From:    John Dowdell <71333.42@COMPUSERVE.COM>
Subject: Re: List related bugs and dummy (tummi) bugs #2

Andreas Viviani posts, on Nov 14, a series of tests that show that lists can be larger on the Mac than on Win.

Yes, this is true, and it's been in the Knowledge Base and online since last spring. Windows 3.1 uses a segmented memory model. Segments are 64K in size. A list needs to fit into a single segment. Therefore, a list on Windows needs to be 64K or less.

In practice this works out to about 10K elements for a linear list, roughly half for a property list. Precise numbers vary with the size of the entries.

Although you don't mention it here, Andreas, I'd like to repeat the other related warning, too:

Global handlers are also stored in a list. This is the same list that holds all Lingo reserved words ("sprite", "foreColor" etc). In this single list of reserved words are also held all symbols and all parameters passed to global handlers. This list, like others, cannot exceed 64K in size on PCs.

(A "global" handler is one accessible throughout the movie... it is a handler stored in a movie script. A handler stored in a private sprite or cast script is in its own, separate list. All global terms for reserved words, handler names, global variables, user-defined symbols and arguments to handlers are stored in a single list of global keywords.)

This special list persists for the life of the application. If you branch to a new movie prior entries will persist.

This list stores only unique names. If you use the same handler name in two sequential movies then it does not create a new entry in this symbol lookup table. If you use the same parameter names in different global handlers then it does not create new entries in this symbol lookup table. It only stores unique names.

(This is related to some parts of the "symbol case" issue discussed earlier this week on the list... because "cos" is a reserved word it is already in the symbol lookup table, and so Lingo will not create a new entry for the term.)

This past summer I saw the first case of a developer breaching this single-segment symbol list. The symptom was that their (very script-heavy) movies worked fine through development, and fine on the Mac, but when they added a script-heavy Shared Cast and did the final "port" to the PC <thunderclap at phrase> they then saw error messages such as "Undefined handler: on? startMovie" and other oddities. This occurred because the symbol list table exceeded a single 64K memory segment. Running without the Shared Cast and restarting Director removed the problem; it was the addition of scripts in the Shared Cast that broached the wall.

Since then I've seen two other developers come across this. Significantly, all chose to develop on Mac and "port" instead of using the dual-authoring environment. All were also past deadline already.

Remedies for exceeding the segment bounds of the symbol list include:

Use object-oriented scripting. This would be recommended anyway for large, heavily scripted projects. Complex projects can be simplified in any environment by reducing the number of global variables and global methods. Removing these data and behaviors from global scope also removes them from the global symbol list, too.
Reuse parameter names. If passing arguments to global handlers, then new placeholder names add new symbols. Using the same placeholder names in different handlers will reduce the additions to the symbol table.
Reduce subroutines in global scripts. Roll them into the calling handlers.
Check symbol usage. Although symbols are faster than strings, each new symbol is listed in the symbol lookup table. If your property lists can use strings instead of symbols, then there would be fewer additions to the symbol lookup table. (Be careful of case and diacriticals when using "getaProp" on string property names, though.)
Put related global variables into data structures. A list of global scope can hold a number of related variables. A parent script can define a struct; it does not need to hold any behaviors.

The segmented memory model is unique to Windows 3.1 and its variants. Windows 95 has moved to a flat memory model. When Director 4 runs in Win95 the memory code does not change, but the next version of Director will be optimized for Win95. There will still have to be some accomodation of Win3.1 playback, however, and I'm not yet sure how this will be handled.

You can determine how many entries are currently in the symbol lookup table by doing an arithmetic operation on a newly-created symbol, such as by typing into the Message Window:

  put #HarryBrowne * 1
  --  533

This shows that there are 532 prior entries in that table. I don't yet know of a way to retrieve the name of a symbol by its index. I also don't yet know how to tell how much space the symbol table currently consumes.

Thanks for bringing this up again, Andreas... although it's been discussed before, if this info reaches new eyes and speeds someone's work, then that would be great.