Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Incompatibility with Actual Window Manager (Read 6658 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Incompatibility with Actual Window Manager

Hi there,

I'm a developer in Actual Tools. Recently, one of our users reported a strange incompatibility with our Actual Window Manager and foobar2000. It seemed that foobar's main window removed a window subclass, which our hooking library set to provide additional functions.

I've made a small research in fb2k's internals, and it seems that one of functions in foo_ui_std.dll checks GWL_WNDPROC in the main window, and resets it to a default value whenever it changes. In foobar2000 version 0.9.6.9, the function address in foo_ui_std.dll is 1009b570. The corresponding C-like code would be as follows:
Code: [Select]
if (m_Wnd && m_WndProcStub && (GetWindowLong(m_Wnd, GWL_WNDPROC) != m_WndProcStub)) {
  SetWindowLong(m_Wnd, GWL_WNDPROC, m_WndProcStub);
}
return 1;
If I NOP calling SetWindowLong out of the code, our subclass is not removed from the main window, and all the fb2k's features seem to work fine.
Could you please consider removing or redesigning this part of your UI library, to make those who use both foobar2000 and our products happy?

Thank you in advance for considering this.
I can provide any additional technical info, if you need it.

Incompatibility with Actual Window Manager

Reply #1
As for redistributing a modified foo_ui_std.dll, I'm quoting the foobar2000 license:
Quote
Only unmodified installers can be redistributed; redistribution of foobar2000 binaries in any other form is not permitted.

As for the lovely window procedure protection code you've found, it's likely there to enforce the following clause in the SDK license:
Quote
It is illegal to use this SDK as a part of foobar2000 components that operate outside of legally documented programming interfaces (APIs), such as using window procedure hooks to modify user interface behaviors. We believe components doing so to be harmful to our userbase by introducing compatibility issues and dependencies on undocumented behaviors of our code that may change at any time without any notice or an update to the SDK which would reflect the change.
Stay sane, exile.

Incompatibility with Actual Window Manager

Reply #2
As for redistributing a modified foo_ui_std.dll, I'm quoting the foobar2000 license:
Quote
Only unmodified installers can be redistributed; redistribution of foobar2000 binaries in any other form is not permitted.


I see.
But my post was not about redistribution, only about making foobar2000 and AWM compatible

As for the lovely window procedure protection code you've found, it's likely there to enforce the following clause in the SDK license:
Quote
It is illegal to use this SDK as a part of foobar2000 components that operate outside of legally documented programming interfaces (APIs), such as using window procedure hooks to modify user interface behaviors. We believe components doing so to be harmful to our userbase by introducing compatibility issues and dependencies on undocumented behaviors of our code that may change at any time without any notice or an update to the SDK which would reflect the change.


This restriction is about fb2k's components.
Why a 3rd party tool cannot use hooking? It has nothing to do with any undocumented features of foobar2000.

Incompatibility with Actual Window Manager

Reply #3
As for redistribution, you offered to provide a modified (bad) and old (even worse) foo_ui_std.dll to your customers.

As for the clause about window procedures, that was to provide a rationale and history for why foobar2000 protects its wndproc.
Before its introduction, there were a lot of crashes and general instability due to the window being subclassed.
As component authors and third party applications wouldn't stop messing with it, even with randomized window class names, the current anti-tamper functionality was introduced with great success.
Stay sane, exile.

Incompatibility with Actual Window Manager

Reply #4
Ok, I got your point.
I'll pass this to our customer.