title: Friendship Trophy

abstract: The Friendship Trophy is a football match, contested on an irregular basis by just two teams: Norwich City and Sunderland. The match dates back to the camaraderie forged between fans of the two clubs at the time of the 1985 Football League Cup Final that they contested. Norwich City won the 1985 Football League Cup Final, however at the end of the First Division Season, both teams were relegated to the Second Division. Mackem and Canary mingled and drank happily together. “The Sunderland supporters were magnificent and everyone seemed to mix, it was light-hearted and very nice,” judged Norwich manager Ken Brown after his team had lifted the trophy thanks to a Gordon Chisholm own goal. On the London Underground, Norwich fans sang “we won the cup”, while Sunderland’s retorted with: “we scored the goal”. Nowadays, the Friendship Trophy is awarded to the team with the winning aggregate score in competitive matches over the season between the two sides. As such, Sunderland are the current holders of the trophy, having won 4–2 over the two league games in the 2017/18 EFL Championship season. The trophy was most recently contested in March 2024, when the teams played at Carrow Road in the EFL Championship. Norwich won 1–0 in that match, though Sunderland won 3–2 on aggregate due to their 3–1 victory at the Stadium of Light in October 2023. This trophy is only infrequently contested, as it requires both Norwich City and Sunderland to be in the same division, or to be drawn together in a cup competition, which last happened in 2009, when Sunderland beat Norwich City 4–1 in the Football League Cup. The most significant cup meeting after the 1985 final was the semi-final of the 1991–92 FA Cup at Hillsborough, which Sunderland won 1–0. In 2013, Talksport named The Friendship Trophy one of football's most pointless awards.

text:
# Friendship Trophy

The **Friendship Trophy** is a football match, contested on an irregular basis by just two teams: Norwich City and Sunderland. The match dates back to the camaraderie forged between fans of the two clubs at the time of the 1985 Football League Cup Final that they contested. Norwich City won the 1985 Football League Cup Final, however at the end of the First Division Season, both teams were relegated to the Second Division.

> Mackem and Canary mingled and drank happily together. “The Sunderland supporters were magnificent and everyone seemed to mix, it was light-hearted and very nice,” judged Norwich manager Ken Brown after his team had lifted the trophy thanks to a Gordon Chisholm own goal. On the London Underground, Norwich fans sang “we won the cup”, while Sunderland’s retorted with: “we scored the goal”.

Nowadays, the Friendship Trophy is awarded to the team with the winning aggregate score in competitive matches over the season between the two sides. As such, Sunderland are the current holders of the trophy, having won 4–2 over the two league games in the 2017/18 EFL Championship season.

The trophy was most recently contested in March 2024, when the teams played at Carrow Road in the EFL Championship. Norwich won 1–0 in that match, though Sunderland won 3–2 on aggregate due to their 3–1 victory at the Stadium of Light in October 2023.

This trophy is only infrequently contested, as it requires both Norwich City and Sunderland to be in the same division, or to be drawn together in a cup competition, which last happened in 2009, when Sunderland beat Norwich City 4–1 in the Football League Cup. The most significant cup meeting after the 1985 final was the semi-final of the 1991–92 FA Cup at Hillsborough, which Sunderland won 1–0.

In 2013, Talksport named The Friendship Trophy one of football's most pointless awards.

## Head to head summary

| Club | P | W | D | L | F | A | +/- |
| --- | --- | --- | --- | --- | --- | --- | --- |
| League | | | | | | | |
| Norwich City | 28 | 15 | 5 | 8 | 31 | 27 | +4 |
| Sunderland | 28 | 8 | 5 | 15 | 27 | 31 | –4 |
| FA Cup | | | | | | | |
| Norwich City | 1 | 0 | 0 | 1 | 0 | 1 | –1 |
| Sunderland | 1 | 1 | 0 | 0 | 1 | 0 | +1 |
| Football League Cup | | | | | | | |
| Norwich City | 2 | 1 | 0 | 1 | 2 | 4 | –2 |
| Sunderland | 2 | 1 | 0 | 1 | 4 | 2 | +2 |
| Totals | | | | | | | |
| **Norwich City** | 31 | 16 | 5 | 10 | 33 | 32 | +1 |
| **Sunderland** | 31 | 10 | 5 | 16 | 32 | 33 | -1 |

## Head-to-head fixtures

| Date | Home Team | Score | Away Team | Competition |
| --- | --- | --- | --- | --- |
| 24 March 1985 | Norwich City | **1–0** | Sunderland | Football League Cup |
| 26 October 1985 | Sunderland | **0–2** | Norwich City | Football League, Second Division |
| 9 April 1986 | Norwich City | **0–0** | Sunderland | Football League, Second Division |
| 25 August 1990 | Norwich City | **3–2** | Sunderland | Football League, First Division |
| 15 December 1990 | Sunderland | **1–2** | Norwich City | Football League, First Division |
| 5 April 1992 | Sunderland | **1–0** | Norwich City | FA Cup |
| 19 August 1995 | Norwich City | **0–0** | Sunderland | Football League First Division |
| 14 January 1996 | Sunderland | **0–1** | Norwich City | Football League First Division |
| 30 August 1997 | Sunderland | **0–1** | Norwich City | Football League First Division |
| 28 January 1998 | Norwich City | **2–1** | Sunderland | Football League First Division |
| 29 September 1998 | Norwich City | **2–2** | Sunderland | Football League First Division |
| 6 March 1999 | Sunderland | **1–0** | Norwich City | Football League First Division |
| 25 October 2003 | Norwich City | **1–0** | Sunderland | Football League First Division |
| 4 May 2004 | Sunderland | **1–0** | Norwich City | Football League First Division |
| 4 November 2006 | Norwich City | **1–0** | Sunderland | Football League Championship |
| 2 December 2006 | Sunderland | **1–0** | Norwich City | Football League Championship |
| 24 August 2009 | Norwich City | **1–4** | Sunderland | Football League Cup |
| 26 September 2011 | Norwich City | **2–1** | Sunderland | Premier League |
| 1 February 2012 | Sunderland | **3–0** | Norwich City | Premier League |
| 2 December 2012 | Norwich City | **2–1** | Sunderland | Premier League |
| 17 March 2013 | Sunderland | **1–1** | Norwich City | Premier League |
| 21 December 2013 | Sunderland | **0–0** | Norwich City | Premier League |
| 22 March 2014 | Norwich City | **2–0** | Sunderland | Premier League |
| 15 August 2015 | Sunderland | **1–3** | Norwich City | Premier League |
| 16 April 2016 | Norwich City | **0–3** | Sunderland | Premier League |
| 13 August 2017 | Norwich City | **1–3** | Sunderland | EFL Championship |
| 10 April 2018 | Sunderland | **1–1** | Norwich City | EFL Championship |
| 27 August 2022 | Sunderland | **0–1** | Norwich City | EFL Championship |
| 12 March 2023 | Norwich City | **0–1** | Sunderland | EFL Championship |
| 28 October 2023 | Sunderland | **3–1** | Norwich | EFL Championship |
| 2 March 2024 | Norwich | **1–0** | Sunderland | EFL Championship |

## InfoBox

Friendship Trophy
| Location | Norwich and Sunderland |
| --- | --- |
| Teams | Norwich City
Sunderland |
| First meeting | 24 March 1985 |
| Latest meeting | Norwich 1–0 Sunderland
2023–24 EFL Championship
(2 March 2024) |
| Next meeting | Norwich city vs Sunderland (EFL Championship) 21/12/24' |
| Statistics | |
| Meetings total | 30 |
| Most wins | Norwich City (15) |
| All-time series | Norwich City: 6
Drawn: 2 (Sunderland retained)
Sunderland: 6 (including 2 solo cup wins) |


title: Trials (journal)

abstract: Trials is an open access peer-reviewed medical journal covering performance and outcomes of randomized controlled trials. The journal is published by BioMed Central; the editors-in-chief are Jeremy Grimshaw, Peter Jüni, Tianjing Li, and Shaun Treweek. It also publishes study protocols.

text:
# Trials (journal)

***Trials*** is an open access peer-reviewed medical journal covering performance and outcomes of randomized controlled trials. The journal is published by BioMed Central; the editors-in-chief are Jeremy Grimshaw (Ottawa Health Research Institute), Peter Jüni (University of Toronto), Tianjing Li (Johns Hopkins Bloomberg School of Public Health), and Shaun Treweek (University of Aberdeen). It also publishes study protocols.

## Abstracting and indexing

The journal is abstracted and indexed in:

According to the *Journal Citation Reports*, the journal has a 2018 impact factor of 1.975.

## InfoBox

*Trials*
| Discipline | General medicine |
| --- | --- |
| Language | English |
| Edited by | Jeremy Grimshaw, Tianjing Li, Shaun Treweek, Peter Jüni |
| Publication details | |
| History | 2006-present |
| Publisher | BioMed Central |
| Frequency | Upon acceptance |
| Open access | Yes |
| License | Creative Commons Attribution |
| Impact factor | 1.975 (2018) |
| Standard abbreviations
 | |
| ISO 4 | *Trials* |
| Indexing
 | |
| CODEN | TRIACW |
| ISSN | 1745-6215
 |
| LCCN | 2006243052 |
| OCLC no. | 63290284 |
| Links | |
|  | |


title: Fernando Cabrera (baseball)

abstract: Fernando José Cabrera is a Puerto Rican former professional baseball relief pitcher. He played in Major League Baseball (MLB) for the Cleveland Indians, Baltimore Orioles, and Boston Red Sox.

text:
# Fernando Cabrera (baseball)

**Fernando José Cabrera** (born November 16, 1981) is a Puerto Rican former professional baseball relief pitcher. He played in Major League Baseball (MLB) for the Cleveland Indians, Baltimore Orioles, and Boston Red Sox.

## Career

### Cleveland Indians

Cabrera was drafted by the Cleveland Indians in the 10th round of the 1999 Major League Baseball draft and signed in August 1999. He was selected to participate in the 2005 All-Star Futures Game. He was designated for assignment by Cleveland on August 1, 2007, and was subsequently released on August 9.

### Baltimore Orioles

The Tampa Bay Devil Rays claimed him off release waivers on August 13, and had five days to sign him or let Cabrera become a free agent. Cabrera decided to become a free agent and signed a minor league contract with the Baltimore Orioles on August 21, 2007. The Orioles recalled Cabrera in September 2007. He was placed on the 15-day disabled list by the Orioles at the beginning of the 2008 season. On September 5, 2008, Cabrera was released by the Orioles.

### Boston Red Sox

On January 27, 2009, he signed a minor league contract with the Boston Red Sox. He was called up to the Red Sox on August 9, 2009.

### Oakland Athletics

He played with the Sacramento River Cats in the Oakland Athletics system in 2011.

### New York Mets

On January 10, 2012, Cabrera signed with the New York Mets to a minor league deal.

### Los Angeles Angels

On January 11, 2013, Cabrera signed a minor league deal with the Los Angeles Angels of Anaheim. He was assigned to the Salt Lake Bees, and he played a season for them before retiring.

### International play

Cabrera played for Puerto Rico in the 2006, 2009 and 2013 World Baseball Classic. In 2009, he gave up the ninth-inning single to David Wright to allow Team USA to come back from a 5–4 deficit to win the game, eliminating Puerto Rico from the competition.

## InfoBox

| Fernando Cabrera | |
| --- | --- |
| Cabrera with the Cleveland Indians in 2007 | |
| **Relief pitcher** | |
| **Born:**  (1981-11-16) November 16, 1981<br>Toa Baja, Puerto Rico | |
| **Batted:** Right**Threw:** Right | |
| MLB debut | |
| August 20, 2004, for the Cleveland Indians | |
| Last MLB appearance | |
| July 16, 2010, for the Boston Red Sox | |
| MLB statistics | |
| Win–loss record | 8–7 |
| Earned run average | 5.24 |
| Strikeouts | 193 |
|  | |
| Teams | |
|  | |
| Medals      Men's baseball  Representing  Puerto Rico  World Baseball Classic  2013 San Francisco Team  Pan American Games  2019 Lima Team | |


title: Eupoecilia neurosema

abstract: Eupoecilia neurosema is a species of moth of the family Tortricidae. It is found in Papua New Guinea.

text:
# Eupoecilia neurosema

***Eupoecilia neurosema*** is a species of moth of the family Tortricidae. It is found in Papua New Guinea.

## InfoBox

| *Eupoecilia neurosema* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Tortricidae |
| Genus: | *Eupoecilia* |
| Species: | ***E. neurosema*** |
| Binomial name | |
| ***Eupoecilia neurosema***<br>(Meyrick, 1938) | |
|
| Synonyms | |
| * *Clysia neurosema* Meyrick, 1938 | |


title: Tethea octogesima

abstract: Tethea octogesima is a moth in the family Drepanidae first described by Arthur Gardiner Butler in 1878. It is found in Japan, Korea, China, Taiwan and the Russian Far East. The wingspan is 20–24 mm. Adults have a dark silvery grey tint, with deep black the transverse lines and markings of the reniform and orbicular spots. The lines near the base are more dentated, the central band is wider and its external limiting line irregularly zigzag.

text:
# Tethea octogesima

***Tethea octogesima*** is a moth in the family Drepanidae first described by Arthur Gardiner Butler in 1878. It is found in Japan, Korea, China (Jilin, Shaanxi, Zhejiang), Taiwan and the Russian Far East.

The wingspan is 20–24 mm. Adults have a dark silvery grey tint, with deep black the transverse lines and markings of the reniform and orbicular spots. The lines near the base are more dentated, the central band is wider and its external limiting line irregularly zigzag.

## Subspecies

* *Tethea octogesima octogesima* (Japan, Korea, Russian Far East, China: Jilin, Shaanxi, Zhejiang)
* *Tethea octogesima watanabei* (Matsumura, 1931) (Taiwan)

## InfoBox

| *Tethea octogesima* | |
| --- | --- |
|  | |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Drepanidae |
| Genus: | *Tethea* |
| Species: | ***T. octogesima*** |
| Binomial name | |
| ***Tethea octogesima***<br>(Butler, 1878) | |
|
| Synonyms | |
| * *Cymatophora octogesima* Butler, 1878 * *Cymatophora intensa* Butler, 1881 * *Cymatophora angustata* Staudinger, 1885 * *Saronaga watanabei* Matsumura, 1931 * *Tethea intensa griseomacula* Werny, 1966 | |


title: Tetheella

abstract: Tetheella is a monotypic moth genus in the family Drepanidae described by Werny in 1966. Its single species, Tetheella fluctuosa, the satin lutestring, was described by Jacob Hübner in 1803. It is found from western Europe across the Palearctic to Kamchatka, Sakhalin Island, Korea and Japan. The wingspan is 35–38 mm. The forewings are light fuscous, white- sprinkled.The first line is whitish, limiting a broad darker central band including dark fuscous median and second lines, followed by a whitish dark-edged waved line. The subterminal is whitish, waved, preceded on the costa by an oblique dark fuscous dash. The hindwings are grey, with a pale postmedian line. The larva is yellow whitish; dorsal, fine subdorsal, and lateral lines fuscous; head reddish-ochreous, brown-marked. The moth flies from June to August depending on the location. The larvae feed on birch and alder.

text:
# Tetheella

***Tetheella*** is a monotypic moth genus in the family Drepanidae described by Werny in 1966. Its single species, ***Tetheella fluctuosa***, the **satin lutestring**, was described by Jacob Hübner in 1803. It is found from western Europe across the Palearctic to Kamchatka, Sakhalin Island, Korea and Japan.

The wingspan is 35–38 mm. The forewings are light fuscous, white- sprinkled .The first line is whitish, limiting a broad darker central band including dark fuscous median and second lines, followed by a whitish dark-edged waved line. The subterminal is whitish, waved, preceded on the costa by an oblique dark fuscous dash. The hindwings are grey, with a pale postmedian line. The larva is yellow whitish; dorsal, fine subdorsal, and lateral lines fuscous; head reddish-ochreous, brown-marked.

The moth flies from June to August depending on the location.

The larvae feed on birch and alder.

## Subspecies

* *Tetheella fluctuosa fluctuosa*
* *Tetheella fluctuosa isshikii* (Matsumura, 1921) (Russian Far East, north-eastern and northern China, Korea, Japan)

## InfoBox

| *Tetheella* | |
| --- | --- |
|  | |
|  | |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Drepanidae |
| Subfamily: | Thyatirinae |
| Genus: | *Tetheella* |
| Species: | ***T. fluctuosa*** |
| Binomial name | |
| ***Tetheella fluctuosa***<br>(Hübner, 1803) | |
|
| Synonyms | |
| * *Noctua fluctuosa* Hübner, \[1803\] * *Palimpsestis fluctuosa isshikii* Matsumura, 1921 * *Palimpsestis hirayami* Matsumura, 1933 | |


title: Eupithecia halosydne

abstract: Eupithecia halosydne is a moth in the family Geometridae. It is found on the Juan Fernandez Islands in Chile. The length of the forewings is about 8–9 mm for females. The forewings are pale ochraceous brown. The hindwings are slightly paler than forewings. Adults have been recorded on wing in March.

text:
# Eupithecia halosydne

***Eupithecia halosydne*** is a moth in the family Geometridae. It is found on the Juan Fernandez Islands in Chile.

The length of the forewings is about 8–9 mm for females. The forewings are pale ochraceous brown. The hindwings are slightly paler than forewings. Adults have been recorded on wing in March.

## InfoBox

| *Eupithecia halosydne* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Geometridae |
| Genus: | *Eupithecia* |
| Species: | ***E. halosydne*** |
| Binomial name | |
| ***Eupithecia halosydne***<br>Prout, 1922 | |
|


title: Macchie, Castelsantangelo sul Nera

abstract: Macchie is an Italian village and hamlet (frazione) of the municipality of Castelsantangelo sul Nera, in the Province of Macerata, Marche. For ISTAT 2001 census, it had a population of 16.

text:
# Macchie, Castelsantangelo sul Nera

**Macchie** is an Italian village and hamlet (*frazione*) of the municipality of Castelsantangelo sul Nera, in the Province of Macerata, Marche. For ISTAT 2001 census, it had a population of 16.

## Geography

The village is placed at 1078 metres in the middle of the Monti Sibillini National Park.

The name "Macchie" derives from the woods (in Italian: *macchie*) that surround the village. It is a mountainous area in the national park of the Sibillini mountains. Below the village one can admire the Vallinfante valley and nearby the Passo Cattivo, Porche di Vallinfante, Colle La Croce, Monte Pagliano, Monte Prata and Monte Cardosa. The village is also at the foot of Monte Cornaccione which, however, cannot be seen entirely from the village.

## Places of interest

There are two churches in Macchie: *St. Anthony's* (in Italian: *Chiesa di Sant'Antonio*) and *St. John's*(in Italian: *Chiesa di San Giovanni Battista*). At about 100 metres below the village there is a chapel: *The Little Virgin* (in Italian: *La Madonnella*), dedicated to the latter. It was restored and consecrated again in August 2007.

Likewise another chapel, along a nearby mountain: *The Virgin of Forcella's Chapel* (in Italian: *Cappella della Madonna della Forcella*), was completely rebuilt in the summer of 2008 by a group of volunteers.

## Bibliography

* Sonia Pierangeli. *Castelsantangelo sul Nera La Storia I Simboli Le Emozioni*. Piediripa, Grafica Maceratese, 2009.

## InfoBox

| Macchie | |
| --- | --- |
| *Frazione* | |
| Macchie from Spina di Gualdo | |
| MacchieLocation of Macchie in Italy | |
| Coordinates: 42°53′50″N 13°10′58″E / 42.89722°N 13.18278°E / 42.89722; 13.18278 | |
| Country | Italy |
| Region | Marche |
| Province | Macerata (MC) |
| *Comune* | Castelsantangelo sul Nera |
| Elevation | 1,078 m (3,537 ft) |
| Population (2001) | |
| Total | 16 |
| Demonym | *Macchiani* |
| Time zone | UTC+1 (CET) |
| Summer (DST) | UTC+2 (CEST) |
| Postal code | 62039 |
| Dialing code | (+39) 0737 |
| Patron saint | St. John the Baptist |
| Saint day | 24 June |


title: Mabry Mill

abstract: Mabry Mill is a watermill located at milepost 176.2 of Blue Ridge Parkway in Floyd County, Virginia. Run by the National Park Service, it is a tourist attraction. A short trail around the mill connects historical exhibits about life in rural Virginia. The trail allows visitors to view the gristmill, sawmill, and blacksmith shop. Mabry Mill was built by Edwin Boston Mabry. He returned to Floyd County in 1903 and began constructing the mill. It was first a blacksmith and wheelwright shop, then became a sawmill. By 1905, it was in operation as a gristmill. By 1910, the front part of the mill was completed and included a lathe for turning out wheel hubs, a tongue and groove lathe, a planer and a jig-saw. Between 1905 and 1914 Mabry bought adjacent tracts of land, mostly for the purpose of acquiring more water power. During peak seasons, demonstrations of crafts are given by National Park Service volunteers at Mabry Mill.

text:
# Mabry Mill

**Mabry Mill** is a watermill located at milepost 176.2 of Blue Ridge Parkway in Floyd County, Virginia. Run by the National Park Service, it is a tourist attraction. A short trail around the mill connects historical exhibits about life in rural Virginia. The trail allows visitors to view the gristmill, sawmill, and blacksmith shop.

Mabry Mill was built by Edwin Boston Mabry (E. B. Mabry). He returned to Floyd County in 1903 and began constructing the mill. It was first a blacksmith and wheelwright shop, then became a sawmill. By 1905, it was in operation as a gristmill. By 1910, the front part of the mill was completed and included a lathe for turning out wheel hubs, a tongue and groove lathe, a planer and a jig-saw. Between 1905 and 1914 Mabry bought adjacent tracts of land, mostly for the purpose of acquiring more water power.

During peak seasons, demonstrations of crafts are given by National Park Service volunteers at Mabry Mill.

36°45′00″N 80°24′18″W / 36.750°N 80.405°W / 36.750; -80.405


title: Eupterote formosana

abstract: Eupterote formosana is a moth in the family Eupterotidae. It was described by Shōnen Matsumura in 1908. It is found in Taiwan.

text:
# Eupterote formosana

***Eupterote formosana*** is a moth in the family Eupterotidae. It was described by Shōnen Matsumura in 1908. It is found in Taiwan.

## InfoBox

| *Eupterote formosana* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Eupterotidae |
| Genus: | *Eupterote* |
| Species: | ***E. formosana*** |
| Binomial name | |
| ***Eupterote formosana***<br>Matsumura, 1908 | |
|


title: Eupterote flavida

abstract: Eupterote flavida is a moth in the family Eupterotidae. It was described by Frederic Moore in 1884. It is found in India. The wingspan is about 74 mm. The ground colour is yellow, with a slight ruddy tinge. The forewings are crossed by three slightly curved oblique bands of blackish scales from near the apex to the inner margin, towards which they diverge. The middle band is often obsolete.

text:
# Eupterote flavida

***Eupterote flavida*** is a moth in the family Eupterotidae. It was described by Frederic Moore in 1884. It is found in India.

The wingspan is about 74 mm. The ground colour is yellow, with a slight ruddy tinge. The forewings are crossed by three slightly curved oblique bands of blackish scales from near the apex to the inner margin, towards which they diverge. The middle band is often obsolete.

## InfoBox

| *Eupterote flavida* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Eupterotidae |
| Genus: | *Eupterote* |
| Species: | ***E. flavida*** |
| Binomial name | |
| ***Eupterote flavida***<br>Moore, 1884 | |
|
| Synonyms | |
| * *Messata acinea* Swinhoe, 1891 * *Eupterote procumbens* Grünberg | |


title: Macbeth (Bloch)

abstract: Macbeth is an opera in three acts, with music by Ernest Bloch to a libretto by Edmond Fleg, after the eponymous play of William Shakespeare. Bloch composed the opera between 1904 and 1906, but it did not receive its first performance until 30 November 1910 by the Opéra-Comique in Paris with Henri Albers in the title role and conducted by François Ruhlmann. Alex Cohen has written of quarrels within the cast that contributed to the opera's poorly received premiere.

text:
# Macbeth (Bloch)

***Macbeth*** is an opera in three acts, with music by Ernest Bloch to a libretto by Edmond Fleg, after the eponymous play of William Shakespeare. Bloch composed the opera between 1904 and 1906, but it did not receive its first performance until 30 November 1910 by the Opéra-Comique in Paris with Henri Albers in the title role and conducted by François Ruhlmann. Alex Cohen has written of quarrels within the cast that contributed to the opera's poorly received premiere.

## Performance history

After the premiere, the opera was performed 15 times through January 1911, but then was withdrawn. Romain Rolland studied the score and communicated his admiration to Bloch in June 1911.

Guido M. Gatti has compared elements of Bloch's opera to the music of Modest Mussorgsky. He has also written of the different treatments of the Macbeth story by Giuseppe Verdi and Bloch in their respective operas on the subject, with Verdi being more "realistic" and Bloch being more in keeping with the symbolist era in art at his time.

After the premiere production, the opera was staged in 1938 in Naples, but was then banned on orders of the Fascist government. Subsequently, the opera was produced in Rome in 1953, and in Trieste.

The opera was staged, in English, at the Juilliard School of Music in New York under the direction of John Houseman, in May 1973. Peter Herman Adler conducted and the singers included L. Carlson, H. Barnsley, R. Termine, F. Burchinal, M. Li-Paz and W. White.

The University College Opera of University College, London, performed the English language premiere of *Macbeth* in the UK in March 2009.

The US premiere by a professional opera company was given by the Long Beach Opera in June 2013 in a production by Andreas Mitisek with Benjamin Makino conducting. That same production was staged by the Chicago Opera Theater in September 2014 with Francesco Milioto conducting.

The opera was staged, in the original French, at the Manhattan School of Music in December 2014 under the direction of Dona D. Vaughn with Laurent Pillot conducting.

## Roles

| Role Type | Character | Voice type | Role creator |
| --- | --- | --- | --- |
| Major | Macbeth | Baritone | Henri Albers |
| Major | Lady Macbeth | Dramatic Soprano/ Mezzo-Soprano | Lucienne Bréval |
| Minor | 1st Witch | Soprano | Espinasse |
| Minor | 2nd Witch | Mezzo-Soprano | Suzanne Brohly |
| Minor | 3rd Witch | Contralto | Marie Charbonnel |
| Minor | Banquo | Low Tenor | Jean Laure |
| Minor | Macduff | Lyric Bass | Félix Vieuille |
| Minor | Servant | Tenor | Robert Pasquier |
| Minor | Duncan | Tenor | Feodoroff |
| Minor | Porter | Baritone | Jean Delvoye |
| Minor | Lennox | Low Tenor | Raymond Gilles |
| Minor | Malcolm | Tenor | François Mario |
| Minor | Old man | Bass | Paul Payan |
| Minor | Murderer | bass | Louis Azéma |
| Minor | Lady Macduff | Soprano | Lucy Vauthrin |
| Minor | Son of Macduff | Mezzo-Soprano | Germaine Carrière |
| Minor | Third apparition | Contralto | Alive Raveau |
| Bit | First apparition | Bass | Paul Guillamat |
| mute | Fleance | - | Fayolle |
| mute | Second Murderer | - |  |
| mute | Attendant | - |  |
| mute | Eight Kings in Macbeth's vision | - |  |
| Chorus | Lords, ladies, soldiers, peasants, ghosts. | various |  |

## Synopsis

The story is essentially that of the Shakespeare play, with the five acts compressed to three. The opera contains seven *tableaux*, with the prelude comprising the first tableau, and each of the three acts containing two tableaux.

## Recordings

Complete recordings conducted by Alexander Rumpf and Friedemann Layer have been produced.

A full recording of a performance in 1997 was issued in 1999 (Musicales Actes Sud OMA34100) with Jean-Philippe Lafont, Markella Hatziano, Jean-Philippe Marlière, Jacque Trussel, Christer Bladin, Philippe Georges, Marcel Vanaud, Sophie Fournier, Hanna Schaer, Ariane Stamboulides, Wojtek Smilek, Annie Varville, Franck Bard, Ferijs Millers, Andris Gailis; with the Orchestre Philharmonique de Montpellier Languedoc-Roussillon; Choeur de la Radio lettone; Friedemann Layer, conductor

A recording exists with Heinz Rehfuss as Macbeth and Lucienne Devallier as Lady Macbeth, with Ernest Ansermet conducting the Orchestre de la Suisse Romande.

## InfoBox

| Macbeth | |
| --- | --- |
| Opera by Ernest Bloch | |
| The composer in 1917 | |
| Librettist | Edmond Fleg |
| Language | French |
| Based on | Shakespeare's *Macbeth* |
| Premiere | 30 November 1910 (1910-11-30)<br>Opéra-Comique, Paris |


title: European Journal of Immunology

abstract: The European Journal of Immunology is an academic journal of the European Federation of Immunological Societies covering basic immunology research, with a primary focus on antigen processing, cellular immune response, immunity to infection, immunomodulation, leukocyte signalling, clinical immunology, innate immunity, molecular immunology, and related new technology. The editor-in-chief is James Di Santo. According to the Journal Citation Reports, the journal had a 2020 impact factor of 5.532. Professionals in the fields of immunology, biochemistry, infection, oncology, hematology, cell biology, rheumatology, endocrinology and molecular biology make up the journal's readership.

text:
# European Journal of Immunology

The ***European Journal of Immunology*** is an academic journal of the European Federation of Immunological Societies covering basic immunology research, with a primary focus on antigen processing, cellular immune response, immunity to infection, immunomodulation, leukocyte signalling, clinical immunology, innate immunity, molecular immunology, and related new technology.

The editor-in-chief is James Di Santo. According to the *Journal Citation Reports*, the journal had a 2020 impact factor of 5.532.

Professionals in the fields of immunology, biochemistry, infection, oncology, hematology, cell biology, rheumatology, endocrinology and molecular biology make up the journal's readership.

## InfoBox

*European Journal of Immunology*
|  | |
| --- | --- |
| Discipline | Allergy. immunology |
| Language | English |
| Edited by | James Di Santo |
| Publication details | |
| History | 1971–present |
| Publisher | Wiley-VCH (Germany) |
| Frequency | Monthly |
| Open access | Online Open |
| Impact factor | 5.532 (2020) |
| Standard abbreviations
 | |
| ISO 4 | *Eur. J. Immunol.* |
| Indexing
 | |
| CODEN | EJIMAF |
| ISSN | 0014-2980 (print)
1521-4141 (web)
 |
| OCLC no. | 01568458 |
| Links | |
|  | |


title: Macaria bicolorata

abstract: Macaria bicolorata, the bicolored angle, is a moth of the family Geometridae. It is found in Eastern North America. The wingspan is about 30 mm (1.2 in). The moths are on wing from May to August depending on the location. The larvae feed on Pinus species.

text:
# Macaria bicolorata

***Macaria bicolorata***, the **bicolored angle**, is a moth of the family Geometridae. It is found in Eastern North America.

The wingspan is about 30 mm (1.2 in). The moths are on wing from May to August depending on the location.

The larvae feed on *Pinus* species.

## InfoBox

| *Macaria bicolorata* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Family: | Geometridae |
| Genus: | *Macaria* |
| Species: | ***M. bicolorata*** |
| Binomial name | |
| ***Macaria bicolorata***<br>Fabricius, 1798 | |
|
| Synonyms | |
| * *Semiothisa bicolorata* * *Phalaena bicolorata* Fabricius, 1798 * *Macaria concepta* Walker, 1861 * *Macaria consimilata* Zeller, 1872 * *Macaria grassata* Hulst, 1881 * *Phalaena praeatomata* Haworth, 1809 | |


title: Eulepidotis pulchella

abstract: Eulepidotis pulchella is a moth of the family Erebidae first described by Constant Bar in 1876. It is found in the Neotropics, including French Guiana and Guyana.

text:
# Eulepidotis pulchella

***Eulepidotis pulchella*** is a moth of the family Erebidae first described by Constant Bar in 1876. It is found in the Neotropics, including French Guiana and Guyana.

## InfoBox

| *Eulepidotis pulchella* | |
| --- | --- |
|
| Scientific classification | |
| Domain: | Eukaryota |
| Kingdom: | Animalia |
| Phylum: | Arthropoda |
| Class: | Insecta |
| Order: | Lepidoptera |
| Superfamily: | Noctuoidea |
| Family: | Erebidae |
| Genus: | *Eulepidotis* |
| Species: | ***E. pulchella*** |
| Binomial name | |
| ***Eulepidotis pulchella***<br>(Bar, 1876) | |
|
| Synonyms | |
| * *Palindia pulchella* Bar, 1876 | |


title: Mach-O

abstract: Mach-O, short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically loaded code, and core dumps. It was developed to replace the a.out format. Mach-O is used by some systems based on the Mach kernel. NeXTSTEP, macOS, and iOS are examples of systems that use this format for native executables, libraries and object code.

text:
# Mach-O

**Mach-O**, short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically loaded code, and core dumps. It was developed to replace the a.out format.

Mach-O is used by some systems based on the Mach kernel. NeXTSTEP, macOS, and iOS are examples of systems that use this format for native executables, libraries and object code.

## Mach-O file layout

Each Mach-O file is made up of one Mach-O header, followed by a series of load commands, followed by one or more segments, each of which contains between 0 and 255 sections. Mach-O uses the REL relocation format to handle references to symbols. When looking up symbols Mach-O uses a two-level namespace that encodes each symbol into an 'object/symbol name' pair that is then linearly searched for, first by the object and then the symbol name.

The basic structure—a list of variable-length "load commands" that reference pages of data elsewhere in the file—was also used in the executable file format for Accent. The Accent file format was in turn, based on an idea from Spice Lisp.

All multi-byte values in all data structures are written in the byte order of the host for which the code was produced.

## Mach-O header

Mach-O File header
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | Magic number |
| 4 | 4 | CPU type |
| 8 | 4 | CPU subtype |
| 12 | 4 | File type |
| 16 | 4 | Number of load commands |
| 20 | 4 | Size of load commands |
| 24 | 4 | Flags |
| 28 | 4 | Reserved (64-bit only) |

The magic number for 32-bit code is `0xfeedface` while the magic number for 64-bit architectures is `0xfeedfacf`.

The reserved value is only present in 64-bit Mach-O files. It is reserved for future use or extension of the 64-bit header.

The CPU type indicates the instruction set architecture for the code. If the file is for the 64-bit version of the instruction set architecture, the CPU type value has the `0x01000000` bit set.

The CPU type values are as follows:

CPU type
| Value | CPU Type |
| --- | --- |
| 0x00000001 | VAX |
| 0x00000002 | ROMP |
| 0x00000004 | NS32032 |
| 0x00000005 | NS32332 |
| 0x00000006 | MC680x0 |
| 0x00000007 | x86 |
| 0x00000008 | MIPS |
| 0x00000009 | NS32352 |
| 0x0000000A | MC98000 |
| 0x0000000B | HP-PA |
| 0x0000000C | ARM |
| 0x0000000D | MC88000 |
| 0x0000000E | SPARC |
| 0x0000000F | i860 (big-endian) |
| 0x00000010 | i860 (little-endian) |
| 0x00000011 | RS/6000 |
| 0x00000012 | PowerPC |

Each CPU type has a set of CPU subtype values, indicating a particular model of that CPU type for which the code is intended. Newer models of a CPU type may support instructions, or other features, not supported by older CPU models, so that code compiled or written for a newer model might contain instructions that are illegal instructions on an older model, causing that code to trap or otherwise fail to operate correctly when run on an older model. Code intended for an older model will run on newer models without problems.

If the CPU type is ARM then the subtypes are as follows:

CPU subtype ARM
| Value | CPU version |
| --- | --- |
| 0x00000000 | All ARM processors. |
| 0x00000001 | Optimized for ARM-A500 ARCH or newer. |
| 0x00000002 | Optimized for ARM-A500 or newer. |
| 0x00000003 | Optimized for ARM-A440 or newer. |
| 0x00000004 | Optimized for ARM-M4 or newer. |
| 0x00000005 | Optimized for ARM-V4T or newer. |
| 0x00000006 | Optimized for ARM-V6 or newer. |
| 0x00000007 | Optimized for ARM-V5TEJ or newer. |
| 0x00000008 | Optimized for ARM-XSCALE or newer. |
| 0x00000009 | Optimized for ARM-V7 or newer. |
| 0x0000000A | Optimized for ARM-V7F (Cortex A9) or newer. |
| 0x0000000B | Optimized for ARM-V7S (Swift) or newer. |
| 0x0000000C | Optimized for ARM-V7K (Kirkwood40) or newer. |
| 0x0000000D | Optimized for ARM-V8 or newer. |
| 0x0000000E | Optimized for ARM-V6M or newer. |
| 0x0000000F | Optimized for ARM-V7M or newer. |
| 0x00000010 | Optimized for ARM-V7EM or newer. |
|

If the CPU type is x86 then the subtypes are as follows:

CPU subtype x86
| Value | CPU version |
| --- | --- |
| 0x00000003 | All x86 processors. |
| 0x00000004 | Optimized for 486 or newer. |
| 0x00000084 | Optimized for 486SX or newer. |
| 0x00000056 | Optimized for Pentium M5 or newer. |
| 0x00000067 | Optimized for Celeron or newer. |
| 0x00000077 | Optimized for Celeron Mobile. |
| 0x00000008 | Optimized for Pentium 3 or newer. |
| 0x00000018 | Optimized for Pentium 3-M or newer. |
| 0x00000028 | Optimized for Pentium 3-XEON or newer. |
| 0x0000000A | Optimized for Pentium-4 or newer. |
| 0x0000000B | Optimized for Itanium or newer. |
| 0x0000001B | Optimized for Itanium-2 or newer. |
| 0x0000000C | Optimized for XEON or newer. |
| 0x0000001C | Optimized for XEON-MP or newer. |

After the subtype value is the file type value.

File type
| Value | Description |
| --- | --- |
| 0x00000001 | Relocatable object file. |
| 0x00000002 | Demand paged executable file. |
| 0x00000003 | Fixed VM shared library file. |
| 0x00000004 | Core file. |
| 0x00000005 | Preloaded executable file. |
| 0x00000006 | Dynamically bound shared library file. |
| 0x00000007 | Dynamic link editor. |
| 0x00000008 | Dynamically bound bundle file. |
| 0x00000009 | Shared library stub for static linking only, no section contents. |
| 0x0000000A | Companion file with only debug sections. |
| 0x0000000B | x86\_64 kexts. |
| 0x0000000C | a file composed of other Mach-Os to be run in the same userspace sharing a single linkedit. |

After the file type value is the number of load commands and the total number of bytes the load commands are after the Mach-O header, then a 32-bit flag with the following possible settings.

Flag Settings
| Flag in left shift | Flag in Binary | Description |
| --- | --- | --- |
| 1\<\<0 | 0000\_0000\_0000\_0000\_0000\_0000\_0000\_0001 | The object file has no undefined references. |
| 1\<\<1 | 0000\_0000\_0000\_0000\_0000\_0000\_0000\_0010 | The object file is the output of an incremental link against a base file and can't be link edited again. |
| 1\<\<2 | 0000\_0000\_0000\_0000\_0000\_0000\_0000\_0100 | The object file is input for the dynamic linker and can't be statically link edited again. |
| 1\<\<3 | 0000\_0000\_0000\_0000\_0000\_0000\_0000\_1000 | The object file's undefined references are bound by the dynamic linker when loaded. |
| 1\<\<4 | 0000\_0000\_0000\_0000\_0000\_0000\_0001\_0000 | The file has its dynamic undefined references prebound. |
| 1\<\<5 | 0000\_0000\_0000\_0000\_0000\_0000\_0010\_0000 | The file has its read-only and read-write segments split. |
| 1\<\<6 | 0000\_0000\_0000\_0000\_0000\_0000\_0100\_0000 | The shared library init routine is to be run lazily via catching memory faults to its writeable segments (obsolete). |
| 1\<\<7 | 0000\_0000\_0000\_0000\_0000\_0000\_1000\_0000 | The image is using two-level name space bindings. |
| 1\<\<8 | 0000\_0000\_0000\_0000\_0000\_0001\_0000\_0000 | The executable is forcing all images to use flat name space bindings. |
| 1\<\<9 | 0000\_0000\_0000\_0000\_0000\_0010\_0000\_0000 | This umbrella guarantees no multiple definitions of symbols in its sub-images so the two-level namespace hints can always be used. |
| 1\<\<10 | 0000\_0000\_0000\_0000\_0000\_0100\_0000\_0000 | Do not have dyld notify the prebinding agent about this executable. |
| 1\<\<11 | 0000\_0000\_0000\_0000\_0000\_1000\_0000\_0000 | The binary is not prebound but can have its prebinding redone. only used when MH\_PREBOUND is not set. |
| 1\<\<12 | 0000\_0000\_0000\_0000\_0001\_0000\_0000\_0000 | Indicates that this binary binds to all two-level namespace modules of its dependent libraries. |
| 1\<\<13 | 0000\_0000\_0000\_0000\_0010\_0000\_0000\_0000 | Safe to divide up the sections into sub-sections via symbols for dead code stripping. |
| 1\<\<14 | 0000\_0000\_0000\_0000\_0100\_0000\_0000\_0000 | The binary has been canonicalized via the un-prebind operation. |
| 1\<\<15 | 0000\_0000\_0000\_0000\_1000\_0000\_0000\_0000 | The final linked image contains external weak symbols. |
| 1\<\<16 | 0000\_0000\_0000\_0001\_0000\_0000\_0000\_0000 | The final linked image uses weak symbols. |
| 1\<\<17 | 0000\_0000\_0000\_0010\_0000\_0000\_0000\_0000 | When this bit is set, all stacks in the task will be given stack execution privilege. |
| 1\<\<18 | 0000\_0000\_0000\_0100\_0000\_0000\_0000\_0000 | When this bit is set, the binary declares it is safe for use in processes with uid zero. |
| 1\<\<19 | 0000\_0000\_0000\_1000\_0000\_0000\_0000\_0000 | When this bit is set, the binary declares it is safe for use in processes when UGID is true. |
| 1\<\<20 | 0000\_0000\_0001\_0000\_0000\_0000\_0000\_0000 | When this bit is set on a dylib, the static linker does not need to examine dependent dylibs to see if any are re-exported. |
| 1\<\<21 | 0000\_0000\_0010\_0000\_0000\_0000\_0000\_0000 | When this bit is set, the OS will load the main executable at a random address. |
| 1\<\<22 | 0000\_0000\_0100\_0000\_0000\_0000\_0000\_0000 | Only for use on dylibs. When linking against a dylib that has this bit set, the static linker will automatically not create a load command to the dylib if no symbols are being referenced from the dylib. |
| 1\<\<23 | 0000\_0000\_1000\_0000\_0000\_0000\_0000\_0000 | Contains a section of type S\_THREAD\_LOCAL\_VARIABLES. |
| 1\<\<24 | 0000\_0001\_0000\_0000\_0000\_0000\_0000\_0000 | When this bit is set, the OS will run the main executable with a non-executable heap even on platforms (e.g. i386) that don't require it. |
| 1\<\<25 | 0000\_0010\_0000\_0000\_0000\_0000\_0000\_0000 | The code was linked for use in an application. |
| 1\<\<26 | 0000\_0100\_0000\_0000\_0000\_0000\_0000\_0000 | The external symbols listed in the nlist symbol table do not include all the symbols listed in the dyld info. |
| 1\<\<27 | 0000\_1000\_0000\_0000\_0000\_0000\_0000\_0000 | Allow LC\_MIN\_VERSION\_MACOS and LC\_BUILD\_VERSION load commands with the platforms macOS, macCatalyst, iOSSimulator, tvOSSimulator and watchOSSimulator. |
| 1\<\<31 | 1000\_0000\_0000\_0000\_0000\_0000\_0000\_0000 | Only for use on dylibs. When this bit is set, the dylib is part of the dyld shared cache, rather than loose in the filesystem. |
| ---- | 0xxx\_0000\_0000\_0000\_0000\_0000\_0000\_0000 | The digits marked with "x" have no use, and are reserved for future use. |

Multiple binary digits can be set to one in the flags to identify any information or settings that apply to the binary.

Now the load commands are read as we have reached the end of the Mach-O header.

## Multi-architecture binaries

Multiple Mach-O files can be combined in a multi-architecture binary. This allows a single binary file to contain code to support multiple instruction set architectures, for example for different generations and types of Apple devices, including different processor architectures such as ARM64 and x86-64.

All fields in the universal header are big-endian.

The universal header is in the following form:

Mach-O universal header
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | Magic number |
| 4 | 4 | Number of binaries |

The magic number in a multi-architecture binary is `0xcafebabe` in big-endian byte order, so the first 4 bytes of the header will always be `0xca 0xfe 0xba 0xbe`, in that order.

The number of binaries is the number of entries that follow the header.

The header is followed by a sequence of entries in the following form:

Mach-O universal file entries
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | CPU type |
| 4 | 4 | CPU subtype |
| 8 | 4 | File offset |
| 12 | 4 | Size |
| 16 | 4 | Section alignment (Power of 2) |

The sequence of entries is followed by a sequence of Mach-O images. Each entry refers to a Mach-O image.

The CPU type and subtype for an entry must be the same as the CPU type and subtype for the Mach-O image to which the entry refers.

The file offset and size are the offset in the file of the beginning of the Mach-O image, and the size of the Mach-O image, to which the entry refers.

The section alignment is the logarithm, base 2, of the byte alignment in the file required for the Mach-O image to which the entry refers; for example, a value of 14 means that the image must be aligned on a 214-byte boundary, i.e. a 16384-byte boundary. This is required by tools that modify the multi-architecture binary, in order for them to keep the image properly aligned.

## Load commands

The load commands are read immediately after the Mach-O header.

The Mach-O header tells us how many load commands exist after the Mach-O header and the size in bytes to where the load commands end. The size of load commands is used as a redundancy check.

When the last load command is read and the number of bytes for the load commands do not match, or if we go outside the number of bytes for load commands before reaching the last load command, then the file may be corrupted.

Each load command is a sequence of entries in the following form:

Load command
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | Command type |
| 4 | 4 | Command size |

The load command type identifies what the parameters are in the load command. If a load command starts with `0x80000000` bit set that means the load command is necessary in order to be able to load or run the binary. This allows older Mach-O loaders to skip commands not understood by the loader that are not mandatory for loading the application.

### Segment load command

Mach-O binaries that use load command type `0x00000001` use the 32-bit version of the segment load command, while `0x00000019` is used to specify the 64-bit version of the segment load command.,

The segment load command varies if the Mach-O header is 32-bit, or 64-bit. This is because 64-bit processor architecture uses 64-bit addresses while 32-bit architectures use 32-bit addresses.

All virtual RAM addresses are added to a base address to keep applications spaced apart. Each section in a segment load command has a relocation list offset that specifies the offsets in the section that must be adjusted based on the application's base address. The relocations are unnecessary if the application can be placed at its defined RAM address locations such as a base address of zero.

Load command (Segment load32/64)
| Offset(32-bit) | Bytes(32-bit) | Offset(64-bit) | Bytes(64-bit) | Description |
| --- | --- | --- | --- | --- |
| 0 | 4 | 0 | 4 | `0x00000001` (Command type 32-bit) `0x00000019` (Command type 64-bit) |
| 4 | 4 | 4 | 4 | Command size |
| 8 | 16 | 8 | 16 | Segment name |
| 24 | 4 | 24 | 8 | Address |
| 28 | 4 | 32 | 8 | Address size |
| 32 | 4 | 40 | 8 | File offset |
| 36 | 4 | 48 | 8 | Size (bytes from file offset) |
| 40 | 4 | 56 | 4 | Maximum virtual memory protections |
| 44 | 4 | 60 | 4 | Initial virtual memory protections |
| 48 | 4 | 64 | 4 | Number of sections |
| 52 | 4 | 68 | 4 | Flag32 |

A segment name cannot be larger than 16 text characters in bytes. The unused characters are `0x00` in value.

The segment command contains the address to write the section in virtual address space plus the application's base address. The number of bytes to write to the address location (Address size).

After the address information is the file offset the segment data is located in the Mach-O binary, and the number of bytes to read from the file.

When the address size is larger than the number of bytes to read from the file, the rest of the bytes in RAM space are set `0x00`.

There is a segment that is called \__PAGEZERO, which has a file offset of zero and a size of zero in the file. It has a defined RAM address and size. Since it reads zero bytes from the file it fills the address location with zeros to where the binary is going to be placed in RAM. This segment is necessary to rid the section of any data from a prior application.

When a segment is initially placed in the virtual address space, it is given the CPU access permissions specified by the initial virtual memory protections value. The permissions on a region of the virtual address space may be changed by application or library code with calls to routines such as `mprotect()`; the maximum virtual memory protections limit what permissions may be granted for access to the segment.

Permissions
| Permission bit in binary | Description |
| --- | --- |
| `00000000000000000000000000000001` | The section allows the CPU to read data from this section (Read setting). |
| `00000000000000000000000000000010` | The section allows the CPU to write data to this section (Write setting). |
| `00000000000000000000000000000100` | The section allows the CPU to execute code in this section (Execute setting). |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxx000` | The digits marked with "x" have no use, and are reserved for future use. |

Then after the CPU address protection settings is the number of sections that are within this segment that are read after the segments flag settings.

The segment flag settings are as follows:

Segment flag settings.
| Flag32 in Binary | Description |
| --- | --- |
| `00000000000000000000000000000001` | The file contents for this segment is for the high part of the VM space, the low part is zero filled (for stacks in core files). |
| `00000000000000000000000000000010` | This segment is the VM that is allocated by a fixed VM library, for overlap checking in the link editor. |
| `00000000000000000000000000000100` | This segment has nothing that was relocated in it and nothing relocated to it, that is it maybe safely replaced without relocation. |
| `00000000000000000000000000001000` | This segment is protected. If the segment starts at file offset 0, the first page of the segment is not protected. All other pages of the segment are protected. |
| `00000000000000000000000000010000` | This segment is made read-only after relocations are applied if needed. |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxx00000` | The digits marked with "x" have no use, and are reserved for future use. |

The number of sections in the segment is a set of entries that are read as follows:

Segment section32/64
| Offset(32-bit) | Bytes(32-bit) | Offset(64-bit) | Bytes(64-bit) | Description |
| --- | --- | --- | --- | --- |
| 0 | 16 | 0 | 16 | Section name |
| 16 | 16 | 16 | 16 | Segment name |
| 32 | 4 | 32 | 8 | Section Address |
| 36 | 4 | 40 | 8 | Section size |
| 40 | 4 | 48 | 4 | Section file offset |
| 44 | 4 | 52 | 4 | Alignment |
| 48 | 4 | 56 | 4 | Relocations file offset |
| 52 | 4 | 60 | 4 | Number of relocations |
| 56 | 4 | 64 | 4 | Flag/Type |
| 60 | 4 | 68 | 4 | Reserved1 |
| 64 | 4 | 72 | 4 | Reserved2 |
| N/A | N/A | 76 | 4 | Reserved3 (64-bit only) |

The section's segment name must match the segments load command name. The sections entries locate to data in the segment. Each section locates to the relocation entries for adjusting addresses in the section if the application base address is added to anything other than zero.

The section size applies to both the size of the section at its address location and size in the file at its offset location.

The section Flag/Type value is read as follows:

Section flag settings
| Flag in binary | Description |
| --- | --- |
| `10000000000000000000000000000000xxxxxxxx` | Section contains only true machine instructions |
| `01000000000000000000000000000000xxxxxxxx` | Section contains coalesced symbols that are not to be in a ranlib table of contents |
| `00100000000000000000000000000000xxxxxxxx` | Ok to strip static symbols in this section in files with the MH\_DYLDLINK flag |
| `00010000000000000000000000000000xxxxxxxx` | No dead stripping |
| `00001000000000000000000000000000xxxxxxxx` | Blocks are live if they reference live blocks |
| `00000100000000000000000000000000xxxxxxxx` | Used with i386 code stubs written on by dyld |
| `00000010000000000000000000000000xxxxxxxx` | A debug section |
| `00000000000000000000010000000000xxxxxxxx` | Section contains some machine instructions |
| `00000000000000000000001000000000xxxxxxxx` | Section has external relocation entries |
| `00000000000000000000000100000000xxxxxxxx` | Section has local relocation entries |

Any of the settings that apply to the section have a binary digit set one. The last eight binary digits is the section type value.

Section type value
| Flag in binary | Description |
| --- | --- |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00000110` | Section with only non-lazy symbol pointers |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00000111` | Section with only lazy symbol pointers |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00001000` | Section with only symbol stubs |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00001100` | Zero fill on demand section (that can be larger than 4 gigabytes) |
| `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx00010000` | Section with only lazy symbol pointers to lazy loaded dylibs |

The Mach-O loader records the symbol pointer sections and symbol stub sections. They are sequentially used by the indirect symbol table to load in method calls.

The size of each symbol stub is stored in reserved2 value. Each pointer is 32-bit address locations in 32-bit Mach-O and 64-bit address locations in 64-bit Mach-O. Once the section end is reached, we move to the next section while reading the indirect symbol table.

#### Segment number and section numbers

The segments and sections are located by segment number and section number in the compressed and uncompressed link edit information sections.

A segment value of 3 would mean the offset to the data of the fourth segment load command in the Mach-O file starting from zero up (0,1,2,3 = 4th segment).

Sections are also numbered from sections 1 and up. Section value zero is used in the symbol table for symbols that are not defined in any section (undefined). Such as an method, or data that exist within another binaries symbol table section.

A segment that has 7 sections would mean the last section is 8. Then if the following segment load command has 3 sections they are labelled as sections 9, 10, and 11. A section number of 10 would mean the second segment, section 2.

We would not be able to properly read the symbol table and linking information if we do not store the order the sections are read in and their address/file offset position.

You can easily use file offset without using the RAM addresses and relocations to build a symbol reader and to read the link edit sections and even map method calls or design a disassembler.

If building a Mach-O loader, then you want to dump the sections to the defined RAM addresses plus a base address to keep applications spaced apart so they do not write over one another.

The segment names and section names can be renamed to anything you like and there link will be no problems locating the appropriate sections by section number, or segment number as long as you do not alter the order the segment commands go in.

Link libraries are the same as any other Mach-O binary, just that there is no command that specifies the main entry point at which the program begins.

There are three load commands for loading a link library file.

Load command type `0x0000000C` are for the full file path to the dynamically linked shared library.

Load command type `0x0000000D` are for dynamically linked shared locations from the application's current path.

Load command type `0x00000018` is for a dynamically linked shared library that is allowed to be missing. The symbol names exist in other link libraries and are used if the library is missing meaning all symbols are weak imported.

The link library command is read as follows:

Load command (Link library)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x0000000C` (Command type) `0x0000000D` (Command type)
`0x00000018` (Command type) |
| 4 | 4 | Command size |
| 8 | 4 | String offset (always offset 24) |
| 12 | 4 | Time date stamp |
| 16 | 4 | Current version |
| 20 | 4 | Compatible version |
| 24 | Command size - 24 | File path string |

The file path name begins at the string offset, which is always 24. The number of bytes per text character is the remaining bytes in command size. The end of the library file path is identified by a character that is `0x00`. The remaining `0x00` values are used as padding, if any.

The library is located by ordinal number in the compressed and uncompressed link edit information sections.

Link libraries are numbered from ordinal 1 and up. The ordinal value zero is used in the symbol table to specify the symbol does not exist as an external symbol in another Mach-O binary.

The link edit information will have no problem locating the appropriate library to read by ordinal number as long as you do not alter the order in which the link library commands go in.

Link library command `0x00000018` should be avoided for performance reasons, as in the case the library is missing, then a search must be performed through all loaded link libraries.

### \__LINKEDIT Symbol table

Mach-O application files and link libraries both have a symbol table command.

The command is read as follows:

Load command (Symbol table)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x00000002` (Command type) |
| 4 | 4 | Command size (always 24) |
| 8 | 4 | Symbols (file offset relative to Mach-O header) |
| 12 | 4 | Number of Symbols |
| 16 | 4 | String table (file offset relative to Mach-O header) |
| 20 | 4 | String table size |

The symbol file offset is the offset relative to the start of the Mach-O header to where the symbol entries begins in the file. The number of symbol entries marks the end of the symbol table.

A symbol has a name offset that should never exceed the string table size. Each symbol name offset is added to the string table file offset which in turn is relative to the start of the Mach-O header. Each symbol name ends with a `0x00` byte value.

The symbol address uses a 32-bit address for 32-bit Mach-O files and a 64-bit address for 64-bit Mach-O files.

Each symbol entry is read as follows:

Symbol32/64
| Offset(32-bit) | Bytes(32-bit) | Offset(64-bit) | Bytes(64-bit) | Description |
| --- | --- | --- | --- | --- |
| 0 | 4 | 0 | 4 | Name offset |
| 4 | 1 | 4 | 1 | Symbol type |
| 5 | 1 | 5 | 1 | Section number 0 to 255 |
| 6 | 2 | 6 | 2 | Data info (library ordinal number) |
| 8 | 4 | 8 | 8 | Symbol address |

The symbol name offset is added to the string table offset. The last text character byte is read as `0x00`.

The symbol type value has multiple adjustable sections in binary. The symbol type is read as follows:

Symbol type sections
| Binary digits | Description |
| --- | --- |
| `???xxxxx` | Local debugging symbols |
| `xxxx???x` | Symbol address type |
| `xxx?xxx?` | Symbol visibility setting flags |

The digits marked `?` are used for the specified purpose; the digits marked `x` are used for other purposes.

The three first binary digits are symbols that locate to function names relative to compiled machine code instructions and line numbers by address location. This information allows us to generate line numbers to the location your code crashed. Local debugging symbols are only useful when designing the application, but are not needed to run the application.

Symbol address type
| Binary value | Description |
| --- | --- |
| `xxxx000x` | Symbol undefined |
| `xxxx001x` | Symbol absolute |
| `xxxx101x` | Symbol indirect |
| `xxxx110x` | Symbol prebound undefined |
| `xxxx111x` | Symbol defined in section number |

The following flag settings:

Symbol visibility setting flags
| Binary value | Description |
| --- | --- |
| `xxx1xxx0` | Private symbol |
| `xxx0xxx1` | External symbol |

External symbols are symbols that have a defined address in the link library and can be copied to an undefined symbol in a Mach-O application. The address location is added to the link library base address.

A private symbol is skipped even if it matches the name of an undefined symbol. A private and external symbol can only be set to an undefined symbol if it is in the same file.

After the symbol type is the section number the symbol exists in. The section number is a byte value (0 to 255). You can add more sections than 255 using segment load commands, but the section numbers are then outside the byte value range used in the symbol entries.

A section number of zero means the symbol is not in any section of the application, the address location of the symbol is zero, and is set as Undefined. A matching External symbol name has to be found in a link library that has the symbol address.

The data info field contains the link library ordinal number that the external symbol can be found in with the matching symbol name. The data info bit field breaks down as follows:

Symbol data info sections
| Binary digits | Description |
| --- | --- |
| `????????xxxxxxxx` | Library ordinal number 0 to 255 |
| `xxxxxxxx????xxxx` | Dynamic loader flag options |
| `xxxxxxxxxxxx????` | Address type option |

The library ordinal number is set zero if the symbol is an external symbol, or exists in the current file. Only undefined symbols use the data info section to specify a library ordinal number and linker options.

The dynamic loader flag options are as follows:

Dynamic loader flag options
| Binary digits | Description |
| --- | --- |
| `xxxxxxxx0001xxxx` | Must be set for any defined symbol that is referenced by dynamic-loader. |
| `xxxxxxxx0010xxxx` | Used by the dynamic linker at runtime. |
| `xxxxxxxx0100xxxx` | If the dynamic linker cannot find a definition for this symbol, it sets the address of this symbol to 0. |
| `xxxxxxxx1000xxxx` | If the static linker or the dynamic linker finds another definition for this symbol, the definition is ignored. |

Any of the 4 options that apply can be set.

The address type option values are as follows:

Dynamic loader address options
| Binary digits | Description |
| --- | --- |
| `xxxxxxxxxxxx0000` | Non Lazy loaded pointer method call |
| `xxxxxxxxxxxx0001` | Lazy loaded pointer method call |
| `xxxxxxxxxxxx0010` | Method call defined in this library/program |
| `xxxxxxxxxxxx0011` | Private Method call defined in this library/program |
| `xxxxxxxxxxxx0100` | Private Non Lazy loaded pointer method call |
| `xxxxxxxxxxxx0101` | Private Lazy loaded pointer method call |

Only one address type value can be set by value. A Pointer is a value that is read by the program machine code to call a method from another binary file. Private means other programs are not intended to be able to read or call the function/methods other than the binary itself. Lazy means the pointer locates to the dyld\_stub\_binder which looks for the symbol then calls the method, then replaces the dyld\_stub\_binder location with the location to the symbol. Any more calls done from machine code in the binary will now locate to the address of the symbol and will not call the dyld\_stub\_binder.

#### Symbol table organization

The symbol table entries are all stored in order by type. The first symbols that are read are local debug symbols if any, then private symbols, then external symbols, and finally the undefined symbols that link to another binary symbol table containing the external symbol address in another Mach-O binary.

The symbol table information load command `0x0000000B` always exists if there is a symbol table section in the Mach-O binary. The command tells the linker how many local symbols there are, how many private, how many external, and how many undefined. It also identifies the symbol number they start at. The symbol table information is used before reading the symbol entries by the dynamic linker as it tells the dynamic linker where to start reading the symbols to load in undefined symbols and where to start reading to look for matching external symbols without having to read all the symbol entries.

The order the symbols go in the symbol section should never be altered as each symbol is numbered from zero up. The symbol table information command uses the symbol numbers for the order to load the undefined symbols into the stubs and pointer sections. Altering the order would cause the wrong method to be called during machine code execution.

### \__LINKEDIT Symbol table information

The symbol table information command is used by the dynamic linker to know where to read the symbol table entries under symbol table command `0x00000002`, for fast lookup of undefined symbols and external symbols while linking.

The command is read as follows:

Load command (Symbol table information)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x0000000B` (Command type) |
| 4 | 4 | Command size (always 80) |
| 8 | 4 | Local symbol index |
| 12 | 4 | Number of local symbols |
| 16 | 4 | External symbols index |
| 20 | 4 | Number of external symbols |
| 24 | 4 | Undefined symbols index |
| 28 | 4 | Number of undefined symbols |
| 32 | 4 | Content table offset |
| 36 | 4 | Number of content table entries |
| 40 | 4 | Module table offset |
| 44 | 4 | Number of module table entries |
| 48 | 4 | Offset to referenced symbol table |
| 52 | 4 | Number of referenced symbol table entries |
| 56 | 4 | Indirect symbol table offset |
| 60 | 4 | Indirect symbol table entries |
| 64 | 4 | External relocation offset |
| 68 | 4 | Number of external relocation entries |
| 72 | 4 | Local relocation offset |
| 76 | 4 | Number of Local relocation entries |

The symbol index is multiplied by 12 for Mach-O 32-bit, or 16 for Mach-O 64-bit plus the symbol table entries offset to find the offset to read the symbol entries by symbol number index.

The local symbol index is zero as it is at the start of the symbol entries. The local symbols are used for debugging information.

Number of local symbols is how many exist after the symbol index.

The same two properties are repeated for external symbols and undefined symbols for fast reading of the symbol table entries.

There is a small index/size gap between local symbols and external symbols if there are private symbols.

Any file offsets that are zero are unused.

#### Indirect table

The Mach-O loader records the symbol pointer sections and symbol stub sections during the segment load commands. They are sequentially used by the indirect symbol table to load in method calls. Once the section end is reached, we move to the next.

The Indirect symbol table offset locates to a set of 32-bit (4-byte) values that are used as a symbol number index.

The order the symbol index numbers go is the order we write each symbol address one after another in the pointer and stub sections.

The symbol stub section contains machine code instructions with JUMP instructions to the indirect symbol address to call a method/function from another Mach-O binary. The size of each JUMP instruction is based on processor type and is stored in the reserved2 value under the section32/64 of a segment load command.

The pointer sections are 32-bit (4-byte) address values for 32-bit Mach-O binaries and 64-bit (8-byte) address values for 64-bit Mach-O binaries. Pointers are read by machine code and the read value is used as the location to call the method/function rather than containing machine code instructions.

A symbol index number `0x40000000` bit set are absolute methods meaning the pointer locates to the exact address of a method.

A symbol index number `0x80000000` bit set are local methods meaning the pointer itself located to the method and that there is no method name (Local method).

If you are designing a disassembler you can easily map just the symbol name to the offset address of each stub and pointer to show the method or function call taking place without looking for the undefined symbol address location in other Mach-O files.

### \__LINKEDIT Compressed table

If the compressed link edit table command exists, then the undefined/external symbols in the symbol table are no longer needed. The indirect symbol table and location of the stubs and pointer sections are no longer required.

The indirect symbol table still exists in the case of building backwards compatible Mach-O files that load on newer and older OS versions.

Load command (Compressed link edit table)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x00000022` (Command type) |
| 4 | 4 | Command size (always 48 bytes) |
| 8 | 4 | Rebase file offset |
| 12 | 4 | Rebase size |
| 16 | 4 | Bind file offset |
| 20 | 4 | Bind size |
| 24 | 4 | Weak bind file offset |
| 28 | 4 | Weak bind size |
| 32 | 4 | Lazy bind file offset |
| 36 | 4 | Lazy bind size |
| 40 | 4 | Export file offset |
| 44 | 4 | Export size |

Any file offsets that are zero are sections that are unused.

#### Binding information

The bind, weak bind, and lazy bind sections are read using the same operation code format.

Originally the symbol table would define the address type in the data info field in the symbol table as lazy, weak, or non-lazy.

Weak binding means that if the set library to look in by library ordinal number, and the set symbol name does not exist but exists under a different previously loaded Mach-O file then the symbol location is used from the other Mach-O file.

Lazy means the address that is written located to the dyld\_stub\_binder, which looks for the symbol then calls the method, then replaces the dyld\_stub\_binder location with the location to the symbol. Any more calls done from machine code in the binary will now locate to the address of the symbol and will not call the dyld\_stub\_binder.

The plain old bind section does not do any fancy loading or address tricks. The symbol must exist in the set library ordinal.

A byte value that is `0x1X` sets the link library ordinal number. The hex digit that is X is a 0 to 15 library ordinal number.

A byte value that is `0x20` to `0x2F` sets the link library ordinal number to the value that is read after the operation code.

The byte sequence `0x20 0x84 0x01` set ordinal number 132.

The number value after the operation code is encoded as a LEB128 number. The last 7 binary digits are added together to form a larger number as long as the last binary digit is set one in value. This allows us to encode variable length number values.

A byte value that is `0x4X` sets the symbol name. The hex digit marked X sets the flag setting.

Flag setting 8 means the method is weak imported. Flag setting 1 means the method is non weak imported.

The byte sequence `0x48 0x45 0x78 0x61 0x6D 0x70 0x6C 0x65 0x00` sets the symbol name Example. The last text character byte is `0x00`. It is also weak imported, meaning it can be replaced if another exportable symbol is found with the same name.

A byte value `0x7X` sets the current location. The hex digit marked X is the selected segment 0 to 15. After the operation code is the added offset as a LEB128 number to the segment offset.

The byte sequence `0x72 0x8C 0x01` sets the location to the third segment load command address and adds 140 to the address.

Operation code `0x90` to `0x9F` binds the current set location to the set symbol name and library ordinal. Increments the current set location by the size 4 bytes for a 32-bit Mach-O binary or increments the set address by 8 for a 64-bit Mach-O binary.

The byte sequence `0x11 0x72 0x8C 0x01 0x48 0x45 0x78 0x61 0x6D 0x70 0x6C 0x65 0x00 0x90 0x48 0x45 0x78 0x61 0x6D 0x70 0x6C 0x65 0x32 0x00 0x90`

Sets link library ordinal 1. Set location to segment number 2, and adds 140 to the current location. Looks for a symbol named Example in the selected library ordinal number. Operation code `0x90` writes the symbol address and increments the current set address. The operation code after that sets the next symbol name to look for a symbol named Example2. Operation code `0x90` writes the symbol address and increments the current set address.

The new format removes the repeated fields in the symbol table and makes the indirect symbol table obsolete.

### Application main entry point

A load command starting with type `0x00000028` is used to specify the address location the application begins at.

Load command (Main entry point)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x00000028` (Command type) |
| 4 | 4 | Command size (always 24 bytes) |
| 8 | 8 | Address location |
| 16 | 8 | Stack memory size |

If the segments/sections of the program do not have to be relocated to run, then the main entry point is the exact address location. This is only if the application segment addresses are added to an application base address of zero and the sections did not need any relocations.

The main entry point in a Mach-O loader is the program's base address plus the Address location. This is the address at which the CPU is set to begin running machine code instructions.

This replaced the old load command `0x00000005` which varied by CPU type as it stored the state that all the registers should be at before the program starts.

### Application UUID number

A load command starting with type `0x0000001B` is used to specify the universally unique identifier (UUID) of the application.

Load command (UUID number)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x0000001B` (Command type) |
| 4 | 4 | Command size (always 24 bytes) |
| 8 | 16 | 128-bit UUID |

The UUID contains a 128-bit unique random number when the application is compiled that can be used to identify the application file on the internet or in app stores.

### Minimum OS version

A load command starting with type `0x00000032` is used to specify the minimum OS version information.

Load command (Minimum OS version)
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | `0x00000032` (Command type) |
| 4 | 4 | Command size |
| 8 | 4 | Platform type |
| 12 | 4 | Minimum OS version |
| 16 | 4 | SDK version |
| 20 | 4 | Number of tools used |

The Platform type the binary is intended to run on are as follows:

Platform type.
| Value | Platform |
| --- | --- |
| 0x00000001 | macOS |
| 0x00000002 | iOS |
| 0x00000003 | tvOS |
| 0x00000004 | watchOS |
| 0x00000005 | bridgeOS |
| 0x00000006 | Mac Catalyst |
| 0x00000007 | iOS simulator |
| 0x00000008 | tvOS simulator |
| 0x00000009 | watchOS simulator |
| 0x0000000A | DriverKit |
| 0x0000000B | visionOS |
| 0x0000000C | visionOS simulator |

The 32-bit version value is read as a 16-bit value and two 8-bit values. A 32-bit version value of `0x000D0200` breaks down as `0x000D` which is 13 in value, then the next 8-bits is `0x02` which is 2 in value, then the last 8-bits is `0x00` which is zero in value giving a version number of 13.2.0v. The SDK version value is read the same way.

The number of tools to create the binary is a set of entries that are read as follows:

Tool type
| Offset | Bytes | Description |
| --- | --- | --- |
| 0 | 4 | Tool type |
| 4 | 4 | Vestion type |

The tool type values are as follows:

Tool type value.
| Value | Tool type used |
| --- | --- |
| 0x00000001 | CLANG |
| 0x00000002 | SWIFT |
| 0x00000003 | LD |

The version number is read the same as OS version and SDK version.

With the introduction of Mac OS X 10.6 platform the Mach-O file underwent a significant modification that causes binaries compiled on a computer running 10.6 or later to be (by default) executable only on computers running Mac OS X 10.6 or later. The difference stems from load commands that the dynamic linker, in previous Mac OS X versions, does not understand. Another significant change to the Mach-O format is the change in how the Link Edit tables (found in the \__LINKEDIT section) function. In 10.6 these new Link Edit tables are compressed by removing unused and unneeded bits of information, however Mac OS X 10.5 and earlier cannot read this new Link Edit table format. To make backwards-compatible executables, the linker flag "-mmacosx-version-min=" can be used.

## Other implementations

A Mach-O application can be run on different operating systems or OS as long as a Mach-O binary image exists that matches the core type in your computer. Most desktops are x86, meaning that a Mach-O with an x86 binary will run without problems if you load the sections into memory. If the Mach-O is designed for iPhone, which has an ARM core, then you would need a PC with an ARM core (does not have to be apple silicon ARM) to run it; otherwise, you would have to change ARM encoded instructions to equivalent x86 encoded instructions. The problem of loading and directly executing a Mach-O is undefined symbols that call functions/methods from other Mach-O binaries that do not exist on another operating system. Some symbols can call other equivalent functions in the different operating systems or even call adaptor functions to make other binary function calls behave like the macOS equivalents. The Mach-O files stored on the device can vary between iPhone (iOS), macOS, watchOS, and tvOS. Causing differences in function calls from undefined symbols.

Some versions of NetBSD have had Mach-O support added as part of an implementation of binary compatibility, which allowed some Mac OS 10.3 binaries to be executed.

For Linux, a Mach-O loader was written by Shinichiro Hamaji that can load 10.6 binaries. As a more extensive solution based on this loader, the Darling Project aims at providing a complete environment allowing macOS applications to run on Linux.

For the Ruby programming language, the ruby-macho library provides an implementation of a Mach-O binary parser and editor.

### Bibliography

* Levin, Jonathan (September 25, 2019). *\*OS Internals, Volume 1: User Mode* (v1.3.3.7 ed.). North Castle, NY: Technologeeks. ISBN 978-0-9910555-6-2.
* Singh, Amit (June 19, 2006). *Mac OS X Internals: A Systems Approach*. Addison-Wesley Professional. ISBN 978-0-13-270226-3.

## InfoBox

Mach-O
|  | |
| --- | --- |
| Filename extension | none, `.o`, `.dylib`, `.kext` |
| Uniform Type Identifier (UTI) | com.apple.mach-o-binary |
| Developed by | Carnegie Mellon University, Apple Inc. |
| Type of format | Binary, executable, object, shared libraries, core dump |
| Container for | ARM, SPARC, PA-RISC, PowerPC and x86 executable code, memory image dumps |


title: Texas City tin smelter

abstract: The Texas City tin smelter is a former metallurgical plant in Texas City and La Marque, United States. It was created in 1942, during the Second World War, to secure the American production of tin from imported ores. It operates until 1991, gradually diversifying. Founded and operated by the U.S. state as Longhorn Tin Smelter, it produced, towards the end of the war, up to 45% of the world's tin production. But deprived of access to tin ore deposits, it collapsed as soon as the international situation normalized. Privatized, it became, under the name of Tex-Tin Corporation, a pioneering plant in the use of the Kaldo process for the recycling of tin-rich waste. However, this reconversion was not sufficient to overcome the low availability of tin ores, and the plant was unable to revive. When it closed, soil pollution was significant and the brownfields were taken over by the Environmental Protection Agency. The restoration plan was successfully completed in 2003.

text:
# Texas City tin smelter

The **Texas City tin smelter** is a former metallurgical plant in Texas City and La Marque, United States. It was created in 1942, during the Second World War, to secure the American production of tin from imported ores. It operates until 1991, gradually diversifying.

Founded and operated by the U.S. state as **Longhorn Tin Smelter**, it produced, towards the end of the war, up to 45% of the world's tin production. But deprived of access to tin ore deposits, it collapsed as soon as the international situation normalized. Privatized, it became, under the name of **Tex-Tin Corporation**, a pioneering plant in the use of the Kaldo process for the recycling of tin-rich waste.

However, this reconversion was not sufficient to overcome the low availability of tin ores, and the plant was unable to revive. When it closed, soil pollution was significant and the brownfields were taken over by the Environmental Protection Agency. The restoration plan was successfully completed in 2003.

## InfoBox

| Texas City tin smelter | |
| --- | --- |
|  | |
| Built | March 1941 (1941-03) |
| Operated | 5 April 1942 – April 1991 |
| Location | Texas City |
| Coordinates | 29°21′24″N 94°56′27″W / 29.356762°N 94.940918°W / 29.356762; -94.940918 |
| Industry | Extractive metallurgy |
| Products | Tin |
| Employees | 850 (1946) |
| Area | 170 acres (0.69 km2) |
| Defunct | April 1991 (1991-04) |


title: European Reform Forum

abstract: The European Reform Forum (ERF) is a committee of senior British politicians, journalists, academics, and businessmen who are seeking to produce a report on the future direction of the European Union. The members are drawn predominantly from a Conservative background. It was launched on 30 June 2005 in the Houses of Parliament in front of a large number of press. Over the six months of the UK presidency of the European Council the ERF took evidence from numerous people on both sides of the debate and produced a final report in December 2005. It advocated the renegotiation of British membership.

text:
# European Reform Forum

**The European Reform Forum** (**ERF**) is a committee of senior British politicians, journalists, academics, and businessmen who are seeking to produce a report on the future direction of the European Union. The members are drawn predominantly from a Conservative background. It was launched on 30 June 2005 in the Houses of Parliament in front of a large number of press. Over the six months of the UK presidency of the European Council the ERF took evidence from numerous people on both sides of the debate and produced a final report in December 2005. It advocated the renegotiation of British membership.

## Membership

## People who have given evidence


title: Terminio

abstract: Terminio is a mountain of Campania, Italy. It has an elevation of 1,806 metres above sea level.

text:
# Terminio

**Terminio** is a mountain of Campania, Italy. It has an elevation of 1,806 metres above sea level.

40°51′N 14°52′E / 40.850°N 14.867°E / 40.850; 14.867

## InfoBox

| Terminio | |
| --- | --- |
|  | |
| Highest point | |
| Elevation | 1,806 m (5,925 ft) |
| Prominence | 954 m (3,130 ft) |
| Geography | |
| TerminioLocation in Italy | |
| Location | Campania, Italy |
| Parent range | Apennines |


title: Macelj massacre

abstract: The Macelj massacre occurred in May and June 1945, at the end of World War II in Europe, in the forests near Macelj, a village in northern Croatia. At the site, a large number of soldiers, women, and children were shot during the Bleiburg repatriations.

text:
# Macelj massacre

The **Macelj massacre** occurred in May and June 1945, at the end of World War II in Europe, in the forests near Macelj, a village in northern Croatia. At the site, a large number of soldiers, women, and children were shot during the Bleiburg repatriations.

## Events

In 1992, after Croatia became independent, 1,163 bodies were excavated from 23 mass graves in the region, leaving around 130 possible mass grave locations unexplored.

Among those executed in Macelj were 25 Catholic priests from the Franciscan monastery of Široki Brijeg, which were temporarily hidden in nearby Krapina. In 2008, the Croatian Ministry of the Interior launched an investigation into Stjepan Hršak's possible involvement in that event.

Reburial of the exhumed bodies in 2005 was followed by a public mass led by Cardinal Josip Bozanić, at the time Archbishop of Zagreb.

## InfoBox

| Macelj massacre | |
| --- | --- |
| Part of the Bleiburg repatriations | |
| A cross in Macelj | |
| Location | Macelj, SR Croatia, Yugoslavia<br>(now Croatia) |
| Date | May and June 1945 |
| Target | NDH prisoners of war and civilians |
| Attack type | Mass executions |
| Deaths | 12,000 (estimated) |
| Perpetrators | Yugoslav Partisans |


title: Tetrabarbital

abstract: Tetrabarbital is a barbiturate derivative used as a hypnotic.

text:
# Tetrabarbital

**Tetrabarbital** (INN; **Butysal**, **Butysedal**, **Tetramal**) is a barbiturate derivative used as a hypnotic.

## InfoBox

Tetrabarbital
|  | |
| --- | --- |
| Clinical data | |
| ATC code | * None |
| Identifiers | |
| IUPAC name * 5-ethyl-5-(hexan-3-yl)pyrimidine-2,4,6(1*H*,3*H*,5*H*)-trione | |
| CAS Number |  |
| PubChem CID |  |
| ChemSpider |  |
| UNII |  |
| CompTox Dashboard (EPA) |  |
| ECHA InfoCard | 100.000.861 |
| Chemical and physical data | |
| Formula | C12H20N2O3 |
| Molar mass | 240.303 g·mol−1 |
| 3D model (JSmol) |  |
| SMILES * O=C1NC(=O)NC(=O)C1(C(CC)CCC)CC | |
| InChI * InChI=1S/C12H20N2O3/c1-4-7-8(5-2)12(6-3)9(15)13-11(17)14-10(12)16/h8H,4-7H2,1-3H3,(H2,13,14,15,16,17) * Key:ZLUNGGZJSQDFPH-UHFFFAOYSA-N | |