Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Win16 Memory Management

os2museum.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Win16 Memory Management

#41

Post by icelusxl »

jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

Memory mapping/bank switching was fairly common on 8-bit and 16-bit systems, where a small memory window was used to select different memory banks, allowing a program to access more memory in chunks.

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.

Re: Win16 Memory Management

#42

Post by boutell »

In 1994 I was 2 years out of school. I'd written one windows shareware application and a whole lot of unix-y things. People were excited about the internet but most people didn't have access. Unix shell accounts via dialup were common though.

One day I was encouraged to write a Windows Sockets emulation layer for ordinary dial-up shell accounts like those offered by netcom. The idea was to allow the use of the recently released Mosaic browser without an actual internet connection. I figured sure, no problem. I'll use curl or some other tool in the shell account to do the actual fetching of URLs, transfer styles over zmodem, and simulate all the tcp/ip calls in the DLL.

I couldn't even get started. The reason is that I couldn't understand how the different Windows applications could all share memory allocated at runtime in the winsock.dll.

I asked a highly experienced ex Microsoft person, and he just said what are you talking about. There's no API to allocate shared memory.

So I gave up. 6 months later someone else did it.

Around then I realized the truth: Windows 3.1 had no memory protection at all. Specifically all global variables in DLLs were shared by default. The hard part wasn't sharing memory among users of a DLL. If anything, the hard part was having good discipline to avoid sharing it.

Since I'd only used multiuser Unix in school, and I knew Windows supported multitasking (even if only the cooperative kind), I just couldn't wrap my head around the idea that I'm multitasking operating system could exist without memory protection.

Re: Win16 Memory Management

#43

Post by JdeBP »

kalleboo wrote: post #39
JdeBP wrote: post #35

Earlier quoted context omitted.

It wasn't really the processor architecture. Segmented addressing was actually fairly easy if the processor was used only in the way that protected mode was envisioned as working. As the headlined article observes, a lot of this stuff simply wasn't necessary in OS/2 1.x, even though that too had DLLs, callback window procedures, and the multiple tiny/small/medium/large/compact/huge memory models. The differences were…

I understood it as Windows developers had to manually deal with segment limitations since Windows supported running on pre-286 CPUs without protected mode (Wikipedia says Windows 1-3 all supported the 8088). OS/2 just made the 286 a minimum requirement so they could rely on a CPU with more modern features. The 68k didn't come with an MMU like the 286 so MacOS couldn't rely on virtual memory like OS/2 did but at least…

Yes, outwith the idea of Family API programs (which couldn't use Presentation Manager and whatnot anyway) OS/2 1.x did target the 286 as a minimum. But that doesn't mean that DOS+Windows didn't use the features.

It did. It was bi-modal. There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mode.

It was the bi-modal nature that was the problem. Essentially, they had to design a whole layer that simulated when in real mode all of the load-on-demand stuff that the processor architecture supplied for free in 286 protected mode, and make it so that the thing would all work either way with no changes to applications.

Re: Win16 Memory Management

#44

Post by markus_zhang »

JdeBP wrote: post #27
markus_zhang wrote: post #8

Earlier quoted context omitted.

I think they learned by reading books such as Undocumented Windows or Windows Internals (not to be confused with Windows NT internals), and Microsoft documents. In fact, I’d argue it was more fun than programming Javascript these days.

It wasn't really the 'Undocumented' and 'Internals' books. Pretty much everything in the headlined article was to be found in the SDK, Microsoft Press publications, and in many third party books about DOS+Windows programming. Petzold's Programming Windows book, for example, devoted an entire chapter (chapter 7) to memory management, with diagrams and examples. In the 2nd edition (which I just pulled off the shelf to…

Yeah you are right. I just listed two random books.

Re: Win16 Memory Management

#45

Post by bluedino »

hnlmorg wrote: post #4
jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

16 bit programs used 16 bit addresses, generally speaking. 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.

And the 32-bit 4GB limit was often really "just a bit under 2GB" depending on the hardware, OS, etc

Re: Win16 Memory Management

#46

Post by cogman10 »

jchw wrote: post #22
jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

As someone who grew up coding after it was mostly 32-bit, I can't say this with certainty, but my gut feeling is that paradoxically you would have and it would've made you stronger.

I think it'd be mixed.

I think the knowledge of underlying hardware is useful and good to know.

But also that sort of knowledge got dated pretty quickly in the early computer era. Further, the capabilities of things like optimizing compilers quickly got to a point where they'd outpace most hand written assembly. Today, it's basically just floating point operations where you can still do better than a compiler.

In the early days, you'd have the correct impression that the C compilers spat out utter garbage which was a lot slower than what you could hand craft. As optimization techniques got better and better, the work you did because the compiler was dumb ultimately would have gotten in the way.

Re: Win16 Memory Management

#47

Post by rramadass »

Good informative article.

Win16 programming was an important formative phase in my career. There is a lot of wisdom in old solutions to thorny problems and knowing them often clues you to how one may adapt them to today's problem. For example, when CPU+GPU programming appeared i immediately imagined CPU memory accessed with "near" pointers and GPU memory accessed with "far" pointers with a switch to a pseudo-segment register.

It also conditioned a programmer to learn about various complexities involved and be careful in their programming i.e. it taught you discipline. You understood your compiler, OS and hardware better and how to write code keeping them all in mind. For example, i often say my study of embedded programming started with Win16!

Another bit of cleverness was "Thunking" between 16-bit and 32-bit code. Here is Raymond Chen on how it worked there and Why can’t you thunk between 32-bit and 64-bit Windows? - https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20...

Re: Win16 Memory Management

#49

Post by unleaded »

jdw64 wrote: post #2

Sometimes I think that if it were the old days, I probably wouldn't have been able to program. I remember that these days we program on top of 64bit virtual addresses, but how did developers do it back then

It's easy when it's the only way to get things done. Think about how nobody who was learning programming before 2023 was seriously thinking "This would be so much easier if the computer wrote it all for me".

Re: Win16 Memory Management

#50

Post by markus_zhang »

hnlmorg wrote: post #32
andyjohnson0 wrote: post #16

Earlier quoted context omitted.

> I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. The 6502 and Z80 could use 16 bit addressing to access up to 64kb of memory. The 6502 had various other addressing systems, including iirc 8 bits, but none of them were wider tha 16 bits.

Oh yeah. I had loads of 6502 and Z80 systems (still do in fact). Can’t believe I forgot about that! Though in fairness, I do mostly now just use those systems to teach my kids BASIC

Just curious how do you teach kids BASIC. I’m sure my 6 year old won’t sit tight.
Post reply on HN