Win16 Memory Management

The differences were (a) that DOS+Windows was designed so that the same programs could run in both real mode, with overlaying, and 286 protected mode, with segmented virtual memory; and (b) that to really save on RAM DOS+Windows had ideas such as the data segments for DLLs being globally shared across all processes. These added all of the complications mentioned in the headlined article and more besides. It was the operating system, not the processor architecture.

What? It's just like static linking! Only, you know, we do it at load time. At least the filenames of the shared objects to load are included into the executable — we could instead just load and search the whole of /usr/lib in unspecified order, you know!

It's complicated and janky as all get-out, but it made more sense if you were coming from 8080/Z80 development, as this was a scheme to ensure some degree of compatibility with 16-bit 8080 addressing while providing access to much more memory. 8086 was not binary compatible with 8080, but was designed so that 8080 programs could be machine converted to 8086 ones.

In languages like C, this took the form of three different types of pointers: NEAR, FAR, and HUGE. NEAR pointers were 16-bit offsets only, and dereferenced with respect to the current segment (usually in DS). FAR pointers were full segment:offset pairs but pointer arithmetic was only done on the offset which meant objects could be 64K max. HUGE pointers allowed for objects larger than 64k but at a significant performance cost.

Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit addresses (and thus 4GB memory limit).

I think it was a lot more common for 8bit systems to allow for 16 bit addressing though.

It’s been a while though. So hopefully I’m not misremembering things.

Similarly, while locking and unlocking memory blocks is no longer generally a concern, most programs still deal with files, and graphics programs still have to call map/unmap functions to access graphics data. All the same tools apply -- helper functions/libraries, RAII, and leak/sanitizer tools to dynamically detect usage errors.

Game consoles like NES, SNES and Game Boy had additional hardware built in the cartridge to support memory mapping/bank switching.

For PCs, EMS (memory) provided a similar concept. It reserved a 64 kB window divided in 16 kB pages in the first 1 MB and allowed to map up to 32 MB.

For me it is fascinating how today I can learn a foreign language, or how to code by interacting with the LLM.

What all of these languages have in common is that you can write meaningful programs entirely without pointers or manual memory management. In particular, all of these languages handle strings in a natural, high-level way (treating them as a value) and don't require you to allocate and free buffers for them. Perl goes a step further with arrays and hashmaps and employs a full garbage collector.

I have vague memories of trying C for the first time and getting completely lost and bogged down by all the pointers and memory management. My reaction was the same as yours: how does anyone program in this. Why bother with this complexity when you can just use Pascal where you simply don't have to.

Of course, the Pascal compiler was likely written in C or assembly and all the memory management still had to happen even if it was hidden away from me. To some people, this might mean that I “lost” something, but to me, it meant greater freedom as I was able to explore the world of higher-level programming which I found interesting, and not have to bother with the low-level details which I found tedious and even infuriating.

It biased your selection of data structures and algorithms.

Max 64KB array size meant pointers to allocated structs and linked lists were much more popular back then versus 1 large array of structs.

The Win16 HANDLE memory allocation also meant you had to worry about how you handle structs which had pointers to others structs (a FAR ptr may not be a stable value, unless you locked the HANDLE for the duration of the allocation)

Then you had to worry about stuff that no college programming book talked about (ignore the lack of error checking):

  char FAR *p;
  char FAR *mem = farmalloc(65536);

  for (p = &mem[65535]; p >= &mem[0]; p--) {
    dostuff(p);
  }

In fact, I’d argue it was more fun than programming Javascript these days.

All of the below is... IIRC

Win16, even in protected mode, in general didn't unless you opted out of the shared VDM. This was to preserve compatibility with how non-protected mode code worked. That said 32bit code or code that specifically marked itself as protected mode got it's own memory space.

> I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection

NGL... I was shocked when I found out that MacOS before 10... really didn't have much protections at all.

Now in regards to DLLs it all depended on which memory segments were being used, and the respective code on DllMain in regards to the thread/process attachment code and related handles.

Knowing what to search for quickly gave me this article from back in the day,

https://learn.microsoft.com/en-us/archive/msdn-magazine/2000...

A submission to survive most likely needs some initial push from non-organic voting.

It probably helps if you share you submission early with your colleagues and in other sites.