Post by Tom SheltonPost by SchmidtOn 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.
Post by Tom SheltonWell, 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).
Post by Tom SheltonI 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>
Post by Tom SheltonPost by SchmidtAnd 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.
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.
Post by Tom SheltonVB6 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).
Post by Tom SheltonIn other words - the end is nigh.
That is true of course, always was - for all of us...;-)
Post by Tom SheltonPost by SchmidtAnd 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."
Post by Tom SheltonYou 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.
Post by Tom SheltonI 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.
Post by Tom SheltonPost by SchmidtFrom 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.
Post by Tom Sheltonand about to fade completely into the foot
notes of history.
In the same way as .NET does.
Post by Tom SheltonIf 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...
Post by Tom Sheltonthey 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).
Post by Tom SheltonWhich, 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.
Post by Tom SheltonAt 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.
Post by Tom SheltonHaven'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.
Post by Tom SheltonAnd, 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).
Post by Tom SheltonThe fact, is the world has moved on and left you behind.
Coming from you I can live with that, I think... ;-)
Olaf