VB6 to VB.NET, comments please

[Galen Somerville]

My application receives and displays Heart sounds and ECG's in real time.
This data comes from a proprietary USB 2.0 device. Unlike most USB devices,
this data comes in short bursts of about 24 bytes. These bursts could come
as fast as every millisecond.

The display of the sound and ECG traces is similar to an oscilloscope
display except a blank space of about 5 pixels is shown as it sweeps across
the screen. This means that not only is six horizontal lines drawn for each
trace, for each data burst, but the next six existing horizontal lines have
to be blanked.

The above equates to around 300 Heart Beats per Minute (BPM). This is easily
handled by my VB6 application.

Using VB2005 Pro I have attempted to convert this VB6 app. As of now I use
shared memory, an in process thread to capture data from the USB and an
ActiveX thread to interface with the USB. I have attempted to do the drawing
with GDI, DirectX, etc.

The best I can get is a 15 BPM heart rate.

I am contemplating doing the drawing in my ActiveX thread. The idea being
that all of the data capture and drawing is, in effect, being done via VB6.
But if I do this then the VB2005 portion becomes one of just showing forms
with Command buttons and Text boxes etc. But my VB6 app already does this.

So my question is, what's the benefit of converting this app to VB.NET?

Apparently I can use the Interop Toolkit on my VB6 app instead of converting
to VB2005. What's the benefit in doing that?

As an aside, 99% of the customers have us buy a computer and install the
software at the factory. Then the computer is shipped to them. So no
installation problems.

I would appreciate any comments pro or con.

Thanks

Galen

 

[Mr. Arnold]

I am contemplating doing the drawing in my ActiveX thread. The idea being
that all of the data capture and drawing is, in effect, being done via
VB6. But if I do this then the VB2005 portion becomes one of just showing
forms with Command buttons and Text boxes etc. But my VB6 app already does
this.

So my question is, what's the benefit of converting this app to VB.NET?

There is nothing saying that you have to convert the VB6 legacy application
to VB.Net. If it works better as being a VB6 application, then keep it as
such, until you are forced to convert it. There will still be plenty of VB6
solutions still running out there for various reasons for a long time to
come that will have no need to be converted to .Net.

The old saying goes like this. If it's not broke, then you don't fix it.

However, if you need to deploy this solution to a Vista machine, then you
might need to go to VB.Net with its ability to produce a .Net manifest for
Vista's UAC.

 

[Henning Krause [MVP - Exchange]]

Hello,

have you tried to track down the performance bottleneck in the VB.NET
application?

If you cut away the visualization part, do you get a decent performance? The
performance degration might come from the way you perform the visualization.
Or it may be on the side of data acquisition.

Best regards,
Henning Krause

 

[Galen Somerville]

There is nothing saying that you have to convert the VB6 legacy
application to VB.Net. If it works better as being a VB6 application,
then keep it as such, until you are forced to convert it. There will still
be plenty of VB6 solutions still running out there for various reasons for
a long time to come that will have no need to be converted to .Net.

The old saying goes like this. If it's not broke, then you don't fix it.

However, if you need to deploy this solution to a Vista machine, then you
might need to go to VB.Net with its ability to produce a .Net manifest for
Vista's UAC.

I split the data files, written to, into a separate folder. Added a manifest
file and the VB6 app runs fine on Vista

Galen

 

[Galen Somerville]

I used QueryPerformanceCounter entries many times as I worked through the
problems.

The visualization is by far the poorest performer. But even the data
acquisition side was not that great. The shared memory saved the day but
still too much marshaling.

Galen

 

[Number 11950 - GPEMC! Replace number with 11950]

There is nothing saying that you have to convert the VB6 legacy application
to VB.Net. If it works better as being a VB6 application, then keep it as
such, until you are forced to convert it. There will still be plenty of VB6
solutions still running out there for various reasons for a long time to
come that will have no need to be converted to .Net.

The old saying goes like this. If it's not broke, then you don't fix it.

However, if you need to deploy this solution to a Vista machine, then you
might need to go to VB.Net with its ability to produce a .Net manifest for
Vista's UAC.

So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
then would compiling a control in VB6 that I add and compile through VB2005
be a more effective way of protecting my secrets than using an obfuscator to
reduce programatic rendering of code to mathematical rendering of code?

Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
compatibility for as long as VB2005 does?

TIA

 

[Galen Somerville]

"Number 11950 - GPEMC! Replace number with 11950" <[email protected]>
wrote in message

So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
then would compiling a control in VB6 that I add and compile through
VB2005
be a more effective way of protecting my secrets than using an obfuscator
to
reduce programatic rendering of code to mathematical rendering of code?

Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
compatibility for as long as VB2005 does?

TIA

--
Timothy Casey GPEMC! >> 11950 is the (e-mail address removed) 2email
Terms & conditions apply. See www.fieldcraft.biz/GPEMC
Discover valid interoperable web menus, IE security, TSR Control,
& the most advanced speed reading application @ www.fieldcraft.biz

My initial reason for trying this VB6 to VB2005 conversion was "to do the
right thing". But the aheader I go, the behinder I get.

Galen

 

[Mr. Arnold]

"Number 11950 - GPEMC! Replace number with 11950" <[email protected]>
wrote in message

So if I want to "weld the hood shut" as the open-sourcers so aptly put it,
then would compiling a control in VB6 that I add and compile through
VB2005
be a more effective way of protecting my secrets than using an obfuscator
to
reduce programatic rendering of code to mathematical rendering of code?

Would a VB6 ActiveX wrapped up in a VB2005 package retain forward
compatibility for as long as VB2005 does?

Many COM components will still be running on the Windows O/S for various
reasons. MS with a .NET solution has to give the ability to incorporate COM
solutions in into a .NET application.

 

[Mr. Arnold]

I split the data files, written to, into a separate folder. Added a
manifest file and the VB6 app runs fine on Vista

That VB6 program running on Vista and that VB6 program running on Vista
using escalated privileges when needed are two different things.

Can you show some kind of proof here that in fact what you have done is
going to allow a VB6 program to run and is not going to be stopped when it
needs escalated privileges for said VB6 program, because you have a
manifest file setting there?

Is the manifest file really being used in this case with the VB6 solution to
present credentials to Vista?

The only way of know about to date for a non .Net solution to escalate its
privileges during execution for a program is set the Run as Administrator on
the properties of the exe or the short-cut pointing to the exe.

 

[Galen Somerville]

That VB6 program running on Vista and that VB6 program running on Vista
using escalated privileges when needed are two different things.

Can you show some kind of proof here that in fact what you have done is
going to allow a VB6 program to run and is not going to be stopped when it
needs escalated privileges for said VB6 program, because you have a
manifest file setting there?

Is the manifest file really being used in this case with the VB6 solution
to present credentials to Vista?

The only way of know about to date for a non .Net solution to escalate its
privileges during execution for a program is set the Run as Administrator
on the properties of the exe or the short-cut pointing to the exe.

This is the Cardio74.exe.manifest I am using.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="7.0.4.0"
processorArchitecture="X86"
name="Cardio74"
type="win32"/>
<description>elevate execution level</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

Galen

 

[Mr. Arnold]

This is the Cardio74.exe.manifest I am using.

I cannot see the .dof files in this link, because I don't have MS Word on
this Vista computer.

Can you tell me if you're in compliacne with the information on how to
implement a program/application that's using or needs to interface with
Vista's UAC?

http://preview.tinyurl.com/27harb

You may find this link of interests to you.

http://www.codeproject.com/useritems/VB6InteropToolkit2.asp?print=true

 

[Galen Somerville]

I cannot see the .dof files in this link, because I don't have MS Word on
this Vista computer.

I didn't include any .doc files

Can you tell me if you're in compliacne with the information on how to
implement a program/application that's using or needs to interface with
Vista's UAC?

http://preview.tinyurl.com/27harb

Way too much to read. My program runs on a standard user, no admin, so I'm
happy.

You may find this link of interests to you.

http://www.codeproject.com/useritems/VB6InteropToolkit2.asp?print=true

That was one of my questions. Why should I use the Interop Toolkit. VB6 runs
fine.

Galen

 

[Mr. Arnold]

Way too much to read. My program runs on a standard user, no admin, so I'm
happy.

Obviously, the program can run on Vista as is. Any type of program should be
able to run with Vista's compatibility mode settings, if need be, along with
the ability to set the exe's or short-cut's property to Run as
Administrator.

And because it runs under Standard User and doesn't need escalated
privileges, then Vista's UAC is not going to check its credentials and
challenge it. I don't think the manifest will every come into play in this
situation and is not needed, and things in the program may not be in the
program to use the manifest.

 

[Dick Grier]

Hi,

It is (AFAIK) a simple fact that, for your sort of application, VB6 will
offer better performance. I have seen this with other similar applications.

If you need UI from VS2005, or other features that benefit, such as
webservices, then you should move code for that portion to .NET.

IMO, you should AVOID, at all costs, the use of COM interop for anything
that seeks improvement in real-time (sic) performance. COM interop should
be used only for communication between your .NET front end and your actual
VB6 application, where that communication does not involve sending and
receiving substantial amounts of data via COM between these partitions.

So, at the end of the day, my suggestion is that if your VB6 application is
meeting your needs, then by all means keep it there. Add "chunks," if
needed using .NET and COM interop, but understand that the COM portion will
have some negative impact on performance, and that raw processing of data
such as in your application will not be as performant (esp, when dealing
with graphical UI elements) as your current solution. So, if you can...
keep the data acquisition and display in VB6, and move only other non
real-time elements to .NET.

At least, that is what I am doing for today.

There can be issues with Vista, and the next generation of MS OS may
exacerbate these (no one knows how it might affect a VB6 app). Ideally,
hardware speed improvements will keep up with the extra overhead that our
new tools and environments are causing. But, buy off on the notion that new
hardware may be required. The last generation simply may not be up to the
task.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Galen Somerville]

Hi,

It is (AFAIK) a simple fact that, for your sort of application, VB6 will
offer better performance. I have seen this with other similar
applications.

If you need UI from VS2005, or other features that benefit, such as
webservices, then you should move code for that portion to .NET.

IMO, you should AVOID, at all costs, the use of COM interop for anything
that seeks improvement in real-time (sic) performance. COM interop should
be used only for communication between your .NET front end and your actual
VB6 application, where that communication does not involve sending and
receiving substantial amounts of data via COM between these partitions.

So, at the end of the day, my suggestion is that if your VB6 application
is meeting your needs, then by all means keep it there. Add "chunks," if
needed using .NET and COM interop, but understand that the COM portion
will have some negative impact on performance, and that raw processing of
data such as in your application will not be as performant (esp, when
dealing with graphical UI elements) as your current solution. So, if you
can... keep the data acquisition and display in VB6, and move only other
non real-time elements to .NET.

At least, that is what I am doing for today.

There can be issues with Vista, and the next generation of MS OS may
exacerbate these (no one knows how it might affect a VB6 app). Ideally,
hardware speed improvements will keep up with the extra overhead that our
new tools and environments are causing. But, buy off on the notion that
new hardware may be required. The last generation simply may not be up to
the task.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

I hear you loud and clear. There will be no web interfaces in our programs
so not much need of Net, at this time.

It's interesting to note that I develope on a Pent D 940 dual-core at
3.2GHz. But our program runs at high BMP rates on older Win98 machines with
way less power and speed.

Galen

 

[Walter Wang [MSFT]]

Hi Galen,

Glad to see you again here. I'm the one who suggested you to use shared
memory to pass data from VB6 to VB2005. The reason I suggested this
workaround is that COM interop between unmanaged and managed code is slow,
this is the price we have to pay for combining two different world. For the
data visualization part, yes WinForm does have some performance issue here.

Depending on your requirement, using Interop Toolkit might help but it will
certainly not help much on the real-time data processing part.

VB6 runtime will still be supported on Vista.

Regards,
Walter Wang ([email protected], remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Dick Grier]

Hi,
It's interesting to note that I develope on a Pent D 940 dual-core at
3.2GHz. But our program runs at high BMP rates on older Win98 machines with
way less power and speed.
<<

You have to really work hard with threading to make the dual-cores perform
(the one that I have is only a 2 GHz notebook, and it is about 30-35% slower
than the Hyperthreaded 3.2 GHz notebook it is replacing -- Vista looks nice,
but looks aren't everything). The OS (and .NET) have added so much that
gets in the way of raw performance that we have to use as much skill as we
can muster to avoid the bottlenecks. And, COM (and STAThread) marshaling is
a big bottleneck.

Perhaps you can investigate a native dll (or even .NET) interface to your
USB hardware. Getting away from the ActiveX interface might provide a
substantial speed improvement.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

 

[Galen Somerville]

Hi,

It's interesting to note that I develope on a Pent D 940 dual-core at
3.2GHz. But our program runs at high BMP rates on older Win98 machines
with
way less power and speed.
<<

You have to really work hard with threading to make the dual-cores perform
(the one that I have is only a 2 GHz notebook, and it is about 30-35%
slower than the Hyperthreaded 3.2 GHz notebook it is replacing -- Vista
looks nice, but looks aren't everything). The OS (and .NET) have added so
much that gets in the way of raw performance that we have to use as much
skill as we can muster to avoid the bottlenecks. And, COM (and STAThread)
marshaling is a big bottleneck.

Perhaps you can investigate a native dll (or even .NET) interface to your
USB hardware. Getting away from the ActiveX interface might provide a
substantial speed improvement.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

My USB drivers are from Jungo. I originally started with the net Jungo
drivers. Now that was slooow. I got up to 0.5 BPM rate. Keep in mind that
the normal use of USB is sending/recieving large streams of data. To a
printer or from a scanner etc.

Whereas I'm getting small 24 byte bursts fairly rapidly. The printers and
scanners don't really care that a little extra time is used by net. I do.

As a side note, my proprietary USB device is 100% assembly language using a
188 type processor and a NetChip USB chip. It's fast.

Galen

 

[jim]

My application receives and displays Heart sounds and ECG's in real time.
This data comes from a proprietary USB 2.0 device. Unlike most USB
devices, this data comes in short bursts of about 24 bytes. These bursts
could come as fast as every millisecond.

The display of the sound and ECG traces is similar to an oscilloscope
display except a blank space of about 5 pixels is shown as it sweeps
across the screen. This means that not only is six horizontal lines drawn
for each trace, for each data burst, but the next six existing horizontal
lines have to be blanked.

The above equates to around 300 Heart Beats per Minute (BPM). This is
easily handled by my VB6 application.

Using VB2005 Pro I have attempted to convert this VB6 app. As of now I use
shared memory, an in process thread to capture data from the USB and an
ActiveX thread to interface with the USB. I have attempted to do the
drawing with GDI, DirectX, etc.

The best I can get is a 15 BPM heart rate.

I am contemplating doing the drawing in my ActiveX thread. The idea being
that all of the data capture and drawing is, in effect, being done via
VB6. But if I do this then the VB2005 portion becomes one of just showing
forms with Command buttons and Text boxes etc. But my VB6 app already does
this.

So my question is, what's the benefit of converting this app to VB.NET?

Apparently I can use the Interop Toolkit on my VB6 app instead of
converting to VB2005. What's the benefit in doing that?

As an aside, 99% of the customers have us buy a computer and install the
software at the factory. Then the computer is shipped to them. So no
installation problems.

I would appreciate any comments pro or con.

Thanks

Galen

While keeping the application in VB6 will give better performance over
interop/COM performance, MS has stated that it will no longer support VB6
after Vista. And, seeing as how MS says the next OS is slated for release
in 2009 (only a year and a half from now) it may be wise to go ahead and
bite the bullet and move away from VB6.

If .Net is too slow (and it most probably is for real time, high speed
serial device input) you may want to go with a C++ application. It's not as
easy to code, but C++ will be around for a very long time to come.

jim

 

[Galen Somerville]

While keeping the application in VB6 will give better performance over
interop/COM performance, MS has stated that it will no longer support VB6
after Vista. And, seeing as how MS says the next OS is slated for release
in 2009 (only a year and a half from now) it may be wise to go ahead and
bite the bullet and move away from VB6.

If .Net is too slow (and it most probably is for real time, high speed
serial device input) you may want to go with a C++ application. It's not
as easy to code, but C++ will be around for a very long time to come.

jim

As I remember, they weren't going to support VB6 in Vista either. The
original apps were in assembly language with two ISA cards doing the real
time work. Then Graphics cards got better and cpu's got faster. That's when
I jumped on VB6 as it was easy to get up to speed.

Then ISA became passe and USB appeared, so I jumped on that.

I've toyed with going to C++ but it puts me back in the position of figuring
everything in detail. Hell, that's what I was doing originally in MASM. Age
comes into play also. My first program was an Infant Hearing Screener
written on an Intel ISIS system using 8085's.

Galen