What operating systems won't free memory on program exit?

Short answer is "none". 即使是几年前在DOS上运行的程序也会在程序终止时释放内存(这仅仅是因为程序停止时没有任何东西在管理内存)。我相信有人可能会看到内核模式代码不一定在应用程序退出时释放内存,或者他们可能引用一些模糊的嵌入式操作系统……但是,您可以假设app exit返回用户模式代码获得的所有内存。(Windows3.x可能有这个问题,具体取决于使用了哪个分配器…)

“应该释放内存”这一优点的原因在于,对于大规模的软件工程,您应该努力开发能够灵活使用的组件,因为在您离开团队很久之后,您永远不知道其他人将如何更改代码的使用。

Think of it like this. Let's say you design some class that is designed to be a singleton (only instantiated once during the app lifetime). As such, you decide not to bother with memory cleanup when your component destructs or gets finalized. That's a perfectly fine decision for that moment. Years later, after you've left for greener pastures, someone else may come along and decide that they need to use your class in multiple places such that many instances will come and go during the app lifetime. Your memory leak will become their problem.

On my team, we've often talked about making the user initiated "close" of the application just be exit() without doing any cleanup. If we ever do this, I would still enforce that the team develop classes and components that properly cleanup after themselves.

在cp/m中,释放这么多内存不是问题,因为您的程序有一个静态的RAM区域,并且每个程序都在相同的空间中运行。所以,当程序A退出,程序B运行时,B被简单地加载到A的顶部。

Now there were mechanisms to reserve memory away from the OS, but this wasn't typically heap memory (in the classic case that we consider it today), it was special reserved areas design for various tasks.

For example, DOS had this exit routine called "Terminate and Stay Resident". This "quit" the program, but didn't not release the space after the program quit. Typically these programs loaded up interrupt vectors (such as keyboard interrupts) to trigger routines. Borland Sidekick was a very popular "TSR" back in the day and offered things like a calculator and contact list.

Finally, since these weren't protected memory systems, your programs could abuse the system in all sorts of ways to do what you want, but that's a different discussion.

No recent unix-like operating system fails to free all process memory when a process exits, where recent probably means "since 1970 or so". I'm fairly sure that very old PC operating systems such as DOS and CP/M had this problem, and some older versions of Windows. I don't know enough about recent Windows to be sure, but I would be very surprised if any of Windows XP, Vista, or Windows 7 would have a problem freeing process memory.

As a rule of thumb, I would suggest that any operating system that doesn't use virtual memory to give processes separate address spaces is likely vulnerable to leaking memory when processes fail in major ways. Once an os has implemented per-process virtual address spaces, it already has to keep track of all physical memory allocated to a process anyway, so freeing it reliably is straightforward.

All that said, it's often a good idea to write your programs to clean up after themselves anyway. It tends to lead to better designed subcomponents, and it also makes it easier to apply tools that look for memory leaks and the like.