Not being enough however, Microsoft took a page out of the old WinOS/2 days and stubbed a Linux kernel to run under Hyper-V, allowing it to run far more applications, and for me giving the ability to use applications that alter memory space, and allowing i386/x32 applications to run. You could happily export your X-11 display to a Windows based X server, and get applications that way. But this isn’t 1993 so it was very limiting.

Enter WSLg

The big change is the ability to use RDP to hook both Wayland and Pulse Audio bringing Linux ‘desktop’ X11 applications to the Windows desktop. Also added in is virtual GPU capabilities allowing accelerated 3D, along with CUDA applications to run (although with a performance penalty.

The downshot for me, is that my existing Debian 10 install was not picking this up, and was somehow picking up a VMware

I have no idea how or why it was picking this up. While I did have the VMware Player installed, the newer versions backend through Hyper-V.

I did find this article, which gave me a path to get where I wanted, although the transition of an existing v2 instance didn’t work for me. Maybe Debian 10 is too weird. I don’t know.

Not sure where how to proceed I backed up my home directory and un-installed VMware Player and purged my existing Debian 10. I installed that Ubuntu Community Preview which promises to include all the new and exciting features.

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Microsoft Corporation (0xffffffff)
    Device: D3D12 (NVIDIA GeForce RTX 2070) (0xffffffff)
    Version: 21.0.3
    Accelerated: yes
    Video memory: 40710MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Microsoft Corporation
OpenGL renderer string: D3D12 (NVIDIA GeForce RTX 2070)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.0.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.1 Mesa 21.0.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Now this is looking MUCH better.

Now compare this to a native version of FuMark:

So it’s a 50% haircut. Ouch.

Gaming however using steam (yes steam runs!) reveals some other deeper issues. The mouse tracking is WAY off. So for FPS stuff you’ll spend a lot of time staring at the ceiling or the floors. The next issue is there is no mouselock, so things that rely on being able to move the mouse far beyond a screen length is impossible to play. To be fair it’s a preview, and so far I have to admit Windows 11 feels more like a technical preview. Also I don’t know what the deal is or anything about profiling it but KOTOR2 is insanely slow. Although at least with 3d acceleration running it’s not 1 frame every 5 seconds.

With all the talk of a possible ‘rocky’ earth like planet making the news, I thought it would be fun to seek out a really ancient (ha!) OpenGL program that did a basic simulation of our solar system.  I am of course talking about ssytem.

Back in the late 90’s I have to admit that this was pretty incredible to look at!  Although it was using OpenGL in software only, and to be honest the best and more stable way to use ssystem was on Windows of all things.

Microsoft had a deal with SGI around the 1993 timeline, and after the release of Windows NT 3.1 they were able to work out a deal to bring Windows NT to the SGI MIPS computers platform in exchange from OpenGL being made available on Windows NT.  SGI couldn’t see a way to monetize NT on their hardware and the port never actually shipped, evidence of it however is present in the leaked Windows NT 4.0 source code.  However OpenGL would prove very import for Microsoft as workstation style graphics could now run on ‘prosumer’ grade OS Windows NT 3.5, and eventually there was even a runtime for Windows 95!

All the old websites, and archives of ssystem have been wiped out, however I did find a copy of the source code for version 1.6 on a HPUX site of all places.

ssystem-1.6-src-11.00.tar.gz

With a filename tracked down, I was able to locate in archvie.org a partial backup of the main site here: http://www1.las.es/~amil/ssystem/english.html

So I thought I could start there.  Ssystem needs the GLUT toolkit and I found a ‘pre-configured’ version 3.7 that Microsoft Visual C++ 6.0 can build on the command line here. Naturally with all the textures, it does rely on the IJG JPEG library (libjpeg) and I used version 6b as ssystem itself dates from 1999.

There was a bit of work to be done with the source code, as I had to massage it to compile with Visual C++, lots of missing headers, and there were some collisions in the lex for parsing the config file, but they were trivial to clean up.  After a bit of going back and forth with a seemingly defective pre-built version of GLUT, re-building it myself got it to link a working executable:

ssystem in orbit around Europa.

Of course, in this day & age, any machine these days has hardware OpenGL acceleration so it is pretty trivial to run this program.

The artifacts in the picture were common at the time, and it’s how I remember it all those years ago so I’m not to worried about it.

I tried to compile with Visual C++ 4.0 however when trying to link I got this error:

Microsoft (R) 32-Bit Incremental Linker Version 3.00.5270
Copyright (C) Microsoft Corp 1992-1995. All rights reserved.

init.obj : error LNK2001: unresolved external symbol _glBindTexture
ssystem.obj : error LNK2001: unresolved external symbol _glBindTexture
stars.obj : error LNK2001: unresolved external symbol _glBindTexture
init.obj : error LNK2001: unresolved external symbol _glGenTextures
astrolib.exe : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: ‘link’ : return code ‘0x19’
Stop.

I’m not sure why, as I re-compiled with Visual C++ 6.0 and I get a working executable.  More bizarre if I try to link the objects that were compiled with Visual C++ 4.0 with Visual C++ 6.0 it also fails in the same way.

I’ve placed in everything I could find into this archive: ssystem-1.6.7z including a pre-compiled version, and the high resolution images.  Along the way I also did find a backup of the site http://www.wam.umd.edu/~kamelkev/Ssystem which actually has a much smaller download of ssystem 1.6 as ssystem-1.6.zip  You may need to play with ssystem.conf to get a more respectable display.  I have also tweeked it to work find on my machine, using the highest values I could get away with, without running over the 2GB per process limit on 32bit processes.

Let’s also not forget the SETI crazy of the 1990’s.