How to convert VB.net unsafe pointers? - vb.net

Question

How to transfer this code from C# to VB.net?
This is from C#
if (local > 0)
{ //Local patches set offsets to data located elsewhere in this section
IntPtr start = data + section->_localPatchesOffset;
LocalPatch* patch = (LocalPatch*)start;
while ((int)patch - (int)start < local && patch->_dataOffset >= 0)
{ //Make the pointer offset relative to itself so it's self-contained
int ptrOffset = patch->_pointerOffset;
int* ptr = (int*)(data + ptrOffset);
*ptr = patch->_dataOffset - ptrOffset;
patch++;
}
}
Or I have this sample from C:
What exactly does it mean (byte*) in C
For example I have some byte array (like MemoryStream loaded from hole file....)
Dim arr As Byte() = New Byte() {1, 2, 33, 4, 55, 6, 7, 8, 9, 10, 10, 114, .....}
For example 33 is (at fromoffset 3) and 114 is (at tooffset 12)
This is not I think... Arr(fromoffset) = Arr(tooffset)
This is from C:
*(byte**)(SectionStart + LF->fromOffset) = SectionStart + LF->toOffset;

Answer 1

As jmc points out, you won't be able to convert that code to vb then compile it. I think your only option will be to make a c# DLL project, put that code into it (with any extra code it needs to function) as a method and then compile the c#
After you've done this you can reference the DLL, or you can even add the C# project to your solution continuing your VB item, and reference the project. The whole lot will compile and even the debugger will happily step from your VB.NET code into the c# and back again; these are not two separate languages when compiled - you could think of each language as merely being a whole lot of syntactic sugar for IL; but as VB simply doesn't have the sugar for unsafe stuff you'll have to do it in C#

Answer 2

The (byte*) is a pointer to a function with a parameter that is a pointer to a pointer of type byte.
Regarding unsafe pointers, the following is an excerpt from my Enhancing Visual Basic Book:
A Note on Recovering VarPtr, ObjPtr, StrPtr, VarPtrArray, and VarPtrStringArray.
If upgraded VB6 code required the “undocumented” VB6 functions VarPtr, ObjPtr, StrPtr, VarPtrArray, or VarPtrStringArray, use this one VB.NET function to duplicate all of them:
Imports System.Runtime.InteropServices
'--------------------------------------------------------------------------------------
' This Module Provides the memory addresses of Numeric Variables, Objects, and Strings.
'--------------------------------------------------------------------------------------
Module modVarPtr
'VB.NET version of VB6 VarPtr, ObjPtr, StrPtr, etc. (ALL of them are now supported by this one function).
'----------------------------------------------------------------------------------------------------------------------
'NOTES: Strings are not BSTR, so this returns the text address, not a BSTR pointer to the address pointing to it. This
' provides C# 'Unsafe Pointers' for VB.NET! Use the returned address right away before the Garbage Collector
' tries to change it! If we must hold it a short time, do not execute the GC.Free() instruction until done.
' We can break this code out in-line, using GC.Free() once we are done, but do not go on Break in the meantime.
' Garbage Collection will be held up until we GC.Free(), until then preventing the release of unused objects.
'----------------------------------------------------------------------------------------------------------------------
Public Function VarPtr(ByVal o As Object) As IntPtr 'Object 'catch all' (Return can also be 'As Integer').
Dim GC As GCHandle = GCHandle.Alloc(o, GCHandleType.Pinned) 'Get a trackable handle and pin (lock) the o address.
VarPtr = GC.AddrOfPinnedObject 'Get an IntPtr to the pinned o (var's data address).
GC.Free() 'free the allocated space used and unlock o address.
End Function 'Be aware IntPtr is 32-bit only on x86 compiles, otherwise it is 64-bit on 64-bit systems.
End Module
I am amaze so many VB6 users demanded a full VB OOPL environment with absolutely no sacrifice of OOPL functionality or data safety in the then-proposed VB.NET in 1999, with fist-shaking threats to abandon VB if their demands were not met. Yet, when they got exactly that, they had the gall to whine about the loss of the unsafe VarPtr, which did not jive with OOPL or data safety, but threatened user-demanded specifications. What was the result? They again threatened to abandon VB. There is a funny anecdote to describe such people, but I doubt they would appreciate it. Me? I love making fun of myself. I am a geek, and my jokes about geeks are merciless!
Finally, notice VB.NET Varptr again allows us to directly copy structure object data using the CopyMemory Pinvoke. However, even though we can grab class object memory addresses as well, we cannot use CopyMemory to copy data from or to it due to violating protected memory. Although some creative developers have managed to achieve this using intermediate memory areas, we can actually bypass employing intermediate buffers and use the .NET methods they recommend, the StructToPtr and PtrToStructure marshalling methods, to actually copy data directly to and from our local memory data and class objects. Even so, because these Unsafe Pointers are an allowed extension of OOPL rules, Microsoft should consider adding unsafe pointers to VB.NET.