ThreadStart and Thread Stop functions in Labwindows

[gfdsg]

Hello,

I am trying to access a PCI Express Card driver that uses the functions ThreadStart and ThreadStop. When I compile

my code, LabWindows generate a "missing prototype error". I looked at the driver's source code and the following line is 

in the header file:

#if !(defined(WIN32) || defined(WIN16)) || defined(WINCE) || defined(_MT)
DWORD DLLCALLCONV ThreadStart(HANDLE *phThread, HANDLER_FUNC pFunc, void *pData);
void DLLCALLCONV ThreadStop(HANDLE hThread);

#endif

I am using Windows XP professionnal so I suppose i shouldn't have to declare and define theses functions. If I remove

the condition, LabWindows can find the prototypes but the same problem happens for other functions and as I am 

probably going to upgrade the driver, I dont want to comment code inside the driver.

has anybody had the same problem or knows the solution  ? (maybe a compiler option....)

Thanks,

Cyril

[Gist]

Hello Cyril,

It sounds like the compiler is in need of these functions prototypes as they are apparently not already defined elsewhere.  Can you explain your reluctance to remove the preprocessor directive conditions as it relates to upgrading your driver?  Thanks in advance!

[gfdsg]

hello Matt,

Thanks for your response. I tried to add #define _MT to force the declaration and the definition of the functions ThreadStart and ThreadStop but the same problem occurs with another function (_beginthreadex) and this function is not defined inside the driver. I found the work around to replace _beginthreadex with CreateThread but I am not very comfortable about using CreateThread as it is supposed to be used only with Windows CE.  Any ideas why theses functions are not available ? Is there any library I could purchase for Labwindows that would includes theses functions?

Thanks

Cyril 

[dummy_decoy · Accepted solution]

ho boy, i think you are screwed ! _beginthreadex() is part of the C runtime library of Visual C++. its name starts with a "_", which means it is a private extension to the runtime: this is clearly not portable and will never compile with any C runtime other than Visual C++'s one.

now you can either use Visual C++ to compile your code, or ask the original developper to stop using private runtime extensions and stick to standard C and standard system calls. i personnally would opt for the second option.

(anyway, i'd like to say that CreateThread() is not only for Windows CE: it is a standard Windows API call available on any Windows system since Windows 95 (maybe even before). don't be fooled by the Windows SDK documentation which separates documentation for Windows CE and for standard Windows. unfortunately, some rather old SDK documentation shows Windows CE functions first (especially when searching in the index), luring people into thinking those functions are only for CE: every function available on Windows CE is also available for standard WIndows OSes with more options and a deeper documentation.)

[gfdsg]

Thanks for your reply, I am going to use CreateThread for now and ask the manufacturer to be a little more standard C friendly next time he wants to update the driver.

Cheers

Cyril

[menchar]

CreateThread() seems to work just fine from CVI, for both single and multi-threaded applications.

The rap against CreateThread() comes from consequences of the C runtime implementation in Visual Studio.  _beginthreadex calls the Visual Studio C runtime to setup TLS (thread local storage) properly for multiple threads - CreateThread() doesn't when used with the VS runtime.  You also have to worry about the single threaded and multi threaded versions of the runtime in VS (though of late I don't think they distribute the single threaded version any longer).

The CVI runtime does properly set up TLS when CreateThread is called, as far as I can tell - I have implemented multi-threaded code using CreateThread and TLS and it all seems to work.

Beveridge & Weiner ISBN 0-201-22234-5   contains a good discussion of the issue.