[RESOLVED] Why do you still use datatype Long for pointers?

[OlimilO]

Why do some of you still use the datatype Long for dealing with pointers? Imho using datatype Long for pointers should've been abandoned many years ago.

it is not hard, in fact it is so easy, what is your excuse?
Search your winapi-declarations, go to every variable name, look if the name starts with "p*" or handles starting with "h*" and replace datatype "Long" with "LongPtr"
And you are good to go, your VB6 code becomes instantly ready for x64, ready for twinBasic, ready for Excel VBAx64 as well
@TheTrick suggestion for your code in 32Bit handling with 64Bit pointers

Public Type LongPtr64
    Value As Currency
End Type

Further reading for people who don't know what I am talking about
https://github.com/OlimilO1402/XL_VBanywhere

[baka]

running 32bit, the best and fastest datatype is still and will ever be LONG, as its 4 bytes equivalent to 32 bits.
also, even if we move to twinbasic and 64bit, theres no need for LongLong if u dont use that range.
its like saying that we should not use byte, integer, boolean and only LONG in 32bit.
datatype should be chosen from requirement not because of running bits.

[fafalone]

In 32bit LongPtr is still a Long so you're not using a different size. You wouldn't actually use "LongPtr64" outside of uses like accessing 64bit memory from 32bit as a hack because you can't/won't compile to native 64bit.

But in 64bit VBA/tB you absolutely do have to use LongLong (what LongPtr is aliased to) or everything expecting it crashes. You can't just keep your APIs the same Long if it's a handle/pointer because it's going to read 8 bytes and get corrupted.

So there's no drawbacks in 32bit and it's mandatory for 64bit; definitely agree it's now very poor practice to not write new code as provisioned for 64bit even if you're not moving immediately. Though OP has understated the difficulty with APIs... it's not extremely difficult but there's lots of edge cases, didn't mention size_t, there's UDT alignment issues you encounter far more frequently... you should just take them from WinDevLib; even for vb6 it's easier to drop the tB syntax (often just the PtrSafe keyword) than rewrite from C yourself.

[OlimilO]

running 32bit, the best and fastest datatype is still and will ever be LONG, as its 4 bytes equivalent to 32 bits.
also, even if we move to twinbasic and 64bit, theres no need for LongLong if u dont use that range.
its like saying that we should not use byte, integer, boolean and only LONG in 32bit.
datatype should be chosen from requirement not because of running bits.

You clearly didn't know what I was talking about. So please read the tutorial

[OlimilO]

definitely agree it's now very poor practice to not write new code as provisioned for 64bit even if you're not moving immediately.

In your closed sources you can do whatever you want to do. leave the code as it is, it's always up to you, it's in your own resposibility, nobody can do antything about it anyway.
But in the moment when you post something publicy either here in the forum or in GitHub you make yourself guilty for releasing buggy code into the wild.

[gilman]

You clearly didn't know what I was talking about. So please read the tutorial

I think there are two different problems:
1. Accessing 64-bits pointers in a 32-bit application, which is what theTrick is addressing in thread [vb6] Read pointer from a x64 process.

2. Creating applications that are compatible with both 32-bit and 64-bit architectures.

In case 1, which I believe is the reason for this new thread, it doesn't make sense to use the LongPtr enumeration, since it will remain 32-bit and won't be able to obtain the 64-bit value. An alternative to theTrick's solution, as proposed by Fafalone, is to switch to TwinBasic and compile in 64-bit.

[OlimilO]

I think there are two different problems:
1. Accessing 64-bits pointers in a 32-bit application, which is what theTrick is addressing in thread [vb6] Read pointer from a x64 process.
2. Creating applications that are compatible with both 32-bit and 64-bit architectures.
In case 1, which I believe is the reason for this new thread, it doesn't make sense to use the LongPtr enumeration, since it will remain 32-bit and won't be able to obtain the 64-bit value. An alternative to theTrick's solution, as proposed by Fafalone, is to switch to TwinBasic and compile in 64-bit.

Well - moreover what I am trying to say is: be expressive in what you want to achieve.
If you want to deal with pointers use the proper datatype, it is as simple as that! In our case we have the datatype LongPtr in VBA since 2007.
Could you consider a person who writes C or C++ and using datatype long or int for pointers, though it is possible? And what are we doing in VB6? We are still using datatype Long for pointers - ***

[gilman]

Well - moreover what I am trying to say is: be expressive in what you want to achieve.
If you want to deal with pointers use the proper datatype, it is as simple as that! In our case we have the datatype LongPtr in VBA since 2007.
Could you consider a person who writes C or C++ and using datatype long or int for pointers, though it is possible? And what are we doing in VB6? We are still using datatype Long for pointers - ***

Why use Long for pointers en VB6? The answer is very simple, there's no other type, if you have a specific prolem, like in the other thread, and you want to get 64-bits info you must use especific type, and Currency is 64-bits type, you also can create a Type LongLong.

But pointers in VB6 must be Long, if you are writing code and want to be compatible with 64-bits, yes you can use LongPtr Enum

[OlimilO]

In case 1, which I believe is the reason for this new thread, it doesn't make sense to use the LongPtr enumeration, since it will remain 32-bit and won't be able to obtain the 64-bit value. An alternative to theTrick's solution, as proposed by Fafalone, is to switch to TwinBasic and compile in 64-bit.

The reason for this new thread is partially the solution posted by theTrick that's true. Of course It does make sense to use datatype LongPtr and that is the reason why I suggest to use a second datatype for a 64bit pointer "LongPtr64" because this code only makes sense in a 32-Bit environment. There is no usage for a second datatype for a pointer anywhere else.

[wqweto]

In your closed sources you can do whatever you want to do. leave the code as it is, it's always up to you, it's in your own resposibility, nobody can do antything about it anyway.
But in the moment when you post something publicy either here in the forum or in GitHub you make yourself guilty for releasing buggy code into the wild.

That's as arrogant as it can get. If you don't like any "buggy" open-source code you can just not use it -- as simple as this.

Your call to start using LongPtr in VB6 is as delusional as it can get and I would argue it gives false sense of code being 64-bit ready when it is far from it. What happens is that you have code sprinkled with LongPtr's but which is *never* compiled under x64 so the moment you try to migrate to TB one suddenly finds that using LongPtr is not enough and there are all sorts of other issues under x64 -- even if the code compiles it later bombs ferociously at run-time which is worse.

A most common omission is when a local variable is declared as Long but is used both as a pointer and as 32-bit parameter so this cannot be easily converted to LongPtr and call it a day. Some common sense is requred on a case by case basis.

Also, VBA with its PtrSafe declares is completely useless -- VB6 devs are never going to port to x64 VBA but only to TB which supports declares without PtrSafe but with proper LongPtr both in 32 and 64-bit.

cheers,
</wqw>

[OlimilO]

That's as arrogant as it can get

If you really think about it, it is completely the other way around, not using the right datatype is as arrogant as it can get

[fafalone]

That's as arrogant as it can get. If you don't like any "buggy" open-source code you can just not use it -- as simple as this.

Your call to start using LongPtr in VB6 is as delusional as it can get and I would argue it gives false sense of code being 64-bit ready when it is far from it. What happens is that you have code sprinkled with LongPtr's but which is *never* compiled under x64 so the moment you try to migrate to TB one suddenly finds that using LongPtr is not enough and there are all sorts of other issues under x64 -- even if the code compiles it later bombs ferociously at run-time which is worse.

A most common omission is when a local variable is declared as Long but is used both as a pointer and as 32-bit parameter so this cannot be easily converted to LongPtr and call it a day. Some common sense is requred on a case by case basis.

Also, VBA with its PtrSafe declares is completely useless -- VB6 devs are never going to port to x64 VBA but only to TB which supports declares without PtrSafe but with proper LongPtr both in 32 and 64-bit.

cheers,
</wqw>

Provisioning code for the move to x64 is "delusional"?? *You* asked for the PtrSafe requirement to be dropped specifically so you could continue to work in VB6 with x64 compatible code without needing to use conditional compilation (and this is a liability for "gives false sense of code being 64-bit ready when it is far from it" -- you lose the immediate readout of APIs you have not updated, though you can avoid this by using what I consider a better path, remove your defs entirely and let WDL handle it) .

Obviously you can't just go around blindly changing every Long to LongPtr but it's utterly ridiculous to suggest it's delusional to start writing compatible code. Even if you miss one here and there it's still getting a lot of the work done. It makes absolutely zero sense to deliberately write incompatible code just to have to redo 100% of it instead of whatever smaller percent you missed or messed up. Is that what you do, in the projects you're still working on in VB6 with the requested PtrSafe-free declares; write your code with Long then only once you're back in tB, go back and redo with LongPtr? Makes no sense if true.

[Elroy]

To me, OlimilO is operating under the delusion that Microsoft will someday release a 64 bit verions of VB6, which, the rest of us know, is clearly never going to happen.

I will agree that the LongPtr type is nice within the VBA. But, as wqweto has pointed out, even there, porting to 64 bit VBA is MUCH more involved that just changing all the pointers from Long to LongPtr. Next, OlimilO will be getting all upset with us because we don't embed the 64 bit API calls within our VB6 application as #IF conditional compilation statements.

I will agree that using some kind of "p" Hungarian notation is nice when we actually have a pointer. But even that is a personal preference.

When considering VB6 and VBA jointly, 99% of the time, I'm porting VBA code to VB6, not the reverse. So, using Long for pointers makes perfect sense to me, and anything else is someone tilting at windmills trying to dictatorially impose their 'brand' of coding on the rest of the world.

[fafalone]

To me, OlimilO is operating under the delusion that Microsoft will someday release a 64 bit verions of VB6, which, the rest of us know, is clearly never going to happen.

I will agree that the LongPtr type is nice within the VBA. But, as wqweto has pointed out, even there, porting to 64 bit VBA is MUCH more involved that just changing all the pointers from Long to LongPtr. Next, OlimilO will be getting all upset with us because we don't embed the 64 bit API calls within our VB6 application as #IF conditional compilation statements.

I will agree that using some kind of "p" Hungarian notation is nice when we actually have a pointer. But even that is a personal preference.

When considering VB6 and VBA jointly, 99% of the time, I'm porting VBA code to VB6, not the reverse. So, using Long for pointers makes perfect sense to me, and anything else is someone tilting at windmills trying to dictatorially impose their 'brand' of coding on the rest of the world.

To me this sounds like you think tB will *never* be a viable replacement. Obviously there's not going to be a 64bit VB6, but the code tB can't handle is small and getting smaller all the time. It's a real, serious path forward that can already compile properly updated VB6 code to 64bit in many cases.

And you obviously don't *have to* ever move to 64bit, even if you migrate to tB since it supports 32bit just fine, but suggesting preparing for it isn't a valid subject for best practices isn't right either. It's about as "dictatorial" as when people say avoid GoTo, declare your variables, use Unicode versions of APIs. It's not forcing it on anyone just establishing best practices for maintainability and upgradeability. You don't want to support Unicode because nobody needs it right this second; fine that's your preference, but it's still bad practice to not just use the W API.

Also it does materially matter. Microsoft has already barred 32bit apps from calling certain APIs; do we think that list will get shorter instead of longer in the future? That they'll never do other things that make it harder on 32bit apps like introduce new features that only have x64 versions? There's what, *maybe* one or two other VB6 people on earth that can write the kind of code The trick can to access 64bit memory, if they even wanted to avoid tB that bad? It makes no sense to not just take the extra 3 keystrokes to use LongPtr; it's not as trivial as OlimiO suggests but nor is it some major architectural change that is too complicated for 99% of VB6 programmers.

[Elroy]

Hi Fafalone,

Yeah, I really don't want to speak ill of tB, and think it's a fantastic endeavor. I must also admit that I still haven't looked at it. I suppose, just to put it out there, my biggest concern about tB is that it isn't open-source. Also, last time I looked, he wanted a subscription to use it, which I'm just not willing to do. But again, I genuinely applaud the endeavor.

IDK, I could say more, trying to bring it back to a discussion of LongPtr, and make several additional points, but I think I'll just leave it at that.

This whole thread just has a vibe of people wanting to argue because their bored, and that's what they do when they're bored.

Fafalone, you take care,
Elroy

[fafalone]

Hi Fafalone,

Yeah, I really don't want to speak ill of tB, and think it's a fantastic endeavor. I must also admit that I still haven't looked at it. I suppose, just to put it out there, my biggest concern about tB is that it isn't open-source. Also, last time I looked, he wanted a subscription to use it, which I'm just not willing to do. But again, I genuinely applaud the endeavor.

IDK, I could say more, trying to bring it back to a discussion of LongPtr, and make several additional points, but I think I'll just leave it at that.

This whole thread just has a vibe of people wanting to argue because their bored, and that's what they do when they're bored.

Fafalone, you take care,
Elroy

VB6 isn't open source either; I'd prefer it for tB go open source too but it's a lateral move in that regard-- and actually should be better, as Wayne has said he'll put the source in escrow once it hits 1.0, so the community gets it in case of his death or disappearance. It's generally by subscription but there's been several offers for perpetual licenses and a lot of people have them now.

As tB becomes better, there will be less and less of a good reason to stay with VB6, since 32 vs 64 aside, someday MS *will* drop support for msvbvm60... I'd be surprised if it's not sunset like VBScript once Win12 hits. So even if the endless list of new language features and modernizations isn't compelling, there might eventually be little choice if you don't want to do a complete trashing-and-rewriting in a completely different language.

[OlimilO]

To me, OlimilO is operating under the delusion that Microsoft will someday release a 64 bit verions of VB6, which, the rest of us know, is clearly never going to happen.

Am I missing something? who is talking about "M$ bringing up something"? At least not me. Though we do have VBA-x64 as you know it is made by Microsoft. Nowadays there is twinBasic a perfect contender to VB6, do you expect more?
I must confess many years ago I was planning to write my own "VB-compiler-c-translater" but since twinBasic is making great strides . . .

... porting to 64 bit VBA is MUCH more involved that just changing all the pointers from Long to LongPtr.

Nope it is not! If you would only try it, you would see that it is in fact more easy than it looks.
But OK I must confess, it takes practice to get the hang of it

Next, OlimilO will be getting all upset with us because we don't embed the 64 bit API calls within our VB6 application as #IF conditional compilation statements.

Just read the tutorial, in fact I say that you don't have to use so much "#IF" statements, in fact you can get rid of so much #IF statements

I will agree that using some kind of "p" Hungarian notation is nice when we actually have a pointer. But even that is a personal preference.

I am not talking about personal preference. I was talking about the names of function parameters in the winapi-functions. This names are provided by microsoft, no personal preference there.
But I am glad you bring this up, whenever you see a parameter name beginning with "lp*" this means "LongPtr" often used for string-parameters.

When considering VB6 and VBA jointly, 99% of the time, I'm porting VBA code to VB6, not the reverse.

Yeah I don't know any of your business. But could it be, that the reason for this is, because the code does not run in VBAx64 because someone used Long instead of LongPtr?

So, using Long for pointers makes perfect sense to me, and anything else is someone tilting at windmills trying to dictatorially impose their 'brand' of coding on the rest of the world.

Come on, now you are getting pathetic

[fafalone]

Nope it is not! If you would only try it, you would see that it is in fact more easy than it looks.
But OK I must confess, it takes practice to get the hang of it

.

Well for once thing, what if you see pdwFlags... starts with a p, but you wouldn't change it to LongPtr if you were using ByRef. Most but not all handles are to be changed. SIZE_T must be changed. Some people user hardcoded pointer sizes and offsets of 4, that has to be changed. Sometimes there's a conditional compilation directive like #If Win64 then #include <pshpack4.h> like with some comctl defs that means you'd want to add a PackingAlignment attribute for tB. Union substitutions are a much more complicated and difficult issue.

So it is harder than you're suggesting. Which again is why you should just use WDL. I've spent a huge amount of time learning all the edge cases, carefully porting from C originals, and constantly reviewing for bugs. And WDL isn't like any VB6 WinAPI set; coverage is far, far more extensive so you're unlikely to ever run into something that hasn't been covered.

[OlimilO]

Well for once thing, what if you see pdwFlags... starts with a p, but you wouldn't change it to LongPtr if you were using ByRef.

good point, makes sense, either you use

ByVal pFlags As LongPtr

or you use

ByRef Flags As Long

it is up to you, just decide what you want
OK this is maybe just an example, but I must say Flags are more likely to be declared as "ByVal" as to be readonly.
If the winapi-function wants to write some flags of course it must be ByRef
but in that case I would suggest to rename the variable to

ByRef Flags_out As Long

just to be declarative and nameing it as an [out]-parameter

Most but not all handles are to be changed. SIZE_T must be changed. Some people user hardcoded pointer sizes and offsets of 4, that has to be changed.

good point, makes sense
have a look into MPtr.bas

#If win64 Then
    Public Const SizeOf_LongPtr As Long = 8
    Public Const SizeOf_Variant As Long = 20
#Else
    Public Const SizeOf_LongPtr As Long = 4
    Public Const SizeOf_Variant As Long = 16
#End If

Sometimes there's a conditional compilation directive like #If Win64 then #include <pshpack4.h> like with some comctl defs that means you'd want to add a PackingAlignment attribute for tB.

you mean PackagingAlignment of some sort of structs resp variables in structs/udtypes - yeah it is not impossible e.g. as you maybe know, you can use different struct-packaging in a tlb/typelibrary or use some other tricks in pure VB

Union substitutions are a much more complicated and difficult issue.
So it is harder than you're suggesting.

And this is a reason for what, we VB6-developers are no wimps at all, are we

Which again is why you should just use WDL.

"WDL"? you mean "IDL" interface definition language like you would use for comiling tlbs?

I've spent a huge amount of time learning all the edge cases, carefully porting from C originals, and constantly reviewing for bugs. And WDL isn't like any VB6 WinAPI set; coverage is far, far more extensive so you're unlikely to ever run into something that hasn't been covered.

I guess this is the type of answer I was expecting, thanks fafalone for the constructive answer
But now we see it is somtimes tricky but not impossible.
I think it was important to have this discussion.

[fafalone]

you mean PackagingAlignment of some sort of structs resp variables in structs/udtypes - yeah it is not impossible e.g. as you maybe know, you can use different struct-packaging in a tlb/typelibrary or use some other tricks in pure VB

Talking about writing x64 compatible defs. twinBASIC supports that attribute, no tricks/hacks needed"

Public Type MSGFILTER
    nmhdr As NMHDR
    msg As Long
    wParam As LongPtr
    lParam As LongPtr
End Type

This is subject to pack(4). For VB6, it doesn't matter, that's the natural alignment. However for 64bit, LongPtr would incorrectly insert 4 bytes between msg and wParam. twinBASIC allows this:

[PackingAlignment(4)]
Public Type MSGFILTER
    nmhdr As NMHDR
    msg As Long
    wParam As LongPtr
    lParam As LongPtr
End Type

So you don't need any tricks to make it correct.

"WDL"? you mean "IDL" interface definition language like you would use for comiling tlbs?

No, I mean Windows Development Library for twinBASIC. It's a tB package that has x64-compatible definitions of all common Win32 APIs/COM interfaces, including all supporting UDTs, enums, and consts. 15,000+ APIs, 3000+ COM interfaces, etc. You can check a box to include it and they're all available for use in your code, no need to copy/paste. I'm saying even for VB6 you could source defs from there... it's far easier to adapt the occasional tB-only language feature than do it yourself from C. And if you are using tB, delete your defs- fixing any signature differences is also better than doing it yourself from scratch. Especially if you're not experienced with C. It's a huge timesaver and very likely lower error rate as I've learned all the edge cases and constantly review for mistakes.

[Elroy]

Ohhh, I just figured it out. This is Olaf.

[The trick]

Guys, I agree the proper types are the good thing. Moreover some my projects use aliases for pointers etc. See this for example. But when we have the specific 32 bit code to access 64 bit code for vb6 this is unnecessary as least for performance reason. The currency math is more faster and simpler. I still try to use the approach with Enum for pointers 1 2 3 4 and more...

[Eduardo-]

So the "right" data type to use is a data type that VB6 doesn't have.

@OlimilO, how do you propose that we should test if we converted the API parameters to LongPtr right in VB6?

[fafalone]

oleexp.tlb adds LongPtr to vb6 or just use an empty enum since an enum is a Long:

#If VBA7 = 0 Then
Public Enum LongPtr: [_]: End Enum
#End If

There, 3 simple lines now VB6 has LongPtr that won't interfere with the proper LongPtr in VBA7/tB (tB sets VBA7=1 too).

@The trick, correct me if I'm wrong, but there's limits even if one were as talented as you with reverse engineering and assembly thunks. As I understand it you're limited to the couple modules loaded as 64bit like ntdll and win32k.sys (as you write, " Your dll can use only native-api-functions. "). That's why you're using reverse engineered internals like gapfnSendMessage instead of user32.SendMessage? Extremely impressive but limited, not addressing things like non-native APIs that block WOW64 calls or the future prospects for 32bit and VB6 runtime support.... and beyond the ability of 99% of us-- not to mention even if one had the skills, it's far more difficult and time consuming than just compiling a regular 64bit app with tB.

For performance; it's very hard to see how it could be faster and simpler with that kind of overhead; the VB6 hacks, VB6 performance itself, the extra ops to move the decimal, and LongLong matching the CPU architecture and not passed through WOW64. Would be very interesting to set up some benchmarks, but the benchmarks that have been done on initial tB LLVM-optimized code, VB6 can't hang even 32bit vs 32bit

[baka]

only in TLB. but coding it, no way.
if I start coding in TwinBasic, it will be 64bit only. at that moment I will take the challenge to convert it into 64bit.
I don't care 1 bit of "prepare it for future needs". I want "at the moment" needs. its both satisfying and productive to work in the "now" with new APIs and types.

when Im in TwinBasic, theres no reason to make 32bits. I will immediately jump to 64bit and learn that. 32bit will be forgotten and never again used.
but now, Im in VB6 and I code in that way. tricks, like TLB, its ok, but other than that, its pure VB6.

[fafalone]

I don't think I've ever seen someone hard code for 64bit *only* and deliberately break 32bit. So you're not going to use LongPtr in 64bit, just use LongLong, and change your pointer sizes to 8 instead of Len(LongPtr)?

Baffling why some people act like writing LongPtr instead of Long is some horrendous burden and huge change.

[baka]

64bit applications of course. not datatypes. will use what I need. byte, integer etc.
its obvious. not sure whats so hard to understand.

[fafalone]

I'm not understanding what possible benefit you'd derive from intentionally going out of your way, doing extra work, just to prevent your code from also compiling to 32bit. If we were getting into asm thunks that's one thing, since it's not simply LongLong vs LongPtr (an alias for LongLong in x64). But you're saying you want to use LongLong just so you *can't* compile to either 32 or 64, you *have to* do all your declares from scratch just so you can break compatibility?? For no other benefit, purely for not being compatible? And maybe also once every 10000 lines get to write 8 instead of Len(Of LongPtr)?

[OlimilO]

64bit applications of course. not datatypes. will use what I need. byte, integer etc.
its obvious. not sure whats so hard to understand.

Look, the thingi is: LongPtr is variable in size
in 32bit it is 4Bytes
in 64bit it is 8Bytes
so if you use LongPtr there is no need for the extra #IF

[OlimilO]

So the "right" data type to use is a data type that VB6 doesn't have.

Well that's kind of right but also not right, because you could use the trick with the empty Enum:

Public Enum LongPtr
    [_]
End Enum

this is very cheap wouldn't you agree

@OlimilO, how do you propose that we should test if we converted the API parameters to LongPtr right in VB6?

Well here is what I do: I test my codes in VB6 as well as in 64Bit Excel VBA7 with Microsoft Office 2024 LTSC, it is very cheap, it costs about EUR 10.- this is not a sells pitch though
Of course I need it for many other things too
But even If you don't need MS Office, or you simply don't like it .. you know .. just because .. whatever reason
Well what about using the community-version of twinBasic?
But even If you don't wanna do any of this stuff.
Whenever you are willing to use a pointer inside of your VB6-codes, for whatever winapi-function or for whatever pointer-safearray-copymemory-hack you will use, even if it has nothing to do with 64bit ...

I would propose to use the proper datatype for a pointer it is nowadays LongPtr and not Long anymore (since 2007)

here is what I do:
whenever I use a pointer I just simply include the module MPtr.bas
maybe have a look:
MPtr.bas

[OlimilO]

Guys, I agree the proper types are the good thing. Moreover some my projects use aliases for pointers etc. See this for example. But when we have the specific 32 bit code to access 64 bit code for vb6 this is unnecessary as least for performance reason. The currency math is more faster and simpler. I still try to use the approach with Enum for pointers 1 2 3 4 and more...

The trick: First I must say many thanks for your great work for the whole VB-Community.
Second: my suggestion for using the Type LongPtr64 maybe was not well thought out. because then you would be forced to use ByRef in VB6
So I dig the simple approach of using just the Currency.
For your approach Enum Ptr I must say it's a step to the right direction, and we could of course give it any name, but the name "LongPtr" was already there and was invented by M$ and is already variable in size and is also supported by twinBASIC

[Eduardo-]

oleexp.tlb adds LongPtr to vb6 or just use an empty enum since an enum is a Long:

#If VBA7 = 0 Then
Public Enum LongPtr: [_]: End Enum
#End If

There, 3 simple lines now VB6 has LongPtr that won't interfere with the proper LongPtr in VBA7/tB (tB sets VBA7=1 too).

Read my post (there is no point to do that in pure VB6).

[Eduardo-]

Well here is what I do: I test my codes in VB6 as well as in 64Bit Excel VBA7 with Microsoft Office 2024 LTSC, it is very cheap, it costs about EUR 10.- this is not a sells pitch though
Of course I need it for many other things too
But even If you don't need MS Office, or you simply don't like it .. you know .. just because .. whatever reason
Well what about using the community-version of twinBasic?

Maybe you program for hobby but I don't have time for doing unneeded things like that.
I don't see a point. When in the future I migrate to tB I'll do that conversion and will be able to test the code and will spend the time to make it work properly.
Maybe at that time there is a library stating which parameters are pointers and which are not in every API so the task can be automated.

But even If you don't wanna do any of this stuff.
Whenever you are willing to use a pointer inside of your VB6-codes, for whatever winapi-function or for whatever pointer-safearray-copymemory-hack you will use, even if it has nothing to do with 64bit ...

I would propose to use the proper datatype for a pointer it is nowadays LongPtr and not Long anymore (since 2007)

here is what I do:
whenever I use a pointer I just simply include the module MPtr.bas
maybe have a look:
MPtr.bas

That's your preference and I respect it. Not a need.

[Eduardo-]

PS: This task would be a good candidate for being done by a AI agent.
I've been thinking that it would be good to have an add-in to help programming, directly working on the program sources. But now I don't have time, maybe later. I'm using Claude, it seems quite good.

Claude probably can do it now. You can upload files.

Change all the API declarations parameters that are pointers, from Long to LongPtr.

[fafalone]

Read my post (there is no point to do that in pure VB6).

Sure there is. Maybe you don't care but I laid them out. And I have yet to hear a reason not to that's not premised on thinking it's somehow not identical to a Long. Again for new code; I'm not saying it's particularly worthwhile to go back and convert existing code now if you're not planning a near term switch. But there's good reasons to write new code with LongPtr and no downside

Maybe at that time there is a library stating which parameters are pointers and which are not in every API so the task can be automated

Again, there is such a library, where every Win32 API you'd use is already in a single source that can be used simply by ticking a box in tB or copy/pasting into VB6. WinDevLib. You could automate a backwards port without AI.

I use AI to help make it... It's not good enough to do it on its own. It makes a lot of mistakes and I have to carefully check every argument. So as mentioned, for others it's still quicker and more accurate to drop the occasional tB-only language feature from a source that's already been 100% human reviewed by someone experienced with the conversion. You may have like me tried using win32api.txt or winu.tlb and found it so incomplete and error filled as to be useless, I promise WDL isn't like that... Even in massive projects you'd been very unlikely to find an API not covered, and the error rate is demonstrably lower than any project like it or anything AI is capable of.

[Eduardo-]

Sure there is..

For you maybe there is a reason to spend time doing something like that in a program that will probably remain in VB6 forever (since it is "fun" or some other reason), for me the reason (and priority) is to finish and deliver the program as soon as possible.

Ah, but the OP said that it was only important for code that will be shared on internet... I'm thinking: how do someone know in advance when writing code for private programs if he will ever post some on internet eventually?

Bye.

[Eduardo-]

And thinking about this "proposal" there is a very strong reason for not using LongPtr here in the code that we share in the "Visual Basic 6 and Earlier" forum (and any code that is intended to be used in VB6): VB6 doesn't have the LongPtr type natively, and even when it is quite easy to add it, unless you include the hacky enum in every code that you share, better not to use that datatype at all, if you have any respect for the ones reading and wanting to use that code.

[fafalone]

Oh come on now, it's not "disrespectful" to have an enum for LongPtr, and certainly not more disrespectful than refusing to type 3 extra characters so your code is more compatible with VBA64 and tB64. Quite frankly it's insulting to presume that whether they use it or not everyone isn't already aware of what LongPtr is when it has existed in the VB language for 19 years now, and disrespectful to presume nobody would ever want to use the code you post online in VBA64 or tB64.

It's also like saying you shouldn't use any enum at all, just the literals everywhere. Because *any* enum can already exist in someone's codebase. And an enum isn't "hacky".

Also once you get the hang of it it takes no extra time at all. In fact now it would take me extra time to *not* do it in VB6, as I'd have to track down or rewrite APIs to specifically not use it rather than grab it from WDL in a fraction of the time, since there's nothing comparable in coverage or error rate that only has 32bit declares. If you want 32bit-only declares, they're either scattered or not even available . So I'd be delivering lower quality code and charging more for the privilege by wasting time declare-hunting or changing them back. Not to mention that most sources for large numbers of VB6 declares are ANSI and it's simply unacceptable to deliver a product that e.g. can't handle Unicode file names in 2026, so now after you track down whatever API you need you'll frequently have to fix that too, again instead of just taking the Unicode version from a single comprehensive source.

[The trick]

@The trick, correct me if I'm wrong, but there's limits even if one were as talented as you with reverse engineering and assembly thunks. As I understand it you're limited to the couple modules loaded as 64bit like ntdll and win32k.sys (as you write, " Your dll can use only native-api-functions. "). That's why you're using reverse engineered internals like gapfnSendMessage instead of user32.SendMessage? Extremely impressive but limited, not addressing things like non-native APIs that block WOW64 calls or the future prospects for 32bit and VB6 runtime support.... and beyond the ability of 99% of us-- not to mention even if one had the skills, it's far more difficult and time consuming than just compiling a regular 64bit app with tB.

This code is intended for very limited scenarios when you need to interact with 64 bit environment from 32 bit code directly. For example if you need to call SendMessage with TVM_GETNEXTITEM or any other private messages of the common controls. There are few scenarios when you need call 64 bit environment. You can't do it directly from the 32 bit code with the 32 bit APIs. When i need a 64 bit application i just write the 64 bit application using suitable languages but sometimes 32 bit is still enough for me.

For performance; it's very hard to see how it could be faster and simpler with that kind of overhead; the VB6 hacks, VB6 performance itself, the extra ops to move the decimal, and LongLong matching the CPU architecture and not passed through WOW64. Would be very interesting to set up some benchmarks, but the benchmarks that have been done on initial tB LLVM-optimized code, VB6 can't hang even 32bit vs 32bit

As i wrote above this code is for very limited scenarios. You don't need to use it for 64-bit replacement! It's for interact with 64 bit environment when OS doesn't provide such interaction from 32 bit environment. Regarding to the performance i meant the Currency is quite faster/more convenient than UDT (for example you can't pass 64-bit pointers wrapped to UDT as ByVal; and all the UDT restrictions). Addition/Subtraction of the Currencies (like pointer arithmetic is straightforward using usual ADD/SUB x86 instructions).

[The trick]

For your approach Enum Ptr I must say it's a step to the right direction, and we could of course give it any name, but the name "LongPtr" was already there and was invented by M$ and is already variable in size and is also supported by twinBASIC

Yes thank you. When you showed me the approach i started to use it.