Tom Shelton
6/2/2011 9:51:00 PM
ralph was thinking very hard :
> On Thu, 02 Jun 2011 11:54:22 -0600, Tony Toews
> <ttoews@telusplanet.net> wrote:
>
>> On Thu, 02 Jun 2011 01:17:49 -0500, ralph <nt_consulting64@yahoo.net>
>> wrote:
>>
>>> If they dropped it from the O/S you could just install it
>>> yourself.
>>
>> Trouble is my app does not require any admin privileges to setup and
>> use. It's a drag and drop deploy. It's also an app that is only used
>> in corporate environments and by Access folks so I want the folks who
>> are playing with it to have as painless a time as possible.
>>
>> I've been told that you can just put the VB6 runtime in the same
>> folder as your exe and it will work just fine too. But that's one
>> more complexity.
>>
>
> Yeah, I had an idea that was your main concern.
>
> But your situation is no different that any one else that uses a
> development platform that depends on a "Runtime" and worse a
> deprecated one. Or depends on a particular library.
>
> [What about people who had an investment in .Net Foundation Library 2?
> But that's another story.]
>
Yes it is - because I've never heard of such a thing. Not for .NET...
Are you talking about the old J++ Java based windowing library? That
was Java not .NET and it was deprecated when they went to J#. Which is
also dead - because there were only like 3 people using J++ and like
another one using J#.
> I'm reminded of a discussion back in the pre-.Net days when it was VC
> vs. VB. It was with some amusement I notice one particular respondent
> pointing out with glee that VB depended on a separate Runtime while
> his MFC application did not.
>
> That was not quite true. There is a MFC Runtime (and a VC one) and
> most Window Apps require it to be present. Now VC does have the
> advantage of being able to compile in those libraries and producing a
> large, independent, and bloated executable - no matter it was huge and
> tough to deliver. Luckily that is not an issue because MS hasn't
> deprecated the MFC/VC 'Runtimes' - YET. <g>
>
If you absolutely must be a single file deploy and you have to support
systems pre/vista then you are limited to only a couple of choices
really. C++ and Delphi are the only ones that come to mind - there are
others, but those are the only two that I know of that can 1) staticly
compile and 2) cross compile to ARM. I think this needs to be a
consideration, as there are going to be ARM based netbooks, tablets,
phones, etc running windows 8.
> You're lucky. You have apparently missed out on the good old days when
> not only we weren't sure if the VB Runtime was installed, we couldn't
> be sure what version it might be. We couldn't be sure of ADO, or Jet,
> drivers, or even MS Office versions or formats.
>
> Nor apparently ever worked with any development platform, such as
> Borland - where we could be almost positive that none of the
> supporting libraries would be present.
>
> "Drag and drop deploying" a single executable works only if all
> dependancies are satisfied. If someone else doesn't provide that
> service then you have to.
>
> But at the risk of getting flamed why are you even bothering to fret
> about it? Let's take a look at the facts.
>
> 1) VB is essentially dead as a "supported" product as far as Microsoft
> is concerned.
> 2) They announced that 12 years ago. Even allowing for a period of
> disbelief and hope, everyone has had at least 8 years to notice they
> seem to be serious and make a change to another development tool.
> 3) If you still are using VB (which currently still works well enough
> by the way) then fine, but you have been warned - "there are no plans
> to support VB Runtime after Windows 7".
> ie, if you make an investment and you are told there are "no plans" to
> provide any future returns on your investment - would you still make
> the investment. Maybe, maybe not - that is your risk.
> 4) They are now chiseling away at VBA (VB's core). (There might be a
> pattern here.)
Yes... easy cross platform compatability. One exe that runs on x86,
x86-64 (as a true 64-bit process), and ARM.
> 5) If the risk to your investment is beyond your comfort level then it
> is time to seek out another development platform, one that currently
> supported and is more likely to be supported in the future.*
> OR, plan on working out a strategy to "drag and drop deploy" several
> files, not just one.
>
> -ralph
> [*That last part saddens me. For years one of the main reasons I stuck
> with Microsoft was their record on "backward-compatibility". Most
> software investments were relatively 'safe' compared to any other
> vendor - but that is no longer the case.]
They still do. Your only thinking in terms of VB.CLASSIC - which even
today still works. Going forward, with ARM, x86-64, and even 128 bit
processing on the horizon, it doesn't make sense to spend time on a
dead platform.
--
Tom Shelton