We are running PB2022 R3
FUNCTION Long WNetGetUniversalName(String lpLocalPath, Long MustBe1or2, ref Blob lpBuffer, ref Long lpBufSize) Library "mpr.dll" Alias For "WNetGetUniversalNameW"
When you run this in 32 bit it works
When you run this in 64 bit it fails silently on "as_UniversalName = String(Long(lblb_Result), "address")"
Appears to happen when you have an as_RemoteNamelike Q:\Sample\XX. Q: to be translated to UNC.
//////////////////////////////////////////////////////////
///
// Map remote filename to UNC form
//
// Args: as_RemoteName = Remote filename of form:
// d:\path\name.ext
// as_UniversalName = UNC filename is returned here
//
// Returns: 1 if ok else -1
/////////////////////////////////////////////////////////////
Constant Long UNIVERSAL_NAME_INFO_LEVEL = 1
Blob lblb_Result
Long ll_Ret, ll_ResultSize = 1024
int li_Ret
lblb_Result = Blob(Space(ll_ResultSize))
TRY
ll_Ret = this.WNetGetUniversalName(as_RemoteName, UNIVERSAL_NAME_INFO_LEVEL, lblb_Result, ll_ResultSize)
if ll_Ret = 0 then
li_Ret = 1
as_UniversalName = String(Long(lblb_Result), "address")
else
li_Ret = -1
as_UniversalName = ""
end if
CATCH (runtimeerror er)
as_UniversalName = ""
li_Ret = -1
END TRY
return li_Ret
Using a LongLong (or Longptr) variable works because the starting memory location for a 64-bit integer is always evenly divisible by 8. This is critical in this particular case because Windows expects the third argument in this API function to be the address of a structure - and in a 64-bit process, structures are also required to have 8-byte alignment. I believe PB Blob variables have 4-byte alignment regardless of process bitness, so if the Blob happened to NOT be 8-byte aligned in a 64-bit process, calling this API function would fail, but it would work in a 32-bit process.
I REALLY wish PB would provide some way to obtain the address of PB variables, as this would be a big help in simplifying the coding needed to interface with external functions.