# Creative SB16 Win16 MIDI-port output contract

This contract records the MIDI-port open and short-message paths from the installed Windows 3.1 audio driver. It does not cover long-message completion or synth output. The findings come from static analysis; no runtime MIDI trace was captured.

Evidence labels distinguish observed behavior from inference and unknowns. The contract contains no code addresses, source excerpts, pseudocode, binary paths, or hashes.

## Open and initialized state

[Observed binary behavior] The open path accepts a port selector, an open descriptor, and callback information. The traced short-message path accepts port selectors `0` and `1`.

[Observed binary behavior] When the lower audio state is available, open allocates and retains per-port state. It stores the port selector and callback data, clears the current status-byte state, and calls the lower service to initialize the port.

[Observed binary behavior] Successful open returns status `0`. It sends callback message value `0x3C7` when a callback target is configured.

[Inferred from Win16 multimedia conventions] Callback value `0x3C7` identifies the MIDI-output-open notification. A captured callback or matching Win16 SDK constant would confirm the name.

[Observed binary behavior] The open path can return `2` when the port selector or device context is invalid, `3` when the lower audio state is unavailable, `4` when initialization fails, and `7` when local state allocation fails.

[Unknown] The exact number of usable MIDI ports, their physical routing, and whether the two accepted selector values refer to different hardware endpoints are not established.

## Short-message submission

[Observed binary behavior] The short-message path checks that a port selector is in the range `0` through `1` and that the selected port has an active context. An invalid selector or missing context returns status `2`. If the lower audio state is unavailable, the path returns status `3`.

[Observed binary behavior] The path uses per-port state to track a current status byte. Status bytes in the channel-message range update that state. System status bytes clear or replace it according to the message class. Data bytes are interpreted using the retained status state.

[Inferred from MIDI conventions] This retained status behavior provides running-status handling for short messages. Capturing a channel message followed by data-only bytes would confirm the behavior at the lower-service boundary. Exact handling of incomplete or malformed messages was not established.

[Observed binary behavior] A reentrancy counter guards the short-message path. A nested send that exceeds the accepted depth returns status `0x43`.

[Observed binary behavior] A send that passes the checks is converted to a lower-service event and submitted through one lower-service call. The driver returns status `0` after this path. No per-message completion callback is visible in the short-message path.

## Call order and state

[Observed binary behavior] Open creates per-port state before later sends can be handled. Short-message submission validates the selector and active context, enters the reentrancy guard, parses status and data bytes using the per-port status state, calls the lower service, and leaves the guard.

[Unknown] The exact packed message layout, timestamp interpretation, lower-service event format, and physical byte ordering at the MIDI port are not established.

## Status summary

| Value | Evidence | Observed result |
|---|---|---|
| `0` | Observed binary behavior | Open or short-message send succeeded |
| `2` | Observed binary behavior | Invalid selector or missing port context |
| `3` | Observed binary behavior | Lower audio state unavailable |
| `4` | Observed binary behavior | Port initialization failure |
| `7` | Observed binary behavior | Open-state allocation failure |
| `0x43` | Observed binary behavior | Short-message reentrancy guard rejected the send |

These values describe the traced paths only. Their mapping to public multimedia error names was not verified.

## Unknowns

[Unknown] Long-message byte parsing, system-exclusive buffering, long-message completion callbacks, and reset or close behavior are outside this contract.

[Unknown] The lower service's command protocol, port I/O, MIDI timing, message queueing, and hardware errors are not mapped.

[Unknown] The order and timing of physical output relative to the successful return are not measured.

## Software-only verification suggestions

[Suggested] In a fresh disposable copy of the Windows 3.11 environment, open each accepted selector and record return values, open notifications, and behavior when the lower service is unavailable.

[Suggested] Send channel messages with explicit status bytes followed by data-only short messages. Record the bytes observed at a software MIDI capture or loopback endpoint, return values, and any callback activity. Include system status and incomplete-message cases.

[Suggested] Repeat sends during any callback activity to probe the reentrancy guard. Keep long-message tests separate because their completion path is not described here.