Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #89265 > unrolled thread

how does one access a specific address location in C?

Back to article view | Back to comp.lang.c

Contents

  how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 06:32 -0700
    Re: how does one access a specific address location in C? gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-16 14:00 +0000
    Re: how does one access a specific address location in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 15:07 +0100
      Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 07:18 -0700
        Re: how does one access a specific address location in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-06-16 11:38 -0500
    Re: how does one access a specific address location in C? Mark Storkamp <mstorkamp@yahoo.com> - 2016-06-16 09:16 -0500
      Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 07:50 -0700
        Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 08:04 -0700
          Re: how does one access a specific address location in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 17:03 +0100
            Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 10:01 -0700
              Re: how does one access a specific address location in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-16 14:29 -0400
              Re: how does one access a specific address location in C? Mark Storkamp <mstorkamp@yahoo.com> - 2016-06-16 13:34 -0500
                Re: how does one access a specific address location in C? BartC <bc@freeuk.com> - 2016-06-16 19:57 +0100
                  Re: how does one access a specific address location in C? raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:50 +0000
                  Re: how does one access a specific address location in C? Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 17:23 -0400
                    Re: how does one access a specific address location in C? raltbos@xs4all.nl (Richard Bos) - 2016-06-18 21:30 +0000
              Re: how does one access a specific address location in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 21:09 +0100
          Re: how does one access a specific address location in C? Mark Storkamp <mstorkamp@yahoo.com> - 2016-06-16 11:10 -0500
        Re: how does one access a specific address location in C? James Kuyper <jameskuyper@verizon.net> - 2016-06-16 13:41 -0400
          Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 11:14 -0700
            Re: how does one access a specific address location in C? Keith Thompson <kst-u@mib.org> - 2016-06-16 11:26 -0700
            Re: how does one access a specific address location in C? James Kuyper <jameskuyper@verizon.net> - 2016-06-16 16:38 -0400
        Re: how does one access a specific address location in C? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-18 11:32 -0400
    Re: how does one access a specific address location in C? James Kuyper <jameskuyper@verizon.net> - 2016-06-16 12:45 -0400
      Re: how does one access a specific address location in C? G G <gdotone@gmail.com> - 2016-06-16 10:19 -0700
      Re: how does one access a specific address location in C? Keith Thompson <kst-u@mib.org> - 2016-06-16 11:20 -0700
      Re: how does one access a specific address location in C? supercat@casperkitty.com - 2016-06-16 11:38 -0700
        Re: how does one access a specific address location in C? raltbos@xs4all.nl (Richard Bos) - 2016-06-18 13:19 +0000
          Re: how does one access a specific address location in C? supercat@casperkitty.com - 2016-06-18 07:11 -0700
            Re: how does one access a specific address location in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-06-18 14:41 -0500
              Re: how does one access a specific address location in C? supercat@casperkitty.com - 2016-06-18 16:02 -0700
                Re: how does one access a specific address location in C? Les Cargill <lcargill99@comcast.com> - 2016-06-18 18:53 -0500
                  Re: how does one access a specific address location in C? supercat@casperkitty.com - 2016-06-18 17:31 -0700
                    Re: how does one access a specific address location in C? Les Cargill <lcargill99@comcast.com> - 2016-06-19 06:47 -0500
                  Re: how does one access a specific address location in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-06-19 00:37 -0500
                    Re: how does one access a specific address location in C? BartC <bc@freeuk.com> - 2016-06-19 11:07 +0100
                      Re: how does one access a specific address location in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-06-19 16:21 -0500
                Re: how does one access a specific address location in C? Robert Wessel <robertwessel2@yahoo.com> - 2016-06-19 00:34 -0500

Page 2 of 2 — ← Prev page 1 [2]

#89318

G G <gdotone@gmail.com> writes:
[...]
> but, no, i was thinking just starting with an address, where one
> knew the object type, could the value be seen?
[...]

Where does this address come from, and in what form do you have it?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#89337

On 06/16/2016 02:14 PM, G G wrote:
> On Thursday, June 16, 2016 at 1:41:21 PM UTC-4, James Kuyper wrote:
>> On 06/16/2016 10:50 AM, G G wrote:
>> ...
>>> given :
>>>    int aNumber; 
>>>    int *aNumberPtr; 
>>>    aNumber = 5; 
>>>    aNumberPtr = &aNumber; 
>>> ----
>>>
>>> if one wanted to look at memory location at &aNumber.
>>> the following is suppose to work?
>>> unsigned int *peekAtValuePtr = ( unsigned int *) 0x7fff5f01bc1c
>> Only if aNumber happens to be located at that address,. What you should
>> be doing is
>>
>>     int *peekAtValuePtr = &aNumber;
>>
>> Is there some reason why that's not an acceptable answer to your question?
> 
> and that works, but no. my thinking was given an address to look at that address.
> i needed an address that i knew i could write to, not restricted by the OS, but 
> from running the program repeatedly, at least on my system, Ben is right, the 
> address changes.

Right - which is why &aNumber is the better approach. It always gives
you correct address for aNumber, regardless of where that object is
located during this run of the program.

> that kind of what started my curiosity because 
> 
> ....
> 
>    int peekAtValuePtr = &aNumber;
>   
>    printf ( "the value at this address is %d", *peekAtValuePtr );
> ....
> works fine.
> 
> but, no, i was thinking just starting with an address, where one
> knew the object type, could the value be seen?

Sure - as long as you know what the address is. The best way to know
what the address of aNumber is to use the '&' operator - that's what
it's there for.

> hm, so perhaps, as i was told earlier, i must not think in terms
> of having the OS handle the I/O? just a general question, and
> please if it is far a field ... i get it. how are devices controlled
> on, for example, PCs.   aren't you writing to specific memory 
> location? i'll find a book on device drivers, but if anyone has any 
> recommendations i'm interested.

That is extremely OS dependent, and I suspect that the more
sophisticated the OS, the less likely it is that device drivers write to
hard-coded memory locations (that's not the kind of programming I do, so
I can't be certain). However, that technique is used (at least, it was
used on the MS-DOS machines I used in the 80's where I knew precisely
how to do such things - I presume it must still be used, somewhere). It
is inherently usable only for memory locations that DONT change, and as
such does not apply to things like aNumber.

[toc] | [prev] | [next] | [standalone]

#89534

On 06/16/2016 10:50 AM, G G wrote:
...
> int main( void )
> {
>    int a;
>    int *aPtr;
> 
>    a = 7;
>    aPtr = &a;
> 
>    printf( "The address of a is %p"
>            "\nThe value of aPtr is %p", &a, aPtr );
> 
> 
>    printf( "\n\nThe value of a is %d"
>            "\nThe value of *aPtr is %d", a, *aPtr );
> 
>    printf( "\n\nShowing that * and & are complements of "
>            "each other\n&*Ptr = %p"
>            "\n*&aPtr = %p\n", &*aPtr, *&aPtr );
> 
>    unsigned int *peekAtValuePtr = (unsigned int *) 0x7fff5596ec1c; // address of a on my machine

It just occurred to me to wonder where exactly you got that
0x7fff5596ec1c from. Was it from the %p output by a previous run of a
similar program? If so, there's an important thing you need to
understand about the "%p" conversion specifier. The only thing that it
guarantees about the output is that it consists entirely of printing
characters, and that if it's read back using scanf() during the lifetime
of the object that the pointer points at, the resulting pointer still
points at that object. Note that scanf("%p", ...) requires a void*
pointer, so your code would have to look something like this:

     T t;
     printf("%p", &t);

     void *pv;
     scanf("%s", &pv);
     assert( (T*)pv == &t);

It's entirely possible that the string printed by "%p" might not be
interpretable as a number. The simplest counter-example I can think of
is that  on platforms with a segment-offset architecture, it might
display in the form "0F9A:8736", where 0F9A is the hexadecimal segment
number, and 8736 is the hexadecimal offset. Note that this output does
not contain the 0X prefix required in order for those numbers to be
interpreted as hexadecimal constants if copied into C code.

[toc] | [prev] | [next] | [standalone]

#89304

On 06/16/2016 09:32 AM, G G wrote:
> how does one access a specific address location?
> 
> given address say:  0x00000002
> 
> given the value at that location is an int, 32 bits in size.
> 
> 
> ------
> 
> given address say: 0x00000006
> 
> given the value at that location in a char, 16 bits in size.
> 
> ------
> 
> Please explain the thought process of addressing a specific address
> location.

Other people have already answered you correctly, but I want to put a
somewhat different emphasis on my answer.

For any given implementation, there might not be any way to do what
you're asking about. However, if there is, then the appropriate code is
very likely to be:

    int *pitwo = (int*)0x00000002;
    char *pcsix = (char*)0x00000006;

> Or/And is it a hack(so to speak) to do so, or does the specification support such a use
> of the C language.

Here's what the standard says about the code that I have given above:

"... the result is implementation-defined, might not be correctly
aligned, might not point to an entity of the referenced type, and might
be a trap representation." (6.3.2.3p5)

So, yes, it is a hack. So why am I suggesting such code? It's the first
part that's relevant: "implementation-defined". This means that the
result of converting an integer to a pointer type must be defined in the
documentation for any conforming implementation of C. The documentation
might cost $200,000, it might be written in badly-translated
Azerbaijani, but it must exist or it isn't a conforming implementation.
If you look there, and find an explanation that allows you to use such
code, you're good - for that implementation. Do NOT expect the code to
work the same way on a different implementation. However, that's pretty
much to be expected - the same memory location might be used for two
entirely different purposes by two different implementations of C.

However, the fact that it's implementation-defined means that the
definition might be more complicated than that. For instance, it might
be that in order to create a pointer that refers to address 0x00000002,
you might have to write the following code:

    int *pitwo = 0x00020000;

Two key points about this possibility:
a) It is extremely unlikely. Implementors do not routinely go out of
their way to make things difficult for their customers - that's a good
way to lose customers.

b) It's entirely possible that there is some platform where there's a
good reason for creating a non-trivial relationship between an address
and the integer used to initialize a pointer pointing at that address. I
wouldn't be surprised if there was such an implementation; I wouldn't be
surprised if there was no such implementation. I would be very surprised
and quite skeptical if anyone claimed to know for certain that there is
no such implementation.

However, if such an implementation did exist, those who use it would
quickly develop terminology to distinguish such things. They might refer
to 0x00000002 as the "machine address" and "0x00020000" as the "C
address", or something like that. Teaching newbies about the distinction
would be a regularly recurring topic in any forum devoted to that
implementation. If you find a document that says "the address for your
sound card's playback memory is 0x12345678", there's a decent chance
that they'll be referring to the C address, rather than the machine
address, particularly if the same article contains example code written
in C.

[toc] | [prev] | [next] | [standalone]

#89309

On Thursday, June 16, 2016 at 12:45:25 PM UTC-4, James Kuyper wrote:
> On 06/16/2016 09:32 AM, G G wrote:
> > how does one access a specific address location?
> > 
> > given address say:  0x00000002
> > 
> > given the value at that location is an int, 32 bits in size.
> > 
> > 
> > ------
> > 
> > given address say: 0x00000006
> > 
> > given the value at that location in a char, 16 bits in size.
> > 
> > ------
> > 
> > Please explain the thought process of addressing a specific address
> > location.
> 
> Other people have already answered you correctly, but I want to put a
> somewhat different emphasis on my answer.
> 
> For any given implementation, there might not be any way to do what
> you're asking about. However, if there is, then the appropriate code is
> very likely to be:
> 
>     int *pitwo = (int*)0x00000002;
>     char *pcsix = (char*)0x00000006;
> 
> > Or/And is it a hack(so to speak) to do so, or does the specification support such a use
> > of the C language.
> 
> Here's what the standard says about the code that I have given above:
> 
> "... the result is implementation-defined, might not be correctly
> aligned, might not point to an entity of the referenced type, and might
> be a trap representation." (6.3.2.3p5)
> 
> So, yes, it is a hack. So why am I suggesting such code? It's the first
> part that's relevant: "implementation-defined". This means that the
> result of converting an integer to a pointer type must be defined in the
> documentation for any conforming implementation of C. The documentation
> might cost $200,000, it might be written in badly-translated
> Azerbaijani, but it must exist or it isn't a conforming implementation.
> If you look there, and find an explanation that allows you to use such
> code, you're good - for that implementation. Do NOT expect the code to
> work the same way on a different implementation. However, that's pretty
> much to be expected - the same memory location might be used for two
> entirely different purposes by two different implementations of C.
> 
> However, the fact that it's implementation-defined means that the
> definition might be more complicated than that. For instance, it might
> be that in order to create a pointer that refers to address 0x00000002,
> you might have to write the following code:
> 
>     int *pitwo = 0x00020000;
> 
> Two key points about this possibility:
> a) It is extremely unlikely. Implementors do not routinely go out of
> their way to make things difficult for their customers - that's a good
> way to lose customers.
> 
> b) It's entirely possible that there is some platform where there's a
> good reason for creating a non-trivial relationship between an address
> and the integer used to initialize a pointer pointing at that address. I
> wouldn't be surprised if there was such an implementation; I wouldn't be
> surprised if there was no such implementation. I would be very surprised
> and quite skeptical if anyone claimed to know for certain that there is
> no such implementation.
> 
> However, if such an implementation did exist, those who use it would
> quickly develop terminology to distinguish such things. They might refer
> to 0x00000002 as the "machine address" and "0x00020000" as the "C
> address", or something like that. Teaching newbies about the distinction
> would be a regularly recurring topic in any forum devoted to that
> implementation. If you find a document that says "the address for your
> sound card's playback memory is 0x12345678", there's a decent chance
> that they'll be referring to the C address, rather than the machine
> address, particularly if the same article contains example code written
> in C.

Ok, thanks James. Thanks Ben, Thanks Mark.

in that i'm still a newbie reading about pointers and addressing, this just 
caused me to think this was common place in C. but, if the OS writes 
to different machine memory location, on each run of a program and 
is free to move objects around in memory i guess my pursuit is futile.

thanks though for entertaining the question.

g.

[toc] | [prev] | [next] | [standalone]

#89316

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> Other people have already answered you correctly, but I want to put a
> somewhat different emphasis on my answer.
>
> For any given implementation, there might not be any way to do what
> you're asking about. However, if there is, then the appropriate code is
> very likely to be:
>
>     int *pitwo = (int*)0x00000002;
>     char *pcsix = (char*)0x00000006;

Note that the use of hexadecimal with leading zeros is mainly for the
benefit of the reader, to emphasize that these are 32-bit numbers (and
assuming a machine with 32-bit addresses).  The above is exactly
equivalent to:

    int *pitwo = (int*)2;
    char *pcsix = (char*)6;

but the hex version is clearer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#89321

On Thursday, June 16, 2016 at 11:45:25 AM UTC-5, James Kuyper wrote:
> Here's what the standard says about the code that I have given above:
> 
> "... the result is implementation-defined, might not be correctly
> aligned, might not point to an entity of the referenced type, and might
> be a trap representation." (6.3.2.3p5)
> 
> So, yes, it is a hack. So why am I suggesting such code? It's the first
> part that's relevant: "implementation-defined". This means that the
> result of converting an integer to a pointer type must be defined in the
> documentation for any conforming implementation of C. The documentation
> might cost $200,000, it might be written in badly-translated
> Azerbaijani, but it must exist or it isn't a conforming implementation.
> If you look there, and find an explanation that allows you to use such
> code, you're good - for that implementation. Do NOT expect the code to
> work the same way on a different implementation. However, that's pretty
> much to be expected - the same memory location might be used for two
> entirely different purposes by two different implementations of C.

The vast majority of the physical machines upon which C is likely to
run have a hardware-defined relationship between integer values and
pointers, and the vast majority of C compilers for platforms that
define such a relationships will use the relationship defined by the
underlying platform.

While there are a few situations where it can be useful for
implementations to have semantics which differ from the underlying
platform (e.g. an implementation may be designed to emulate the
behavior of some other hardware platform) it would be helpful if
the Standard specified some means via which programmers could
determine, without having to learn Azerbaijani, which aspects of
underlying platform semantics a given implementation would or would
not expose to the programmer.  As yet, however, I am unaware of
any such means.

[toc] | [prev] | [next] | [standalone]

#89530

supercat@casperkitty.com wrote:

> On Thursday, June 16, 2016 at 11:45:25 AM UTC-5, James Kuyper wrote:
> > Here's what the standard says about the code that I have given above:
> > 
> > "... the result is implementation-defined, might not be correctly
> > aligned, might not point to an entity of the referenced type, and might
> > be a trap representation." (6.3.2.3p5)

> > Do NOT expect the code to
> > work the same way on a different implementation. However, that's pretty
> > much to be expected - the same memory location might be used for two
> > entirely different purposes by two different implementations of C.
> 
> The vast majority of the physical machines upon which C is likely to
> run have a hardware-defined relationship between integer values and
> pointers, and the vast majority of C compilers for platforms that
> define such a relationships will use the relationship defined by the
> underlying platform.

Erm. That may be the case right now. It might not be - I don't know how
weird things get on PICs and similar elevator controllers - but it's
certainly _in appearance_ true on Wintel systems. Note "in appearance":
there are things going on behind the scenes. These need not concern the
user-programmer, though.
However. It was not true for a significant part of C's history, and may
return to not being true some time in the future. Recall MS-DOS's
segmented memory schemes? (Well, strictly speaking they were Intel's,
but MS-DOS was where you encountered them.) Windows papers over all that
where and if still necessary, but I wouldn't want to rely absolutely on
something similar never coming back on, say, portable platforms.

Richard

[toc] | [prev] | [next] | [standalone]

#89532

On Saturday, June 18, 2016 at 8:19:56 AM UTC-5, Richard Bos wrote:
> supercat wrote:
> > The vast majority of the physical machines upon which C is likely to
> > run have a hardware-defined relationship between integer values and
> > pointers, and the vast majority of C compilers for platforms that
> > define such a relationships will use the relationship defined by the
> > underlying platform.
> 
> However. It was not true for a significant part of C's history, and may
> return to not being true some time in the future. Recall MS-DOS's
> segmented memory schemes? (Well, strictly speaking they were Intel's,
> but MS-DOS was where you encountered them.) Windows papers over all that
> where and if still necessary, but I wouldn't want to rely absolutely on
> something similar never coming back on, say, portable platforms.

The 8086 had a clearly defined format for a pointer (offset first, followed
by segment) which is used in the LDS and LES instructions, as well as
interrupt vectors.  While the processor didn't have a defined format for
32-bit integers as such, since the only operations that used those were
limited to operating upon the DX/AX register pair, I believe their
assembler did have a directive (something like dq) for storing 32-bit
values, and in any case the fact that bytes in a 16-bit word were stored
in little-endian format strongly suggested that the halves of a 32-bit
longword should logically be stored likewise, which is how--so far as I
know--all language tools for that platform have stored them.

I did not say that all machines defined the mapping of pointers to integers
in strictly linear fashion throughout the entire address space; Intel's
under-appreciated 8086 architecture is the most interesting counter-example,
though there are a fair number of other machines which had (and in the
embedded world still do have) discontinuous regions of addressable storage
and pointer arithmetic that cannot straddle region boundaries.  

The 80286 protected mode could be considered a bit more of a counter-
example, since while there is are defined logical mappings between integers
and hardware addresses, and between integers and pointer representations,
there is no fixed mapping between pointer representations and hardware
addresses.  I don't know that the 80286 protected mode was a terribly
popular platform, however.  In real mode, a program could have 64K of
quickly-addressable storage, another 512K or so of moderately-slowly
addressable storage, and an arbitrary amount of storage that could
efficiently only be fetched or stored in large blocks.  In protected mode,
a program could have 64K of quickly-addressable storage and an arbitrary
amount of storage that was sufficiently slower than the "middle" 512K of
real mode that one would want to concentrate accesses into loads and
stores of chunks into the fast 64K.  While chunks could be loaded and
stored less slowly in protected mode than in real mode, real mode could
access its 512K faster than protected mode could access anything beyond
64K.

[toc] | [prev] | [next] | [standalone]

#89549

On Sat, 18 Jun 2016 07:11:04 -0700 (PDT), supercat@casperkitty.com
wrote:
>I don't know that the 80286 protected mode was a terribly
>popular platform, however.


What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
most popular platform on the planet.

[toc] | [prev] | [next] | [standalone]

#89576

On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
> most popular platform on the planet.

I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
had a really limited 8086-compatible mode, and a somewhat usable 80286-
compatible mode, the 80386-compatible mode was where things really took
off.  Am I misremembering?

[toc] | [prev] | [next] | [standalone]

#89580

supercat@casperkitty.com wrote:
> On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
>> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
>> most popular platform on the planet.
>
> I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
> had a really limited 8086-compatible mode, and a somewhat usable 80286-
> compatible mode, the 80386-compatible mode was where things really took
> off.  Am I misremembering?
>


The Win32 API dates back to... the advent of WinNT 3.1, around '93.
An awful lot of code run on Windows, even through the '00s, was 16 bit.

Around '95 is when I started to notice the predominance of 32 bit
applications.

Win7 is the first version I saw that flat balked at real mode code and
that was in 2011.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#89585

On Saturday, June 18, 2016 at 6:49:47 PM UTC-5, Les Cargill wrote:
> The Win32 API dates back to... the advent of WinNT 3.1, around '93.
> An awful lot of code run on Windows, even through the '00s, was 16 bit.

Until Windows 3.1 came out, it was necessary for 32-bit code to use some
nasty hackery to pass objects to the 16-bit API.  If I recall, code would
pass a 32-bit pointer to a special API function that would construct a
segment descriptor for that pointer and return a segment/offset pointer,
called a "thunk", using that descriptor.  That could then be passed to
the 16-bit Windows API.  After that was done, code would need to make sure
the thunk got released.  Despite the need for cumbersome thunking
operations, the performance benefits of the 80386 linear addressing space
outweighed that cost.

Besides, even on the 80286 there is still hardware-defined relationship
between pointer and integer representations.  Unlike the 8086, the 80286
allows the relationship between logical and bus addresses to be
configured in ways which may be beyond the C programmer's control, but
reading the hardware documentation would show how logical addresses are
converted to physical addresses, and reading the OS documentation would
indicate whether it is possible to obtain logical pointers which will
correspond with physical addresses.

[toc] | [prev] | [next] | [standalone]

#89612

supercat@casperkitty.com wrote:
> On Saturday, June 18, 2016 at 6:49:47 PM UTC-5, Les Cargill wrote:
>> The Win32 API dates back to... the advent of WinNT 3.1, around '93.
>> An awful lot of code run on Windows, even through the '00s, was 16 bit.
>
> Until Windows 3.1 came out, it was necessary for 32-bit code to use some
> nasty hackery to pass objects to the 16-bit API.

Stuff like this is why I totally avoided all exposure to Windows until
3.1. I literally could not willingly suspend disbelief to deal with that.

By ...1988, I was mainly playing with 680x0 at work and no such
problems.

> If I recall, code would
> pass a 32-bit pointer to a special API function that would construct a
> segment descriptor for that pointer and return a segment/offset pointer,
> called a "thunk", using that descriptor.  That could then be passed to
> the 16-bit Windows API.  After that was done, code would need to make sure
> the thunk got released.  Despite the need for cumbersome thunking
> operations, the performance benefits of the 80386 linear addressing space
> outweighed that cost.
>

There were no "machine cycle" justifications for any of that.
"Performance" just meant you could have large(r) data objects without 
overlays and/or playing games with HIMEM  and extended/expanded memory 
drivers. Er, I vaguely recall.

> Besides, even on the 80286 there is still hardware-defined relationship
> between pointer and integer representations.  Unlike the 8086, the 80286
> allows the relationship between logical and bus addresses to be
> configured in ways which may be beyond the C programmer's control, but
> reading the hardware documentation would show how logical addresses are
> converted to physical addresses, and reading the OS documentation would
> indicate whether it is possible to obtain logical pointers which will
> correspond with physical addresses.
>

Dunno; I just ran real-mode stuff until Win3.1 and then Win95.
The majority of it was just DOS windows.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#89606

On Sat, 18 Jun 2016 18:53:07 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

>supercat@casperkitty.com wrote:
>> On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
>>> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
>>> most popular platform on the planet.
>>
>> I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
>> had a really limited 8086-compatible mode, and a somewhat usable 80286-
>> compatible mode, the 80386-compatible mode was where things really took
>> off.  Am I misremembering?
>>
>
>
>The Win32 API dates back to... the advent of WinNT 3.1, around '93.
>An awful lot of code run on Windows, even through the '00s, was 16 bit.
>
>Around '95 is when I started to notice the predominance of 32 bit
>applications.


With the advent of Win95.  Before that, except for the very limited
Win32s, there was no Win32 support except on the NT line, and the
installed base of that was tiny relative to the Win3 line.


>Win7 is the first version I saw that flat balked at real mode code and
>that was in 2011.


And then only if you installed a 64-bit version of Windows.  Windows
still supports virtual DOS machines and 16-bit p-mode in 32-bit
installs.

[toc] | [prev] | [next] | [standalone]

#89608

On 19/06/2016 06:37, Robert Wessel wrote:
> On Sat, 18 Jun 2016 18:53:07 -0500, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> supercat@casperkitty.com wrote:
>>> On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
>>>> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
>>>> most popular platform on the planet.
>>>
>>> I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
>>> had a really limited 8086-compatible mode, and a somewhat usable 80286-
>>> compatible mode, the 80386-compatible mode was where things really took
>>> off.  Am I misremembering?
>>>
>>
>>
>> The Win32 API dates back to... the advent of WinNT 3.1, around '93.
>> An awful lot of code run on Windows, even through the '00s, was 16 bit.
>>
>> Around '95 is when I started to notice the predominance of 32 bit
>> applications.
>
>
> With the advent of Win95.  Before that, except for the very limited
> Win32s, there was no Win32 support except on the NT line, and the
> installed base of that was tiny relative to the Win3 line.

With 80386 you could write more or less 32-bit applications in 16-bit 
mode (making use of 32-bit registers and with data and address width 
overrides), even if the OS might still be 16-bit.

And weren't there also ways to write full 32-bit-mode apps that ran 
under 16-bit Windows?

So there could have been more pseudo-32-bit or actual 32-bit apps around 
than people realised.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#89626

On Sun, 19 Jun 2016 11:07:42 +0100, BartC <bc@freeuk.com> wrote:

>On 19/06/2016 06:37, Robert Wessel wrote:
>> On Sat, 18 Jun 2016 18:53:07 -0500, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>> supercat@casperkitty.com wrote:
>>>> On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
>>>>> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
>>>>> most popular platform on the planet.
>>>>
>>>> I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
>>>> had a really limited 8086-compatible mode, and a somewhat usable 80286-
>>>> compatible mode, the 80386-compatible mode was where things really took
>>>> off.  Am I misremembering?
>>>>
>>>
>>>
>>> The Win32 API dates back to... the advent of WinNT 3.1, around '93.
>>> An awful lot of code run on Windows, even through the '00s, was 16 bit.
>>>
>>> Around '95 is when I started to notice the predominance of 32 bit
>>> applications.
>>
>>
>> With the advent of Win95.  Before that, except for the very limited
>> Win32s, there was no Win32 support except on the NT line, and the
>> installed base of that was tiny relative to the Win3 line.
>
>With 80386 you could write more or less 32-bit applications in 16-bit 
>mode (making use of 32-bit registers and with data and address width 
>overrides), even if the OS might still be 16-bit.


So long as you saved all your 32-bit registers before calling anyone,
including the OS.  Since Win16 apps were non-preemptive, you didn't
have to worry about the OS switching away and not saving registers
(and interrupts were handled by the 32-bit DOS extender/VM code
anyway).  But since there was little actual language support for that,
that sort of thing tended to show up in critical inner loops of
things, and coded in assembler (so that was popular with CODECs,
compression routines, etc.).

>And weren't there also ways to write full 32-bit-mode apps that ran 
>under 16-bit Windows?


The 386Enh DOS extender was DPMI compliant, so you could run other
extended DOS apps under its control, and those could be 32-bit
(AutoCAD and a number of games were good examples of that, although
those largely ignored Windows, even when running underneath it).  Or
you could put code into VxDs.  In either case, you pretty much had to
roll your own mechanism if you wanted to talk to the Windows API.

Win32s provided a way to do "normal" 32 bit Windows programs, but saw
modest, at best use.


>So there could have been more pseudo-32-bit or actual 32-bit apps around 
>than people realised.


There were some, but not many that were seriously 32-bit.  A number of
applications had a VxD tossed in for some reason or another (for
example, to provide an API to the virtual DOS boxes), while the actual
application was almost all Win16 code.

[toc] | [prev] | [next] | [standalone]

#89605

On Sat, 18 Jun 2016 16:02:46 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Saturday, June 18, 2016 at 2:41:09 PM UTC-5, robert...@yahoo.com wrote:
>> What are you smoking?  In the Win3.x days, p-mode 16-bit x86 was the
>> most popular platform on the planet.
>
>I thought Windows didn't overtake DOS until Windows 3.0, and while Win3.0
>had a really limited 8086-compatible mode, and a somewhat usable 80286-
>compatible mode, the 80386-compatible mode was where things really took
>off.  Am I misremembering?


Win3.0 real mode is best ignored, except for compatibility with
programs written for Win1 and Win2 (and it was dropped from Win3.1).

OTOH, "standard" (286) and "386 enhanced" modes were really the names
of the underlying DOS extender.  In both cases Windows proper, and any
applications, ran in a 16-bit p-mode environment.  386Enh mode largely
added paging (underneath Windows itself) as well as virtual DOS boxes
for improved DOS compatibility, and more-or-less ran Windows itself in
one of the VMs ("more-or-less" because the actual p-mode code wasn't
really in a VM like the DOS emulations underneath).

There were at least several attempts to run Windows itself in a third
party DOS extender, with limited success.

But yes, in many ways largely Windows became practical with the 386,
since 286s often lacked them memory and speed required to make Windows
useful, plus the real-mode VM support of the 386 made DOS apps
actually usable under Windows, which was a huge aid to Windows
popularity.

But other than applications specifically written to make use of some
of the underlying 386-mode DOS extender (and there were certainly
some), most Win3.x apps were purely 16-bit protected mode code, and
would run in 286 or modes.

Win3.11 dropped 286 (standard) mode, as it moved a bunch of support
(DOS and networking) code into virtual device drivers, which only ran
in 386Enh mode.  But again, that largely didn't impact any standard
applications, which remained 16-bit p-mode.

MS introduced Win32s, as a subset of the Win32 API, which would work
on some versions of Win3 (certainly Win3.11, perhaps Win3.1 in 386Enh
mode - memories grow dim), which was implemented as a set of VxDs and
an extension to the program loader.  It was little used, but did
permit some "normal" 32-bit application programming.  Writing code in
VxDs was always possible, but again, that tended to be more system
stuff, not normal applications (not exclusively, of course).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web