On Thu, Mar 29, 2012 at 3:03 PM, Eric Auer <e.a...@jpberlin.de> wrote:
> In DOS, you would probably only notice due to high CPU heat output.
> Because when you press the key, even the weak program still reacts
> immediately and most users are still happy.
> You could use some advanced cache statistics to see which parts of
> the program are accessed most often, some CPUs have very CPU model
> specific functionality for that sort of stuff. Also, you could try
> some interrupt counting TSR to see what is called how often, maybe
> Rugxulo knows one.

There are various tools (Trace, UI21DEB, KGB, Argus) that work in
limited situations, or presumably you could also just run through an
emulator with built-in debugger (BOCHS? DOSBox?). I don't know, it's a
tricky situation because apps tend to be quite complex and don't
always interact well in weird situations (e.g. under a debugger).
Though who knows, perhaps 386SWAT could handle it.    ;-)

I just stumbled upon this TSR, Dostap, but I didn't try it. Though it
has sources (MS C + MASM) but isn't redistributable except by them
(eh?). It's fairly old, circa 1996, so maybe one of you could *nicely*
ask them to GPL it or some such. It's meant to lure you to port to
their proprietary (embedded?) software. ( support _AT_ smxrtos _DOT_
com )


DOStap (DOS & BIOS interrupt logging program) 68K (multiple files, compressed)

This TSR will unobtrusively log the DOS & BIOS calls that your program
makes. With the list produced, you will see which calls will need to
be emulated if DOS is removed from your system (such as when moving to
protected mode). Check the list in the unDOS documentation to see what
calls we already have emulated. This program is supplied free of
charge to prospects considering purchasing unDOS and is not to be
distributed, except by Micro Digital.

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
Freedos-user mailing list

Reply via email to