Re: Multithreading

8 Jun 2009 8:22 AM

SupaFly

Thank you! If you've ever used Angry IP Scanner, that's what I'm trying to
create. An IP scanner that can go through and find everything on the
network by pinging all the IPs. That would take forever pinging one-by-one.
If you had a 1000ms response time limit and you wanted it to try 3 times,
it would take 12 minutes to cover a 255 IP range. With Angry IP Scanner
using multiple threads, it takes less than 10 seconds.

So that's why I want to use multiple threads. It's warranted in this case,
wouldn't you say?

When I tried the Active EXE's, it took 100% of the CPU the whole time and
it's kind of slow. Angry IP Scanner with 255 threads takes like 0%
(seriously ZERO!), but it's written in C++, so that's to be expected. But I
was hoping not to take 100% and be faster. I could live with maybe 20% on
my CPU, for example.

I refuse to go to VB.NET, yet anyway. What a mess that is.

Show quoteHide quote

On 8-Jun-2009, "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote:

> Hi,
>
> Keep in mind that multithreading (or multiprogramming or multitasking,
> where
> you are talking about) takes always a lot of extra overhead.
>
> Therefore as that is something you want to avoid, then think before you
> begin.
>
> Multitasking is only effect full in areas where you can by instance
> download
> something form Internet and print that in the same time. Things which are
> themselves slow.
>
> Cor

8 Jun 2009 8:33 AM

Cor Ligthert[MVP]

What has VB Net to do with this, I assume you were asking something for VB6
?

I completely don't understand why you use this newsgroup to state our
opinion about VB.Net

Cor

Show quoteHide quote

"SupaFly" <superfly9***@hotmail.com> wrote in message
news:egyH9IB6JHA.2656@TK2MSFTNGP05.phx.gbl...
> Thank you! If you've ever used Angry IP Scanner, that's what I'm trying
> to
> create. An IP scanner that can go through and find everything on the
> network by pinging all the IPs. That would take forever pinging
> one-by-one.
> If you had a 1000ms response time limit and you wanted it to try 3 times,
> it would take 12 minutes to cover a 255 IP range. With Angry IP Scanner
> using multiple threads, it takes less than 10 seconds.
>
> So that's why I want to use multiple threads. It's warranted in this
> case,
> wouldn't you say?
>
> When I tried the Active EXE's, it took 100% of the CPU the whole time and
> it's kind of slow. Angry IP Scanner with 255 threads takes like 0%
> (seriously ZERO!), but it's written in C++, so that's to be expected. But
> I
> was hoping not to take 100% and be faster. I could live with maybe 20% on
> my CPU, for example.
>
> I refuse to go to VB.NET, yet anyway. What a mess that is.
>
>
> On 8-Jun-2009, "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote:
>
>> Hi,
>>
>> Keep in mind that multithreading (or multiprogramming or multitasking,
>> where
>> you are talking about) takes always a lot of extra overhead.
>>
>> Therefore as that is something you want to avoid, then think before you
>> begin.
>>
>> Multitasking is only effect full in areas where you can by instance
>> download
>> something form Internet and print that in the same time. Things which are
>> themselves slow.
>>
>> Cor

8 Jun 2009 2:55 PM

Tom Shelton

On 2009-06-08, SupaFly <superfly9***@hotmail.com> wrote:
Show quoteHide quote

> Thank you! If you've ever used Angry IP Scanner, that's what I'm trying to
> create. An IP scanner that can go through and find everything on the
> network by pinging all the IPs. That would take forever pinging one-by-one.
> If you had a 1000ms response time limit and you wanted it to try 3 times,
> it would take 12 minutes to cover a 255 IP range. With Angry IP Scanner
> using multiple threads, it takes less than 10 seconds.
>
> So that's why I want to use multiple threads. It's warranted in this case,
> wouldn't you say?
>
> When I tried the Active EXE's, it took 100% of the CPU the whole time and
> it's kind of slow. Angry IP Scanner with 255 threads takes like 0%
> (seriously ZERO!), but it's written in C++, so that's to be expected. But I
> was hoping not to take 100% and be faster. I could live with maybe 20% on
> my CPU, for example.
>
> I refuse to go to VB.NET, yet anyway. What a mess that is.
>

LOL... What a mess indeed. I just wrote a basic version of this (only scans
my network and only the lower 255 range) in about 10 minutes:

Option Explicit On
Option Strict On

Imports System.Net
Imports System.Net.NetworkInformation
Imports System.Threading

Public Class Form1
    Private ips As New List(Of IPAddress)()

    Private Delegate Sub UpdateListDelegate(ByVal data As String)

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        For Each ip As IPAddress In ips
            Dim t As New Thread(AddressOf PingIt)
            t.Start(ip)
        Next
    End Sub

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        For i As Integer = 0 To 255
            Dim ip As String = String.Format("192.168.15.{0}", i)
            ips.Add(IPAddress.Parse(ip))
        Next
    End Sub

    Private Sub PingIt(ByVal ip As Object)
        Dim p As New Ping()

        For i As Integer = 1 To 3
            Dim r As PingReply = p.Send(DirectCast(ip, IPAddress), 1000)
            If r.Status = IPStatus.Success Then
                ListBox1.Invoke(New UpdateListDelegate(AddressOf UpdateList), New Object() {String.Format("Passed: {0}", ip.ToString())})
                Return
            End If
        Next

        ListBox1.Invoke(New UpdateListDelegate(AddressOf UpdateList), New Object() {String.Format("Failed: {0}", ip.ToString())})
    End Sub

    Private Sub UpdateList(ByVal data As String)
        ListBox1.Items.Add(data)
    End Sub
End Class

I know, I know - I'm fueling "the war". But, we can take this as an example
of easy threading that I was going to do at one point for someone :)

--
Tom Shelton

9 Jun 2009 7:56 AM

SupaFly

Sorry, I guess I should have also mentioned that I wanted to do other things
in a multithreading manner. I have 3 years of coding invested in my
software and trying to move it all or re-writing it all in VB.net would be a
MESS.

Sorry I even mentioned .NET. :( I never will again though, not in this
group. It's become a nightmare and I really haven't gotten anywhere.
Complete waste of time.

I will try these other products and see what I can come up with. Thanks.

9 Jun 2009 3:41 PM

Tom Shelton

On 2009-06-09, SupaFly <superfly9***@hotmail.com> wrote:

No, first I should apologize. I was feeling snarky, and I gave in to it
against my better judgement. In other words, I have pretty much decided
against getting involved in these discussions.

> Sorry, I guess I should have also mentioned that I wanted to do other things
> in a multithreading manner. I have 3 years of coding invested in my
> software and trying to move it all or re-writing it all in VB.net would be a
> MESS.
>

Would it? How many hours have you spend trying to get something
multi-threaded to work in VB6, compared to the 10 minutes it took me to write
a multi-threaded ping?

> Sorry I even mentioned .NET. :( I never will again though, not in this
> group. It's become a nightmare and I really haven't gotten anywhere.
> Complete waste of time.
>
> I will try these other products and see what I can come up with. Thanks.

Good luck.

--
Tom Shelton

10 Jun 2009 9:59 PM

SupaFly

On 9-Jun-2009, Tom Shelton <tom_shel***@comcastXXXXXXX.net> wrote:

> No, first I should apologize. I was feeling snarky, and I gave in to it
> against my better judgement. In other words, I have pretty much decided
> against getting involved in these discussions.

That's ok, I understand I guess. All this back and forth with VB6/.NET has
gotten out of hand.

> Would it? How many hours have you spend trying to get something
> multi-threaded to work in VB6, compared to the 10 minutes it took me to
> write
> a multi-threaded ping?

About 3 days now, but it would probably take well over a year to re-write my
large app to .NET. It looks like I found a good solution though.

See, I need to get my software to generate more revenue so I can take that
time out to even take a look at .NET. If my software pings (or operates)
slower than the rest, then people will buy other software instead of mine
for that year of development on .NET. By then I'd be out of business. So,
spend a week getting multithreading to work in VB6, or a year re-writing my
entire app. in VB.NET? I think I'll pick the week. :)

The one thing I like about .NET is all the advanced components available.
But it's just a whole different animal. A different way of thinking than
I'm used to in .NET. Not to mention that some of my software couldn't be
converted because I need to run it remotely, and there's no way I'm going to
force a company to install .NET runtime hundreds of machines (XP, 2000, NT4)
that might not have it. I might as well go with Delphi at that point, and I
hate Delphi. But now that I mentioned that, I'm going to have 10 Delphi
people after me. :)

Of course this is not a .NET group, so I should definitely not have brought
it up, but I also thought there were mostly VB6-only people who aren't happy
about .NET. So I didn't think it would be a big deal, but apparently it
was.

11 Jun 2009 6:06 AM

MM

Show quote Hide quote

On Wed, 10 Jun 2009 21:59:17 GMT, "SupaFly" <superfly9***@hotmail.com>
wrote:

>On 9-Jun-2009, Tom Shelton <tom_shel***@comcastXXXXXXX.net> wrote:
>
>> No, first I should apologize. I was feeling snarky, and I gave in to it
>> against my better judgement. In other words, I have pretty much decided
>> against getting involved in these discussions.
>
>That's ok, I understand I guess. All this back and forth with VB6/.NET has
>gotten out of hand.
>
>> Would it? How many hours have you spend trying to get something
>> multi-threaded to work in VB6, compared to the 10 minutes it took me to
>> write
>> a multi-threaded ping?
>
>About 3 days now, but it would probably take well over a year to re-write my
>large app to .NET. It looks like I found a good solution though.
>
>See, I need to get my software to generate more revenue so I can take that
>time out to even take a look at .NET. If my software pings (or operates)
>slower than the rest, then people will buy other software instead of mine
>for that year of development on .NET. By then I'd be out of business. So,
>spend a week getting multithreading to work in VB6, or a year re-writing my
>entire app. in VB.NET? I think I'll pick the week. :)
>
>The one thing I like about .NET is all the advanced components available.
>But it's just a whole different animal. A different way of thinking than
>I'm used to in .NET. Not to mention that some of my software couldn't be
>converted because I need to run it remotely, and there's no way I'm going to
>force a company to install .NET runtime hundreds of machines (XP, 2000, NT4)
>that might not have it. I might as well go with Delphi at that point, and I
>hate Delphi. But now that I mentioned that, I'm going to have 10 Delphi
>people after me. :)
>
>Of course this is not a .NET group, so I should definitely not have brought
>it up, but I also thought there were mostly VB6-only people who aren't happy
>about .NET. So I didn't think it would be a big deal, but apparently it
>was.

Speaking for myself I would *never* install the .NET framework in
order to run an application. I have seen a few apps where in the
'small print', almost apologetically, the words are kinda hidden:
"needs .NET framework", and as soon as I read this, my interest in the
production comes to a dead stop. I have always found non-.NET
solutions instead.

As for *developing* in and for .NET, not in my lifetime! And not in a
thousand lifetimes were I to have a hotline to the deity who could
grant such an extension.

..NET represents the longest dump in history -- of Microsoft on to
classic VB programmers and I will NOT support it on principle
therefore.

MM

11 Jun 2009 7:37 AM

Cor Ligthert[MVP]

MM,

I see you never writing that a Net Executable is mostly 100 times smaller
then a VB6 one.

Show quoteHide quote

> Speaking for myself I would *never* install the .NET framework in
> order to run an application. I have seen a few apps where in the
> 'small print', almost apologetically, the words are kinda hidden:
> "needs .NET framework", and as soon as I read this, my interest in the
> production comes to a dead stop. I have always found non-.NET
> solutions instead.
>

11 Jun 2009 10:49 AM

Mark

Since VB6 -> VB.NET migration was mentioned by the OP, this Microsoft
UK page is really excellent:

http://msdn.microsoft.com/en-gb/dd408373.aspx

And here's a link with some good discussion.
http://stackoverflow.com/questions/395/how-to-switch-a-large-app-from-vb6-to-vb-net

On the usage of VB6 compared to VB.NET, this survey by Microsoft UK
was interesting. By my calculations at least 45% of those still using
VB6 said their companies were also using VB.NET.

http://geekswithblogs.net/iupdateable/archive/2009/02/17/results-of-the-visual-basic-survey-part-1-language-and.aspx

Cheers
Mark

11 Jun 2009 11:13 AM

MM

On Thu, 11 Jun 2009 09:37:35 +0200, "Cor Ligthert[MVP]"
<Notmyfirstn***@planet.nl> wrote:

>MM,
>
>I see you never writing that a Net Executable is mostly 100 times smaller
>then a VB6 one.

I don't care if a nuclear power station control room could be run on
the back of a fag packet with three lines of .NET code, I don't wanna
know! Principles is principles! The only good Nazi is a dead Nazi.

MM

10 Jun 2009 9:54 AM

Bill McCarthy

Hi SuaFly,

"SupaFly" <superfly9***@hotmail.com> wrote in message
news:OChbFfN6JHA.1092@TK2MSFTNGP06.phx.gbl...
> Sorry, I guess I should have also mentioned that I wanted to do other
> things
> in a multithreading manner. I have 3 years of coding invested in my
> software and trying to move it all or re-writing it all in VB.net would be
> a
> MESS.
>

Well, if you started it three years ago, you should have been well aware of
..NET then and could and should have worked towards making your code suitable
for the move to .NET. Clearly if you want multi-threading, VB.NET would
have been the correct way to go. In fact you can still do that today by
writing the multithreaded parts of your app in VB.NET and call on your
VB.NET dll from your existing code.

10 Jun 2009 12:08 PM

Schmidt

Show quote Hide quote

"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:OBnDUGb6JHA.4116@TK2MSFTNGP04.phx.gbl...
> Hi SuaFly,
>
> "SupaFly" <superfly9***@hotmail.com> wrote in message
> news:OChbFfN6JHA.1092@TK2MSFTNGP06.phx.gbl...
> > Sorry, I guess I should have also mentioned that I wanted
> > to do other things in a multithreading manner. I have 3 years
> > of coding invested in my software and trying to move it all
> > or re-writing it all in VB.net would be a MESS.
> >
>
> Well, if you started it three years ago, you should have been well
> aware of .NET then and could and should have worked towards
> making your code suitable for the move to .NET.

But you're aware, that there are some devs out there who don't
want/like (to ship) that huge runtime - and VB-Classic is one
of those languages, which allows smaller deployment-packages.

> Clearly if you want multi-threading, VB.NET would have been
> the correct way to go.

No - multithreading is available in almost all languages -
(also in VB6) it is not a ".NET-exclusive" thing.
What VB6 does *not* offer, is "lightweight-multithreading", since
VB-Classic does its multithreading stuff within STAs - and within
that STAs in a "STA-hosted" COM-Class-instance.
That has some overhead regarding the Thread-*Creation*,
which is of course an issue here, since the OP wanted to
fire-up a huge amount of threads.

> In fact you can still do that today by writing the multithreaded
> parts of your app in VB.NET and call on your VB.NET dll
> from your existing code.

In fact he can do that today by implementing his lightweight-
threads in languages that don't require the framework - and
which do support the usage of the CreateThread-API with
all bells and whistles - and without any STA-requirements
(as VB6-native, "heavy-threads" would).

FreeBasic will be suitable, ending up with a small 20-30kByte
Helper-Dll, callable from VB-Classic.
Or if someone has a bit of C-experience, then also the nice
tinycc-compiler (download-volume about 250kByte only)
can do that, able to create even smaller Std-Dlls then.

Aside from that, Nobodys suggestion, to use the proper async-
APIs for the OPs usecase would be my first choice (firing up
256 threads, is a bit of "a waste" IMO - just look within your
taskmanager, if there's any Process listed, which has more than
32-64 threads running) - and a solution that is based on these
async-APIs could be implemented also directly within VB6.

Olaf

10 Jun 2009 2:01 PM

Cor Ligthert[MVP]

Schmidt,

Why don't you tell this simply to the OP instead of creating a kind of war
from this?

Cor

Show quoteHide quote

"Schmidt" <s**@online.de> wrote in message
news:%23xVJUXc6JHA.1424@TK2MSFTNGP02.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:OBnDUGb6JHA.4116@TK2MSFTNGP04.phx.gbl...
>> Hi SuaFly,
>>
>> "SupaFly" <superfly9***@hotmail.com> wrote in message
>> news:OChbFfN6JHA.1092@TK2MSFTNGP06.phx.gbl...
>> > Sorry, I guess I should have also mentioned that I wanted
>> > to do other things in a multithreading manner. I have 3 years
>> > of coding invested in my software and trying to move it all
>> > or re-writing it all in VB.net would be a MESS.
>> >
>>
>> Well, if you started it three years ago, you should have been well
>> aware of .NET then and could and should have worked towards
>> making your code suitable for the move to .NET.
> But you're aware, that there are some devs out there who don't
> want/like (to ship) that huge runtime - and VB-Classic is one
> of those languages, which allows smaller deployment-packages.
>
>> Clearly if you want multi-threading, VB.NET would have been
>> the correct way to go.
> No - multithreading is available in almost all languages -
> (also in VB6) it is not a ".NET-exclusive" thing.
> What VB6 does *not* offer, is "lightweight-multithreading", since
> VB-Classic does its multithreading stuff within STAs - and within
> that STAs in a "STA-hosted" COM-Class-instance.
> That has some overhead regarding the Thread-*Creation*,
> which is of course an issue here, since the OP wanted to
> fire-up a huge amount of threads.
>
>> In fact you can still do that today by writing the multithreaded
>> parts of your app in VB.NET and call on your VB.NET dll
>> from your existing code.
> In fact he can do that today by implementing his lightweight-
> threads in languages that don't require the framework - and
> which do support the usage of the CreateThread-API with
> all bells and whistles - and without any STA-requirements
> (as VB6-native, "heavy-threads" would).
>
> FreeBasic will be suitable, ending up with a small 20-30kByte
> Helper-Dll, callable from VB-Classic.
> Or if someone has a bit of C-experience, then also the nice
> tinycc-compiler (download-volume about 250kByte only)
> can do that, able to create even smaller Std-Dlls then.
>
> Aside from that, Nobodys suggestion, to use the proper async-
> APIs for the OPs usecase would be my first choice (firing up
> 256 threads, is a bit of "a waste" IMO - just look within your
> taskmanager, if there's any Process listed, which has more than
> 32-64 threads running) - and a solution that is based on these
> async-APIs could be implemented also directly within VB6.
>
> Olaf
>
>

10 Jun 2009 2:42 PM

Michael Williams

"Cor Ligthert[MVP]" <Ligth***@planet.nl> wrote in message
news:ekHO2Pd6JHA.3968@TK2MSFTNGP03.phx.gbl...

> Schmidt, Why don't you tell this simply to the OP instead
> of creating a kind of war from this?

It was Bill McCarthy, who is both a liar and an identity thief, who created
the war in this thread. Olaf was merely responding to McCarthy's diatribe.

By the way, Ligthert, are you still having those wet dreams about Micro$oft?
You'll go blind you know ;-)

Mike

11 Jun 2009 5:02 AM

Bill McCarthy

Hi Schmidt,

Show quoteHide quote

"Schmidt" <s**@online.de> wrote in message
news:%23xVJUXc6JHA.1424@TK2MSFTNGP02.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:OBnDUGb6JHA.4116@TK2MSFTNGP04.phx.gbl...
>> Hi SuaFly,
>>
>> "SupaFly" <superfly9***@hotmail.com> wrote in message
>> news:OChbFfN6JHA.1092@TK2MSFTNGP06.phx.gbl...
>> > Sorry, I guess I should have also mentioned that I wanted
>> > to do other things in a multithreading manner. I have 3 years
>> > of coding invested in my software and trying to move it all
>> > or re-writing it all in VB.net would be a MESS.
>> >
>>
>> Well, if you started it three years ago, you should have been well
>> aware of .NET then and could and should have worked towards
>> making your code suitable for the move to .NET.
> But you're aware, that there are some devs out there who don't
> want/like (to ship) that huge runtime -

One rarely has to ship the runtime. These days all new windows based PC's
come with at least the 2.0 runtime. Even the XP boxes generally have them.
The runtime is also available via windows update, and compared to the size
of many of windows updates, it's quite small ;)
I think the argument of shipping the runtime was valid back when .NET first
came out, but not anymore. This has always been the case with VB. I
remember when VB4 came out and relatively speaking for the time, and the
bandwidths available in those days, (as well as hard disk space cost), the
VB4 runtime was huge
..

> and VB-Classic is one
> of those languages, which allows smaller deployment-packages.
>

VB classic does not provide true multi threading. You can twist it as much
as you like and pretend it does via activex.exe, but we all know in reality
that isn't practical.

>> Clearly if you want multi-threading, VB.NET would have been
>> the correct way to go.
> No - multithreading is available in almost all languages -
> (also in VB6) it is not a ".NET-exclusive" thing.
> What VB6 does *not* offer, is "lightweight-multithreading", since
> VB-Classic does its multithreading stuff within STAs - and within
> that STAs in a "STA-hosted" COM-Class-instance.
> That has some overhead regarding the Thread-*Creation*,
> which is of course an issue here, since the OP wanted to
> fire-up a huge amount of threads.
>

Firing up multiple processes running on their own single threads is not the
same as multi threading.

Show quoteHide quote

>> In fact you can still do that today by writing the multithreaded
>> parts of your app in VB.NET and call on your VB.NET dll
>> from your existing code.
> In fact he can do that today by implementing his lightweight-
> threads in languages that don't require the framework - and
> which do support the usage of the CreateThread-API with
> all bells and whistles - and without any STA-requirements
> (as VB6-native, "heavy-threads" would).
>
> FreeBasic will be suitable, ending up with a small 20-30kByte
> Helper-Dll, callable from VB-Classic.
> Or if someone has a bit of C-experience, then also the nice
> tinycc-compiler (download-volume about 250kByte only)
> can do that, able to create even smaller Std-Dlls then.
>

Sure he can use multiple languages. VB.NET is just one of many alternatives

> Aside from that, Nobodys suggestion, to use the proper async-
> APIs for the OPs usecase would be my first choice (firing up
> 256 threads, is a bit of "a waste" IMO - just look within your
> taskmanager, if there's any Process listed, which has more than
> 32-64 threads running) - and a solution that is based on these
> async-APIs could be implemented also directly within VB6.
>

If he only wanted to use that one API. As he had already stated before you
posted this, he wanted to use multi threading in respect to other API as
well.

11 Jun 2009 6:26 AM

Schmidt

"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:%23AtmPLl6JHA.4376@TK2MSFTNGP06.phx.gbl...

> One rarely has to ship the runtime.

Yeah, sure... <g>
There are more things about .NET which does not make
it suitable for me - but I'm bored ...

> VB classic does not provide true multi threading.
Wrong.

Learn your stuff, how to do it properly in VB6 -
if AX-Exes are not suitable for you - then just use
external helper-libs, that have *no* dependencies
to the .NET-runtimes.

I cannot believe it - a .NETer (with apparently no
threading-experience) wants to tell me, what I
cannot do with VB6.

[STAs]

> Firing up multiple processes running on their own single
> threads is not the same as multi threading.

As already said, learn your stuff, read about STAs -
google is your friend - hint: they have nothing to do with
"multi-processing".

[alternative environments/compilers]

> Sure he can use multiple languages. VB.NET is just one
> of many alternatives

How does that match with your earlier statement here?:

"Clearly if you want multi-threading, VB.NET would
have been the correct way to go..."

Olaf

11 Jun 2009 7:57 AM

Bill McCarthy

"Schmidt" <s**@online.de> wrote in message
news:eS2d98l6JHA.4376@TK2MSFTNGP06.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:%23AtmPLl6JHA.4376@TK2MSFTNGP06.phx.gbl...
>
>> One rarely has to ship the runtime.
> Yeah, sure... <g>
> There are more things about .NET which does not make
> it suitable for me - but I'm bored ...
>

Yeh this is the typical FUD response I expected. The truth is, as was
contained in the paret of my post you snipped, that modern day computers
that ship with windows include the .NET framework,; that the .Net framework
is available from windows update; that the relative size of the .NET
framework is inconsequential compared to Windows update sizes; and in
comaprison to band width and disk space cost per dollar, the .ENt framework
is small compared to what the VB4 runtimes where when VB4 shipped (note:
that doesn't even include all the extra 3rd party components you needed with
VB4 apps)

>> VB classic does not provide true multi threading.
> Wrong.

You can stomp your feet when you say that, but it still doens't make your
claim true. VB6 does not provide true multi threading.

> Learn your stuff, how to do it properly in VB6 -
> if AX-Exes are not suitable for you - then just use
> external helper-libs, that have *no* dependencies
> to the .NET-runtimes.
>

Funny how your code is reliant on extenral libraries to do the threading.
Lol !!

> I cannot believe it - a .NETer

Wow, you say that with such gutso and fever, like some form of KKK racism .

I guees there's no point in trying to discuss facts with you then.

> (with apparently no
> threading-experience) wants to tell me, what I
> cannot do with VB6.
>

Actually you said it in your previous post, and your need to use extenral
libraries shows that VB6 does not provide multi threading.

> [STAs]
>> Firing up multiple processes running on their own single
>> threads is not the same as multi threading.
> As already said, learn your stuff, read about STAs -
> google is your friend - hint: they have nothing to do with
> "multi-processing".
>

I suggest you read up on them, and also not I said "multiple processes" as
opposed to the "multiple-processing" you seem to have substituted. I guess
you should google up on what "in process" and "out of process" mean.

> [alternative environments/compilers]
>> Sure he can use multiple languages. VB.NET is just one
>> of many alternatives
>
> How does that match with your earlier statement here?:
>
> "Clearly if you want multi-threading, VB.NET would
> have been the correct way to go..."
>

Well clearly VB.NET does provide multi threading without the need to use
another language or third party library written in another language etc,
etc. If you go back and read the thread in context it *might* be clearer to
you .

11 Jun 2009 8:22 PM

Schmidt

Have no time to find out, why my reply is not going through.
(maybe the sheer count of the term: 'A-X-e-x-e', ...).

So here is a link to it:
www.datenhaus.de/Downloads/Re-Multithreading.txt

Olaf

12 Jun 2009 3:47 AM

Bill McCarthy

"Schmidt" <s**@online.de> wrote in message
news:e4T9EQt6JHA.4632@TK2MSFTNGP02.phx.gbl...
>
> Have no time to find out, why my reply is not going through.
> (maybe the sheer count of the term: 'A-X-e-x-e', ...).
>

Yeh well given it was a continuation of your previous post, it's pretty
clear why the server rejected it. And despite all the irrelevant rant you
go on about in there, you still haven't addressed the fact that the .NET 2.0
runtime is pretty much available on most windows PC's these days.

12 Jun 2009 4:56 AM

Schmidt

"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:OtLcTKx6JHA.5180@TK2MSFTNGP04.phx.gbl...
>
> "Schmidt" <s**@online.de> wrote in message
> news:e4T9EQt6JHA.4632@TK2MSFTNGP02.phx.gbl...
> >
> > Have no time to find out, why my reply is not going through.
> > (maybe the sheer count of the term: 'A-X-e-x-e', ...).
> >
>
> Yeh well given it was a continuation of your previous post,
> it's pretty clear why the server rejected it.

LOL, nice - really.

> And despite all the irrelevant rant you go on about in there,
> you still haven't addressed the fact that the .NET 2.0
> runtime is pretty much available on most windows PC's
> these days.

According to:
http://en.wikipedia.org/wiki/Microsoft_Windows

the relation between Vista and XP is about 30% vs 70%

So, if we give the 30% Vistas a 100% of preinstalled
..NET 2.0 - and the remaining 70% of XP a value of
30% of installed Framework-2.0 versions, then indeed,
you end up with:
0.3*1.0 + 0.7*0.3 = 0.51

So, yeah - you are right, that gives stunning 51% -
which does not prove your statement wrong:
"...the .NET 2.0 runtime is pretty much available
on most windows PC's these days"

But wait - now I bring up the yet remaining W2K, Me
and Win98 installations, which I neglected for now, since
they only make up a total of about 2.1% market-share
nowadays (at least according to wikipedia, although
that seems a bit low to me - but however).
So, including that low percentage in my calculation now,
we suddenly end up with only about 49.9% .NET 2.0
installs - which would render your statement wrong. ;o)

Ok, just making fun...
But another question that is somewhat related:
Do you already use the recommended WPF-GUIs
in your App (only available in .NET 3.5 - or just wait
for 4.0 for "even better" WPF-support) - or are you yet
coding against the "deprecated" WinForms" which
2.0 has to offer?

And what do you think is the currently preinstalled
percentage for these newer versions? ;-)

I mean, in your post to SupaFly you told him, that
it would have been a wise decision, to change to the
"newer, better stuff" earlier - a fool who does not do
so, hence my question to you is eligible I'd say.

Hoping now, that the "ranting" in my (just linked)
post does make a bit more sense to you, regarding
these "stable APIs" a developer wants to work against.

But no doubt - in a few years the new version 4.0
of the framework will be "pretty much available on
most PCs" too - it's just, that we then have presumably
a .NET version 6.0 around the corner, which then can
even play "hallelujah" automatically in case someone
enters "Hello World" into a demo-app - and certainly
will be able, to read LINQ-queries directly from your lips,
giving you a complete new developing-experience then
of course.

So, yeah - enjoy your "ride".

Olaf

12 Jun 2009 5:47 AM

Bill McCarthy

Show quote Hide quote

"Schmidt" <s**@online.de> wrote in message
news:%23xTjVvx6JHA.1764@TK2MSFTNGP06.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:OtLcTKx6JHA.5180@TK2MSFTNGP04.phx.gbl...
>>
>> "Schmidt" <s**@online.de> wrote in message
>> news:e4T9EQt6JHA.4632@TK2MSFTNGP02.phx.gbl...
>> >
>> > Have no time to find out, why my reply is not going through.
>> > (maybe the sheer count of the term: 'A-X-e-x-e', ...).
>> >
>>
>> Yeh well given it was a continuation of your previous post,
>> it's pretty clear why the server rejected it.
> LOL, nice - really.
>
>> And despite all the irrelevant rant you go on about in there,
>> you still haven't addressed the fact that the .NET 2.0
>> runtime is pretty much available on most windows PC's
>> these days.
>
> According to:
> http://en.wikipedia.org/wiki/Microsoft_Windows
>
> the relation between Vista and XP is about 30% vs 70%
>
> So, if we give the 30% Vistas a 100% of preinstalled
> .NET 2.0 - and the remaining 70% of XP a value of
> 30% of installed Framework-2.0 versions, then indeed,
> you end up with:
> 0.3*1.0 + 0.7*0.3 = 0.51
>

And where did you pluck that 30% of XP has .Net installed figure from ???
Just making things up ?

> So, yeah - you are right

Thanks.

>
> But wait - now I bring up the yet remaining W2K, Me
> and Win98 installations, which I neglected for now, since
> they only make up a total of about 2.1% market-share
> nowadays

yeh well you're welcome to them ;)
you forgot about DOS and Windows 3.1 too ;)

> But another question that is somewhat related:
> Do you already use the recommended WPF-GUIs
> in your App (only available in .NET 3.5 - or just wait
> for 4.0 for "even better" WPF-support) - or are you yet
> coding against the "deprecated" WinForms" which
> 2.0 has to offer?
>

If winforms is deprecated, then there's no future at all for VB6, as they
both use the same basic windows API, albeit Winforms does so in a more
modern way and with niceties such as full Unicode support etc, etc. But if
your argument about .NET framework being readily available on most machines
is now one that Winforms is somehow deprecated, then your argument is
against VB6 as well.

> And what do you think is the currently preinstalled
> percentage for these newer versions? ;-)
>

<sigh> Again you still don't seme ot get it. Again, remember VB4. How many
Windows 95 had VB4 ? how many Windows 3.1 ? Remeber back when VB6 was
released, how many Windows 98 had VB6 ? Still don't get it yet ??

> I mean, in your post to SupaFly you told him, that
> it would have been a wise decision, to change to the
> "newer, better stuff" earlier - a fool who does not do
> so, hence my question to you is eligible I'd say.
>

Actually those are all your words not mine. Nice try though. Here's
*Exactly* what I wrote, not what you try to spin it as :

"Well, if you started it three years ago, you should have been well aware of
..NET then and could and should have worked towards making your code suitable
for the move to .NET. Clearly if you want multi-threading, VB.NET would
have been the correct way to go. In fact you can still do that today by
writing the multithreaded parts of your app in VB.NET and call on your
VB.NET dll from your existing code. "

> Hoping now, that the "ranting" in my (just linked)
> post does make a bit more sense to you, regarding
> these "stable APIs" a developer wants to work against.
>

ROFL !!

12 Jun 2009 6:50 AM

Schmidt

Show quote Hide quote

"Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
news:OLQoQFy6JHA.1716@TK2MSFTNGP03.phx.gbl...

> > According to:
> > http://en.wikipedia.org/wiki/Microsoft_Windows
> >
> > the relation between Vista and XP is about 30% vs 70%
> >
> > So, if we give the 30% Vistas a 100% of preinstalled
> > .NET 2.0 - and the remaining 70% of XP a value of
> > 30% of installed Framework-2.0 versions, then indeed,
> > you end up with:
> > 0.3*1.0 + 0.7*0.3 = 0.51
> >
>
> And where did you pluck that 30% of XP has .Net installed
> figure from ???

Don't know, just a guess? ;)

Do you have a reliable source which states conrete values?

The only relative reliable assumption can be made probably
from the current ATI-marketshare (graphics-cards, running
on XP) from this chart for example:
http://origin.arstechnica.com/news.media/JPRMarket.jpg

ATI hereby probably the main-distributor of the .NET-
framework, since it is undoubtedly a needed prerequisite,
to "change a few driver settings over a top-notch GUI".

So about 15-17 of these 30 percents are apparently
already "safe".

Not sure about the rest - of course the ratio of software-
developers in relation to "normal-human-beings" could
probably be added - whatever the value is in reality,
but wait, maybe add only half of the value - not every
developer needs the framework to develop software
for windows (aside from the ATI-guys of course).

And a larger part adds presumably over Windows-Updates
running on these machines of all the lost souls, who haven't
deactivated it yet (or don't even know, that it exists). <g>

> Just making things up ?

Of course I'm making a bit of fun ... Bill, you are only
bearable in that mode ... didn't know that?

Show quoteHide quote

> > So, yeah - you are right
>
> Thanks.
Any time. :-)

> > But another question that is somewhat related:
> > Do you already use the recommended WPF-GUIs
> > in your App (only available in .NET 3.5 - or just wait
> > for 4.0 for "even better" WPF-support) - or are you yet
> > coding against the "deprecated" WinForms" which
> > 2.0 has to offer?
>
> If winforms is deprecated, then there's no future at all for
> VB6, as they both use the same basic windows API,

Hmm, if they both use the same windows API, how is
VB6 then in danger?

> ...
> But if your argument about .NET framework being readily
> available on most machines is now one that Winforms is
> somehow deprecated, then your argument is against VB6
> as well.

Ok, so we already have two deprecated versions now -
so what was your argument, why I should switch from
from one deprecated version to another one?

Hmm, think I decide, to use my already familiar deprecated
version for a few years more. Maybe I can also skip that
WPF-thingy entirely - and then just use the next great thing,
whatever the MS-marketing decides that will be.

[upcoming .NET4]

> > And what do you think is the currently preinstalled
> > percentage for these newer versions? ;-)
>
> <sigh> Again you still don't seme ot get it. Again,
> remember VB4. How many Windows 95 had VB4 ?
> how many Windows 3.1 ? Remeber back when VB6
> was released, how many Windows 98 had VB6 ?
> Still don't get it yet ??

Of course I get it - what I get is, that for the first time I
have a preinstalled runtime-version for my programming-
tool of choice, which has a 99% coverage on all current
systems, including the upcoming OS-version (now given,
that Win98 is soon going "out of scope").

I feel really happy Bill, ...hmm, think I'll buy my children
an extra-icecream now...

Olaf

12 Jun 2009 7:23 AM

Tom Shelton

On 2009-06-12, Schmidt <s**@online.de> wrote:
Show quoteHide quote

>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:OLQoQFy6JHA.1716@TK2MSFTNGP03.phx.gbl...
>
>> > According to:
>> > http://en.wikipedia.org/wiki/Microsoft_Windows
>> >
>> > the relation between Vista and XP is about 30% vs 70%
>> >
>> > So, if we give the 30% Vistas a 100% of preinstalled
>> > .NET 2.0 - and the remaining 70% of XP a value of
>> > 30% of installed Framework-2.0 versions, then indeed,
>> > you end up with:
>> > 0.3*1.0 + 0.7*0.3 = 0.51
>> >
>>
>> And where did you pluck that 30% of XP has .Net installed
>> figure from ???
> Don't know, just a guess? ;)
>
> Do you have a reliable source which states conrete values?
>
> The only relative reliable assumption can be made probably
> from the current ATI-marketshare (graphics-cards, running
> on XP) from this chart for example:
> http://origin.arstechnica.com/news.media/JPRMarket.jpg
>
> ATI hereby probably the main-distributor of the .NET-
> framework, since it is undoubtedly a needed prerequisite,
> to "change a few driver settings over a top-notch GUI".
>
> So about 15-17 of these 30 percents are apparently
> already "safe".
>
> Not sure about the rest - of course the ratio of software-
> developers in relation to "normal-human-beings" could
> probably be added - whatever the value is in reality,
> but wait, maybe add only half of the value - not every
> developer needs the framework to develop software
> for windows (aside from the ATI-guys of course).
>
> And a larger part adds presumably over Windows-Updates
> running on these machines of all the lost souls, who haven't
> deactivated it yet (or don't even know, that it exists). <g>
>
>> Just making things up ?
> Of course I'm making a bit of fun ... Bill, you are only
> bearable in that mode ... didn't know that?
>
>> > So, yeah - you are right
>>
>> Thanks.
> Any time. :-)
>
>
>> > But another question that is somewhat related:
>> > Do you already use the recommended WPF-GUIs
>> > in your App (only available in .NET 3.5 - or just wait
>> > for 4.0 for "even better" WPF-support) - or are you yet
>> > coding against the "deprecated" WinForms" which
>> > 2.0 has to offer?
>>
>> If winforms is deprecated, then there's no future at all for
>> VB6, as they both use the same basic windows API,
> Hmm, if they both use the same windows API, how is
> VB6 then in danger?
>
>> ...
>> But if your argument about .NET framework being readily
>> available on most machines is now one that Winforms is
>> somehow deprecated, then your argument is against VB6
>> as well.
> Ok, so we already have two deprecated versions now -
> so what was your argument, why I should switch from
> from one deprecated version to another one?
>
> Hmm, think I decide, to use my already familiar deprecated
> version for a few years more. Maybe I can also skip that
> WPF-thingy entirely - and then just use the next great thing,
> whatever the MS-marketing decides that will be.
>
> [upcoming .NET4]
>> > And what do you think is the currently preinstalled
>> > percentage for these newer versions? ;-)
>>
>> <sigh> Again you still don't seme ot get it. Again,
>> remember VB4. How many Windows 95 had VB4 ?
>> how many Windows 3.1 ? Remeber back when VB6
>> was released, how many Windows 98 had VB6 ?
>> Still don't get it yet ??
> Of course I get it - what I get is, that for the first time I
> have a preinstalled runtime-version for my programming-
> tool of choice, which has a 99% coverage on all current
> systems, including the upcoming OS-version (now given,
> that Win98 is soon going "out of scope").
>
> I feel really happy Bill, ...hmm, think I'll buy my children
> an extra-icecream now...
>
>
> Olaf
>
>

A few points - for your education:

1) WPF was avaialbe starting in .NET 3.0
2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run on the
    2.0 runtime - the newer versions simply added compiler features and new
    libraries.
3) Winforms has not been deprecated, though I am starting to do new project
    development using WPF.
4) Code written and compiled against 1.0 will, in almost all cases, run on a
    current 2.0 runtime.

And it's been sometime since I've had to deal with an xp machine that didn't
have the .net runtime installed.

--
Tom Shelton

12 Jun 2009 8:22 AM

Schmidt

"Tom Shelton" <tom_shel***@comcastXXXXXXX.net> schrieb im Newsbeitrag
news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...

> 1) WPF was avaialbe starting in .NET 3.0

Ok, but not yet really usable at this point in time - at least
that's what I read in my dotnet-pro-journal subscription.
The articles on "how to WPF" are popping up slowly now,
mainly mentioning, that the IDE and the external designers
(Blend) for advanced WPF-stuff was not yet at a usable
level some time ago.

> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run
> on the 2.0 runtime - the newer versions simply added compiler
> features and new libraries.

I know that, but does an application which already incorporates
for example Linq and/or WPF can run without installing
"additional stuff on top of 2.0"?

I doubt that, since I was told some time ago, that I will have
to install .NET 3.5, to try out a small Linq-example on XP.

> 3) Winforms has not been deprecated, though I am starting to
> do new project development using WPF.

IIRC I've put that into quotes ... just checking ... yes,
there is a "deprecated" in it.

> 4) Code written and compiled against 1.0 will, in almost all cases,
> run on a current 2.0 runtime.

Now, does WPF and Linq already run on a plain 2.0-install?

> And it's been sometime since I've had to deal with an xp machine
> that didn't have the .net runtime installed.

Same thing here - only the other way round. ;-)

Olaf

12 Jun 2009 8:44 AM

Tom Shelton

On 2009-06-12, Schmidt <s**@online.de> wrote:

>
> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> schrieb im Newsbeitrag
> news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...
>
>
>> 1) WPF was avaialbe starting in .NET 3.0
> Ok, but not yet really usable at this point in time - at least
> that's what I read in my dotnet-pro-journal subscription.
> The articles on "how to WPF" are popping up slowly now,
> mainly mentioning, that the IDE and the external designers
> (Blend) for advanced WPF-stuff was not yet at a usable
> level some time ago.
>

Well, considering I did a couple of major WPF projects during that time frame,
I would say it was useable. It's gotten a lot better as of 3.5, though.

>> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run
>> on the 2.0 runtime - the newer versions simply added compiler
>> features and new libraries.
> I know that, but does an application which already incorporates
> for example Linq and/or WPF can run without installing
> "additional stuff on top of 2.0"?
>
> I doubt that, since I was told some time ago, that I will have
> to install .NET 3.5, to try out a small Linq-example on XP.

That's because linq and wpf are some of the "additional libraries" I
mentioned..

>
>> 3) Winforms has not been deprecated, though I am starting to
>> do new project development using WPF.
> IIRC I've put that into quotes ... just checking ... yes,
> there is a "deprecated" in it.
>
>> 4) Code written and compiled against 1.0 will, in almost all cases,
>> run on a current 2.0 runtime.
> Now, does WPF and Linq already run on a plain 2.0-install?
>

Of course not - it doesn't have the libraries.

>> And it's been sometime since I've had to deal with an xp machine
>> that didn't have the .net runtime installed.
> Same thing here - only the other way round. ;-)

I imagine so.

--
Tom Shelton

12 Jun 2009 9:41 AM

Bill McCarthy

Hi Tom,

"Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...

> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run on
> the
> 2.0 runtime - the newer versions simply added compiler features and new
> libraries.

Nope. 4.0 is a different runtime that can run side by side with 2.0

12 Jun 2009 1:45 PM

Tom Shelton

On 2009-06-12, Bill McCarthy <TPASoft.com> wrote:

> Hi Tom,
>
> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
> news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...
>
>> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run on
>> the
>> 2.0 runtime - the newer versions simply added compiler features and new
>> libraries.
>
> Nope. 4.0 is a different runtime that can run side by side with 2.0
>

Hmmm... Ok. I hadn't really looked at it too deeply yet. I've been playing
with the VS2010 beta, but mostly experimenting with F# - hadn't looked at the
actual runtime yet :)

--
Tom Shelton

13 Jun 2009 3:19 AM

Bill McCarthy

Hi Tom,

Show quoteHide quote

"Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
news:ea%23f9P26JHA.2456@TK2MSFTNGP02.phx.gbl...
> On 2009-06-12, Bill McCarthy <TPASoft.com> wrote:
>> Hi Tom,
>>
>> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
>> news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...
>>
>>> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run
>>> on
>>> the
>>> 2.0 runtime - the newer versions simply added compiler features and
>>> new
>>> libraries.
>>
>> Nope. 4.0 is a different runtime that can run side by side with 2.0
>>
>
> Hmmm... Ok. I hadn't really looked at it too deeply yet. I've been
> playing
> with the VS2010 beta, but mostly experimenting with F# - hadn't looked at
> the
> actual runtime yet :)
>

Ah you lucky man. I need to make some time and play with F# too, more for
the exerise of thinking with that functional view than anythign else ;) How
you finding it so far ? Any good links ?

As to 4.0 sxs with 2.0, there's some good entries on the CLR team's blog.

13 Jun 2009 4:43 AM

Tom Shelton

On 2009-06-13, Bill McCarthy <TPASoft.com> wrote:
Show quoteHide quote

> Hi Tom,
>
> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
> news:ea%23f9P26JHA.2456@TK2MSFTNGP02.phx.gbl...
>> On 2009-06-12, Bill McCarthy <TPASoft.com> wrote:
>>> Hi Tom,
>>>
>>> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
>>> news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...
>>>
>>>> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all run
>>>> on
>>>> the
>>>> 2.0 runtime - the newer versions simply added compiler features and
>>>> new
>>>> libraries.
>>>
>>> Nope. 4.0 is a different runtime that can run side by side with 2.0
>>>
>>
>> Hmmm... Ok. I hadn't really looked at it too deeply yet. I've been
>> playing
>> with the VS2010 beta, but mostly experimenting with F# - hadn't looked at
>> the
>> actual runtime yet :)
>>
>
> Ah you lucky man. I need to make some time and play with F# too, more for
> the exerise of thinking with that functional view than anythign else ;) How
> you finding it so far ? Any good links ?
>

I do have a few links. I'll post some on my blog or something soon. I'm sort
of working on an article about my experience with the language so far.

As for how am I finding it... I like it. I'm not sure I'm ready to throw in
the C# towel yet - but, I can definately see some potential. It is definately
a different way of thinking though :)

> As to 4.0 sxs with 2.0, there's some good entries on the CLR team's blog.
>

Thanks, I'll check it out. I did look in the 4.0 folder - and you are
definately correct, it's a full runtime install.

--
Tom Shelton

13 Jun 2009 6:31 AM

F# user

Hi Mr. Shelton,

I am new here, is this the newsgroup for F#

:-)

Cor

Show quoteHide quote

"Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
news:ecoL%23F%236JHA.1712@TK2MSFTNGP03.phx.gbl...
> On 2009-06-13, Bill McCarthy <TPASoft.com> wrote:
>> Hi Tom,
>>
>> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
>> news:ea%23f9P26JHA.2456@TK2MSFTNGP02.phx.gbl...
>>> On 2009-06-12, Bill McCarthy <TPASoft.com> wrote:
>>>> Hi Tom,
>>>>
>>>> "Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
>>>> news:%23W3HB7y6JHA.5012@TK2MSFTNGP05.phx.gbl...
>>>>
>>>>> 2) 2.0, 3.0, 3.5, and as near as I can tell from the 4.0 beta, all
>>>>> run
>>>>> on
>>>>> the
>>>>> 2.0 runtime - the newer versions simply added compiler features and
>>>>> new
>>>>> libraries.
>>>>
>>>> Nope. 4.0 is a different runtime that can run side by side with 2.0
>>>>
>>>
>>> Hmmm... Ok. I hadn't really looked at it too deeply yet. I've been
>>> playing
>>> with the VS2010 beta, but mostly experimenting with F# - hadn't looked
>>> at
>>> the
>>> actual runtime yet :)
>>>
>>
>> Ah you lucky man. I need to make some time and play with F# too, more
>> for
>> the exerise of thinking with that functional view than anythign else ;)
>> How
>> you finding it so far ? Any good links ?
>>
>
> I do have a few links. I'll post some on my blog or something soon. I'm
> sort
> of working on an article about my experience with the language so far.
>
> As for how am I finding it... I like it. I'm not sure I'm ready to throw
> in
> the C# towel yet - but, I can definately see some potential. It is
> definately
> a different way of thinking though :)
>
>> As to 4.0 sxs with 2.0, there's some good entries on the CLR team's blog.
>>
>
> Thanks, I'll check it out. I did look in the 4.0 folder - and you are
> definately correct, it's a full runtime install.
>
> --
> Tom Shelton

13 Jun 2009 6:46 AM

Bill McCarthy

Hi Tom,

Show quoteHide quote

"Tom Shelton" <tom_shel***@comcastXXXXXXX.net> wrote in message
news:ecoL%23F%236JHA.1712@TK2MSFTNGP03.phx.gbl...
>
> I do have a few links. I'll post some on my blog or something soon. I'm
> sort
> of working on an article about my experience with the language so far.
>
> As for how am I finding it... I like it. I'm not sure I'm ready to throw
> in
> the C# towel yet - but, I can definately see some potential. It is
> definately
> a different way of thinking though :)
>

Thanks I'll keep an eye out for it. I still view F# as "academic" but it
does address many of the conceptual issues we face as we move towards true
multi-processor//multi threading applications

Show quoteHide quote

>> As to 4.0 sxs with 2.0, there's some good entries on the CLR team's blog.
>>
>
> Thanks, I'll check it out. I did look in the 4.0 folder - and you are
> definately correct, it's a full runtime install.
>
> --
> Tom Shelton

13 Jun 2009 8:13 AM

Michael Williams

"Bill McCarthy" <Bill McCarthy is Liar and An Identity Thief> wrote in
message news:e%23UoEX96JHA.1764@TK2MSFTNGP06.phx.gbl...

> I need to make some time and play with F# too

Perhaps you'd have more time to do that if you stopped playing with your
sheep and stopped having your wet dreams about Micro$oft. Why don't you just
piss off and take your dotnet garbage with you. Take Cor Ligthert with you
as well. Judging by his MVP photo Ligthert looks as though he's having a
perpetual wet dream. He's got a face like a smacked arse. I'm sure you'd
enjoy yourselves together. Take Tom Shelton with you as well.

Mike

12 Jun 2009 9:39 AM

Bill McCarthy

Show quote Hide quote

"Schmidt" <s**@online.de> wrote in message
news:Oiz88uy6JHA.5008@TK2MSFTNGP05.phx.gbl...
>
> "Bill McCarthy" <TPASoft.com Are Identity Thieves> schrieb im Newsbeitrag
> news:OLQoQFy6JHA.1716@TK2MSFTNGP03.phx.gbl...
>
>> > According to:
>> > http://en.wikipedia.org/wiki/Microsoft_Windows
>> >
>> > the relation between Vista and XP is about 30% vs 70%
>> >
>> > So, if we give the 30% Vistas a 100% of preinstalled
>> > .NET 2.0 - and the remaining 70% of XP a value of
>> > 30% of installed Framework-2.0 versions, then indeed,
>> > you end up with:
>> > 0.3*1.0 + 0.7*0.3 = 0.51
>> >
>>
>> And where did you pluck that 30% of XP has .Net installed
>> figure from ???
> Don't know, just a guess? ;)
>

Uh huh. In other words you're makign thigns up again. that's why I
referred to your claims earlier as FUD.

HTH's :)

12 Jun 2009 9:11 AM

Cor Ligthert[MVP]

> http://en.wikipedia.org/wiki/Microsoft_Windows
>
> the relation between Vista and XP is about 30% vs 70%
>

I don't think that will last long anymore as with SP2 on Vista 64 my system
is extremely fast running

Cor

14 Jun 2009 5:39 PM

Mike Williams

"Bill McCarthy" <BillMcCarthy is an Identity Thief and a Liar> wrote in
message news:OBnDUGb6JHA.4116@TK2MSFTNGP04.phx.gbl...

> Clearly if you want multi-threading, VB.NET would
> have been the correct way to go.

That's just about the most stupid statement you've ever made, McCarthy, and
you've made some really stupid statement in the past! Are you seriously
suggesting that VB.Net is the only development environment that allows a
programmer to perform multi threading? If so then you are sorely mistaken!
But of course you are a well known liar and an identity thief, so nobody
really believes what you say.

Mike