Re: VB6, VB2005, or Something Else?


"Anthony" <Anthony@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:14AA6095-860B-4455-A3B3-74F808E54912@xxxxxxxxxxxxxxxx
Paul

It seems to me that you are a proponent for the .net framework, and it
sounds like you know a lot about it. That's fine. I am just wondering what
your suggestion would be though redarging the issues I presented:

"(1) our code wouldn't convert, (2) the
framework seemed overly large for shareware downloads, (3) anyone that
wanted
to could decompile our code, and (4) the final application seemed very
sluggish (slow) compared to a vb6 app"

Relating to the above 4 items: A small company selling software such as us
is more interested in (1) code conversion speed (and possibility to
convert),
(2) small filesize so people will download and "try" it before they buy,
(3)
intellectual and piracy protection and (4) software that works AT LEAST as
fast as the old release (definately not slower).

Relating to the above 4 items: Can't Microsoft:

(1) Provide better conversion or better abilities to wrap a vb6 project
into
a .net project (even if it's a $1,000 add-on, we would consider it), (2)
enable coders to link framework components used to create an .exe that
does
not need the entire framework, (3) give us a way to protect out code so
people can't decompile it, and (4) make our apps run AT LEAST as fast as
VB6?

We would even subscribe to MSDN membership and continue to pay for vb6
upgrades if we knew Microsoft would support them through future operating
systems.

Seems to us Microsoft put lots of great features and gizmos into the
language (I actually like C# very much), which are very nice, but do not
allow us to meet our objective. Kind of like having a Mercedes that has
every
feature in the world, but you can't drive it to where you want to go.

Has Microsoft forgotton (or are they no longer interested) in the software
companies selling software?

Lots of posts in this topic - we still feel like we don't know what the
heck
to do next. It's scary -



--
Anthony Dunleavy
www.atrixware.com




"Paul Clement" wrote:

On Fri, 24 Feb 2006 10:27:35 -0800, Stefan Berglund
<sorry.no.koolaid@xxxxxx> wrote:

¤ On Fri, 24 Feb 2006 11:13:45 -0600, "Ralph"
<nt_consulting64@xxxxxxxxx>
¤ wrote:
¤ in <cbmdnXIR_PUFoGLenZ2dnUVZ_tydnZ2d@xxxxxxxxxxxx>
¤
¤
¤ >Its a b*tch that MS that MS is a @#%1&@ - but it is and they are -
and here
¤ >we are. Their way or highway.
¤ >
¤ >If you chose to remain with MS = It becomes the classic Fram Oil
Filter
¤ >quandary - "Pay me now, or pay me later". With the obvious answer -
buy in
¤ >now, buy in quickly, and buy in completely. Don't look back.
¤ >
¤ >Or seek, not another tool, but another operating system.
¤ >
¤ >-ralph
¤
¤
¤ No, sorry but I'm not buying that crap anymore. As Alpine says there
¤ are other viable alternatives to the ~flamework~ (love that one) and
¤ inevitably microsoft will feel the hurt. Remember the saying,
"Suppose
¤ they call a war and nobody comes?
¤

Then they win by forfeit.


Paul
~~~~
Microsoft MVP (Visual Basic)


I haven't been a "shrink-wrap" vendor in quite a few years. I work mostly
helping out development teams within a business environment. So this is only
based on personally observing what others are doing...

You have summed up the major problems with .Net very well.
Code conversion, Filesize, Intellectual and piracy protection, Performance.

1) Code conversion.
VB code is the most difficult conversion possible. (There are MFC horror
stories as well, but I'll stick with VB.) Success and expense is totally
dependent on the original architecture of the program. Simple data entry and
client/server apps port well. Specialized computational apps do not.

For all the programs examined for possible conversion about half are
found to not be suitable. At least half of all attempted coversions I have
witnessed have been essentially abandoned - either dropped or became a
complete re-write. But even with the so called 'successes' a lot of code has
been touched. (Actually a huge understatement.)

Most of the successful conversion I have seen, I would call
'replacements' in spite of what the developers thought they had
accomplished. There isn't a lot of help out there because those who have the
experience appreciate it is sellable commodity.

On the positive side, teams do get dramatically better as they go from
one project to another. They get a 'feel for it'.

2) Filesize.
If you don't count the Framework. Most .Net replacements are usually
much smaller. Or can easily be made so. (What I like to call the
'second-round' of conversion) Most are just offering the Framework as a
separate download. Some say this is costing them money other say it has
little effect as everyone is downloading the Framework anyway. <?>

I have heard from both sides and from quite a few users; Their reaction
runs, as one would expect, from "Hell No - I will never bother with that
crap" to "Great - I get to play with something new". Don't know what the
actual numbers are - I don't think anyone knows yet (well they are talking
like they do, but everyone has a clear bias).

3) Intellectual and piracy protection.
You have to obfuscate. Period. The good ones are expensive. Period. In
the corporate world, you can easily guard your code with normal system
security, but in the wild, there is nothing else. You still run the risk of
people swipping whole objects (one doesn't need to disassemble to steal),
but that is nothing new.

4) Performance.

There is no answer. .Net is slow. Period. There are some situations
where an 'average' vb runs a bit faster when converted to .Net. For example,
the container classes in .Net run circles around VB's Collection - but who
in their right mind uses VB's Collection in a speed conscious app. <g>

It appears MS is standing pat on expecting everyone to upgrade their
cpu. There are rumors the Framework will end up as some compiled thingy in
the kernal, but nothing real has shown up yet.

Many shops have gone to creating C++ managed modules for critical
features. Which is kind of funny as that was exactly the same place we were
back in the VB3/4 days. In fact that was how I made my living back then. But
even then you are not much faster, if at all, than the VB COM app you
started with.

[Which brings up other discussion points - If one has to revert to C++ for
some items - why not just go all the way back? Talk about losing your
knowledge base - ha. I would like to be there when you announce that
decision to the crew.]

The whole thing just sucks.

-ralph



.