> GNOME actually works decently on it
On a Surface Go? Touchscreen and all?
Is it usable without a keyboard and mouse? And if so, fully usable?
I have other questions but those are the significant ones. I don't know how anyone syncs books from a router -- huh? -- or how a dinghy would help. To me that is a small boat, either a sail powered or a rubber inflatable boat.
This is intriguing to me.
Just last week, we received notification that IBM is rolling out a "program" to upper-level employees with decades of experience. The idea is that we would work reduced hours for the next year at full pay, and then leave IBM after a year (next March, I believe.)
Of course, this is for US employees only. I think we can be sure that the replacements for these employees (if there are any) won't be in the US.
You didn't "cut cable" if you didn't have it in the first place; the number they're citing is a percentage of total households without cable, not the number of total households that had cable and got rid of it.
Agreed.
"AI" is the last thing I want. I have changed my browser settings to _block_ "AI" generated results.
I did not know DDG was run by the same sort of idiotic blind fashion-followers. This is sad news.
It's odd.
I get a strange mix of feedback. Some from people who call me a jerk etc., and if they go into detail, that usually means they did not understand what I wrote. And the rest says "thank you for writing this. So few people understand. We are really glad someone does."
I work hard on _not_ being hostile, confrontational, and rude.
But, to quote Bill Hicks:
'I don't mean to sound bitter, cold, or cruel, but I am, so that's how it comes out.'
Actually, recently that has been proven false.
It was "proven false" by mathematicians who considered the number 200,000 to be the same as "infinite."
The thing is that XMS is only for data. A real mode DOS binary can't put code there: the addresses are out of range. Only the 64kB of the HMA could hold executable code: 1024-1088kB.
XMS allows a DOS app running on a 286 or 386 to store blocks of data above 1088kB, but the programmer gets no more space for their executable at all.
While EMS _also_ gave you lots more storage, but was much longer established, and it worked on an 8088/8086 and didn't need a 286.
If you wanted bigger *programs* then they had to run in protected mode. To do that and access DOS services meant using a DOS extender, and that did mean paying, but it allowed you to have (a theoretical max of) 16MB programs on a 286 PC and 4GB programs on a 386 PC.
(Not that anyone had 4GB of RAM in an x86 PC in the 20th century.)
So, the choice was:
* EMS: runs on anything, highly compatible, only gets you more data
* XMS: only runs on >= 80286, less compatible, only gets you more data
* DOS Extender: only runs on >= 80286, less compatible, but you get up to 25x bigger programs and almost all the restrictions of plain old DOS go away.
Not a tough choice.
If you used Watcom C, you got Tenberry DOS/4G (or DOS/16) for free.
The point is that XMS was next to no use to DOS apps.
"Please, help me, I am so thirsty... I have not had any water in 2 days."
"Certainly, sir, welcome to our petrol station. Feel free to drink as much petrol as you want."
Still not convinced you're not using an LLM bot to come up with this.
Things like:
> I made a mistake in my previous comment. Contrary to what I wrote, DOS programs running under Windows on a 8086 or 80286 cannot use DPMI
Are _exactly_ the sort of thing I expect from ChatGPT or similar when told it's wrong. I could not write a better pastiche of LLM bot output.
Your claims about Windows are still all over the shop.
Yes, it could pre-empt DOS VMs. No, that does not mean they could be swapped. They couldn't. No, it does not mean they had their own memory spaces. They didn't. Pre-386 versions of Windows had to run all DOS apps in the same memory space, and that was the same space as Windows itself.
No, they could not use any API to give more memory to DOS apps.
No, before Windows 3.0, Windows apps could not be kept in XMS or run in XMS.
There is a good history here published a few days ago:
https://www.ninakalinina.com/n...
Yes you can run DOS in a VM. That is not the same as V86 mode.
https://en.wikipedia.org/wiki/...
V86 mode was not a hypervisor. Significantly, V86 mode made it easier for an OS to communicate with its DOS apps. They all shared the samefilesystem, for instance. That's harder with a hypervisor.
Now, this matters less because software can just emulate a whole DOS PC, like DOSbox does. You don't need clever bypasses when you can emulate the entire hardware and software and just do whatever you can program.
> I made a mistake in my previous comment. Contrary to what I wrote, DOS programs running under Windows on a 8086 or 80286 cannot use DPMI. DPMI is available only to the Windows kernel itself in Windows 3.x Standard mode. Sorry for that, my memory is getting fuzzy. But XMS is still available, so the point stands.
This sounds like the output of an LLM bot.
As such, I think I'm trying to argue with a machine acting as a spammer.
> There is yet another thing I can't remember clearly (but can learn again by some testing). I'm not sure that the total memory footprint of all loaded DOS apps under real or standard mode Windows 3.x can't be more than 640Kb. It could be true, or not. Windows real/standard mode can swap out the memory belonging to an inactive DOS app to a disk file and restore it on task switch, as far as I can recall.
What is the point of this?
Only Windows 2/386 or 3.x in 386 Enhanced mode has multiple virtual DOS boxes, can swap, etc.
> There is a hacked "NTVDM" for 64-bit Windows, called NTVDMx64. AFAIK, it can run DOS apps under 64-bit Windows using one of two methods - a limited CPU emulator from Insignia that was used in the old non-Intel versions of Windows NT, or using HAXM, which to my limited understanding means using the Intel virtualization extensions to achieve the same result as the V86 mode.
I have written about this:
https://www.theregister.com/20...
For anyone else reading, I think @vbdasc is a software bot, and this looks exactly like "AI" bot slop: a jumbled mess of inconsistent fragments ofthe bot's input data.
Not really, no, to any of this.
> Windows 3.1 on a 80286 allowed DOS programs to use XMS and DPMI, which allowed them vastly more memory than 640Kb.
Few DOS apps supported XMS, and indeed, back in the era when DOS was current, not many supported DPMI either... but in the era when Windows 3.x was starting to take over, DOS Extenders started to become more common.
https://en.wikipedia.org/wiki/...
Quite a few games used DOS extenders, such as Phar Lap:
https://en.wikipedia.org/wiki/...
But that does not help ordinary DOS software, the vast majority of which was limited to what would fit into the base 640kB,
So, no, I do not accept your point.
1. Apps had to be specially developed to use this.
2. Those apps wouldn't run on machines that didn't support the tech.
3. There was a per-copy cost for the extenders, so the app vendors had to accept that cost.
4. Different DOS extenders were incompatible with different DOS memory managers. So, for instance, one of the biggest non-game apps, Lotus 1-2-3 R3, used a DOS extender that turned out to be incompatible with HIMEM.SYS and thus Windows 3.x. DOS predated most PCs having internet connections. Before mass use of the Internet, distributing updates was nearly impossible and very *very* expensive.
As a result, it was generally preferable to go without DOS extenders unless absolutely required. You saved money _and_ got wider compatibility.
So, no.
Much the same applies to EMS, except that it was even more limited because everything had to go through the page frame. Also see things like 16MB DMA limits, double-buffering, etc.
> Virtualization extensions from AMD and Intel bring back the V86 mode
No, they do not.
> or something very similar.
Only conceptually similar but incompatible and zero use for running DOS apps under a 64-bit OS.
> AmigaOS was a 32bit OS, and could run a multitasking gui in 0.5mb of ram.
I'd call the classic Amiga and AmigaOS a 16-bit OS myself. Fully 32-bit 680x0 chips did not arrive until later (the 68020) and memory management hardware until later still (68030) -- and AmigaOS cannot use any of those extra features.
[Disclaimer: I own an A1200 with a 68030 accelerator in it, but I am no Amiga expert.]
> There is nothing inherent in a 32bit os that makes it require 4mb of ram
Very true.
But other x86 OSes were as small and multitasked. Concurrent DOS could multitask on an 8086 in 640kB of RAM. QNX could too and was smaller. MWC Coherent was tiny and offered small-memory-model Unix-like multitasking in different variants for 8086, 80286 (Coherent 3) and 80386 in Coherent 4, which is now FOSS:
https://github.com/gspu/Cohere...
[Article author here]
> Windows 3.1 had preemptive multitasking too, for DOS programs. In fact, its predecessor Windows/386 2.01 had it too in 1987.
And 3.0, and Windows 2 on all platforms, 8086 and 80286 and 80386.
The thing is that on 8086 and 80286, all your DOS apps had to fit into the same shared 640kB -- which meant it wasn't much use.
> As for backward compatibility, current OS/2 still can run DOS and Win16 applications, with excellent compatibility. Current Windows can't do that.
A very good point.
Of course this is because OS/2 and eComStation and ArcaOS are all 32-bit OSes for x86-32. Sadly x86-64 does not include Virtual86 mode any more, so they can't easily run DOS and DOS apps without emulation.
Intel PAE is a kludge, but I do suspect that a version of ArcaOS with PAE support would do most of what I need from a desktop OS. Sadly I do not think it will ever happen.
> Unmentioned in the article is how OS/2 was IBM,
I wrote the article.
I did not mention this because it was not true.
OS/2 was not an IBM product. It was _both_ an IBM _and_ a Microsoft product. Both wrote it, both marketed it.
Allegedly, in v1.x, MS did most of the work and IBM paid. But I can't prove that. If anyone can, let me know.
"Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977
