Was ist mit "#ifdef _MAC" in Windows-Header-Dateien?

Question

Ich war durch Windows Platform SDK-Header-Dateien (was für ein Leben, richtig?), Und ich bemerkte, dass viele Orte Referenzen auf das Präprozessorsymbol _MAC enthalten. Zum Beispiel:

// WinUser.h line 1568 
/* 
* Message structure 
*/ 
typedef struct tagMSG { 
    HWND  hwnd; 
    UINT  message; 
    WPARAM  wParam; 
    LPARAM  lParam; 
    DWORD  time; 
    POINT  pt; 
#ifdef _MAC 
    DWORD  lPrivate; 
#endif 
} MSG, *PMSG, NEAR *NPMSG, FAR *LPMSG; 

Bedeutet dies "Macintosh", wie es scheint? Gab es eine Zeit, in der Windows oder eine Untergruppe von Windows für den Macintosh kompiliert werden konnte?

Answer 1

Zu einer Zeit war Microsoft der größte Entwickler von Macintosh-Software in der Welt. Excel und Word beherrschten ihre jeweiligen Märkte auf dem Macintosh, und später auch Office. So ist es nicht verwunderlich, dass die Anwendungsabteilung von MS eine Teilmenge der Windows-Header-Dateien, die auf dem MAC funktionierten, haben möchte, damit ihre plattformübergreifende Software einfacher zu warten ist.

Aber es gab nie eine Version des Windows-Betriebssystems, die auf dem Macintosh ausgeführt wurde.

In jedem Fall dieses Fragment aus objidl.h ist, scheint darauf hinzudeuten, dass _MAC tatsächlich Macintosh bedeutet in der Header-Dateien, obwohl ...

//FSSpec is Macintosh only, defined in macos\files.h 
#ifdef _MAC 
    typedef struct tagSTATSTG 
    {      
     LPOLESTR pwcsName; 
      FSSpec *pspec; 
     DWORD type; 
     ULARGE_INTEGER cbSize; 
... 
    } STATSTG; 
#else //_MAC 

Answer 2

Ich nehme an, dass es/wurde für die Kompilierung von Microsoft-Software (Office, IE, Windows Media Player) für MacOS verwendet wurde. Ich weiß, dass IE und WMP für Solaris eine Untergruppe von Windows selbst (z. B. libwinnt.so, libkernel32.so) als direkten Ersatz für die entsprechenden Windows-DLLs enthalten.

Answer 3

Viele MS-Code verweist auf MAC, wie sie auch für Mac entwickeln - zum Beispiel Büro. Wahrscheinlich kam dieses Bit der Header-Datei von diesen Teams.

Answer 4

Wie andere erwähnt haben, wurden Microsoft-Anwendungen portiert der Mac, und sie fanden es wahrscheinlich einfacher, die zugrunde liegenden APIs/Frameworks in eine portable Abstraktionsschicht umzuwandeln, anstatt die Apps selbst neu zu schreiben ... genau wie das QuickTime-Team bei der Portierung in die entgegengesetzte Richtung (von Mac nach Windows) - In den Carbon-Headern des Mac gibt es ähnliche #if WIN32-Bedingungen. Wenn Sie zum Beispiel die Codebasis Ihrer gesamten Win32-Anwendung nach CreateFile() durchsuchen und jede Referenz durch #ifdefs ersetzen oder konditionieren, erstellen Sie einfach eine Mac-Version von CreateFile() und machen Sie damit fertig. Wiederholen Sie dies für jeden Win32-API-Aufruf.

Das Überraschende an historischer Trivialität ist folgendes: Das Endergebnis von Microsofts Portierungsbemühungen war für Dritte in Form von "Microsoft Visual C++ Cross-Development Edition für Macintosh" verfügbar. So könnte jeder seine Win32-App mit dieser Abstraktionsschicht auf den Mac portieren.

Zitat aus meiner guten alten MSDN Oktober 1996 CD:

„Microsoft Visual C++ Version 4.0 Cross-Development Edition für Macintosh erleichtert die Übertragung von Programmen für die Microsoft Windows-Betriebssystemumgebung auf den Apple 680x0 Macintosh oder Power Macintosh-Umgebung. Entwickelt, um eine vollständige Programmentwicklungsumgebung bereitzustellen, unterstützt Visual C++ für Macintosh C, die Standard-C-Laufzeitbibliothek, C++, den größten Teil der Microsoft Win32-API einschließlich OLE und ODBC sowie die Microsoft Foundation Class Library. "

So enthielt es sogar MFC. Meine Vermutung ist, dass "#ifdef _MAC" ein Artefakt der MSVC++ Cross-Development Edition für Macintosh (R.I.P.) ist.