The article doesn't mention "apt update", only "apt upgrade". It looks like a paragraph on this was meant to be present, but it's not there.
You should also mention the distinction between "apt" and "apt-get". "apt" is a bit more user-friendly for interactive sessions, involving colored text and an animated status bar. These features look good, but they get in the way when the command is scripted or if you're running it from a simple terminal type.
The "apt-get" command pretty much does the same thing as apt, but with simpler user feedback, making it more appropriate for use in scripts and where the user may be using a terminal with minimal capabilities.
The 64K document limit isn't a function of "extended" memory (which is one of several mechanisms for DOS PCs to access more than 640K of RAM, "extended" being one that uses a 286+ processor's protected mode), but of the various memory models used by software running in an x86 processor's "real mode".
In real mode, memory is managed using segments and offsets. A segment is a 64K region of memory. A segment register is a 16-bit value that represents a physical memory location divided by 16. An offset is a 16-bit offset from the start of a segment. And yes, there is lots of overlap between the 64K possible segments. This is also what defines the 1MB conventional address space.
Any memory pointer may be "near", meaning it is a 16-bit offset from one of the CPU's segment registers (code segment and data segment) or it may be "far", meaning it is a 32-bit value containing a segment address and an offset from the start of that segment.
Compilers for DOS and real-mode define memory models that specify what kinds of pointers are used by an application by default (apps could always explicitly declare a pointer to be near or far as well).
The "tiny" model means that all pointers are near and furthermore, the code and data segment registers have same value. So the entire app must fit within 64K of RAM.
The "small" model has all pointers as near, but with different code and date segments. So apps are limited to 64K of code and 64K of data.
The "compact" model has near code pointers but far data pointers. So apps can have up to 64K of code, but can use all available RAM for data.
The "medium" model has far code pointers and near data pointers. So apps can use all available RAM for code, but up to 64K of data.
The "large" model has far code pointers and far data pointers. So apps can use all available RAM for both code and data. But standard libraries (like the C runtime library) will limit any single memory object to 64K.
The "huge" model is like the large model, but the standard libraries include code to allow individual objects to be as large as available RAM, but at a cost of more complicated pointer arithmetic (and therefore lower performance) when accessing objects.
Freemacs was probably written using the large model and is using a single memory buffer object for the document, hence the 64K document size limit. This was the most popular memory model for DOS apps, so I'm not surprised that Freemacs uses it.
See also https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012
Authored Comments
The article doesn't mention "apt update", only "apt upgrade". It looks like a paragraph on this was meant to be present, but it's not there.
You should also mention the distinction between "apt" and "apt-get". "apt" is a bit more user-friendly for interactive sessions, involving colored text and an animated status bar. These features look good, but they get in the way when the command is scripted or if you're running it from a simple terminal type.
The "apt-get" command pretty much does the same thing as apt, but with simpler user feedback, making it more appropriate for use in scripts and where the user may be using a terminal with minimal capabilities.
The 64K document limit isn't a function of "extended" memory (which is one of several mechanisms for DOS PCs to access more than 640K of RAM, "extended" being one that uses a 286+ processor's protected mode), but of the various memory models used by software running in an x86 processor's "real mode".
In real mode, memory is managed using segments and offsets. A segment is a 64K region of memory. A segment register is a 16-bit value that represents a physical memory location divided by 16. An offset is a 16-bit offset from the start of a segment. And yes, there is lots of overlap between the 64K possible segments. This is also what defines the 1MB conventional address space.
Any memory pointer may be "near", meaning it is a 16-bit offset from one of the CPU's segment registers (code segment and data segment) or it may be "far", meaning it is a 32-bit value containing a segment address and an offset from the start of that segment.
Compilers for DOS and real-mode define memory models that specify what kinds of pointers are used by an application by default (apps could always explicitly declare a pointer to be near or far as well).
The "tiny" model means that all pointers are near and furthermore, the code and data segment registers have same value. So the entire app must fit within 64K of RAM.
The "small" model has all pointers as near, but with different code and date segments. So apps are limited to 64K of code and 64K of data.
The "compact" model has near code pointers but far data pointers. So apps can have up to 64K of code, but can use all available RAM for data.
The "medium" model has far code pointers and near data pointers. So apps can use all available RAM for code, but up to 64K of data.
The "large" model has far code pointers and far data pointers. So apps can use all available RAM for both code and data. But standard libraries (like the C runtime library) will limit any single memory object to 64K.
The "huge" model is like the large model, but the standard libraries include code to allow individual objects to be as large as available RAM, but at a cost of more complicated pointer arithmetic (and therefore lower performance) when accessing objects.
Freemacs was probably written using the large model and is using a single memory buffer object for the document, hence the 64K document size limit. This was the most popular memory model for DOS apps, so I'm not surprised that Freemacs uses it.
See also https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012