Hey,
Can any of the older minds in here recall if there's a win16 program available that can identify where in memory exe modules have been loaded?

1. You might try downloading MAP.exe (Actually, Map2, with the irritating NIGEL screen)

2. You might try reading ORC's tools on How to crack - Lesson 2.0

3. You might also try reading softICE manual (commands PDF actually, not the user guide)

Have Phun

Well I've tried using Map, but it's a bit pointless as it only works with real mode (Win 3.1 Standard Mode runs in 286 PM) so I can't see any relevant memory (above 1MB).

Trying to stay away from SI to be honest, I don't like the interface.

Why does it have to be Win16? I don't think Win16 programs even have the ability to retrieve information about all the modules loaded in the system.

Because I'm trying to debug a Win16 target using the Bochs debugger. It has everything I need bar the ability to search memory, which means that I have to resort to crazy things like causing exceptions and tracing through thousands of unrelated instructions to find out where I should be looking. Being able to find out what is where easily would be nice.

True, the API is unlikely to provide the ToolHelp functions that came in with Win32. But surely in the old days programmers still needed this type of functionality and probably achieved it using a driver or special hack to see what Windows sees?

MATT PIETREK: Windows 95 System programming secrets

If you can run your Win16 process under Win95 you should read CHAPTER 7 : W I N 1 6 MODULES AND TASKS - ~100 pages of what you want to know.

There is a program bundled with the book - SHOW16 - that can show you segment informations, global heap handles and other interesting stuff that you might find helpfull.

And you can use toolhelp to access some of the win16 data (at least under win 95).

Hi

You don't say what OS you're running this under. If this is a 16bit Windows app then Win98 + Softice 4.05 is probably the most useful way to run it, for a DOS program you can use DLDR.EXE.

Not to beat a dead horse, but here is the 16bit Cardfile.exe paused at program start under Softice in Win98, ready for tracing with all the power of the Softice memory and other commands available.



Might not be the tool of your choice, but nothing else is needed really.

Kayaker

I'm running Bochs under XP.
Yes, I could get a Win98/SI combo going, but it's a bit like opening the petals of a flower with a sledgehammer. I can already see what I need to see (when, by chance, it appears where I expect), the only thing I'm trying to achieve is to look at the registers and stack before and after certain routines have been executed. Nothing more.

Never mind, after much searching I found InfoSpy, a nice little shareware program that can provide you with an itemised listing of the heap with physical addresses, amongst other things.

No problem, I just wanted to illustrate Sice running a 16bit app. That InfoSpy app seems pretty useful for looking at 16 bit environments. I was surprised it works just as well with an NT based OS where 16bit apps run under NTVDM. I'm not sure if you're emulating Win95/98 under Bochs or not, or what you can use, but I was also going to mention that TopToBottomNT by SmidgeonSoft (pretty useful in general) can also look at the memory a 16bit app occupies under NTVDM.

InfoSpy is better at specifically identifying the sectors used by the 16bit app, code, resources, private areas and such, and has a basic memory viewer. But one might be able to use TopToBottomNT as well to get a bit further information since it has a more detailed memory map of the regions used by NTVDM and the underlying 16bit app, as well as any associated modules. Your Bochs debugger might be better for looking at the stack areas, but TopToBottomNT might be useful as well if you can identify the memory.

Well in the end I got rid of InfoSpy because it was not terribly stable doing what I wanted. In fact, I went right back to basics and used MS Heap Walker (I had a VC++ 1.52 CD lying around), just wanted to know where in memory different code segments were loaded (Bochs is crap in that respect, but oh well).

Pretty pointless, too, given that after doing some work on a program it crashes shortly after accepting my key! Now I don't know whether my key is at fault or whether the program itself (or its supporting files) are b0rked.

It was for an +ORC lesson, btw. A "hard" one.