Hi folks,
due to my very limited C(pp) knowledge I would like to know how to translate :
typedef DWORD PCTXHF;
typedef PCTXHF far * PPCTXHF;

into D.
Unfortunately HtoD seems to have some problems with : far *

Björn

*-----------------------------------------------------------------------------------------------------------*/
/* Interface avec la dll HyperFile  */
/*-----------------------------------------------------------------------------------------------------------*/
#ifndef __WDHF_H
#define __WDHF_H

#if !defined(_INC_WINDOWS) && !defined(__WINDOWS_H)
#include <windows.h>
#endif
//
typedef DWORD PCTXHF;  /*numйro d'instance*/
typedef PCTXHF far * PPCTXHF;
//THIS !!!!
-------------


#define HFCTX_NULL (PCTXHF)NULL
    						
#ifdef __cplusplus
extern "C" {
#endif

== Quote from BLS (nanali@wanadoo.fr)'s article
> Hi folks,
> due to my very limited C(pp) knowledge I would like to know how to
> translate :
> typedef DWORD PCTXHF;
> typedef PCTXHF far * PPCTXHF;
> into D.
> Unfortunately HtoD seems to have some problems with : far *

Far is an old hack (part of the standard but ugly as watever) to allow a 16 bit computer to access a 32bit address space without wasting lots of time. What was done is to use a 16bit "section" address for the upper half of the address. then all htta is need is a 16bit pointer for the lower half. This is called a near pointer and avoids the need to load the whole thing each time. A far pointer use when that isn't good enough. It is just a full 32bit pointer.

You should be able to ignore it. If you find a near pointer... you will have problems.

BCS wrote:
<snip>
> Far is an old hack (part of the standard but ugly as watever) to allow a 16 bit
> computer to access a 32bit address space without wasting lots of time. What was
> done is to use a 16bit "section" address for the upper half of the address. then
> all htta is need is a 16bit pointer for the lower half. This is called a near
> pointer and avoids the need to load the whole thing each time. A far pointer use
> when that isn't good enough. It is just a full 32bit pointer.
> 
> You should be able to ignore it. If you find a near pointer... you will have problems.

If finding a near pointer is a problem, then the API isn't 32-bit compatible.

Under a 32-bit system, there's no such distinction as that between near and far pointers.  C(++) compilers may accept "near" and "far" in 32-bit mode, but this is purely for backward compatibility with 16-bit code. You'll find that both are treated as 32-bit pointers just the same.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

On Sat, 09 Sep 2006 23:40:47 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:

>BCS wrote:
><snip>
>> Far is an old hack (part of the standard but ugly as watever) to allow a 16 bit computer to access a 32bit address space without wasting lots of time.

>Under a 32-bit system, there's no such distinction as that between near and far pointers.

Being extremely pedantic, I think it's possible to compile for a memory model with far pointers that are bigger than 32-bit. Even 32 bit processors could have >4GB memory.

Very unlikely, though, at least for applications - apps don't see the physical address space these days.

-- 
Remove 'wants' and 'nospam' from e-mail.

Steve Horne wrote:
> On Sat, 09 Sep 2006 23:40:47 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> 
>> BCS wrote:
>> <snip>
>>> Far is an old hack (part of the standard but ugly as watever) to allow a 16 bit computer to access a 32bit address space without wasting lots of time.
>> 
>> Under a 32-bit system, there's no such distinction as that between near and far pointers.
> 
> Being extremely pedantic, I think it's possible to compile for a memory model with far pointers that are bigger than 32-bit.

Do such compilers/languages actually call it "far"?  Could be confusing....

Interesting facts: The ZX Spectrum (16K/48K models at least) was an
8-bit machine with a flat 16-bit address space.  16-bit on PCs relies on
both 16-bit (near) and 32-bit (far) memory addresses.  32-bit systems
have a flat 32-bit address space.

If the pattern had continued, then 64-bit systems would have both 32-bit and 64-bit pointers.  (OK, so if they're going to still be able to run 32-bit apps....)

> Even 32 bit processors could have >4GB memory.
<snip>

I'd be surprised to see more than 4GB on the _processor_....

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

== Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
> 32-bit apps....)
> > Even 32 bit processors could have >4GB memory.
> <snip>
> I'd be surprised to see more than 4GB on the _processor_....
> Stewart.

FWIW
modern 32bit CPUs can address more than 4GB of memeory. I would expect only OS
code would need to do this.

http://www.quepublishing.com/articles/article.asp?p=481859&seqNum=17&rl=1

about a 1/4 of the way down it says that the P2's address space is 64GB (36bit
addressing)

On Sun, 10 Sep 2006 13:34:45 +0100, Stewart Gordon <smjg_1998@yahoo.com> wrote:

>> Being extremely pedantic, I think it's possible to compile for a memory model with far pointers that are bigger than 32-bit.
>
>Do such compilers/languages actually call it "far"?  Could be confusing....

Dunno. Never done it. May be completely wrong about it - just an idea I picked up somewhere.

>Interesting facts: The ZX Spectrum (16K/48K models at least) was an 8-bit machine with a flat 16-bit address space.

Yeah - same on most 8 bit chips. I had a Commodore myself ;-)

>  16-bit on PCs relies on
>both 16-bit (near) and 32-bit (far) memory addresses.

Pedantism two : A far pointer may have been 32 bits wide, but it only addressed a 20 bit address space.

The 68000 was a 16 bit chip that addressed 24 bits. But then, in some ways it was a 32 bit chip. 32 bit registers, mainly, including address registers. When a later 68000-series chip supported a 32 bit address bus, it didn't need any change to the registers or instruction set.

In fact, just what defines the 8/16/32/64 bittiness of a chip? Register width? Data bus width? Address bus width? Width of a chunk of an instruction?

In some ways, the original Pentium was a 64 bit chip. 64 bit registers, 64 bit data bus IIRC. Could MMX instructions process 128 bits of data at a time in the earliest Pentium MMX chips? SSIMD/3DNow instructions certainly handle 128 bits (4 floats) at a time, and have done for some time.

These days, the data bus is already much wider than 64 bits. Nothing to do with what an instruction can process at once, just shifting cache pages in and out as quick as possible.

Yet in terms of the width of a chunk of an instruction, the current 64 bit desktop CPUs are still 8 bit chips. Instruction opcodes that worked on the original 8086 and 8088 about 20 years ago still work now, and the 8086 was criticised for not really being 16 bit when it was released because of the 8-bit instruction coding.

So you could argue that your average P4-generation chip is 8 bit, or 128 bit, or maybe more based on the data bus.

Not to disrespect 64 bit, mind you. It's not just meaningless marketing. Nothing like the Intel marketing claiming that dual cores are necessary just to run a web browser and listen to music at the same time (how many times have we been sold multitasking so far? DOS TSRs, nonpreemptive, preemptive, separate address spaces, multiprocessor support, and how many meanings did I miss?)

Just seems a bit daft.

>> Even 32 bit processors could have >4GB memory.
><snip>
>
>I'd be surprised to see more than 4GB on the _processor_....

LOL!

But then again, in ten years or so...

-- 
Remove 'wants' and 'nospam' from e-mail.