我正在尝试在虚拟化的 Windows XP SP2（使用 VmWare）上安装 SQL Server 2008 R2 和 SQL Server Management Studio。

我已经成功安装了 SQL Server，但由于以下错误，我无法安装 Management Studio：

你能帮忙吗？

我有一个相当大的代码库，我继承了它，我现在有点停留在过去。我在 Windows 7（32 位）中使用 Visual C++ 6，但是，我的目标是 XP 机器（Service Pack 2）。Corporate 没有看到将其升级到 .NET 的投资回报率，而且我的吸引力与 Mini Cooper 牵引火车一样大。

话虽如此，我似乎确实在我的 Win7 机器上成功安装了 VC++6（不兼容 XP），并且可以正常编译和运行。但是，当我尝试将发布版本部署到我的 XP 机器时，它会崩溃（但在 Win7 上不会崩溃）。但是，如果我直接在 XP 机器上构建相同的代码，它就可以正常工作。在我的 Win7 机器上以 XP 兼容模式运行 VC++6 在打开我的工作区时会导致 IDE 崩溃。

我唯一能想到的就是代码大量使用了 ActiveX 控件和注册表。我不确定是否正在进行一些特定于 Win7 的注册表修改，反之亦然。再说一次，我对注册表知之甚少；当我为了快乐而编码时，我在 Unix 环境中工作肯定要舒服得多，尤其是当我用 C/C++ 编码时。

这是我在崩溃时遇到的错误的屏幕截图。我正在想象它与 ActiveX 注册有关。

在 Windows XP SP3 上可以访问 Https 站点（在 IE 设置/注册表中启用 Tls 后），但在 Windows XP SP2 上无法访问（在启用 Tls 设置后）。

我们如何以编程方式查找支持安全连接 (https) 的操作系统版本和服务包。所以我们可以使用替代（http）链接来连接。

在 2015 年的博客文章RichEdit Colors，微软开发人员Murray Sargent指出，RichEdit控件支持“临时”格式；拼写检查器和 IME 编辑器使用：

临时格式

IME 和校对工具喜欢使用诸如波浪下划线和特殊颜色之类的字符格式来指示专门的文本处理，例如拼写错误。为避免更改底层字符格式，RichEdit 提供了下划线类型和颜色以及前景色和背景色的临时格式。删除此类格式后，将再次使用原始格式进行显示。临时格式不保留在文件格式中，也不能被客户端读出，只能应用。

要定义临时格式属性，请调用

• ITextFont::Reset(tomApplyTmp) （用于校对目的），或
• ITextFont::Reset(tomApplyIMETmp) （用于 IME 目的）

然后根据需要通过调用指定临时格式颜色：

• ITextFont::SetForeColor()
• ITextFont::SetBackColor()

通过调用指定临时下划线颜色和类型ITextFont::SetUnderline(value)。

将值指定为value：

• value = tomAutoColor：使用自动颜色（默认文本颜色）。
• value = (color | 0xFF000000): 临时下划线颜色设置为value & 0x00FFFFFF.
• 否则，当 value 是有效的下划线类型时：临时下划线类型设置为 value。

要应用如此定义的临时格式，请调用ITextFont->Reset(tomApplyNow). 如果未定义临时格式属性，则使用相应的原始属性。

强调我的

您如何实际删除“临时”格式？

要将临时格式应用于文本块：

他在2012 年指出RichEdit 多年来一直支持这些东西 - 文本对象模型（即它是在 Window XP SP1 中引入的）：

RichEdit 拼写检查、自动更正和预测

RichEdit 多年来一直支持客户端拼写检查（TOM 对象模型和临时字符格式——请参阅tomApplyTmp）和自动更正（请参阅EM_SETAUTOCORRECTPROC）。但访问拼写检查和自动更正组件是 RichEdit 客户端的责任，内置数学自动更正选项除外。对于像 OneNote 和 Outlook 这样的客户，这样的责任只是应用程序的一小部分。但是对于小程序来说，访问校对组件可能很困难。对于使用Windows RT编写的小型应用程序尤其如此。

我可以弄清楚如何将临时格式应用于文本块：

但我不知道如何清除所有现有的临时格式。

我试图“选择一切，什么都不应用”：

但这只是保留了现有的临时格式。

注： 2015 年 Remy Lebeau( @RemyLebeau ) 指出文本服务对象模型需要 MsftEdit.dll（即 Microsoft Edit v4.1）

奖金喋喋不休

Rich Edit是在 Windows 95 中引入的，最初具有 Windows 类名：

多年来，它得到了改进，但获得了新的类名，位于新的 dll 中，以保持向后兼容性。

Windows XP SP1 引入了新的“Microsoft Edit”类，位于“MsftEdit.dll”中

因此，“Microsoft Edit”是您应该使用的东西（并且需要用于文本服务），而不是“Rich Edit”。

Microsoft Edit使用较新版本的操作系统进行更新：

在 Windows 8 中，Microsoft Edit控件获得了自动支持拼写检查的能力（因为 Windows 8 添加了 SpellCheck API）。

我正在尝试将 MinGW 编译器套件从 32 位迁移到 64。我的应用程序已经在 32 位 MinGW 下运行了好几年。我在 11 月下旬安装了 MinGW-w64。程序版本为 C:\wba\sd>gcc --version gcc (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 8.1.0 C:\wba\sd>ld --version GNU ld (GNU二进制实用程序）2.30

我的程序由一个小型控制台应用程序和一个小型 Windows 应用程序组成，并带有一个它们链接到的大型 dll。这些东西已经在我的 Windows XP Service Pack 3 笔记本电脑上运行了好几年。

由于过去遇到的问题，我使用静态链接到各种系统服务。相关的makefile东西是

但是，如果程序无法访问 libwinpthread-1.dll，则程序现在会失败。当我设置为编译时，它就在路径中。具体来说，它在 C:\Program Files\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin\libwinpthread-1.dll 但它不在客户的计算机上。我也有 C:\Program Files\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\i686-w64-mingw32\lib\libpthread.a 和 C:\Program Files\mingw-w64 \i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\i686-w64-mingw32\lib\libpthread.dll.a 我尝试产生正确的咒语以使这个静态喜欢进入我的程序，但没有成功。我对这一切有点生疏了。任何人都可以帮忙吗？