What is Microsoft's Visual Basic 6 Support Strategy?

Paul, You made a gallant plea for migrants, but did you sell? I doubt it. You have the same battle as MS has with XP and Vista. Doubts.

 

How can you possibly encourage me to drop VB5.0 and migrate to VB.NET when VB.NET cannot do - I repeat CANNOT DO - what I can easily do on VB5. Why should I be so foolish as spend $1000 or more for VS2010 if it DOES NOT DO THE JOBS I need to do, and can do now.

 

For example, my most-used VB5.0 program processes astronomical images up to 80Mb in size, reducing image noise and reducing tonal range in stacked images, as well as doing metric and statistical work on the images. To achieve that, I use pointers to read bitmap data as both one and two dimensional arrays. I will NOT use lockbits for this purpose - at 72 yoa I cannot afford to wait for several GB of pixels to be moved back and forth between managed and unmanaged memory. And having left get and put long ago I have no desire to type those again. Dot NET may have advantages but it takes TIME coding,TIME compiling and ?TIME running. In addition, I call assembler routines which obviously use memory locations. VB.NET and C# cannot cope.

 

If you ARE really desperate to get VB6 (and us real sceptics of VB5 and earlier) over to VB.NET you MUST maintain the coding tools of VB6. All your pleas MUST fall on deaf ears otherwise. You must see that. How cam interop rework code, that uses memory moves, to a platform that does not recognise them.

 

I don't want the dog's dinner of pointer rubbish that litters C and C++. I am in the desperate situation of going ther. I hate it so far. I know plenty of C and C++ programmers who don't want it either! Just give me back:

 

1)    VARPTR on any damn thing I want. Don't worry about the GC - you can restrict to proc to GLOBAL or STATIC which are outside its range. But give them back to me.

 

2)   Clean methods to put them wherever I want to - pointers to array structures and data, bitmaps and bitmap data, and any user defined data structure.

 

And please don't tell me its too hard. DotNET is doing it ALL THE TIME. Then you may be in time to sell me VS2013!

 

But thanks for at least keeping the tenor of VB alive. As I said somewhere else, VB is a natural language worth far more than its image in some communities. I now spend a lot of time talking to my computer (Dragon Naturally Speaking). I don't let it talk back. It might win!! But even computer programming could move that way. Then I hope the conversation would be like that between Dillon and Andromeda than between the ?Arkona guru and his computer.

 

On a related matter, what in hell is MS doing pushing yet another new general purpose language. We have enough. Its getting bad enough with image formats. Absorb the F# team and make VB more powerful that it was before .NET (and, OK, even C# can benefit too, though heaven knows why).

 

Email me direct if you need to

 

Regards

 

Ron

 

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).

C/C++ returns nothing -- the job is done in situ. On return to VB the following should be true:

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.

 

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

 

 

 Assembler accesses the BM1.pvBits

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

 

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

 

        

 

 I would be happy to stay with VB 5.0 were it not that the camera control SDK needs VB.NET  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?

 

A fair number of issues for someone who hasn't needed to use C for nearly 20 years! I have a lot to learn.

 

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 don't use.

 

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 what did Luca PROMISE me?

 

Regards, Ron

 

 

 

 

 

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

What happens to the Pic1() and Pic2() data references to data? -- its out of reach of the GC but small -- or should they be defined empty Does VB.NET give me BM1.pvBits -- VB 5.0 does ALL of this for me. GIVE ME IT ALL BACK.

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

 

WORRIES and DOUBTS: