Grzyb wrote on 2024-05-28, 03:09:

The above screenshots are from the /286 version, right?

I guess so. It's not the /386 version, at least.

Sorry, I'm not used to think of the /286 version as something special.
- When my father got a copy of Windows first time, Windows 2.03 (retail) was the "normal" Windows. There was no /286 version yet that I know of.

The /386 version, by contrast, was the professional version with the built-in memory manager.

So I've never really thought of the /286 version. 🤷
It's essentially the plain version with HMA support tacked-on. No 286 instructions in the program code etc.

Btw, Windows/386 edition can also run on XTs/ATs by running WIN86, if memory serves.
That will load the 16-Bit Windows kernal (the lone Windows "VM") without the 386 memory manager.

It's nothing special, just good to know. I've noticed, because my father had a copy of Windows/386 v2.03 on tape.
Was a QIC tape, more precisely. Those old QIC streamers connected via SCSI. Backup software was SyTOS, I believe.

Grzyb wrote on 2024-05-28, 03:16:

Anyway, it's all well described there - https://gekk.info/articles/dosapps.html

Thank you! 😁

Grzyb wrote on 2024-05-27, 07:04:

Windows 1.x and 2.x/286 may run a graphical DOS program in a window, but only if it does everything via INT 10h BIOS calls.
And I bet there's very few programs that do graphics via INT 10h - it only allows to write a single pixel, drawing anything larger is sure to be slooow...

Bye the way, do you by any chance know of a good INT 10h graphics demo ?
Something simple and fool proof ? It should work on plain CGA, if possible.

I've found one at https://www.youtube.com/watch?v=HQlczzl2rMM
The tutorial's sample code is in the YT comments and attached below.
(no (c), so I consider it Public Domain/Freeware).

But it seems to be having compatibility issues with emulators.
Not sure why. The sample code seems correct and nicely written to me.

It runs fine in DOSBox VGA machine mode, but not in CGA (blank screen).
It also doesn't work in PCem v17 with "VGA" and "CGA" graphics hardware (blank screen).

Selecting "EGA" or "OAK-67" causes a single dot to be written.
By contrast, ET4000AX (KASAN VGA BIOS) seems to work as should.

Jo22 wrote on 2024-05-29, 00:32:

It runs fine in DOSBox VGA machine mode, but not in CGA (blank screen).

Of course - uses mode 0Dh, needs at least EGA.

And I guess video BIOS emulation in PCem is incomplete.
Really, drawing pixels one-by-one via INT 10h is painfully slow and hardly ever used - no wonder somebody forgot to implement it in the emulator.

Also, it's easy to write your own programs for such experiments.
You don't have to use assembler - 3GL stuff like Turbo/Borland Pascal is good enough, just use the Intr() procedure, not the BGI library.

Grzyb wrote on 2024-05-29, 01:25:

Jo22 wrote on 2024-05-29, 00:32:

It runs fine in DOSBox VGA machine mode, but not in CGA (blank screen).

Of course - uses mode 0Dh, needs at least EGA.

My bad, I didn't notice. Saw the comment about 640x200 hi-res mode and thought it's CGA hi-res.
The yellow colour should have made me suspicious, though. I guess I assumed color selection would be ignored by plain CGA hardware.

Grzyb wrote on 2024-05-29, 01:25:

And I guess video BIOS emulation in PCem is incomplete.
Really, drawing pixels one-by-one via INT 10h is painfully slow and hardly ever used - no wonder somebody forgot to implement it in the emulator.

Or it's the "fault" of the EGA/VGA BIOS writers, maybe, I believe. PCem/86Box normally use real BIOS images for such things.

Grzyb wrote on 2024-05-29, 01:25:

Also, it's easy to write your own programs for such experiments.
You don't have to use assembler - 3GL stuff like Turbo/Borland Pascal is good enough, just use the Intr() procedure, not the BGI library.

Thanks, that's worth a try. Might take a while, though - I'm not used to not to use BGI. 😅

Quick update. Did experiment a little bit with productivity software on Windows 2.03.
To my surprise, Clipper did actually run in such a limited environment.
Both programs are from 1987, by the way.

What didn't work was text output of the compiled executable.
Or so it seems. There was a blinking cursor for a fraction of a second.

Anyway, such an use case might have been useful at one time.

An user might have had the need to keep a terminal connection in background, while compiling a program.
With a smart modem or a null-modem connection, this scenario might have been technically possible.

I don't know about Clipper, but TP/BP allows to choose direct or BIOS text output.
Try something like:

uses Crt;
begin
DirectVideo := True;
WriteLn('I can write directly to the video memory...');
DirectVideo := False;
WriteLn('...but I can also do it via BIOS!');
end.

Quick update. Just stumbled upon an interesting YouTube video about OS/2.

https://www.youtube.com/watch?v=GcqSPG1Duag

It seems to be a '92 "product information" from IBM Germany.
The narrator sounds like it's from the 80s, though.

The narrative voice essentially says that DOS used to be the dominant PC operating system for years, merely being slightly updated by being paired with Windows now.

He goes further that PC performance and storage had been increased thousands of times since release of the original IBM PC, while DOS hasn't really catched up with it.
Then OS/2 hits the scene..

Edit: I hope you guys don't mind that it's not an English video. I can understand if it may hurt your ears.
My language has that effect on foreign ears, I'm afraid. It sounds a bit harsh if not being used to. 😅

It's just that there was a time when OS/2 was very popular in my place here.
It was when OS/2 2.x and Warp 3.0 were around.

Back then, OS/2 was being adopted as a "migration platform".

OS/2 was essentially being used as a graphical multitasker to run existing, commercial DOS and Windows 3.x applications. A bit like DesqView/X, if we will.

The HPFS filesystem and the mature multimedia capabilities were a nice addition, too.

Natively developed OS/2 application existed, too, but were a minority.
Running Windows applications in separate VMs was good enough, it seems.

Windows NT had a separate feature in the PIF settings, I believe.

Anyway, the problem at the time was memory consumption.
Home users didn't see the point investing in memory, so OS/2 was often being run on 4 MB PCs.
Which was equally fun as running Windows 95 on same hardware.

Speaking of Windows 95, the advent of 32-Bit Windows applications caused headaches to OS/2 users.

Win32s 1.25 could be made run on Win-OS/2, but that didn't guarante Windows 95 compatibility.

Win32s was closer to Windows NT in terms of compatibility,
ie. Windows NT 3.1 era applications were often being able to run on Win32s - and on OS/2, thus. So OS/2 had limited Windows NT software compatibility, if we will! 😃

Probably because early Windows NT development tools had created "clean" Win32 applications, complete with rellocation tables.

It made sense if we know that Win32 API originated from Windows NT,
rather Windows 95 (Win NT=Win32, Win95=Win32c, Win31+extension=Win32s) .

Interestingly, in later life, Win32s 1.30 got being updated beyond the Windows NT 3.1 capabilities.

Win32s also got a few changes making it slightly more Windows 95 (Win32c API) compatible.

Thus, some of the newer Windows NT applications did run on Windows 3.1+Win32s and Windows 95, but not on original Windows NT 3.1 anymore.

Grzyb wrote on 2024-05-29, 10:21:

I don't know about Clipper, but TP/BP allows to choose direct or BIOS text output. Try something like: […]
Show full quote

I don't know about Clipper, but TP/BP allows to choose direct or BIOS text output.
Try something like:

uses Crt;
begin
DirectVideo := True;
WriteLn('I can write directly to the video memory...');
DirectVideo := False;
WriteLn('...but I can also do it via BIOS!');
end.

Hi there! I did give your sample program a try! 😁
- Compiling worked in TP 6, but not TP 3.

I guess I'm a little bit out of practice here - or maybe I'm just more used to use TP 6 by now. 😅
I fondly remember using TP 6 to compile by own version of TOP - The Other Packet, an amateur radio program.
I had been adapting it to my CB radio needs in late 90s/early 2000s (source code was available).

Anyway, it worked as expected, I guess. BIOS output only. Drat! 😾
Originally, I wanted to have a COM file here, so I did prefer trying TP 3 at first.
But it doesn't make a big difference, I guess. The EXE is just 3 KB (tiny).

PS: It did fully work on plain MS-DOS, of course. I didn't attach a screenshot for this (picture limit).
It also worked in DOSBox no problem.

Jo22 wrote on 2024-05-31, 06:19:

Anyway, it worked as expected, I guess. BIOS output only. Drat! 😾

Of course - these are the limitations of virtualization in Real mode.

Note that you're running Windows in VGA mode, with video memory at A0000h.
Direct text writes go to B8000h, ie. to nowhere.
With Windows running in CGA mode, however, you would also get garbage on the screen.

Anyway - although severely limited - the feature of running DOS programs in a window without V86 is fascinating.
And I bet vastly unknown even to those who have used PCs since the XT era - I only learned about it recently!
Hardly anybody cared about Windows before the 3.0 - and that was when that feature got removed...

Grzyb wrote on 2024-05-31, 08:26:

Jo22 wrote on 2024-05-31, 06:19:

Anyway, it worked as expected, I guess. BIOS output only. Drat! 😾

Of course - these are the limitations of virtualization in Real mode.

Though programs like DesqView and PC-MOS/386 somehow managed to run Norton Commander in a window or a virtual console.
Norton Commander did direct writes, too, didn't it? 😟

Here's a video I've taken a while ago.
https://www.youtube.com/watch?v=LtHNEUEF2Iw&t=150

It's about PC-MOS/386 on an XT (it can do that, but at cost of advanced memory management).

GW-BASIC and Norton Commander are running on separate consoles.

GW-BASIC uses BIOS output, but NC had compatibility issues in older releases of MOS.
So it must be doing something with the text output.

Grzyb wrote on 2024-05-31, 08:26:

Note that you're running Windows in VGA mode, with video memory at A0000h.
Direct text writes go to B8000h, ie. to nowhere.
With Windows running in CGA mode, however, you would also get garbage on the screen.

That seems logical, yes.

Grzyb wrote on 2024-05-31, 08:26:

Anyway - although severely limited - the feature of running DOS programs in a window without V86 is fascinating.
And I bet vastly unknown even to those who have used PCs since the XT era - I only learned about it recently!

I wished PC GEOS had supported it, too. Especially Geoworks Ensemble 2, since it was a worthy Windows 3.0 rival once.

In the XT era, given the available software, the best someone could probably do was to get an intel inboard/386 or similar 386 accelerator board.
So a common 386 memory manager/multi-tasker could be used.

AT owners could get a special MMU, in theory, to simulate EMS and re-map i/o ports.
This had worked while 80286 was in Real-Mode.

https://m.youtube.com/watch?v=xgMIbo6QoM4

PC-MOS/386 had support for some add-on like this, I vaguely remember.

Though in practice, a 386 upgrade via interposer (MakeIt! Series) or a accelerator card was more practical perhaps.

Grzyb wrote on 2024-05-31, 08:26:

Hardly anybody cared about Windows before the 3.0 - and that was when that feature got removed...

Right. Not at home, at least, were it could have been useful to users with humble PCs.
Windows/386 (or 2.x, respectively) was about the oldest Windows I've found real software for (there were a few early birds for Windows 1 but they're a minority).

In the office back then, Windows /386 probably served as a multi-tasker for DOS applications, with a few special applications being programmed in-house or with some commercial applications.

Windows/386 served as an seemingly cheaper alternative to using OS/2 1.x.
OS/2 was better and also cheaper on the long run, of course, but it did little for existing DOS and Windows applications.

Windows/386 was available very early, also by comparison.
It ran on weak hardware, too. So users who opted for Windows/386 had bought time, at least.

Still, Windows/386 merely had one common VM for all Windows applications.
So Windows applications didn't get their own VMs.

Instead, they had the opportunity to request EMS from Windows/386 memory manager, just like any DOS application could.
This got some large applications like SQL Windows (?) or Page Maker 3 running.

By contrast, what Windows 3.0 Real-Mode did introduce was system-wide EMS support, essentially.
For the first time, Windows itself did use EMS (as a consumer, rather than a producer). And shared it with certain Windows applications, too.

Edited. 2x.

Jo22 wrote on 2024-05-31, 21:55:

Though programs like DesqView and PC-MOS/386 somehow managed to run Norton Commander in a window or a virtual console. Norton C […]
Show full quote

Though programs like DesqView and PC-MOS/386 somehow managed to run Norton Commander in a window or a virtual console.
Norton Commander did direct writes, too, didn't it? 😟

Here's a video I've taken a while ago.
https://www.youtube.com/watch?v=LtHNEUEF2Iw&t=150

It's about PC-MOS/386 on an XT (it can do that, but at cost of advanced memory management).

GW-BASIC and Norton Commander are running on separate consoles.

GW-BASIC uses BIOS output, but NC had compatibility issues in older releases of MOS.
So it must be doing something with the text output.

There's no windows on that video, only full-screen.
Any task swapper can do it, eg. DOS Shell.

Grzyb wrote on 2024-06-01, 02:51:

There's no windows on that video, only full-screen.
Any task swapper can do it, eg. DOS Shell.

No, no it isn't. There's no window, right. I didn't link a video to DESQview here.
Should have been more clear about this. 😅

A video about DESQView can be found here: https://www.youtube.com/watch?v=HRPCGWGSqD4
Sadly, though, it doesn't feature Norton Commander. I hadn't thought about it.
When I recorded it about 6-7 years ago, I was trying out how good it can task-switch VGA programs.
It displays screenshots for windowed/inactive applications, essentially, until they're full-screen again.

The video I had previously linked is PC-MOS/386 with the ADDTASK command.
At the time position I've linked, I'm switching tasks. Or rather, virtual terminals or consoles (like in Linux).
First, I'm running NC on one terminal, then I'm switching to the second terminal (ALT+ TASK ID via num pad) and run GW-BASIC.
NC is still running on a time-sharing basis on the other terminal, it's not being halted.

Physically, the PC is a Siemens Nixdorf M35 with 8088 CPU and CGA+Hercules simultaneously running (2 graphics cards).
Drive A: is a 360K drive with boot disk. Drive B: is a GOTEK emulator with various disk images.

Note that I haven't tried running much applications on a physical serial terminal yet.
PC-MOS/386 can do that, like MP/M can. Or any Unix.

However, I don't know if a simple terminal is good enough here for Norton Commander.
For cursor control (or cursor positioning), ANSI escape sequences are needed, maybe.
Something like VT-52 or Wyse standard might be needed to run Norton Commander, thus.

Without that, the terminal output is like an electronic typewriter, a telex machine.
Programs that use line wise output (BIOS or DOS) might still work.
Something like Zork can surely be run via typewriter.

Anyway, PC-MOS/386 is very interesting. Gratefully, v5 is Open Source now and available to everyone!
Because, for it's time, it was like the DOS-equivalent to Unix. It has so much features.
For example, it explicitly supports modem connections for a distant terminal.
A bit like in the original War Games movie! 😁

That being said, it's still rocking! MOS can be used for developing new DOS software still.
All the classic compilers and IDEs can be run simultaneously, which is useful.

Edit: To span a bridge to the OS/2 topic here, "European" MS-DOS 4 released in mid-80s tried to introduce multi-tasking, too.
However, it required special applications for that purpose. It was more like a proto-version of OS/2 1.0.
This was before the concept of the Family API was being made public, also.
(Family API was about OS/2 programs that also ran on plain DOS through a rudimentary OS/2 runtime they had built-in.)

Edit: Pictures attached. I've taken screenshots in PCem v17 with 486 emulation.
The 386 specific drivers were being loaded for sake of convenience.
With way less memory available it also works on an XT or AT, as seen in that video.

Switching between tasks works via ALT+TASK ID on num pad.
(Say ALT+0 to get master console, ALT+1 for switching to first task/terminal).

Edit: I've mounted the NC 2 floppy image because I was too confused to find my image of NC 1.
I've could have opened the MOS 3 HDD image with WinImage of course, and inject NC files, but..
WinImage has trouble with the filesystem or vice versa. Some files can't be seen by MOS after injecting them.

So I'd have to use a MS-DOS boot disk to make them visible by moving files back and forth (say, by moving everything to C:\TEMP and back).
I've suppose this has to do with how the FAT is being read or updated, not sure. MOS 5 surely has fixed this issue.

Quick update. I've tried Norton Commander 1.02 on DESQView 2.x (PCem/XT 286/VGA).
I can re-size the fullscreen application, so it becomes windowed.
(I can even move around inside the window to choose my viewport.)

What's interesting, though, the cursor in Norton Commander keeps blinking.
Normally, the cursor blink is done in hardware. The Motorola CRTC does it by itself.

Anyway, I don't know how exactly this works here, just find this interesting.
DESQView setup also found Norton Commander, so it's aware of the application.
Maybe there's some code patching happening behind the scene or something.

Jo22 wrote on 2024-06-01, 05:32:

Quick update. I've tried Norton Commander 1.02 on DESQView 2.x (PCem/XT 286/VGA).
I can re-size the fullscreen application, so it becomes windowed.
(I can even move around inside the window to choose my viewport.)

But is the NC still running and updating its screen while windowed?
Or is it frozen?

What's interesting, though, the cursor in Norton Commander keeps blinking.
Normally, the cursor blink is done in hardware. The Motorola CRTC does it by itself.

Of course it's blinking, it's still text mode!

Anyway, I've got an idea how to window a SINGLE direct-video program without V86...

CGA, EGA, and VGA cards provide multiple video pages in text mode.
If the program only uses the first page, the multitasker TUI can freely use the second page - eg. draw a window, and copy data from the first page to the window on the timer interrupt.

I think Hercules doesn't allow for multiple text pages, but it allows for two graphics pages.
The text mode program writes to B0000h, the multitasker GUI can use B8000h...

Yes, very convoluted and failure-prone, but possible.
I doubt if anybody has actually done that...

Grzyb wrote on 2024-06-01, 09:10:

But is the NC still running and updating its screen while windowed?
Or is it frozen?

That's a good question, really.
A lot of people seem to question DESQView's multitasking capabilities in this regards.

On the other hand, though, what about BBS operators that had run multiple copies of their BBS software?

If I remember correctly, they've often told that they had used DESQView or 32-Bit OS/2 to have same BBS software running multiple times (to serve multiple logins).

Before they've switched to Linux or sometimes else, I mean.

Grzyb wrote on 2024-06-01, 09:10:

Of course it's blinking, it's still text mode!

Sure, it's VGA's text-mode, even, perhaps. So custom fonts might be possible, maybe.
(DV Setup auto-detected the graphics system as VGA.)

What I've found interesting though, is that the cursor stayed at the correct spot while blinking.

When I've "zoomed" the NC window, I could move the visible viewport (like a magnifying glass), but the cursor stayed at same position.

So if application was inactive and it was just an image that I saw, a screenshot, then why did the cursor stay active at the correct spot?
That confuses me.

Edit: I find the idea with the Hercules card intriguing. 🙂👍

Grzyb wrote on 2024-05-27, 07:04:

There may be cards that can provide two frame buffers at the same time: A0000..AFFFF (for the system) and B8000..BFFFF (for the DOS program), and that would indeed allow for certain trickery.

I think I've found a card that can do it...
#4 from this thread - Need help with identifying old isa graphics cards.

http://www.seasip.info/VintagePC/mdsi_genius.html
"The first 512 lines live between 0A0000h and 0AFFFFh, the second 496 between 0B8000h and 0C7FFFh"
"the text in the MDA framebuffer (at 0B0000h) can optionally be superimposed on the graphic display"

Quick update. Found something online, I'd like to share it before I forget about it.

Off-topic, but has anyone else reviewed the MT-DOS 4.0 documentation from the “Ozzie drop”? It’s very clear MT-DOS 4.0 was the p […]
Show full quote

Off-topic, but has anyone else reviewed the MT-DOS 4.0 documentation from the “Ozzie drop”? It’s very clear MT-DOS 4.0 was the predecessor to OS/2 1.0. But in an even more bizarre fashion, MT-DOS 4.0 seems to have the memory management infrastructure from Windows 1.0 ported over but ready to use as a general purpose operating system.

It makes the origins of the 1.x DOS Compatibility Box a little more obvious, if you view OS/2 1.0 as basically a protected-mode version of MT-DOS 4.0, much how Windows 3.0 was a protected-mode version of Windows, so programs didn’t need to bother with the real-mode Windows memory management anymore.

The obvious open question is how Microsoft internally let MT-DOS 4.0, Windows, and OS/2 1.x get fractured. There was clearly a plan to keep them unified.

Overall, the MT-DOS 4.0 plan seemed to be:

– Provide an API so that a properly written program could run on plain DOS 3.x or MT-DOS 4.0 with either a very simple recompile or the exact same binary. This survived in the “family API” on OS/2 1.x+.

– Encourage developers to use MT-DOS 4.0’s memory management so they could take advantage of more memory in a future, 286-enabled version.

– Maintain full compatibility with 8086 machines. MT-DOS 4.0 runs on an 8086. Given the tight RAM constraints and how slow a typical 8086 was, this was not a worthy goal in retrospect.

– Provide a pathway to a future protected-mode 80286 based operating system which could continue to run the same binaries.

Notably, none of this took the “DOS Extender” approach. OS/2/NT didn’t take the DOS Extender approach either, but Windows 3.x/9x did. In retrospect, the DOS Extender approach worked better since people with plain old DOS but a 286 machine could run programs which needed more RAM without having to bother with a new OS.

Source: https://www.os2museum.com/wp/learn-something- … #comment-383122

Quick update. Has anyone here ever heard of advanced DOSes like Wendin DOS, L3 (w/ L3DOS) or Multiuser DOS 7 GOLD?

Here's the former site of Multiuser DOS 7 GOLD
This is the most obscure multi-tasking DOS I've learned of yet.

Edited.

Well, I heard about Wendin DOS.
And that Multiuser DOS 7 GOLD is just an adaptation of DR/Novell Multiuser DOS - another branch was REAL/32.

Only that L3 thing is totally obscure - looks like it was only in German...

Grzyb wrote on 2024-06-01, 10:45:

I think I've found a card that can do it... #4 from this thread - Need help with identifying old isa graphics cards. […]
Show full quote

Grzyb wrote on 2024-05-27, 07:04:

There may be cards that can provide two frame buffers at the same time: A0000..AFFFF (for the system) and B8000..BFFFF (for the DOS program), and that would indeed allow for certain trickery.

I think I've found a card that can do it...
#4 from this thread - Need help with identifying old isa graphics cards.

http://www.seasip.info/VintagePC/mdsi_genius.html
"The first 512 lines live between 0A0000h and 0AFFFFh, the second 496 between 0B8000h and 0C7FFFh"
"the text in the MDA framebuffer (at 0B0000h) can optionally be superimposed on the graphic display"

Thank you, I didn't know about this one here! 😁

This is first time I've heard of superimposing text on an IBM PC!

It's always a pleasure to learn something new from you, btw. 😎

Grzyb wrote on 2024-06-04, 06:48:

Well, I heard about Wendin DOS.
And that Multiuser DOS 7 GOLD is just an adaptation of DR/Novell Multiuser DOS - another branch was REAL/32.

Sure, but in some ways Caldera DOS is "just" an adaption of DR DOS, too.
The long list of supported interface cards and terminal devices of the "Multiuser DOS 7 GOLD" page is impressive, still. 😁

Grzyb wrote on 2024-06-04, 06:48:

Well, I heard about Wendin DOS.
Only that L3 thing is totally obscure - looks like it was only in German...

Yes, it seems. My father didn't know about it, either. Must have been some highly niche software.
(Speaking under correction for the lack of further information.)

There's a free version called "L3FREI", but not much information is available online.
Some disk images have to be restored with Teledisk (archaic!), others with rawrite (the ones at the linked page).

From what I understand, the DOS emulator is both very sophisticated and very limited.
It can do provide some networking, which is neat - but also kinda mandatory in a multi-tasking/multi-user environment.
Everything physical seems being represented in abstract form, by contrast. XMS/EMS, DPMI etc are missing. It's an XT-like environment, more or less.

Considering its MS-DOS 3.20 compatibility level, my guess is that L3DOS networking is roughly at level of ancient MS-Net, maybe early MS LAN Manager.
On other hand, it can load the real COMMAND.COM from MS-DOS 3.20, which is cool but somehow pointless?

The networking is also being used to avoid the need for implementing floppy drive support.
ASSIGN and APPEND are being used to fool DOS software into thinking that an A:\> drive exists.
- Sorry, I meant A> of course. It's the 80s, after all. 😉

Correction: PC LAN v1.3 and DOS 3.3 compatibility (IBM or MS?). Can load MSCDEX/CD-ROM driver, too.
EMS 3.2 compatibility available (v3.2 can store data only, AFAIK).

L3 User Manual about L3DOS (machine translation)

L3 Reference Manual about L3DOS (machine translation)

Still, I'm fascinated about how many operating systems had provided a DOS emulation.
When I've started tinkering with emulators, they usually ran on DOS - they didn't emulate DOS.

Now, it looks like about any OS had some sort of DOS emulation.
The oldest one I can think of is DOS Plus 1.x, that CP/M-86 in disguise, with its PC-MODE DOS emulator..

Grzyb wrote on 2024-06-04, 06:48:

Only that L3 thing is totally obscure - looks like it was only in German...

Ah, sorry about that by the way. I guess this gets on everyone's nerves at some point. 😅
It's just that my source of information always/often starts in this location (esp. because of old physical floppies and magazines).
I often wished the search engines would show me information in other languages, too, besides English and German.
Say, Italian, Swedish, Spanish, Français or Polski (an old copy of Archie had been found there just recently. See YT video.).