On 11/05/15 10:23, Martin Brown wrote:
On 10/05/2015 20:40, John Rumm wrote:
On 08/05/2015 13:19, Martin Brown wrote:
On 08/05/2015 11:19, John Rumm wrote:

Or in the case of TP too closely integrated with a particular version of
Explorer. ISTR that TP5 will run OK on Win7 x64 with a bit of fiddling
but that the later TP6 will not due to its "improvements".

I abandoned TP in favour of TB on moving to Win7 x64.

There were some really bad apps that didn't work as they asked how
much
disk/ram was there and thought the answer was negative once they got
big
enough.

They are not bad apps, they just use a deprecated API call to get the
information. Alas the API designers did not have the foresight to
allocate large enough return parameters.

Not the first time it has happened either.

It also highlights why Charles Simonyi's insistence on using Hungarian
Notation[1] for all the formal parameter names in the Win16 API was a
daft idea - win32 is still lumbered with LParam and WParam where the W
version is 32 bit, and even the Win64 API has them and they are both 64
bit!

[1] Never a good system IMHO, and only plausibly justified in the days
of K&R style C compilers with untyped formal function parameters and lax
type checking.

Couldn't agree more. I had some terrible times interfacing strongly
typed Modula2 and Pascal related languages to OS/2 PM and Win95 APIs.

The world might have been a much better place if the early CPU address
space had been too big to fit into an integer so that C could not use
integers and pointers quite so interchangeably.


Good grief. You don't understand anything about computer hardware do you?

If you are going to use a register to contain a value that might be a
memory content or a memory address you are screwed from the start
irrespective of the length of either or both.

If you are going to allow registers that corresponding to memory
addresses to be incremented. decremented or have arbitrary offsets
addressed to them, so you can index tables, you already have te hardware
potential for malfeasance.

If you are going to use the stack to contain data as well as return
addresses, you al;ready have the potential for using data to alter
program flow.

This is all in the architecture of the hardware, not in the language.
And if you remove it from the hardware then you have a very inefficient
computer.








We still live with the results with rampant buffer overrun attacks and
other tricks that rely on cryptic micromanaged insecure but fast coding.



--
Everything you read in newspapers is absolutely true, except for the
rare story of which you happen to have first-hand knowledge. €“ Erwin Knoll