Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.basic.misc > #206

Re: Upgrading older VB programs (sans Project Files) to VB.NET

Cross-posted to 6 groups.

Show all headers | View raw

Am 13.01.2012 21:22, schrieb Tom Shelton:

>> On the other hand, Winforms are deprecated in
>> the meantime, as is the usage of Silverlight...
>> (more to come, just wait).
>>
>
> I don't know if youv'e been paying attention...
> Win32 is pretty much deprecated.

That's misinformation, because MS cannot afford,
to throw out the Win32-API-layer any time soon.
The relation of Win32-Apps/Win64-Apps is currently
about 80/20 I'd say - a long way for MS, to be
able to pull the plug there.

> Well, in windows 8 and beyond - Metro is the
 > native desktop.
Not in my book - Metro/WinRT is foremost
only "an attempt to support a trend" (touch-
screens and non-x86 CPUs).

BTW, I've recently sold Desktop-Systems, which offered
(at request) both, a TouchScreen-interface and
alternatively "classic input" over Mouse/Keyboard.
What happened after a few weeks of playing around
is, that on my last visit everybody was back
using the Mouse exclusively.

So (IMO) there's just no need, to offer Touch-Interfaces
for "normal Desktop-Work" with classic Notebooks
or PC/TFT combinations.

Touchscreens make sense on devices without a Mouse
(Tablets and Phones - or large presentation-screens) -
nowhere else.

And there's rumors, that the real Desktop (running
on the classic Win32/64-API) will be made the default
(at least in Win8-company-versions, analogous to Win7).


> I still fail to see your point...
 > Winforms/silverlight and all .net apps will continue
> to run and function just as they always have on the legacy
> desktop. What is it that you are trying to get at here?
I'm repeating myself... they are in the same way
"dead, deprecated, whatever" as VB6 is - so let me
retype your above sentence:

"VB6 and VB6-apps will continue to run and function
  just as they always have on the legacy desktop.
  What is it that you are trying to get at here?"
<g>


>> And the VBClassic-runtime-lib (in conjunction with
>> the VBClassic language) does its job just fine
>> at the moment - as well as in the near future.
>>
>
> Not in the new desktop.

What exactly *is* the "new desktop"?
These Touch-Interface-optimized Entry-Screen-Tiles,
nobody who does serious Desktop-work will use
in the end?

Aside from that, it should not be that hard,
to bring a native VB6-App into this Tile-Upstarter.
And since WinRT is COM, it should also not be that
hard, to address it from VB6 - I'm sure this topic
will be "investigated" here in the community,
as soon as Win8 is out.


> And, not on ARM.
WTFuzz - here you come again, armed with the ARM-argument.
If one wants to address 95% of all Tablet- and Phone-
Users, he writes his App with either the Android- or
the Apple-Tools (Java or Objective-C).

And just in case I want to address the poor souls,
who indeed bought a Win8/ARM-device, then
Speaking for myself, I would write small HTML/JS-Apps
for devices like that. This way I could even address
the poor souls, who accidentally bought Win8/ARM-gadgets.

In either case, the applications which run on these
devices are not the classical, complex branch-solutions
which were/are the main-field of VB6-Devs. These new
mobile Apps are usually small, handling only a small
volume of data, not that many "screens to code" -
so the implementation-language does not matter that much.
The larger, complex Apps which are used on these
devices (Google-Maps or stuff like that), usually run
online anyways (in the Mobile-Browsers), so what you
need for development in these complex cases is an environment,
which can create WebApps - and for that there's loads
of alternatives to MS-stuff.


> VB6 will continue to work on the legacy desktop,
 > which we know will be phased out in the not to many
> versions hence.

"Which we know will be phased out..." - where can
I want to read more about that - do you have a
link or something?

Your so called "legacy Desktop" is still, also in
Win8, the main-workhorse for all kind of productive
labour - as I wrote further above already - the users
just "don't touch" the new stuff, as soon as a Mouse
is in reach.

Maybe we see a kind of "Vista-Effekt" for the new
Tile-Desktop (at least in productive environments).

> In other words - the end is nigh.

That is true of course, always was - for all of us...;-)


>> And it is "less far" from the current base-tech
>> (C/C++ and COM) than .NET is - that's my whole point.
>> ...
 >
> First off - the runtime is not a thin layer over c/c++.

I didn't wrote that.
Oh - you mean the WinRT (not the VBClassic-Runtime-lib)?
In this case I have to tell you, that the C/C++ guys
are very happy with WinRT, because they can bypass
any "intermediate .NET-layer" (you know, the "bloated
VM" I wrote about earlier <g>), to get access to the
system much more directly.
And of course the WinRT sits atop of C/C++ libs
(currently the classic Win-API on x86-machines) -
but on top of the WinAPI and WinRT comes the consuming
Application-Code, which (if you don't want bloat) should be
written also in C/C++. So, the "thin layer thingy"
works both ways of course...

Here the happy statement of a C++-developer -
at the end of the article (in the chapter 'Conclusion') on:
http://www.codeproject.com/KB/cpp/WinRTVisualCppIntro.aspx

"...But for faster applications with smaller memory footprints
  where performance is the key focal point, using C++ to write
  Metro apps is the way to go because when you do that it's
  metal on metal! The renaissance is here, finally."

> You act as if I have some problem with C/C++?
How do you come to this conclusion? I'm pretty
sure, I've done more work (manifested in megabytes
of VBclassic-adapted binaries) in C/C++ than you.

> I do not. In fact, I love C++.
Then go on, use it - there's even better suited
Newsgroups to talk about your love or C++ and all that.

>> From my point of view, it is you who's living in a
>> dream world, not acknowledging, that both approaches
>> (from MS' point of view) were only temporary cash-cows,
>> sold to "crowds of RAD-believers".
>>
>> The difference between .NET- and "still VB6"-users is,
>> that the latter ones recognized "the pattern" much
>> earlier (fool me once) - and didn't invest that much
>> time again into "the next distraction".
>
> That is simply the most ridiculous bunch of rubbish
> I have ever read. VB6 is simply irrelavent -

If you say so - but again, in the same way as .NET is
becoming more and more irrelevant.

> and about to fade completely into the foot
> notes of history.
In the same way as .NET does.

> If you can't see that, than you simply aren't paying
> attention. Smart tv's, smart camera's, tablets, phones, etc
Yeah, sure.
Smart anything - as well as "i like" or "fast and fluent"
or other marketing-rubbish you apparently are fond of...

> they are becomming the center of the computing industry.
Prebuilt devices with prebuilt vendor-apps, accompanied
by already saturated "App-markets". That's what the
"new developer-generation" has to struggle with
(to get their feets in).

What remains (for existing small software-companies
and selfemployed devs with a bit of a business-background)
is more or less (still) the branch-applications,
which wants to be run on a normal Desktop, on a
normal PC (with mouse and keyboard).

> Which, basically means even MS is struggling to stay relavent
> right now, against the on slaught of Android/iOS.
 > And that means, java or C (well, objective-c for ios :)
Glad you admit that.
It's an important point - and BTW the base of my assumption,
that my statement ".NET is becoming more and more irrelevant too"
is becoming a true one.


> At least, with C# there are tools for targeting android and even ios.

Yes, as I wrote above, the few percent which are left
for MS in this tv/table/phone consumer-market can be addressed
either with C#/VB.NET/C++ or with just simple HTML/JS.
And as said, should I ever be inconvenienced with the
requirement, to write a (probably then accompanying a larger DeskApp)
small application for a tablet or phone-device, then I'd
do it in HTML/JS - since all these platforms come with a
mobile-browser. There's even jQuery-abstraction-classes
for the touch-interface-events for most of them.

> Haven't seen any for VB6...
As said, not needed - for Desktop-stuff VBClassic is more
than enough - for "fun- and simple consumer-stuff" HTML/JS
should be sufficient too.

> And, worse case - it's not that difficult to port my C#
> libraries to Java (the major programming environment in the
> android echo system).
What are these libraries, if I may ask that?
What sense do they make, ported to a small-screen-device?
Aside from that, wouldn't it be better, to leave them
"as is" and just put their functionality at the serverside
and just show the computed (HTML/JSON) results on these small
screens (in a few WebPages), hmm?

You see, why I ask that - do you? Because exactly
the same way is open for any COM-library, written
in VBClassic (to put them into place behind a WebServer).

> The fact, is the world has moved on and left you behind.
Coming from you I can live with that, I think... ;-)


Olaf

Back to comp.lang.basic.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Upgrading older VB programs (sans Project Files) to VB.NET Ubiquitous <weberm@polaris.net> - 2012-01-04 18:23 -0500
  Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-05 09:25 -0500
  Re: Upgrading older VB programs (sans Project Files) to VB.NET "Thorsten Albers" <gudea@gmx.de> - 2012-01-05 16:33 +0000
  Re: Upgrading older VB programs (sans Project Files) to VB.NET Helmut_Meukel <Helmut_Meukel@bn-hof.invalid> - 2012-01-05 22:32 +0100
    Re: Upgrading older VB programs (sans Project Files) to VB.NET "Auric__" <not.my.real@email.address> - 2012-01-06 02:50 +0000
  Re: Upgrading older VB programs (sans Project Files) to VB.NET Tony Toews <ttoews@telusplanet.net> - 2012-01-09 20:29 -0700
    Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-10 09:22 -0500
      Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-10 10:14 -0700
        Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-10 17:04 -0500
        Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-11 21:02 +0100
          Re: Upgrading older VB programs (sans Project Files) to VB.NET "Henning" <computer_hero@coldmail.com> - 2012-01-12 15:33 +0100
          Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-12 09:34 -0700
            Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-13 20:17 +0100
              Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-13 13:22 -0700
                Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-13 16:07 -0500
                Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-13 14:14 -0700
                Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-13 20:58 -0500
                Re: Upgrading older VB programs (sans Project Files) to VB.NET Tony Toews <ttoews@telusplanet.net> - 2012-01-19 19:10 -0700
                Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-14 00:12 +0100
                Re: Upgrading older VB programs (sans Project Files) to VB.NET "Henning" <computer_hero@coldmail.com> - 2012-01-14 00:24 +0100
                Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-14 00:58 +0100

csiph-web