wininet.h to PB

[Bisonte]

Hi.

Resulting in a size of delusional (<- Google Translate)
i tried to convert the wininet.h to pb as resident.

But : Some of our "API Gurus" have a look to the structures, because my skill to
translate the correct datatypes in the structures is weak...

In the zip-archiv is the source and a resident file (PB5.1x86 Final)

download wininet.h to pb

[luis]

Hi, the first thing I notice is you replaced some (but not all ?) LPTSTR occurrences with PB strings (.s)

LPTSTR are pointers so you could simply to remove the .s

BTW: when you have doubts you can look at the stupid msft type redefinitions on msdn to see how they are defined. 90% of the time they are some kind of number (word, long, int)

[Shield]

BTW: when you have doubts you can look at the stupid msft type redefinitions on msdn to see how they are defined. 90% of the time they are some kind of number (word, long, int)

I wouldn't call it stupid. It makes a lot of sense to redefine types to avoid problems
when compiling on different systems / architectures (also for 32 / 64 compatibility).
However I do agree sometimes they overdid it.

@Bisonte:
You should be careful with ".l" types. Most of them should be ".i" I guess.

[luis]

It's only my opinion obviously. I call it stupid because the original idea had his merits, to instantly recognize that an anonymous "long" is very particular type of long, an HANDLE for example, and *much later* for portability as you suggested. But all that is lost now under a myriad of redefinitions often of the same thing, and what it should be a simply recognizable integer or a pointer is now VERYLONGANDVERYFAR_PTR_LONG_LONG_INT_EXTRA_V2_WIDE.
Now instead of helping it requires an interpreter, as testified by all the errors people commit when translating them.

[Bisonte]

@Shield: hm DWORD are two words, so its a LONG in PB. I checked it with other predefined structures at the structureviewer in pb-ide.
@Luis: I thought that a Blabla.s in a structure is only a pointer to a string in memory , like LPSTR ...

Thats why I said : Someone with more skill have to check it

[Shield]

Yes, but the original size definition of "word" goes back to older times. A word is the natural unit of a processor,
so on 32 Bit systems a "word" is PB's long whereas on 64bit systems a "word" is actually PB's quad (64 bit).

Microsoft (and most others apparently) decided to keep the old definitions.

[Bisonte]

Yes, but the original size definition of "word" goes back to older times. A word is the natural unit of a processor,
so on 32 Bit systems a "word" is PB's long whereas on 64bit systems a "word" is actually PB's quad (64 bit).

Microsoft (and most others apparently) decided to keep the old definitions.

But if I changed .l to .i at DWORD entries, the size of structure is not the same on x86 and x64...

[Shield]

Why is that a requirement? That's usually how it should be.
But of course it depends on the structure itself. It's really not always easy to convert types from C.
So I can't say for sure what's correct in this case.

[Danilo]

int/long and unsigned int/long (and DWORD) are 32bit on Win x86 and Win x64, so PureBasic's .l is correct in structures.

Even WinAPI function calls use (unsigned) int/long (or macros like DWORD) most of the time, so they use 32bit.
The difference is that function arguments are widened to 64bit anyway in 64bit mode, giving arguments as
64bit types on stack and in registers to the functions. In structures no widening happens, so size must be correct.

With PB5.10 you should/could use: "Structure name Align #PB_Structure_AlignC"

Of course structure sizes may be different with PB32 and PB64:

Code: Select all

Structure theStructure Align #PB_Structure_AlignC
    theLong.l
    *thePointer
EndStructure

Debug SizeOf(theStructure)
Debug OffsetOf(theStructure\theLong)
Debug OffsetOf(theStructure\thePointer)