The computing historian or researcher

Stacks Today The practitioner's archive for HyperCard stack development Stacks Today is a rigorous technical archive of HyperCard development as it was actually practiced between 1987 and 2004. The publication exists because the practitioner record — the techniques, design decisions, extension mechanisms, and commercial ecosystem that made HyperCard a living platform — is scattered across out-of-print books, unsearchable scans, decaying forum threads, and fading memories. No single resource organizes this knowledge into a navigable, citable, maintainable corpus. Stacks Today fills that gap. Success means completeness and accuracy: a computing historian who consults an entry can cite it with confidence, and a returning developer who opens it alongside Basilisk II finds precise, trustworthy guidance. The mechanism is straightforward: each entry reduces a recurring uncertainty that currently forces researchers and practitioners to reconstruct answers from fragments. When a historian needs to understand the XCMD callback architecture, or how background sharing strategies worked in commercial stacks, or what the third-party extension marketplace looked like — they find it here, cross-referenced and sourced. The publication earns its place by being the resource people point to instead of explaining the same thing again. Over time, coverage compounds: entries interlink, gaps close, and the corpus becomes the definitive technical record of HyperCard as a platform. The editorial approach inherits Danny Goodman's standard — technically authoritative, written in plain English, treating the reader as capable without assuming expertise. Every entry is written to be understandable by an attentive general reader while meeting the precision threshold a specialist demands. Authority comes from explicit editorial standards — transparent about what counts as evidence and how errors are corrected — and from earning recognition from the practitioner community as the reference that gets things right. To serve as the single structured, citable reference for HyperCard development knowledge — the language, the design practice, the extension system, the commercial ecosystem, and the tools — organized for retrieval and maintained for accuracy. The publication is an archive, not a feed: its value lives in the accumulated corpus, not in any individual update cycle. HyperCard as an Apple product and as a platform economy, 1987–2004. This includes: HyperTalk (the scripting language, object hierarchy, message passing, and scripting patterns); stack architecture (design principles, structural conventions, UI patterns from Apple's guidelines); XCMDs and XFCNs (the extension mechanism, entry-point conventions, callback architecture, resource fork packaging, and the vendor ecosystem); the platform economy (retail stacks, the shareware scene, third-party tools, developer-publishers, and the HyperCard press); and development tools and practice (Apple's Developer Toolkit, debugging approaches, authoring tools, and workflow context). Coverage treats HyperCard as a complete platform with its own industry, not merely as a software application. - Successor tools and lineage: LiveCode, OpenXTalk, SuperCard, Decker, and other xTalk descendants or spiritual successors are out of scope. The archive boundary is HyperCard itself and the ecosystem that formed around it during its active life. - Emulation setup and "running HyperCard today" operational guidance: useful but outside the archival mission. The publication documents the platform as it was, not how to access it now. - Beginner introductions to HyperCard: "what is HyperCard?" content is well-served elsewhere. Entries assume the reader knows what HyperCard is and cares about how it worked in depth. - Nostalgic or cultural retrospectives: the publication is a technical record, not a appreciation piece. Historical context serves precision, not sentiment. - Granular command-by-command language reference: the HyperCard Center already webifies the HyperTalk Reference. Stacks Today covers language concepts, patterns, and architecture — not a duplicate syntax listing. The computing historian or researcher Someone writing about hypermedia's prehistory, analyzing HyperCard stacks as cultural or technical artifacts, tracing the genealogy of ideas that became the web, or building a serious account of personal computing history. They need technically accurate, citable reference that goes beyond Wikipedia's surface — the kind of source that can anchor a footnote in a paper or book. They may be an academic, a journalist covering computing history, or a serious independent researcher. They use the publication as a primary reference: looking up specific technical details (how did message passing actually work?), verifying claims about HyperCard's capabilities, understanding the commercial ecosystem, and cross-referencing entries to build a complete picture. They need stable URLs, clear sourcing, and entries precise enough that citing them doesn't require independent verification. What will lose them instantly: factual errors about HyperCard behavior, invented technical details, or nostalgia-inflected writing that signals the publication is cultural commentary rather than technical record. They have access to Goodman's books and Apple's documentation in scan form — the publication must demonstrably add value over reading those originals, through organization, cross-referencing, and synthesis rather than through novelty. They can cite Stacks Today as a reliable technical source in serious published work — a paper, a book chapter, a long-form article — without needing to independently verify every claim against primary sources. The underlying stake: their professional credibility depends on the accuracy of their sources, and for HyperCard's technical record, no citable structured reference currently exists. The returning developer who thinks historically Someone who learned HyperCard in school or at work in the late 1980s or early 1990s, recently rediscovered it through emulation or the Internet Archive, and now wants to go further than they ever did. They remember enough to be dangerous — the feel of the Message Box, the basics of handlers and buttons — but the advanced techniques (XCMD integration, multi-stack architecture, performance optimization, sophisticated scripting patterns) are new territory. They approach HyperCard with a historian's curiosity even when their immediate need is practical: they want to understand *why* things work the way they do, not just copy a script. They use the publication mid-session: Basilisk II is open in another window, they're building or exploring a stack, and they need a precise answer about object hierarchy behavior, background sharing strategy, or how a particular XCMD pattern works. They also browse for depth — reading architectural entries to understand design decisions they never questioned as a novice. What will lose them: condescension (they are not beginners), padding (they have limited time and a stack waiting), or imprecision (they will test what they read immediately and discover errors within minutes). They can resolve a technical question or design decision in minutes instead of the current process of searching across PDFs, forum archives, and scattered blog posts — and they trust what they find enough to apply it without a second source. The underlying stake: their limited hobby time is wasted on archaeology when it should be spent building. Write in the Danny Goodman tradition: technically authoritative, plain English, direct. Address the reader as a capable person who may not have specialized background in the specific topic at hand. Use second person sparingly and naturally — "you" for procedural context, not as a rhetorical crutch. Favor concrete explanation over abstract summary. Lead with what the thing is and why it matters before explaining how it works. Every entry should be understandable to an attentive general reader while meeting the precision threshold a specialist requires — this is achieved through clear exposition, not by dumbing down. Warm but not casual. Authoritative but not academic. The register is that of a knowledgeable colleague explaining something clearly at a whiteboard — neither a textbook nor a blog post. Respect the reader's intelligence and time equally. Avoid hedging language when the facts are known; acknowledge genuine uncertainty or contested points directly. Permitted when it arises naturally from the material — Goodman's books had personality without performing it. Never force levity. Never use humor to soften a lack of substance. The publication is a technical record, not an argument for HyperCard's significance. Let the documented facts carry whatever cultural weight they carry. Do not editorialize about what Apple should have done, what the industry lost, or how HyperCard predicted the future. If a design decision was controversial among practitioners at the time, present the positions; do not adjudicate. Where the historical record contains genuine disagreements (design philosophy debates, competing approaches to stack architecture, Apple's internal decisions about HyperCard's direction), present them as the record shows. Attribute positions. Do not flatten real disagreement into false consensus, and do not amplify minor disputes for narrative interest. Use HyperCard's own terminology precisely — stack, card, background, field, button, handler, message, chunk expression, XCMD, XFCN, user level — and define terms on first substantive use within each entry. Do not substitute informal equivalents for official terminology (e.g., do not call handlers "functions" or backgrounds "templates" for accessibility). The reader learns the correct vocabulary by encountering it in context with clear explanation. Every substantive technical claim should be traceable to a primary or strong secondary source: Apple's official documentation, Goodman's published books, the HyperCard Script Language Guide, Apple Technical Notes, or contemporaneous coverage in Macworld, MacUser, or similar publications. When synthesizing across sources, make the synthesis visible — "Apple's guidelines specified X; Goodman's practice was Y." When a claim cannot be sourced to a specific document, say so: "This convention is widely attested in practitioner accounts but does not appear in Apple's official documentation." Never present synthesized inference as documented fact. The subject matter is historical; nothing in the core record changes. Entries should be written as durable reference — present tense for describing how HyperCard works ("the message hierarchy passes messages from..."), past tense for historical events ("Apple released HyperCard 2.0 in 1990"). Include version-specific information where behavior changed between HyperCard versions, and always specify which version is being described when version matters. Primary sources take precedence: Apple's official documentation (HyperCard Script Language Guide, Stack Design Guidelines, Technical Notes, Developer Toolkit documentation), Danny Goodman's published books (The Complete HyperCard Handbook, HyperCard Developer's Guide), and the HyperTalk Reference stack (available as PDF and via HyperCard Center). Contemporaneous trade press coverage (Macworld, MacUser, BMUG newsletters) serves as strong secondary sourcing for ecosystem, commercial, and community claims. Internet Archive's HyperCard collection is a primary source for stack examples and emulation context. The Vintage Apple PDF archive at vintageapple.org hosts scannable versions of key books. Modern retrospectives, blog posts, and forum threads are tertiary — useful for identifying topics and cross-checking claims, but not sufficient as sole sources for technical assertions. - **Nostalgia distortion:** Most modern writing about HyperCard is impressionistic and culturally oriented. Claims about what HyperCard "could do" or "was like" in retrospective articles frequently overstate capabilities or conflate different versions. Always verify against primary technical documentation. - **Version conflation:** HyperCard changed significantly across versions (1.0 through 2.4.1). Capabilities, syntax, and behavior differed. Sources that describe "HyperCard" without specifying version are unreliable for precise technical claims. The HyperTalk Reference PDF corresponds to version 2.4; Goodman's Developer's Guide covers version 1.2. - **Wikipedia surface accuracy:** Wikipedia's HyperCard and HyperTalk articles are broadly accurate for overview claims but lack the depth and precision this publication requires. Use them for orientation, not as source material. - **Forum thread decay:** Technical answers in archived forum threads (TinkerDifferent, comp.sys.mac.hypercard via Google Groups) may contain tested practitioner knowledge, but also contain errors, version-specific advice presented as universal, and incomplete answers. Treat as leads to verify, not as sources to cite. - **XCMD documentation scarcity:** Explanatory documentation for the XCMD/XFCN mechanism is the most fragmented area. Source code exists (e.g., XFromApp on GitHub) but code alone is not documentation. Apple's Developer Toolkit docs and Goodman's coverage are the strongest sources; supplement with caution.

Stay updated.