Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Upgrading older VB programs (sans Project Files) to VB.NET
15 views
Skip to first unread message
Ubiquitous
Jan 4, 2012, 6:23:10 PM1/4/12
to
I have some old Visual Basic programs I'd like to upgrade to .NET because
they currently require obsolete drivers like "VBRUN300.DLL" to run. I
attempted to use the upgrade wizard but it appears it requires a project
file and I only have .FRM, .FRX, and Make files, like this one:
>VERSION 2.00
>Begin Form Form1
> BackColor = &H00C0C0C0&
> BorderStyle = 1 'Fixed Single
> Caption = "Dice roller"
> ClientHeight = 1950
> ClientLeft = 1230
> ClientTop = 2625
> ClientWidth = 2295
> Height = 2355
> Icon = SRDICE01.FRX:0000
> Left = 1170
> LinkTopic = "Form1"
> MaxButton = 0 'False
> ScaleHeight = 1950
> ScaleWidth = 2295
> Top = 2280
> Width = 2415
> Begin TextBox Text3
> BackColor = &H00000000&
> ForeColor = &H00FFFFFF&
> Height = 285
> Left = 1200
> TabIndex = 7
> Text = "0"
> Top = 1560
> Width = 975
> End
> Begin TextBox Text2
> Height = 285
> Left = 1560
> TabIndex = 2
> Text = "4"
> Top = 480
> Width = 615
> End
> Begin ListBox List1
> Columns = 3
> Height = 1005
> Left = 120
> Sorted = -1 'True
> TabIndex = 4
> Top = 840
> Width = 975
> End
> Begin CommandButton Command1
> BackColor = &H00C0C0C0&
> Caption = "&Roll"
> Default = -1 'True
> Height = 375
> Left = 1200
> TabIndex = 3
> Top = 840
> Width = 975
> End
> Begin TextBox Text1
> Height = 285
> Left = 1560
> TabIndex = 1
> Text = "1"
> Top = 120
> Width = 615
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "Successes"
> Height = 255
> Index = 2
> Left = 1200
> TabIndex = 6
> Top = 1320
> Width = 975
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "&Target number"
> Height = 255
> Index = 1
> Left = 120
> TabIndex = 5
> Top = 480
> Width = 1335
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "&Number of dice"
> Height = 255
> Index = 0
> Left = 120
> TabIndex = 0
> Top = 120
> Width = 1335
> End
>End
>
>Sub Command1_Click ()
>
> list1.Clear
> nsucc = 0
> For i = 1 To Val(text1.Text)
> v = 0
>reloop:
> v = v + Int(Rnd(6) * 6 + 1)
> If v Mod 6 = 0 Then GoTo reloop
> If v >= Val(text2.Text) Then nsucc = nsucc + 1
> list1.AddItem Format$(v, "00")
> Next
> text3.Text = Format$(nsucc)
>
>End Sub
I have a feeling these pre-date VB 6 but wondered if there is a way to
systematically perform the upgrade without a project file instead of
making them from scratch.
they currently require obsolete drivers like "VBRUN300.DLL" to run. I
attempted to use the upgrade wizard but it appears it requires a project
file and I only have .FRM, .FRX, and Make files, like this one:
>VERSION 2.00
>Begin Form Form1
> BackColor = &H00C0C0C0&
> BorderStyle = 1 'Fixed Single
> Caption = "Dice roller"
> ClientHeight = 1950
> ClientLeft = 1230
> ClientTop = 2625
> ClientWidth = 2295
> Height = 2355
> Icon = SRDICE01.FRX:0000
> Left = 1170
> LinkTopic = "Form1"
> MaxButton = 0 'False
> ScaleHeight = 1950
> ScaleWidth = 2295
> Top = 2280
> Width = 2415
> Begin TextBox Text3
> BackColor = &H00000000&
> ForeColor = &H00FFFFFF&
> Height = 285
> Left = 1200
> TabIndex = 7
> Text = "0"
> Top = 1560
> Width = 975
> End
> Begin TextBox Text2
> Height = 285
> Left = 1560
> TabIndex = 2
> Text = "4"
> Top = 480
> Width = 615
> End
> Begin ListBox List1
> Columns = 3
> Height = 1005
> Left = 120
> Sorted = -1 'True
> TabIndex = 4
> Top = 840
> Width = 975
> End
> Begin CommandButton Command1
> BackColor = &H00C0C0C0&
> Caption = "&Roll"
> Default = -1 'True
> Height = 375
> Left = 1200
> TabIndex = 3
> Top = 840
> Width = 975
> End
> Begin TextBox Text1
> Height = 285
> Left = 1560
> TabIndex = 1
> Text = "1"
> Top = 120
> Width = 615
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "Successes"
> Height = 255
> Index = 2
> Left = 1200
> TabIndex = 6
> Top = 1320
> Width = 975
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "&Target number"
> Height = 255
> Index = 1
> Left = 120
> TabIndex = 5
> Top = 480
> Width = 1335
> End
> Begin Label Label1
> BackColor = &H00C0C0C0&
> Caption = "&Number of dice"
> Height = 255
> Index = 0
> Left = 120
> TabIndex = 0
> Top = 120
> Width = 1335
> End
>End
>
>Sub Command1_Click ()
>
> list1.Clear
> nsucc = 0
> For i = 1 To Val(text1.Text)
> v = 0
>reloop:
> v = v + Int(Rnd(6) * 6 + 1)
> If v Mod 6 = 0 Then GoTo reloop
> If v >= Val(text2.Text) Then nsucc = nsucc + 1
> list1.AddItem Format$(v, "00")
> Next
> text3.Text = Format$(nsucc)
>
>End Sub
I have a feeling these pre-date VB 6 but wondered if there is a way to
systematically perform the upgrade without a project file instead of
making them from scratch.
Mayayana
Jan 5, 2012, 9:25:38 AM1/5/12
to
You've posted to a ridiculous number of groups, some of which
are VB and some of which are VB.Net. VB and VB.Net are very
different things that share only a similar appearance. VB is for
Windows compiled software and is COM-centric. VB.Net is a Java
clone using a VM, designed to compete with Java in RAD server-
side software.
Your question should be posted only to .Net groups -- whis would
be the last 2 groups in your list. If you don't get an answer there,
you can try the online forums. Microsoft has discontinued
support for their own newsgroups and any MVP who wants to
keep a gold star on his/her forehead sticks to the online forums.
The forums are web-based. hard to use, moderated, and really
little more than a marketing device... but they're all that's left
in terms of Microsoft-supported discussion. You can find listings
here:
http://social.microsoft.com/Forums/en-US/categories
http://social.technet.microsoft.com/forums/en-US/categories/
http://social.msdn.microsoft.com/Forums/en/categories/
are VB and some of which are VB.Net. VB and VB.Net are very
different things that share only a similar appearance. VB is for
Windows compiled software and is COM-centric. VB.Net is a Java
clone using a VM, designed to compete with Java in RAD server-
side software.
Your question should be posted only to .Net groups -- whis would
be the last 2 groups in your list. If you don't get an answer there,
you can try the online forums. Microsoft has discontinued
support for their own newsgroups and any MVP who wants to
keep a gold star on his/her forehead sticks to the online forums.
The forums are web-based. hard to use, moderated, and really
little more than a marketing device... but they're all that's left
in terms of Microsoft-supported discussion. You can find listings
here:
http://social.microsoft.com/Forums/en-US/categories
http://social.technet.microsoft.com/forums/en-US/categories/
http://social.msdn.microsoft.com/Forums/en/categories/
Thorsten Albers
Jan 5, 2012, 11:33:05 AM1/5/12
to
Ubiquitous <web...@polaris.net> schrieb im Beitrag
<je49ej$37u$2...@dont-email.me>...
bit VB (in your case VB 3.0) used the extension ".MAK" for project files.
It is rather unlikely that the upgrade wizard accepts project files from a
16 bit version of VB.
--
Thorsten Albers
gudea at gmx.de
<je49ej$37u$2...@dont-email.me>...
> I have some old Visual Basic programs I'd like to upgrade to .NET because
> they currently require obsolete drivers like "VBRUN300.DLL" to run. I
> attempted to use the upgrade wizard but it appears it requires a project
> file and I only have .FRM, .FRX, and Make files, like this one:
Those files you are naming "make files" in fact are _the project files_. 16
> they currently require obsolete drivers like "VBRUN300.DLL" to run. I
> attempted to use the upgrade wizard but it appears it requires a project
> file and I only have .FRM, .FRX, and Make files, like this one:
bit VB (in your case VB 3.0) used the extension ".MAK" for project files.
It is rather unlikely that the upgrade wizard accepts project files from a
16 bit version of VB.
--
Thorsten Albers
gudea at gmx.de
Helmut_Meukel
Jan 5, 2012, 4:32:26 PM1/5/12
to
Ubiquitous stellte die Frage:
>> End
>>
>> Sub Command1_Click ()
>>
>> list1.Clear
>> nsucc = 0
>> For i = 1 To Val(text1.Text)
>> v = 0
>> reloop:
>> v = v + Int(Rnd(6) * 6 + 1)
>> If v Mod 6 = 0 Then GoTo reloop
>> If v >= Val(text2.Text) Then nsucc = nsucc + 1
>> list1.AddItem Format$(v, "00")
>> Next
>> text3.Text = Format$(nsucc)
>>
>> End Sub
>
> I have a feeling these pre-date VB 6 but wondered if there is a way to
> systematically perform the upgrade without a project file instead of
> making them from scratch.
This is a 16-bit VB3 project. It's project file is the .MAK file.
You are lucky, because the .FRM and .BAS files were saved as text
(default was Binary).
But you still must first upgrade the projects to 32-bit (VB5 or VB6),
then you can try the upgrade wizard to .net.
Any as binaries saved VB3 projects can't be opened by VB5/6, you must
open those project again in VB3 and select the option "save as text"
before saving.
Having said all this, I think it's better to begin all these old programs
from scratch in VB.NET.
If it's a small program, it's still probably faster.
If it's a large project, the upgrade wizzard will produce code that
needs much work to get it running and the code will still be a mess.
Helmut.
> I have some old Visual Basic programs I'd like to upgrade to .NET because
> they currently require obsolete drivers like "VBRUN300.DLL" to run. I
> attempted to use the upgrade wizard but it appears it requires a project
> file and I only have .FRM, .FRX, and Make files, like this one:
>
>> VERSION 2.00
>> Begin Form Form1
[...]
> they currently require obsolete drivers like "VBRUN300.DLL" to run. I
> attempted to use the upgrade wizard but it appears it requires a project
> file and I only have .FRM, .FRX, and Make files, like this one:
>
>> VERSION 2.00
>> Begin Form Form1
>> End
>>
>> Sub Command1_Click ()
>>
>> list1.Clear
>> nsucc = 0
>> For i = 1 To Val(text1.Text)
>> v = 0
>> reloop:
>> v = v + Int(Rnd(6) * 6 + 1)
>> If v Mod 6 = 0 Then GoTo reloop
>> If v >= Val(text2.Text) Then nsucc = nsucc + 1
>> list1.AddItem Format$(v, "00")
>> Next
>> text3.Text = Format$(nsucc)
>>
>> End Sub
>
> I have a feeling these pre-date VB 6 but wondered if there is a way to
> systematically perform the upgrade without a project file instead of
> making them from scratch.
You are lucky, because the .FRM and .BAS files were saved as text
(default was Binary).
But you still must first upgrade the projects to 32-bit (VB5 or VB6),
then you can try the upgrade wizard to .net.
Any as binaries saved VB3 projects can't be opened by VB5/6, you must
open those project again in VB3 and select the option "save as text"
before saving.
Having said all this, I think it's better to begin all these old programs
from scratch in VB.NET.
If it's a small program, it's still probably faster.
If it's a large project, the upgrade wizzard will produce code that
needs much work to get it running and the code will still be a mess.
Helmut.
Auric__
Jan 5, 2012, 9:50:53 PM1/5/12
to
Helmut_Meukel wrote:
> Having said all this, I think it's better to begin all these old programs
> from scratch in VB.NET.
> If it's a small program, it's still probably faster.
> If it's a large project, the upgrade wizzard will produce code that
> needs much work to get it running and the code will still be a mess.
Very much agreed. Restarting from scratch is likely to give you an overall
> Having said all this, I think it's better to begin all these old programs
> from scratch in VB.NET.
> If it's a small program, it's still probably faster.
> If it's a large project, the upgrade wizzard will produce code that
> needs much work to get it running and the code will still be a mess.
better program than importing, IMO.
--
The more you say, the less I understand.
Tony Toews
Jan 9, 2012, 10:29:34 PM1/9/12
to
On Wed, 04 Jan 2012 18:23:10 -0500, Ubiquitous <web...@polaris.net>
wrote:
>I have some old Visual Basic programs I'd like to upgrade to .NET because
>they currently require obsolete drivers like "VBRUN300.DLL" to run.
Or upgrade them to VB6 as the VB6 runtime is part of the OS from
Windows 2000 to Windows 8. If you can locate the VB6 IDE/compiler
for a decent price on Ebay then that may be all that is required.
Unless third party controls are involved but there likely are
replacements available.
I do see several on eBay for about $140 and up. Sort by price to get
the books out of the way.
Note that the eBay item "Microsoft MSDN Library Visual Studio 6 6.0
Basic Help" is just the help for VB6/VS6 and does not contain the
actual IDE/compiler.
(Sheesh, why would you be selling a VB6 certification exam guide on
eBay?)
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
wrote:
>I have some old Visual Basic programs I'd like to upgrade to .NET because
>they currently require obsolete drivers like "VBRUN300.DLL" to run.
Windows 2000 to Windows 8. If you can locate the VB6 IDE/compiler
for a decent price on Ebay then that may be all that is required.
Unless third party controls are involved but there likely are
replacements available.
I do see several on eBay for about $140 and up. Sort by price to get
the books out of the way.
Note that the eBay item "Microsoft MSDN Library Visual Studio 6 6.0
Basic Help" is just the help for VB6/VS6 and does not contain the
actual IDE/compiler.
(Sheesh, why would you be selling a VB6 certification exam guide on
eBay?)
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Mayayana
Jan 10, 2012, 9:22:14 AM1/10/12
to
| Or upgrade them to VB6 as the VB6 runtime is part of the OS from
| Windows 2000 to Windows 8.
Especially on the Desktop. (Presumably it will still be relevant
on corporate servers.) As I understand it, Windows 8 will have
Metro apps, which will be little more than scripted webpages, must
be approved by MS, and MS gets a cut of any sales income.
Win8 is still expected to have normal compiled software, which
will not suffer the restrictions and control of Metro apps, but will
be cast as fuddy duddy technology.
VB is still relevant for compiled software. Javascript is increasingly
relevant for $2 trinket software and games. .Net is not optimized
for either. It's hard to find a clear, complete story on Win8 and
Metro, but it sounds like .Net will be "repurposed" as a javascript
IDE.
Tom Shelton
Jan 10, 2012, 12:14:33 PM1/10/12
to
Mayayana formulated the question :
You seriously don't know what your talking about... .NET is a BIG part
of windows 8 and metro. HTML/JavaScript is just one way to create
limited functionality metro apps. Most apps will be C#/VB or C++ using
wpf as the front end. Some parts of the .net runtime will be mapped to
winrt - but, .net is not dead.
--
Tom Shelton
of windows 8 and metro. HTML/JavaScript is just one way to create
limited functionality metro apps. Most apps will be C#/VB or C++ using
wpf as the front end. Some parts of the .net runtime will be mapped to
winrt - but, .net is not dead.
--
Tom Shelton
Mayayana
Jan 10, 2012, 5:04:48 PM1/10/12
to
| You seriously don't know what your talking about... .NET is a BIG part
| of windows 8 and metro.
a wrapper-pretending-to-be-an-API as .Net is. May
as well script it.
Geez, it's taking a lot to rouse you
out of the woodwork these days, Tom. :)
Schmidt
Jan 11, 2012, 3:02:17 PM1/11/12
to
Am 10.01.2012 18:14, schrieb Tom Shelton:
> ... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".
That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).
All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".
The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.
Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).
Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.
Olaf
> ... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".
That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).
All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".
The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.
Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).
Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.
Olaf
Henning
Jan 12, 2012, 9:33:39 AM1/12/12
to
"Schmidt" <s...@online.de> skrev i meddelandet
news:jekpsc$e1c$1...@dont-email.me...
Your .NET decompiler alternative has arrived! Telerik JustDecompile is a
powerful yet free-of-charge tool, which enables you to effortlessly explore
and analyze compiled .NET assemblies at the click of a button.
/Henning
Tom Shelton
Jan 12, 2012, 11:34:11 AM1/12/12
to
Schmidt expressed precisely :
developed. New capabilities, new technologies being added, and new
versions being produced. So, I fail to see how .NET is anything like
VB6. Sure, there will be some changes comming. It's 10 year old tech
- of course it's going to change, and I expect at some point it will be
deprecated...
> Really funny, that we are back now, to the combination
> of 'C++ and COM' as the only recommended way to develop
> serious and new "native Desktop-Apps" (because any other
> (MS-)tools cannot be considered "future-proof" or
> "safe with regards to line-of-code-investments").
>
What I want to know is where you got that C++ and COM is the only
recommended way to develop metro apps. Have you even loaded VS11? I
guarentee you that VB and C# are there.
> IIRC we had this C++/COM combination already some 15 years ago,
> followed up by VB5/6-RAD to "develop COM-Apps even faster".
> So VB6 is yet a good tool, working "directly on top" of
> the current "state of the art tech".
I think it's more like C++/WinRT - COM is part of winrt, but asfict
it's not out in the forefront. Just like COM is part of .NET - but,
it's pretty much invisible for the most part.
> That much to selling us .NET as "technologic innovation"
> and urging us "to move on".
> Seems that the serious code-bases will always be C/C++ (as the
> best compromise, to abstract a language from the hardware).
>
> All the rest on top of it is (at least in MS' Book)
> apparently considered "throw-away software".
>
> The invention of COM, as a kind of objectoriented,
> (class-hosting and selfdescribing) library-format
> seems at least a well-surviving idea. As was VB-classic,
> as a glue-language for COMponents as well. It does
> its job even today, and will do so also on Win8.
>
> Aside from, that the new RAD-kid on the "blog" is now
> apparently the HTML/JS combination (and accompanying new
> IDEs, to "glue stuff together this way", including
> automatic uploads into the great new world of App-Stores).
>
> Let's see, how this works out - and what VB6/COM-based
> Apps on the Win8-Desktop are good for in the long run.
>
> Olaf
You are living in some sort of dream world, where all tech is good
forever. Doesn't happen. And, I seriously don't see how my .net code
base is in anyway threatend going forward at this time. Might have to
do some new UI's - but, since all of my real code is in libraries, I
really don't see this as a huge deal.
--
Tom Shelton
> Am 10.01.2012 18:14, schrieb Tom Shelton:
>
>> ... but, .net is not dead.
>
> It's now in the same way "not dead", as VB6 is...
> Welcome to the club!
>
VB6 has been deprecated - .NET has not. It is still being actively
>
>> ... but, .net is not dead.
>
> It's now in the same way "not dead", as VB6 is...
> Welcome to the club!
>
developed. New capabilities, new technologies being added, and new
versions being produced. So, I fail to see how .NET is anything like
VB6. Sure, there will be some changes comming. It's 10 year old tech
- of course it's going to change, and I expect at some point it will be
deprecated...
> Really funny, that we are back now, to the combination
> of 'C++ and COM' as the only recommended way to develop
> serious and new "native Desktop-Apps" (because any other
> (MS-)tools cannot be considered "future-proof" or
> "safe with regards to line-of-code-investments").
>
recommended way to develop metro apps. Have you even loaded VS11? I
guarentee you that VB and C# are there.
> IIRC we had this C++/COM combination already some 15 years ago,
> followed up by VB5/6-RAD to "develop COM-Apps even faster".
> So VB6 is yet a good tool, working "directly on top" of
> the current "state of the art tech".
it's not out in the forefront. Just like COM is part of .NET - but,
it's pretty much invisible for the most part.
> That much to selling us .NET as "technologic innovation"
> and urging us "to move on".
> Seems that the serious code-bases will always be C/C++ (as the
> best compromise, to abstract a language from the hardware).
>
> All the rest on top of it is (at least in MS' Book)
> apparently considered "throw-away software".
>
> The invention of COM, as a kind of objectoriented,
> (class-hosting and selfdescribing) library-format
> seems at least a well-surviving idea. As was VB-classic,
> as a glue-language for COMponents as well. It does
> its job even today, and will do so also on Win8.
>
> Aside from, that the new RAD-kid on the "blog" is now
> apparently the HTML/JS combination (and accompanying new
> IDEs, to "glue stuff together this way", including
> automatic uploads into the great new world of App-Stores).
>
> Let's see, how this works out - and what VB6/COM-based
> Apps on the Win8-Desktop are good for in the long run.
>
> Olaf
forever. Doesn't happen. And, I seriously don't see how my .net code
base is in anyway threatend going forward at this time. Might have to
do some new UI's - but, since all of my real code is in libraries, I
really don't see this as a huge deal.
--
Tom Shelton
Schmidt
Jan 13, 2012, 2:17:10 PM1/13/12
to
Am 12.01.2012 17:34, schrieb Tom Shelton:
> Schmidt expressed precisely :
>> Am 10.01.2012 18:14, schrieb Tom Shelton:
>>
>>> ... but, .net is not dead.
>>
>> It's now in the same way "not dead", as VB6 is...
>> Welcome to the club!
>>
>
> VB6 has been deprecated - .NET has not.
The VB6-IDE is not *supported* anymore - the essential
> Schmidt expressed precisely :
>> Am 10.01.2012 18:14, schrieb Tom Shelton:
>>
>>> ... but, .net is not dead.
>>
>> It's now in the same way "not dead", as VB6 is...
>> Welcome to the club!
>>
>
> VB6 has been deprecated - .NET has not.
technology under the covers (an underlying C/C++ compiler
and COM is by no means deprecated).
On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
>> Really funny, that we are back now, to the combination
>> of 'C++ and COM' as the only recommended way to develop
>> serious and new "native Desktop-Apps" (because any other
>> (MS-)tools cannot be considered "future-proof" or
>> "safe with regards to line-of-code-investments").
>>
>
> What I want to know is where you got that C++ and COM is
> the only recommended way to develop metro apps.
about "native Desktop-Apps" - and the only secure
way (the word "recommended" was not that well-choosen)
in terms of code-investments is apparently C/C++
(33 year old "technology" in the meantime).
> You are living in some sort of dream world, where all
> tech is good forever. Doesn't happen.
I say, tech *can* be "good forever", when there's not
much left to optimize (just look at "the wheel" <g>).
And apparently C/C++ is such a wheel.
Everything on top of it (in case you want to
construct a bicycle for example) - is just
different shortcuts (e.g. if you use different
frames (aka frameworks/libraries) in combination
with a highlevel-language, to be able to
build "customized cycles" a little bit faster).
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.
And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.
It remains to be seen (I'd say, let's talk about it again
in 10 years or so), whether a thin runtime-layer on top
of C/C++ - or a bloated VM, will better survive over time.
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".
Olaf
Tom Shelton
Jan 13, 2012, 3:22:55 PM1/13/12
to
Schmidt was thinking very hard :
deprecated.
>>> Really funny, that we are back now, to the combination
>>> of 'C++ and COM' as the only recommended way to develop
>>> serious and new "native Desktop-Apps" (because any other
>>> (MS-)tools cannot be considered "future-proof" or
>>> "safe with regards to line-of-code-investments").
>>>
>>
>> What I want to know is where you got that C++ and COM is
>> the only recommended way to develop metro apps.
>
> I was not talking about "Metro-Apps" - I was talking
> about "native Desktop-Apps" - and the only secure
> way (the word "recommended" was not that well-choosen)
> in terms of code-investments is apparently C/C++
> (33 year old "technology" in the meantime).
>
>
Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
the api. Win32 and the old dekstop are legacy.
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?
>> You are living in some sort of dream world, where all
>> tech is good forever. Doesn't happen.
> That's what you try to sell us for years now.
> I say, tech *can* be "good forever", when there's not
> much left to optimize (just look at "the wheel" <g>).
>
Sorry - but, if that was the case we would all still be using COBOL and
Fortran.
> And apparently C/C++ is such a wheel.
C/C++ are fairly close to the metal - and I love them both. But, even
they have evolved over the years. Have you been looking at the new
standards? Lots of features we have in C# being added - lambdas, etc.
> Everything on top of it (in case you want to
> construct a bicycle for example) - is just
> different shortcuts (e.g. if you use different
> frames (aka frameworks/libraries) in combination
> with a highlevel-language, to be able to
> build "customized cycles" a little bit faster).
>
C++ are just layers on top of assembly. So what?
> 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. And, not on ARM. VB6 will continue to work on
the legacy desktop, which we know will be phased out in the not to many
versions hence.
In other words - the end is nigh.
> And it is "less far" from the current base-tech
> (C/C++ and COM) than .NET is - that's my whole point.
>
C/C++ will not be using COM directly in the new paradigm. They, along
with C#/VB/JavaScript will be using WinRT. WinRT does use COM - in
fact, it's very important for the internals of WinRT, but the average
C++ dev developing for the new desktop is not going to care about that.
> It remains to be seen (I'd say, let's talk about it again
> in 10 years or so), whether a thin runtime-layer on top
> of C/C++ - or a bloated VM, will better survive over time.
>
You guys and your bloated VM thing are really getting tiresome.
First off - the runtime is not a thin layer over c/c++. It is a layer
over the win32 api - but, that is native code, ie machine code. It is
irrelavent that a lot of it was done in C (and I mean straigth C).
The framework, is a set of libraries - that is all. It doesn't all get
loaded at runtime. They don't all get used by any single application.
The size on disk and the download time of said framework is pretty much
irrelavent give modern broadband and disk sizes. Both, of which are
mostly irrelavent - since, like the VB6 runtimes - it is part of the
base OS install now.
You act as if I have some problem with C/C++? I do not. In fact, I
love C++. It was my first programming language - I still do stuff in
it on occasion. It's the love for C++ and C style syntax, that made me
move to C# when I had to move to .NET.
> 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 - and about to fade completely into the foot
notes of history. If you can't see that, than you simply aren't paying
attention. Smart tv's, smart camera's, tablets, phones, etc - they are
becomming the center of the computing industry. 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 :) ). At least, with C# there are tools for targeting android
and even ios. Haven't seen any for VB6... And, worse case - it's not
that difficult to port my C# libraries to Java (the major programming
environment in the android echo system).
The fact, is the world has moved on and left you behind.
--
Tom Shelton
> Am 12.01.2012 17:34, schrieb Tom Shelton:
>> Schmidt expressed precisely :
>>> Am 10.01.2012 18:14, schrieb Tom Shelton:
>>>
>>>> ... but, .net is not dead.
>>>
>>> It's now in the same way "not dead", as VB6 is...
>>> Welcome to the club!
>>>
>>
>> VB6 has been deprecated - .NET has not.
> The VB6-IDE is not *supported* anymore - the essential
> technology under the covers (an underlying C/C++ compiler
> and COM is by no means deprecated).
>
> 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
>> Schmidt expressed precisely :
>>> Am 10.01.2012 18:14, schrieb Tom Shelton:
>>>
>>>> ... but, .net is not dead.
>>>
>>> It's now in the same way "not dead", as VB6 is...
>>> Welcome to the club!
>>>
>>
>> VB6 has been deprecated - .NET has not.
> The VB6-IDE is not *supported* anymore - the essential
> technology under the covers (an underlying C/C++ compiler
> and COM is by no means deprecated).
>
> On the other hand, Winforms are deprecated in
> the meantime, as is the usage of Silverlight...
> (more to come, just wait).
>
deprecated.
>>> Really funny, that we are back now, to the combination
>>> of 'C++ and COM' as the only recommended way to develop
>>> serious and new "native Desktop-Apps" (because any other
>>> (MS-)tools cannot be considered "future-proof" or
>>> "safe with regards to line-of-code-investments").
>>>
>>
>> What I want to know is where you got that C++ and COM is
>> the only recommended way to develop metro apps.
>
> I was not talking about "Metro-Apps" - I was talking
> about "native Desktop-Apps" - and the only secure
> way (the word "recommended" was not that well-choosen)
> in terms of code-investments is apparently C/C++
> (33 year old "technology" in the meantime).
>
>
the api. Win32 and the old dekstop are legacy.
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?
>> You are living in some sort of dream world, where all
>> tech is good forever. Doesn't happen.
> That's what you try to sell us for years now.
> I say, tech *can* be "good forever", when there's not
> much left to optimize (just look at "the wheel" <g>).
>
Fortran.
> And apparently C/C++ is such a wheel.
they have evolved over the years. Have you been looking at the new
standards? Lots of features we have in C# being added - lambdas, etc.
> Everything on top of it (in case you want to
> construct a bicycle for example) - is just
> different shortcuts (e.g. if you use different
> frames (aka frameworks/libraries) in combination
> with a highlevel-language, to be able to
> build "customized cycles" a little bit faster).
>
> 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.
>
the legacy desktop, which we know will be phased out in the not to many
versions hence.
In other words - the end is nigh.
> And it is "less far" from the current base-tech
> (C/C++ and COM) than .NET is - that's my whole point.
>
with C#/VB/JavaScript will be using WinRT. WinRT does use COM - in
fact, it's very important for the internals of WinRT, but the average
C++ dev developing for the new desktop is not going to care about that.
> It remains to be seen (I'd say, let's talk about it again
> in 10 years or so), whether a thin runtime-layer on top
> of C/C++ - or a bloated VM, will better survive over time.
>
First off - the runtime is not a thin layer over c/c++. It is a layer
over the win32 api - but, that is native code, ie machine code. It is
irrelavent that a lot of it was done in C (and I mean straigth C).
The framework, is a set of libraries - that is all. It doesn't all get
loaded at runtime. They don't all get used by any single application.
The size on disk and the download time of said framework is pretty much
irrelavent give modern broadband and disk sizes. Both, of which are
mostly irrelavent - since, like the VB6 runtimes - it is part of the
base OS install now.
You act as if I have some problem with C/C++? I do not. In fact, I
love C++. It was my first programming language - I still do stuff in
it on occasion. It's the love for C++ and C style syntax, that made me
move to C# when I had to move to .NET.
> 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".
VB6 is simply irrelavent - and about to fade completely into the foot
notes of history. If you can't see that, than you simply aren't paying
attention. Smart tv's, smart camera's, tablets, phones, etc - they are
becomming the center of the computing industry. 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 :) ). At least, with C# there are tools for targeting android
and even ios. Haven't seen any for VB6... And, worse case - it's not
that difficult to port my C# libraries to Java (the major programming
environment in the android echo system).
The fact, is the world has moved on and left you behind.
--
Tom Shelton
Mayayana
Jan 13, 2012, 4:07:25 PM1/13/12
to
|
| I don't know if youv'e been paying attention... Win32 is pretty much
| deprecated.
|
It's the basis of WinRT.
| I don't know if youv'e been paying attention... Win32 is pretty much
| deprecated.
|
http://tirania.org/blog/archive/2011/Sep-15.html
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
"most if not all WinRT APIs are wrappers on top of existing functionality in
Win32 or COM components."
If you search on WinRT and API you find lots of
people saying that WinRT is "finally replacing the
old, decrepit API". And you'll find a few people, like
the links above, pointing out that WinRT, like .Net
before it, is no more than a [bloated] sandboxing
wrapper on top of the basic OS.
| Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
| the api. Win32 and the old dekstop are legacy.
| the legacy desktop, which we know will be phased out in the not to many
| versions hence.
|
Legacy... legacy... PCs are legacy. Mouse and keyboard
| versions hence.
|
are legacy. The Win API is legacy. VB is legacy. Desktops
and file systems are legacy. Whatever "legacy" is, it sounds
rather useful and comnprehensive.
Tom Shelton
Jan 13, 2012, 4:14:01 PM1/13/12
to
Mayayana used his keyboard to write :
practicle purposes, it is dead to the a developer targeting the metro
interface. Period. To think that WinRT does not make use of Win32 at
this point would be naive at best.
>> Well, in windows 8 and beyond - Metro is the native desktop. WinRT
>> is the api. Win32 and the old dekstop are legacy.
>> ..... VB6 will continue to work on
>> the legacy desktop, which we know will be phased out in the not to
>> many versions hence.
>>
>
> Legacy... legacy... PCs are legacy. Mouse and keyboard
> are legacy. The Win API is legacy. VB is legacy. Desktops
> and file systems are legacy. Whatever "legacy" is, it sounds
> rather useful and comnprehensive.
Keep saying that when you want your apps to run on Windows 8 arm
devices...
--
Tom Shelton
>>
>> I don't know if youv'e been paying attention... Win32 is pretty
>> much deprecated.
>>
>
> It's the basis of WinRT.
> http://tirania.org/blog/archive/2011/Sep-15.html
>
> http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
> "most if not all WinRT APIs are wrappers on top of existing
> functionality in Win32 or COM components."
>
> If you search on WinRT and API you find lots of
> people saying that WinRT is "finally replacing the
> old, decrepit API". And you'll find a few people, like
> the links above, pointing out that WinRT, like .Net
> before it, is no more than a [bloated] sandboxing
> wrapper on top of the basic OS.
>
You can not access Win32 functions directly in a metro app. For all
>> I don't know if youv'e been paying attention... Win32 is pretty
>> much deprecated.
>>
>
> It's the basis of WinRT.
> http://tirania.org/blog/archive/2011/Sep-15.html
>
> http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
> "most if not all WinRT APIs are wrappers on top of existing
> functionality in Win32 or COM components."
>
> If you search on WinRT and API you find lots of
> people saying that WinRT is "finally replacing the
> old, decrepit API". And you'll find a few people, like
> the links above, pointing out that WinRT, like .Net
> before it, is no more than a [bloated] sandboxing
> wrapper on top of the basic OS.
>
practicle purposes, it is dead to the a developer targeting the metro
interface. Period. To think that WinRT does not make use of Win32 at
this point would be naive at best.
>> Well, in windows 8 and beyond - Metro is the native desktop. WinRT
>> is the api. Win32 and the old dekstop are legacy.
>> ..... VB6 will continue to work on
>> the legacy desktop, which we know will be phased out in the not to
>> many versions hence.
>>
>
> Legacy... legacy... PCs are legacy. Mouse and keyboard
> are legacy. The Win API is legacy. VB is legacy. Desktops
> and file systems are legacy. Whatever "legacy" is, it sounds
> rather useful and comnprehensive.
devices...
--
Tom Shelton
Schmidt
Jan 13, 2012, 6:12:26 PM1/13/12
to
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,
>> 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.
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.
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?
"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>
What is it that you are trying to get at here?"
>> 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.
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.
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.
>> 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.
> First off - the runtime is not a thin layer over c/c++.
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++?
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++.
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 -
becoming more and more irrelevant.
> and about to fade completely into the foot
> notes of history.
> If you can't see that, than you simply aren't paying
> attention. Smart tv's, smart camera's, tablets, phones, etc
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.
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 :)
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.
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...
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 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.
Olaf
Henning
Jan 13, 2012, 6:24:31 PM1/13/12
to
news:jeqdot$gs8$1...@dont-email.me...
kb/mouse. Their expensive touchscreens are only "normal" monitors today.
> 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
>
>>> 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.
kb/mouse. Their expensive touchscreens are only "normal" monitors today.
Schmidt
Jan 13, 2012, 6:58:33 PM1/13/12
to
Am 14.01.2012 00:24, schrieb Henning:
>> 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.
Glad you confirmed that...
>> 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.
But it's logical IMO - first thing is, you usually
*sit* on a Desktop - and there's no convenient way, to
hold one of these larger 21-24" Touchscreens "on your lap"
One has to be standing, to use the touch-interface.
So first there's the "ergonomics" which are at play
here. And then there's of course a whole bunch of
more or less irrational reasoning, as for example:
"I hate those thumbprints on my screen, do I really
have to clean them myself any other day?"
not the least among them. ;-)
> Their expensive touchscreens are only "normal"
> monitors today.
about 100Euro more expensive than their normal counterparts.
I used this model here (the touch worked well enough,
it even came with a small TouchPen-device in the bottom-
right corner):
http://www.alternate.de/html/product/Iiyama/ProLite_T2250MTS-B1/144613/?
Olaf
Mayayana
Jan 13, 2012, 8:58:12 PM1/13/12
to
| You can not access Win32 functions directly in a metro app. For all
| practicle purposes, it is dead to the a developer targeting the metro
| interface. Period. To think that WinRT does not make use of Win32 at
| this point would be naive at best.
|
I don't want to write Metro trinkets. I doubt
that you really want to either. And it's *very*
unlikely that anyone's going to make money
doing that.
It'll be interesting to see how it pans out. Metro
is completely unrealistic for PCs. Nokia/Win phones
are getting great reviews, but no one is buying them.
Tablets never made much sense in the first place,
so it's hard to know how that will work out. No
matter how you look at it, people are not going to
be writing docs and spreadsheets on a swipe screen.
Microsoft tried to move developers out of the system
with .Net. They're doing it further with Metro. The plan
sounds a lot like trying to cash in on the Apple model:
Tight control. Developers have to be approved. MS gets
a 30% cut of software sales. That might happen, but it's
not going to happen on a PC. And that's the only kind
of software I'm interested in writing or using.
I'm actually very curious. On the surface, at least,
Microsoft seems to be turning away from corporate and
toward the entertainment market. So corporate PCs with
Win8 will be set to Desktop while non-business PCs will
be tuned to Metro, where people will spend their time
updating their Facebook page on their swipe screen?
That vision is so untenable in so many ways that I'm
quite curious to see how it all shakes out.
It seems clear that VB will be usable for Desktop
software as long as people can actually control their
own Windows PCs. And .Net will continue to be relevant
on corporate intranets, if nowhere else. If Metro survives
at all it will be in an entirely different arena.
Tony Toews
Jan 19, 2012, 9:10:22 PM1/19/12
to
On Fri, 13 Jan 2012 20:58:12 -0500, "Mayayana"
<maya...@invalid.nospam> wrote:
>Tablets never made much sense in the first place,
I very much like my Kobo Vox 7" tablet. But then all I really do on
<maya...@invalid.nospam> wrote:
>Tablets never made much sense in the first place,
it is read eBooks and browse the web. I don't do much else with it.
I certainly don't type more than a sentence on it while in Facebook.
>so it's hard to know how that will work out. No
>matter how you look at it, people are not going to
>be writing docs and spreadsheets on a swipe screen.
using it to do some light work.
0 new messages