Re: API declarations and 64-bit C/C++ code portability

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Fri, 7 Oct 2005 08:36:00 +1000, "Leslie Milburn"
<CDB4W@xxxxxxxxxxxxxxxxxx> wrote:

>"Bob Hairgrove" <invalid@xxxxxxxxxxx> wrote in message
>news:ldpak155htngcqhrnhvn9re3da4bqugrfi@xxxxxxxxxx
>
>> However, I still wonder how we should write our API code ... should we
>> replace "int" and "long" everywhere with these typedefs in case we get
>> 128-bit Windows some day?? I'm not sure that I can sleep any better
>> now than before!
>
>Hi Bob,
>
>What you say is correct. A short and a long are by definition the natural
>small and larger sizes for the specific hardware. An int can be either a
>short or a long depending upon the compiler and it *was* usually the most
>efficient implementation. We totally eliminated the use of int (back in
>1988) because you do not know for sure going forward what size it really is
>!!

Hi Leslie,

That's a nice choice of words: "going forward"! OTOH, when writing any
kind of code, for whatever platform, I think "looking backward" is
perhaps even more important.

>So, after the pain of going from the 16 bit to the 32 bit world we created
>our own #defines which we now use. Basically, I would *not* rely upon the
>Microsoft defines if I could help it.

OK, you've got your own #defines ... but if the Windows API changes
and breaks your #defines, you have no choice but to change as well if
you want to continue to support that platform. The big problem with
this philosophy, which I also endorsed until recently, is that one is
always forced to "second-guess" whatever the prevailing wind from
Redmond might dictate. However, M$ (...ahem...) is not immune to the
forces of the marketplace. Witness their sudden -- and successful! --
efforts to make their C/C++ compiler more ANSI standards-compliant...

>As an aside....
>I am laughing at whoever decided INT_PTR and DWORD_PTR - IMO, its become one
>big joke (where are these programmers getting this stuff from?). Why
>couldn't they have used normal sounding defines like 16INT, 32INT and 64INT.

Well, one reason might be that identifiers must begin with a non-digit
character. Their present solution (i.e. INT32, INT64 etc.) is a step
in the right direction. However, they haven't outright changed thir
API header files yet, so there are lots of functions out there which
depend on certain assumptions (such as sizeof(int)==sizeof(long))
which just aren't supported by the standard (and presumably never will
be).

As I see it, the "paradigm" back in the 1980's was not far-reaching
enough. To be honest, nobody, at least none of the code hackers,
thought they would live long enough to see 64-bit Windows back then,
or they thought they would be well into retirement by then ... And
since languages like C++ were so young, the powers that be thought
that they could dictate the path the language standard would take
solely by strength of market.

Well, there came to be "open source" and "Linux" ... two things that
they really don't want to hear anywhere close to Redmond!

>Gee, its just like the hungarian "goulash" notation they insist on using -
>might have been a good idea at the time (we never liked it or used it) but
>its also become a joke - just take LPSTR for example. a Long Pointer ??
>Should we now change everything to LLPSTR (or should that be PTR_PTRSTR) for
>64 bit pointers, I don't think so - what a joke.

If you take into consideration the lack of standards-compliance that
even the in-house compilers had at that time, it might not seem so
funny. Today, seeing declarations like "typedef struct _tagXYZ {
/*...*/ } XYZ, FAR * LPXYZ;" is pretty hilarious indeed (what is a
"FAR *", for example?).

--
Bob Hairgrove
NoSpamPlease@xxxxxxxx
.

Relevant Pages

  • Re: Automatically generate variables
    ... Must be C by your definition since crapit might possibly be a header that makes it C. ... I knew it was *the* windows windows.h header because the ... Given certain assumptions the C code was valid C code, however from what I remember it certainly was not a C program solving the problem since it not only relied on non-C APIs but also relied on external programs that in general are *not* installed on machine. ... You, on the other hand, just said that it might be C even if it goes beyond what the standard defined and gave no outer limit on what could be considered C. ...
    (comp.lang.c)
  • Re: V6 Suggestion
    ... Almost no VM is reflexive if that is what you mean, and Dolphin also has the compiler "outside" of the living smalltalk, as many low level behaviour which uses standard windows API, for performance and Windows coupling, I guess. ...
    (comp.lang.smalltalk.dolphin)
  • Re: High USB throughput requirement
    ... undocumented API). ... Standard timers would not work faster than about 50 ms, IIRC, ... 18.2Hz interval interrupt event that Windows used. ... simply reprogram the timer chip to provide ...
    (comp.arch.embedded)
  • Re: up with PyGUI!
    ... >> If PyGUI will have native widgets for Windows as it does for Mac, ... >> it becomes standard. ... Its API seemed cleaner than wxPython's (and with ...
    (comp.lang.python)
  • Re: newbe about API
    ... Emne: Re: newbe about API ... > I found all these API-CALL strings are finally compiled to ... more than that...and Windows simply takes this to an extreme that this ... DLL, when a weak point is found (which, with Microsoft, is something ...
    (alt.lang.asm)