[comp.sys.ibm.pc] MS Windows and Physical memory?

berger@datacube.UUCP (12/09/86)

Has anyone had experience using Microsoft Windows where they need
to talk to hardware using pointers?  Does Windows allow explicet
pointers to physical memory?

For example something crude like (assume large model):

char *p;

	p = 0xa0000; /* Set p to point to some hardware location */

	*p = 0xff;	/* Set the register to some value */

Or do you HAVE to use a device driver to access physical memory.

The device that we are accessing is NOT the device that windows is using
itself for display or anything.

Also, does Windows do anything funny to data structures that are globally
shared among functions that are linked together?  Can all functions that
are linked together share all globals?

Is there a better forum for Windows questions/discussions?

			Bob Berger 

Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 	617-535-6644
	
ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!berger

kneller@ucsfcgl.UUCP (Don Kneller%Langridge) (12/12/86)

In article <105500001@datacube> berger@datacube.UUCP writes:
>
>Has anyone had experience using Microsoft Windows where they need
>to talk to hardware using pointers?  Does Windows allow explicet
>pointers to physical memory?
>
>For example
>
>char *p;
>
>	p = 0xa0000; /* Set p to point to some hardware location */
>
>	*p = 0xff;	/* Set the register to some value */

I don't know about Windows, but this may not work because pointers may
not be stored in the same format as longs.  For Microsoft C, the above
*won't* work.  I assume your trying to reference segment A000, offset 0.
In MSC you would say FP_SEG(p) = 0xA000; FP_OFF(p) = 0x0;  This is
definitely not the same as p = 0xA0000.
-- 
	Don Kneller
UUCP:	...ucbvax!ucsfcgl!kneller
ARPA:	kneller@cgl.ucsf.edu
BITNET:	kneller@ucsfcgl.BITNET

jallen@netxcom.UUCP (John Allen) (12/12/86)

In article <9965@cgl.ucsf.edu.ucsfcgl.UUCP> kneller@cgl.ucsf.edu.UUCP (Don Kneller) writes:
>In article <105500001@datacube> berger@datacube.UUCP writes:
>>
>>Has anyone had experience using Microsoft Windows where they need
>>to talk to hardware using pointers?  Does Windows allow explicet
>>pointers to physical memory?
>>
>>For example
>>
>>char *p;
>>
>>	p = 0xa0000; /* Set p to point to some hardware location */
>>
>>	*p = 0xff;	/* Set the register to some value */
>
>I don't know about Windows, but this may not work because pointers may
>not be stored in the same format as longs.  For Microsoft C, the above
>*won't* work.  I assume your trying to reference segment A000, offset 0.
>In MSC you would say FP_SEG(p) = 0xA000; FP_OFF(p) = 0x0;  This is
>definitely not the same as p = 0xA0000.

Well, I *have* done just this in Microsoft C.  The thing to remember is
that "0xA0000" is a 20 bit value, so you must either:

1)  Use the Large model, or

2)  Declare a Far pointer, and enable 'NEAR' and 'FAR' during compile, ie:

	static char far *p = 0xa0000;

(or, in deference to Don's suggestion)

	static char far *p = FP_SEG(0xa000) + FP_OFF(0x0);


John Allen
=========================================================================
NetExpress Communications, Inc.      seismo!{sundc|hadron}!netxcom!jallen
1953 Gallows Road, Suite 300         (703) 749-2238
Vienna, Va., 22180
=========================================================================

michael@orcisi.UUCP (02/16/87)

> >>Has anyone had experience using Microsoft Windows where they need
> >>to talk to hardware using pointers?  Does Windows allow explicet
> >>pointers to physical memory?
> 
> Well, I *have* done just this in Microsoft C.  The thing to remember is
> that "0xA0000" is a 20 bit value, so you must either:
> 
> 1)  Use the Large model, or
> 
> 2)  Declare a Far pointer, and enable 'NEAR' and 'FAR' during compile, ie:
> 
> 	static char far *p = 0xa0000;
> 
> (or, in deference to Don's suggestion)
> 
> 	static char far *p = FP_SEG(0xa000) + FP_OFF(0x0);

In general, this can be used to talk to hardware but won't work for
data that is not FIXED or locked.

In practice, you have to arbitrate task access to the hardware
device when more than one copy of the application is running under Windows.