Static libs for QT (windows)?

When running my app in debug mode TurboActivate crashes on pretty much every API call (IsActivated(), Disable(), etc...). In release mode everything works A-OK so I figured taking the debug static libs for a ride would help.

This shouldn't happen. Is TurboActivate.dll in the same folder as your debug executable? Are you using the correct build of TurboActivate (e.g. x64 or x86). Also, do you have a stack trace?

The .lib's compiled in visual studio aren't compatible with mingw

We've been considering making static libs for GNU compilers. But you're right, it's not a top priority. There are some other features we want to push out first.

First: big thanks for burning weekend cycles checking the forums 🙂

Oh yeah, no issues with misplaced DLL's or using the wrong platform.

I actually called Deactivate() in release mode to see if having no license would fix the issue...and it did. So I went through and re-activated my licence and immediately after the TurboActivate finished I call IsActivated() - which crashed with this bt (TurboActive is down in Thread 1)

Thread 8 (Thread 4164.0xdf8):#0 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#2 0x778b3352 in ntdll!RtlCreateTagHeap () from C:\Windows\system32\ntdll.dllNo symbol table info available.#3 0x00000a08 in ?? ()No symbol table info available.#4 0x1268fedc in ?? ()No symbol table info available.#5 0x7522339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from C:\Windows\syswow64\kernel32.dllNo symbol table info available.#6 0x047494d8 in ?? ()No symbol table info available.#7 0x77899ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#8 0x047494d8 in ?? ()No symbol table info available.#9 0x77899ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#10 0x778b3e45 in ntdll!RtlSidIsHigherLevel () from C:\Windows\system32\ntdll.dllNo symbol table info available.#11 0x047494d8 in ?? ()No symbol table info available.#12 0x00000000 in ?? ()No symbol table info available.

Thread 6 (Thread 4164.0x4ac):#0 0x7787fd71 in ntdll!RtlFindSetBits () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x76b431bb in SleepEx () from C:\Windows\syswow64\KernelBase.dllNo symbol table info available.#2 0x00000000 in ?? ()No symbol table info available.

Thread 5 (Thread 4164.0x12fc):#0 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#2 0x778b3352 in ntdll!RtlCreateTagHeap () from C:\Windows\system32\ntdll.dllNo symbol table info available.#3 0x000001b4 in ?? () at ../../../../QtSDK/Desktop/Qt/4.8.0/mingw/include/QtCore/qvector.h:514No symbol table info available.#4 0x1228fedc in ?? ()No symbol table info available.#5 0x7522339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from C:\Windows\syswow64\kernel32.dllNo symbol table info available.#6 0x047494d8 in ?? ()No symbol table info available.#7 0x77899ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#8 0x047494d8 in ?? ()No symbol table info available.#9 0x77899ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#10 0x778b3e45 in ntdll!RtlSidIsHigherLevel () from C:\Windows\system32\ntdll.dllNo symbol table info available.#11 0x047494d8 in ?? ()No symbol table info available.#12 0x00000000 in ?? ()No symbol table info available.

Thread 4 (Thread 4164.0x1308):#0 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x77881f26 in ntdll!LdrQueryProcessModuleInformation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#2 0x778b3352 in ntdll!RtlCreateTagHeap () from C:\Windows\system32\ntdll.dllNo symbol table info available.#3 0x00000a08 in ?? ()No symbol table info available.#4 0x1208fedc in ?? ()No symbol table info available.#5 0x7522339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from C:\Windows\syswow64\kernel32.dllNo symbol table info available.#6 0x047494d8 in ?? ()No symbol table info available.#7 0x77899ef2 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#8 0x047494d8 in ?? ()No symbol table info available.#9 0x77899ec5 in ntdll!RtlpNtSetValueKey () from C:\Windows\system32\ntdll.dllNo symbol table info available.#10 0x778b3e45 in ntdll!RtlSidIsHigherLevel () from C:\Windows\system32\ntdll.dllNo symbol table info available.#11 0x047494d8 in ?? ()No symbol table info available.#12 0x00000000 in ?? ()No symbol table info available.

Thread 3 (Thread 4164.0x1460):#0 0x7788013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x7788013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#2 0x778b2f51 in ntdll!RtlWeaklyEnumerateEntryHashTable () from C:\Windows\system32\ntdll.dllNo symbol table info available.#3 0x00000003 in ?? () at ../PhotoMonkee/childwindow.h:36No symbol table info available.#4 0x7522339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from C:\Windows\syswow64\kernel32.dllNo symbol table info available.#5 0x00000000 in ?? ()No symbol table info available.

Thread 2 (Thread 4164.0x12c0):#0 0x7788013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#1 0x7788013d in ntdll!RtlEnableEarlyCriticalSectionEventCreation () from C:\Windows\system32\ntdll.dllNo symbol table info available.#2 0x76b40bdd in WaitForMultipleObjectsEx () from C:\Windows\syswow64\KernelBase.dllNo symbol table info available.#3 0x00000001 in ?? () at ../PhotoMonkee/childwindow.h:36No symbol table info available.#4 0x00000001 in ?? () at ../PhotoMonkee/childwindow.h:36No symbol table info available.#5 0x00000000 in ?? ()No symbol table info available.

Thread 1 (Thread 4164.0xcc8):#0 0x66bfbda5 in ?? () from C:\Users\SGreth\bin\TurboActivate.dllNo symbol table info available.#1 0x66bfcf17 in ?? () from C:\Users\SGreth\bin\TurboActivate.dllNo symbol table info available.#2 0x66bfd699 in ?? () from C:\Users\SGreth\bin\TurboActivate.dllNo symbol table info available.#3 0x66bf52d6 in ?? () from C:\Users\SGreth\bin\TurboActivate.dllNo symbol table info available.#4 0x66c00bf8 in TurboActivate!IsActivated () from C:\Users\SGreth\bin\TurboActivate.dllNo symbol table info available.#5 0xbf18737b in ?? ()No symbol table info available.#6 0x00000000 in ?? ()

The dissassembler says it's bombing here:0x66bfbd91 <+0x0000> cld0x66bfbd92 <+0x0000> add %dl,0x53(%eax)0x66bfbd95 <+0x0000> push %ecx0x66bfbd96 <+0x0000> push %edx0x66bfbd97 <+0x0000> mov $0x564d5868,%eax0x66bfbd9c <+0x0000> mov $0x14,%ecx0x66bfbda1 <+0x0000> mov $0x5658,%dx0x66bfbda5 <+0x0000> in (%dx),%eax0x66bfbda6 <+0x0000> mov %eax,-0x1c(%ebp)0x66bfbda9 <+0x0000> pop %edx0x66bfbdaa <+0x0000> pop %ecx0x66bfbdab <+0x0000> pop %ebx0x66bfbdac <+0x0000> pop %eax0x66bfbdad <+0x0000> jmp 0x66bfbdb60x66bfbdaf <+0x0000> xor %eax,%eax0x66bfbdb1 <+0x0000> inc %eax0x66bfbdb2 <+0x0000> ret0x66bfbdb3 <+0x0000> mov -0x18(%ebp),%esp0x66bfbdb6 <+0x0000> movl $0xfffffffe,-0x4(%ebp)0x66bfbdbd <+0x0000> xor %eax,%eax0x66bfbdbf <+0x0000> cmp -0x1c(%ebp),%eax0x66bfbdc2 <+0x0000> sbb %eax,%eax0x66bfbdc4 <+0x0000> neg %eax Function: TurboActivate!PDetsFromPath

It's crashing at your call to "PDetsFromPath()". How are you handling the error code from that function? Are you throwing an exception?

It's crashing at your call to "PDetsFromPath()". How are you handling the error code from that function? Are you throwing an exception?

I'm not calling PDetsFromPath() though. I can repro this now with : - and yes, mykey is my actually key 🙂

int main(int argc, char *argv[]){ // Check if the user is activated if(IsActivated(L"mykey") != TA_OK) { // At this point I get the same backtrace that I posed before.

}

I'll try calling PDetsFromPath() directly to see what happens there.

This sounds like it might be a bug with Qt. Or more likely, MingW (their C library is notoriously buggy).

Is there any reason you're not using Microsoft's compilers on Windows? They're very high quality and they even have free editions.

Calling PDetsFromPath() directly at the start of the app works just fine. The subsequent call to IsActivated() still goes belly up however. Later tonight I'll cook up a dummy QT app and see if this might be an issue with linking against the visual studio libs...

Oh, I love Visual Studio (I use it daily at my 9-5) but I'm using QT Creator for the GUI layout functionality rather than laying out the controls in code. I think I've got a copy of visual studio 2005 kicking around and I'll see if I can port the project over to that.

Are you using the latest version of QT Creator? If so, I'll give it a try later this week and see if I can reproduce this bug.

Are you using the latest version of QT Creator? If so, I'll give it a try later this week and see if I can reproduce this bug.

Yeah the stock 4.8 download should do the trick. I'm cooking up that dummy project now to see if I can get a repro scenario for you.

I think you can officially file mingW in the "not supported" list 👽

All you need to do to repro is setup a dummy qt gui app (it has a single MainWindow instance). I changed my main.cpp to look like so (with the exception of the GUID):

#include <QtGui/QApplication>#include "mainwindow.h"#include <QtGui>

#include "TurboActivate/TurboActivate.h"

int main(int argc, char *argv[]){ if(IsActivated(L"putyourguidhere") != TA_OK) { qDebug() << "Not Activated"; }

QApplication a(argc, argv); MainWindow w; w.show(); return a.exec();}

Inside of the project file I link to the lib like so:LIBS += $$PWD\TurboActivate\TurboActivate.lib

If you run it in debug mode and step over IsActivated you'll hit the crash. This has got to be an issue with using the Visual Studio lib in mingw.

If you run it in debug mode and step over IsActivated you'll hit the crash. This has got to be an issue with using the Visual Studio lib in mingw.

I think you're right. For some reason MingW is choking on the import library when in debug mode. Try linking directly to the DLL (rather than using the .lib file).

Tried two more methods:1) linking directly to the .dll (no luck there)2) Snagging function pointer directly

HINSTANCE hLib=LoadLibrary(L"TurboActivate.dll");

if(hLib==NULL) { qDebug() << "Unable to load library!" << endl; return false;}

typedef HRESULT (TA_CC *IsActivatedFunc)(STRCTYPE versionGUID);

IsActivated=(IsActivatedFunc)GetProcAddress((HMODULE)hLib, "IsActivated");

if(IsActivated(L"gooowid") != TA_OK) { qDebug() << "Not Activated";}

Still blows up at IsActivated() with the same backtrace. I did this last test in my little dummy barebones app.

Hmmm... the problem with the stack trace is that it's crashing at PDetsFromPath:

....0x66bfbdbf <+0x0000> cmp -0x1c(%ebp),%eax0x66bfbdc2 <+0x0000> sbb %eax,%eax0x66bfbdc4 <+0x0000> neg %eaxFunction: TurboActivate!PDetsFromPath

Obviously you're not calling PDetsFromPath(), so I'm thinking the MingW compiler is screwing something up here.

1. What is the "STRCTYPE" type resolving to in your debug mode? (It should be "LPCWSTR" or "CONST WCHAR *").
2. What type of system are you running on? (Windows 32-bit or 64-bit)?
3. What architecture is the debug executable being compiled to? You can verify this by opening the Windows Task Manager, running your app, pausing before the crash point, and looking at the "Image Name" column. If you see a "* 32" next to the image name, then it's being run as a 32-bit process (and thus should use the x86 version of TurboActivate). Otherwise your app is running as a 64-bit process (and thus should use the x64 version of TurboActivate).

1. What is the "STRCTYPE" type resolving to in your debug mode? (It should be "LPCWSTR" or "CONST WCHAR *").
2. What type of system are you running on? (Windows 32-bit or 64-bit)?
3. What architecture is the debug executable being compiled to? You can verify this by opening the Windows Task Manager, running your app, pausing before the crash point, and looking at the "Image Name" column. If you see a "* 32" next to the image name, then it's being run as a 32-bit process (and thus should use the x86 version of TurboActivate). Otherwise your app is running as a 64-bit process (and thus should use the x64 version of TurboActivate).

1) showing up at const wchar *'s2) I'm running Win7 64 bit3) The process is a 32-bit process and I triple checked that the appropriate TurboActivate.dll is being used.

Strangely enough, when I pass in a junk GUID to IsActivated the function doesn't crash and returns the appropriate error code.

I'll have to look into this. In the meantime I'd recommend using the QT libraries built for MSVC2008 or MSVC2010 (they're options in the Qt SDK online installer).

Unfortunately those libs are for their respective visual studio builds. While using QT Creator as the development environment you have to use the mingw build libs.

I've been meaning to port the project into visual studio anyway (crashdump support, a better memory leak tool, etc) so this will be my catalyst 🙂 I don't want you to burn cycles just supporting mingw if I'm the only one out there using it.

All re-compiled with Visual Studio and life is good again. So, in the event you get another QT'er with issues:

TurboActivate works just fine *without* GDB attached. When GDB is attached it will crash when calling any API that will result in a successful license validation. For whatever reason when a license check failed (again, only using the debugger) no issues were hit.

Glad to be back using Visual Studio...compiles are SO much faster. 🙂

Wyatt - Thanks again for all the help. LimeLM and wyUpdate are an amazing combo and the integration of the two was surprisingly simple using your php example (thanks for that).

TurboActivate works just fine *without* GDB attached. When GDB is attached it will crash when calling any API that will result in a successful license validation. For whatever reason when a license check failed (again, only using the debugger) no issues were hit.

That's odd, GDB works fine with TurboActivate on the Linux and Mac platforms. I'll have to look into this when I get some time (in case anyone else runs into this).

Thanks for taking the time to look into it.

Wyatt - Thanks again for all the help. LimeLM and wyUpdate are an amazing combo and the integration of the two was surprisingly simple using your php example (thanks for that).

Great, if you have any other questions I'll be glad to help.

I am trying to use QT 4.7.4 with mingWProblem is that the app crashes as soon as I call any function: (....myapp.exe exited with code -1073741701)Calling code: try { if(IsActivated(L"MyGUIDxxxxxxxxxxxxxxxxxxxx") != TA_OK) { qDebug() << "Not Activated"; } cout << " so far so good..."; } catch (Exception e) { cout << e.GetDescription() << endl;

}SO does QT with mingW work? is it supported? Please do not say to use MS Studio as my zpp is for Windows, Linux and MAC OSX.So if I must get this to work with mingW.

The other option may be to use Inno Setup but that only works for Windows OSCan NSIS setup work with LimeLM products?Anyone?

SO does QT with mingW work? is it supported?

Yes, it works, but on Windows GDB has a bug where it crashes. This is a bug with GDB on Windows. GDB on Linux and Mac works fine.

Can NSIS setup work with LimeLM products?

Yes. You can integrate TurboActivate in any installer.

great that QT works - I need it, and I do not need GDBbut my app crashescan you post any simple QT example project and/or source code?

ALSOany simple example for NSIS setup?

What version of QT are you using, and on what platform are you using it?

any simple example for NSIS setup?

Sure we can put one together.

Can you please let me know where I can get the example, when you have it?Thank you. 😎

On your API page.

Also, what version of QT are you using, and on what platform are you using it?

I am developing on multiple platforms - Windows, MAC, Linux, etc.All the questions here are relating to QT 4.7.4 and WindowsIn this context my development platform is Windows7 - but all versions of windows are targeted.

Regarding the working exampleYour link to my API page - I cannot locate any examples/If you are referring to the standard download items - I cannot find a single complete working example in the downloaded zip package.

What I would like is a simple "Hello World" example in QT (any 4.7.x)Alternately an NSIS setup example would be nice and may be suitable.

I have downloaded the API kit and have compiled my app - but it crashes, as explained in my previous post.

Apologies, if any examples are there - but I cannot find them.

What I would like is a simple "Hello World" example in QT (any 4.7.x)

We don't have a C++ example beyond the header file and the Using TurboActivate with C, C++, and Objective-C article.

We'll be adding a simple console C app and a QT 4.8.x example for the next "point" release of TurboActivate (3.2.1). We'll also add an NSIS example.

I have downloaded the API kit and have compiled my app - but it crashes, as explained in my previous post.

This is a bug with GDB on Windows. Like I've said before, MingW is very low quality. On Windows you'd be better off using the Microsoft compilers. That being said, we're going to look into this problem and see if we can find a workaround for the GDB bugs.

As explained before, regarding GDB - I am not using GDB or any debugger.The app crashes as soon as I call any function - if I do not make a call, the app works fine.I have not had any problems in 10,000 plus installs and without any crashes. I have no bad experiences with QT ( I guess I am lucky)

I look forward to the console app QT 4.8.x and NSIS.Can you hazard a guess as to expected delivery date?

As for Windows Suite - now there is where I had tons of problems and huge costs.(talking about getting what you pay for... 🙂)I guess ying and yang.

Just to be clearShould I forget about this - for now?OR Will you have something reasonably soon?

Will you have something reasonably soon?

We want to have these examples pushed out by the end of next week.

Regarding your crash:

• Is TurboActivate.dll in the same directory as your executable?
• Is TurboActivate.dat in the same directory as TurboActivate.dll?
• Are you using the correct version of TurboActivate (if you're compiling a 32-bit app use the x86 version of TurboActivate, if you're compiling a 64-bit app use the x64 version of TurboActivate).

regarding the directory with executable and support files yesthat was the first thing I verified - as per instructions and support forum, before posting.but thank you for trying to help and verifying

regarding the availability

anything reasonably soon?ORdo I need to do something else?

apologies - did not see your previous reply 😳 I guess it would take longer than a week to find something else

as always patience can be a good thing

SO does QT with mingW work? is it supported? Please do not say to use MS Studio as my zpp is for Windows, Linux and MAC OSX.So if I must get this to work with mingW.

I just wanted to chime in on this point -

Just because you switch over to the Visual Studio development environment (on windows) doesn't mean that you're abandoning QT. My project is based almost entirely off of QT framework calls and I fully plan to get a linux/mac version someday. That being said, switching compilers on the Windows platform doesn't mean you're throwing in the towel for the other platforms. It just means on Windows you'll be getting a native debugger ( a very good thing ).

My experience over the last couple of weeks since "porting" over to Visual Studio has been a mixed bag. Compile times are much faster but the Intellisense is nowhere near as good as QT Creator. Also, adding new forms to the app is a bit clunky but functional. You never expect a perfect implementation for a cross platform API but QT is about as good as it gets IMO.

Good luck with your project!

hey Rob First thank you for this excellent thread/topic/postI used your example code and your tip for the project fileNothing says it better than a simple exampleThank you again and for your good luck wishes.

You make many good points, and of course a native compiler should be better than a cross platform

That being said, MS wants a lot of money for a compiler and of course there is the upkeepand the addons/libraries/support - everything costsbut enuff of my grumbling

QT is great, free and does work for me

best of luck to you Rob!

BTW "XNA is Not an Acronym".Does LimeLM support Microsoft's XNA?I cannot port my project, but it may be something to consider on a future project.

Does LimeLM support Microsoft's XNA?

Sorry, I just saw this question. No, XNA is a closed system designed by Microsoft. As of February 22nd, 2012 LimeLM & TurboActivate can only run on Windows, Linux, and Mac OS X. We're adding other platforms, but it doesn't include XBox.

XNA NO problem - thanks for the replyhope to hear soon aboout QT 4.x.x ....

If you send me an email, klrkt, I can send you the NSIS example we have finished. Send it to wyatt@wyday.com.

Or you can wait until we release TurboActivate 3.2.1 on Sunday.

I am sick as a dog, so I cannot do anything for a few daysbut is the new QT 4.x.x ready, do you need beta testers?

No, we ran into some troubles with the Qt example. It will be a few days.

No, we ran into some troubles with the Qt example. It will be a few days.

Is it working now. That is; does limelm work with mingw (4.4 | 4.8) and run using the same runtime. (compiled with mingw) And are thereexamples of use, produced?

We're considering this product and are using mingw 4.4 (4.8 in the future) dueto QT. This in an alternative only if this is present and works.

Regarding GDB a link to the bug-tracker would be nice, if the problem still exists.

I'm sorry about posing in an old thread, but it seemed relevant and unresolved.

-- dings

And are there examples of use, produced?

Yes, use the C/C++ console application example. It shows how to use TurboActivate. See: Using TurboActivate with C, C++, and Objective-C.

Is it working now. That is; does limelm work with mingw (4.4 | 4.8) and run using the same runtime.

It's always worked at runtime. I presume it still does. The problem was that MingW's GDB debugger crashed for some odd reason. I don't know if that crashing bug still exists. Test it and see if it does.

We're considering this product and are using mingw 4.4 (4.8 in the future) dueto QT

Use the Microsoft compilers. They produce smaller, faster code. They're stable. They're free. They're actively supported. And QT builds with it out of the box.

MingW is a buggy disaster.

>>And are there examples of use, produced?

>Yes, use the C/C++ console application example. It shows how to use TurboActivate. >See: Using >TurboActivate with C, C++, and Objective-C.

The referenced page seems to refer to static libraries comiled with VS compiler. Also it seems to be a page that has existed as long as this thread, not the "simple console C app and a QT 4.8.x example" referenced previously in this thread.

>>[Is it working now. That is; does limelm work with mingw (4.4 | 4.8) >>and run using the same runtime.

>It's always worked at runtime. I presume it still does. The problem was that MingW's >GDB debugger crashed for some odd reason. I don't know if that crashing bug still >exists. Test it and see if it does.

The use of a debugger is a sidetrack. The important thing is wheter you supply libraries compiledwith mingw so that libstdc++ is the same.As klrkt stated previously in this thread:->####klrkt#####->As explained before, regarding GDB - I am not using GDB or any debugger.->The app crashes as soon as I call any function - if I do not make a call, the app works fine.->####/klrkt#####

>>We're considering this product and are using mingw 4.4 (4.8 in the future) due>>to QT

>Use the Microsoft compilers. They produce smaller, faster code. They're stable. >They're free. They're actively supported. And QT builds with it out of the box.

>MingW is a buggy disaster.

My use-case is C++ compiled with the mingw 4.4 compiler, which is why I am asking. Suggesting changing the development/build environment invalidates the question.

Just like "klrkt" I've had no problems using qt & mingw, and it allows me to build using the same compiler on multiple platforms which is a huge pluss.

->####klrkt####->I have not had any problems in 10,000 plus installs and without any crashes.->I have no bad experiences with QT ( I guess I am lucky)->####klrkt####

The referenced page seems to refer to static libraries comiled with VS compiler. Also it seems to be a page that has existed as long as this thread, not the "simple console C app and a QT 4.8.x example" referenced previously in this thread.

No, the article references both the static and dynamic libraries. The dynamic libraries work with all well-made compilers. The static libraries were made specifically for specific versions of Microsoft compilers.

Use the dynamic libraries.

As far as example app goes, download the TurboActivate.zip (referenced from the linked article) it contains the example code. It's not QT specific, it's C/C++/Objective-C specific. Meaning all platforms, and all well made compilers can compile it.

So, in short, follow the article and example code.