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" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

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

[Galen Somerville]

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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.

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

Galen

[Number 11950 - GPEMC! Replace number with 11950]

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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.

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 nu****@fieldcraft.com.au 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

[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

"Henning Krause [MVP - Exchange]" <ne***************@this.infinitec.de>
wrote in message news:eY*************@TK2MSFTNGP04.phx.gbl...

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" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

>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

[Galen Somerville]

"Number 11950 - GPEMC! Replace number with 11950" <nu****@fieldcraft.biz>
wrote in message
news:46***********************@lon-reader.news.telstra.net...

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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 nu****@fieldcraft.com.au 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" <nu****@fieldcraft.biz>
wrote in message
news:46***********************@lon-reader.news.telstra.net...

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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]

"Galen Somerville" <ga***@community.nospamwrote in message
news:e7**************@TK2MSFTNGP05.phx.gbl...

>
"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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]

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:eZ**************@TK2MSFTNGP05.phx.gbl...

>
"Galen Somerville" <ga***@community.nospamwrote in message
news:e7**************@TK2MSFTNGP05.phx.gbl...

>>
"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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.

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]

"Galen Somerville" <ga***@community.nospamwrote in message
news:u3**************@TK2MSFTNGP02.phx.gbl...

>
"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:eZ**************@TK2MSFTNGP05.phx.gbl...

>>
"Galen Somerville" <ga***@community.nospamwrote in message
news:e7**************@TK2MSFTNGP05.phx.gbl...

>>>
"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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...asp?print=true

[Galen Somerville]

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uo**************@TK2MSFTNGP06.phx.gbl...

>
"Galen Somerville" <ga***@community.nospamwrote in message
news:u3**************@TK2MSFTNGP02.phx.gbl...

>>
"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:eZ**************@TK2MSFTNGP05.phx.gbl...

>>>
"Galen Somerville" <ga***@community.nospamwrote in message
news:e7**************@TK2MSFTNGP05.phx.gbl...

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...

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

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.

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...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'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]

"Dick Grier" <dick_grierNOSPAM@.msn.comwrote in message
news:uv**************@TK2MSFTNGP03.phx.gbl...

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]

"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

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]

"jim" <ji*@yourpc.eduwrote in message
news:GN*****************@bignews2.bellsouth.net...

"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

>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

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

[jim]

"Galen Somerville" <ga***@community.nospamwrote in message
news:eF**************@TK2MSFTNGP04.phx.gbl...

>
"jim" <ji*@yourpc.eduwrote in message
news:GN*****************@bignews2.bellsouth.net...

>"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...

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

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

I feel your pain. I am 39. I taught my first programming class when I was
15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my own
business doing network administration for small to mid-sized bsinesses. It
gets boring, but it beats the hell out of coding for big companies like
Citibank, Porsche, Coca-Cola, etc. (The constant push to put apps out before
they are ready...and all that crap.)

I have been planning on doing some .Net stuff, learning C & C++...but I am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will let
me do my job as fast as possible and go live a little.

In fact, it looks to me like the general population is tiring of the whole
technology boom. Just look at the Wii kicking the butts of Playstation and
XBox.

I've screamed about it until blood has shot out of my mouth.....people just
want simple. Simple has always outsold complex, and it always will.

Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.

But, I'll be damned if anyone is listening.

Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?

..Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try and
sell it (there NEVER was a "Dll Hell" and I can prove it). They push .Net
on programmers because they can.

(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple reason...proprietary
data formats.

Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD or
thousands of other applications and move to a different app (much less a
different OS).

Things will never change until we enact legislation that enforces open data
formats. All companies that store user data should be forced by law to
publish the data formats that the data is stored in BEFORE they can sell (or
update) their software that users will use to store data. After all, it is
your data (regardless of what software package you use to compile or store
it) and it should always be your data and be portable to where ever you want
to take it.

If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.

Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively port
their data to an app more suited to their needs.

(OK....ok.....I'm stepping down now......)

[Galen Somerville]

"jim" <ji*@yourpc.eduwrote in message
news:zS*****************@bignews5.bellsouth.net...

>
"Galen Somerville" <ga***@community.nospamwrote in message
news:eF**************@TK2MSFTNGP04.phx.gbl...

>>
"jim" <ji*@yourpc.eduwrote in message
news:GN*****************@bignews2.bellsouth.net.. .

>>"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
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

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

I feel your pain. I am 39. I taught my first programming class when I
was 15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my
own business doing network administration for small to mid-sized
bsinesses. It gets boring, but it beats the hell out of coding for big
companies like Citibank, Porsche, Coca-Cola, etc. (The constant push to
put apps out before they are ready...and all that crap.)

I have been planning on doing some .Net stuff, learning C & C++...but I am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will
let me do my job as fast as possible and go live a little.

In fact, it looks to me like the general population is tiring of the whole
technology boom. Just look at the Wii kicking the butts of Playstation
and XBox.

I've screamed about it until blood has shot out of my mouth.....people
just want simple. Simple has always outsold complex, and it always will.

Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.

But, I'll be damned if anyone is listening.

Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?

.Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try
and sell it (there NEVER was a "Dll Hell" and I can prove it). They push
.Net on programmers because they can.

(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple
reason...proprietary data formats.

Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD
or thousands of other applications and move to a different app (much less
a different OS).

Things will never change until we enact legislation that enforces open
data formats. All companies that store user data should be forced by law
to publish the data formats that the data is stored in BEFORE they can
sell (or update) their software that users will use to store data. After
all, it is your data (regardless of what software package you use to
compile or store it) and it should always be your data and be portable to
where ever you want to take it.

If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.

Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively
port their data to an app more suited to their needs.

(OK....ok.....I'm stepping down now......)

I agree. My apps have a number of different file formats in use. I decided
early on that they would be handled within the programs.

Galen

[Number 11950 - GPEMC! Replace number with 11950]

"jim" <ji*@yourpc.eduwrote in message
news:zS*****************@bignews5.bellsouth.net...

>
"Galen Somerville" <ga***@community.nospamwrote in message
news:eF**************@TK2MSFTNGP04.phx.gbl...

"jim" <ji*@yourpc.eduwrote in message
news:GN*****************@bignews2.bellsouth.net...

"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
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

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

I feel your pain. I am 39. I taught my first programming class when I

was

15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my own
business doing network administration for small to mid-sized bsinesses.

It

gets boring, but it beats the hell out of coding for big companies like
Citibank, Porsche, Coca-Cola, etc. (The constant push to put apps out

before

they are ready...and all that crap.)

I have been planning on doing some .Net stuff, learning C & C++...but I am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will

let

me do my job as fast as possible and go live a little.

In fact, it looks to me like the general population is tiring of the whole
technology boom. Just look at the Wii kicking the butts of Playstation

and

XBox.

I've screamed about it until blood has shot out of my mouth.....people

just

want simple. Simple has always outsold complex, and it always will.

Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.

But, I'll be damned if anyone is listening.

Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?

.Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try

and

sell it (there NEVER was a "Dll Hell" and I can prove it). They push .Net
on programmers because they can.

(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple

reason...proprietary

data formats.

Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD

or

thousands of other applications and move to a different app (much less a
different OS).

Things will never change until we enact legislation that enforces open

data

formats. All companies that store user data should be forced by law to
publish the data formats that the data is stored in BEFORE they can sell

(or

update) their software that users will use to store data. After all, it

is

your data (regardless of what software package you use to compile or store
it) and it should always be your data and be portable to where ever you

want

to take it.

If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.

Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively

port

their data to an app more suited to their needs.

(OK....ok.....I'm stepping down now......)

Anyone can come up with a database format, and provided it communicates via
internationally recognised standard formats, it does the job. It's the API
for which a standard needs to be set. This would be possible only if it can
be legally recognised that the API is part of the IDEA of the operating
system and NOT part of its design. That way, the API can neither be
protected by copyright nor patent. As a programming level communications
standard necessary for cross-platform (XP) applications, I'd say that it's
not unreasonable to consider the API of ANY operating system fair game for
application in competing operating systems. If the Open Source crowd had the
cajones to take the Windows API on as an application communication standard,
all our apps would suddenly be Linux compatible as well...

The push for a redundant intermediate level API known as the framework via
..NET, signals plans to make major changes to the existing API - namely the
removal of substantial functionality. By going .NET your software becomes
forward compatible with respect to planned changes to Windows API. There is
a lot of pressure from wealthy Hollywood nobs to remove functions that can
be used to directly access media without monitoring by the operating
system's anti-piracy routines. Equally, this means that the Open Source
crowd will not only have to take on the Microsoft for the Windows API but
also for the Framework as well - if the dream of true XP applications is
ever going to be realised...

I would suggest that the Hollywood set may not necessarily represent
American interests - something to remember next time you vote...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 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

[Galen Somerville]

Whoa. Way to much for me. I am deleting this newsgroup and sticking with
VB6.general.discussion or whatever.

Galen

"Number 11950 - GPEMC! Replace number with 11950" <nu****@fieldcraft.biz>
wrote in message
news:46***********************@lon-reader.news.telstra.net...

"jim" <ji*@yourpc.eduwrote in message
news:zS*****************@bignews5.bellsouth.net...

>>
"Galen Somerville" <ga***@community.nospamwrote in message
news:eF**************@TK2MSFTNGP04.phx.gbl...

>
"jim" <ji*@yourpc.eduwrote in message
news:GN*****************@bignews2.bellsouth.net...
"Galen Somerville" <ga***@community.nospamwrote in message
news:%2***************@TK2MSFTNGP06.phx.gbl...
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

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

I feel your pain. I am 39. I taught my first programming class when I

was

>15 (Apple IIe and IIgs). I stopped coding 4 years ago and opened my own
business doing network administration for small to mid-sized bsinesses.

It

>gets boring, but it beats the hell out of coding for big companies like
Citibank, Porsche, Coca-Cola, etc. (The constant push to put apps out

before

>they are ready...and all that crap.)

I have been planning on doing some .Net stuff, learning C & C++...but I
am
(and I think everyone gets) not so impressed with technology any more. I
look for simple, cost effective solutions. I look for things that will

let

>me do my job as fast as possible and go live a little.

In fact, it looks to me like the general population is tiring of the
whole
technology boom. Just look at the Wii kicking the butts of Playstation

and

>XBox.

I've screamed about it until blood has shot out of my mouth.....people

just

>want simple. Simple has always outsold complex, and it always will.

Simple is more cost-effective and makes greater profit margins. Simple
means fewer tech support calls. Simple means money.

But, I'll be damned if anyone is listening.

Microsoft killed the most popular programming language EVER (in terms of
coders and application base) in favor of what? .Net?

.Net was never written for programmers. It was written by Microsoft, for
Microsoft's vision of software as a service. They lied to people to try

and

>sell it (there NEVER was a "Dll Hell" and I can prove it). They push
.Net
on programmers because they can.

(One more point and I promise....I'm off my soapbox.) And, Microsoft can
push programmers (and end users) around for one simple

reason...proprietary

>data formats.

Proprietary data formats make it damned near impossible (practically or
financially) for businesses to leave Microsoft or Quickbooks or AutoCAD

or

>thousands of other applications and move to a different app (much less a
different OS).

Things will never change until we enact legislation that enforces open

data

>formats. All companies that store user data should be forced by law to
publish the data formats that the data is stored in BEFORE they can sell

(or

>update) their software that users will use to store data. After all, it

is

>your data (regardless of what software package you use to compile or
store
it) and it should always be your data and be portable to where ever you

want

>to take it.

If we enacted open data format legislation, you would see a whole new,
affordable, usable downpour of applications and OS' begin to be used in
business and home use.

Software would have to compete based on usability, features and cost
effectiveness....not because the users can't easily or cost effectively

port

>their data to an app more suited to their needs.

(OK....ok.....I'm stepping down now......)

Anyone can come up with a database format, and provided it communicates
via
internationally recognised standard formats, it does the job. It's the API
for which a standard needs to be set. This would be possible only if it
can
be legally recognised that the API is part of the IDEA of the operating
system and NOT part of its design. That way, the API can neither be
protected by copyright nor patent. As a programming level communications
standard necessary for cross-platform (XP) applications, I'd say that it's
not unreasonable to consider the API of ANY operating system fair game for
application in competing operating systems. If the Open Source crowd had
the
cajones to take the Windows API on as an application communication
standard,
all our apps would suddenly be Linux compatible as well...

The push for a redundant intermediate level API known as the framework via
.NET, signals plans to make major changes to the existing API - namely the
removal of substantial functionality. By going .NET your software becomes
forward compatible with respect to planned changes to Windows API. There
is
a lot of pressure from wealthy Hollywood nobs to remove functions that can
be used to directly access media without monitoring by the operating
system's anti-piracy routines. Equally, this means that the Open Source
crowd will not only have to take on the Microsoft for the Windows API but
also for the Framework as well - if the dream of true XP applications is
ever going to be realised...

I would suggest that the Hollywood set may not necessarily represent
American interests - something to remember next time you vote...

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 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

[Number 11950 - GPEMC! Replace number with 11950]

"Galen Somerville" <ga***@community.nospamwrote in message
news:uR**************@TK2MSFTNGP06.phx.gbl...

Whoa. Way to much for me. I am deleting this newsgroup and sticking with
VB6.general.discussion or whatever.

Galen

"Number 11950 - GPEMC! Replace number with 11950" <nu****@fieldcraft.biz>
wrote in message
news:46***********************@lon-reader.news.telstra.net...

[SNIP]

Sorry, but I could never resist a good soapbox! :^)

--
Timothy Casey GPEMC! >11950 is the nu****@fieldcraft.com.au 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