Alternative Replacement for mstscax.dll --> rdclientax.dll

Hi,

While the "modern" Microsoft remote desktop clients such as the one used for Azure Remote Desktop receive a lot of updates, they essentially use a lot of the same core as the "classic" remote desktop client (mstsc), but with none of the extensibility offered by the official RDP ActiveX core (mstscax.dll).

rdclientax.dll is an undocumented, non-redistributable file that is part of msrdc. It is not meant for usage by third-parties, and even if we figured out a way to do it, we wouldn't be able to bundle it within Remote Desktop Manager.

The only official way to integrate the Microsoft RDP client stack within a third-party application is with mstscax.dll. Please note that we offer FreeRDP integration on all of our supported platforms, including Windows.

Best regards,

Hi,

Good news - I've been hard at work on this one, and despite the lack of official documentation from Microsoft, we managed to correctly integrate the newer MSRDC engine in RDM. You can give it a try using the RDM 2022.1 beta:

https://forum.devolutions.net/topics/36760/remote-desktop-manager-20221--beta

In order to use MSRDC, it has to be installed on the system (obviously), after which you can modify your RDP entry to use "MSRDC" as the RDP version. This option works with both embedded and external modes.



While there are relatively few visual hints that can tell which one is which, especially with the embedded mode, it really does load rdclientax.dll instead of mstscax.dll. This means you can now use the newer client without having to wait for Windows updates, since MSRDC is shipped out-of-box.

Let me know if this works for you!

Before someone hits the same issue - the current beta build (2022.1.6.0) only checks for MSRDC in the global installation path (%ProgramFiles%\Remote Desktop) but not the local installation path (%LocalAppData%\Apps\Remote Desktop). Make sure to install MSRDC for all users for now, we'll add support for automatically detecting the local installation path in a future build.

Hello Marc-André,

I tried it, works fine, i did not face any problems with the integration.

The only imperfection that still exists (was the same with mstscax.dll) is the per-screen DPI setting, the connection uses the DPI setting of the main-screen (where the connection is made initially) and does not change it when moving the session window to a screen with a different DPI setting.

as far as i see, this is the only disadvantage to msrdc.exe right now.

good work :)

Hi,

I'm glad that it is working for you! This has been quite an adventure, but I'm really excited about the result even if the difference is barely visible to most.

About the DPI issue, both mstsc.exe and msrdc.exe support per-monitor DPI awareness by default, so I wonder if you haven't disabled it explicitly a while ago and forgot about it. Process Monitor can be used to check the DPI awareness of processes (that column needs to be added). I have a mixed DPI system and it does handle the DPI changes. As for embedded sessions, RDM does not yet have full per-monitor DPI awareness support.

The funny thing is that there's no documented way to disable DPI awareness in mstsc.exe, which can be problematic when connecting to older versions of Windows (7, etc) that don't support DPI synchronization at the RDP level. While researching this I found that mstsc.exe accepts a /dpiunaware command-line option that disables it. Otherwise, mstsc.exe and msrdc.exe both use per-monitor DPI awareness.

Hello,

the dpi-awareness works, but it does not work correct when you move the session window to a screen with a different dpi setting.

i show you what i am talking about.. i have a system with 2 screens here - one (main screen) with 150% scale and a secondary screen with 125% scale.

i open 2 connections, one with the msrdcw.exe client for azure virtual desktops (avd) and one with rdm, and i call the same website:

this is the result on the main screen. dpi scaling is the same with both client-engines, the result is absolutely the same quality:


then i move both windows to the secondary screen with 125% scale:

the avd connection keeps it perfect scaling and looks like a native application on the client system, while the rdm connections becomes blurry and does not render correct.


when i change the main screen and re-open the sessions the result is equal on the 125% scale display and different (blurry with rdm) on the 150% display screen.

even the window title "2c-esecure" becomes blurry when moving the window to the second screen.

i could solve it - i have to set per-monitor dpi awareness for RemoteDesktopManagerFree.exe itself:



If the main application is only system dpi aware i face the issue as described above.

is there a simple possibility to set per-monitor dpi awareness for the main application by default?

i see that about 50% of the apps running in this moment on my system are system dpi aware and about 50% are per-monitor dpi aware without showing a system behind. some are this, some are that.

Hi,

It is strange that the parent process has to be per-monitor DPI aware for mstsc.exe / msrdc.exe to correctly handle DPI changes, even if process explorer reports the subprocesses as being per-monitor DPI aware. I'm glad that it works by making RDM itself per-monitor DPI aware - it's not enabled by default because there are a couple of unhandled cases, so mileage may vary. You can change it in File -> Options, under "User Interface":