Mail Archives: djgpp/2002/07/18/08:51:31
Eli Zaretskii :
>Make the interrupt handler set a flag when the memory buffer is almost
>full, and make the main foreground function of your logger look at the
Pedro Izecksohn :
> Why don't you create a new file every 5 minutes, (and
>save and close the old one), with a little modified
>filename?
The problem is that I have no main foreground function (and of course cannot
call libc functions from an interrupt context) - as I said, a second program
is spawn'd, but as I didn't make clear, the second program is a legacy piece
of real mode DOS software for which I have no source.
Hans-Bernhard Broeker :
>Why not? Let's see: how fast can even a *very* fast human type? Ten
>keys per second, or let's say a hundred (even the typematic isn't that
>fast)? If you let that person hack away freely for as long as (s)he
>can stay awake, that'll be on the order of one hundred thousand
>seconds times 100 keys per seconds, for a total of 10 Megabytes. If
>that person is *extremely* fast and can keep up that pace for 30 hours
>on end, that is. And you say you don't have memory for that? In a
>DJGPP application?
The consideration is that the memory must be locked, and that the
application I am catching keys from is at least 10 years old, and therefore
has a number of users under every DOS related operating system from that
period from actual DOS up to Windows ME. I assume that if I lock 10mb under,
say, Windows 95, in a machine with just 16mb RAM, things are going to go
very quickly wrong when the operating system finds it cannot page almost
anything to disc above and beyond its own footprint. Although I may be
wrong.
However, on the plus side I am only actually catching the states of seven or
eight keys, and the application is a particular game - massively reducing
how much needs to be stored compared to, say, a word processor or a shell of
some sort.
I expect you are right though, keeping stuff in memory is probably the only
answer, so why quibble?
Thanks!
-Thomas
- Raw text -