This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?

In D22957#513827, @nmel wrote:

This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?

Thanks for asking. Because the Q_OS_WIN code blocks are not new ones (previously they were Q_WS_WIN blocks) and having taken into account the aforementioned web pages:

a) Under non-Windows operating systems: The "#ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN" code paths have to work (as they did before this commit), because Q_OS_WIN is not defined there now, nor Q_WS_WIN was defined there previously.

Note: Krusader has the same behavior in the tests that I performed. Also, for example inside

void KRpermHandler::init()
{

there is a

#ifndef Q_WS_WIN

section where anyone can add a

qDebug() << "########################### EXECUTED, IN" << "krperm";

execute "krusader -d" and see the message. Also anyone can replace the

#ifndef Q_WS_WIN

with

#ifndef Q_OS_WIN

and see the message, too.

b) Under Windows operating systems is where the behavior has to change (the Q_OS_WIN code paths are aimed to work, because Q_OS_WIN is defined there).

Some tests were also performed by Moritz Bunkus (https://bugs.kde.org/show_bug.cgi?id=411446#c10) and he didn't see any problem.

I agree with you. Thanks Alex and Nikita! (and Moritz :-)