将CreateThread调用移植到Win8/WinRT App

本文介绍了将CreateThread调用移植到Win8/WinRT App的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我需要从C#Win8/WinRT应用程序中调用C ++库.

I need to call a C++ library from my C# Win8/WinRT app.

该库是多线程的，并通过对Win32 API(WaitForSingleObject等)的调用来管理线程.我能够找出所有这些调用的替代项(始终有一个适用于Apps的...Ex版本，例如，来自<synchapi.h>的WaitForSingleObjectEx，请参见有(如果您正在寻找).

The library is multithreaded and manages threads through calls to the Win32 API (WaitForSingleObject, etc.). I was able to figure out the replacements for all these calls (there is always a ...Ex version available for Apps, e.g. WaitForSingleObjectEx from <synchapi.h> see there if you're looking for it).

但是有一个呼叫我无法弄清楚如何替换:这是对 CreateThread函数.没有等效的功能，因此看起来此类线程创建现在必须通过新的API.

But there is one call I cannot figure out how to replace: it is a call to the CreateThread function. There is no equivalent, so it looks like such thread creation has to go through the new APIs now.

但是我还没有深入研究WinRT上的新线程模型.根据您的经验，移植此线程创建调用的正确方法是什么?唯一的限制是它是我作为"WinApp C ++库"项目构建的C ++库.

But I did not dive into the new threading model on WinRT yet. From your experience, what would be the right way to port this threads creation call? The only constraint is that it is a C++ library that I build as a "C++ Library for WinApp" project.

总结:

在我为其应用程序链接的库中，线程是通过 CreateThread Win32 API调用.我需要将这些调用更改为什么才能使其在我的App环境中正常工作?

In a library I am linking against for my app, threads are created through CreateThread Win32 API call. What do I need to change these calls to so that it works in my App environment?

推荐答案

您是正确的:您将无法简单地用新调用替换CreateThread.您将必须将线程代码移植到新的API.

You are correct: you won't be able to simply replace CreateThread with a new call. You will have to port your threading code to the new APIs.

根据我的经验，链接如果您希望将代码更轻松地移植到WinRT ThreadPool模型，则Raman Sharma的文章是很好的参考.我已经成功地使用在那里找到的填充程序实现了一个Win32线程仿真层，我的较早依赖Win32的代码可以与之交互.

From my experience, the link Raman Sharma's posted is a great reference if you wish to port your code more easily to the WinRT ThreadPool model. I have successfully used the shim found there to implement a Win32 thread emulation layer that my older Win32-dependent code can interact with.