Bringing rktio (and related libraries) more up to date

I am have doing some work around updating the dynamic libraries used by Racket for Windows. As part of this, I have been learning more about the rktio library. It seems to me that there is a lot of code that is there to support very old versions of Windows and well as older version of Linux (and other Unix systems).

I am wondering if bring things more up to date makes sense. I honestly see no reason to officially support older versions of Windows and target Windows 10/11 (and related server versions) only. As an example, I was able to simplify the console code in rktio quite a bit because newer versions of Windows are better behaved (and don't require workarounds).

But, I think this needs broader discussion and support before going to far. To be clear, this isn't about changing the code base to be completely different, but to use less workarounds and newer APIs where they make sense.

For example, the new PseduoConsole API in Windows might really help bridge the gap on on things like polling on stdin/stdout and bring it closer to how Unix works. Or not, but if there is agreement that Windows 10 is a minimum, then that API can be used.

Nathan

Such a change would not affect me directly because I use Linux exclusively.
But I do get the impression that there are many users who are stuck on older versions of Windows, because they find the new versions offensive or incompatible with their applications.
Your changes could prevent them from continuing to use Racket.

I normally favor supporting old systems, and if I were making the changes, I would probably start out trying to use GetProcAddress — at least, if only a handful of functions are needed. But if that's is too much of a hassle (which could easily be the case), then Windows 10 seems like a reasonable place to draw a line on Windows versions going forward.

Beyond Hendrik's impressions and Matthew's predeliction, there is also the point that we have a fairly large (thousands of downloads per day) user base that is mostly invisible to us here, namely students and teachers who use HtDP. Historically we interacted directly with them more and learned that they often have old computers in rarely refreshed computing labs.

Of course, since they are invisible to us, it is possible they don't exist (well, they probably exist, given the downloads, although their characteristics are unclear) but, all else being equal, it seems wise that we try to avoid breaking racket on old systems.

Isn’t one of the (premises|promises) of Racket to be accessible to middle school and high school students? Who are likely to be stuck with obsolete Windows systems?

1 Like

I'd hate to see support for older platforms removed. I think it is worth some extra complexity to keep racket working on older systems. Of course, I'm not the one actually maintaining the code.

Personally, I still occasionally use racket on a powerpc mac and have a goal of building racket for windows xp(I think this is still possible to do but I have yet to track down an older version of visual studio to try it.)

Thanks for the feedback. I have some responses and instead of reply to each post, I thought it best to just address it in one post.

Firstly. nothing is stopping users on outdated and unsupported versions of Windows from using older versions of Racket and the related tools.

As to middle and high schools, Chromebooks are replacing the computer lab as we know it, so that's a whole different set of challenges. In general, any lab that is running versions of Windows older than version 10 has way more issues than potentially not being able to run Racket 1x in the future. Those labs have the option to move to Linux if they don't want to update hardware.

There are a number of libraries that may not be officially be supported for older versions of Windows. Even if they may work, so we can't do very much in terms of ensuring older versions of Windows will actually run effectively.

There is more than just Windows issues here, but assumptions about old versions of Unix and OS/X as well.

In terms of how the API functions are loaded, it would be the same model (using GetProcAddress) as is currently used. Of course, if fallbacks can be used, that is preferred. I am concerned that the code might get too convoluted in certain cases or that will nullify certain advantages.

In general, if there is significant enough gains in simplifying the library and potential performance benefits, then I think it is very reasonable to say that Windows 10 or newer is required moving forward.

ETA: Also, this would allow the use of the UCRT library, which has some notable benefits (UTF-8 locale support, C11) as well.

This is true, but a racket developer who would like their application to run on deprecated platforms would have to restrict their use of new features that are unsupported on those platforms. In most cases developers wouldn't make these considerations and over time more packages would break on the deprecated platforms.

The racket developers have done an outstanding job ensuring that new releases do not break existing code. This doesn't extend to guaranteeing new code works on older racket releases, however.