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


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

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

From "Henning" <computer_hero@coldmail.com>
Newsgroups alt.comp.lang.vb, alt.comp.lang.visualbasic, comp.lang.basic.misc, comp.lang.basic.visual.misc, microsoft.public.dotnet.languages.vb, microsoft.public.dotnet.languages.vb.upgrade
Subject Re: Upgrading older VB programs (sans Project Files) to VB.NET
Date 2012-01-14 00:24 +0100
Organization A noiseless patient Spider
Message-ID <jeqefk$opr$1@dont-email.me> (permalink)
References (4 earlier) <jekpsc$e1c$1@dont-email.me> <jen22c$n55$1@dont-email.me> <jepvvp$h89$1@dont-email.me> <jeq3r8$9kq$1@dont-email.me> <jeqdot$gs8$1@dont-email.me>

Cross-posted to 6 groups.

Show all headers | View raw


"Schmidt" <sss@online.de> skrev i meddelandet 
news:jeqdot$gs8$1@dont-email.me...
> 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.

I have the same experience, they used it for a month, then went back to 
kb/mouse. Their expensive touchscreens are only "normal" monitors today.

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