Complier and platform support

[matt335672]

I've started this discussion to bring a few threads together:-

• This comment in Using a library to parse config files #2399
• build fix for older gcc #1722
• our coding style, in particular the section related to for statements

The wish to use a C99 library for TOML support, and also to maintain support for GCC 4.6.3 are to some extent incompatible with each other.

My personal take is that we should be testing on big-endian architectures if possible, but if none are available that shouldn't prevent us adopting a newer coding standard to keep the code fresh and accesible to modern developers. I'm not aware of any relatively cheap development boards running big endian, but I'd be happy to be corrected on that.

Any other thoughts on this topic?

[jsorg71]

Thanks Matt for starting this discussion. Sorry if this situation has caused frustration. There is two topic I want to comment on. I feel that SPARC or big endian systems are getting unfairly blamed here.

Matt, I'm assuming the TOML lib you want to use is here
https://github.com/cktan/tomlc99

GCC 4.6.3 does support C99, it doesn't default C99, you need to specify --std=c99. tomlc99 compiles too as they have --std=c99 in the Makefile. So xrdp can compile fine too with C99 code when using CC="gcc --std=c99" make.
This C99 issue or missing parameter has nothing to do with SPARC. It's just the older version that causes the issue. GCC 4.6.3 on x86 should have the same problem. When I created #1722 I didn't know the for loop variable issue can be resolved with --std=c99. Actually I like my vars at the top anyway even if the latest C std is available...

Now about the big endian testing, why do it? If you for example look at Debian 10 supported architectures, here is the list: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x. These are the supported architectures. In this list, mips and s390 are big endian. It's true there has been more in the past, namely SPARC and PowerPC have been removed. SPARC in now SPARC64(Tier2) and PowerPC is now ppc64el. SPARC64 is still big endian as it's hard coded in the CPU. PowerPC, it's configurable.
So years ago, I bought a cheep ebay SPARC machine to do MINIMAL big endian test. Everything worked fine for years until Debian 8 dropped SPARC support. I can correct this by installing Debian SPARC64 which is a modern distro.
I don't even know how we can not support big endian as Debain will build and release them. Here is the buster xrdp builds.
https://packages.debian.org/buster/xrdp
That is a list of xrdp builds for 10 architectures, including 2 big endian architectures.

BTW I am a RISC fan and I am really excited about RISC-V :)

Hoping to hear from others.

[matt335672]

I'm hoping RISC-V will shake things up a bit too, especially given that xrdp doesn't have big hardware requirements.

Getting access to cheap big-endian hardware looks a bit challenging. There's a MIPS® Creator CI20 bit it's getting on, and it's only got 1GB of RAM which is a challenge to develop with. I've not found anything else so far. The SPARC stuff on ebay now isn't cheap any more and it's getting really old!

[Nexarian]

This is a bit of a tangent, and while I agree that we should at least compile for Debian and it's supported platforms, I'm not 100% sure it makes sense to fully SUPPORT old platforms like SPARC.

Here's my thought: Most organizations when push-comes-to-shove that I've interacted with have the following approaches to remote desktop:

1. They pay for a supported enterprise solution like NoMachine or Parsec.
2. They don't have a solution, and expect developers to fend for themselves.
3. They simply give everyone a desktop and expect you to be in the office all the time.

My belief is that XRDP can reach a situation where it is THE DE-FACTO-BEST remote desktop solution for Linux, but first we have to do the things that will make people want to rabidly use it. The first must-have for this is performance. The developers I've worked with are incredibly sensitive to even the slightest graphical glitches or latency. GFX can fix that. The second must-have is the auth work that Matt is doing, things like NLA that will convince IT departments that XRDP is worth supporting (though asking any IT department to support something that's open source is always a huge lift).

If we can get people to simply assume that XRDP is the default solution to use, then that will attract people who will develop it, it will take oxygen away from paid solutions like NoMachine that were never that great to being with, and spin a virtuous cycle flywheel that will continue to cement its position, or attract developers to improving GRD for Wayland or related projects. Right now, the majority of developers I interact with assume that good remote desktop is either in extremely expensive silos or a dead technology and they don't understand it. We need to change the conversation.

My thought is that spending any time on things like SPARC will not move this needle forward. While I applaud the ideal of supporting as many platforms and legacy standards as we can (that is also part of the open source ethos), the way to attract enough people to work on this project is to invest in things that will make it go viral.

[jsorg71]

I removed the comments about Sparc in "Coding Style" wiki.
Lets move to C99. I myself don't think I'll use variable declaration in for loops. This is more of a coding style decision.
https://en.wikipedia.org/wiki/C99
That "restrict" keyword look interesting mainly for codecs.
I'd like to propose we look at something like rust instead of moving beyond C99.

[matt335672]

I've not looked at rust myself yet, but given a lot of code we've got runs as root, I think that would be a good long-term place to be.

xorgxrdp will need to remain as C, as long as X servers are still supported. Goodness know what will happen in that area.

[jsorg71]

For other platforms

Win32 can probably go. There was a time when xrdp, libxrdp and libcommon worked on Windows. Back in the Calista days.
There is lots of WIN32 code in os_calls.c, threadcalls.c that can go.

BSD I think is still active although we don't specify what CPUs we support.

Solaris, AIX, others I guess can go unless someone want to support them. I think there is only a few defines in os_calls.c for them.

[matt335672]

FreeBSD works pretty well, on x86_64 at least. We've got at least a few people using it. If anything's going to get promoted to tier 1 support from tier 2 in the near future, I think FreeBSD would be it, particularly as it gives us a systemd-free testing capability (i.e. multiple sessions per user).

I've got a soft spot for Solaris, having worked with it quite a bit back around the turn of the millennium, when Sun were making great machines. The Oracle acquisition and subsequent change to Solaris licensing pretty much killed Solaris though. None of the existing Open Solaris derivatives look like they'd benefit from xrdp support, but who knows?

I've never used AIX so I can't comment on it.