I assume you want to use that area for the purpose it was originally intended... inter-application communication. If I am not mistaken, 4F0h to 4FFh has been a "dead" area in ROM-BIOS memory since the early days of DOS. It was just too small to store any meaningful data (maybe big enough for a few pointers and flags, but that's about the extent of it).
If memory serves me correctly, there was once an interrupt intended to facilitate use of this area, but I have long since lost the documentation. I tried to dig it back up by scanning through my old DOS programming tomes and searching Ralf Brown's Interrupt list but I couldn't locate more than a passing reference to it.
I don't believe you will find documentation for use of this area by Windows or any modern application. It probably serves no useful purpose.
One might be tempted to try....
Code:
DEFINT A-Z
V$ = "16 bytes of data"
Ch = 1
DEF SEG = 0
FOR Address = &H4F0 TO &H4FF
POKE Address, ASC(MID$(V$, Ch, 1))
Ch = Ch + 1
NEXT
DEF SEG
...in one program and then attempt to read the data with...
Code:
DEF SEG = 0
FOR Address = &H4F0 TO &H4FF
Vr$ = Vr$ + CHR$(PEEK(Address))
NEXT
DEF SEG
PRINT Vr$
...in another program.... But Windows isn't going to allow you to do that any more than it will allow you to pass variables through either the local environment or the master environment. (
Remember the master environment table? We used to find it by tracing through the PSP chain until we found the first running copy of the command interpreter, searching for the name of the environment variable we wanted to modify, and then poking the values directly into memory. That stragegy hasn't worked since Win3.11.)
As it turns out, the easiest and most reliable way for two 16-bit apps to exchange "effective" amounts data under Windows, is to write and read the data using the file methods.
Sorry I couldn't be more helpful... it appears that you have excavated the fossilized remains of a prehistoric horse. It's going to take a lot more than CPR to bring it back to life.