# Difference Between MulleObjC-startup and Foundation's Startup Process

> Explore the MulleObjC-startup vs Foundation startup process. Learn how MulleObjC initializes a minimal runtime while Foundation sets up the complete framework, including NSAutoreleasePool and class hierarchy.

- Repository: [mulle-objc/mulleobjc-startup](https://github.com/mulle-objc/mulleobjc-startup)
- Tags: deep-dive
- Published: 2026-03-07

---

**MulleObjC-startup registers a minimal MulleObjC universe with essential runtime services, whereas Foundation's startup process extends this foundation to initialize the full Foundation framework including NSAutoreleasePool, exception handling, and the complete class hierarchy.**

The distinction between these two initialization layers is crucial when building Objective-C executables with the MulleObjC ecosystem. Understanding the difference between MulleObjC-startup and Foundation's startup process helps developers choose the correct linking strategy for command-line tools versus full applications. This article examines the implementation details, source files, and linking requirements for both startup mechanisms.

## Core Purpose and Scope

**MulleObjC-startup** serves as the minimal bootstrap library that creates a bare-metal executable environment. It supplies the entry point `__register_mulle_objc_universe` and installs only the essential runtime services required to allocate Objective-C objects and send messages.

**Foundation startup** (provided by the MulleFoundation-startup repository) performs a richer initialization that prepares the higher-level Foundation framework. After the universe exists, it sets up Foundation-specific globals, registers the default `NSAutoreleasePool`, initializes exception handling, and loads the MulleFoundation class hierarchy.

## Source File Implementation

The implementation differs significantly between the two layers, with Foundation building directly upon the core startup.

### MulleObjC-startup Source

In `src/MulleObjC-startup.m`, the library implements `__register_mulle_objc_universe` and invokes `MulleObjCBang` to create the universe. The source copies the global default configuration (`mulle_objc_global_get_default_universeconfiguration`) and passes it unchanged to the runtime.

### Foundation Startup Source

In `src/MulleFoundation-startup.m`, the code imports the MulleObjC-startup symbol and adds `__register_mulle_foundation_universe`. After calling `MulleObjCBang`, it executes `MulleFoundationBang` to augment the configuration with a `MulleFoundationUniverseInfo` structure containing the default `NSAutoreleasePool` class and exception handler tables.

## Symbol Registration and Dependencies

**MulleObjC-startup** only requires the core MulleObjC runtime and helper libraries `mulle-atinit`/`mulle-atexit`. It exposes a single essential symbol: `__register_mulle_objc_universe`.

**Foundation startup** links against additional higher-level libraries including MulleFoundation and MulleThread. It exposes both the imported `__register_mulle_objc_universe` symbol plus its own `__register_mulle_foundation_universe` symbol.

## Practical Usage Examples

The following examples demonstrate the functional difference when linking against each startup layer.

### Using Only MulleObjC-startup

Link with `-lMulleObjC-startup` for small tools that need only the Objective-C object model without Foundation classes.

```c
#include <MulleObjC/MulleObjC.h>
#include <MulleObjC-startup/MulleObjC-startup.h>

int main(void)
{
    // Universe automatically registered via __attribute__((constructor))
    struct mulle_objc_object *obj = MulleObjCObjectCreate(0);
    MulleObjCObjectRelease(obj);
    return 0;
}

```

This executable can create and release objects, but attempting to use `NSString` or `NSAutoreleasePool` will fail because the required class tables never registered.

### Using Foundation Startup

Link with both `-lMulleObjC-startup` and `-lMulleFoundation-startup` to access the complete Foundation API.

```c
#include <MulleObjC/MulleObjC.h>
#include <MulleFoundation/MulleFoundation.h>
#include <MulleFoundation-startup/MulleFoundation-startup.h>

int main(void)
{
    NSAutoreleasePool *pool = [NSAutoreleasePool new];
    NSString *msg = @"Hello, Foundation!";
    NSLog(@"%@", msg);
    [pool drain];
    return 0;
}

```

The `NSAutoreleasePool` works because `MulleFoundation-startup` called `MulleFoundationBang`, which registered the pool class and exception handling tables during the constructor phase.

## Summary

- **MulleObjC-startup** provides the minimal bootstrap in `src/MulleObjC-startup.m` via `MulleObjCBang`, registering only core runtime services.
- **Foundation startup** extends this in `src/MulleFoundation-startup.m` via `MulleFoundationBang`, adding `NSAutoreleasePool`, exception handling, and the full class hierarchy.
- Linking requires `-lMulleObjC-startup` for bare-metal Objective-C, or both libraries for Foundation-dependent applications.
- Without Foundation startup, Foundation classes remain unavailable because their specific universe configuration and class tables never initialize.

## Frequently Asked Questions

### What happens if I link MulleFoundation but forget MulleFoundation-startup?

Your application will likely crash when accessing Foundation classes. While the core MulleObjC universe exists via `__register_mulle_objc_universe`, the Foundation-specific initialization in `__register_mulle_foundation_universe` never executes. This means `NSAutoreleasePool` and other Foundation globals remain unregistered, causing failures when the runtime attempts to allocate these objects.

### Can I use MulleObjC-startup without any Foundation libraries?

Yes. MulleObjC-startup is designed exactly for this use case in `src/MulleObjC-startup.m`. It only links against the core MulleObjC runtime and `mulle-atinit`/`mulle-atexit` helpers. This configuration suits command-line utilities or embedded tools requiring only the Objective-C object model and message passing without higher-level Foundation abstractions.

### Why does Foundation startup require both symbols (`__register_mulle_objc_universe` and `__register_mulle_foundation_universe`)?

Foundation startup depends on the core universe existing first. The `__register_mulle_foundation_universe` function in `src/MulleFoundation-startup.m` assumes `MulleObjCBang` has already executed via `__register_mulle_objc_universe`. The dependency chain ensures the runtime initializes in the correct order: core universe first, then Foundation extensions.

### How do I add these libraries to my build system?

For MulleObjC-startup alone, use `mulle-sde add github:mulle-objc/MulleObjC-startup` or link with `-lMulleObjC-startup`. For Foundation support, additionally run `mulle-sde add github:mulle-objc/MulleFoundation-startup` or add `-lMulleFoundation-startup` to your linker flags. The CMakeLists.txt in each repository defines the static libraries produced (`libMulleObjC-startup.a` and `libMulleFoundation-startup.a`).