“#ifdef _MAC”是什么?在 Windows 头文件中?

发布于 2024-08-23 16:43:43 字数 501 浏览 14 评论 0原文

我正在浏览 Windows 的 Platform SDK 头文件(真是太棒了,对吧?),我注意到很多地方都包含对预处理器符号 _MAC 的引用。例如:

// 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;

这是否意味着“Macintosh”,正如它所显示的那样?曾经有一段时间可以为 Macintosh 编译 Windows 或 Windows 的子集吗?

I was browsing through Windows's Platform SDK header files (what a life, right?), and I noticed many places contained references to the preprocessor symbol _MAC. For example:

// 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;

Does this mean "Macintosh", as it appears? Was there a time where Windows or a subset of Windows could be compiled for the Macintosh?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

墨落画卷 2024-08-30 16:43:43

微软曾一度是世界上最大的麦金塔软件开发商。 Excel 和 Word 在 Macintosh 上占据了各自的市场,后来 Office 也占据了主导地位。因此,MS 的应用程序部门想要在 MAC 上运行的 Windows 头文件的子集也就不足为奇了,以使他们的跨平台软件更易于维护。

但从来没有任何版本的 Windows 操作系统可以在 Macintosh 上运行。

无论如何,这个片段来自 objidl.h,似乎表明 _MAC 确实意味着头文件中的 Macintosh...

//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

At one time Microsoft was the largest developer of Macintosh software in the world. Excel and Word dominated their respective markets on the Macintosh, and later so did Office. So it's not that surprising that the applications division at MS would want a subset of the Windows header files that worked on the MAC - to make their cross platform software easier to maintain.

But there was never any version of the Windows OS that ran on the Macintosh.

In any case, this fragment is from objidl.h, seems to indicate that _MAC does indeed mean Macintosh in the header files though...

//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
微凉 2024-08-30 16:43:43

正如其他人所指出的,微软应用程序被移植到 Mac 上,他们可能发现将底层 API/框架转变为可移植的抽象层更容易,而不是重写应用程序本身......正如据报道 QuickTime 团队在移植时所做的那样相反的方向(从 Mac 到 Windows——Mac 的 Carbon 标头中有类似的 #if WIN32 条件)。例如,与其在整个 Win32 应用程序的代码库中查找 CreateFile() 并用 #ifdefs 替换或条件化每个引用,不如创建一个 Mac 版本的 CreateFile() 并完成它。对每个 Win32 API 调用重复此操作。

令人惊讶的历史琐事是这样的:微软移植工作的最终结果以“Microsoft Visual C++ Cross-Development Edition for Macintosh”的形式提供给第三方。因此任何人都可以使用这个抽象层将他们的 Win32 应用程序移植到 Mac。

引自我值得信赖的 MSDN 1996 年 10 月 CD:

“Microsoft Visual C++ 4.0 Macintosh 交叉开发版有助于将 Microsoft Windows 操作环境的程序转移到 Apple 680x0 Macintosh 或 Power Macintosh 环境。旨在提供完整的程序开发环境、Visual C++ for Macintosh 支持 C、标准 C 运行时库、C++、大多数 Microsoft Win32 API(包括 OLE 和 ODBC)以及 Microsoft 基础类库。”

所以它甚至包括了MFC。我的猜测是任何“#ifdef _MAC”都是 MSVC++ Macintosh 交叉开发版本 (RIP) 的产物。

As others have noted, Microsoft apps were ported to the Mac, and they probably found it easier to turn the underlying APIs/frameworks into a portable abstraction layer, rather than rewrite the apps themselves... just as the QuickTime team reportedly did when porting in the opposite direction (from Mac to Windows -- there are similar #if WIN32 conditionals in the Mac's Carbon headers). E.g., rather than riffle though your entire Win32 app's code base looking for CreateFile() and replacing or conditionalizing each reference with #ifdefs, just create a Mac version of CreateFile() and be done with it. Repeat for each Win32 API call.

The surprising bit of historical trivia is this: the end result of Microsoft's porting effort was available to third parties in the form of "Microsoft Visual C++ Cross-Development Edition for Macintosh". So anyone could take their Win32 app and port it to Mac using this abstraction layer.

Quote from my trusty MSDN October 1996 CD:

"Microsoft Visual C++ version 4.0 Cross-Development Edition for Macintosh facilitates the transfer of programs for the Microsoft Windows operating environment to the Apple 680x0 Macintosh or Power Macintosh environment. Designed to provide a complete program development environment, Visual C++ for Macintosh supports C, the standard C run-time library, C++, most of the Microsoft Win32 API including OLE and ODBC, and the Microsoft Foundation Class Library."

So it even included MFC. My guess is that any "#ifdef _MAC" is an artifact of the MSVC++ Cross-Development Edition for Macintosh (R.I.P.).

我认为它用于为 MacOS 编译 Microsoft 软件(Office、IE、Windows Media Player)。我知道 Solaris 的 IE 和 WMP 包含 Windows 本身的一个子集(例如 libwinnt.so、libkernel32.so),作为相应 Windows DLL 的直接替代。

I assume it is/was used for compiling Microsoft software (Office, IE, Windows Media Player) for MacOS. I know that IE and WMP for Solaris included a subset of Windows itself (e.g. libwinnt.so, libkernel32.so) as a direct replacement for the corresponding Windows DLLs.

寒冷纷飞旳雪 2024-08-30 16:43:43

许多 MS 代码在为 Mac 开发时都引用了 MAC - 例如 Office。可能这部分头文件来自那些团队。

Lots of MS code has references to MAC as they develop for mac as well - for example office. Probably this bit of the header file came from those teams.

十秒萌定你 2024-08-30 16:43:43

正如您在 Windows.h 头文件中看到的,宏 _MAC 定义如下:

#if defined(_68K_) || defined(_MPPC_)
#define _MAC
#endif
#endif

所以,是的,它仅针对旧的 macOS 环境定义(在开始使用 intel 处理器之前)

As you can see in Windows.h header file, macro _MAC is defined as follows:

#if defined(_68K_) || defined(_MPPC_)
#define _MAC
#endif
#endif

So, yes, it is defined only for old macOS environment (before it started to use intel processors)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文