Qt’s GUI Thread

If you’re a Qt developer, you surely are aware of the fact that you can only display GUI elements and access them from the main thread. This limitation as far as I know is mostly bound to the limitations of X and it isn’t to exclude that multithreading support for GUIs will be added soon.

This limitation never caused me any trouble, since the signal & slots mechanism is thread-safe and communicating between threads and GUI elements can be achieved through it. However, yesterday I needed to show a messagebox in a method and, in case the code is not executing in the main thread, show a native win32 MessageBox instead of a QMessageBox (of course, only on Windows can I do that, on other platforms when I’m not in the main thread, I won’t show anything).

Anyway, here’s a simple method to establish if we’re running the GUI thread:

bool isGuiThread()
{
    if (QCoreApplication::instance()->thread() == QThread::currentThread())
        return true;
    return false;
}

As you can see this is a pointer comparision, but can we rely on the value returned by currentThread? Yes, we can since the pointer is associated with the thread itself as we can see from the code of the method:

QThread *QThread::currentThread()
{
    QThreadData *data = QThreadData::current();
    Q_ASSERT(data != 0);
    return data->thread;
}

// thread_win.cpp

QThreadData *QThreadData::current()
{
    qt_create_tls();
    QThreadData *threadData = reinterpret_cast(TlsGetValue(qt_current_thread_data_tls_index));
    if (!threadData) {
        QThread *adopted = 0;
        if (QInternal::activateCallbacks(QInternal::AdoptCurrentThread, (void **) &adopted)) {
            Q_ASSERT(adopted);
            threadData = QThreadData::get2(adopted);
            TlsSetValue(qt_current_thread_data_tls_index, threadData);
            adopted->d_func()->running = true;
            adopted->d_func()->finished = false;
            static_cast(adopted)->init();
        } else {
            threadData = new QThreadData;
            // This needs to be called prior to new AdoptedThread() to
            // avoid recursion.
            TlsSetValue(qt_current_thread_data_tls_index, threadData);
            threadData->thread = new QAdoptedThread(threadData);
            threadData->deref();
        }

        if (!QCoreApplicationPrivate::theMainThread) {
            QCoreApplicationPrivate::theMainThread = threadData->thread;
        } else {
            HANDLE realHandle = INVALID_HANDLE_VALUE;
#if !defined(Q_OS_WINCE) || (defined(_WIN32_WCE) && (_WIN32_WCE>=0x600))
            DuplicateHandle(GetCurrentProcess(),
                    GetCurrentThread(),
                    GetCurrentProcess(),
                    &realHandle,
                    0,
                    FALSE,
                    DUPLICATE_SAME_ACCESS);
#else
                        realHandle = (HANDLE)GetCurrentThreadId();
#endif
            qt_watch_adopted_thread(realHandle, threadData->thread);
        }
    }
    return threadData;
}

qt_create_tls just calls once for every thread TlsAlloc and if the data for the current thread hasn’t been set yet, it is set with TlsSetValue. So, we can rely on a pointer comparision.

Server Bug: Reupload

Today I received the following email from my hosting provider:

[…] Security is our highest priority and the last years we have taken dramatic measures to build the most secure hosting environment around.

Unfortunately we have however been affected by the Linux kernel vulnerability (CVE-2009-2692) for a 24 hour period. Due to our architecture this exploit did not compromise personal data and all customer records are safe.

After updating the kernel on our systems we scanned all customer accounts and found that your index was removed. Therefore we kindly ask you to check your webpage and reupload your index page if it is missing.

We sincerely apologize for this incident and will take measures to ensure to prevent such incidents in the future.

The index pages of both rcecafe and ntcore were missing in fact. For precaution I reuploaded both pages completely.

Native Blocks Pre-Alpha

Here’s a presentation of my new tool. I called it Native Blocks. It’s a re-assembler basically. Since a written presentation would take me too much time I prepared a video presentation.

Again, this is a pre-alpha. This tool will soon support other technologies such as java, actionscript and maybe even x86. Right now it only supports .NET (and even .NET support will be hugely improved, like for instance supporting the direct modification of assemblies without having to use Rebel.NET).

The development of this tool depends mainly on the interest of people.

As I can be considered a student from now on, I would like to earn some extra money by writing tools such as this one. I have still my job as consultant, but it’s a very limited partime, because I just became a student.

This tool is in my opinion pretty good, it is not only good for deobfuscation purposes but also patching and assembling on the fly.

If this tool can be sold, then the support of technologies will depend on requests. I think I’ll add Java immediately and after that maybe x86/x64. Again it depends.

Suggestions and comments are welcome.