What the h**l is difference between LONG pointer, and short pointer? Is long pointer 64 bits and pointer 32? Or 32 and 16 respectively? Is this only because Pentiums handle 32 bits at a time faster than say 8 bits? And in the future processors will be using some kinda 64 bit architecture? I''m confused...

J2xC (J. Connolly)

"Then study this: Borg provokes Klingon, Klingon breaks Borg's nose" Belanna Torres, Star Trek Voyager 5.11 "Someone to watch over me"

The reason to use LPSTR instead of PSTR? Because that is how Microsoft defines it. Really, what would happen to your code if Microsoft changes the definitions of those? You''d have to go back through your code and change all the references you made just to keep your code from dying. It might compile just fine right now. But, in the future it might not.
As an aside, that was the reason that MS decided to have the sizeof included in almost all of their structures. It''s a way to check on the version that you are using so that the API can call the correct version (win16, win32s, win32, win64, ...). It''s a waste to include it in a structure just to include it. But, as an error check or version check it makes some sense unless two different versions use the same size structure.

-MartinJ

quote:

---

Original post by J2xC

What the h**l is difference between LONG pointer, and short pointer? Is long pointer 64 bits and pointer 32? Or 32 and 16 respectively? Is this only because Pentiums handle 32 bits at a time faster than say 8 bits? And in the future processors will be using some kinda 64 bit architecture? I''m confused...

---

Well, not exactly. The processor (as far as I know) can handle 32-bits just as fast as any data type. There is no longer - and never will be - such a thing as a long pointer. It used to be that you would have far pointers (which mean the same thing as long pointers). As for someone''s claim that 64-bit Windows may need this again, it will not. 64-bit processes will use *only* 64-bit pointers and 32-bit processes will use the 4 GB address space and therefore 32-bit pointers. Nobody will mess with segments anymore.

quote:

---

Original post by MartinJ

The reason to use LPSTR instead of PSTR? Because that is how Microsoft defines it. Really, what would happen to your code if Microsoft changes the definitions of those? You''d have to go back through your code and change all the references you made just to keep your code from dying. It might compile just fine right now. But, in the future it might not.
As an aside, that was the reason that MS decided to have the sizeof included in almost all of their structures. It''s a way to check on the version that you are using so that the API can call the correct version (win16, win32s, win32, win64, ...). It''s a waste to include it in a structure just to include it. But, as an error check or version check it makes some sense unless two different versions use the same size structure.

---

I think Jeffrey Richter knows what he told me. Would you like to email him and ask him? His book avoids LPs and lpPtrs like the plague.

http://www.jeffreyrichter.com/

I don''t think Charles Petzold (my direct source) would tell me that LP is a waste if it wasn''t.

That was my post. I keep forgetting to type my name in because of the other UBB board I use. :o

P.S: I don''t think Microsoft would have any reason to include the PSTR data type and all of a sudden decide to reintroduce long pointers without solving the compatibility issue.

I know, I''m quite hoary. But this deserves to be brought up again.

Geez man, let it rest....