I want to do a lot of work on very large bitmaps (20 Mp or more; 80Mb or more ARGB) using arrays for access. This I used to do in VB5.0 using the SAFEARRAY and BITMAP structures. NOT the corresponding .NET CLASSES. But I now need to use an SDK needing .NET. However, through lack of wisdom, the VB team dropped 5 critical resources on the move to VB.NET - VarPtr, VarPtrArray, the 2 structures and CopyMemory. The SAFEARRAY CLASS seems to lack a set method for array data and the BITMAP CLASS seems to lack both get and set methods for data. On building a .NET solution using VB.NET, c#.NET and C++.NET projects I could not locate the set and get methods. Interop could not upgrade my VB5.0 to VB2005 - presumably on account of these 5 problems. I was surprised that even C++ suffered too. .NET hurts. So, first off, two critcal simple questions:

A) Bearing in mind that much of the .NET is tinsel-wrapped APIs, does a pointer to an array still point to a defining SAFEARRAY STRUCTURE of the original format (NOT of course to a first element of an array). If that is so I am lucky for I can then fill and use (perhaps) my own SAFEARRAY STRUCTURE by memory manipulation in C++.

B) If the same applies to a bitmap pointer I can then perhaps do the same with BITMAP STRUCTURES. If that can be done I can hopefully work in a .NET solution containing C++ (for the pointer and mmory work) and VB2005 (for the rest of the work).

I can then

1) in VB define two empty byte-arrays GLOBAL in VB.NET- Pic1() and Pic2(). They do not need to be dimensioned. SAFE FROM GC

2) in VB define two GLOBAL SAFEARRAYS to match the arrays, one with one and another with 2 dims matching the bitmap. SAFE FROM GC

3) move ByRef the 4 objects to VC++. STILL SAFE FROM GC, EXACTLY WHERE THEY WERE.

3) copy the BITMAP data pointers to the data pointers of the SAFEARRAYS. DOES NOT MOVE ANYTHING.

4) copy the addresses of the SAFEARRAYS to the corresponding arrays STILL DOES NOT MOVE ANYTHING, BUT JOB DONE.

And then I will be able to process the images in seconds rather than minutes after moving only 4 4-byte numbers. I would welcome alternative sequences, provided they DO NOT involve put and set pixels or array elements on the trivial side and do not involve moving 80Mb of image data between "safe" and "unsafe" memory on the Herculian side.

If I can't overcome these 5 silly MS blunders I'll just have to build two uncoupled projects - one in VB5.0 and the other in VB/VC++ .NET. I'm not going to get involved myself with tinsel and gladwrap workarounds. In that case, VS2010 and VS2013 will stay on the shelf alongside Vista.