Hi, I'm speaking under correction, but I'm afraid there are no 'processes' in 16-Bit Windows as we know it.
Looking from outside into Windows 3.1, it looks like one big program with many sub routines.

Of course, Windows 3.1 has multi-tasking (cooperative, message based, on a time-sharing basis) and runs multiple programs.
However, it's not like it is with Windows 9x or NT.

(Programs in Windows 3.1 share one global memory space and use relocation tables, thus.
Relocation tables allow Win16/Win32s programs to start at different locations in the same, shared memory.
- Compilers meant for Windows NT 3.1 and Win32s insert relocation tables in Win32 binaries, too, even though Windows NT and Win95 usually don't require them.
In recent times, however, they come in handy because of DEP etc. Programs that can relocate are more flexible than those who can't.)

Cool, thank you, I didn't know that.
So is there something that will display it in a graphical sense?
Or is it time to just sit down and get comfortable with something like debug?

You're welcome. :)

I'm not sure, to be honest. I guess the answer is "yes", though (there is).

I vaguely remember such programs from the Windows 2.x days.
They showed the various memory locations (conventional, UMBs, EMS) etc.

So I believe there must be similar tools for Windows 3.x, also.
Maybe as part of commercial packages (PC-Tools etc).

However, as I said, I'm not really sure.
In the early Windows 1.x/2.x days, Win16 programs were still allowed/expected to tinker with memory (first MB).
Programming guidelines for Windows 3.0 compatible programs later on forbade memory arithmetics.

That was because Windows now was meant to be run in Protected-Mode primarily.
And those old tinkering with memory addresses was causing stability issues.

Anyway, that's a bit off-topic, I'm afraid. 😅

I'll have a look. Maybe I can find an utility for you.

CraigAB69 wrote on 2021-12-28, 02:53:

On a side note, there is a cool util umbinfo.com (In german, I think) which only shows the UMB, obviously. If it did all memory in DOS that would be great.
MSD, seems to only good for dos, no windows version.

It sounds like you'd be interested in the DOS MEM /C command then, but as already mentioned that is only going to show you processes that DOS is aware of, which isn't the tasks running under Windows.

I assume you want to find out the physical locations in memory, rather than the addresses as seen by the application? I don't know if Windows would have ever provided APIs to enable you to find that information out, except when you locked a block of memory, since when it's not locked it might be moved around at any time. I'm not sure why you want to know the physical locations but they're not going to be that useful if they might have already changed even before you see them. If what you're after is the addresses seen by the application, they can change too for some types of memory depending on whether you're using Real, Standard or 386 Enhanced mode. It might help if you explained a bit more about your goals.

I imagine the kernel debugger probably lets you get this information though. I assume it will let you halt Windows so that things don't get moved around while you're looking at them. http://www.os2museum.com/wp/kernel-debugging- … ith-virtualbox/ talks a little about how you can use that debugger (after first talking about the OS/2 one).

If the way Windows manages memory is unfamiliar to you, you might be able to learn a bit from chapter 7 of "Programming Windows 3.1" by Charles Petzold, which is included in various of the first few MSDN CDs in the "Books and Periodicals" section. There were earlier editions of the book too and I imagine it's available for loan from archive.org. I think I learned about how it deals with memory (and promptly forgot quite a bit) from "Microsoft Windows 3 Developer's Workshop" by Richard Wilton which tried to focus on the problematic areas of Windows development unlike Petzold's book which seems more like a tutorial, but unfortunately the Wilton book isn't available online. I'm sure Petzold has all the important information, I just skimmed chapter 7 for a refresher.

Hi there!

I've remembered an earlier thread about Windows 3.x memory managment
and found some old memory utilites for Windows 2.x, too..

Re: Viewing the Upper Memory area

Good luck! 😀

I just remembered HeapWalker, which comes for example with Visual C++ 1.5. It shows individual memory allocations with details including their address, handle, size, owning module and type (e.g. resource, code, etc.). The owning module is an executable or DLL, so you can't necessarily map the memory usage to a particular process (or task as they are called, at least in the 16-bit Windows API), but that's a normal issue with operating systems that allow more than one process to run. You can highlight some allocations and select the "Add!" menu option to see the total size. It's definitely at a lower level than Process Explorer, then.

Speaking of Process Explorer:

CraigAB69 wrote on 2021-12-28, 02:53:

I can only find version 10.6 of Process Explorer (is there earlier version somewhere?)

Here are the oldest versions of the sites distributing software from the company that made Process Explorer which I could find on the Wayback Machine:

https://web.archive.org/web/19981212033213/ht … sinternals.com/ - 1998
https://web.archive.org/web/19980121010948/ht … winternals.com/ - 1998
https://web.archive.org/web/19961222153527/ht … tinternals.com/ - 1996

I don't see any indication of them supporting anything before Windows 95.

I found a shareware program called "Hogs" or "Memory Hogs" by Kamyan Software which doesn't show addresses, but shows total memory usage for each module, sorted from highest to lowest. The list of modules seems to include drivers, and also down the bottom it has fonts which take up 0.2KB each. If you don't check "Show DLLs", it won't show significant parts of Windows itself like GDI and USER and less significant parts like the fonts, just programs.

Here I gave my emulated machine 4MB of RAM. The DOS MEM command showed about 500KB of conventional memory and all 3MB of extended memory available before I started Windows, and when I added the sizes of all the modules shown by Hogs to the free memory it came out to close to 3.5MB, so I think it can see everything, or just about everything.

As I said, it's shareware. It has a registration fee of $15 and I would feel bad using it without paying since it's not hard to track down the author, but based on this post where he released the full version of a shareware game he wrote back then, it looks like he'd probably be happy to make it freeware if anyone asked: https://www.pixarra.com/pendulous.html I might ask if nobody beats me to it and I end up wanting to use it for something.

Next I want to check out McAfee's Proview for Windows. I used it back when it was new, but only briefly, mostly using the DOS version. I'm not sure if it provides this kind of information about memory usage, but the DOS one did regarding DOS memory.

Edit:

Here is a link to download Hogs: http://cd.textfiles.com/somuch/smsharew6/winutils/hogs16.zip

For anyone who is interested, I found it by browsing random shovelware CD indexes on cd.textfiles.com. I noticed that most memory-related programs seem to describe themselves as just showing the amount of memory free and used, resource usage, etc., and this was the first one whose description (in http://cd.textfiles.com/wthreepack/wthreepack … CDM/TEXT/MEMORY - yes that's a different CD, I searched the site for a newer version after reading that description) said it actually listed programs. I stopped looking after I found this one so there might be other/better ones out there.

doshea wrote on 2022-04-30, 02:17:

I found a shareware program called "Hogs" or "Memory Hogs" by Kamyan Software which doesn't show addresses, but shows total memory usage for each module, sorted from highest to lowest. The list of modules seems to include drivers, and also down the bottom it has fonts which take up 0.2KB each. If you don't check "Show DLLs", it won't show significant parts of Windows itself like GDI and USER and less significant parts like the fonts, just programs.

Thanks mate,

I cannot find it. I have tried searching for (Individually and a combination of:) "Memory hog", "1.6", "windows 3.1", "Shareware".
Do you have a link?

Maybe my google-fu needs work?

Oops, sorry, I meant to include the link! I've edited the post to add that to the end and also explain how I found it.

I've checked McAfee's Proview for Windows now, but it actually shows memory allocations at the DOS level - and in fact other lower-levels things like BIOS memory usage, etc. - exactly like the DOS version, so it's not useful here. For anyone who wants to check that out, Google "site:cd.textfiles.com wpv102a".

Thanks for the link.

Yea, ProView is interesting. https://archive.org/details/WPV12_ZIP

It is so strange to be from the era of Win 3.1, yet not to know about useful software.
I feel like I must have been living under a rock.
I suppose the Internet can be thanked for the exposure of knowledge.

CraigAB69 wrote on 2022-05-03, 00:31:

Thanks for the link.

Not a problem!

Yea, ProView is interesting. https://archive.org/details/WPV12_ZIP

It looks like that'd be version 1.02, whereas the search I posted above would give you 1.02a, for whatever it's worth.

It is so strange to be from the era of Win 3.1, yet not to know about useful software.
I feel like I must have been living under a rock.
I suppose the Internet can be thanked for the exposure of knowledge.

I guess that back then you needed to be subscribed to a magazine and/or have access to BBSes to keep up with this stuff to any extent, and even then there was a limit to how much you could download and try out!

I'm not sure if anyone will be interested, but I've been thinking a little about writing some software along these lines myself. Hogs is okay but I'd kind of like something that - at least by default - grouped all the non-program modules into "other" or something like that. I don't really want to make a GUI, and I have two options in mind:
- I've been working on a fork of an open source Lisp interpreter which runs under Windows 3.1. I've been adding support to it for automating things in Windows, like sending keystrokes, etc. I could add support for the APIs required for getting task information, and then code the logic for generating totals and summaries in Lisp.
- "Troy's Kernel" (which I should do a post or something about one day) also runs on Windows 3.1 is kind of like Cygwin (but with very limited capabilities and not much ported to it). It has a "ps" command which does provide information on all Windows tasks, but not modules, and it doesn't show memory usage. It could be updated to provide more information.
I'm not sure if I'll get around to either of those, but if someone is particularly interested in either of those environments I might.

I have been kicking around the idea of writing something, in a basic form, like process explorer for Win 3.x. But at the moment I have been tied down with other work.
That's why I was asking about process explorer for Win 3.x, I didn't want to re-invent the wheel.

But bottom line, it will be a learning process for me.

Assembly, was the target language. Mostly because of the low level knowledge required, but also the size.

I enjoy the older environments, less distractions.

Yea, magazine subscriptions. First you would need to know the correct mags to subscribe to, then the high cost to get them sent here to Australia. Not to mention trying to find people that had similar interests, which was surprisingly difficult back in the lat 80's / early 90's. Well it was for me, country Victoria, Australia was not known for it's Technology, 🤣.

CraigAB69 wrote on 2022-05-05, 00:44:

I have been kicking around the idea of writing something, in a basic form, like process explorer for Win 3.x. But at the moment […]
Show full quote

I have been kicking around the idea of writing something, in a basic form, like process explorer for Win 3.x. But at the moment I have been tied down with other work.
That's why I was asking about process explorer for Win 3.x, I didn't want to re-invent the wheel.

But bottom line, it will be a learning process for me.

Assembly, was the target language. Mostly because of the low level knowledge required, but also the size.

Sounds good!

I'm sure it's doable from assembly, but you would be calling APIs defined in C header files, and I suspect that you don't need too much low-level knowledge to get information out of Windows unless you're bypassing the API, in which case I suspect you'd be depending on the kind of internals that differ between versions (so probably a bit painful, but at least there aren't too many versions).

Also, maybe there are some assembly frameworks for writing Windows 3.x applications that make it better, but have you ever seen how huge a basic "Hello world" application for Windows 3.x written in C is? See for example https://archive.org/details/programming-windows-3/page/16 in Charles Petzold's famous Programming Windows book, which it says is over 80 lines long. I'd hate to think of what the assembler equivalent would be! But I know some people do write assembly code for Windows so maybe there are ways to avoid it being so bad.

Yea, magazine subscriptions. First you would need to know the correct mags to subscribe to, then the high cost to get them sent here to Australia. Not to mention trying to find people that had similar interests, which was surprisingly difficult back in the lat 80's / early 90's. Well it was for me, country Victoria, Australia was not known for it's Technology, 🤣.

Oh yeah, I'm sure things would have been much harder in the country! Unless IBM's factory in Wangaratta resulted in there being a lot of tech folks in that particular area?

Aside from expensive overseas magazines, there was also Australian Personal Computer Magazine which seemed good. Also in terms of both magazines and similar interests, there were PC user groups if you were lucky enough to know that they existed. One of the members of this forum has archived some magazines from Brisbane's group here: http://archive.shikadi.net/brisbug/ I have a vague recollection that the Melbourne PC User Group was well known as being quite good although perhaps a membership fee wouldn't have looked so attractive if you could only get the magazine delivered but never attend the meetings!

If you look at those magazines, you'll see a listing of new programs at the back. You could drop off your order, attend the meeting, then pick up some floppies with the software you ordered after the meeting, so that was another way of getting new software which I forgot about before!