New OSes require new CPUs. This isn't really a new thing. But whether or not 32-bit code will become like the dinosaurs is another matter. I personally don't want it to die, there are many advantages to keeping it viable. And I suspect many others feel the same, so my guess is it will still be usable for many years to come. Perhaps the only thing that will kill it is if CPUs no longer support 32-bit code. The two major CPUs on the market today, x86 and ARM, are still supporting the 32-bit code and I don't seen them making any threats to kill it. In fact with the latest 64-bit instructions from ARM almost all instructions can be either 32-bit or 64-bit wide even without switching to 32-bit legacy mode.

That's just it, its only "failure" is its inability to run the latest version of the software. The hardware is still perfectly ok

Meh, I thought Arch was about choice as they advertise. Good to know they're full of bullshit too just like Ubuntu. It makes me cringe everytime I see 64-bit pointers or ints or whatever when you can't even fill 32 of them, just because certain individuals are obsessed with it.

Some of us use a lot of Virtual Machines. I'm so sick of their justifications always being as if OSes are never used in slim VMs.

I want to be able to "print" my own hardware so I can have one good OS forever (because even if the hardware fails due to age, I can print another) instead of relying on others' whim. Really makes me mad right now.

(it doesn't mean I won't use the latest "trend" at all ofc, but I want to have a reliable and trusty one to keep forever, just like I keep my data, it doesn't mean I don't get new data of course...)

I hate to defend the industry and its overzealous deprecation, but in fairness, development is expensive, difficult, and time-consuming. So without volunteers to maintain 32-bit distros, it won't be done. Also, in fairness, the last of the 32-bit only cpus was made (more or less) many years ago, so those machines are dying out: breaking, being disconnected, etc. New hardware is relatively cheap these days (thankfully). There will still be 32-bit app compatibility atop 64-bit OSes (and of course VMs, as you mentioned). I know this is far from perfect and inconvenient in many ways, but they never truly pretended to keep 32-bit alive forever.

Time consuming? Sometimes they port it to completely different architectures who are still less popular! It is beyond retarded to keep say PPC and not x86-32 no matter how you see it, nothing but an excuse.

It's as easy as recompiling with a switch, because if it does indeed work specifically only for x86-64, then the code won't work on PPC either. But it does, thus the code is indeed "portable". A flick of a switch (or command line option) is all that is needed. That's why Gentoo works on almost everything.

As for VMs, you missed the point. VMs need an OS to run. And that's the problem here. You can't use a VM if you don't have an OS, and where will you get the OS from?


So what's the problem? Building the ISO once every 6 months? That's pathetic excuse to be honest. Bandwidth? That's only a problem if a lot of people actually download it, which makes the deprecation retarded anyways.

It just needs to be there as an option for when you need it. BTW yes Volunteers can do it, the problem with Volunteers is that they are not official. People tend to look for official things, as they get popularity/advertisement and trust it better.

DexOS (written with FASM) is 32-bit single-tasking. IIRC, he was loosely inspired by (original) XBox, which was one cpu running a single task and (up to) three threads.

Desqview supposedly had an 8086 version. DOSSHELL supported (286+ ??) task swapping, which wasn't nearly as good. But OS/2 1.x (286+) was multitasking yet had heavy penalty ("penalty box" ??) for real-mode DOS software due to "brain dead" lack of proper mode switching (LOADALL?). I think Win 3.x's "standard" (286) mode was task-switching only (where only Win16/NE apps multitasked?), hence 386 "enhanced" (with newfangled DPMI) was preferred for multitasking DOS stuff. Novell / DR-DOS 7 was similar in regards to task swapping (286+) vs. true multitasking (386+), the latter of which required its own EMM386 + DPMI.



Intel 80376 (embedded) perhaps?? BTW, with computers that have UEFI but no CSM, i.e. no BIOS compatibility, what is the point? I guess it's just simpler to use the same fabs instead of trying to forcibly remove the obsolete functionality from the cpu?



Do literally any support "real" mode?? Besides DOS? I'm not sure how much "support" they could give. Bimodal code? Unlikely. Some old OS/2-friendly compilers used to output "bound" .EXEs, and you can still insert a (useful) DOS stub into a PE MZ these days, but that's not OS-level support either. In short, (386+) V86 mode was hugely popular and heavily utilized by OS/2 2.x, Win9x, WinNT (non-64-bit), DOSEMU (32-bit), etc.

For all intents and purposes, V86 mode is considered "real mode" (compatible). That was the whole point. (I know you know this, just saying.)



We do have (Intel) Nehalem-era "unrestricted guest mode" (circa 2010), aka (newer) VT-X (virtualization). AMD allegedly has "paged real mode".



Except (386+) V86 mode is considered a variation of pmode, allowing you to directly run old DOS programs.



Unlike 32-bit code, you cannot mix 64-bit code with other bitness. So there's no 64-bit DOS extender, no. Yet people genuinely either aren't aware or don't understand that DOS programs can be 32-bit and/or pmode (e.g. Doom, Quake, etc.) using 32-bit registers, accessing well over 1 MB of RAM. Well, even (hardware) EMS or (286+) XMS would let you do that years before (but not as good).

I've not seen any real attempts to provide PAE (36-bit?) memory support to DOS. At one time CWSDPMI planned to support it, but I guess nobody cared. 32-bit Windows hates PAE due to driver bugs, and the address space alone limits available RAM to 3.1 GB. Plus you can't (normally) mix 64-bit objs, libs, plugins, drivers, etc. on a 32-bit system or vice versa. So that makes things difficult and redundant. With Windows 10 requiring a late-model P4, I'm guessing that 32-bit will go away entirely eventually. If it isn't MS who kills it, it will be driver manufacturers or similar.

As far as registers, you could already use (FPU-ish) MMX for 64-bit numbers or SSE2 etc. in plain DOS. Or handroll your own (software-only) routines. I've seen 64-bit number crunching (or bignum) in DOS, too. DOS compilers long ago had the foresight to allow 32-bit numbers, e.g. Turbo C, Turbo Pascal, Oberon-M, etc. Hence the FAT12/16 limit of 2 GB files (which fit in a "signed long"). Obviously DOS just didn't have the infrastructure (or developer interest) to get further file systems, though, beyond FAT32 (which has larger capacity but still limited in individual file size, and even FreeDOS omits the quirky/unpopular 4 GB files and instead only sticks to 2 GB).

So, no, not in the traditional AMD64 sense can you use "64-bit", but in other contexts 64-bit is far from impossible (in DOS). Just use FreeDOS + DJGPP (32-bit DPMI) with -std=c99 ("long long") and a really big RAM drive and/or software cache!

Just thought you should know ....

https://blog.finnix.org/2017/04/18/the-future-of-finnix/

EDIT:


Perhaps OpenRISC? EDIT: Maybe not, RISC-V sounds much better but still not nearly perfect.

Well, at least there's the community initiative for now: http://archlinux32.org/ (idk how long it will last)

I guess I'll have to learn to use Gentoo for my VMs... kinda a pain to compile everything on updates for VMs tho.

CP/M was before my time, so I don't really know anything about it from first-hand experience. Of course, it was still very influential to many others, to say the least.

Apparently Gary was only a part-time contractor, not really full-time working for Intel. Although he was indeed highly educated, skilled, experienced, etc. Besides, CP/M was originally only 8-bit for 8080, a far cry from 16-bit 8086. MS-DOS/PC-DOS v2 was vastly different to CP/M, and it only diverged further from there. DOS was not written in PL/M either.

LGR made a nice video summary about Digital Research.

Gary's kids recently (quasi-)published online (part of) his unpublished/unfinished memoir. Very informative.

Gary was also co-host of The Computer Chronicles for seven years (1983-90). Many of their old videos are also available on YouTube, and they even did a retrospective of him after he died.

EDIT: Oops, you already mentioned The Computer Chronicles (although you link to a different channel with other non-related stuff).

If you're really super interested in CP/M, you'll probably get more help from news://comp.os.cpm (or that one user around here who is unnaturally obsessed with CP/M-86 despite no attempted FASM port).



[ ] is just the documentation's notation (a common idiom). It means optional parameter, so you can omit those options upon use, if desired.

DOS v1 (same as CP/M) didn't have subdirs, so they used '/' for switch char (switchar). When subdirs were added in v2, they then used '\' for path separator.



If you have XP (or older), try SwsVpkt (virtual packet driver). Never tried it myself, but it may allow you to use suitable DOS networking programs (e.g. Links2 although Windows binaries also exist, apparently).

Graphics? Windows? I don't understand either one! But you're presumably better off using/learning SDL and/or something like QB64. (Hmmm, apparently QB64 no longer uses SDL but instead FreeGLUT.) EDIT: Or maybe Allegro would interest you?