Developer News - 25_CW47 - Quick recap about the DevCon

As already mentioned in the announcement, this year's DevCon unfortunately had to be moved to our Discord server at short notice. For various reasons, it was not possible to hold a face-to-face meeting. However, this had the positive side effect that other members of the development team were able to join the meeting on the World Wide Web for a few hours or days. However, it was quickly agreed to make up for the in-person meeting in the first few months of the new year, as some topics are much easier to discuss in person and working together is quite different from just being connected virtually.

As expected, much of the content turned around DMXControl 3. In addition to various bug fixes, the topic of code styling took up a large part of the time. The goal here is to clean up the source code of DMXControl 3 both visually and technically. As is well known, some parts of the source code of DMXControl 3 have been around since 2008. Not only has a lot of source code been added in the meantime, but coding has also evolved with the further development of C# itself. This, together with easily readable code, ultimately helps with further development and debugging. A major challenge in this area is that, ultimately, a large proportion of the source code files have to be touched during this code styling process. In the context of DMXControl 3, we are talking about over 2,500 files that need to be edited in this process. This is made even more complicated by the fact that software development is not a single development strand. Typically, separate branches, i.e., offshoots from the main branch, are created for the development of new features or the fixing of bugs, and development then takes place in these branches. Once the feature or bug fix is complete, these are merged back into the main branch. If changes are made to the main branch in the meantime, the feature or bug fix branches must also be updated. However, code styling involves a large number of changes, which also take place in the code parts that are affected by the feature or bug fix development. Unfortunately, this creates a great many conflicts, most of which have to be resolved manually. The developers are going to look at which branches really need to be updated and which things were perhaps just an experiment but will never find their way into the software. This should prevent the effort required for manual reconciliation from exploding too much.

The “Protobuf files” package also fits in with the topic of code styling. These define the communication between the various program parts of DMXControl 3. We have now published a repository with this project on our Github account so that programs from other developers can also communicate with DMXControl 3. However, the existing project structure from DMXControl 3 has been adopted 1:1 here. Although this structure was ideal for the DMXControl 3 developers, it was unfortunately not suitable for integration into other projects. Thanks to the restructuring, our public Protobuf interface repository can be integrated much more easily into projects with other programming languages starting with the next DMXC version.

Another area of work was the 64-bit version for the kernel. The challenge here is that not all DLLs of the output plugins for DMXControl 3 are also available in a 64-bit version. Unfortunately, 32-bit DLLs are compatible only with a 32-bit application - as the kernel currently is. Therefore 32-bit DLLs cannot be integrated into a 64-bit application because they simply cannot be loaded there. The development team used DevCon to take the first steps with a handling module that acts (if necessary) as an interface between the kernel in the 64-bit version and the 32-bit DLLs for the output plugin. Ideally, this would mean no change for the user, and DMXControl 3 would continue to support a large number of DMX interfaces in the 64-bit version. This applies in particular to DMX interfaces where we do not have access to the source code of the DLLs. Our Nodle interfaces, as well as Art-Net and sACN, are natively compatible with 64-bit. However, there are only a few 64-bit DLLs for third-party USB interfaces. The extent to which the current attempts are successful will remain to be seen in the near future.

These are, of course, just a few examples of the content covered at the last DevCon. Even though you, as a user, often see little to nothing of these points in the software itself, they are nonetheless important for enabling effective work in the source code. After all, source code is not built to last forever and, like a house, requires regular maintenance and renewal - often due to external influences.

Your DMXControl-Team