>> > it, why not just continue with VB.NET for the UI element as well.
>>
[quoted text clipped - 3 lines]
>
> I don't understand. What has 'web' got to do with the question?

Signature
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm
> >> > it, why not just continue with VB.NET for the UI element as well.
> >>
[quoted text clipped - 6 lines]
> dotNET.... note the word "NET" in there. Designed with the InterNET in mind,
> obviously....
Ok I see. dotNET -> NET -> interNET -> Web. Seems to me your reaching a
bit there.
> You know... it takes forever to load, forever to update the screen, etc,
> etc.
None of the above is actually true. I can believe that .NET is somewhat
slower than a comparable VB6 app. I doubt that makes a real difference on
modern and future hardware but I could be wrong.
Just as the "IE browser is good as an application UI" juggernaut (which may
have true in some cases) meant that users are being saddled with
sub-standard UIs in the name progress the same could be happening here. You
could be right but you'll lose anyway.
A well written C++ standalone app will beat VB6 app. I can remember when
compilied VB5 came along and heard this same sort of argument then between
C++ and VB devs. It's all daft.
Don't get me wrong I like VB6 and still use it more than C#. Being familiar
with the Win API I don't see there being a compelling commercial reason to
switch. However, daft sweeping statements like the couple above don't
really help any "VB6 is better than .NET argument", which IMO is a silly
thing to argue about anyway.
> ...and, where you can nearly right click and say "View Source" and it gives
> you the source for the entire app (with the help of any cheap debugger, that
> is).. no matter how much you spend on an obfuscator, something that VB6 or
> any other fully compiled language doesn't need at all, there are companies
> like the one below...
Yes it's possible to get some semblance of source code from disassembly but
unless you've written some hardcore algorithm which gives you a competative
advantage it's doubtful that even unobfuscated disassembly is of really much
use to anyone and very doubtful that it can hurt you where it counts, in the
pocket.
> "Think your code is safe, think again. Salamander .NET decompiler may steal
> your source code"
> http://www.remotesoft.com/
J French - 13 Mar 2007 12:46 GMT
<snip>
>Ok I see. dotNET -> NET -> interNET -> Web. Seems to me your reaching a
>bit there.
No, I think Ken has correctly picked up on what MS were trying to
convey.
>> You know... it takes forever to load, forever to update the screen, etc,
>> etc.
>None of the above is actually true. I can believe that .NET is somewhat
>slower than a comparable VB6 app. I doubt that makes a real difference on
>modern and future hardware but I could be wrong.
>Just as the "IE browser is good as an application UI" juggernaut (which may
>have true in some cases) meant that users are being saddled with
>sub-standard UIs in the name progress the same could be happening here. You
>could be right but you'll lose anyway.
>A well written C++ standalone app will beat VB6 app. I can remember when
>compilied VB5 came along and heard this same sort of argument then between
>C++ and VB devs. It's all daft.
VB5 was fully compileable from the outset.
It, like VB6 uses a jiggered C compiler
A CPP application does not have to be faster than a VB5/6 Application,
VB5/6 does more behind the scenes, a lot of that is unnecessary
Bear in mind that a lot of code is simply calling APIs
- also that things like copying one Byte Array to another pre-existing
Byte Array is astonishingly fast in VB
>Don't get me wrong I like VB6 and still use it more than C#. Being familiar
>with the Win API I don't see there being a compelling commercial reason to
>switch. However, daft sweeping statements like the couple above don't
>really help any "VB6 is better than .NET argument", which IMO is a silly
>thing to argue about anyway.
>> ...and, where you can nearly right click and say "View Source" and it
>gives
[quoted text clipped - 3 lines]
>> any other fully compiled language doesn't need at all, there are companies
>> like the one below...
>Yes it's possible to get some semblance of source code from disassembly but
>unless you've written some hardcore algorithm which gives you a competative
>advantage it's doubtful that even unobfuscated disassembly is of really much
>use to anyone and very doubtful that it can hurt you where it counts, in the
>pocket.
I would not bet on that, one of the reasons why DoDi, the VB3/4
decompiler writer discontinued his work was because he felt it
unethical to be able to re-engineer source.
Under many circumstances de-compilation is a real advantage, but those
are when the 'owner' of the App already owns the source.
>> "Think your code is safe, think again. Salamander .NET decompiler may
>steal
>> your source code"
>> http://www.remotesoft.com/
My beef is that MS are trying to pass off Fred.NET as an upgrade to
the old BASIC VB line
- it is not, it is an entirely different branch, say an elephant
masquerading as the descedant of a horse.
Ken Halter - 13 Mar 2007 15:12 GMT
> My beef is that MS are trying to pass off Fred.NET as an upgrade to
> the old BASIC VB line
> - it is not, it is an entirely different branch, say an elephant
> masquerading as the descedant of a horse.
All they would've needed to do is come up with one or more "new" letters to
name their "new" language, instead of trying to steal the thunder (lol) from
VB.real
They might've had people climbing all over themselves trying to grab copies.
"New Coke" just isn't "Coke". You'd think large companies would realize
their customers are the ones that made them large and avoid ticking that
customer base off, at all costs. "All costs" could've been as simple as
leaving "VB" alone or, better yet, completing their VB7 project and simply
picking a new name for their new language.
Why is it that COBOL and Delphi can run nearly untouched in dotNet but VB,
their own language, can't? Just plain silly. It's also silly to think no one
on earth can write a decent wizard to help people migrate their code. Any
7th grader these days can write a wizard that dumps "ToDo's" everywhere.

Signature
Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..
In Loving Memory - http://www.vbsight.com/Remembrance.htm
Galen Somerville - 13 Mar 2007 21:57 GMT
> > >> > it, why not just continue with VB.NET for the UI element as well.
> > >>
[quoted text clipped - 18 lines]
> slower than a comparable VB6 app. I doubt that makes a real difference on
> modern and future hardware but I could be wrong.
I have a USB device supplying Heart sounds and ECG traces that runs at 300 beats-per-minute on VB6.
So far in .NET if fails above 15 beats-per-minute.
Galen
> Just as the "IE browser is good as an application UI" juggernaut (which may
> have true in some cases) meant that users are being saddled with
[quoted text clipped - 29 lines]
> > your source code"
> > http://www.remotesoft.com/
Anthony Jones - 14 Mar 2007 13:09 GMT
> > > >> > it, why not just continue with VB.NET for the UI element as well.
> > > >>
[quoted text clipped - 23 lines]
>
> Galen
Thats pretty poor. 20x slower. Stick with VB6 while you can.
What's the spec of the machine it is running on?
Is this a port from the VB6 app or a from scratch re-write?