Blog › ICP guides

SuperCard developer on retainer: AFP network write collision, Allegiant SuperCard developer, SuperCard kiosk developer on monthly retainer

October 9, 2026 · ~15 min read

A SuperCard developer was maintaining a museum interactive kiosk application for a natural history museum. The museum had 4 Mac OS X 10.5 Leopard kiosk stations, each running the same compiled SuperCard 4.7.2 runtime — the SuperCard Viewer standalone application bundle. Each kiosk station ran an interactive exhibit about prehistoric marine life; visitors could navigate through cards, answer quiz questions, and request printed fact sheets. At the closing screen of each exhibit visit, a SuperTalk handler named logVisitorInteraction appended a visitor interaction record to a shared log file at /Volumes/MuseumServer/kiosklogs/visitor_interactions.txt on a Mac OS X Server AFP volume. During busy periods — weekend afternoons with school groups — the museum’s IT coordinator noticed the visitor_interactions.txt log consistently showed 3–5 fewer records per day than the mechanical door counter showed visitors. No error dialog appeared on any kiosk station. The closing screen on every station functioned normally; visitors received their printed fact sheets without incident. The interaction record was silently lost with no visible indication to staff or visitor. Silent visitor interaction records lost per busy day: 3–5 → 0 after switching to per-station log files (visitor_interactions_station1.txt, visitor_interactions_station2.txt, visitor_interactions_station3.txt, visitor_interactions_station4.txt) merged nightly by an AppleScript consolidation job scheduled via launchd on the Mac OS X Server.

The root cause was a concurrent write collision at the AFP (Apple Filing Protocol) layer. SuperCard’s open file filename command on an AFP network-mounted volume opens the file using POSIX open() with O_RDWR | O_CREAT. AFP advisory byte-range locking — available via fcntl F_SETLK — is accessible to POSIX code running on Mac OS X, but SuperCard does not use advisory locks. It simply opens the file with no coordination mechanism and no exclusive lock request. When two kiosk stations both call logVisitorInteraction within the same 1-second window, the following sequence unfolds: Station 1 opens visitor_interactions.txt (AFP open succeeds — no exclusive lock); Station 2 opens visitor_interactions.txt (AFP open also succeeds — no exclusive lock); Station 1 executes seek to end of file "visitor_interactions.txt" and receives EOF position 4,820 bytes; Station 2 executes seek to end of file "visitor_interactions.txt" and also receives EOF position 4,820 bytes, because Station 1 has not written yet; Station 1 writes its 180-byte visitor record at position 4,820, and the file grows to 5,000 bytes; Station 2 writes its 180-byte visitor record starting at position 4,820 — its cached seek position — overwriting Station 1’s record entirely; the file remains 5,000 bytes; Station 2 closes its file handle; Station 1 closes its file handle. The result: Station 1’s visitor record no longer exists in the file. Only Station 2’s record survives at that offset. The log shows one visitor where two visited simultaneously; the museum’s weekly analytics report is short by exactly the number of same-second concurrent visit completions across the busiest hours.

The invisibility of the bug has two layers. First, no error is raised on either kiosk station. AFP’s advisory lock model means that absent an explicit fcntl F_SETLK request, no OS-level conflict is detected: from the OS perspective, two processes each hold valid open file descriptors, each perform a legal lseek to EOF, each perform a legal write at a valid offset, and each call close successfully. The second write is a legal overwrite of bytes that the OS did not know were reserved by the first writer. SuperCard receives no error from any of these file operations. The logVisitorInteraction handler exits normally. The closing card displays the “Thank you for visiting” message as designed. Second, the developer who tested the kiosk application during development and acceptance testing never activated two stations simultaneously because the test environment had only one station configured at a time. With one writer, seek to end of file always returns a unique position, the write always lands at a fresh offset, the record is always preserved. The bug is structurally invisible to all standard single-station testing.

SuperCard history: from Silicon Beach Software through Allegiant Technologies to IncWell Digital Media

SuperCard was created by Bill Appleton at Silicon Beach Software in 1986. Silicon Beach Software was a Macintosh software company based in San Diego, California, known for products including SuperPaint and Digital Darkroom. Appleton designed SuperCard as a more powerful Mac alternative to Apple’s HyperCard, which Apple had begun bundling with every Macintosh in 1987. HyperCard’s fundamental constraint for professional developers was its single-window model: HyperCard could only display one card at a time in one stack window, all content was black-and-white (color was not added until HyperCard 2.3 in 1993), and its scripting language HyperTalk, while pioneering for its English-like syntax, had limited support for multiple simultaneous data contexts.

SuperCard’s key distinctions from HyperCard at launch were significant. A SuperCard project could contain multiple stacks, each of which could be open simultaneously as a separate window. A museum kiosk application in SuperCard could have a navigation palette window, a content display window, and a quiz window all open at once, with SuperTalk handlers passing messages between them using send message to window. SuperCard supported full color graphics from its initial release — a major differentiator in the late 1980s when HyperCard remained black-and-white. SuperCard also provided a richer set of object types: in addition to HyperCard’s cards, backgrounds, buttons, and fields, SuperCard added graphical objects (shapes drawn directly on cards), picture objects (imported images as distinct card objects), and a more expressive object reference syntax for targeting specific windows, buttons, and fields by name across the multi-window project. The SuperTalk scripting language was a superset of HyperTalk, carrying HyperTalk’s English-like syntax (on mouseUp, go to card, put value into field) and adding the inter-window communication architecture.

Silicon Beach Software was acquired by Aldus Corporation in 1990; Aldus subsequently sold the SuperCard product line to Allegiant Technologies, a San Diego company that took over development and marketing from 1989 through 1998. Under Allegiant, SuperCard matured through several releases that extended its kiosk and interactive multimedia capabilities. Allegiant’s SuperCard gained wider adoption in museum kiosk deployments, trade show interactive presentations, airport information kiosks, and educational software published on CD-ROM for Macintosh. The Allegiant-era SuperCard products — SuperCard 1.x, 2.x, and 3.x — ran on Mac OS 6 through Mac OS 9 and were widely deployed on Mac LC, Centris, Quadra, and Power Macintosh hardware in institutional settings throughout the 1990s. Many of those institutional deployments — museums, science centers, libraries, corporate training centers — remained in production on classic Mac OS hardware well into the 2000s, creating the retainer market that persists today for SuperCard specialists.

Allegiant ceased active SuperCard development in 1998. The product went through a period of uncertainty until IncWell Digital Media, a small Mac software company, acquired the SuperCard intellectual property in 2001 and released SuperCard 4.0 with Mac OS X compatibility. IncWell’s contribution was bringing SuperCard into the Carbon and Cocoa era of Mac OS X, allowing the enormous installed base of SuperCard kiosk projects to run on Mac OS X 10.1 through 10.6 Snow Leopard hardware. IncWell released SuperCard 4.5, 4.6, and the final version SuperCard 4.7.2, which was the last Mac OS X Leopard and Snow Leopard compatible release. IncWell ceased active SuperCard development around 2009. SuperCard 4.7.x does not run natively on Mac OS X 10.7 Lion or later (which dropped Rosetta, the PowerPC-to-Intel translation layer that earlier SuperCard versions depended on in their Carbon implementation). The consequence for retainer developers is that SuperCard kiosk deployments are frozen on Mac OS X 10.5 Leopard or 10.6 Snow Leopard hardware — machines that are now 15–17 years old, running without security updates, and maintained only by the original deploying institution’s IT department with support from a SuperCard specialist on retainer.

The primary migration path for SuperCard deployments is LiveCode (formerly known as Runtime Revolution, then Revolution). LiveCode’s scripting language, also called LiveCode Script, is a direct descendant of HyperTalk and is syntactically very close to SuperTalk: on mouseUp, go to card, put value into field, open file, read from file, and close file all work in LiveCode with the same syntax as in SuperTalk. A SuperCard developer migrating a kiosk project to LiveCode can typically port the SuperTalk handlers with modest adaptation; the main labor is in the project structure (LiveCode uses stacks and cards similar to SuperCard’s model), media re-embedding (LiveCode handles images and audio as resources in the stack file or as externally referenced files), and the inter-window messaging architecture (LiveCode uses send to named stacks and cards). The per-station log file fix that resolves the AFP write collision bug works identically in LiveCode: open file (logDir & "visitor_interactions_station" & stationID & ".txt") followed by a write and close, with the same guarantee that a sole writer per file eliminates all collision risk.

SuperTalk file I/O and the AFP advisory lock gap

SuperTalk’s file I/O command set follows the same English-like idiom as the rest of the language. open file filename opens a file for read/write access (creating it if it does not exist). read from file filename until return reads characters from the current file position until a carriage return character is encountered. read from file filename until end of file reads the entire remaining content from the current position. write text to file filename writes a string at the current file position. seek to end of file filename moves the file position pointer to the byte immediately following the last byte in the file — the standard append-positioning operation. seek to beginning of file filename moves the file position pointer to byte 0. close file filename closes the file and releases the file descriptor. There is no lock file filename command in SuperTalk. There is no open file filename for exclusive access variant. There is no built-in mutex, semaphore, or advisory lock API accessible from SuperTalk. The developer who needs to coordinate concurrent file access across multiple SuperCard sessions must implement coordination entirely outside the SuperTalk file I/O command set.

The AFP advisory lock gap is the precise technical reason the write collision is invisible. POSIX advisory byte-range locking via fcntl(fd, F_SETLK, &flock) allows a process to declare that it intends to write to a specific byte range of a file and to receive an error (EACCES or EAGAIN) if another process holds a conflicting advisory lock on an overlapping range. The key word is advisory: the OS only enforces the lock between processes that both participate in the advisory lock protocol. A process that opens the file without requesting an advisory lock can read and write any byte in the file regardless of what advisory locks other processes hold. Since SuperCard’s open file implementation does not request an advisory lock, both kiosk stations can open the file, both can seek to EOF, and both can write at the same offset — all without any OS-level conflict. The AFP server (Mac OS X Server running AFP) relays the file operations faithfully because neither client requested a lock. The second write silently overwrites the first. The only coordination mechanism that works without modifying the SuperCard runtime is to eliminate the shared resource: per-station log files, one per station, each written by exactly one writer.

A lock-file approach is also possible in SuperTalk, using the file system itself as a mutex: before opening visitor_interactions.txt, the handler attempts to create a lock file at /Volumes/MuseumServer/kiosklogs/visitor_interactions.lock using open file lockPath and checking whether the file already existed (non-zero size). If the lock file already exists, the station waits and retries. If the lock file does not exist, the station creates it, writes the log record to the main file, and then deletes the lock file. This approach has its own failure mode: if the SuperCard Viewer crashes while holding the lock file, the lock file persists and all subsequent stations wait indefinitely. The per-station file approach eliminates this failure mode entirely. The museum’s nightly AppleScript consolidation job — scheduled via a launchd plist on the Mac OS X Server — reads all four station log files, sorts the records chronologically by the timestamp embedded in each record, writes the consolidated visitor_interactions_merged.txt file, and archives the four station files with a date suffix. Interaction record losses: 3–5 per busy day → 0.

Typical SuperCard developer retainer work and what it looks like in a work log

AFP network write collision on shared visitor interaction log is the canonical SuperCard invisible production kiosk deployment bug. The pattern is consistent: a SuperTalk handler in the closing card’s on closeCard or on mouseUp of the “Finish” button calls open file "/Volumes/MuseumServer/kiosklogs/visitor_interactions.txt"; seek to end of file "visitor_interactions.txt"; write (stationID & "," & visitorTimestamp & "," & quizScore & return) to file "visitor_interactions.txt"; close file "visitor_interactions.txt". The developer tests with one kiosk station — no collision possible. In production, four stations run concurrently; two visitors complete the exhibit and reach the closing card within the same 1-second window; both stations seek to EOF and receive the same byte position; both stations write their 180-byte records at that position; the second write overwrites the first; the file length does not change; both stations close their file handles without error; both closing cards display normally. The museum’s daily analytics count shows 3–5 fewer records than the door counter. Work log: “MarineLifeExhibit SuperCard project; closing card on closeCard handler; open file & seek to end of file on AFP volume /Volumes/MuseumServer/kiosklogs/visitor_interactions.txt; no advisory lock; 4 concurrent kiosk stations; same-second concurrent seeks return same EOF offset; Station 2 write overwrites Station 1 write; 180-byte record silently lost; 3–5 per busy day; fix: per-station log files (visitor_interactions_stationN.txt); nightly AppleScript merge via launchd; losses: 3–5/day → 0; 3h.”

SuperTalk memory leak on navigation loop in a long-running kiosk session is the second most common SuperCard retainer pattern in museum deployments where the kiosk runs continuously for 8–10 hours per day. A SuperTalk handler in the main navigation card uses open file "/Volumes/MuseumServer/content/exhibit_data.txt" to load dynamic exhibit data for each card visit, reads the relevant lines, and then continues navigation without calling close file. Each card visit opens a new file descriptor to the same file path. On Mac OS X, the per-process file descriptor table limit is 256 by default (configurable via launchctl limit maxfiles but not by default on museum kiosk hardware). After 256 card visits during a busy afternoon, SuperCard exhausts the file descriptor table; subsequent open file calls fail silently (SuperCard does not raise an error dialog for a failed open file in most error configurations); read from file returns empty; exhibit data fields display blank or retain stale content from the last successful read. Visitors at the kiosk see blank content fields with no explanation. The kiosk must be restarted. Fix: add close file "/Volumes/MuseumServer/content/exhibit_data.txt" at the end of each navigation handler, or restructure the handler to open the file, read the required data, and close the file within a single handler invocation. File descriptor exhaustion after N card visits: 256 → never (file always closed after read). Work log: “MarineLifeExhibit SuperCard project; navigation handler in MainMenu card script; open file without close file on each card visit; file descriptor leak; 256 visits to exhaust fd table on Mac OS X 10.5; exhibit content fields blank after exhaustion; kiosk restart required; fix: close file added at end of navigation handler; fd leak: 1 per card visit → 0; kiosk session stable for full 10-hour operating day; 2h.”

SuperCard project migration to LiveCode is the third major SuperCard retainer engagement category, and typically the largest by hours. A museum with a SuperCard 4.7.2 kiosk deployment on Mac OS X 10.5 Leopard hardware is running machines that are past end-of-life for Apple security updates, cannot be upgraded to current macOS without replacing the SuperCard Viewer application, and are increasingly difficult to maintain as the hardware ages. The retainer developer scopes the migration to LiveCode by inventorying: total card and stack count across the SuperCard project; all SuperTalk file I/O handlers (every open file, read from file, write to file, close file call, with its target path and concurrency risk profile); all send message to window inter-window communication patterns (migrated to LiveCode’s send to named stacks); all external media references (images, sounds, video) and whether they are embedded in the project or externally linked; all printing logic (print card, fact sheet dispatch handlers); and all custom external function calls or AppleScript calls from SuperTalk. SuperTalk’s do AppleScript command for shell integration migrates to LiveCode’s do shell script or do script command with equivalent syntax. The per-station AFP log file pattern from the write collision fix migrates to LiveCode verbatim: open file (logDir & "visitor_interactions_station" & stationID & ".txt") is syntactically identical in LiveCode Script. Work log: “MarineLifeExhibit SuperCard 4.7.2 project; migration scope to LiveCode 9.6; 3 stacks, 47 cards, 12 SuperTalk file I/O handlers, 6 inter-window send handlers, 23 externally linked media files, 1 printing handler; AFP write collision fix (per-station log files) migrates verbatim; estimated migration: 24h; scoping report delivered; 4h.”

How HourTab tracks SuperCard developer retainer hours

SuperCard AFP write collision bugs are invisible by exactly the same mechanism that makes all concurrent file I/O bugs invisible in single-station development testing: with one writer, seek to end of file always returns a unique position because no other process holds an open file descriptor at a position between seeks. The write always lands at a fresh offset. The record is always preserved. The close file completes without error. The SuperTalk handler exits normally. The kiosk works perfectly. Only when two concurrent sessions both call seek to end of file within the same sub-second window — a condition that requires simultaneous visitor activity on adjacent kiosk stations — does the collision occur. Because the collision rate is proportional to concurrent throughput, it is nearly undetectable in low-traffic periods and becomes a consistent daily loss only during the museum’s busiest hours. The museum’s IT coordinator noticed it only because she compared the log record count against the door counter at the end of a particularly busy school-group Saturday. There was no error in any log file, no alert from any monitoring system, and no complaint from any visitor.

The work log must name the mechanism to be auditable: which SuperCard project file (MarineLifeExhibit.sc), which SuperTalk handler (logVisitorInteraction in the closing card script), the open file path (/Volumes/MuseumServer/kiosklogs/visitor_interactions.txt on AFP volume), the seek mechanism (seek to end of file, no advisory lock, concurrent dual-seek collision), the concurrent station count (4 Mac OS X 10.5 kiosk stations), the interaction records lost per busy day before fix (3–5 silent overwrites on peak days), the records lost after fix (0), and the fix (per-station log files visitor_interactions_station1.txt through visitor_interactions_station4.txt; nightly AppleScript consolidation job via launchd on the Mac OS X Server). A log entry that says “fixed logging issue on museum kiosk, 3h” is not auditable. A log entry that names the project, the handler, the AFP path, the byte-offset collision mechanism, the silent data loss count, and the per-station-file fix is auditable and defensible to the museum’s exhibit director, development team, and IT department. HourTab gives SuperCard developers a public retainer-hours URL they send to clients — natural history museums, science centers, children’s museums, library systems, and corporate training departments that deployed interactive kiosk and educational applications in SuperCard during the Allegiant Technologies and IncWell Digital Media eras, maintained today by the original deploying developer or a successor retainer consultant.

The broader context for SuperCard retainer billing is that the clients who run these deployments typically have no direct awareness of the platform they are running. A museum exhibit director knows the kiosk shows dinosaur cards and tallies quiz scores; she does not know that the application is compiled SuperCard 4.7.2 running on a Mac OS X 10.5 machine that has not received a security update since 2009. When 3–5 visitor records disappear per busy day, her first instinct is to ask whether the door counter is malfunctioning or whether visitors are leaving without completing the exhibit. The SuperCard retainer developer’s role is to establish the causal chain: door counter accurate, visitor completion rate consistent, log file record count consistently short by 3–5 on peak days, time-window analysis shows the missing records cluster at the busiest concurrent-visit periods, SuperTalk handler uses unguarded seek to end of file on AFP volume, AFP advisory locks not used, concurrent seek collision produces silent overwrite, per-station files eliminate the collision entirely. That causal chain, named precisely in the work log, is the artifact that justifies the retainer hours and builds the trust that sustains the retainer relationship.

Comparative context: SuperCard AFP write collision bugs are structurally related to concurrent file I/O patterns in other HyperTalk-family platforms where the scripting language’s file I/O commands lack a built-in coordination mechanism. HyperCard developer retainers cover the same HyperTalk-family file I/O model — open file, seek to end of file, write to file, close file — with the same absence of advisory lock coordination, the same silent overwrite on concurrent kiosk deployments, and the same per-station file fix. Lingo developer retainers cover Director’s FileIO Xtra exclusive lock pattern on shared network kiosk log files — a related but distinct mechanism where the second concurrent station receives an OS file-sharing violation error rather than a silent overwrite, but the outcome (one visitor interaction record silently lost) and the fix (per-station log files consolidated server-side) are identical. LiveCode developer retainers cover the same read-modify-write lost-update pattern on shared network files in the direct successor platform to SuperCard — relevant to SuperCard retainer developers scoping or executing a migration from SuperCard 4.7.x to LiveCode, because the file I/O architecture and the concurrent-write risk profile carry forward verbatim into the migrated LiveCode stack.

FAQ: SuperCard developer retainers