Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:36 ADT
Stephen Dennis (sdennis@svdltd.com)
Wed, 17 Jun 1998 00:47:06 -0700
On Tuesday, June 16, 1998 10:46 PM, Marcus Watts [SMTP:mdw@umich.edu]
wrote:
> You wrote (with some editting):
> Equivalent, but less convenient results, might be
> obtained by seducing the proper microsoft employee(s), if you can find
> them.
This isn't a big secret.
GlobalLock is an old call. A 16-bit windows application -must- call it
to even get a pointer to memory it allocated with GlobalAlloc.
GlobalAlloc only returns a handle. It was useful when Windows was
running in real-mode and 286-mode with -very- limited memory. The
function takes a handle and gives you a pointer (segment:offset in
real-mode, descriptor:offset in 286-mode and 386-mode).
Real-Mode and 286-Mode:
If a block of memory doesn't have any outstanding pointers to it, then
Windows will write it to disk in an effort to free up very limited
memory. If it is swapped out, it will never be brought back into memory
unless you GlobalLock it again. If your entire application is swapped
out because you change the focus from one window to another and both
applications won't fit in memory at the same time, that "locked" piece
of memory will almost certainly be swapped out, too. Windows may swap
your piece of memory out, and then just not let you run -- you'll be
stuck in GetMessage() I think. So, perhaps a solution is don't call
GetMessage() until your data structures are safely encrypted, but the
crypto people here will tell you, if the key you used to protect that
data is also written to disk, then it's a pointless exercise...the key
and the encrypted data are both on the disk.
386-Mode:
If you are running in 386-mode, there's a hardware-assisted layer of
address translation and demand paging, so your block of memory can be
moved around in physical memory (and will be) even though your address
to it doesn't change. Theoretically, if you access your memory -all- the
time, it won't be paged out to disk. But that's a silly approach, and in
practice it doesn't work because....
...there's a bug in Windows 3.1. I can't remember whether or not the bug
exists in Windows 3.1a or WFW 3.11. I think it was fixed in WFW 3.11,
but I know that the bug does not exist in Windows 95. The LRU paging is
broken. It doesn't stand for least-recently-used...it is more acurately
named: least-randomly-used. The page still has a good chance of being
swapped out to disk (and brought back in almost immediately).
You can better address these issues in a VxD, but that only runs in
386-mode, and there is still some funny business which unfortunately, I
can't remember anymore. I know that you can do what you want with a VxD
running WFW 3.11 or later. Actually, your code can be Ring 3, but you'll
need a VxD to lock you down correctly.
I don't work for Microsoft anymore. I was the primary architect for the
Windows Printing System. The sleek version (where the parallel port is
essentially a slightl-buffered video interface) needs it's bits locked
down in physical memory.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:18:36 ADT