TextureMind Desktop

In just 2 days, I ported the entire common module in TextureMind Framework to MacOS. Now it builds without errors and the common test runs correctly.

The common module contains: Log handler; Array, List, Map, MultiMap; Files handler; Simple math and geometry; Memory handler; Multi-threading; Inter-process communication; Networking; Strings handler; Environment variables; Zip and LZ4 compression; xxHash, GUID and SHA256; Message transport; Objects and serialization; Process handler; The full set of APIs.

I ported also the modules: core, picture, sample, geometry, project, language, shader, engine, graphics, physics, gui, audio and the entire TMD protocol. Now it’s time to implement the system module, which is more complicated because contains functions to handle windows and desktop functionalities, like screen capture, display layout, input injection and audio. I think I’ll be finished in a couple of weeks.

I’m working hard to release the new version 2025.1 of both TMD Viewer and TMD Server. Among the most notable improvements, there will be support for Wayland on Linux and extended support for the older versions of Windows.

About Wayland, I was able to maintain the paradigm that allows TMD to run on any Linux distro with a single build on CentOS 7. From now on, Wayland will be used 100% instead of Xwayland. Wayland will be dynamically detected at runtime and used only if available, even in older versions of Linux, starting from compositor version 4 (which covers up to CentOS 8). If not available, X11 will be used instead. To maintain the highest degree of compatibility, I decided to introduce a cross-platform client-side window decoration system (with a look similar to Windows 10) that will be used everywhere, even on X11 and Windows. The new TMD Server will work under Wayland desktop capturing the screens thanks to the PipeWire+Portal add-on instead of giving a black screen, as in the current 2025.0 version.

TMD Viewer 2025.1 will be compatible with extremely old versions of 32-bit Windows, like Windows Vista or Windows Server 2008, while version 2025.0 is limited to 64-bit Windows 8. To summarize, 2025.1 will run on 32/64 bit Windows Vista, Windows 7 / 8 / 10 / 11, Windows Server 2008 / 2012 / 2016 / 2019 / 2022 / 2025.

To support Wayland, the entire window and event handling stack, along with screen capture and input handling functionality, needs to be rewritten. Compared to Xorg, Wayland has a number of limitations that are part of the new design, such as the inability to position the window, the lack of server-side window decorations on most distributions, the inability to capture screens with native system calls, the inability to capture or inject mouse and keyboard input.

Any missing functionality, where possible, will be replaced with the use of external components, such as PipeWire+Portal. For now, I have already rewritten the entire part relative to window creation, drawing and managing client-side decorations (in place of server-side ones). I also wrote the part about managing pointer and keyboard input, and it’s possible now to change the pointer icon with the system cursor or any image, with animation support as well. Now there is support for Cairo and Vulkan surfaces, with decorations drawn by the graphics context, while the windows can be dragged and resized. Some framework applications are already able to start and function normally, and TMD Viewer works already. The next step is to get the TMD Server up and running, supporting the missing components for screen capture, input handling, and the system clipboard.

One day I woke up with the crazy idea of supporting this opensource operating system which is a clone of Windows XP. So basically running in ReactOS means running on Windows XP and we are in 2025. I absolutely like the idea! Analyzing TextureMind Framework, I discovered that the applications don’t run because of 16 functions in kernel32.dll (and probably there are other functions in other system libraries, like user32.dll, gdi32.dll, ntdll.dll and so on).

Given the architecture of the framework, it is not at all difficult to intercept these functions and try to work around them. I’m already working on a compatibility layer for the core features to make this porting possible. It wouldn’t involve downloading a separate build, but simply downloading the 32-bit version and running it normally, like any other application. TMD viewer will certainly be available soon, while for TMD server I will need to work on a feasibility plan for the missing features.

In the next months, I will focus my efforts in developing the following missing features for TMD:

• Wayland support
• Linux on ARM
• MacOS support

About Wayland, I started to evaluate the code and it’s not difficult, I think a first working prototype can be done in few weeks. For Linux on ARM, I will buy a Raspberry PI 5 for building and testing the software, so at the end of the process, TMD will be able to run on Raspberry PI 5, both client and server. Finally, I will buy a Mini Mac M4 for starting a porting of the entire TextureMind Framework to MacOS. This is an important milestone, because not only TMD but all the framework applications will be able to benefit from it.

After few days of debugging and fixing bugs on Linux, now TMD (version 2025.0.3) can work on a wide range of Linux distros, with support for console user sessions and login/logout screen. It has been tested successfully on Centos 7, Centos 8, Ubuntu 20, Ubuntu 24, OpenSUSE 15 and Amazon Linux 2023.7.2, but it can run anywhere. Only a note: Wayland is not supported yet, so you need to disable it before using TMD. The support for Wayland will be added in the next few months, for now you can continue to use X11 instead.

After months and months of non-stop development, TMD is taking a break. I will continue to promote the product and provide support to users, fixing bugs reported to me. Development of new features will resume in few months. I’ll take this opportunity to continue working on the framework and focus on other topics, such as graphics, 3D applications, modeling, CAD, video games, artificial intelligence, and retrodev.

In the download page, you can find a new version of TMD, for the first time with Linux support. Now TMD is a service also on Linux, so it can run in background all the time and handle console sessions. This is an important release, because now TMD is a complete product with cross-platform support and user sessions.

The list of new features:

TMD Viewer 2025.0.3 (3 September 2025)

Features:

• Linux support
• Improve virtual monitors stability

TMD Server 2025.0.3 (3 September 2025)

Features:

• Create virtual monitors with ADL2
• Linux support with installer script
• Console sessions on Linux

In the download page, you can find a new version of TMD with important patches. The most relevant is the patch for a bug preventing TMD from working on some environments caused by a bad name to SID mapping for the creation of a secure named pipe. There are also other bug fixes and improvements on both client and server:

TMD Viewer 2025.0.2 (31 August 2025)

Features:

• Make it possible to add or remove virtual monitors

Bug fixes:

• Manual trust window is truncated by screen borders with small desktop resolutions
• Primary display is invalid when primary display is deactivated

TMD Server 2025.0.2 (31 August 2025)

Features:

• Create virtual monitors with NvAPI

Bug fixes:

• Wrong detection of correct displays number with multiple adapters
• Impossible to deactivate primary display
• Failing name to SID resolution for ACL creation prevented TMD from working in service mode, black screen
• Random screen block when display layout changes

I finished the implementation of virtual monitors on NVIDIA GRID cards and it works. Now it’s possible to open one or more virtual monitors and set a resolution up to 4K. It worked fine on EC2 g6.xlarge with Windows Server 2025. In TMD, you don’t need a client with more than 1 monitor to handle multiple monitors on the server. You can change display layout from the viewer and connect into one or more monitors. Physical monitors are not deactivated so you don’t get black screen when the client connects to the physical machine. You can eventually deactivate your physical monitors and mount virtual monitors instead, to exclude physical monitors from rendering. In TMD, you can have different graphics cards from different hardware vendors and support virtual monitors created for each adapter. For example, if you have 1 NVIDIA GRID card and 1 Radeon AMD card on the same machine, you can mount 1 virtual monitor for NVDIA and 1 virtual monitor for AMD (but you can do the same with virtual display drivers mounted on Microsoft Basic Display Adapter). The frames captured with NVDIA will be compressed with NvENC and the frames captured with AMD will be compressed with AMF, with 0 CPU copies (however, frames captured by software adapters may be still compressed by hardware adapters, if available). Codecs are negotiated per adapter, so the client will be able to pick the best codec for decoding the frames with the video format supported by the adapter (i.e. AV1, H.264…).

The next version of TMD with these features available will be released in the next weeks.