KDE Plasma Login Manager Won’t Support Systemd-Free Linux or BSD Systems

[T-Aoki]

^ https://en.wikipedia.org/wiki/Unreal_mode

Interesting!
But unfortunately, as far as I know, no compilers available (and not hard to find where they're sold) supported the mode at least in Japan, especially outside Tokyo. More, if I recall correctly, no Japanese computer magazines focused on the feature at the moment .

And segments in "protected mode" should have the same kind of "full address space segment".

 

[LoganGreystone]

Alternatively, as in the example of TDE, I could see a fork in the near future for Plasma. Perhaps one or more of the devs could go the way of Timothy Pearson?

https://github.com/Sonic-DE
I wish it would work, but unfortunately these things often stall. Only Cinnamon seems like a reliable fork because it is backed by Linux Mint.

 

[T-Aoki]

https://github.com/Sonic-DE
I wish it would work, but unfortunately these things often stall. Only Cinnamon seems like a reliable fork because it is backed by Linux Mint.

Note that Mate DE is a fork of Gnome2 and still here.

 

[LoganGreystone]

Yes, for now, but it seems they are having trouble adapting to GTK4. Hopefully they will overcome it.

 

[T-Aoki]

Yes, for now, but it seems they are having trouble adapting to GTK4. Hopefully they will overcome it.

I come to think following Gtk major versions is not a good thing, as Gnome is going to dispose X11.
Forking Gtk3 and maintaining (by someone possible, but unfortunately, not me) it seems to be way to go.
Or fork upcoming Gtk5 to adapt again with X11?
In my humble opinion, dropping X11 is simply silly. Disposing Wayland and reconsidering what should be done and what should not may be far more constructive.

 

[AlfredoLlaquet]

Disposing Wayland

What do you mean? I'm not sure I'm following you.

 

[T-Aoki]

What do you mean? I'm not sure I'm following you.

Exactly what you quote.
At least for me, Wayland broke Japanese inputs, which is working OK on X11 (which needed a decade+ to be stabilized and usable). Modifying this part looks crazy for me. Should be re-designed to use what's working on X11 as-is.

Yes, there would be complaints with X11, maybe on its "thickness" and resource consumptions (if I recall correctly, for example, X11 didn't work fine without FPU). So part of Wayland could be (hopefully) reused for redesign. But if I understand correctly, Wayland requires each apps to have too duplicated things with other apps (like Rust wants to do). It seems way back.

Some X11 lovers wants X11 clients (which wants X11 server to draw anything) to display on remote (from the point of view the X11 client is running) X11 server at the user's location, but it seems that this is one of which Wayland wants to dispose. Would need a plenty of discussions within quite wide range of stake holders (not only IT companies like RedHat/IBM, but end users and developers) which is really correct.

And would be far, far more to be reconsidered.

 

[Zare]

Interesting!
But unfortunately, as far as I know, no compilers available (and not hard to find where they're sold) supported the mode at least in Japan, especially outside Tokyo.

I think historically the mode wasn't known until proliferation of Windows 2 and DOS 5, coming with HIMEM driver for 286 in late 80s.
386 was already a thing.

Also it is merely an extension of real mode as far as segmentation is concerned. The normal 16-bit real mode code just works under it. So the modification to usual C program would be inlined asm to kick into the mode, and some asm functions to repoint or copy segments above to segments below. You don't have to actually change your programs memory model to use extra memory.

So for these two reasons I think no major compiler existed at all...

 

[T-Aoki]

I think historically the mode wasn't known until proliferation of Windows 2 and DOS 5, coming with HIMEM driver for 286 in late 80s.
386 was already a thing.

Also it is merely an extension of real mode as far as segmentation is concerned. The normal 16-bit real mode code just works under it. So the modification to usual C program would be inlined asm to kick into the mode, and some asm functions to repoint or copy segments above to segments below. You don't have to actually change your programs memory model to use extra memory.

So for these two reasons I think no major compiler existed at all...

Annoyingly, pre-32bit era compilers (at least, proprietary ones) had "memory models", usually "S" for single 64kiB segs for each segregs, "M" for multiple 64kiB CS and single per others, "L" allowing all (but SS, maybe) segregs multiple 64kiB. Some had "T" for so-called "com" that shared single 64kiB segment with all segregs (for *.com on DOS) and "L" for multiple 64kiB segs of DS and single for others (and "H" stands for huge, that I cannot recall).

The restriction was reasonable for "real mode only" pre-286 processors that needed to allow porting from i8008, i8080 and i8085 (or any other licensed ones lile Z80) 8bit processors easier and simpler. But not at all good limitation for protected mode introduced at i80286.

If i80286 had vm86 mode and allowing to "context switch" to it, applying the 64kiB limitations just to real mode (before entering protected mode) and vm86, things could be different.

 

[Espionage724]

Interesting!
But unfortunately, as far as I know, no compilers available (and not hard to find where they're sold) supported the mode at least in Japan, especially outside Tokyo. More, if I recall correctly, no Japanese computer magazines focused on the feature at the moment .

And segments in "protected mode" should have the same kind of "full address space segment".

I wonder if it's possible to use Unreal Mode at all today? It'd be interesting to see Unreal Tournament using it

 

[Zare]

Yeah. Because they needed to assist the developer in working around segffset model. So they made few of those 'T-shirt' size presets, of which compact was IMO mostly used, as it was uncommon to have more than 64kb of code.

And yep this thing is 8080 heritage as it was a 64kB CPU. The segment register was a cheap solution. I think worse problem for early PC was DMA from 8080 chipset, that also lost a channel for DRAM refresh. The 8 bit memory bus of PC and XT is able to do over 1 megabyte per second, but there were no device to device transfers, and no standard ISA bus mastering methods.

Btw on 286 and vm86, check here - https://en.wikipedia.org/wiki/LOADALL#Usage , second paragraph. This is very early on, first year of development for 286, and it isn't clear whether this was a 'trick' Intel knew about, but didn't put their money on because it was inoptimal, but was perfected for 386, or it is the OS vendors usage pattern that made Intel realize they need vm86 mode.

 

[Zare]

I wonder if it's possible to use Unreal Mode at all today? It'd be interesting to see Unreal Tournament using it

All of UT games back in the day started with Unreal Mode. It is the initial mode set by BIOS on Pentium and up, all the way to UEFI

 

[Jose]

I am actually shocked they have not jumped on the AI enshitification band wagon yet.

Give them time. I'm sure it's coming.

 

[T-Aoki]

Btw on 286 and vm86, check here - https://en.wikipedia.org/wiki/LOADALL#Usage , second paragraph.

Off topic here, but there were EMS that allowed pre-i286 CPUs to use >1MB of memory in tricky way (bank switching on configured i.e., 64kiB, memory window).

Maybe young persons wouldn't be able to believe, but PC-9801Vm2 (its CPU was V30) I've used before had only 384kiB (not GiB nor TiB, even not MiB!) and I had 2MiB of "Bank Memory" technically alike hardware EMS (used 128kiB memory window) to expand memory to the maximum 640kiB that is supported by pre-i286 PC-9801 series and used remainders as ramdisk. Putting dics there, this ramdisk allowed Japanese inputs "still slow but not fully unusable" speeds, which cannot live without it. The main memory and computational power was too insufficient for satisfactory Japanese inputs.
Japanese edition of the EMS page describes a bit about the "bank memory".

 

[Crivens]

... and then there was overlays, which brought a whole lot of other problems to the party...

 

[Zare]

T-Aoki I actually have an EMS card in my XT, today.

EMS is a kind of pure PC(/XT) thing. With the 286 came XMS.
They're actually a same thing, interfaces provided by DOS drivers to equip possibility of mapping large amounts of RAM to real mode code. They both use windows e.g. 64k segments in conventional memory area to map or copy the stuff from the "backend". In EM case the backend is chip card over the bus, in in XM case the backend is the system memory accessible under protected mode.

The XMS stuff is IBM/Microsoft lead way to remove the chief impediment of 286 to PC adoption which is access the new amounts of RAM from old code.

As these two are just interfaces, they can be backed by anything. With vm86 on 386 it was possible to intercept anything, so EMM386 driver can use the >1MB memory to provide EMS support. There are also drivers that provide XMS backed by EMS.

Messing around EMM386 and HIMEM.SYS (the 286+ XMS driver) was an usual procedure to run any demanding DOS software (games) that had real mode code, which is many 90s games. 32-bit protected mode DOS via DPMI extenders is probably another (off)topic but still a lot of good 90s titles did not use them.

As such, I can run many 286 games requiring 1MB+ RAM on my XT. All these games require is 80186 (286 is 186 with protected mode) instructions, and XMS memory. And a XT with V20 CPU and EMS card can do both.

... and then there was overlays, which brought a whole lot of other problems to the party...

IMO the most complex area of PC programming is graphics. With VGA you can almost arbitrarily set up video memory organization and pixel sequencing. There are some 'custom' e.g. non IBM advertised modes that have unlogical planar organization, which makes working with normal assets or normal drawing procedures really hard, but it allows to use vram latches to perform internal copies.