What is Microsoft's Visual Basic 6 Support Strategy? | Visual Studio Team Interviews

Regnwald
Regnwald

Paul,

That post got badly chopped in the posting. Don't know why. Try again!

G'day Paul.

Well, you did ask what I want to do!

I have a REAL LARGE BITMAP defined GLOBAL in VB -- the image -- BM1 (20 Mp; ie 80Mb as ARGB). The BM1.pvBits is to be obtained and transferred to a C/C++ routine. In C/C++ two SAFEARRAY structures SA1 and SA2 are defined with GLOBAL scope. SA1 matches BM1 as a 1D array. SA2 matches BM1 as a 2D array. The SAFEARRAY structures pvData are both pointed to the BM1.pvBits data. Two small arrays of bytes are defined GLOBAL -- Pic1() and Pic2(). Pointers to addresses of Pic1() Pic2() SA1 and SA2 are obtained. The SA1 pointer is copied into the Pic1() pointer and the SA2 pointer is copied into the Pic2() pointer.

C/C++ returns nothing -- the job is done in situ.

On return to VB the following should be true:

The Pic1 no longer points to its small array, but to the BM1 data

The BM1 data is now accessed by Pic1() as a 1D array

The Pic2 no longer points to its small array, but to the BM1 data

The BM1 data is now accessed by Pic2() as a 2D array

Assembler accesses the BM1.pvBits

The SAFEARRAYs never go out of scope, are immune to GC so BM1 Pic1() and Pic2() are safe

WORRIES and DOUBTS:

What happens to the Pic1() and Pic2() data references to data?

Iits out of reach of the GC but small -- or should they be empty

Does VB.NET give me BM1.pvBits -- VB 5.0 does ALL of this for me. GIVE ME IT BACK

Is the SAFEARRAY structure still describing arrays in VB.NET

What pointer type problems do I have in C/C++?

Which C/C++ dialect should I use -- what headers.

How does .NET deal with pointers to foreign objects in GLOBAL (unmanaged) memory

How does native C deal with .NET

C++ .NET will not build 2D arrays in GLOBAL scope -- in this case does it know it has?

C++ .NET it seems, does not redefine global arrays and only defines them outside routines?

This will have to be done for each image as the BM1.pvBits will occupy different memory -- I KNOW, CLEAN UP NEEDED!!

That's a lot to lear for someone who has't needed to use C for nearly 20 years. But seriously, there is ONLY ONE WAY to get VB6ers onto VB.NET. You must be able to say TRUTHFULLY -- "VB.NET WILL DO EVERYTHING THAT VB6 DOES - AND MORE." But even then you have a clumsy technology which I suspect many C/C++ guys won't use. I would be happy to just stay with VB 5.0 were it not that a camera manufacturer's SDK requires VB.NET.

Until you can say that you are largely wasting your time. Trust requires a proven track record of backward compatibility. A workaround is a pain at best and it means YOU FAILED. You ARE behind schedule with this and the VS bottom line suffers accordingly! But hope is eternal. What did Luca PROMISE me. If he does that, and catches up with the past, you may well get me caught in 2013.

Regards, Ron

androidi

In reply to Regnwald

#Sep 14th @ 10:04 PM

I've to say I haven't tried them but one of the .NET GPGPU libs might be of interest if the you're looking for potential speed up without writing any C..

http://research.microsoft.com/en-us/projects/Accelerator/ << research project - i believe there are some better supported alternatives but I forget the names right now.

With the new Radeon 5xxx series that from demos so far looks to be way faster than currently available cards, with suitable data size (fit into gpu memory) you could be looking at massive perf increases for this sort of application over say doing same thing with app compiled with Intel C++ compiler and latest 8 core.

Regnwald
Regnwald

Thanks, Androidi,

I'll bear the card matter in mind when I upgrade, but I cannot impose that on my clients. My * with MS is that they did not maintain backward compatibility and that has NOTHING to do with .NET issues. It seems to be too much waste paper wrappers causing a mess in which the real contents get lost.